From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3562.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3562.txt (limited to 'doc/rfc/rfc3562.txt') diff --git a/doc/rfc/rfc3562.txt b/doc/rfc/rfc3562.txt new file mode 100644 index 0000000..7a23a5b --- /dev/null +++ b/doc/rfc/rfc3562.txt @@ -0,0 +1,395 @@ + + + + + + +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. + +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. + +1. Introduction + + 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. + + We show a quantitative approach to determining the security + requirements of keys used with [RFC2385], which tends to suggest the + following: + + o Key lengths SHOULD be between 12 and 24 bytes, with larger keys + having effectively zero additional computational costs when + compared to shorter keys. + + + + + + + +Leech Informational [Page 1] + +RFC 3562 Considerations for the TCP MD5 Signature Option July 2003 + + + o Key sharing SHOULD be limited so that keys aren't shared among + multiple BGP peering arrangements. + + o Keys SHOULD be changed at least every 90 days. + +1.1. Requirements Keywords + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + and "MAY" that appear in this document are to be interpreted as + described in [RFC2119]. + +2. Performance assumptions + + 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. + + 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. + + 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. + + 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 + + + +Leech Informational [Page 2] + +RFC 3562 Considerations for the TCP MD5 Signature Option July 2003 + + + performance from 4.1e6 operations per second, to somewhere between + 1.0e11 and 1.0e13 MD5 operations per second. + + 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). + +3. Key Lifetimes + + 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. + + 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. + +3. Key Entropy + + 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. + + 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. + + + + + +Leech Informational [Page 3] + +RFC 3562 Considerations for the TCP MD5 Signature Option July 2003 + + + 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. + + 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. + + 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. + + 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. + +4. Key management practices + + 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. + + + + +Leech Informational [Page 4] + +RFC 3562 Considerations for the TCP MD5 Signature Option July 2003 + + + 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. + +5. Security Considerations + + This document is entirely about security requirements for keying + material used with RFC 2385. + + No new security exposures are created by this document. + +6. Acknowledgements + + Steve Bellovin, Ran Atkinson, and Randy Bush provided valuable + commentary in the development of this document. + +7. References + + [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 + (BGP-4)", RFC 1771, March 1995. + + [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June + 1995. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP + MD5 Signature Option", RFC 2385, August 1998. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MDXMAC] Van Oorschot, P. and B. Preneel, "MDx-MAC and Building + Fast MACs from Hash Functions". Proceedings Crypto '95, + Springer-Verlag LNCS, August 1995. + + [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + + +Leech Informational [Page 5] + +RFC 3562 Considerations for the TCP MD5 Signature Option July 2003 + + + [EFF98] "Cracking DES: Secrets of Encryption Research, Wiretap + Politics, and Chip Design". Electronic Frontier + Foundation, 1998. + + [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", + RFC 2633, June 1999. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [CAIDA2001] "CAIDA Analysis of Code Red" + http://www.caida.org/analysis/security/code-red/ + +8. Author's Address + + Marcus D. Leech + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON + Canada, K1Y 4H7 + + Phone: +1 613-763-9145 + EMail: mleech@nortelnetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leech Informational [Page 6] + +RFC 3562 Considerations for the TCP MD5 Signature Option July 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + 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. + + + + + + + + + + + + + + + + + + + +Leech Informational [Page 7] + -- cgit v1.2.3