idnits 2.17.1 draft-ietf-ipsec-auth-hmac-md5-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-03-29) 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 are 3 instances 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. 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 1998) is 9539 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 238, but no explicit reference was found in the text ** 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' == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-02 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-02 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-03 -- Unexpected draft version: The latest known version of draft-ietf-ipsec-doc-roadmap is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'Thayer97a') ** Downref: Normative reference to an Informational RFC: RFC 2202 Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group IPsec Working Group 2 INTERNET DRAFT C. Madson 3 Expire in six months Cisco Systems Inc. 4 R. Glenn 5 NIST 6 February 1998 8 The Use of HMAC-MD5-96 within ESP and AH 9 11 Status of this Memo 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 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this memo is unlimited. 35 Abstract 37 This draft describes the use of the HMAC algorithm [RFC-2104] in 38 conjunction with the MD5 algorithm [RFC-1321] as an authentication 39 mechanism within the revised IPSEC Encapsulating Security Payload 40 [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 41 provides data origin authentication and 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 MD5 [RFC-1321] combined with HMAC 49 [RFC-2104] as a keyed authentication mechanism within the context of 50 the Encapsulating Security Payload and the Authentication Header. 51 The goal of HMAC-MD5-96 is to ensure that the packet is authentic and 52 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-MD5-96 is used within the context of ESP and AH. 63 For further information on how the various pieces of ESP - including 64 the confidentiality mechanism -- fit together to provide security 65 services, refer to [ESP] and [Thayer97a]. For further information on 66 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 [RFC-1321] describes the underlying MD5 algorithm, while [RFC-2104] 75 describes the HMAC algorithm. The HMAC algorithm provides a framework 76 for inserting various hashing algorithms such as MD5. 78 HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements 79 are specified in [RFC-1321] and are part of the MD5 algorithm. If 80 MD5 is built according to [RFC-1321], there is no need to add any 81 additional padding as far as HMAC-MD5-96 is concerned. With regard 82 to "implicit packet padding" as defined in [AH], no implicit packet 83 padding is required. 85 HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit 86 value can be truncated as described in RFC2104. For use with either 87 ESP or AH, a truncated value using the first 96 bits MUST be 88 supported. Upon sending, the truncated value is stored within the 89 authenticator field. Upon receipt, the entire 128-bit value is 90 computed and the first 96 bits are compared to the value stored in 91 the authenticator field. No other authenticator value lengths are 92 supported by HMAC-MD5-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". [RFC-1810] provides some performance 102 analysis and recommendations of the use of MD5 with Internet 103 protocols. As of this writing no performance analysis has been done 104 of HMAC or HMAC combined with MD5. 106 [RFC-2104] outlines an implementation modification which can improve 107 per-packet performance without affecting interoperability. 109 3. Keying Material 111 HMAC-MD5-96 is a secret key algorithm. While no fixed key length is 112 specified in [RFC-2104], for use with either ESP or AH a fixed key 113 length of 128-bits MUST be supported. Key lengths other than 114 128-bits MUST NOT be supported (i.e. only 128-bit keys are to be used 115 by HMAC-MD5-96). A key length of 128-bits was chosen based on the 116 recommendations in [RFC-2104] (i.e. key lengths less than the 117 authenticator length decrease security strength and keys longer than 118 the authenticator length do not significantly increase security 119 strength). 121 [RFC-2104] discusses requirements for key material, which includes a 122 discussion on requirements for strong randomness. A strong pseudo- 123 random function MUST be used to generate the required 128-bit key. 125 At the time of this writing there are no specified weak keys for use 126 with HMAC. This does not mean to imply that weak keys do not exist. 127 If, at some point, a set of weak keys for HMAC are identified, the 128 use of these weak keys must be rejected followed by a request for 129 replacement keys or a newly negotiated Security Association. 131 [ARCH] describes the general mechanism for obtaining keying material 132 when multiple keys are required for a single SA (e.g. when an ESP SA 133 requires a key for confidentiality and a key for authentication). 135 In order to provide data origin authentication, the key distribution 136 mechanism must ensure that unique keys are allocated and that they 137 are distributed only to the parties participating in the 138 communication. 140 [RFC-2104] states that for "minimally reasonable hash functions" the 141 "birthday attack" is impractical. For a 64-byte block hash such as 142 HMAC-MD5-96, an attack involving the successful processing of 2**64 143 blocks would be infeasible unless it were discovered that the 144 underlying hash had collisions after processing 2**30 blocks. A hash 145 with such weak collision-resistance characteristics would generally 146 be considered to be unusable. No time-based attacks are discussed in 147 the document. 149 While it it still cryptographically prudent to perform frequent 150 rekeying, current literature does not include any recommended key 151 lifetimes for HMAC-MD5-96 (i.e. there are too many variables involved 152 to propose a general recommendation). When any recommendations for 153 HMAC-MD5-96 key lifetimes become available they will be included in a 154 revised version of this document. 156 4. Interaction with the ESP Cipher Mechanism 158 As of this writing, there are no known issues which preclude the use 159 of the HMAC-MD5-96 algorithm with any specific cipher algorithm. 161 5. Security Considerations 163 The security provided by HMAC-MD5-96 is based upon the strength of 164 HMAC, and to a lesser degree, the strength of MD5. [RFC-2104] claims 165 that HMAC does not depend upon the property of strong collision 166 resistance, which is important to consider when evaluating the use of 167 MD5, an algorithm which has, under recent scrutiny, been shown to be 168 much less collision-resistant than was first thought. At the time of 169 this writing there are no known cryptographic attacks against HMAC- 170 MD5-96. 172 It is also important to consider that while MD5 was never developed 173 to be used as a keyed hash algorithm, HMAC had that criteria from the 174 onset. While the use of MD5 in the context of data security is 175 undergoing reevaluation, the combined HMAC with MD5 algorithm has 176 held up to cryptographic scrutiny. 178 [RFC-2104] also discusses the potential additional security which is 179 provided by the truncation of the resulting hash. Specifications 180 which include HMAC are strongly encouraged to perform this hash 181 truncation. 183 As [RFC-2104] provides a framework for incorporating various hash 184 algorithms with HMAC, it is possible to replace MD5 with other 185 algorithms such as SHA-1. [RFC-2104] contains a detailed discussion 186 on the strengths and weaknesses of HMAC algorithms. 188 As is true with any cryptographic algorithm, part of its strength 189 lies in the correctness of the algorithm implementation, the security 190 of the key management mechanism and its implementation, the strength 191 of the associated secret key, and upon the correctness of the 192 implementation in all of the participating systems. [RFC-2202] 193 contains test vectors and example code to assist in verifying the 194 correctness of HMAC-MD5-96 code. 196 6. Acknowledgments 198 This document is derived in part from previous works by Jim Hughes, 199 those people that worked with Jim on the combined DES/CBC+HMAC-MD5 200 ESP transforms, the ANX bakeoff participants, and the members of the 201 IPsec working group. 203 7. References 205 [RFC-1321] Rivest, R., "MD5 Digest Algorithm", RFC-1321, April 1992. 207 [RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 208 Hashing for Message Authentication", RFC-2104, 209 February 1997. 211 [RFC-1810] Touch, J. "Report on MD5 Performance", RFC-1810, 212 June 1995. 214 [Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying 215 Hash Functions for Message Authentication", Advances in 216 Cryptography, Crypto96 Proceeding, June 1996. 218 [ARCH] Kent, S., Atkinson, R., "Security Architecture for 219 the Internet Protocol", draft-ietf-ipsec-arch-sec-02.txt, 220 work in progress, November 1997. 222 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 223 Payload", draft-ietf-ipsec-esp-v2-02.txt, work in progress, 224 November 1997. 226 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 227 draft-ietf-ipsec-auth-header-03.txt, work in progress, 228 November 1997. 230 [Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 231 Document Roadmap", 232 draft-ietf-ipsec-doc-roadmap-02.txt, work in progress, 233 November 1997. 235 [RFC-2202] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and 236 HMAC-SHA-1", RFC-2202, March 1997. 238 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", RFC-2119, March 1997. 241 8. Editors' Address 243 Cheryl Madson 244 Cisco Systems, Inc. 245 e-mail: 247 Rob Glenn 248 NIST 249 e-mail: 251 The IPsec working group can be contacted through the chairs: 253 Robert Moskowitz 254 ICSA 255 e-mail: 256 Ted T'so 257 Massachusetts Institute of Technology 258 e-mail: