idnits 2.17.1 draft-ietf-ipsec-ah-hmac-md5-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 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([HMAC-MD5], [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 77: '... Authentication Header specification [RFC-1826] MUST implement this...' RFC 2119 keyword, line 98: '...ant implementations MUST support a key...' RFC 2119 keyword, line 99: '... Implementations SHOULD support longer...' RFC 2119 keyword, line 102: '...following concerns MUST be considered....' RFC 2119 keyword, line 104: '...bited and implementations MUST prevent...' (1 more instance...) 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 (August 30, 1996) is 10073 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 234, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC-MD5' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP-DES-MD5' Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Oehler (NSA) 2 R. Glenn (NIST) 3 Internet Draft August 30, 1996 5 HMAC-MD5 IP Authentication with Replay Prevention 6 8 Status of This Memo 10 Distribution of this memo is unlimited. 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a ``working draft'' 21 or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 25 Directories on: 27 ftp.is.co.za (Africa) 28 nic.nordu.net (Europe) 29 ds.internic.net (US East Coast) 30 ftp.isi.edu (US West Coast) 31 munnari.oz.au (Pacific Rim) 33 Abstract 35 This document describes a keyed-MD5 transform to be used in 36 conjunction with the IP Authentication Header [RFC-1826]. The 37 particular transform is based on [HMAC-MD5]. An option is also 38 specified to guard against replay attacks. 40 Contents 42 1. Introduction...................................................3 43 1.1 Keys........................................................3 44 1.2 Data Size...................................................4 45 2. Packet Format..................................................4 46 2.1 Replay Prevention...........................................4 47 2.2 Authentication Data Calculation.............................5 48 3. Security Considerations........................................6 49 ACKNOWLEDGMENTS....................................................6 50 REFERENCES.........................................................6 51 CONTACTS...........................................................6 53 1. Introduction 55 The Authentication Header (AH) [RFC-1826] provides integrity and 56 authentication for IP datagrams. The transform specified in this 57 document uses a keyed-MD5 mechanism [HMAC-MD5]. The mechanism uses 58 the (key-less) MD5 hash function [RFC-1321] which produces a message 59 digest. When combined with an AH Key, authentication data is 60 produced. This value is placed in the Authentication Data field of 61 the AH [RFC-1826]. This value is also the basis for the data 62 integrity service offered by the AH protocol. 64 To provide protection against replay attacks, a Replay Prevention 65 field is included as a transform option. This field is used to help 66 prevent attacks in which a message is stored and re-used later, 67 replacing or repeating the original. The Security Parameters Index 68 (SPI) [RFC-1825] is used to determine whether this option is included 69 in the AH. 71 Familiarity with the following documents is assumed: "Security 72 Architecture for the Internet Protocol" [RFC-1825], "IP 73 Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for 74 Message Authentication" [HMAC-MD5]. 76 All implementations that claim conformance or compliance with the IP 77 Authentication Header specification [RFC-1826] MUST implement this 78 HMAC-MD5 transform. 80 1.1 Keys 82 The "AH Key" is used as a shared secret between two communicating 83 parties. The Key is not a "cryptographic key" as used in a 84 traditional sense. Instead, the AH key (shared secret) is hashed with 85 the transmitted data and thus, assures that an intervening party 86 cannot duplicate the authentication data. 88 Even though an AH key is not a cryptographic key, the rudimentary 89 concerns of cryptographic keys still apply. Consider that the 90 algorithm and most of the data used to produce the output is known. 91 The strength of the transform lies in the singular mapping of the key 92 (which needs to be strong) and the IP datagram (which is known) to 93 the authentication data. Thus, implementations should, and as 94 frequently as possible, change the AH key. Keys need to be chosen at 95 random, or generated using a cryptographically strong pseudo-random 96 generator seeded with a random seed. [HMAC-MD5] 98 All conforming and compliant implementations MUST support a key 99 length of 128 bits or less. Implementations SHOULD support longer 100 key lengths as well. It is advised that the key length be chosen to 101 be the length of the hash output, which is 128 bits for MD5. For 102 other key lengths the following concerns MUST be considered. 104 A key length of zero is prohibited and implementations MUST prevent 105 key lengths of zero from being used with this transform, since no 106 effective authentication could be provided by a zero-length key. 107 Keys having a length less than 128 bits are strongly discouraged as 108 it would decrease the security strength of the function. Keys longer 109 than 128 bits are acceptable, but the extra length may not 110 significantly increase the function strength. A longer key may be 111 advisable if the randomness of the key is suspect. MD5 operates on 112 64-byte blocks. Keys longer than 64-bytes are first hashed using 113 MD5. The resulting hash is then used to calculate the authentication 114 data. 116 1.2 Data Size 118 MD5 produces a 128-bit value which is used as the authentication 119 data. It is naturally 64 bit aligned and thus, does not need any 120 padding for machines with native double words. 122 2. Packet Format 124 +---------------+---------------+---------------+---------------+ 125 | Next Header | Length | RESERVED | 126 +---------------+---------------+---------------+---------------+ 127 | SPI | 128 +---------------+---------------+---------------+---------------+ 129 | Replay Prevention | 130 | | 131 +---------------+---------------+---------------+---------------+ 132 | | 133 + Authentication Data | 134 | | 135 +---------------+---------------+---------------+---------------+ 136 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 138 The Next Header, RESERVED, and SPI fields are specified in [RFC- 139 1826]. The Length field is the length of the Replay Prevention field 140 and the Authentication Data in 32-bit words. 142 2.1 Replay Prevention 144 The Replay Prevention field is a 64-bit value used to guarantee that 145 each packet exchanged between two parties is different. This field 146 is similar to the one specified in [ESP-DES-MD5]. Each IPsec 147 Security Association specifies whether Replay Prevention is used for 148 that Security Association. If Replay Prevention is NOT in use, then 149 the Authentication Data field will directly follow the SPI field. 151 The 64-bit field is an up counter starting at a value of 1. 153 The secret shared key must not be used for a period of time that 154 allows the counter to wrap, that is, to transmit more than 2^64 155 packets using a single key. 157 Upon receipt, the replay value is assured to be increasing. The 158 implementation may accept out of order packets. The number of packets 159 to accept out of order is an implementation detail. If an "out of 160 order window" is supported, the implementation shall ensure that any 161 and all packets accepted out of order are guaranteed not to have 162 arrived before. That is, the implementation will accept any packet at 163 most once. 165 [ESP-DES-MD5] provides example code that implements a 32 packet 166 replay window and a test routine to show how it works. 168 2.2 Authentication Data Calculation 170 The authentication data is the output of the authentication algorithm 171 (MD5). This value is calculated over the entire IP datagram. Fields 172 within the datagram that are variant during transit and the 173 authentication data field itself, must contain all zeros prior to the 174 computation [RFC-1826]. The Replay Prevention field if present, is 175 included in the calculation. 177 The definition and reference implementation of MD5 appears in [RFC- 178 1321]. Let 'text' denote the data to which HMAC-MD5 is to be applied 179 and K be the message authentication secret key shared by the parties. 180 If K is longer than 64-bytes it MUST first be hashed using MD5. In 181 this case, K is the resulting hash. 183 We define two fixed and different strings ipad and opad as follows 184 (the 'i' and 'o' are mnemonics for inner and outer): 185 ipad = the byte 0x36 repeated 64 times 186 opad = the byte 0x5C repeated 64 times. 187 To compute HMAC-MD5 over the data `text' we perform 188 MD5(K XOR opad, MD5(K XOR ipad, text)) 189 Namely, 190 (1) append zeros to the end of K to create a 64 byte string 191 (e.g., if K is of length 16 bytes it will be appended with 48 192 zero bytes 0x00) 193 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step 194 (1) with ipad 195 (3) append the data stream 'text' to the 64 byte string resulting 196 from step (2) 198 (4) apply MD5 to the stream generated in step (3) 199 (5) XOR (bitwise exclusive-OR) the 64 byte string computed in 200 step (1) with opad 201 (6) append the MD5 result from step (4) to the 64 byte string 202 resulting from step (5) 203 (7) apply MD5 to the stream generated in step (6) and output 204 the result 206 This computation is described in more detail, along with example 207 code and performance improvements, in [HMAC-MD5]. Implementers 208 should consult [HMAC-MD5] for more information on this technique 209 for keying a cryptographic hash function. 211 3. Security Considerations 213 The security provided by this transform is based on the strength of 214 MD5, the correctness of the algorithm's implementation, the security 215 of the key management mechanism and its implementation, the strength 216 of the associated secret key, and upon the correctness of the 217 implementations in all of the participating systems. [HMAC-MD5] 218 contains a detailed discussion on the strengths and weaknesses of 219 MD5. 221 Acknowledgments 223 This document is largely based on text written by Hugo Krawczyk. The 224 format used was derived from work by William Simpson and Perry 225 Metzger. The text on replay prevention is derived directly from work 226 by Jim Hughes. 228 References 230 [RFC-1825] R. Atkinson, "Security Architecture for the Internet 231 Protocol", RFC-1852, Naval Research Laboratory, July 1995. 232 [RFC-1826] R. Atkinson, "IP Authentication Header", 233 RFC-1826, August 1995. 234 [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", 235 RFC-1828, August 1995. 236 [RFC-1321] R. Rivest, "The MD5 Message-Digest Algorithm", 237 RFC-1321, April 1992. 238 [HMAC-MD5] H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5 239 for Message Authentication", Internet Draft, March, 1996. 240 [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention 241 Security Transform", Internet Draft, April, 1996. 243 Contacts 245 Michael J. Oehler 246 National Security Agency 247 Atn: R23, INFOSEC Research and Development 248 9800 Savage Road 249 Fort Meade, MD 20755 251 mjo@tycho.ncsc.mil 253 Robert Glenn 254 NIST 255 Building 820, Room 455 256 Gaithersburg, MD 20899 258 rob.glenn@nist.gov