RFC 1828

IP Authentication using Keyed MD5 🎀

okay bestie, this is RFC 1828 and it's giving tight security spec energy 💅✨

Network Working Group: P. Metzger (Piermont) and W. Simpson (Daydreamer) 👯‍♀️ Category: Standards Track 🦋 Date: August 1995 🌸 Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙈

---

Status of This Memo 📜

ok so this is an Internet standards track protocol 💜 It's a real spec for the Internet community, and they're literally asking everyone for discussion and suggestions for improvements 🫶 For where it sits in the standardization state, you check the current edition of "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share it with everyone 🌈

Abstract ✨

so basically this doc explains how to use keyed MD5 with the IP Authentication Header 🔐

Table of Contents 🧚

  1.     Introduction ..........................................    1
     1.1       Keys ............................................    1
     1.2       Data Size .......................................    1
     1.3       Performance .....................................    1

  2.     Calculation ...........................................    2

  SECURITY CONSIDERATIONS ......................................    2
  ACKNOWLEDGEMENTS .............................................    3
  REFERENCES ...................................................    3
  AUTHOR'S ADDRESS .............................................    4

1. Introduction 🌸

okay the Authentication Header (AH) [RFC-1826] is the thing that gives IP datagrams integrity and authentication 🔐 This spec is about how AH uses keys with Message Digest 5 (MD5) [RFC-1321] 💖

hard rule here: every implementation that claims to be conformant or compliant with the Authentication Header spec MUST implement this keyed MD5 mechanism 🫶 no skipping!

also you should read the related doc "Security Architecture for the Internet Protocol" [RFC-1825] first. it's the big-picture security plan for IP and it's basically the background for everything here 🧚

1.1. Keys 🗝️

the secret authentication key that the two parties share SHOULD be a cryptographically strong random number, never a guessable string of any sort 🙅‍♀️ bestie, that's the whole vibe 💀

the transform doesn't put any particular size limit on the key 💅 Lengths up to 128 bits MUST be supported by the implementation, though any single key is allowed to be shorter. longer keys are encouraged 🌈✨

1.2. Data Size 🍓

MD5's 128-bit output is naturally 64-bit aligned, so it lines up nicely 🎀 Usually there's no extra padding needed for the Authentication Data field 💜

1.3. Performance 🦋

MD5 is fast enough for the LAN and WAN links people commonly use, but it's reportedly too slow for newer link technologies [RFC-1810] 😭

Nota Bene: Suggestions are sought on alternative authentication algorithms that have significantly faster throughput, are not patent-encumbered, and still retain adequate cryptographic strength. 🔥

2. Calculation 🧮

the 128-bit digest gets calculated the way [RFC-1321] describes it 💖 MD5's spec even comes with a portable 'C' description of the algorithm, so you're covered 👑

the authenticated message looks like this:

key, keyfill, datagram, key, MD5fill

step one: take the variable-length secret key and pad it out to the next 512-bit boundary, using the same pad-with-length trick MD5 already defines 🧚

step two: glue that filled key onto the invariant fields of the whole IP datagram (variant fields get zeroed out), then glue the original variable-length key on the end again 🫶

step three: MD5 adds its own trailing pad with length out to the next 512-bit boundary for the whole message 💅 then you compute the 128-bit MD5 digest and stick the result into the Authentication Data field 🎀 done and dusted ✨

Discussion: when the implementation puts the keys and padding in place before and after the IP datagram, be careful that the link driver doesn't send the keys and/or padding over the link 😭🚨 this is a big deal, bestie!

Security Considerations 🔐

okay this section is SERIOUS 💀 Users have to understand that how secure this is depends completely on how strong the MD5 hash function is, whether that algorithm is implemented correctly, how secure the key management mechanism and its implementation are, how strong the key is [CN94], and whether every participating node has correct implementations 🙈

as of when this was written, it's known to be possible to produce collisions in the compression function of MD5 [dBB93] 😱 nobody has found a way to use those collisions to attack MD5 in practice yet, but some authors find this disturbing [Schneier94] 🥺

it has also recently been worked out [vOW94] that you could build a machine for $10 Million that finds two chosen text variants with a common MD5 hash value 🤯 it's unclear whether that attack applies to keyed MD5 though 🤷‍♀️

this attack takes about 24 days 🗓️ the same kind of attack works on any iterated n-bit hash function, and the time comes down entirely to MD5's 128-bit length 🧠

even though there's no big weakness for most IP security applications, keep in mind that current technology is catching up to the 128-bit hash length MD5 uses 🏃‍♀️💨 apps that need extremely high security might want to move in the near future to algorithms with longer hash lengths 👑

Acknowledgements 🫶

this doc was reviewed by the IP Security Working Group of the Internet Engineering Task Force (IETF) 💜 comments go to the ipsec@ans.net mailing list 📬

some of the text came from work by Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups 🌸

the basic concept and use of MD5 comes mostly from the work done for SNMPv2 [RFC-1446] 🧚

Steve Bellovin, Phil Karn, Charles Lynn, Dave Mihelcic, Hilarie Orman, Jeffrey Schiller, Joe Touch, and David Wagner gave super useful critiques of earlier drafts 👑🫶

References 📚

• [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994.
• [dBB93] den Boer, B., and Bosselaers, A., "Collisions for the Compression function of MD5", Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994
• [KR95] Kaliski, B., and Robshaw, M., "Message authentication with MD5", CryptoBytes (RSA Labs Technical Newsletter), vol.1 no.1, Spring 1995.
• [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT and RSA Data Security, Inc., April 1992.
• [RFC-1446] Galvin, J., and K. McCloghrie, "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, TIS, Hughes LAN Systems, April 1993.
• [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
• [RFC-1800] Postel, J., "Internet Official Protocol Standards", STD 1, RFC 1800, USC/Information Sciences Institute, July 1995.
• [RFC-1810] Touch, J., "Report on MD5 Performance", RFC 1810, USC/Information Sciences Institute, June 1995.
• [RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995.
• [RFC-1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL August 1995.
• [Schneier94] Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2
• [vOW94] van Oorschot, P. C., and Wiener, M. J., "Parallel Collision Search with Applications to Hash Functions and Discrete Logarithms", Proceedings of the 2nd ACM Conf. Computer and Communications Security, Fairfax, VA, November 1994.

Author's Address 💌

questions about this memo can also go to:

Perry Metzger
Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2
New York, NY  10033

perry@piermont.com


William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan  48071

Bill.Simpson@um.cc.umich.edu
    bsimpson@MorningStar.com

---

that's the whole thing, bestie! 🌈💖🦋 keyed MD5 for AH, the key rules, the calculation steps, and the security warnings, all in one place 👑✨