idnits 2.17.1 draft-ietf-ipsec-ah-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-19) 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 21 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] MUST 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...' (11 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 9892 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 296, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1852 (ref. 'RFC-1825') (Obsoleted by RFC 2841) ** 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 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP-DES-MD5' -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC-TESTS' Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Oehler (NSA) 3 R. Glenn (NIST) 4 Internet Draft March 20, 1997 6 HMAC-MD5-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-MD5 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 Authentication Header (AH) [RFC-1826] provides integrity and 58 authentication for IP datagrams. The transform specified in this 59 document uses a keyed-MD5 mechanism [RFC-2104]. The mechanism uses 60 the (key-less) MD5 hash function [RFC-1321] which produces a message 61 digest. When combined with an AH Key, Authentication Data is 62 produced. This value is placed in the Authentication Data field of 63 the AH [RFC-1826]. This value is also the basis for the data 64 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] MUST implement this 80 HMAC-MD5-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 128 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 128 bits for 132 MD5. 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. 138 Keys having a length less than 128 bits are strongly discouraged as 139 it would decrease the security strength of the function. Keys longer 140 than 128 bits are acceptable, but the extra length may not 141 significantly increase the function strength. MD5 operates on 64- 142 byte blocks. Keys longer than 64-bytes are first hashed using MD5. 143 The resulting hash is then used to calculate the Authentication Data. 145 1.3 Data Size 147 HMAC-MD5 produces a 128-bit value. HMAC-MD5-96 uses the first or 148 left most 96 bits as the Authentication Data. This procedure is 149 known as truncation. In the case of this transform, truncation is 150 used to help maintain 64-bit packet header alignment, eliminate 151 unnecessary overhead, and potentially provide stronger 152 authentication. [RFC-2104] provides more information on the 153 advantages and disadvantages of truncation. 155 2. Packet Format 157 +---------------+---------------+---------------+---------------+ 158 | Next Header | Length | RESERVED | 159 +---------------+---------------+---------------+---------------+ 160 | SPI | 161 +---------------+---------------+---------------+---------------+ 162 | Replay Prevention | 163 +---------------+---------------+---------------+---------------+ 164 | | 165 + + 166 | Authentication Data | 167 + + 168 | | 169 +---------------+---------------+---------------+---------------+ 170 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 172 The Next Header, RESERVED, and SPI fields are specified in [RFC- 173 1826]. The Length field is the length of the Replay Prevention field 174 and the Authentication Data in 32-bit words. The Length field will 175 always be set to 4 (128 bits) for HMAC-MD5-96. 177 2.1 Replay Prevention 179 The Replay Prevention field is a 32-bit value used to guarantee that 180 each packet exchanged between two parties is different. Each IPsec 181 Security Association specifies whether Replay Prevention is used for 182 that Security Association. The Replay Prevention field is always 183 included in the calculation of the Authentication Data. If Replay 184 Prevention is NOT in use, the 32-bit value is set to 0, included in 185 the calculation of the Authentication Data, and ignored upon receipt 186 with regard to checking for replay. This field is used to help 187 prevent attacks in which a message is stored and re-used later, 188 replacing or repeating the original. 190 Replay Prevention SHOULD be implemented. If Replay Prevention is not 191 implemented, the 32-bit field remains are part of the AH and is 192 treated as if Replay Prevention is NOT in use (i.e. the 32-bit value 193 is set to 0, included in the calculation of the Authentication Data, 194 and ignored upon receipt with regard to checking for replay. 196 The 32-bit field is an up counter starting at a value of 1. 198 The secret shared key MUST NOT be used for a period of time that 199 allows the counter to wrap, that is, to transmit more than 2^32 200 packets using a single key. 202 Upon receipt, the replay value is assured to be increasing. An 203 implementation MAY accept out of order packets. If an "out of order 204 window" is supported, an implementation MUST guarantee that any and 205 all packets accepted out of order have not arrived before. That is, 206 an implementation MUST accept any packet, at most, once. The size of 207 the window is a negotiated value specified by the IPsec Security 208 Association. 210 [ESP-DES-MD5] provides more information on negotiated windows sizes, 211 example code that implements a 32 packet replay window, and a test 212 routine to show how it could be implemented. 214 When the destination address is a multicast address and more than one 215 sender is sharing the same IPsec Security Association to that 216 multicast destination address, then Replay Prevention SHOULD NOT be 217 enabled. When Replay Prevention is desired for a multicast session 218 having multiple senders to the same multicast destination address, 219 each sender SHOULD have its own IPsec Security Association. 221 2.2 Authentication Data Calculation 223 The Authentication Data is the output of the MD5 authentication 224 algorithm. This value is calculated over the entire IP datagram. 225 Fields within the datagram that are variant during transit and the 226 Authentication Data field itself, must contain all zeros prior to the 227 computation [RFC-1826]. The Replay Prevention field, used or not, is 228 always included in the calculation. 230 The definition and reference implementation of MD5 appears in [RFC- 231 1321]. Let 'text' denote the data to which HMAC-MD5-96 is to be 232 applied and K be the message authentication secret key shared by the 233 parties. If K is longer than 64-bytes it MUST first be hashed using 234 MD5. In this case, K is the resulting hash. 236 We define two fixed and different strings ipad and opad as follows 237 (the 'i' and 'o' are mnemonics for inner and outer): 239 ipad = the byte 0x36 repeated 64 times 240 opad = the byte 0x5C repeated 64 times. 242 To compute HMAC-MD5 over the data `text' we perform 244 MD5(K XOR opad, MD5(K XOR ipad, text)) 246 The result of which is truncated to 96 bits (retaining the left most 247 bits) to produce HMAC-MD5-96. 249 The calculation of the Authentication Data consists of the following 250 steps: 252 (1) append zeros to the end of K to create a 64 byte string (e.g., if 253 K is of length 16 bytes it will be appended with 48 zero bytes 0x00) 254 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in 255 step (1) with ipad 256 (3) append the data stream 'text' to the 64 byte string resulting 257 from step (2) 258 (4) apply MD5 to the stream generated in step (3) 259 (5) XOR (bitwise exclusive-OR) the 64 byte string computed in 260 step (1) with opad 261 (6) append the MD5 result from step (4) to the 64 byte string 262 resulting from step (5) 263 (7) apply MD5 to the stream generated in step (6) 264 (8) use the left most 96 bits of the result obtained in (7) as the final 265 result 267 A similar computation is described in more detail, along with example 268 code and performance improvements, in [RFC-2104]. Implementers should 269 consult [RFC-2104] for more information on this technique for keying 270 a cryptographic hash function. 272 3. Security Considerations 274 The security provided by this transform is based on the strength of 275 MD5, the correctness of the algorithm's implementation, the security 276 of the key management mechanism and its implementation, the strength 277 of the associated secret key, and upon the correctness of the 278 implementations in all of the participating systems. [RFC-2104] 279 contains a detailed discussion on the strengths and weaknesses of 280 HMAC algorithms. [HMAC-TESTS] contains test vectors and example code 281 to assist in verifying the correctness of HMAC-MD5 code. 283 Acknowledgments 285 This document is largely based on text written by Hugo Krawczyk. The 286 format used was derived from work by William Simpson and Perry 287 Metzger. The text on replay prevention is derived from work by Jim 288 Hughes. 290 References 292 [RFC-1825] R. Atkinson, "Security Architecture for the Internet 293 Protocol", RFC-1852, Naval Research Laboratory, July 1995. 294 [RFC-1826] R. Atkinson, "IP Authentication Header", 295 RFC-1826, August 1995. 296 [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", 297 RFC-1828, August 1995. 298 [RFC-1321] R. Rivest, "The MD5 Message-Digest Algorithm", 299 RFC-1321, April 1992. 300 [RFC-2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing 301 for Message Authentication", RFC-2104, February, 1997. 302 [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention 303 Security Transform", Internet Draft, September 1996. 304 [HMAC-TESTS] P. Cheng, R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 305 Internet Draft, March 1997. 307 Authors' Addresses 309 Michael J. Oehler 310 National Security Agency 311 Atn: R23, INFOSEC Research and Development 312 9800 Savage Road 313 Fort Meade, MD 20755 315 mjo@tycho.ncsc.mil 317 Robert Glenn 318 NIST 319 Building 820, Room 455 320 Gaithersburg, MD 20899 322 rob.glenn@nist.gov