RFC 2857

The Use of HMAC-RIPEMD-160-96 within ESP and AH

📅 published June 2000, from ietf

RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH 🎀

okay bestie, this is RFC 2857 💖 It's titled "The Use of HMAC-RIPEMD-160-96 within ESP and AH," written by A. Keromytis (University of Pennsylvania) and N. Provos (Center for Information Technology Integration) 🦋 It's a Standards Track doc, dated June 2000. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

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

Abstract 🌸

So this memo explains how to use HMAC (the [RFC 2104] algorithm) together with RIPEMD-160 ([RIPEMD-160]) as an authentication mechanism inside the revised IPSEC Encapsulating Security Payload ([ESP]) and the revised IPSEC Authentication Header ([AH]). HMAC with RIPEMD-160 gives you data origin authentication and integrity protection 🔥

For the other stuff you need to make ESP and AH actually work, check out [Thayer97a] 🧚

1. Introduction 🦋

Okay, so this memo is all about RIPEMD-160 ([RIPEMD-160]) mixed with HMAC ([RFC 2104]) as a keyed authentication mechanism inside the Encapsulating Security Payload and the Authentication Header. The whole point of HMAC-RIPEMD-160-96 is making sure a packet is authentic and can't get modified in transit 🛡️✨

HMAC is a secret key authentication algorithm, and the data integrity and data origin authentication it gives you 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 going between those two parties. Basically, if the HMAC checks out, it proves the source must have added it 👑

HMAC-RIPEMD-160-96 is used inside ESP and AH here. For more on how the bits of ESP fit together (confidentiality included) to give you security services, look at [ESP] and [Thayer97a]. For more on AH, look at [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 🍓

[RIPEMD-160] describes the RIPEMD-160 algorithm underneath everything, and [RFC 2104] describes HMAC. HMAC gives you a framework where you can plug in different hashing algorithms, like RIPEMD-160 ✨

HMAC-RIPEMD-160-96 works on 64-byte blocks of data. The padding rules are in [RIPEMD-160] and they're part of the RIPEMD-160 algorithm. Padding bits are only needed when computing the HMAC-RIPEMD-160 authenticator value, and they MUST NOT be included in the packet 🙈

HMAC-RIPEMD-160-96 produces a 160-bit authenticator value. You can truncate that value like [RFC2104] describes. For ESP or AH, a truncated value using the first 96 bits MUST be supported. When you send, the truncated value goes into the authenticator field. When you receive, you compute the entire 160-bit value and compare the first 96 bits against what's stored in the authenticator field. No other authenticator value lengths are supported by HMAC-RIPEMD-160-96 💅

The 96-bit length was picked because it's the default authenticator length in [AH] and it meets the security requirements in [RFC 2104] 🌈

2.1. Performance 🧁

[Bellare96a] says that "(HMAC) performance is essentially that of the underlying hash function". [RIPEMD-160] has some performance analysis too. As of writing, nobody has done a detailed performance analysis of HMAC or HMAC combined with RIPEMD-160 yet 🤷‍♀️

[RFC 2104] outlines an implementation modification that can improve per-packet performance without affecting interoperability ⚡

3. Keying Material 🔑

HMAC-RIPEMD-160-96 is a secret key algorithm. [RFC 2104] doesn't specify a fixed key length, but for ESP or AH a fixed key length of 160-bits MUST be supported. Key lengths other than 160-bits SHALL NOT be supported. The 160-bit key length was chosen based on the recommendations in [RFC 2104] (basically, keys shorter than the authenticator length weaken security strength, and keys longer than the authenticator length don't meaningfully add to it) 💖

[RFC 2104] talks about key material requirements, including strong randomness. A strong pseudo-random function MUST be used to generate the required 160-bit key. Implementors should look at RFC 1750 for guidance on what those functions need to do 🧚

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

[ESP] describes the general mechanism for getting keying material for the ESP transform. Deriving the key from some amount of keying material doesn't change between manual and automatic key management mechanisms 🫶

To provide data origin authentication, the key distribution mechanism has to make sure unique keys get allocated and that they're only distributed to the parties in the communication 🔐

[RFC 2104] says that for "minimally reasonable hash functions" the "birthday attack" is impractical. For a 64-byte block hash like HMAC-RIPEMD-160-96, an attack that successfully processes 264 blocks would be infeasible, unless someone discovered the underlying hash had collisions after processing 230 blocks. (A hash with weak collision-resistance like that would generally be considered unusable.) No time-based attacks are discussed in the document 🙃

It is still cryptographically prudent to rekey often, but current literature doesn't include any recommended key lifetimes for HMAC-RIPEMD. When recommendations for HMAC-RIPEMD key lifetimes show up, they'll be included in a revised version of this document 📅

4. Interaction with the ESP Cipher Mechanism 🧩

As of writing, there are no known issues that rule out using HMAC-RIPEMD-160-96 with any specific cipher algorithm ✨

5. Security Considerations 🚨

Okay, this part is serious, bestie 😭 The security from HMAC-RIPEMD-160-96 depends on the strength of HMAC and, to a lesser degree, the strength of RIPEMD-160. As of writing, there are no known practical cryptographic attacks against RIPEMD-160 💀

Also, RIPEMD-160 was never designed to be used as a keyed hash algorithm, but HMAC had that requirement from the very beginning 👑

[RFC 2104] also discusses the extra security you can get from truncating the resulting hash. Specifications that include HMAC are strongly encouraged to do this hash truncation 🎀

Since [RFC 2104] gives you a framework for plugging in different hash algorithms with HMAC, it's possible to swap RIPEMD-160 out for other algorithms like SHA-1. [RFC 2104] has a detailed discussion of the strengths and weaknesses of HMAC algorithms 🧐

Like any cryptographic algorithm, its strength depends on how correctly the algorithm is implemented, how secure the key management mechanism and its implementation are, how strong the secret key is, and whether the implementation is correct in every participating system. [Kapp97] contains test vectors and example code to help you verify that your HMAC-RIPEMD-160-96 code is correct 🔥

6. Acknowledgements 🌷

This document is derived from work by C. Madson and R. Glenn, and from earlier work by Jim Hughes, the people who worked with Jim on the combined DES/CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the members of the IPsec working group 🫶

7. References 📚

[RIPEMD-160]  3.ISO/IEC 10118-3:1998, "Information technology -
              Security techniques - Hash-functions - Part 3:
              Dedicated hash-functions," International Organization
              for Standardization, Geneva, Switzerland, 1998.

[RFC 2104]    Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
              Keyed-Hashing for Message Authentication", RFC 2104,
              September, 1997.

[Bellare96a]  Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash
              Functions for Message Authentication", Advances in
              Cryptography, Crypto96 Proceeding, June 1996.

[ESP]         Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

[AH]          Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

[Thayer97a]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
              Document Roadmap", RFC 2411, November 1998.

[Kapp97]      Kapp, J., "Test Cases for HMAC-RIPEMD160 and HMAC-
              RIPEMD128", RFC 2286, March 1998.

[RFC 1750]    Eastlake 3rd, D., Crocker, S. and J. Schiller,
              "Randomness Recommendations for Security", RFC 1750,
              December 1994.

[RFC 2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8. Authors' Addresses 🏠

   Angelos D. Keromytis
   Distributed Systems Lab
   Computer and Information Science Department
   University of Pennsylvania
   200 S. 33rd Street
   Philadelphia, PA 19104 - 6389

   EMail: angelos@dsl.cis.upenn.edu


   Niels Provos
   Center for Information Technology Integration
   University of Michigan
   519 W. William
   Ann Arbor, Michigan 48103 USA

   EMail: provos@citi.umich.edu

   The IPsec working group can be contacted through the chairs:

   Robert Moskowitz
   International Computer Security Association

   EMail: rgm@icsa.net


   Ted T'so
   VA Linux Systems

   EMail: tytso@valinux.com

okay bestie, this section is the legal bit, so I'm keeping every word the same 💅 Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸

the gist: you can copy this document and share it with people, and you can write derivative works that comment on it or explain it or help people implement it, and you can publish those too, in whole or in part, no restrictions of any kind 🦋 BUT the copyright notice and this paragraph have to stay on every copy and every derivative work. ngl that's giving "credit where it's due" energy 🫶

the one hard no: this 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 you need it for developing Internet standards (then the Internet Standards process copyright procedures MUST be followed) or when you're translating it into languages other than English. so you can translate it, just don't mess with the original text 💖

the permissions are perpetual, and the Internet Society and its successors or assigns will not revoke them ✨ forever and ever, bestie 👑

and the disclaimer, which is very serious and very capital-letters: this document and the information in it are provided "AS IS" 😭 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. no promises, no cap, it's on you to check it works for you 🙈

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society 💜 shoutout to them for keeping the lights on, slay 🧚

📦 where this page comes from