RFC 3562

RFC 3562: Key Management Considerations for the TCP MD5 Signature Option ✨

Okay bestie, this is RFC 3562 🎀 It's about how to pick and handle the secret keys for the TCP MD5 Signature Option, so the keys can't be guessed. Let's get into it 💅

• RFC number: 3562
• Author: M. Leech, Nortel Networks 🦋
• Series: Network Working Group
• Category: Informational
• Date: July 2003
• Obsoletes / Updates: the title block doesn't list any RFCs that this one obsoletes or updates 🌸

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. So it's just info, not a rule book, and anyone can share it 💜

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved. 📜

Abstract

The TCP MD5 Signature Option ([RFC2385]) is used mostly by BGP, and it's been deployed in really critical parts of Internet infrastructure 🌈 Its security depends heavily on how good the keying material is, because that material is what goes into the MD5 signature. This document looks at the security requirements for that keying material 🔐

1. Introduction ✨

Okay so, the security of a cryptographic function comes from two things: how strong the function is against different kinds of attack, and, maybe even more importantly, the keying material you use with it 🔑 Theoretical attacks on the simple MAC construction used in RFC 2385 are possible [MDXMAC]. But you'd need a bunch of text-MAC pairs to forge anything, which makes key-guessing way more likely to be the main threat against RFC 2385 😭

This document takes a quantitative approach to figuring out the security requirements for keys used with [RFC2385]. Here's what it suggests:

• Key lengths SHOULD be between 12 and 24 bytes. Larger keys have effectively zero extra computational cost compared to shorter ones 💖
• Key sharing SHOULD be limited so that keys aren't shared among multiple BGP peering arrangements 🙅‍♀️
• 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]. Those are the official BCP 14 words, so read them carefully 🧐

2. Performance assumptions

The most recent performance study of MD5 that this author could find was done by J. Touch at ISI 🧪 The results were written up in [RFC1810]. The assumption here is that Moores Law applies to the data in that study. At the time, the best-possible software performance for MD5 was 87Mbits/second. Projecting that forward to the ca 2002 timeframe of this document suggests a number near 2.1Gbits/second 📈

To keep things simple, we'll assume our key-guessing attacker only attacks short packets. A likely minimal packet is an ACK with no data. That means computing MD5 over about 40 bytes of data, plus some reasonable maximum number of key bytes 🎯 MD5 effectively pads its input to 512-bit boundaries (64 bytes). (Okay, it's actually more complicated than that, but this simplifying assumption is good enough for this analysis 🙈) So a minimum MD5 "block" is 64 bytes. For a ca 2002-scaled software performance of 2.1Gbits/second, that works out to a single-CPU software MD5 performance near 4.1e6 single-block MD5 operations per second 🔥

These numbers assume the key-guessing attacker is limited to a single CPU. In reality, distributed cryptographic key-guessing attacks have been super successful recently 👀

It's useful to look at recent Internet worm infections to figure out the probable maximum number of hosts that could be secretly recruited for a key-guessing attack against MD5 🐛 CAIDA [CAIDA2001] reported that the Code Red worm infected over 350,000 Internet hosts in its first 14 hours. It seems reasonable to assume that a worm whose "payload" is a mechanism for quietly performing a key-guessing attack (maybe using the idle CPU cycles of infected hosts) could be at least as effective as Code Red was 😱 If you assume such a worm were engineered to be maximally stealthy, 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 💀

In 1997, John Gilmore and the Electronic Frontier Foundation [EFF98] built a special-purpose machine for an investment of approximately USD$250,000 🛠️ It could 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 a similar hardware approach could be used for key-guessing attacks against MD5, for key lengths similar to DES's, 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 suggests that keys used with this option may have lifetimes on the order of months 🗓️ So it seems prudent to choose a minimum key length that guarantees key-guessing runtimes are some small multiple of the key-change interval. That's under best-case (for the attacker) practical attack performance assumptions 🧠

The keys used with RFC 2385 are only meant to provide authentication, not confidentiality. Because of that, the ability of an attacker to determine the key used for old traffic (traffic sent before a key-change event) is not considered a threat 🌷

7. References ✨

okay bestie, here's the reference list, copied exactly so nothing gets lost 📚

   [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.

   [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 🎀

the author's contact info, exactly as written 💌

   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

9. Full Copyright Statement ⚖️

this is the legal part, so I've kept the wording exactly as it is. no edits, no vibes, just the facts 🫶

   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 🌸

last one, and it's short and sweet 🥰

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

that's the whole RFC, bestie! 🌈✨