idnits 2.17.1 draft-ietf-ipsec-ah-hmac-sha-04.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-16) 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 29 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 80: '... Authentication Header specification [RFC-1826] SHOULD implement this...' RFC 2119 keyword, line 89: '... - MUST...' RFC 2119 keyword, line 94: '... - SHOULD...' RFC 2119 keyword, line 119: '...ant implementations MUST support a key...' RFC 2119 keyword, line 120: '... Implementations SHOULD support longer...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 85 has weird spacing: '... In this d...' == Line 86 has weird spacing: '...ficance of ea...' == Line 91 has weird spacing: '...ns that the ...' == Line 96 has weird spacing: '... means that ...' == Line 97 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 (November 20, 1996) is 10009 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 271, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 277, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC-MD5' -- 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. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP-DES-MD5' Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Chang (NIST) 3 R. Glenn (NIST) 4 November 20, 1996 5 Internet Draft 7 HMAC-SHA IP Authentication with Replay Prevention 8 10 Status of This Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as 22 reference material, or to cite them other than as a ``working draft'' 23 or ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 27 Directories on: 29 ftp.is.co.za (Africa) 30 nic.nordu.net (Europe) 31 ds.internic.net (US East Coast) 32 ftp.isi.edu (US West Coast) 33 munnari.oz.au (Pacific Rim) 35 Abstract 37 This document describes a keyed-SHA transform to be used in 38 conjunction with the IP Authentication Header [RFC-1826]. The 39 particular transform is based on [HMAC-MD5]. An option is also 40 specified to guard against replay attacks. 42 Contents 44 1. Introduction...................................................3 45 1.1 Teminology..................................................3 46 1.2 Keys........................................................4 47 1.3 Data Size...................................................4 48 2 Packet Format..................................................5 49 2.1 Replay Prevention...........................................5 50 2.2 Authentication Data Calculation.............................6 51 3. Security Considerations........................................7 52 Acnowledgements....................................................7 53 References.........................................................7 54 Authors' Addresses.................................................8 56 1. Introduction 58 The IP Authentication Header (AH) provides integrity and 59 authentication for IP datagrams [RFC-1826]. The transform specified 60 in this document uses a keyed-SHA mechanism based on [HMAC-MD5]. The 61 mechanism uses the (key-less) SHA hash function [FIPS-180-1] which 62 produces a message digest. When combined with an AH Key, 63 authentication data is produced. This value is placed in the 64 Authentication Data field of the AH [RFC-1826]. This value is also 65 the basis for the data integrity service offered by the AH protocol. 67 To provide protection against replay attacks, a Replay Prevention 68 field is included as a transform option. This field is used to help 69 prevent attacks in which a message is stored and re-used later, 70 replacing or repeating the original. The Security Parameters Index 71 (SPI) [RFC-1825] is used to determine whether this option is included 72 in the AH. 74 Familiarity with the following documents is assumed: "Security 75 Architecture for the Internet Protocol" [RFC-1825], "IP 76 Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for 77 Message Authentication" [HMAC-MD5]. 79 All implementations that claim conformance or compliance with the IP 80 Authentication Header specification [RFC-1826] SHOULD implement this 81 HMAC-SHA transform. 83 1.1 Terminology 85 In this document, the words that are used to define the 86 significance of each particular requirement are usually capitalized. 87 These words are: 89 - MUST 91 This word or the adjective "REQUIRED" means that the item is an 92 absolute requirement of the specification. 94 - SHOULD 96 This word or the adjective "RECOMMENDED" means that there might 97 exist valid reasons in particular circumstances to ignore this item, 98 but the full implications should be understood and the case carefully 99 weighed before taking a different course. 101 1.2 Keys 103 The AH Key is used as a shared secret between two communicating 104 parties. The Key is not a cryptographic key as used in a traditional 105 sense. Instead, the AH key (shared secret) is hashed with the 106 transmitted data and thus, assures that an intervening party cannot 107 duplicate the authentication data. 109 Even though an AH key is not a cryptographic key, the rudimentary 110 concerns of cryptographic keys still apply. Consider that the 111 algorithm and most of the data used to produce the output is known. 112 The strength of the transform lies in the singular mapping of the key 113 (which needs to be strong) and the IP datagram (which is known) to 114 the authentication data. Thus, implementations should, and as 115 frequently as possible, change the AH key. Keys need to be chosen at 116 random, or generated using a cryptographically strong pseudo-random 117 generator seeded with a random seed. [HMAC-MD5] 119 All conforming and compliant implementations MUST support a key 120 length of 160 bits or less. Implementations SHOULD support longer 121 key lengths as well. It is advised that the key length be chosen to 122 be the length of the hash output, which is 160 bits for SHA. For 123 other key lengths the following concerns MUST be considered. 125 A key length of zero is prohibited and implementations MUST prevent 126 key lengths of zero from being used with this transform, since no 127 effective authentication could be provided by a zero-length key. SHA 128 operates on 64-byte blocks. Keys longer than 64-bytes are first 129 hashed using SHA. The resulting hash is then used to calculate the 130 authentication data. 132 1.3 Data Size 134 SHA generates a message digest of 160 bits. To maintain 64-bit word 135 alignment, all conforming and compliant implementations MUST include 136 the ability to pad the message digest to 192 bits as described in 137 this paragraph. Implementations MAY also include the ability to use 138 the 160 bit message digest without the pad when 64-bit alignment is 139 not required. Padding is added by appending 32 zero bits to SHA 140 message digest. The length of the Authentication Data, specified in 141 the Length field of the AH in 32-bit words, should include the 142 padding bits, if present. Upon receipt, the value of the padded bits 143 MUST be zero and are otherwise ignored. 145 2. Packet Format 147 +---------------+---------------+---------------+---------------+ 148 | Next Header | Length | RESERVED | 149 +---------------+---------------+---------------+---------------+ 150 | SPI | 151 +---------------+---------------+---------------+---------------+ 152 | Replay Prevention | 153 | | 154 +---------------+---------------+---------------+---------------+ 155 | | 156 + Authentication Data | 157 | | 158 +---------------+---------------+---------------+---------------+ 159 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 161 The Next Header, RESERVED, and SPI fields are specified in [RFC- 162 1826]. The Length field is the length of the Replay Prevention field 163 and the Authentication Data in 32-bit words. 165 2.1 Replay Prevention 167 The Replay Prevention field is a 64-bit value used to guarantee that 168 each packet exchanged between two parties is different. Each IPsec 169 Security Association specifies whether Replay Prevention is used for 170 that Security Association. If Replay Prevention is NOT in use, then 171 the Authentication Data field will directly follow the SPI field. 172 This field is used to help prevent attacks in which a message is 173 stored and re-used later, replacing or repeating the original. 175 The 64-bit field is an up counter starting at a value of 1. 177 The secret shared key must not be used for a period of time that 178 allows the counter to wrap, that is, to transmit more than 2^64 179 packets using a single key. 181 Upon receipt, the replay value is assured to be increasing. The 182 implementation may accept out of order packets. The number of packets 183 to accept out of order is an implementation detail. If an "out of 184 order window" is supported, the implementation shall ensure that any 185 and all packets accepted out of order are guaranteed not to have 186 arrived before. That is, the implementation will accept any packet at 187 most once. 189 When the destination address is a multicast address, replay 190 protection is in use, and more than one sender is sharing the same 191 IPsec Security Association to that multicast destination address, 192 then Replay Protection SHOULD NOT be enabled. When replay protection 193 is desired for a multicast session having multiple senders to the 194 same multicast destination address, each sender SHOULD have its own 195 IPsec Security Association. 197 [ESP-DES-MD5] provides example code that implements a 32 packet 198 replay window and a test routine to show how it works. 200 2.2 Authentication Data Calculation 202 The computation of the 160-bit SHA digest is described 203 in [FIPS-180-1]. The digest is calculated over 204 the entire IP datagram. Fields within the datagram that are variant 205 during transit and the authentication data field itself must contain 206 all zeros prior to the computation [RFC-1826]. 207 The Replay Prevention field, if present, is included in the calculation. 209 To compute HMAC-SHA over the data 'text', the following is calculated: 211 SHA (K XOR opad, SHA (K XOR ipad, text)) 213 K denotes the secret key shared by the parties. If K is longer 214 than 64-bytes it MUST first be hashed using SHA. 215 In this case, K is the resulting hash. The variables 'ipad', 'opad' 216 denote fixed strings for inner and outer padding respectively. 217 The two strings are: 219 ipad = the byte 0x36 repeated 64 times, 220 opad = the byte 0x5C repeated 64 times. 222 The calculation of the authentication data consists of the following steps: 224 (1) append zeros to the end of K to create a 64 byte string (e.g., if K is 225 of length 20 bytes it will be appended with 44 zero bytes 0x00) 226 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with 227 ipad 228 (3) concatenate to the 64 byte string resulting from step (2) the data 229 stream 'text' 230 (4) apply SHA to the stream generated in step (3) 231 (5) XOR the 64 byte string computed in step (1) with opad 232 (6) concatenate to the 64 byte string resulting from step (5) the SHA result 233 of step (4) 234 (7) apply SHA to the stream generated in step (6) 235 (8) The sender then zero pads the resulting hash to a 64-bit boundary 236 for word alignment. IPv4 implemenations choosing not to pad will not 237 zero pad the resulting hash. The receiver then compares the 238 generated 160-bit hash to the first 160-bits of authentication data 239 contained in the AH. 241 A similar computation is described in more detail, along with example 242 code and performance improvements, in [HMAC-MD5]. Implementers 243 should consult [HMAC-MD5] for more information on this technique 244 for keying a cryptographic hash function. 246 3. Security Considerations 248 The security provided by this transform is based on the strength of 249 SHA, the correctness of the algorithm's implementation, the security 250 of the key management mechanism and its implementation, the strength 251 of the associated secret key, and upon the correctness of the 252 implementations in all of the participating systems. 254 At this time there are no known cryptographic attacks against SHA 255 [SCHNEIER]. The 160-bit digest makes SHA more resistant to brute 256 force attacks than MD4 and MD5 which produce a 128-bit digest. 258 Acknowledgments 260 This document is largely based on text written by Hugo Krawczyk. The 261 format used was derived from work by William Simpson and Perry Metzger. 262 The text on replay prevention is derived directly from work by Jim 263 Hughes. 265 References 267 [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol", 268 RFC-1825, August 1995. 269 [RFC-1826] R. Atkinson, "IP Authentication Header", 270 RFC-1826, August 1995. 271 [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", 272 RFC-1828, August 1995. 273 [HMAC-MD5] H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5 274 for Message Authentication", Internet Draft, March, 1996. 275 [FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 276 [URL] http://csrc.nist.gov/fips/fip180-1.txt (ascii) 277 [URL] http://csrc.nist.gov/fips/fip180-1.ps (postscript) 278 [SCHNEIER] B. Schneier, "Applied Cryptography Protocols, Algorithms, and 279 Source Code in C", John Wiley & Sons, Inc. 1994. 280 [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention 281 Security Transform", Internet Draft, April, 1996. 283 Authors' Addresses 285 Shu-jen Chang 286 NIST 287 Building 820, Room 456 288 Gaithersburg, MD 20899 290 shu-jen.chang@nist.gov 292 Robert Glenn 293 NIST 294 Building 820, Room 455 295 Gaithersburg, MD 20899 297 rob.glenn@nist.gov