RFC 2841

IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) 🎀

okay bestie, this is RFC 2841 and it's giving historic classic 🧚 It's a Historic document, so it doesn't set an Internet standard, but it's still the blueprint for how IP datagrams get authenticated with keyed SHA1. It was written by P. Metzger of Piermont and W. Simpson of DayDreamer, published in November 2000, and it obsoletes RFC 1852 💅

Status of This Memo

okay so this memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒

Abstract

this one is short and sweet ✨ It describes using keyed SHA1 with the IP Authentication Header.

Table of Contents 💜

1.   Introduction ............................................. 2
1.1. Keys ..................................................... 2
1.2. Data Size ................................................ 2
1.3. Performance .............................................. 3
2.   Calculation .............................................. 3
A.   Changes .................................................. 5
Security Considerations ....................................... 6
Acknowledgements .............................................. 6
References .................................................... 7
Contacts ...................................................... 8
Editor's Note ................................................. 8
Full Copyright Statement ...................................... 9

---

1. Introduction 🦋

okay so the Authentication Header (AH) [RFC-1826] is the thing that gives IP datagrams integrity and authentication, and this spec explains how AH uses keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1] 🔐 The SHA1-IP-MAC algorithm is lowkey a variant of the "envelope method": it puts a leading key and a trailing key around the data, with alignment padding between the keys and the data. literally so clean 😭

It should be noted that this document specifies a newer version of SHA than that described in [FIPS-180], which was flawed. The older version is not interoperable with the newer version. 🙈

also, you need to be familiar with "Security Architecture for the Internet Protocol" [RFC-1825] first, bc it lays out the overall security plan for IP and gives you the background you need for this spec 📚

1.1. Keys 🗝️

the secret authentication key shared between the communicating parties SHOULD be a cryptographically strong random number, not a guessable string of any sort. no weak vibes allowed 💀

this transform doesn't put any particular size limit on the shared key. Lengths of 160-bits (20 octets) MUST be supported by the implementation, although any particular key may be shorter. Longer keys are encouraged 🔥

1.2. Data Size 📏

SHA1's 160-bit output is naturally 32-bit aligned. however, a lot of implementations need the headers that come after it to be 64-bit aligned, and that's where the drama starts 😤

so there are a few options for data alignment, ranked from most preferred to least preferred:

1. only the most significant 128-bits (16 octets) of output are used.
2. an additional 32-bits (4 octets) of padding is added before the SHA1 output.
3. an additional 32-bits (4 octets) of padding is added after the SHA1 output.
4. the SHA1 output is variably bit-positioned within 192-bits (24 octets).

the size and position of the output are negotiated as part of the key management. padding bits are filled with unspecified, implementation dependent (random) values, and they get ignored on receipt 🫶

Discussion:

although truncating the output for alignment might seem like it would weaken the algorithm, some attack verification analysts suggest it may actually make it more robust [PO95a]. plot twist 🤯

1.3. Performance 🏎️

preliminary results say SHA1 is 62% as fast as MD5, and 80% as fast as DES hashing. so basically:

                       SHA1 < DES < MD5

this still seems like a reasonable tradeoff, bc SHA1 internal chaining is way longer than either DES or MD5:

                       DES < MD5 < SHA1

Nota Bene: suggestions are sought on alternative authentication algorithms that have significantly faster throughput, are not patent-encumbered, and still keep adequate cryptographic strength. if you've got ideas, bestie, send them 💌

---

2. Calculation 🧮

the 160-bit digest is calculated as described in [FIPS-180-1]. there's a portable C language implementation of SHA1 you can grab over FTP at ftp://rand.org/pub/jim/sha.tar.gz 💻

the form of the authenticated message looks like this:

SHA1( key, keyfill, datagram, datafill, key, sha1fill )

step one: the variable length secret authentication key gets filled out to the next 512-bit boundary, using the same pad-with-length technique defined for SHA1. that padding includes a length, so it protects arbitrary length keys 🔑

step two: the filled key gets concatenated with (immediately followed by) the invariant fields of the entire IP datagram. variant fields are zeroed. then this whole thing is filled to the next 512-bit boundary, using the same pad-with-length technique defined for SHA1. the length includes the leading key and data 📦

step three: the filled data gets concatenated with (immediately followed by) the original variable length key again. a trailing pad-with-length to the next 512-bit boundary for the entire message is added by SHA1 itself ✨

step four: the 160-bit SHA1 digest is calculated, and the result is inserted into the Authentication Data field. slay 👑

Discussion:

the leading copy of the key is padded so you can copy the key at machine boundaries without having to realign the datagram that follows. filling to the SHA1 block size also means the key can be prehashed, which skips the physical copy in some implementations 🧠

the trailing copy of the key isn't needed to protect against appending attacks, bc the IP datagram already has a total length field. it does bring back mixing of the entire key, though, which protects very long and very short datagrams and makes things more robust against possible attacks on the IP length field itself 🛡️

When the implementation adds the keys and padding in place before and after the IP datagram, care must be taken that the keys and/or padding are not sent over the link by the link driver. ⚠️

Full Copyright Statement ✨

Okay bestie, the legal bit 💅 Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it can be copied and shared with others. Derivative works that comment on it, explain it, or help with implementing it can also be written, copied, published and distributed, in whole or in part, with no restrictions of any kind. The one condition is that the above copyright notice and this paragraph are included on all those copies and derivative works. BUT this document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: when it's needed for developing Internet standards (then the copyright procedures in the Internet Standards process must be followed), or when it's translated into languages other than English. 🎀

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them. 🦋

This document and the information in it 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 🫶

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