idnits 2.17.1 draft-ietf-ipsec-ah-hmac-sha-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-18) 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 26 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. 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 (May 1, 1996) is 10214 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 221, 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. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP-DES-MD5' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 May 1, 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 Keys........................................................3 46 1.2 Data Size...................................................4 47 2 Packet Format..................................................4 48 2.1 Replay Prevention...........................................4 49 2.2 Authentication Data Calculation.............................5 50 3. Security Considerations........................................6 51 ACKNOWLEDGMENTS....................................................6 52 REFERENCES.........................................................6 53 CONTACTS...........................................................6 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 [HMAC-MD5]. The 60 mechanism uses the (key-less) SHA hash function [FIPS-180-1] which 61 produces a message authentication code. 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 included as a transform option. The Security Parameters 68 Index (SPI) [RFC-1825] is used to determine whether this option is 69 included 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 1.1 Keys 78 The "AH Key" is used as a shared secret between two communicating 79 parties. The Key is not a "cryptographic key" as used in a 80 traditional sense. Instead, the AH key (shared secret) is hashed with 81 the transmitted data and thus, assures that an intervening party 82 cannot duplicate the authentication data. 84 Even though an AH key is not a cryptographic key, the rudimentary 85 concerns of cryptographic keys still apply. Consider that the 86 algorithm and most of the data used to produce the output is known. 87 The strength of the transform lies in the singular mapping of the key 88 (which needs to be strong) and the IP datagram (which is known) to 89 the authentication data. Thus, implementations should, and as 90 frequently as possible, change the AH key. Keys need to be chosen at 91 random, or generated using a cryptographically strong pseudo-random 92 generator seeded with a random seed. [HMAC-MD5] 94 There is no mandated key size for the HMAC-SHA transform. 95 Implementations must support a key length of any size, except zero. 96 It is advised that keys be chosen as the length of the hash output, 97 or 160-bits for SHA. For other key lengths, the following concerns 98 must be considered. 100 A key length of zero is prohibited and implementations should provide 101 an alert, since the authentication data would be identical to that of 102 SHA, solely. SHA operates on 64-byte blocks. Keys longer than 64 103 bytes are first hashed using SHA. The resulting hash is then used to 104 calculated the authentication data. 106 1.2 Data Size 108 SHA generates a message digest of 160 bits, which is automatically 109 aligned on a 32-bit word boundary. However, some implementations may 110 require 64-bit alignment of the IP headers, in which case, 32 zero 111 bits are appended as padding to the SHA output. The length of the 112 Authentication Data, specified in the Length field of the AH in 32- 113 bit words, should include the padding bits. Therefore, an 114 implementation that appends a 32-bit padding to the SHA output will 115 have a length of six 32-bit words. The padded bits are ignored at 116 the receiving end. 118 2. Packet Format 120 +---------------+---------------+---------------+---------------+ 121 | Next Header | Length | RESERVED | 122 +---------------+---------------+---------------+---------------+ 123 | SPI | 124 +---------------+---------------+---------------+---------------+ 125 | Replay Prevention (optional) | 126 +---------------+---------------+---------------+---------------+ 127 | | 128 + Authentication Data | 129 | | 130 +---------------+---------------+---------------+---------------+ 131 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 133 The Next Header, RESERVED, and SPI fields are specified in [RFC- 134 1826]. The Length field is the length of the Replay Prevention field 135 and the Authentication Data in 32-bit words. 137 2.1 Replay Prevention 139 The Replay Prevention field is a 32 bit value used to guarantee that 140 each packet exchanged between two parties is different. This field 141 is similar to the one specified in [ESP-DES-MD5]. The SPI is used to 142 determine whether or not the field is included in the packet (i.e. if 143 it is not included, the header will have the SPI directly followed by 144 the Authentication Data). Without this field it is possible to 145 attack a system by retransmitting packets. 147 The 32-bit field is an up counter starting at a value of 1. 149 The secret shared key must not be used for a period of time that 150 allows the counter to wrap, that is, to transmit more than 2^32 151 packets using a single key. 153 Upon receipt, the replay value is assured to be increasing. The 154 implementation may accept of out of order packets. The number of 155 packets to accept out of order is an implementation detail. If a "out 156 of order window" is supported, the implementation shall ensure that 157 any and all packets accepted out of order are guaranteed not to have 158 arrived before. That is, the implementation will accept any packet at 159 most once. 161 [ESP-DES-MD5] provides example code that implements a 32 packet 162 replay window and a test routine to show how it works. 164 2.2 Authentication Data Calculation 166 The computation of the 160-bit SHA digest is described 167 in [FIPS-180-1]. The digest is calculated over 168 the entire IP datagram. Fields within the datagram that are variant 169 during transit and the authentication data field itself, must contain 170 all zeros prior to the computation [RFC-1826]. 171 The Replay Prevention field, if present, is included in the calculation. 173 To compute HMAC-SHA over the data 'text', the following is calculated: 175 SHA (K XOR epad, SHA (K XOR ipad, text)) 177 where 'K' denotes the secret key shared by the parties, and 'epad', 'ipad' 178 denotes a fixed string for internal and external padding respectively. The 179 two strings are: 181 ipad = the byte 0x36 repeated 64 times, 182 epad = the byte 0x5C repeated 64 times. 184 The calculation of the authentication data consists of the following steps: 186 (1) append zeros to the end of K to create a 64 byte string (e.g., if K is 187 of length 20 bytes it will be appended with 44 zero bytes 0x00) 188 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with 189 ipad 190 (3) concatenate to the 64 byte string resulting from step (2) the data 191 stream 'text' 192 (4) apply SHA to the stream generated in step (3) 193 (5) XOR the 64 byte string computed in step (1) with epad 194 (6) concatenate to the 64 byte string resulting from step (5) the SHA result 195 of step (4) 196 (7) apply SHA to the stream generated in step (6) 197 (8) Pad to 64-bit boundary if necessary for word alignment 198 A similar computation is described in more detail, along with example 199 code and performance improvements, in [HMAC-MD5]. 200 3. Security Considerations 202 The security provided by this transform is based on the strength of 203 SHA and the associated secret key. At this time there are no known 204 cryptographic attacks against SHA [SCHNEIER]. The 160-bit digest 205 makes SHA more resistant to brute force attacks than MD4 and MD5 206 which produce a 128-bit digest. 208 Acknowledgments 210 This document is largely based on text written by Hugo Krawczyk. The 211 format used was derived from work by William Simpson and Perry Metzger. 212 The text on replay prevention is derived directly from work by Jim 213 Hughes. 215 References 217 [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol", 218 RFC-1825, August 1995. 219 [RFC-1826] R. Atkinson, "IP Authentication Header", 220 RFC-1826, August 1995. 221 [RFC-1828] P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5", 222 RFC-1828, August 1995. 223 [HMAC-MD5] H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5 224 for Message Authentication", Internet Draft, March, 1996. 225 [FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 226 [SCHNEIER] B. Schneier, "Applied Cryptography Protocols, Algorithms, and 227 Source Code in C", John Wiley & Sons, Inc. 1994. 228 [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention 229 Security Transform", Internet Draft, April, 1996. 231 Contacts 233 Shu-jen Chang 234 NIST 235 Building 820, Room 456 236 Gaithersburg, MD 20899 238 shu-jen.chang@nist.gov 240 Robert Glenn 241 NIST 242 Building 820, Room 455 243 Gaithersburg, MD 20899 244 rob.glenn@nist.gov