RFC 1852

RFC 1852: IP Authentication using Keyed SHA 🎀

okay bestie, this one is an Experimental 🧪 doc, so it's not an Internet standard, just a "hey, try this and tell us what you think" situation. It's from September 1995 📅, part of the Network Working Group, and it's Request for Comments: 1852. The authors are P. Metzger (Piermont) and W. Simpson (Daydreamer) 👩‍💻. The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Status of this Memo ✨

This document defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. Discussion and suggestions for improvement are requested, and distribution of this memo is unlimited 🦋

Abstract 🌸

This doc is all about using keyed SHA with the IP Authentication Header. It's giving "combine these two things and make them work together" 🫶

Table of Contents 📜

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

     2.     Calculation ...........................................    3

     SECURITY CONSIDERATIONS ......................................    4
     ACKNOWLEDGEMENTS .............................................    4
     REFERENCES ...................................................    5
     AUTHOR'S ADDRESS .............................................    6

1. Introduction ✨

okay so the Authentication Header (AH) [RFC-1826] gives you integrity and authentication for IP datagrams 🔐. This spec explains how AH uses keys together with the Secure Hash Algorithm (SHA) [FIPS-180-1] 💖

Worth flagging: this doc uses a newer version of SHA than the one in [FIPS-180], because that older version was flawed 💀. The two versions are not interoperable with each other, so don't mix them up 🙈

This doc assumes you already know "Security Architecture for the Internet Protocol" [RFC-1825]. That one lays out the big-picture 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 🔑

The shared key isn't limited to any particular size by this transform 🙌 Lengths of up to 160 bits MUST be supported by the implementation, though any particular key can be shorter. Longer keys are encouraged 💜

1.2. Data Size 📏

SHA's 160-bit output is naturally 32-bit aligned ✨ However, plenty of implementations need the following headers to be 64-bit aligned. When that happens, an extra 32 bits of padding gets added, either before or after the SHA output 🧚

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

1.3. Performance 🏎️

Preliminary results say SHA is 62% as fast as MD5, and 80% as fast as DES hashing. So the ranking goes:

SHA < DES < MD5

Nota Bene: the authors are asking for suggestions on other authentication algorithms that are significantly faster, aren't patent-encumbered, and still have solid cryptographic strength 💅

2. Calculation 🧮

The 160-bit digest gets calculated as described in [FIPS-180-1]. At the time of writing, there's a portable C implementation of SHA you can grab by FTP from ftp://rand.org/pub/jim/sha.tar.gz 🍓

The form of the authenticated message is:

key, keyfill, datagram, key, SHAfill

First, the variable-length secret authentication key gets filled out to the next 512-bit boundary, using the same pad-with-length technique defined for SHA 🎀

Then the filled key gets concatenated with (immediately followed by) the invariant fields of the entire IP datagram. The variant fields get zeroed out. After that, the original variable-length key gets stuck on the end again 🌈

SHA itself adds a trailing pad, with length, out to the next 512-bit boundary for the entire message 🫶 Then the 160-bit SHA digest gets calculated, and the result is inserted into the Authentication Data field ✨

Discussion:

The leading copy of the key is padded so it's easy to copy the key at machine boundaries without having to realign the datagram that follows 🧸 The padding technique includes a length, which protects keys of any length 💖 Filling out to the SHA block size also lets the key get prehashed, which skips the physical copy in some implementations 🔥

The trailing copy of the key isn't needed to protect against appending attacks, since the IP datagram already has a total length field 🙅‍♀️ What it does do is bring back mixing of the entire key. That gives minimal protection for very long and very short datagrams, plus a bit of extra robustness 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, be careful that the keys and/or padding don't get sent over the link by the link driver 🚨

Security Considerations 🔐

Okay, this section is serious, so listen up 👑 How good the security is under this spec depends completely on a bunch of things: how strong the SHA 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 implemented everything correctly 😭

SHA was originally derived from the MD4 algorithm [RFC-1320]. A flaw was apparently found in the original SHA spec [FIPS-180], so this document uses a corrected version instead [FIPS-180-1] 💀

As of when this was written, there are no known flaws in SHA. No known attacks on SHA or any of its components do better than brute force. The 160-bit hash output from SHA is also a lot more resistant to brute force attacks than the 128-bit hash size of MD4 and MD5 💪

But here's the tea: as the flaw in the original SHA algorithm proves, cryptographers are fallible 🙈 There may still be substantial deficiencies in the algorithm that nobody has found yet 😱

Acknowledgements 🫶

Some of the text in this spec was derived from work by Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups 🙌

Preliminary performance analysis was provided by Joe Touch 📊

Comments should be sent to the ipsec@ans.net mailing list 💌

References 📚

• [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994.
• [FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, National Institute of Standards and Technology, U.S. Department Of Commerce, May 1993. Also known as: 58 Fed Reg 27712 (1993).
• [FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995. Also known as: 59 Fed Reg 35317 (1994).
• [RFC-1320] Ronald Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 1992.
• [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
• [RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC-1825, Naval Research Laboratory, July 1995.
• [RFC-1826] Atkinson, R., "IP Authentication Header", RFC-1826, Naval Research Laboratory, July 1995.

Author's Address 💌

If you have questions about this memo, you can reach out to these two legends 🧚‍♀️

   Questions about this memo can also be directed 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 tea, bestie 🌈💖 IP authentication with keyed SHA, all the details in place. Periodt 💅✨