Network Working Group M. Leech
Request for Comments: 3562 Nortel Networks
Category:Informational July 2003
Key Management Considerations for
the TCP MD5 Signature Option
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.
著作権（C）インターネット協会（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.
キーが複数のBGPピアリングアレンジメントの間で共有されないように、O鍵共有を制限する必要があります。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "SHOULD NOT"、および[RFC2119]で説明したように解釈されるべきであり、この文書に表示される "MAY"。
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.タッチで行われました。この研究の結果は、[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バイト）にその入力をパッド。 2.1Gbits /秒のCA 2002スケールのソフトウェアのパフォーマンスのために、我々は毎秒4.1e6シングルブロックMD5操作近いシングルCPUソフトウェアのMD5のパフォーマンスを得るように、最低限のMD5「ブロック」は64バイトであることを意味しています。
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] Code Redワームは、操作の最初の14時間で35万以上のインターネットホストに感染することを報告しています。その「ペイロード」静かに（おそらく感染したホストのアイドルCPUサイクルを使用して）、キー推測攻撃を実行するための仕組みであるワームはCode Redのがあったように、少なくともとして有効であることができることを考えるのが妥当と思われます。 1は、このようなワームが最大限に内証であるように操作されたと仮定した場合、定常状態の感染が考えられる100万台のホスト以上に達する可能性があります。それは毎秒1.0e11と1.0e13 MD5操作の間のどこかに、毎秒4.1e6事業からの当社のシングルCPUのパフォーマンスを変更します。
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年には、ジョン・ギルモア、および電子フロンティア財団（EFF）[EFF98]は、約USD $ 250,000の投資のために、専用機を開発しました。このマシンは、1週間の下で鍵をDESに対するキー推測攻撃をマウントし、計算することができました。ムーア法律、同じ投資を考えると、今日は約8倍の速さと同じ作業を行うことができ、マシンをもたらすであろう。ハードウェアで多少、性能低下（MD5性能は同じくらい2~3倍遅くなることがありますと同様のハードウェアのアプローチは、DESに類似キーの長さのために、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.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ビットのエントロピーを持っていることを覚えておく必要があります。他の人間の言語は似ています。これは、人間の言語から導出鍵はエントロピーの96ビットを生成するエントロピーの80ビット、および73のバイトを生成するのに長い約61バイトである必要があることを意味します。
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.
より合理的なアプローチは、96ビット以上の高品質ランダム鍵を生成するために、[RFC1750]に記載された技術を使用することであろう。
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バイトのブロックで計算されることが指摘されています。実質的に、攻撃者が合理的に使用することができ、最短パケットがないペイロードと、IP + TCPヘッダデータの40バイトから成るであろうことを考えると、MD5ブロックの残りの24のバイトは合理ルータの追加のCPUコストをかけずに材料を合わせるために使用することができるが、攻撃者の負担を増やします。このような行為は、それがMD5の計算が第二MD5ブロックにオーバーフローさせる傾向があるため、通常の短いBGPパケットのCPUの負担を増加させる傾向があるだろうが、現在、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.
最も合理的な練習は、それから、運用が合理的である25のバイトが、少なくとも12バイトよりも小さい可能な最大キー長を選択することです。
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ビットを含みます。このような場合には、辞書ドリブン攻撃はブルートフォースアプローチはかかる時間の割合で結果を得ることができます。このような実装では、コマンドライン・インタフェースを使用して直接バイナリキーを入力するようユーザーに許可すべきです。一つの可能な実装では、接頭辞「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.
彼らは他のキーホルダーのいずれかに由来するかのようにキーを所有している誰もがパケットを偽造することが可能であるので、最も合理的なセキュリティプラクティスは、正確に二者の間で使用するキーを制限するだろう。現在の実装では、これが困難になるかもしれないが、キーの有効期間が長い最も安全なアプローチです。キーの有効期間を減らすことは、部分的に「不正」キーホルダーのための機会の窓を制限することによって、widescale鍵共有を軽減することができます。
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.
スティーブBellovin氏は、アトキンソンを走り、ランディブッシュ大統領は、このドキュメントの開発に貴重な論評を提供しました。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC1810]タッチ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]バンOorschot、P.とB. Preneel、 "ハッシュ関数からMDX-MACおよびビル高速のMAC"。議事暗号'95、シュプリンガー・フェアラークLNCS、1995年8月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[EFF98] "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design". Electronic Frontier Foundation, 1998.
[EFF98]「DESをクラック：暗号研究と盗聴政策、チップ設計の秘密」。電子フロンティア財団（EFF）、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]ダークス、T.とC.アレン、 "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
マーカスD.ヒルNortel Networksの私書箱ボックス3511、駅のCオタワ、カナダON、K1Y 4H7
Phone: +1 613-763-9145 EMail: mleech@nortelnetworks.com
電話：+1 613-763-9145電子メール：mleech@nortelnetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。