Network Working Group M. Leech
Request for Comments: 3562 Nortel Networks
Category:Informational July 2003
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.
版权所有（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.
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]中。假设摩尔定律适用于研究中的数据，该数据当时显示出MD5的最佳软件性能为87Mbits/s。将这个数字预测到本文件的ca 2002时间段，将建议一个接近2.1Gbit/s的数字。
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字节，因此对于2.1Gbit/s的ca 2002扩展软件性能，我们可以获得接近每秒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
查看最近的Internet蠕虫感染情况，以确定针对MD5的密钥猜测攻击可能秘密编组的最大主机数可能是多少，这可能会很有启发性。CAIDA[CAIDA2001]报告说，红色代码蠕虫在运行的头14小时内感染了35万多台互联网主机。假设一个蠕虫的“有效载荷”是一种安静地执行密钥猜测攻击（可能使用受感染主机的空闲CPU周期）的机制，那么它至少可以和红色代码一样有效。如果有人假设这种蠕虫被设计成最大程度的隐蔽性，那么稳态感染可能达到100万或更多的宿主。这改变了我们的单一CPU
performance from 4.1e6 operations per second, to somewhere between 1.0e11 and 1.0e13 MD5 operations per second.
性能从每秒4.1e6次操作，到每秒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，John Gilmore和电子前沿基金会（EF998）开发了一种专用机器，投资约250000美元。这台机器能够对DES发起密钥猜测攻击，并在不到1周的时间内计算出一个密钥。根据摩尔定律，今天同样的投资将产生一台机器，它能以大约8倍的速度完成同样的工作。似乎可以合理地假设，对于与DES相似的密钥长度，可以采用类似的硬件方法来应对针对MD5的密钥猜测攻击，但性能有所降低（硬件中的MD5性能可能比DES慢2-3倍）。
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位。其他人类语言也类似。这意味着从人类语言派生的密钥需要大约61字节长才能产生80位的熵，73字节长才能产生96位的熵。
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计算溢出到第二个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.
因此，最合理的做法是选择可能的最大密钥长度，该长度小于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.
一些实现将密钥限制为ASCII字符字符串，很像简单的密码，通常为8字节或更少。真正的风险是，如上所述，这些密钥非常容易受到密钥猜测攻击。最坏的情况是ASCII键/密码是人类语言单词或伪单词。这些密钥/密码最多包含12位熵。在这种情况下，字典驱动的攻击可以在蛮力方法所需时间的一小部分内产生结果。此类实现应允许用户使用命令行界面输入直接二进制密钥。一种可能的实现是建立一种约定，即以前缀“0x”开头的ASCII键被解释为以十六进制表示的字节字符串。理想情况下，如[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.
由于拥有密钥的任何人都有可能伪造数据包，就好像这些数据包是由其他任何密钥持有人伪造的一样，因此最合理的安全实践是限制密钥仅在两方之间使用。当前的实现可能会使这一点变得困难，但在密钥生命周期较长的情况下，这是最安全的方法。通过限制“流氓”密钥持有者的机会窗口，缩短密钥寿命可以部分缓解大规模密钥共享。
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]、Secure Shell（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）、阿特金森（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，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC1810]Touch，J.，“MD5性能报告”，RFC1810，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.
Van Oorschot，P.和B.Preneel，“MDx MAC和利用哈希函数构建快速MAC”。1995年8月，斯普林格·维拉格LNCS出版的《1995年加密诉讼》。
[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]“破解DES：加密研究、窃听政治和芯片设计的秘密”。电子前沿基金会，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”，RFC2246，1999年1月。
[CAIDA2001] "CAIDA Analysis of Code Red"
http://www.caida.org/analysis/security/code-red/
[CAIDA2001] "CAIDA Analysis of Code Red"
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邮政信箱3511，加拿大渥太华C站，K1Y 4H7
Phone: +1 613-763-9145
EMail: mleech@nortelnetworks.com
Phone: +1 613-763-9145
EMail: 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编辑功能的资金目前由互联网协会提供。