RFC 2403

RFC 2403: The Use of HMAC-MD5-96 within ESP and AH 💖 (Part 1 of 2)

Authors: C. Madson (Cisco Systems Inc.) and R. Glenn (NIST) 🎀 Category: Standards Track 🦋 Date: November 1998 🌸 Obsoletes / Updates: this title block doesn't list anything it obsoletes or updates 🧚

---

Status of This Memo ✨

okay so this one's an Internet standards track protocol for the Internet community, and it's basically asking for discussion and suggestions for improvements 💅 for the current standardization state and status of this protocol, check the latest edition of "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share it with your whole group chat 🫶

Copyright Notice ✨

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

Abstract ✨

this memo is all about using the HMAC algorithm [RFC-2104] with the MD5 algorithm [RFC-1321] as an authentication mechanism. it's for the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. the vibe is HMAC with MD5 gives you data origin authentication and integrity protection, so nobody's messing with your data 🔥

the other stuff you need to build ESP and AH is covered by [Thayer97a], so go check that one too 🧚

1. Introduction ✨

this memo specifies MD5 [RFC-1321] combined with HMAC [RFC-2104] as a keyed authentication mechanism for the Encapsulating Security Payload and the Authentication Header. the whole goal of HMAC-MD5-96 is to make sure the packet is authentic and can't be modified in transit 🔐

okay so HMAC is a secret key authentication algorithm 💅 its data integrity and data origin authentication depend on how far the secret key gets distributed. if only the source and destination know the HMAC key, you get data origin authentication and data integrity for packets going between those two parties. if the HMAC checks out, that proves it must have been added by the source 🫶

in this memo, HMAC-MD5-96 is used inside ESP and AH. for how all the ESP pieces fit together to give you security services (including the confidentiality mechanism), check [ESP] and [Thayer97a]. for AH, check [AH] and [Thayer97a] 💖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. ✨

2. Algorithm and Mode 🌈

[RFC-1321] describes the underlying MD5 algorithm, and [RFC-2104] describes HMAC. HMAC gives you a framework for plugging in different hash algorithms, like MD5 🧚

HMAC-MD5-96 works on 64-byte blocks of data. the padding requirements are in [RFC-1321] and they're part of the MD5 algorithm itself. if MD5 is built according to [RFC-1321], you don't need any extra padding as far as HMAC-MD5-96 is concerned 🎀 about "implicit packet padding" as defined in [AH]: no implicit packet padding is required, so no stress 🙈

HMAC-MD5-96 gives you a 128-bit authenticator value. this 128-bit value can be truncated as described in RFC 2104. for use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. when you're sending, the truncated value gets stored in the authenticator field. when you're receiving, the entire 128-bit value gets computed, and then the first 96 bits are compared to the value stored in the authenticator field. no other authenticator value lengths are supported by HMAC-MD5-96, so don't even try 💀

the 96-bit length was picked because it's the default authenticator length in [AH] and it meets the security requirements described in [RFC-2104]. iconic choice honestly 👑

2.1. Performance 🍓

[Bellare96a] says that "(HMAC) performance is essentially that of the underlying hash function". [RFC-1810] has some performance analysis and recommendations for using MD5 with Internet protocols. as of this writing, no performance analysis has been done on HMAC or on HMAC combined with MD5, so that's still a mystery 🔍

[RFC-2104] outlines an implementation modification that can improve per-packet performance without affecting interoperability. ngl that's a whole glow-up with no downside ✨

3. Keying Material 🔑

HMAC-MD5-96 is a secret key algorithm. [RFC-2104] doesn't specify a fixed key length, but for use with either ESP or AH, a fixed key length of 128-bits MUST be supported. key lengths other than 128-bits MUST NOT be supported, which means only 128-bit keys are to be used by HMAC-MD5-96. 128 bits was chosen based on the recommendations in [RFC-2104]: keys shorter than the authenticator length weaken the security strength, and keys longer than the authenticator length don't meaningfully boost it 💅

[RFC-2104] talks about requirements for key material, including strong randomness. a strong pseudo-random function MUST be used to generate the required 128-bit key 🎲

as of this writing, there are no specified weak keys for HMAC. that does not mean weak keys don't exist 👀 if a set of weak keys for HMAC gets identified later, the use of those weak keys must be rejected, followed by a request for replacement keys or a newly negotiated Security Association 🚫

Warning, bestie: weak keys might show up later. when they do, reject them and ask for replacements or negotiate a new Security Association. no exceptions 🙅‍♀️

[ARCH] describes the general mechanism for getting keying material when a single SA needs multiple keys (for example, when an ESP SA needs one key for confidentiality and another for authentication) 🧩

to give you data origin authentication, the key distribution mechanism has to make sure that unique keys get allocated and that they're only distributed to the parties in the communication. main character energy for key security 👑

[RFC-2104] makes the following recommendation about rekeying. current attacks don't point to a specific recommended frequency for key changes, since these attacks are practically infeasible. still, periodic key refreshment is a fundamental security practice. it helps against potential weaknesses of the function and keys, it reduces the information available to a cryptanalyst, and it limits the damage from an exposed key 🌸

9. Full Copyright Statement ✨

Okay bestie, time for the legal bit 📜 Copyright (C) The Internet Society (1998). All Rights Reserved. 💅

You're allowed to copy this document and share it with others 🦋 You can also make derivative works that comment on or explain it, or help people implement it. Those can be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind. The one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works 🎀

BUT the document itself may not be modified in any way 🙅‍♀️ Like, you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are: when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English 🌈

Translations are the exception, so it's not a free-for-all. Modifying the document itself is a no-go unless one of those two exceptions applies.

The permissions above are perpetual 💜 They will not be revoked by the Internet Society or its successors or assigns. Forever and ever, no take-backs 🧚

Now the disclaimer, which is serious but still iconic 💀 This document and the information in it is provided on an "AS IS" basis. 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. Not me going "no warranties at all" 😭🫶