GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3562

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3562.txt · Last modified: 2003/07/02 23:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki