From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2857.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2857.txt (limited to 'doc/rfc/rfc2857.txt') diff --git a/doc/rfc/rfc2857.txt b/doc/rfc/rfc2857.txt new file mode 100644 index 0000000..37a69d3 --- /dev/null +++ b/doc/rfc/rfc2857.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group A. Keromytis +Request for Comments: 2857 University of Pennsylvania +Category: Standards Track N. Provos + Center for Information Technology Integration + June 2000 + + + The Use of HMAC-RIPEMD-160-96 within ESP and AH + +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 Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This memo describes the use of the HMAC algorithm [RFC 2104] in + conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an + authentication mechanism within the revised IPSEC Encapsulating + Security Payload [ESP] and the revised IPSEC Authentication Header + [AH]. HMAC with RIPEMD-160 provides data origin authentication and + integrity protection. + + Further information on the other components necessary for ESP and AH + implementations is provided by [Thayer97a]. + +1. Introduction + + This memo specifies the use of RIPEMD-160 [RIPEMD-160] combined with + HMAC [RFC 2104] as a keyed authentication mechanism within the + context of the Encapsulating Security Payload and the Authentication + Header. The goal of HMAC-RIPEMD-160-96 is to ensure that the packet + is authentic and cannot be modified in transit. + + HMAC is a secret key authentication algorithm. Data integrity and + data origin authentication as provided by HMAC are dependent upon the + scope of the distribution of the secret key. If only the source and + destination know the HMAC key, this provides both data origin + authentication and data integrity for packets sent between the two + parties; if the HMAC is correct, this proves that it must have been + added by the source. + + + +Keromytis & Provos Standards Track [Page 1] + +RFC 2857 HMAC-RIPEMD-160-96 within ESP and AH June 2000 + + + In this memo, HMAC-RIPEMD-160-96 is used within the context of ESP + and AH. For further information on how the various pieces of ESP - + including the confidentiality mechanism -- fit together to provide + security services, refer to [ESP] and [Thayer97a]. For further + information on AH, refer to [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 underlying RIPEMD-160 algorithm, while + [RFC 2104] describes the HMAC algorithm. The HMAC algorithm provides + a framework for inserting various hashing algorithms such as RIPEMD- + 160. + + HMAC-RIPEMD-160-96 operates on 64-byte blocks of data. Padding + requirements are specified in [RIPEMD-160] and are part of the + RIPEMD-160 algorithm. Padding bits are only necessary in computing + the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in + the packet. + + HMAC-RIPEMD-160-96 produces a 160-bit authenticator value. This + 160-bit value can be truncated as described in RFC2104. For use with + either ESP or AH, a truncated value using the first 96 bits MUST be + supported. Upon sending, the truncated value is stored within the + authenticator field. Upon receipt, the entire 160-bit value is + computed and the first 96 bits are compared to the value stored in + the authenticator field. No other authenticator value lengths are + supported by HMAC-RIPEMD-160-96. + + The length of 96 bits was selected because it is the default + authenticator length as specified in [AH] and meets the security + requirements described in [RFC 2104]. + +2.1 Performance + + [Bellare96a] states that "(HMAC) performance is essentially that of + the underlying hash function". [RIPEMD-160] provides some + performance analysis. As of this writing no detailed performance + analysis has been done of HMAC or HMAC combined with RIPEMD-160. + + [RFC 2104] outlines an implementation modification which can improve + per-packet performance without affecting interoperability. + + + + + + +Keromytis & Provos Standards Track [Page 2] + +RFC 2857 HMAC-RIPEMD-160-96 within ESP and AH June 2000 + + +3. Keying Material + + HMAC-RIPEMD-160-96 is a secret key algorithm. While no fixed key + length is specified in [RFC 2104], for use with either ESP or AH a + fixed key length of 160-bits MUST be supported. Key lengths other + than 160-bits SHALL NOT be supported. A key length of 160-bits was + chosen based on the recommendations in [RFC 2104] (i.e. key lengths + less than the authenticator length decrease security strength and + keys longer than the authenticator length do not significantly + increase security strength). + + [RFC 2104] discusses requirements for key material, which includes a + discussion on requirements for strong randomness. A strong pseudo- + random function MUST be used to generate the required 160-bit key. + Implementors should refer to RFC 1750 for guidance on the + requirements for such functions. + + At the time of this writing there are no specified weak keys for use + with HMAC. This does not mean to imply that weak keys do not exist. + If, at some point, a set of weak keys for HMAC are identified, the + use of these weak keys must be rejected followed by a request for + replacement keys or a newly negotiated Security Association. + + [ESP] describes the general mechanism to obtain keying material for + the ESP transform. The derivation of the key from some amount of + keying material does not differ between the manual and automatic key + management mechanisms. + + In order to provide data origin authentication, the key distribution + mechanism must ensure that unique keys are allocated and that they + are distributed only to the parties participating in the + communication. + + [RFC 2104] states that for "minimally reasonable hash functions" the + "birthday attack" is impractical. For a 64-byte block hash such as + HMAC-RIPEMD-160-96, an attack involving the successful processing of + 2**64 blocks would be infeasible unless it were discovered that the + underlying hash had collisions after processing 2**30 blocks. (A + hash with such weak collision-resistance characteristics would + generally be considered to be unusable.) No time-based attacks are + discussed in the document. + + While it it still cryptographically prudent to perform frequent + rekeying, current literature does not include any recommended key + lifetimes for HMAC-RIPEMD. When recommendations for HMAC-RIPEMD key + lifetimes become available they will be included in a revised version + of this document. + + + + +Keromytis & Provos Standards Track [Page 3] + +RFC 2857 HMAC-RIPEMD-160-96 within ESP and AH June 2000 + + +4. Interaction with the ESP Cipher Mechanism + + As of this writing, there are no known issues which preclude the use + of the HMAC-RIPEMD-160-96 algorithm with any specific cipher + algorithm. + +5. Security Considerations + + The security provided by HMAC-RIPEMD-160-96 is based upon the + strength of HMAC, and to a lesser degree, the strength of RIPEMD-160. + At the time of this writing there are no known practical + cryptographic attacks against RIPEMD-160. + + It is also important to consider that while RIPEMD-160 was never + developed to be used as a keyed hash algorithm, HMAC had that + criteria from the onset. + + [RFC 2104] also discusses the potential additional security which is + provided by the truncation of the resulting hash. Specifications + which include HMAC are strongly encouraged to perform this hash + truncation. + + As [RFC 2104] provides a framework for incorporating various hash + algorithms with HMAC, it is possible to replace RIPEMD-160 with other + algorithms such as SHA-1. [RFC 2104] contains a detailed discussion + on the strengths and weaknesses of HMAC algorithms. + + As is true with any cryptographic algorithm, part of its strength + lies in the correctness of the algorithm implementation, the security + of the key management mechanism and its implementation, the strength + of the associated secret key, and upon the correctness of the + implementation in all of the participating systems. [Kapp97] + contains test vectors and example code to assist in verifying the + correctness of HMAC-RIPEMD-160-96 code. + +6. Acknowledgements + + This document is derived from work by C. Madson and R. Glenn and from + previous works by Jim Hughes, those people that 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. + + + +Keromytis & Provos Standards Track [Page 4] + +RFC 2857 HMAC-RIPEMD-160-96 within ESP and AH June 2000 + + + [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 + + + + + +Keromytis & Provos Standards Track [Page 5] + +RFC 2857 HMAC-RIPEMD-160-96 within ESP and AH June 2000 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Keromytis & Provos Standards Track [Page 6] + +RFC 2857 HMAC-RIPEMD-160-96 within ESP and AH June 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein 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. + + + + + + + + + + + + + + + + + + + +Keromytis & Provos Standards Track [Page 7] + -- cgit v1.2.3