RFC 2404

RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH 💖

Okay bestie, let's start with the title block 🎀 This is an RFC from November 1998, written by Cheryl Madson of Cisco Systems Inc. and Rob Glenn of NIST. It's on the Standards Track 🔥, so it's an Internet standards track protocol. It doesn't list any obsoletes or updates, so it isn't replacing or changing any older RFCs, at least according to its 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 💅 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited 🌈

Copyright Notice ©

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

Abstract 🦋

This memo is all about using the HMAC algorithm [RFC-2104] together with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism. It works inside the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 gives you data origin authentication and integrity protection 🔐

If you want more on the other pieces you need for ESP and AH implementations, [Thayer97a] has you covered ✨

1. Introduction 🌸

Okay so this memo specifies using SHA-1 [FIPS-180-1] combined with HMAC [RFC-2104] as a keyed authentication mechanism, inside the Encapsulating Security Payload and the Authentication Header. The whole goal of HMAC-SHA-1-96 is to make sure the packet is authentic and can't be modified in transit 😤

HMAC is a secret key authentication algorithm, and that's the vibe: 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 integrity for packets sent between those two parties. And if the HMAC checks out, it proves the source must have added it 🫶

Here, HMAC-SHA-1-96 gets used inside ESP and AH. For how the different ESP pieces fit together to give security services (confidentiality mechanism included), 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]. These are the official requirement words, so pay attention to them 💀

2. Algorithm and Mode 💜

Here's the breakdown: [FIPS-180-1] describes the underlying SHA-1 algorithm, and [RFC-2104] describes the HMAC algorithm. HMAC is basically a framework where you can plug in different hashing algorithms, like SHA-1 🍓

HMAC-SHA-1-96 works on 64-byte blocks of data. The padding rules are in [FIPS-180-1] and they're part of the SHA-1 algorithm. So if you build SHA-1 according to [FIPS-180-1], you don't need to add any extra padding for HMAC-SHA-1-96. And when it comes to "implicit packet padding" as defined in [AH], no implicit packet padding is required ✨

HMAC-SHA-1-96 makes a 160-bit authenticator value, and that value can be truncated the way RFC2104 describes. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. When sending, the truncated value gets stored in the authenticator field. When receiving, the full 160-bit value gets computed, and the first 96 bits are compared to what's stored in the authenticator field. HMAC-SHA-1-96 doesn't support any other authenticator value lengths, so no drama there 🙅‍♀️

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] 💅

2.1. Performance 🏎️

[Bellare96a] says that "(HMAC) performance is essentially that of the underlying hash function". As of writing this, nobody has done a detailed performance analysis of SHA-1, HMAC, or HMAC combined with SHA-1 yet 🙈

[RFC-2104] outlines an implementation modification that can improve per-packet performance without messing up interoperability. Nice, right? 🌈

3. Keying Material 🔑

HMAC-SHA-1-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 160-bits MUST be supported. Key lengths other than 160-bits MUST NOT be supported, so HMAC-SHA-1-96 only uses 160-bit keys 👑 The 160-bit choice comes from 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 160-bit key 🎲

As of writing, there are no specified weak keys for HMAC. That does NOT mean weak keys don't exist, though 👀 If a set of weak HMAC keys gets identified later, those weak keys must be rejected, followed by a request for replacement keys or a newly negotiated Security Association.

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

To provide data origin authentication, the key distribution mechanism must make sure unique keys get allocated and that they're only distributed to the parties in the communication. No sharing with randoms 🙅‍♀️

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

---

✨ Part 1 ends here. Part 2 picks up with Section 4, Interaction with the ESP Cipher Mechanism, and keeps going from there 🎀

9. Full Copyright Statement ✨

okay bestie, the legal bit 📜💅 The copyright line is Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀

Anyone can copy this document and pass it along to others, and they can make derivative works that comment on or explain it, or help with implementing it. They can publish and distribute those in whole or in part with no restrictions of any kind 🦋, as long as 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 removing 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 copyright procedures in the Internet Standards process must be followed, or when it's translated into languages other than English 🌍.

The permissions above are perpetual 💜, and the Internet Society or its successors or assigns will not revoke them. ⭐

Last but not least, this document and the information in it are 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. 🫶

That's the whole document, periodt! 🌈✨