idnits 2.17.1 draft-ietf-ipsec-auth-hmac-md5-96-00.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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 61 lines 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC-2104], [RFC-1321], [Thayer97a], [AH], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 82: '...he first 96 bits MUST be supported. U...' RFC 2119 keyword, line 107: '...ngth of 128-bits MUST be supported. A...' RFC 2119 keyword, line 115: '... random function MUST be used to gener...' 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 1997) is 9782 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 72, but not defined ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 1810 -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare96a' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-esp is -00, but you're referring to -04. -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth is -01, but you're referring to -05. -- No information found for draft-ietf-ipsec-ff-Doc-Framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Thayer97a' ** Downref: Normative reference to an Informational draft: draft-cheng-hmac-test-cases (ref. 'HMAC-TESTS') Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IPsec Working Group 3 INTERNET DRAFT C. Madson 4 Expire in six months Cisco Systems Inc. 5 R. Glenn 6 NIST 7 July 1997 9 The Use of HMAC-MD5-96 within ESP and AH 10 12 Status of this Memo 14 This document is a submission to the IETF Internet Protocol Security 15 (IPSEC) Working Group. Comments are solicited and should be addressed 16 to the working group mailing list (ipsec@tis.com) or to the editor. 18 This document is an Internet-Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working Groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet-Drafts draft documents are valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this memo is unlimited. 36 Abstract 38 This draft describes the use of the HMAC algorithm [RFC-2104] in 39 conjunction with the MD5 algorithm [RFC-1321] as an authentication 40 mechanism within the revised IPSEC Encapsulating Security Payload 41 [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 42 provides data origin authentication and integrity protection. 44 Further information on the other components necessary for ESP and AH 45 implementations is provided by [Thayer97a]. 47 1. Introduction 49 This draft specifies a the use of MD5 [RFC-1321] combined with HMAC 50 [RFC-2104] as a keyed authentication mechanism within the context of 51 the Encapsulating Security Payload and the Authentication Header. 52 The goal of HMAC-MD5-96 is to ensure that the packet is authentic and 53 cannot be modified in transit. 55 HMAC is a secret key authentication algorithm. Data integrity and 56 data origin authentication as provided by HMAC are dependent upon the 57 scope of the distribution of the secret key. If only the source and 58 destination know the HMAC key, this provides both data origin 59 authentication and data integrity for packets sent between the two 60 parties; if the HMAC is correct, this proves that it must have been 61 added by the source. 63 In this draft, HMAC-MD5-96 is used within the context of ESP and AH. 64 For further information on how the various pieces of ESP - including 65 the confidentiality mechanism -- fit together to provide security 66 services, refer to [ESP] and [Thayer97a]. For further information on 67 AH, refer to [AH] and [Thayer97a]. 69 In this document, the key words "MAY", "MUST", "optional", 70 "recommended", "required", "SHOULD", and "SHOULD NOT", are to be 71 interpreted as described in [RFC-2119]. 73 2. Algorithm and Mode 75 [RFC-1321] describes the underlying MD5 algorithm, while [RFC-2104] 76 describes the HMAC algorithm. The HMAC algorithm provides a framework 77 for inserting various hashing algorithms such as MD5. 79 HMAC-MD5-96 operates on 64-byte blocks of data and produces a 128-bit 80 authenticator value. This 128-bit value can be truncated as 81 described in RFC2104. For use with either ESP or AH, a truncated 82 value using the first 96 bits MUST be supported. Upon sending, the 83 truncated value is stored within the authenticator field. Upon 84 receipt, the entire 128-bit value is computed and the first 96 bits 85 are compared to the value stored in the authenticator field. No 86 other authenticator value lengths are supported by HMAC-MD5-96. 88 The length of 96 bits was selected because it is the default 89 authenticator length as specified in [AH] and meets the security 90 requirements described in [RFC-2104]. 92 2.1 Performance 94 [Bellare96a] states that "(HMAC) performance is essentially that of 95 the underlying hash function". [RFC-1810] provides some performance 96 analysis and recommendations of the use of MD5 with Internet 97 protocols. As of this writing no performance analysis has been done 98 of HMAC or HMAC combined with MD5. 100 [RFC-2104] outlines an implementation modification which can improve 101 per-packet performance without affecting interoperability. 103 3. Keying Material 105 HMAC-MD5-96 is a secret key algorithm. While no fixed key length is 106 specified in [RFC-2104], for use with either ESP or AH a fixed key 107 length of 128-bits MUST be supported. A key length of 128-bits was 108 chosen based on the recommendations in [RFC-2104] (i.e. key lengths 109 less than the authenticator length decrease security strength and 110 keys longer than the authenticator length do not significantly 111 increase security strength). 113 [RFC-2104] discusses requirements for key material, which includes a 114 discussion on requirements for strong randomness. A strong pseudo- 115 random function MUST be used to generate the required 128-bit key. 117 At the time of this writing there are no specified weak keys for use 118 with HMAC. This does not mean to imply that weak keys do not exist. 119 If, at some point, a set of weak keys for HMAC are identified, the 120 use of these weak keys must be rejected followed by a request for 121 replacement keys or a newly negotiated Security Association. 123 [ESP] describes the general mechanism to obtain keying material for 124 the ESP transform. The derivation of the key from some amount of 125 keying material does not differ between the manual and automatic key 126 management mechanisms. 128 In order to provide data origin authentication, the key distribution 129 mechanism must ensure that unique keys are allocated and that they 130 are distributed only to the parties participating in the 131 communication. 133 [RFC-2104] states that for "minimally reasonable hash functions" the 134 "birthday attack" is impractical. For a 64-byte block hash such as 135 HMAC-MD5-96, an attack involving the successful processing of 2**64 136 blocks would be infeasible unless it were discovered that the 137 underlying hash had collisions after processing 2**30 blocks. (A 138 hash with such weak collision-resistance characteristics would 139 generally be considered to be unusable.) No time-based attacks are 140 discussed in the document. 142 As it it still cryptographically prudent to perform frequent 143 rekeying, the recommended key lifetimes are 2**32 blocks and ???? 144 seconds. 146 4. Interaction with the ESP Cipher Mechanism 148 As of this writing, there are no known issues which preclude the use 149 of the HMAC-MD5-96 algorithm with any specific cipher algorithm. 151 5. Security Considerations 153 The security provided by HMAC-MD5-96 is based upon the strength of 154 HMAC, and to a lesser degree, the strength of MD5. [RFC-2104] claims 155 that HMAC does not depend upon the property of strong collision 156 resistance, which is important to consider when evaluating the use of 157 MD5, an algorithm which has, under recent scrutiny, been shown to be 158 much less collision-resistant than was first thought. 160 It is also important to consider that while MD5 was never developed 161 to be used as a keyed hash algorithm, HMAC had that criteria from the 162 onset. While the use of MD5 in the context of data security is 163 undergoing reevaluation, the combined HMAC with MD5 algorithm has 164 held up to cryptographic scrutiny. 166 [RFC-2104] also discusses the potential additional security which is 167 provided by the truncation of the resulting hash. Specifications 168 which include HMAC are strongly encouraged to perform this hash 169 truncation. 171 As [RFC-2104] provides a framework for incorporating various hash 172 algorithms with HMAC, it is possible to replace MD5 with other 173 algorithms such as SHA-1. [RFC-2104] contains a detailed discussion 174 on the strengths and weaknesses of HMAC algorithms. 176 As is true with any cryptographic algorithm, part of its strength 177 lies in the correctness of the algorithm implementation, the security 178 of the key management mechanism and its implementation, the strength 179 of the associated secret key, and upon the correctness of the 180 implementation in all of the participating systems. [HMAC-TESTS] 181 contains test vectors and example code to assist in verifying the 182 correctness of HMAC-MD5-96 code. 184 6. Acknowledgments 186 This document is derived in part from previous works by Jim Hughes, 187 those people that worked with Jim on the combined DES/CBC+HMAC-MD5 188 ESP transforms, the ANX bakeoff participants, and the members of the 189 IPsec working group. 191 7. References 193 [RFC-1321] Rivest, R., "MD5 Digest Algorithm", RFC-1321, April 1992 195 [RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 196 Hashing for Message Authentication", RFC-2104, 197 February, 1997 199 [RFC-1810] Touch, J. "Report on MD5 Performance", RFC-1810, 200 June 1995. 202 [Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying 203 Hash Functions for Message Authentication", Advances in 204 Cryptography, Crypto96 Proceeding, June 1996. 206 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 207 Payload", draft-ietf-ipsec-esp-04.txt, work in progress, 208 March 26, 1997 210 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 211 draft-ietf-ipsec-auth-05.txt, work in progress, 212 March 26, 1997 214 [Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 215 Document Framework", 216 draft-ietf-ipsec-ff-Doc-Framework-00.txt, work in progress, 217 June 1997. 219 [HMAC-TESTS] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and 220 HMAC-SHA-1", draft-cheng-hmac-test-cases-00.txt, work 221 in progress, March 1997. 223 8. Editors' Address 225 Cheryl Madson 226 227 Cisco Systems, Inc. 229 Rob Glenn 230 231 NIST 233 The IPsec working group can be contacted through the chairs: 235 Robert Moskowitz 236 237 Chrysler Corporation 239 Ted T'so 240 tytso@mit.edu 241 Massachusetts Institute of Technology