idnits 2.17.1 draft-ietf-ipsec-ah-hmac-sha-1-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-24) 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 25 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC-2104], [RFC-1826]), 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 79: '... Authentication Header specification [RFC-1826] SHOULD implement this...' RFC 2119 keyword, line 88: '... - MUST...' RFC 2119 keyword, line 93: '... - SHOULD...' RFC 2119 keyword, line 100: '... - MAY...' RFC 2119 keyword, line 128: '...ant implementations MUST support a key...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 84 has weird spacing: '... In this d...' == Line 85 has weird spacing: '...ficance of ea...' == Line 90 has weird spacing: '...ns that the ...' == Line 95 has weird spacing: '... means that ...' == Line 96 has weird spacing: '... exist valid...' -- 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 (March 20, 1997) is 9897 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) == Unused Reference: 'RFC-1828' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Downref: Normative reference to an Historic RFC: RFC 1828 ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'URL' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP-DES-MD5' -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC-TESTS' Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Chang (NIST) 2 R. Glenn (NIST) 3 March 20, 1997 4 Internet Draft 6 HMAC-SHA-1-96 IP Authentication with Replay Prevention 7 9 Status of This Memo 11 Distribution of this memo is unlimited. 13 This document is an Internet-Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months, and may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as 21 reference material, or to cite them other than as a ``working draft'' 22 or ``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: 28 ftp.is.co.za (Africa) 29 nic.nordu.net (Europe) 30 ds.internic.net (US East Coast) 31 ftp.isi.edu (US West Coast) 32 munnari.oz.au (Pacific Rim) 34 Abstract 36 This document describes a keyed-SHA transform to be used in 37 conjunction with the IP Authentication Header [RFC-1826]. The 38 particular transform is based on [RFC-2104]. A replay prevention 39 field is also specified. 41 Contents 43 1. Introduction...................................................3 44 1.1 Terminology.................................................3 45 1.2 Keys........................................................4 46 1.3 Data Size...................................................4 47 2 Packet Format..................................................5 48 2.1 Replay Prevention...........................................5 49 2.2 Authentication Data Calculation.............................6 50 3. Security Considerations........................................7 51 Acknowledgments....................................................7 52 References.........................................................8 53 Authors' Addresses.................................................8 55 1. Introduction 57 The IP Authentication Header (AH) provides integrity and 58 authentication for IP datagrams [RFC-1826]. The transform specified 59 in this document uses a keyed-SHA mechanism based on [RFC-2104]. The 60 mechanism uses the (key-less) SHA hash function [FIPS-180-1] which 61 produces a message digest. When combined with an AH Key, 62 Authentication Data is produced. This value is placed in the 63 Authentication Data field of the AH [RFC-1826]. This value is also 64 the basis for the data integrity service offered by the AH protocol. 66 To provide protection against replay attacks, a Replay Prevention 67 field is specified as a transform option. This field is used to help 68 prevent attacks in which a message is stored and re-used later, 69 replacing or repeating the original. The Security Parameters Index 70 (SPI) [RFC-1825] is used to determine whether this option is included 71 in the AH. 73 Familiarity with the following documents is assumed: "Security 74 Architecture for the Internet Protocol" [RFC-1825], "IP 75 Authentication Header" [RFC-1826], and "HMAC: Keyed Hashing for 76 Message Authentication" [RFC-2104]. 78 All implementations that claim conformance or compliance with the IP 79 Authentication Header specification [RFC-1826] SHOULD implement this 80 HMAC-SHA-1-96 transform. 82 1.1 Terminology 84 In this document, the words that are used to define the 85 significance of each particular requirement are usually capitalized. 86 These words are: 88 - MUST 90 This word or the adjective "REQUIRED" means that the item is an 91 absolute requirement of the specification. 93 - SHOULD 95 This word or the adjective "RECOMMENDED" means that there might 96 exist valid reasons in particular circumstances to ignore this item, 97 but the full implications should be understood and the case carefully 98 weighed before taking a different course. 100 - MAY 102 This word or the adjective "OPTIONAL" means that this item is truly 103 optional. One vendor might choose to include the item because a 104 particular marketplace requires it or because it enhances the product, 105 for example; another vendor may omit the same item. 107 For the purpose of this specification, the terms conformance and 108 compliance are synonymous. 110 1.2 Keys 112 The "AH Key" is used as a shared secret between two communicating 113 parties. The Key is not a "cryptographic key" as used in a 114 traditional sense. Instead, the AH key (shared secret) is hashed with 115 the transmitted data and thus, assures that an intervening party 116 cannot duplicate the Authentication Data. 118 Even though an AH key is not a cryptographic key, the rudimentary 119 concerns of cryptographic keys still apply. Consider that the 120 algorithm and most of the data used to produce the output is known. 121 The strength of the transform lies in the singular mapping of the key 122 (which needs to be strong) and the IP datagram (which is known) to 123 the Authentication Data. Thus, implementations should, and as 124 frequently as possible, change the AH key. Keys need to be chosen at 125 random, or generated using a cryptographically strong pseudo-random 126 generator seeded with a random seed. [RFC-2104] 128 All conforming and compliant implementations MUST support a key 129 length of 160 bits or less. Implementations SHOULD support longer 130 key lengths as well. It is advised that the key length be chosen to 131 be the length of the hash algorithm output, which is 160 bits for 132 SHA. For other key lengths the following concerns MUST be 133 considered. 135 A key length of zero is prohibited and implementations MUST prevent 136 key lengths of zero from being used with this transform, since no 137 effective authentication could be provided by a zero-length key. SHA 138 operates on 64-byte blocks. Keys longer than 64-bytes are first 139 hashed using SHA. The resulting hash is then used to calculate the 140 Authentication Data. 142 1.3 Data Size 144 HMAC-SHA-1 generates a message digest of 160 bits. HMAC-SHA-1-96 uses 145 the first or left most 96 bits as the Authentication Data. This 146 procedure is known as truncation. In the case of this transform, 147 truncation is used to help maintain 64-bit packet header alignment, 148 eliminate unnecessary overhead, and potentially provided stronger 149 authentication. [RFC-2104] provides more information on the 150 advantages and disadvantages of truncation. 152 2. Packet Format 154 +---------------+---------------+---------------+---------------+ 155 | Next Header | Length | RESERVED | 156 +---------------+---------------+---------------+---------------+ 157 | SPI | 158 +---------------+---------------+---------------+---------------+ 159 | Replay Prevention | 160 +---------------+---------------+---------------+---------------+ 161 | | 162 + + 163 | Authentication Data | 164 + + 165 | | 166 +---------------+---------------+---------------+---------------+ 167 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 169 The Next Header, RESERVED, and SPI fields are specified in [RFC- 170 1826]. The Length field is the length of the Replay Prevention field 171 and the Authentication Data in 32-bit words. The Length field will 172 always be set to 4 (128 bits) for HMAC-SHA-1-96. 174 2.1 Replay Prevention 176 The Replay Prevention field is a 32-bit value used to guarantee that 177 each packet exchanged between two parties is different. Each IPsec 178 Security Association specifies whether Replay Prevention is used for 179 that Security Association. The Replay Prevention field is always 180 included in the calculation of the Authentication Data. If Replay 181 Prevention is NOT in use, the 32-bit value is set to 0, included in 182 the calculation of the Authentication Data, and ignored upon receipt 183 with regard to checking for replay. This field is used to help 184 prevent attacks in which a message is stored and re-used later, 185 replacing or repeating the original. Replay Prevention SHOULD be 186 implemented. 188 Replay Prevention SHOULD be implemented. If Replay Prevention is not 189 implemented, the 32-bit field remains are part of the AH and is 190 treated as if Replay Prevention is NOT in use (i.e. the 32-bit value 191 is set to 0, included in the calculation of the Authentication Data, 192 and ignored upon receipt with regard to checking for replay. 194 The 32-bit field is an up counter starting at a value of 1. 196 The secret shared key MUST NOT be used for a period of time that 197 allows the counter to wrap, that is, to transmit more than 2^32 198 packets using a single key. 200 Upon receipt, the replay value is assured to be increasing. An 201 implementation MAY accept out of order packets. If an "out of order 202 window" is supported, an implementation MUST guarantee that any and 203 all packets accepted out of order have not arrived before. That is, 204 an implementation MUST accept any packet, at most, once. The size of 205 the window is a negotiated value specified by the IPsec Security 206 Association. 208 [ESP-DES-MD5] provides more information on negotiated windows sizes, 209 example code that implements a 32 packet replay window, and a test 210 routine to show how it could be implemented. 212 When the destination address is a multicast address and more than one 213 sender is sharing the same IPsec Security Association to that 214 multicast destination address, then Replay Prevention SHOULD NOT be 215 enabled. When Replay Prevention is desired for a multicast session 216 having multiple senders to the same multicast destination address, 217 each sender SHOULD have its own IPsec Security Association. 219 2.2 Authentication Data Calculation 221 The Authentication Data is the output of the SHA authentication 222 algorithm as described in [FIPS-180-1]. The digest is calculated 223 over the entire IP datagram. Fields within the datagram that are 224 variant during transit and the Authentication Data field itself must 225 contain all zeros prior to the computation [RFC-1826]. The Replay 226 Prevention field, used or not, is included in the calculation. 228 To compute HMAC-SHA-1 over the data 'text', the following is 229 calculated: 231 SHA (K XOR opad, SHA (K XOR ipad, text)) 233 The result of which is truncated to 96 bits (retaining the left most 234 bits) to produce HMAC-SHA-1-96. 236 K denotes the secret key shared by the parties. If K is longer than 237 64-bytes, it MUST first be hashed using SHA. In this case, K is the 238 resulting hash. The variables 'ipad', 'opad' denote fixed strings 239 for inner and outer padding respectively. The two strings are: 241 ipad = the byte 0x36 repeated 64 times, 242 opad = the byte 0x5C repeated 64 times. 244 The calculation of the Authentication Data consists of the following 245 steps: 247 (1) append zeros to the end of K to create a 64 byte string (e.g., if K 248 is of length 16 bytes it will be appended with 48 zero bytes 0x00) 249 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) 250 with ipad 251 (3) concatenate to the 64 byte string resulting from step (2) the data 252 stream 'text' 253 (4) apply SHA to the stream generated in step (3) 254 (5) XOR the 64 byte string computed in step (1) with opad 255 (6) concatenate to the 64 byte string resulting from step (5) the SHA 256 result of step (4) 257 (7) apply SHA to the stream generated in step (6) 258 (8) use the left most 96 bits of the result obtained in (7) as the final 259 result 261 A similar computation is described in more detail, along with example 262 code and performance improvements, in [RFC-2104]. Implementers 263 should consult [RFC-2104] for more information on the HMAC technique 264 for keying a cryptographic hash function. 266 3. Security Considerations 268 The security provided by this transform is based on the strength of 269 SHA, the correctness of the algorithm's implementation, the security 270 of the key management mechanism and its implementation, the strength 271 of the associated secret key, and upon the correctness of the 272 implementations in all of the participating systems. [RFC-2104] 273 contains a detailed discussion on the strengths and weaknesses of 274 HMAC algorithms. [HMAC-TESTS] contains test vectors and example code 275 to assist in verifying the correctness of HMAC-SHA-1 code. 277 Acknowledgments 279 This document is largely based on text written by Hugo Krawczyk. The 280 format used was derived from work by William Simpson and Perry Metzger. 281 The text on replay prevention is derived from work by Jim Hughes. 283 References 285 [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol", 286 RFC-1825, August 1995. 287 [RFC-1826] R. Atkinson, "IP Authentication Header", 288 RFC-1826, August 1995. 289 [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", 290 RFC-1828, August 1995. 291 [RFC-2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing 292 for Message Authentication", RFC-2104, February, 1997. 293 [FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 294 [URL] http://csrc.nist.gov/fips/fip180-1.txt (ascii) 295 [URL] http://csrc.nist.gov/fips/fip180-1.ps (postscript) 296 [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention 297 Security Transform", Internet Draft, September 1996. 298 [HMAC-TESTS] P. Cheng, R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 299 Internet Draft, March 1997. 301 Authors' Addresses 303 Shu-jen Chang 304 NIST 305 Building 820, Room 456 306 Gaithersburg, MD 20899 308 shu-jen.chang@nist.gov 310 Robert Glenn 311 NIST 312 Building 820, Room 455 313 Gaithersburg, MD 20899 315 rob.glenn@nist.gov