[要約] RFC 3562は、TCP MD5 Signatureオプションのキーマネジメントに関する考慮事項を提供しています。このRFCの目的は、TCPセッションの認証とデータの完全性を確保するための適切なキーマネジメント手法を提案することです。
Network Working Group M. Leech
Request for Comments: 3562 Nortel Networks
Category:Informational July 2003
Key Management Considerations for the TCP MD5 Signature Option
TCP MD5署名オプションの主要な管理上の考慮事項
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material.
主にBGPが使用するTCP MD5署名オプション（RFC 2385）は、インターネットインフラストラクチャの重要な分野で重要な展開を見てきました。このオプションのセキュリティは、MD5の署名を計算するために使用されるキーイング材料の品質に大きく依存しています。このドキュメントでは、そのキーイング資料のセキュリティ要件に対応しています。
The security of various cryptographic functions lies both in the strength of the functions themselves against various forms of attack, and also, perhaps more importantly, in the keying material that is used with them. While theoretical attacks against the simple MAC construction used in RFC 2385 are possible [MDXMAC], the number of text-MAC pairs required to mount a forgery make it vastly more probable that key-guessing is the main threat against RFC 2385.
さまざまな暗号機能のセキュリティは、さまざまな形態の攻撃に対する関数自体の強度の両方にあり、さらにはより重要なことには、それらと一緒に使用されるキーイング素材の両方にあります。RFC 2385で使用される単純なMAC構造に対する理論的攻撃は可能ですが[MDXMAC]、偽造をマウントするために必要なテキストMACペアの数により、キー推測がRFC 2385に対する主な脅威である可能性が非常に高くなります。
We show a quantitative approach to determining the security requirements of keys used with [RFC2385], which tends to suggest the following:
[RFC2385]で使用されるキーのセキュリティ要件を決定するための定量的アプローチを示します。これは、以下を提案する傾向があります。
o Key lengths SHOULD be between 12 and 24 bytes, with larger keys having effectively zero additional computational costs when compared to shorter keys.
o キーの長さは12〜24バイトで、より短いキーと比較した場合、より大きなキーが追加の計算コストを効果的にゼロにする必要があります。
o Key sharing SHOULD be limited so that keys aren't shared among multiple BGP peering arrangements.
o キー共有は、キーが複数のBGPピアリングアレンジメントで共有されないように制限する必要があります。
o Keys SHOULD be changed at least every 90 days.
o キーは、少なくとも90日ごとに変更する必要があります。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
キーワードは、「必要はない」、「必須」、「必須」、「そうはない」、「そうではない」、およびこのドキュメントに表示される「可能性」は、[RFC2119]で説明されているように解釈されるべきです。
The most recent performance study of MD5 that this author was able to find was undertaken by J. Touch at ISI. The results of this study were documented in [RFC1810]. The assumption is that Moores Law applies to the data in the study, which at the time showed a best-possible *software* performance for MD5 of 87Mbits/second. Projecting this number forward to the ca 2002 timeframe of this document, would suggest a number near 2.1Gbits/second.
この著者が見つけたMD5の最新のパフォーマンス研究は、ISIでJ. Touchが実施しました。この研究の結果は[RFC1810]に記録されました。仮定は、ムーアの法律が研究のデータに適用され、当時は87Mbits/秒のMD5の最適な *ソフトウェア *パフォーマンスを示したことです。この数字をこの文書のCA 2002の時間枠に投影すると、2.1Gbits/秒近くの数字が示唆されます。
For purposes of simplification, we will assume that our key-guessing attacker will attack short packets only. A likely minimal packet is an ACK, with no data. This leads to having to compute the MD5 over about 40 bytes of data, along with some reasonable maximum number of key bytes. MD5 effectively pads its input to 512-bit boundaries (64 bytes) (it's actually more complicated than that, but this simplifying assumption will suffice for this analysis). That means that a minimum MD5 "block" is 64 bytes, so for a ca 2002-scaled software performance of 2.1Gbits/second, we get a single-CPU software MD5 performance near 4.1e6 single-block MD5 operations per second.
単純化の目的のために、キー推測の攻撃者が短いパケットのみを攻撃すると仮定します。おそらく最小限のパケットはACKで、データはありません。これにより、約40バイトのデータと、適切な最大数のキーバイトでMD5を計算する必要があります。MD5は、入力を効果的に512ビット境界（64バイト）にパッドします（実際にはそれよりも複雑ですが、この単純化された仮定はこの分析で十分です）。つまり、最小MD5「ブロック」は64バイトであるため、CA 2002スケールのソフトウェアパフォーマンスが2.1Gbits/秒である場合、1秒あたり4.1E6シングルブロックMD5操作の近くにシングルCPUソフトウェアMD5パフォーマンスが得られます。
These numbers are, of course, assuming that any key-guessing attacker is resource-constrained to a single CPU. In reality, distributed cryptographic key-guessing attacks have been remarkably successful in the recent past.
もちろん、これらの数字は、キー推測の攻撃者が単一のCPUにリソースに制約されていると仮定しています。現実には、分散型の暗号化されたキー推測攻撃は、最近の過去に非常に成功しています。
It may be instructive to look at recent Internet worm infections, to determine what the probable maximum number of hosts that could be surreptitiously marshalled for a key-guessing attack against MD5. CAIDA [CAIDA2001] has reported that the Code Red worm infected over 350,000 Internet hosts in the first 14 hours of operation. It seems reasonable to assume that a worm whose "payload" is a mechanism for quietly performing a key-guessing attack (perhaps using idle CPU cycles of the infected host) could be at least as effective as Code Red was. If one assumes that such a worm were engineered to be maximally stealthy, then steady-state infection could conceivably reach 1 million hosts or more. That changes our single-CPU performance from 4.1e6 operations per second, to somewhere between 1.0e11 and 1.0e13 MD5 operations per second.
最近のインターネットワーム感染症を調べて、MD5に対するキー推測攻撃のために秘密にマーシャリングされる可能性のある宿主の可能性がどのようなものを決定するかを判断することは有益かもしれません。Caida [Caida2001]は、コードレッドワームが最初の14時間の操作で350,000を超えるインターネットホストに感染したことを報告しています。「ペイロード」がキー推測攻撃（おそらく感染した宿主のアイドルCPUサイクルを使用）を静かに実行するメカニズムであるワームは、少なくともコードレッドと同じくらい効果的である可能性があると想定するのは合理的と思われます。そのようなワームが最大限にステルスになるように設計されていると仮定した場合、定常状態の感染症はおそらく100万人以上の宿主に達する可能性があります。これにより、シングルCPUのパフォーマンスは、1秒あたり4.1E6操作から、1秒あたり1.0E11から1.0E13 MD5の操作に変わります。
In 1997, John Gilmore, and the Electronic Frontier Foundation [EFF98] developed a special-purpose machine, for an investment of approximately USD$250,000. This machine was able to mount a key-guessing attack against DES, and compute a key in under 1 week. Given Moores Law, the same investment today would yield a machine that could do the same work approximately 8 times faster. It seems reasonable to assume that a similar hardware approach could be brought to bear on key-guessing attacks against MD5, for similar key lengths to DES, with somewhat-reduced performance (MD5 performance in hardware may be as much as 2-3 times slower than DES).
1997年、ジョンギルモアと電子フロンティア財団[EFF98]は、約250,000米ドルの投資のために特別な目的マシンを開発しました。このマシンは、DESに対するキー推測攻撃を取り付け、1週間以内にキーを計算することができました。ムーアの法律を考えると、今日の同じ投資は、同じ作業を約8倍高速に行うことができる機械を生み出します。同様のハードウェアアプローチをMD5に対するキー推測攻撃に耐えることができると仮定するのは合理的であると思われます。DESより）。
Operational experience with RFC 2385 would suggest that keys used with this option may have lifetimes on the order of months. It would seem prudent, then, to choose a minimum key length that guarantees that key-guessing runtimes are some small multiple of the key-change interval under best-case (for the attacker) practical attack performance assumptions.
RFC 2385での運用経験は、このオプションで使用されるキーが数か月の順序で寿命を持っている可能性があることを示唆しています。したがって、キーからの推測のランタイムが、ベストケース（攻撃者の場合）の実用的な攻撃パフォーマンスの仮定の下でのキー変更間隔のいくつかの小さな倍数であることを保証する最小キーの長さを選択することは賢明に思えます。
The keys used with RFC 2385 are intended only to provide authentication, and not confidentiality. Consequently, the ability of an attacker to determine the key used for old traffic (traffic emitted before a key-change event) is not considered a threat.
RFC 2385で使用されるキーは、認証のみを提供することを目的としており、機密性はありません。その結果、攻撃者が古いトラフィックに使用されるキー（キー変更イベントの前に放出されるトラフィック）を決定する能力は、脅威とは見なされません。
If we make an assumption that key-change intervals are 90 days, and that the reasonable upper-bound for software-based attack performance is 1.0e13 MD5 operations per second, then the minimum required key entropy is approximately 68 bits. It is reasonable to round this number up to at least 80 bits, or 10 bytes. If one assumes that hardware-based attacks are likely, using an EFF-like development process, but with small-country-sized budgets, then the minimum key size steps up considerably to around 83 bits, or 11 bytes. Since 11 is such an ugly number, rounding up to 12 bytes is reasonable.
キーチェンジ間隔は90日であり、ソフトウェアベースの攻撃パフォーマンスの合理的な上限が1秒あたり1.0E13 MD5操作であると仮定した場合、最小必要なキーエントロピーは約68ビットであると仮定します。この数を少なくとも80ビット、または10バイトまで締めくくることは合理的です。EFFのような開発プロセスを使用して、ハードウェアベースの攻撃が可能性が高いと仮定した場合、小国サイズの予算では、最小キーサイズが約83ビット、または11バイトまでかなり上昇します。11はこのような醜い数であるため、最大12バイトの丸めは妥当です。
In order to achieve this much entropy with an English-language key, one needs to remember that English has an entropy of approximately 1.3 bits per character. Other human languages are similar. This means that a key derived from a human language would need to be approximately 61 bytes long to produce 80 bits of entropy, and 73 bytes to produce 96 bits of entropy.
英語のキーを使用してこのエントロピーを達成するためには、英語のエントロピーが文字あたり約1.3ビットのエントロピーを持っていることを覚えておく必要があります。他の人間の言語は似ています。これは、人間の言語から派生したキーは、80ビットのエントロピーを生成するには約61バイトの長さであり、96ビットのエントロピーを生成するために73バイトである必要があることを意味します。
A more reasonable approach would be to use the techniques described in [RFC1750] to produce a high quality random key of 96 bits or more.
より合理的なアプローチは、[RFC1750]で説明されている手法を使用して、96ビット以上の高品質のランダムキーを生成することです。
It has previously been noted that an attacker will tend to choose short packets to mount an attack on, since that increases the key-guessing performance for the attacker. It has also been noted that MD5 operations are effectively computed in blocks of 64 bytes. Given that the shortest packet an attacker could reasonably use would consist of 40 bytes of IP+TCP header data, with no payload, the remaining 24 bytes of the MD5 block can reasonably be used for keying material without added CPU cost for routers, but substantially increase the burden on the attacker. While this practice will tend to increase the CPU burden for ordinary short BGP packets, since it will tend to cause the MD5 calculations to overflow into a second MD5 block, it isn't currently seen to be a significant extra burden to BGP routing machinery.
攻撃者は、攻撃者のキー推測パフォーマンスを向上させるため、攻撃者が攻撃を行うために短いパケットを選択する傾向があることに注意しています。また、MD5操作は64バイトのブロックで効果的に計算されていることも注目されています。攻撃者が合理的に使用できる最短のパケットは、ペイロードなしで40バイトのIP TCPヘッダーデータで構成されていることを考えると、MD5ブロックの残りの24バイトは、ルーターのCPUコストを追加せずに材料をキーリングするために合理的に使用できますが、大幅に増加します攻撃者の負担。このプラクティスは、通常の短いBGPパケットのCPUの負担を増加させる傾向がありますが、MD5計算を2番目のMD5ブロックにオーバーフローする傾向があるため、BGPルーティング機械の大きな余分な負担であるとは見られていません。
The most reasonable practice, then, would be to choose the largest possible key length smaller than 25 bytes that is operationally reasonable, but at least 12 bytes.
最も合理的な慣行は、運用上合理的であるが少なくとも12バイトである25バイトよりも小さい最大のキー長を選択することです。
Some implementations restrict the key to a string of ASCII characters, much like simple passwords, usually of 8 bytes or less. The very real risk is that such keys are quite vulnerable to key-guessing attacks, as outlined above. The worst-case scenario would occur when the ASCII key/password is a human-language word, or pseudo-word. Such keys/passwords contain, at most, 12 bits of entropy. In such cases, dictionary driven attacks can yield results in a fraction of the time that a brute-force approach would take. Such implementations SHOULD permit users to enter a direct binary key using the command line interface. One possible implementation would be to establish a convention that an ASCII key beginning with the prefix "0x" be interpreted as a string of bytes represented in hexadecimal. Ideally, such byte strings will have been derived from a random source, as outlined in [RFC1750]. Implementations SHOULD NOT limit the length of the key unnecessarily, and SHOULD allow keys of at least 16 bytes, to allow for the inevitable threat from Moores Law.
いくつかの実装は、通常8バイト以下の単純なパスワードと同様に、キーを一連のASCII文字に制限します。非常に現実的なリスクは、上記のように、そのようなキーがキー推測攻撃に対して非常に脆弱であることです。最悪のシナリオは、ASCIIキー/パスワードが人間言語単語、または擬似ワードである場合に発生します。このようなキー/パスワードには、せいぜい12ビットのエントロピーが含まれています。そのような場合、辞書駆動攻撃は、ブルートフォースアプローチがとる時間のほんの一部で結果をもたらす可能性があります。このような実装により、ユーザーはコマンドラインインターフェイスを使用して直接バイナリキーを入力できるようになります。可能な実装の1つは、プレフィックス「0x」から始まるASCIIキーが16進数で表される一連のバイトとして解釈されるという条約を確立することです。理想的には、[RFC1750]で概説されているように、そのようなバイト文字列はランダムソースから派生しています。実装は、キーの長さを不必要に制限するものではなく、ムーアの法律による避けられない脅威を可能にするために、少なくとも16バイトのキーを許可する必要があります。
In current operational use, TCP MD5 Signature keys [RFC2385] may be shared among significant numbers of systems. Conventional wisdom in cryptography and security is that such sharing increases the probability of accidental or deliberate exposure of keys. The more frequently such keying material is handled, the more likely it is to be accidentally exposed to unauthorized parties.
現在の運用上の使用では、TCP MD5署名キー[RFC2385]は、かなりの数のシステム間で共有される場合があります。暗号化とセキュリティにおける従来の知恵は、そのような共有が偶発的または意図的なキーの露出の確率を高めるということです。そのようなキーイング素材がより頻繁に処理されるほど、不正な当事者に誤ってさらされる可能性が高くなります。
Since it is possible for anyone in possession of a key to forge packets as if they originated with any of the other keyholders, the most reasonable security practice would be to limit keys to use between exactly two parties. Current implementations may make this difficult, but it is the most secure approach when key lifetimes are long. Reducing key lifetimes can partially mitigate widescale key-sharing, by limiting the window of opportunity for a "rogue" keyholder.
パケットが他のキーホルダーのいずれかに由来するかのように、鍵を築くための鍵を所有している人は誰でも可能であるため、最も合理的なセキュリティ慣行は、正確に2つの関係者間で使用する鍵を制限することです。現在の実装はこれを難しくするかもしれませんが、重要な寿命が長いときに最も安全なアプローチです。キーライフタイムを減らすことは、「不正な」キーホルダーの機会の窓を制限することにより、ワイドスケールのキー共有を部分的に軽減できます。
Keying material is extremely sensitive data, and as such, should be handled with reasonable caution. When keys are transported electronically, including when configuring network elements like routers, secure handling techniques MUST be used. Use of protocols such as S/MIME [RFC2633], TLS [RFC2246], Secure Shell (SSH) SHOULD be used where appropriate, to protect the transport of the key.
キーイング素材は非常に敏感なデータであるため、合理的な注意を払って処理する必要があります。キーを電子的に輸送する場合、ルーターなどのネットワーク要素を構成するときは、安全な取り扱い手法を使用する必要があります。S/MIME [RFC2633]、TLS [RFC2246]、安全なシェル（SSH）などのプロトコルの使用は、キーの輸送を保護するために使用する必要があります。
This document is entirely about security requirements for keying material used with RFC 2385.
このドキュメントは、RFC 2385で使用されるキーイングマテリアルのセキュリティ要件に関するものです。
No new security exposures are created by this document.
このドキュメントによって新しいセキュリティエクスポージャーは作成されません。
Steve Bellovin, Ran Atkinson, and Randy Bush provided valuable commentary in the development of this document.
Steve Bellovin、Ran Atkinson、Randy Bushは、この文書の開発に貴重な解説を提供しました。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC1810] Touch、J。、「MD5パフォーマンスに関するレポート」、RFC 1810、1995年6月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MDXMAC] Van Oorschot, P. and B. Preneel, "MDx-MAC and Building Fast MACs from Hash Functions". Proceedings Crypto '95, Springer-Verlag LNCS, August 1995.
[MDXMAC] Van Oorschot、P。およびB. Preneel、「Mdx-MacおよびHash関数からの高速MACの構築」。Proceedings Crypto '95、Springer-Verlag LNCS、1995年8月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[EFF98] "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design". Electronic Frontier Foundation, 1998.
[Eff98]「クラッキングDE：暗号化研究、盗聴政治、チップデザインの秘密」。Electronic Frontier Foundation、1998年。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[CAIDA2001] "CAIDA Analysis of Code Red" http://www.caida.org/analysis/security/code-red/
[Caida2001] "Caida分析コードレッド" http://www.caida.org/analysis/security/code-red/
Marcus D. Leech Nortel Networks P.O. Box 3511, Station C Ottawa, ON Canada, K1Y 4H7
Marcus D. Leech Nortel Networks P.O.ボックス3511、駅Cオタワ、カナダ、K1Y4H7
Phone: +1 613-763-9145
EMail: mleech@nortelnetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。