idnits 2.17.1 draft-ietf-ipsec-auth-hmac-sha196-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 4 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. ** The abstract seems to contain references ([RFC-2104], [Thayer97a], [AH], [FIPS-180-1], [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 72, but not defined == Unused Reference: 'RFC-2119' is defined on line 233, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- 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: 12 errors (**), 0 flaws (~~), 7 warnings (==), 5 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-SHA-1-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 SHA-1 algorithm [FIPS-180-1] as an 39 authentication mechanism within the revised IPSEC Encapsulating 40 Security Payload [ESP] and the revised IPSEC Authentication Header 41 [AH]. HMAC with SHA-1 provides data origin authentication and 42 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 the use of SHA-1 [FIPS-180-1] 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-SHA-1-96 is to ensure that the packet is authentic 53 and 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-SHA-1-96 is used within the context of ESP and 64 AH. For further information on how the various pieces of ESP - 65 including the confidentiality mechanism -- fit together to provide 66 security services, refer to [ESP] and [Thayer97a]. For further 67 information on AH, refer to [AH] and [Thayer97a]. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC 2119]. 73 2. Algorithm and Mode 75 [FIPS-180-1] describes the underlying SHA-1 algorithm, while 76 [RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides 77 a framework for inserting various hashing algorithms such as SHA-1. 79 HMAC-SHA-1-96 operates on 64-byte blocks of data. Padding 80 requirements are specified in [FIPS-180-1] and are part of the SHA-1 81 algorithm. If you build SHA-1 according to [FIPS-180-1] you do not 82 need to add any additional padding as far as HMAC-SHA-1-96 is 83 concerned. With regard to "implicit packet padding" as defined in 84 [AH] no implicit packet padding is required. 86 HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit 87 value can be truncated as described in RFC2104. For use with either 88 ESP or AH, a truncated value using the first 96 bits MUST be 89 supported. Upon sending, the truncated value is stored within the 90 authenticator field. Upon receipt, the entire 160-bit value is 91 computed and the first 96 bits are compared to the value stored in 92 the authenticator field. No other authenticator value lengths are 93 supported by HMAC-SHA-1-96. 95 The length of 96 bits was selected because it is the default 96 authenticator length as specified in [AH] and meets the security 97 requirements described in [RFC-2104]. 99 2.1 Performance 101 [Bellare96a] states that "(HMAC) performance is essentially that of 102 the underlying hash function". As of this writing no detailed 103 performance analysis has been done of SHA-1, HMAC or HMAC combined 104 with SHA-1. 106 [RFC-2104] outlines an implementation modification which can improve 107 per-packet performance without affecting interoperability. 109 3. Keying Material 111 HMAC-SHA-1-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 160-bits MUST be supported. Key lengths other than 114 160-bits MUST NOT be supported (i.e. only 160-bit keys are to be used 115 by HMAC-SHA-1-96). A key length of 160-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 160-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-SHA-1-96, an attack involving the successful processing of 2**80 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-SHA-1-96 (i.e. there are too many variable 152 involved to propose a general recommendation). When any 153 recommendations for HMAC-SHA-1-96 key lifetimes become available they 154 will be included in a 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-SHA-1-96 algorithm with any specific cipher algorithm. 161 5. Security Considerations 163 The security provided by HMAC-SHA-1-96 is based upon the strength of 164 HMAC, and to a lesser degree, the strength of SHA-1. At the time of 165 this writing there are no known cryptographic attacks against SHA-1 166 or HMAC-SHA-1-96. 168 It is also important to consider that while SHA-1 was never developed 169 to be used as a keyed hash algorithm, HMAC had that criteria from the 170 onset. 172 [RFC-2104] also discusses the potential additional security which is 173 provided by the truncation of the resulting hash. Specifications 174 which include HMAC are strongly encouraged to perform this hash 175 truncation. 177 As [RFC-2104] provides a framework for incorporating various hash 178 algorithms with HMAC, it is possible to replace SHA-1 with other 179 algorithms such as MD5. [RFC-2104] contains a detailed discussion on 180 the strengths and weaknesses of HMAC algorithms. 182 As is true with any cryptographic algorithm, part of its strength 183 lies in the correctness of the algorithm implementation, the security 184 of the key management mechanism and its implementation, the strength 185 of the associated secret key, and upon the correctness of the 186 implementation in all of the participating systems. [RFC-2202] 187 contains test vectors and example code to assist in verifying the 188 correctness of HMAC-SHA-1-96 code. 190 6. Acknowledgments 192 This document is derived in part from previous works by Jim Hughes, 193 those people that worked with Jim on the combined DES/CBC+HMAC-MD5 194 ESP transforms, the ANX bakeoff participants, and the members of the 195 IPsec working group. 197 7. References 199 [FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard, 200 April 1995. 201 http://csrc.nist.gov/fips/fip180-1.txt (ascii) 202 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 204 [RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 205 Hashing for Message Authentication", RFC-2104, 206 February 1997. 208 [Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying 209 Hash Functions for Message Authentication", Advances 210 in Cryptography, Crypto96 Proceeding, June 1996. 212 [ARCH] Kent, S., Atkinson, R., "Security Architecture for 213 the Internet Protocol", 214 draft-ietf-ipsec-arch-sec-02.txt, work in progress, 215 November 1997. 217 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 218 Payload", draft-ietf-ipsec-esp-v2-02.txt, 219 work in progress, November 1997. 221 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 222 draft-ietf-ipsec-auth-header-03.txt, work in progress, 223 November 1997. 225 [Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 226 Document Roadmap", 227 draft-ietf-ipsec-doc-roadmap-02.txt, work in 228 progress, November 1997. 230 [RFC-2202] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and 231 HMAC-SHA-1", RFC-2202, March 1997. 233 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", RFC-2119, March 1997. 236 8. Editors' Address 238 Cheryl Madson 239 Cisco Systems, Inc. 240 e-mail: 242 Rob Glenn 243 NIST 244 e-mail: 246 The IPsec working group can be contacted through the chairs: 248 Robert Moskowitz 249 ICSA 250 e-mail: 252 Ted T'so 253 Massachusetts Institute of Technology 254 e-mail: