idnits 2.17.1 draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 15 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC-2104], [Thayer97a], [RIPEMD-160], [AH], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 69, but not defined == Unused Reference: 'RFC-2119' is defined on line 225, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPEMD-160' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare96a' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-01 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-02 -- No information found for draft-ietf-ipsec-doc-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Thayer97a' ** Downref: Normative reference to an Informational RFC: RFC 2286 (ref. 'Kapp97') Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Angelos D. Keromytis 2 INTERNET DRAFT Niels Provos 3 Expire in six months July 1998 5 The Use of HMAC-RIPEMD-160-96 within ESP and AH 6 8 Status of this Memo 10 This document is a submission to the IETF Internet Protocol Security 11 (IPSEC) Working Group. Comments are solicited and should be addressed 12 to the working group mailing list (ipsec@tis.com) or to the editor. 14 This document is an Internet-Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet-Drafts draft documents are valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this memo is unlimited. 32 Abstract 34 This draft describes the use of the HMAC algorithm [RFC-2104] in 35 conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an 36 authentication mechanism within the revised IPSEC Encapsulating 37 Security Payload [ESP] and the revised IPSEC Authentication Header 38 [AH]. HMAC with RIPEMD-160 provides data origin authentication and 39 integrity protection. 41 Further information on the other components necessary for ESP and AH 42 implementations is provided by [Thayer97a]. 44 1. Introduction 46 This draft specifies the use of RIPEMD-160 [RIPEMD-160] combined with 47 HMAC [RFC-2104] as a keyed authentication mechanism within the context 48 of the Encapsulating Security Payload and the Authentication Header. 49 The goal of HMAC-RIPEMD-160-96 is to ensure that the packet is 50 authentic and cannot be modified in transit. 52 HMAC is a secret key authentication algorithm. Data integrity and 53 data origin authentication as provided by HMAC are dependent upon the 54 scope of the distribution of the secret key. If only the source and 55 destination know the HMAC key, this provides both data origin 56 authentication and data integrity for packets sent between the two 57 parties; if the HMAC is correct, this proves that it must have been 58 added by the source. 60 In this draft, HMAC-RIPEMD-160-96 is used within the context of ESP 61 and AH. For further information on how the various pieces of ESP - 62 including the confidentiality mechanism -- fit together to provide 63 security services, refer to [ESP] and [Thayer97a]. For further 64 information on AH, refer to [AH] and [Thayer97a]. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC 2119]. 70 2. Algorithm and Mode 72 [RIPEMD-160] describes the underlying RIPEMD-160 algorithm, while 73 [RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides 74 a framework for inserting various hashing algorithms such as 75 RIPEMD-160. 77 HMAC-RIPEMD-160-96 operates on 64-byte blocks of data. Padding 78 requirements are specified in [RIPEMD-160] and are part of the 79 RIPEMD-160 algorithm. Padding bits are only necessary in computing 80 the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in 81 the packet. 83 HMAC-RIPEMD-160-96 produces a 160-bit authenticator value. This 84 160-bit value can be truncated as described in RFC2104. For use 85 with either ESP or AH, a truncated value using the first 96 bits 86 MUST be supported. Upon sending, the truncated value is stored 87 within the authenticator field. Upon receipt, the entire 160-bit 88 value is computed and the first 96 bits are compared to the value 89 stored in the authenticator field. No other authenticator value 90 lengths are supported by HMAC-RIPEMD-160-96. 92 The length of 96 bits was selected because it is the default 93 authenticator length as specified in [AH] and meets the security 94 requirements described in [RFC-2104]. 96 2.1 Performance 98 [Bellare96a] states that "(HMAC) performance is essentially that of 99 the underlying hash function". [RIPEMD-160] provides some performance 100 analysis. As of this writing no detailed performance analysis has 101 been done of HMAC or HMAC combined with RIPEMD-160. 103 [RFC-2104] outlines an implementation modification which can improve 104 per-packet performance without affecting interoperability. 106 3. Keying Material 108 HMAC-RIPEMD-160-96 is a secret key algorithm. While no fixed key 109 length is specified in [RFC-2104], for use with either ESP or AH a 110 fixed key length of 160-bits MUST be supported. Key lengths other 111 than 160-bits SHALL NOT be supported. A key length of 160-bits was 112 chosen based on the recommendations in [RFC-2104] (i.e. key lengths 113 less than the authenticator length decrease security strength and 114 keys longer than the authenticator length do not significantly 115 increase security strength). 117 [RFC-2104] discusses requirements for key material, which includes a 118 discussion on requirements for strong randomness. A strong pseudo- 119 random function MUST be used to generate the required 160-bit key. 121 At the time of this writing there are no specified weak keys for use 122 with HMAC. This does not mean to imply that weak keys do not exist. 123 If, at some point, a set of weak keys for HMAC are identified, the 124 use of these weak keys must be rejected followed by a request for 125 replacement keys or a newly negotiated Security Association. 127 [ESP] describes the general mechanism to obtain keying material for 128 the ESP transform. The derivation of the key from some amount of 129 keying material does not differ between the manual and automatic key 130 management mechanisms. 132 In order to provide data origin authentication, the key distribution 133 mechanism must ensure that unique keys are allocated and that they 134 are distributed only to the parties participating in the 135 communication. 137 [RFC-2104] states that for "minimally reasonable hash functions" the 138 "birthday attack" is impractical. For a 64-byte block hash such as 139 HMAC-RIPEMD-160-96, an attack involving the successful processing of 140 2**64 blocks would be infeasible unless it were discovered that the 141 underlying hash had collisions after processing 2**30 blocks. (A 142 hash with such weak collision-resistance characteristics would 143 generally be considered to be unusable.) No time-based attacks are 144 discussed in the document. 146 While it it still cryptographically prudent to perform frequent 147 rekeying, current literature does not include any recommended key 148 lifetimes for HMAC-RIPEMD. When recommendations for HMAC-RIPEMD key 149 lifetimes become available they will be included in a revised version 150 of this document. 152 4. Interaction with the ESP Cipher Mechanism 154 As of this writing, there are no known issues which preclude the use 155 of the HMAC-RIPEMD-160-96 algorithm with any specific cipher 156 algorithm. 158 5. Security Considerations 160 The security provided by HMAC-RIPEMD-160-96 is based upon the 161 strength of HMAC, and to a lesser degree, the strength of RIPEMD-160. 162 At the time of this writing there are no known cryptographic attacks 163 against RIPEMD-160. 165 It is also important to consider that while RIPEMD-160 was never 166 developed to be used as a keyed hash algorithm, HMAC had that 167 criteria from the onset. 169 [RFC-2104] also discusses the potential additional security which is 170 provided by the truncation of the resulting hash. Specifications 171 which include HMAC are strongly encouraged to perform this hash 172 truncation. 174 As [RFC-2104] provides a framework for incorporating various hash 175 algorithms with HMAC, it is possible to replace RIPEMD-160 with other 176 algorithms such as SHA-1. [RFC-2104] contains a detailed discussion 177 on the strengths and weaknesses of HMAC algorithms. 179 As is true with any cryptographic algorithm, part of its strength 180 lies in the correctness of the algorithm implementation, the security 181 of the key management mechanism and its implementation, the strength 182 of the associated secret key, and upon the correctness of the 183 implementation in all of the participating systems. [Kapp97] 184 contains test vectors and example code to assist in verifying the 185 correctness of HMAC-RIPEMD-160-96 code. 187 6. Acknowledgments 189 This document is derived from work by C. Madson and R. Glenn and 190 from previous works by Jim Hughes, those people that worked with Jim 191 on the combined DES/CBC+HMAC-MD5 ESP transforms, the ANX bakeoff 192 participants, and the members of the IPsec working group. 194 7. References 196 [RIPEMD-160] Dobbertin, H., Bosselaers A., and Preneel, B. 197 "RIPEMD-160: A Strengthened Version of RIPEMD" 198 April 1996, ftp.esat.kuleuven.ac.be: 199 /pub/COSIC/bosselae/ripemd/ripemd160.ps.gz 201 [RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 202 Hashing for Message Authentication", RFC-2104, 203 February, 1997 205 [Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying 206 Hash Functions for Message Authentication", Advances 207 in Cryptography, Crypto96 Proceeding, June 1996. 209 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 210 Payload", draft-ietf-ipsec-esp-v2-01.txt, 211 work in progress, October, 1997 213 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 214 draft-ietf-ipsec-auth-header-02.txt, work in progress, 215 October 1997 217 [Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 218 Document Framework", 219 draft-ietf-ipsec-doc-framework-01.txt, work in 220 progress, July 1997. 222 [Kapp97] Kapp, J.S., "Test Cases for HMAC-RIPEMD160 and 223 HMAC-RIPEMD128", RFC-2286, March 1998 225 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", RFC-2119, March 1997. 228 8. Authors' Address 230 Angelos D. Keromytis 231 Distributed Systems Lab 232 Computer and Information Science Department 233 University of Pennsylvania 234 200 S. 33rd Street 235 Philadelphia, PA 19104 - 6389 236 angelos@dsl.cis.upenn.edu 238 Niels Provos 239 PHYSnet Rechnerverbund 240 Universitaet Hamburg 241 Jungiusstrasse 9 242 Germany 20355 Hamburg 243 provos@physnet.uni-hamburg.de 245 The IPsec working group can be contacted through the chairs: 247 Robert Moskowitz 248 rgm@icsa.net 249 International Computer Security Association 251 Ted T'so 252 tytso@mit.edu 253 Massachusetts Institute of Technology