RFC 2085

RFC 2085 🎀 HMAC-MD5 IP Authentication with Replay Prevention

okay bestie, so this is RFC 2085 💅 It's a Standards Track doc from February 1997, written by M. Oehler (NSA) and R. Glenn (NIST). It doesn't obsolete anything, and it doesn't update anything either (there are no Obsoletes or Updates lines in the header) 🌸

Status of This Memo ✨

so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Abstract 🦋

this doc describes a keyed-MD5 transform that you use together with the IP Authentication Header [RFC-1826] ✨ The transform is based on [HMAC-MD5]. It also has an option that guards against replay attacks 🛡️

Table of Contents 🌸

   1.  Introduction...................................................1
   1.1    Terminology.................................................2
   1.2    Keys........................................................2
   1.3    Data Size...................................................3
   2.  Packet Format..................................................3
   2.1    Replay Prevention...........................................4
   2.2    Authentication Data Calculation.............................4
   3.  Security Considerations........................................5
   Acknowledgments....................................................5
   References.........................................................6
   Authors' Addresses.................................................6

---

1. Introduction ✨

okay so the Authentication Header (AH) [RFC-1826] gives you integrity and authentication for IP datagrams 🔐 The transform in this doc uses a keyed-MD5 mechanism [HMAC-MD5]. That mechanism uses the (key-less) MD5 hash function [RFC-1321], which spits out a message digest. When you combine that with an AH Key, you get authentication data. This value goes in the Authentication Data field of the AH [RFC-1826], and it's also the basis for the data integrity service the AH protocol offers 💖

to protect against replay attacks, there's a Replay Prevention field that you can include as a transform option 🔁 It helps stop the kind of attack where someone stores a message and reuses it later, replacing or repeating the original 👀 The Security Parameters Index (SPI) [RFC-1825] is what tells you whether this option is included in the AH 🧚

you should already be familiar with these docs: "Security Architecture for the Internet Protocol" [RFC-1825], "IP Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for Message Authentication" [HMAC-MD5] 📚

every implementation that claims conformance or compliance with the IP Authentication Header specification [RFC-1826] MUST implement this HMAC-MD5 transform. 👑

1.1 Terminology 🍓

in this doc, the words that define how significant each requirement is are usually capitalized. Here they are:

• MUST

this word, or the adjective "REQUIRED", means the item is an absolute requirement of the spec 🔥

• SHOULD

this word, or the adjective "RECOMMENDED", means there might be valid reasons in particular circumstances to ignore the item. But you should understand the full implications and carefully weigh the case before you go a different way 🤔

1.2 Keys 🗝️

the "AH Key" is a shared secret between two communicating parties 🫶 It's not a "cryptographic key" in the traditional sense. Instead, the AH key (shared secret) gets hashed with the transmitted data, so an intervening party can't duplicate the authentication data 🙈

even though an AH key isn't a cryptographic key, the basic concerns about cryptographic keys still apply 💅 Assume the algorithm and most of the data used to make the output are known. The strength of the transform comes from the one-of-a-kind mapping of the key (which needs to be strong) and the IP datagram (which is known) to the authentication data ✨ So implementations should, and as frequently as possible, change the AH key. Keys need to be chosen at random, or generated using a cryptographically strong pseudo-random generator seeded with a random seed. [HMAC-MD5] 🎲

All conforming and compliant implementations MUST support a key length of 128 bits or less. Implementations SHOULD support longer key lengths as well 💖 It's advised that the key length be the length of the hash output, which is 128 bits for MD5. For other key lengths, the following concerns MUST be considered 📏

a key length of zero is prohibited, and implementations MUST prevent key lengths of zero from being used with this transform. No effective authentication could be provided by a zero-length key 🙅‍♀️ Keys shorter than 128 bits are strongly discouraged, because they'd lower the security strength of the function 😬 Keys longer than 128 bits are acceptable, but the extra length may not significantly increase the function strength. A longer key may be advisable if the randomness of the key is suspect 🤨 MD5 operates on 64-byte blocks. Keys longer than 64-bytes get hashed with MD5 first, and then that resulting hash is used to calculate the authentication data 🧮

1.3 Data Size 📏

MD5 produces a 128-bit value, and that's what's used as the authentication data. It's naturally 64 bit aligned, so it doesn't need any padding on machines with native double words 🥰

2. Packet Format 📦

     +---------------+---------------+---------------+---------------+
     | Next Header   | Length        |           RESERVED            |
     +---------------+---------------+---------------+---------------+
     |                              SPI                              |
     +---------------+---------------+---------------+---------------+
     |                     Replay Prevention                         |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     +                     Authentication Data                       |
     |                                                               |
     +---------------+---------------+---------------+---------------+
      1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

the Next Header, RESERVED, and SPI fields are specified in [RFC-1826] 🧸 The Length field is the length of the Replay Prevention field and the Authentication Data, counted in 32-bit words 🍬

2.1 Replay Prevention 🔁

