idnits 2.17.1 draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == 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 7 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 (February 1999) is 9202 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 71, but not defined == Unused Reference: 'RFC-2119' is defined on line 227, 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: 11 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 February 1999 5 The Use of HMAC-RIPEMD-160-96 within ESP and AH 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 This document is a submission to the IETF Internet Protocol Security 14 (IPSEC) Working Group. Comments are solicited and should be addressed 15 to the working group mailing list (ipsec@tis.com) or to the editor. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working Groups. Note that other 19 groups may also distribute working documents as Internet Drafts. 21 Internet-Drafts draft documents are valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Abstract 36 This draft describes the use of the HMAC algorithm [RFC-2104] in 37 conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an 38 authentication mechanism within the revised IPSEC Encapsulating 39 Security Payload [ESP] and the revised IPSEC Authentication Header 40 [AH]. HMAC with RIPEMD-160 provides data origin authentication and 41 integrity protection. 43 Further information on the other components necessary for ESP and AH 44 implementations is provided by [Thayer97a]. 46 1. Introduction 48 This draft specifies the use of RIPEMD-160 [RIPEMD-160] combined with 49 HMAC [RFC-2104] as a keyed authentication mechanism within the context 50 of the Encapsulating Security Payload and the Authentication Header. 51 The goal of HMAC-RIPEMD-160-96 is to ensure that the packet is 52 authentic and cannot be modified in transit. 54 HMAC is a secret key authentication algorithm. Data integrity and 55 data origin authentication as provided by HMAC are dependent upon the 56 scope of the distribution of the secret key. If only the source and 57 destination know the HMAC key, this provides both data origin 58 authentication and data integrity for packets sent between the two 59 parties; if the HMAC is correct, this proves that it must have been 60 added by the source. 62 In this draft, HMAC-RIPEMD-160-96 is used within the context of ESP 63 and AH. For further information on how the various pieces of ESP - 64 including the confidentiality mechanism -- fit together to provide 65 security services, refer to [ESP] and [Thayer97a]. For further 66 information on AH, refer to [AH] and [Thayer97a]. 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC 2119]. 72 2. Algorithm and Mode 74 [RIPEMD-160] describes the underlying RIPEMD-160 algorithm, while 75 [RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides 76 a framework for inserting various hashing algorithms such as 77 RIPEMD-160. 79 HMAC-RIPEMD-160-96 operates on 64-byte blocks of data. Padding 80 requirements are specified in [RIPEMD-160] and are part of the 81 RIPEMD-160 algorithm. Padding bits are only necessary in computing 82 the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in 83 the packet. 85 HMAC-RIPEMD-160-96 produces a 160-bit authenticator value. This 86 160-bit value can be truncated as described in RFC2104. For use 87 with either ESP or AH, a truncated value using the first 96 bits 88 MUST be supported. Upon sending, the truncated value is stored 89 within the authenticator field. Upon receipt, the entire 160-bit 90 value is computed and the first 96 bits are compared to the value 91 stored in the authenticator field. No other authenticator value 92 lengths are supported by HMAC-RIPEMD-160-96. 94 The length of 96 bits was selected because it is the default 95 authenticator length as specified in [AH] and meets the security 96 requirements described in [RFC-2104]. 98 2.1 Performance 100 [Bellare96a] states that "(HMAC) performance is essentially that of 101 the underlying hash function". [RIPEMD-160] provides some performance 102 analysis. As of this writing no detailed performance analysis has 103 been done of HMAC or HMAC combined with RIPEMD-160. 105 [RFC-2104] outlines an implementation modification which can improve 106 per-packet performance without affecting interoperability. 108 3. Keying Material 110 HMAC-RIPEMD-160-96 is a secret key algorithm. While no fixed key 111 length is specified in [RFC-2104], for use with either ESP or AH a 112 fixed key length of 160-bits MUST be supported. Key lengths other 113 than 160-bits SHALL NOT be supported. A key length of 160-bits was 114 chosen based on the recommendations in [RFC-2104] (i.e. key lengths 115 less than the authenticator length decrease security strength and 116 keys longer than the authenticator length do not significantly 117 increase security strength). 119 [RFC-2104] discusses requirements for key material, which includes a 120 discussion on requirements for strong randomness. A strong pseudo- 121 random function MUST be used to generate the required 160-bit key. 123 At the time of this writing there are no specified weak keys for use 124 with HMAC. This does not mean to imply that weak keys do not exist. 125 If, at some point, a set of weak keys for HMAC are identified, the 126 use of these weak keys must be rejected followed by a request for 127 replacement keys or a newly negotiated Security Association. 129 [ESP] describes the general mechanism to obtain keying material for 130 the ESP transform. The derivation of the key from some amount of 131 keying material does not differ between the manual and automatic key 132 management mechanisms. 134 In order to provide data origin authentication, the key distribution 135 mechanism must ensure that unique keys are allocated and that they 136 are distributed only to the parties participating in the 137 communication. 139 [RFC-2104] states that for "minimally reasonable hash functions" the 140 "birthday attack" is impractical. For a 64-byte block hash such as 141 HMAC-RIPEMD-160-96, an attack involving the successful processing of 142 2**64 blocks would be infeasible unless it were discovered that the 143 underlying hash had collisions after processing 2**30 blocks. (A 144 hash with such weak collision-resistance characteristics would 145 generally be considered to be unusable.) No time-based attacks are 146 discussed in the document. 148 While it it still cryptographically prudent to perform frequent 149 rekeying, current literature does not include any recommended key 150 lifetimes for HMAC-RIPEMD. When recommendations for HMAC-RIPEMD key 151 lifetimes become available they will be included in a revised version 152 of this document. 154 4. Interaction with the ESP Cipher Mechanism 156 As of this writing, there are no known issues which preclude the use 157 of the HMAC-RIPEMD-160-96 algorithm with any specific cipher 158 algorithm. 160 5. Security Considerations 162 The security provided by HMAC-RIPEMD-160-96 is based upon the 163 strength of HMAC, and to a lesser degree, the strength of RIPEMD-160. 164 At the time of this writing there are no known cryptographic attacks 165 against RIPEMD-160. 167 It is also important to consider that while RIPEMD-160 was never 168 developed to be used as a keyed hash algorithm, HMAC had that 169 criteria from the onset. 171 [RFC-2104] also discusses the potential additional security which is 172 provided by the truncation of the resulting hash. Specifications 173 which include HMAC are strongly encouraged to perform this hash 174 truncation. 176 As [RFC-2104] provides a framework for incorporating various hash 177 algorithms with HMAC, it is possible to replace RIPEMD-160 with other 178 algorithms such as SHA-1. [RFC-2104] contains a detailed discussion 179 on the strengths and weaknesses of HMAC algorithms. 181 As is true with any cryptographic algorithm, part of its strength 182 lies in the correctness of the algorithm implementation, the security 183 of the key management mechanism and its implementation, the strength 184 of the associated secret key, and upon the correctness of the 185 implementation in all of the participating systems. [Kapp97] 186 contains test vectors and example code to assist in verifying the 187 correctness of HMAC-RIPEMD-160-96 code. 189 6. Acknowledgments 191 This document is derived from work by C. Madson and R. Glenn and 192 from previous works by Jim Hughes, those people that worked with Jim 193 on the combined DES/CBC+HMAC-MD5 ESP transforms, the ANX bakeoff 194 participants, and the members of the IPsec working group. 196 7. References 198 [RIPEMD-160] Dobbertin, H., Bosselaers A., and Preneel, B. 199 "RIPEMD-160: A Strengthened Version of RIPEMD" 200 April 1996, ftp.esat.kuleuven.ac.be: 201 /pub/COSIC/bosselae/ripemd/ripemd160.ps.gz 203 [RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 204 Hashing for Message Authentication", RFC-2104, 205 February, 1997 207 [Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying 208 Hash Functions for Message Authentication", Advances 209 in Cryptography, Crypto96 Proceeding, June 1996. 211 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 212 Payload", draft-ietf-ipsec-esp-v2-01.txt, 213 work in progress, October, 1997 215 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 216 draft-ietf-ipsec-auth-header-02.txt, work in progress, 217 October 1997 219 [Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 220 Document Framework", 221 draft-ietf-ipsec-doc-framework-01.txt, work in 222 progress, July 1997. 224 [Kapp97] Kapp, J.S., "Test Cases for HMAC-RIPEMD160 and 225 HMAC-RIPEMD128", RFC-2286, March 1998 227 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", RFC-2119, March 1997. 230 8. Authors' Address 232 Angelos D. Keromytis 233 Distributed Systems Lab 234 Computer and Information Science Department 235 University of Pennsylvania 236 200 S. 33rd Street 237 Philadelphia, PA 19104 - 6389 238 angelos@dsl.cis.upenn.edu 240 Niels Provos 241 Center for Information Technology Integration 242 University of Michigan 243 519 W. William 244 Ann Arbor, Michigan 48103 USA 245 provos@citi.umich.edu 247 The IPsec working group can be contacted through the chairs: 249 Robert Moskowitz 250 rgm@icsa.net 251 International Computer Security Association 253 Ted T'so 254 tytso@mit.edu 255 Massachusetts Institute of Technology