the Replay Prevention field is a 64-bit value that guarantees each packet exchanged between two parties is different 💫 Each IPsec Security Association says whether Replay Prevention is used for that Security Association. If Replay Prevention is NOT in use, the Authentication Data field goes right after the SPI field 🙌

the 64-bit field is an up counter that starts at a value of 1 🔢

the secret shared key must not be used for a period of time that lets the counter wrap. That means you can't transmit more than 2^64 packets using a single key 🚫

upon receipt, the replay value is assured to be increasing. The implementation may accept out of order packets, and how many it accepts out of order is an implementation detail 🤷‍♀️ If an "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. In other words, the implementation will accept any packet at most once 🎯

when the destination address is a multicast address, replay protection is in use, and more than one sender shares the same IPsec Security Association to that multicast destination address, then Replay Protection SHOULD NOT be enabled. If you want replay protection for a multicast session with multiple senders to the same multicast destination address, each sender SHOULD have its own IPsec Security Association 🌈

[ESP-DES-MD5] has example code that implements a 32 packet replay window, plus a test routine so you can see how it works 🧪

2.2 Authentication Data Calculation 🧮

the authentication data is the output of the authentication algorithm (MD5) 💜 It's calculated over the entire IP datagram. Fields in the datagram that vary in transit, and the authentication data field itself, must contain all zeros before the computation [RFC-1826]. The Replay Prevention field, if present, is included in the calculation 🌸

the definition and reference implementation of MD5 is in [RFC-1321]. Let 'text' be the data you're applying HMAC-MD5 to, and let K be the message authentication secret key the parties share 🤝 If K is longer than 64-bytes, it MUST first be hashed using MD5. In that case, K is the resulting hash ✨

we define two fixed and different strings, ipad and opad (the 'i' and 'o' are short for inner and outer) 🦋

ipad = the byte 0x36 repeated 64 times
opad = the byte 0x5C repeated 64 times.

to compute HMAC-MD5 over the data `text' we perform:

MD5(K XOR opad, MD5(K XOR ipad, text))

namely, the steps are:

(1) append zeros to the end of K to create a 64 byte string
    (e.g., if K is of length 16 bytes it will be appended with 48
    zero bytes 0x00)
(2) XOR (bitwise exclusive-OR) the 64 byte string computed in step
    (1) with ipad
(3) append the data stream 'text' to the 64 byte string resulting
    from step (2)
(4) apply MD5 to the stream generated in step (3)
(5) XOR (bitwise exclusive-OR) the 64 byte string computed in
    step (1) with opad
(6) append the MD5 result from step (4) to the 64 byte string
    resulting from step (5)
(7) apply MD5 to the stream generated in step (6) and output
    the result

this whole computation gets a deeper dive, with example code and performance improvements, in [HMAC-MD5] 💅 Implementers should check out [HMAC-MD5] for more on this technique for keying a cryptographic hash function 🧠

3. Security Considerations 🚨

this part is serious, bestie 😭 The security this transform gives you depends on several things: the strength of MD5, whether the algorithm is implemented correctly, how secure the key management mechanism and its implementation are, how strong the associated secret key is, and whether all of the participating systems are implemented correctly 🔐 If you want the full rundown on the strengths and weaknesses of MD5, [HMAC-MD5] has a detailed discussion 📖

Acknowledgments 🙏

this document is largely based on text written by Hugo Krawczyk. The format comes from work by William Simpson and Perry Metzger, and the text on replay prevention is derived directly from work by Jim Hughes 🫶🌈

References ✨

Okay bestie, here's the reading list 📚🎀 Every source the spec leans on is right here, exactly as written:

   [RFC-1825]    Atkinson, R., "Security Architecture for the Internet
                 Protocol", RFC 1852, Naval Research Laboratory,
                 July 1995.
   [RFC-1826]    Atkinson, R., "IP Authentication Header",
                 RFC 1826, August 1995.
   [RFC-1828]    Metzger, P., and W. Simpson, "IP Authentication using
                 Keyed MD5", RFC 1828, August 1995.
   [RFC-1321]    Rivest, R., "The MD5 Message-Digest Algorithm",
                 RFC 1321, April 1992.
   [HMAC-MD5]    Krawczyk, H., Bellare, M., and R. Canetti,
                 "HMAC: Keyed-Hashing for Message Authentication",
                 RFC 2104, February 1997.
   [ESP-DES-MD5] Hughes, J., "Combined DES-CBC, MD5, and Replay
                 Prevention Security Transform", Work in Progress.

---

Authors' Addresses 💌

And here's who wrote it, the people behind the words 🫶🌸

   Michael J. Oehler
   National Security Agency
   Atn: R23, INFOSEC Research and Development
   9800 Savage Road
   Fort Meade, MD 20755

   EMail: mjo@tycho.ncsc.mil


   Robert Glenn
   NIST
   Building 820, Room 455
   Gaithersburg, MD 20899

   EMail: rob.glenn@nist.gov

That's the whole doc, babe! 💖 The authors are giving main character energy and honestly it's iconic 👑