idnits 2.17.1 draft-kelly-ipsec-ciph-sha2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 846. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 152: '...e hash functions MUST be supported, an...' RFC 2119 keyword, line 154: '... MUST NOT be supported....' RFC 2119 keyword, line 196: '... function MUST be used to generate t...' RFC 2119 keyword, line 248: '...m output size -- MUST be supported. N...' RFC 2119 keyword, line 785: '... 2001 MAY,...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 5, 2007) is 6320 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) == Missing Reference: 'TBA-1' is mentioned on line 725, but not defined == Missing Reference: 'TBA-2' is mentioned on line 727, but not defined == Missing Reference: 'TBA-3' is mentioned on line 729, but not defined == Missing Reference: 'TBA-4' is mentioned on line 736, but not defined == Missing Reference: 'TBA-5' is mentioned on line 738, but not defined == Missing Reference: 'TBA-6' is mentioned on line 740, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2-2' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kelly 3 Internet-Draft Aruba Networks 4 Intended status: Standards Track S. Frankel 5 Expires: July 9, 2007 NIST 6 January 5, 2007 8 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec 9 draft-kelly-ipsec-ciph-sha2-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 9, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 40 Abstract 42 This specification describes the use of HMAC in conjunction with the 43 SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms 44 may be used as the basis for data origin authentication and integrity 45 verification mechanisms for the AH, ESP, IKE and IKEv2 protocols, and 46 also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated 47 output lengths are specified for the authentication-related variants, 48 with the corresponding algorithms designated as HMAC-SHA-256-128, 49 HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not 50 truncated, and are called HMAC-SHA-PRF-256, HMAC-SHA-PRF-384, and 51 HMAC-SHA-PRF-512. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. The HMAC-SHA-256+ Algorithms . . . . . . . . . . . . . . . . . 3 57 2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3 58 2.1.1. Data Origin Authentication and Integrity 59 Verification Usage . . . . . . . . . . . . . . . . . . 4 60 2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4 61 2.1.3. Randomness and Key Strength . . . . . . . . . . . . . 5 62 2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . . 5 63 2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . . 5 64 2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Using HMAC-SHA-256+ As PRFs in IKE and IKEv2 . . . . . . . 6 67 2.5. Interactions with the ESP, IKE, or IKEv2 Cipher 68 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.6. HMAC-SHA-256+ Parameter Summary . . . . . . . . . . . . . 7 70 2.7. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.7.1. PRF Test Vectors . . . . . . . . . . . . . . . . . . . 7 72 2.7.2. Authenticator Test Vectors . . . . . . . . . . . . . . 11 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 3.1. HMAC Key Length vs Truncation Length . . . . . . . . . . . 17 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 77 6. Normative References . . . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 79 Intellectual Property and Copyright Statements . . . . . . . . . . 21 81 1. Introduction 83 This document specifies the use of SHA-256, SHA-384, and SHA-512 84 [SHA2-1] combined with HMAC [HMAC] as data origin authentication and 85 integrity verification mechanisms for the IPsec AH [AH], ESP [ESP], 86 IKE [IKE], and IKEv2 [IKEv2] protocols. Output truncation is 87 specified for these variants, with the corresponding algorithms 88 designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512- 89 256. These truncation lengths are chosen in accordance with the 90 birthday bound for each algorithm. 92 This specification also describes untruncated variants of these 93 algorithms as PRFs for use with IKE and IKEv2, and those algorithms 94 are called HMAC-SHA-PRF-256, HMAC-SHA-PRF-384, and HMAC-SHA-PRF-512. 95 For ease of reference, these PRF algorithms and the authentication 96 variants described above are collectively referred to below as "the 97 HMAC-SHA-256+ algorithms." 99 The goal of the PRF variants is to provide secure pseudo-random 100 functions suitable for generation of keying material and other 101 protocol-specific numeric quantities, while the goal of the 102 authentication variants is to ensure that packets are authentic and 103 cannot be modified in transit. The relative security of HMAC-SHA- 104 256+ when used in either case is dependent on the distribution scope 105 and unpredictability of the associated secret key. If the key is 106 unpredictable and known only by the sender and recipient, these 107 algorithms ensure that only parties holding an identical key can 108 derive the associated values. 110 2. The HMAC-SHA-256+ Algorithms 112 [SHA2-1] and [SHA2-2] describe the underlying SHA-256, SHA-384, and 113 SHA-512 algorithms, while [HMAC] describes the HMAC algorithm. The 114 HMAC algorithm provides a framework for inserting various hashing 115 algorithms such as SHA-256, and [SHA256+] describes combined usage of 116 these algorithms. The following sections describe the various 117 characteristics and requirements of the HMAC-SHA-256+ algorithms when 118 used with IPsec. 120 2.1. Keying Material 122 Requirements for keying material vary depending on whether the 123 algorithm is functioning as a PRF or as an authentication/integrity 124 mechanism. In the case of authentication/integrity, key lengths are 125 fixed according to the output length of the algorithm in use. In the 126 case of PRFs, key lengths are variable, but guidance is given to 127 ensure interoperability. These distinctions are described further 128 below. 130 Before describing key requirements for each usage, it is important to 131 clarify some terms we use below: 133 Block size: the size of the data block the underlying hash algorithm 134 operates upon; for SHA-256, this is 512 bits. For SHA-384 and 135 SHA-512, this is 1024 bits. 137 Output length: the size of the hash value produced by the underlying 138 hash algorithm. For SHA-256, this is 256 bits, for SHA-384 this 139 is 384 bits, and for SHA-512, this is 512 bits. 141 Authenticator length: the size of the "authenticator" in bits. This 142 only applies to authentication/integrity related algorithms, and 143 refers to the bit length remaining after truncation. In this 144 specification, this is always half the output length of the 145 underlying hash algorithm. 147 2.1.1. Data Origin Authentication and Integrity Verification Usage 149 HMAC-SHA-256+ are secret key algorithms. While no fixed key length 150 is specified in [HMAC], this specification requires that when used as 151 an integrity/authentication algorithm, a fixed key length equal to 152 the output length of the hash functions MUST be supported, and key 153 lengths other than the output length of the associated hash function 154 MUST NOT be supported. 156 These key length restrictions are based in part on the 157 recommendations in [HMAC] (key lengths less than the output length 158 decrease security strength, and keys longer than the output length do 159 not significantly increase security strength), and in part because 160 allowing variable length keys for IPsec authenticator functions would 161 create interoperability issues. 163 2.1.2. Pseudo-Random Function (PRF) Usage 165 IKE and IKEv2 use PRFs for generating keying material and for 166 authentication of the IKE_SA. The IKEv2 specification differentiates 167 between PRFs with fixed key sizes and those with variable key sizes, 168 and so we give some special guidance for this below. 170 When a PRF described in this document is used with IKE or IKEv2, it 171 is considered to have a variable key length, and keys are derived in 172 the following ways (note that we simply reiterate that which is 173 specified in [HMAC]): 175 o If the length of the key is exactly the algorithm block size, use 176 it as-is. 178 o If the key is shorter than the block size, lengthen it to exactly 179 the block size by padding it on the right with zero bits. 180 However, note that [HMAC] strongly discourages a key length less 181 than the output length. Nonetheless, we describe handling of 182 shorter lengths here in recognition of shorter lengths typically 183 chosen for IKE or IKEv2 preshared keys. 185 o If the key is longer than the block size, shorten it by computing 186 the corresponding hash algorithm output over the entire key value, 187 and treat the resulting output value as your HMAC key. Note that 188 this will always result in a key that is less than the block size 189 in length, and this key value will therefore require 0-padding (as 190 described above) prior to use. 192 2.1.3. Randomness and Key Strength 194 [HMAC] discusses requirements for key material, including a 195 requirement for strong randomness. Therefore, a strong pseudo-random 196 function MUST be used to generate the required key for use with HMAC- 197 SHA-256+. At the time of this writing there are no published weak 198 keys for use with any HMAC-SHA-256+ algorithms. 200 2.1.4. Key Distribution 202 [ARCH] describes the general mechanism for obtaining keying material 203 when multiple keys are required for a single SA (e.g. when an ESP SA 204 requires a key for confidentiality and a key for authentication). In 205 order to provide data origin authentication and integrity 206 verification, the key distribution mechanism must ensure that unique 207 keys are allocated and that they are distributed only to the parties 208 participating in the communication. 210 2.1.5. Refreshing Keys 212 There are no currently practical attacks against the algorithms 213 recommended here, and especially against the key sizes recommended 214 here. However, as noted in [HMAC] "...periodic key refreshment is a 215 fundamental security practice that helps against potential weaknesses 216 of the function and keys, and limits the damage of an exposed key." 218 Putting this into perspective, this specification requires 256, 384, 219 or 512-bit keys produced by a strong PRF for use as a MAC. A brute 220 force attack on such keys would take longer to mount than the 221 universe has been in existence. On the other hand, weak keys (e.g. 222 dictionary words) would be dramatically less resistant to attack. It 223 is important to take these points, along with the specific threat 224 model for your particular application and the current state of the 225 art with respect to attacks on SHA-256, SHA-384, and SHA-512 into 226 account when determining an appropriate upper bound for HMAC key 227 lifetimes 229 2.2. Padding 231 The HMAC-SHA-256 algorithms operate on 512-bit blocks of data, while 232 the HMAC-SHA-384 and HMAC-SHA-512 algorithms operate on 1024-bit 233 blocks of data. Padding requirements are specified in [SHA2-1] as 234 part of the underlying SHA-256, SHA-384, and SHA-512 algorithms, so 235 if you implement according to [SHA2-1], you do not need to add any 236 additional padding as far as the HMAC-SHA-256+ algorithms specified 237 here are concerned. With regard to "implicit packet padding" as 238 defined in [AH], no implicit packet padding is required. 240 2.3. Truncation 242 The HMAC-SHA-256+ algorithms each produce a nnn-bit value, where nnn 243 corresponds to the output bit length of the algorithm, e.g. HMAC- 244 SHA-nnn. For use as an authenticator, this nnn-bit value can be 245 truncated as described in [HMAC]. When used as a data origin 246 authentication and integrity verification algorithm in ESP, AH, IKE, 247 or IKEv2, a truncated value using the first nnn/2 bits -- exactly 248 half the algorithm output size -- MUST be supported. No other 249 authenticator value lengths are supported by this specification. 251 Upon sending, the truncated value is stored within the authenticator 252 field. Upon receipt, the entire nnn-bit value is computed and the 253 first nnn/2 bits are compared to the value stored in the 254 authenticator field, with the value of 'nnn' depending on the 255 negotiated algorithm. 257 [HMAC] discusses potential security benefits resulting from 258 truncation of the output MAC value, and in general, encourages HMAC 259 users to perform MAC truncation. In the context of IPsec, a 260 truncation length of nnn/2 bits is selected because it corresponds to 261 the birthday attack bound for each of the HMAC-SHA-256+ algorithms, 262 and it simultaneously serves to minimize the additional bits on the 263 wire resulting from use of this facility. 265 2.4. Using HMAC-SHA-256+ As PRFs in IKE and IKEv2 267 The HMAC-SHA-PRF-256 algorithm is identical to HMAC-SHA-256-128, 268 except that variable-length keys are permitted, and the truncation 269 step is NOT performed. Likewise, the implementations of HMAC-SHA- 270 PRF-384 and HMAC-SHA-PRF-512 are identical to those of HMAC-SHA-384- 271 192 and HMAC-SHA-512-256 respectively, except that again, truncation 272 is NOT performed. 274 2.5. Interactions with the ESP, IKE, or IKEv2 Cipher Mechanisms 276 As of this writing, there are no known issues which preclude the use 277 of the HMAC-SHA-256+ algorithms with any specific cipher algorithm. 279 2.6. HMAC-SHA-256+ Parameter Summary 281 The following table serves to summarize the various quantities 282 associated with the HMAC-SHA-256+ algorithms. 284 +------------------+--------+--------+--------+----------+------------+ 285 | Algorithm | Block | Output | Trunc. | Key | Algorithm | 286 | ID | Size | Length | Length | Length | Type | 287 +==================+========+========+========+==========+============+ 288 | HMAC-SHA-256-128 | 512 | 256 | 128 | 256 | auth/integ | 289 +------------------+--------+--------+--------+----------+------------+ 290 | HMAC-SHA-384-192 | 1024 | 384 | 192 | 384 | auth/integ | 291 +------------------+--------+--------+--------+----------+------------+ 292 | HMAC-SHA-512-256 | 1024 | 512 | 256 | 512 | auth/integ | 293 +------------------+--------+--------+--------+----------+------------+ 294 | HMAC-SHA-256-PRF | 512 | 256 | (none) | variable | PRF | 295 +------------------+--------+--------+--------+----------+------------+ 296 | HMAC-SHA-384-PRF | 1024 | 384 | (none) | variable | PRF | 297 +------------------+--------+--------+--------+----------+------------+ 298 | HMAC-SHA-512-PRF | 1024 | 512 | (none) | variable | PRF | 299 +------------------+--------+--------+--------+----------+------------+ 301 2.7. Test Vectors 303 The following test cases include the key, the data, and the resulting 304 authenticator and/or PRF values for each algorithm. The values of 305 keys and data are either ASCII character strings (surrounded by 306 double quotes) or hexadecimal numbers. If a value is an ASCII 307 character string, then the HMAC computation for the corresponding 308 test case DOES NOT include the trailing null character ('\0') of the 309 string. The computed HMAC values are all hexadecimal numbers. 311 2.7.1. PRF Test Vectors 313 These test cases were borrowed from RFC 4231 [HMAC-TEST]. For 314 reference implementations of the underlying hash algorithms, see 315 [SHA256+]. Note that for testing purposes, PRF output is considered 316 to be simply the untruncated algorithm output. 318 Test Case PRF-1: 319 Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 320 0b0b0b0b (20 bytes) 322 Data = 4869205468657265 ("Hi There") 324 HMAC-SHA-256-PRF = b0344c61d8db38535ca8afceaf0bf12b 325 881dc200c9833da726e9376c2e32cff7 327 HMAC-SHA-384-PRF = afd03944d84895626b0825f4ab46907f 328 15f9dadbe4101ec682aa034c7cebc59c 329 faea9ea9076ede7f4af152e8b2fa9cb6 331 HMAC-SHA-512-PRF = 87aa7cdea5ef619d4ff0b4241a1d6cb0 332 2379f4e2ce4ec2787ad0b30545e17cde 333 daa833b7d6b8a702038b274eaea3f4e4 334 be9d914eeb61f1702e696c203a126854 336 Test Case PRF-2: 337 Key = 4a656665 ("Jefe") 339 Data = 7768617420646f2079612077616e7420 ("what do ya want ") 340 666f72206e6f7468696e673f ("for nothing?") 342 HMAC-SHA-256-PRF = 5bdcc146bf60754e6a042426089575c7 343 5a003f089d2739839dec58b964ec3843 345 HMAC-SHA-384-PRF = af45d2e376484031617f78d2b58a6b1b 346 9c7ef464f5a01b47e42ec3736322445e 347 8e2240ca5e69e2c78b3239ecfab21649 349 HMAC-SHA-512-PRF = 164b7a7bfcf819e2e395fbe73b56e0a3 350 87bd64222e831fd610270cd7ea250554 351 9758bf75c05a994a6d034f65f8f0e6fd 352 caeab1a34d4a6b4b636e070a38bce737 354 Test Case PRF-3: 355 Key aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 356 aaaaaaaa (20 bytes) 358 Data = dddddddddddddddddddddddddddddddd 359 dddddddddddddddddddddddddddddddd 360 dddddddddddddddddddddddddddddddd 361 dddd (50 bytes) 363 HMAC-SHA-256-PRF = 773ea91e36800e46854db8ebd09181a7 364 2959098b3ef8c122d9635514ced565fe 366 HMAC-SHA-384-PRF = 88062608d3e6ad8a0aa2ace014c8a86f 367 0aa635d947ac9febe83ef4e55966144b 368 2a5ab39dc13814b94e3ab6e101a34f27 370 HMAC-SHA-512-PRF = fa73b0089d56a284efb0f0756c890be9 371 b1b5dbdd8ee81a3655f83e33b2279d39 372 bf3e848279a722c806b485a47e67c807 373 b946a337bee8942674278859e13292fb 375 Test Case PRF-4: 376 Key = 0102030405060708090a0b0c0d0e0f10 377 111213141516171819 (25 bytes) 379 Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 380 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 381 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 382 cdcd (50 bytes) 384 HMAC-SHA-256-PRF = 82558a389a443c0ea4cc819899f2083a 385 85f0faa3e578f8077a2e3ff46729665b 387 HMAC-SHA-384-PRF = 3e8a69b7783c25851933ab6290af6ca7 388 7a9981480850009cc5577c6e1f573b4e 389 6801dd23c4a7d679ccf8a386c674cffb 391 HMAC-SHA-512-PRF = b0ba465637458c6990e5a8c5f61d4af7 392 e576d97ff94b872de76f8050361ee3db 393 a91ca5c11aa25eb4d679275cc5788063 394 a5f19741120c4f2de2adebeb10a298dd 396 Test Case PRF-5: 397 Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 398 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 399 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 400 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 401 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 402 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 403 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 404 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 405 aaaaaa (131 bytes) 407 Data = 54657374205573696e67204c61726765 ("Test Using Large") 408 72205468616e20426c6f636b2d53697a ("r Than Block-Siz") 409 65204b6579202d2048617368204b6579 ("e Key - Hash Key") 410 204669727374 (" First") 412 HMAC-SHA-256-PRF = 60e431591ee0b67f0d8a26aacbf5b77f 413 8e0bc6213728c5140546040f0ee37f54 415 HMAC-SHA-384-PRF = 4ece084485813e9088d2c63a041bc5b4 416 4f9ef1012a2b588f3cd11f05033ac4c6 417 0c2ef6ab4030fe8296248df163f44952 419 HMAC-SHA-512-PRF = 80b24263c7c1a3ebb71493c1dd7be8b4 420 9b46d1f41b4aeec1121b013783f8f352 421 6b56d037e05f2598bd0fd2215d6a1e52 422 95e64f73f63f0aec8b915a985d786598 424 Test Case PRF-6: 426 Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 427 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 428 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 429 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 430 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 431 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 432 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 433 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 434 aaaaaa (131 bytes) 436 Data = 54686973206973206120746573742075 ("This is a test u") 437 73696e672061206c6172676572207468 ("sing a larger th") 438 616e20626c6f636b2d73697a65206b65 ("an block-size ke") 439 7920616e642061206c61726765722074 ("y and a larger t") 440 68616e20626c6f636b2d73697a652064 ("han block-size d") 441 6174612e20546865206b6579206e6565 ("ata. The key nee") 442 647320746f2062652068617368656420 ("ds to be hashed ") 443 6265666f7265206265696e6720757365 ("before being use") 444 642062792074686520484d414320616c ("d by the HMAC al") 445 676f726974686d2e ("gorithm.") 447 HMAC-SHA-256-PRF = 9b09ffa71b942fcb27635fbcd5b0e944 448 bfdc63644f0713938a7f51535c3a35e2 450 HMAC-SHA-384-PRF = 6617178e941f020d351e2f254e8fd32c 451 602420feb0b8fb9adccebb82461e99c5 452 a678cc31e799176d3860e6110c46523e 454 HMAC-SHA-512-PRF = e37b6a775dc87dbaa4dfa9f96e5e3ffd 455 debd71f8867289865df5a32d20cdc944 456 b6022cac3c4982b10d5eeb55c3e4de15 457 134676fb6de0446065c97440fa8c6a58 459 2.7.2. Authenticator Test Vectors 461 In the following sections are test cases for HMAC-SHA256-128, HMAC- 462 SHA384-192, and HMAC-SHA512-256. PRF outputs are also included for 463 convenience. These test cases were generated using the SHA256+ 464 reference code provided in [SHA256+]. 466 2.7.2.1. SHA256 Authentication Test Vectors 467 Test Case AUTH256-1: 468 Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 469 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (32 bytes) 471 Data = 4869205468657265 ("Hi There") 473 HMAC-SHA-256-PRF = 198a607eb44bfbc69903a0f1cf2bbdc5 474 ba0aa3f3d9ae3c1c7a3b1696a0b68cf7 476 HMAC-SHA-256-128 = 198a607eb44bfbc69903a0f1cf2bbdc5 478 Test Case AUTH256-2: 479 Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 480 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 482 Data = 7768617420646f2079612077616e7420 ("what do ya want ") 483 666f72206e6f7468696e673f ("for nothing?") 485 HMAC-SHA-256-PRF = 167f928588c5cc2eef8e3093caa0e87c 486 9ff566a14794aa61648d81621a2a40c6 488 HMAC-SHA-256-128 = 167f928588c5cc2eef8e3093caa0e87c 490 Test Case AUTH256-3: 491 Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 492 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (32 bytes) 494 Data = dddddddddddddddddddddddddddddddd 495 dddddddddddddddddddddddddddddddd 496 dddddddddddddddddddddddddddddddd 497 dddd (50 bytes) 499 HMAC-SHA-256-PRF = cdcb1220d1ecccea91e53aba3092f962 500 e549fe6ce9ed7fdc43191fbde45c30b0 502 HMAC-SHA-256-128 = cdcb1220d1ecccea91e53aba3092f962 503 Test Case AUTH256-4: 504 Key = 0102030405060708090a0b0c0d0e0f10 505 1112131415161718191a1b1c1d1e1f20 (32 bytes) 507 Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 508 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 509 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 510 cdcd (50 bytes) 512 HMAC-SHA-256-PRF = 372efcf9b40b35c2115b1346903d2ef4 513 2fced46f0846e7257bb156d3d7b30d3f 515 HMAC-SHA-256-128 = 372efcf9b40b35c2115b1346903d2ef4 517 2.7.2.2. SHA384 Authentication Test Vectors 519 Test Case AUTH384-1: 520 Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 521 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 522 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (48 bytes) 524 Data = 4869205468657265 ("Hi There") 526 HMAC-SHA-384-PRF = b6a8d5636f5c6a7224f9977dcf7ee6c7 527 fb6d0c48cbdee9737a959796489bddbc 528 4c5df61d5b3297b4fb68dab9f1b582c2 530 HMAC-SHA-384-128 = b6a8d5636f5c6a7224f9977dcf7ee6c7 531 fb6d0c48cbdee973 533 Test Case AUTH384-2: 534 Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 535 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 536 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 538 Data = 7768617420646f2079612077616e7420 ("what do ya want ") 539 666f72206e6f7468696e673f ("for nothing?") 541 HMAC-SHA-384-PRF = 2c7353974f1842fd66d53c452ca42122 542 b28c0b594cfb184da86a368e9b8e16f5 543 349524ca4e82400cbde0686d403371c9 545 HMAC-SHA-384-192 = 2c7353974f1842fd66d53c452ca42122 546 b28c0b594cfb184d 548 Test Case AUTH384-3: 549 Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 550 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 551 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (48 bytes) 553 Data = dddddddddddddddddddddddddddddddd 554 dddddddddddddddddddddddddddddddd 555 dddddddddddddddddddddddddddddddd 556 dddd (50 bytes) 558 HMAC-SHA-384-PRF = 809f439be00274321d4a538652164b53 559 554a508184a0c3160353e3428597003d 560 35914a18770f9443987054944b7c4b4a 562 HMAC-SHA-384-192 = 809f439be00274321d4a538652164b53 563 554a508184a0c316 565 Test Case AUTH384-4: 566 Key = 0102030405060708090a0b0c0d0e0f10 567 1112131415161718191a1b1c1d1e1f20 568 0a0b0c0d0e0f10111213141516171819 (48 bytes) 570 Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 571 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 572 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 573 cdcd (50 bytes) 575 HMAC-SHA-384-PRF = 5b540085c6e6358096532b2493609ed1 576 cb298f774f87bb5c2ebf182c83cc7428 577 707fb92eab2536a5812258228bc96687 579 HMAC-SHA-384-192 = 5b540085c6e6358096532b2493609ed1 580 cb298f774f87bb5c 582 2.7.2.3. SHA512 Authentication Test Vectors 583 Test Case AUTH512-1: 584 Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 585 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 586 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 587 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (64 bytes) 589 Data = 4869205468657265 ("Hi There") 591 HMAC-SHA-512-PRF = 637edc6e01dce7e6742a99451aae82df 592 23da3e92439e590e43e761b33e910fb8 593 ac2878ebd5803f6f0b61dbce5e251ff8 594 789a4722c1be65aea45fd464e89f8f5b 596 HMAC-SHA-512-256 = 637edc6e01dce7e6742a99451aae82df 597 23da3e92439e590e43e761b33e910fb8 599 Test Case AUTH512-2: 600 Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 601 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 602 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 603 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 605 Data = 7768617420646f2079612077616e7420 ("what do ya want ") 606 666f72206e6f7468696e673f ("for nothing?") 608 HMAC-SHA-512-PRF = cb370917ae8a7ce28cfd1d8f4705d614 609 1c173b2a9362c15df235dfb251b15454 610 6aa334ae9fb9afc2184932d8695e397b 611 fa0ffb93466cfcceaae38c833b7dba38 613 HMAC-SHA-512-256 = cb370917ae8a7ce28cfd1d8f4705d614 614 1c173b2a9362c15df235dfb251b15454 616 Test Case AUTH512-3: 617 Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 618 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 619 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 620 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (64 bytes) 622 Data = dddddddddddddddddddddddddddddddd 623 dddddddddddddddddddddddddddddddd 624 dddddddddddddddddddddddddddddddd 625 dddd (50 bytes) 627 HMAC-SHA-512-PRF = 2ee7acd783624ca9398710f3ee05ae41 628 b9f9b0510c87e49e586cc9bf961733d8 629 623c7b55cebefccf02d5581acc1c9d5f 630 b1ff68a1de45509fbe4da9a433922655 632 HMAC-SHA-512-256 = 2ee7acd783624ca9398710f3ee05ae41 633 b9f9b0510c87e49e586cc9bf961733d8 635 Test Case AUTH512-4: 636 Key = 0a0b0c0d0e0f10111213141516171819 637 0102030405060708090a0b0c0d0e0f10 638 1112131415161718191a1b1c1d1e1f20 639 2122232425262728292a2b2c2d2e2f30 640 3132333435363738393a3b3c3d3e3f40 (64 bytes) 642 Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 643 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 644 cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd 645 cdcd (50 bytes) 647 HMAC-SHA-512-PRF = 5e6688e5a3daec826ca32eaea224eff5 648 e700628947470e13ad01302561bab108 649 b8c48cbc6b807dcfbd850521a685babc 650 7eae4a2a2e660dc0e86b931d65503fd2 652 HMAC-SHA-512-256 = 5e6688e5a3daec826ca32eaea224eff5 653 e700628947470e13ad01302561bab108 655 3. Security Considerations 657 In a general sense, the security provided by the HMAC-SHA-256+ 658 algorithms is based both upon the strength of the underlying hash 659 algorithm, and upon the additional strength derived from the HMAC 660 construct. At the time of this writing there are no practical 661 cryptographic attacks against SHA-256, SHA-384, SHA-512 or HMAC. 662 However, as with any cryptographic algorithm, an important component 663 of these algorithms' strength lies in the correctness of the 664 algorithm implementation, the security of the key management 665 mechanism, the strength of the associated secret key, and upon the 666 correctness of the implementation in all of the participating 667 systems. This specification contains test vectors to assist in 668 verifying the correctness of the algorithm implementation, but these 669 in no way verify the correctness (or security) of the surrounding 670 security infrastructure. 672 3.1. HMAC Key Length vs Truncation Length 674 There are important differences between the security levels afforded 675 by HMAC-SHA1-96 and the HMAC-SHA-256+ algorithms, but there are also 676 considerations which are somewhat counter-intuitive. There are two 677 different axes along which we gauge the security of these algorithms: 678 HMAC output length and HMAC key length. If we assume the HMAC key is 679 a well-guarded secret which can only be determined through offline 680 attacks on observed values, and that its length is less than or equal 681 to the output length of the underlying hash algorithm, then the key's 682 strength is directly proportional to its length. And if we assume an 683 adversary has no knowledge of the HMAC key, then the probability of 684 guessing a correct MAC value for any given packet is directly 685 proportional to the HMAC output length. 687 This specification defines truncation to output lengths of either 128 688 192, or 256 bits. It is important to note that at this time, it is 689 not clear that HMAC-SHA-256 with a truncation length of 128 bits is 690 any more secure than HMAC-SHA1 with the same truncation length, 691 assuming the adversary has no knowledge of the HMAC key. This is 692 because in such cases, the adversary must predict only those bits 693 which remain after truncation. Since in both cases that output 694 length is the same (128 bits), the adversary's odds of correctly 695 guessing the value are also the same in either case: 1 in 2^128. 696 Again, if we assume the HMAC key remains unknown to the attacker, 697 then only a bias in one of the algorithms would distinguish one from 698 the other. Currently, no such bias is known to exist in either HMAC- 699 SHA1 or HMAC-SHA-256+. 701 If, on the other hand, the attacker is focused on guessing the HMAC 702 key, and we assume that the hash algorithms are indistinguishable 703 when viewed as PRF's, then the HMAC key length provides a direct 704 measure of the underlying security: the longer the key, the harder it 705 is to guess. This means that with respect to passive attacks on the 706 HMAC key, size matters - and the HMAC-SHA-256+ algorithms provide 707 more security in this regard than HMAC-SHA1-96. 709 4. IANA Considerations 711 This document does not specify the conventions for using SHA256+ for 712 IKE Phase 1 negotiations. For IKE Phase 2 negotiations, IANA has 713 assigned the following authentication algorithm identifiers: 715 HMAC-SHA2-256: 5 717 HMAC-SHA2-384: 6 719 HMAC-SHA2-512: 7 721 For use of HMAC-SHA-256+ as a PRF in IKEv2, IANA has assigned the 722 following IKEv2 Pseudo-random function (type 2) transform 723 identifiers: 725 PRF_HMAC_SHA2_256 [TBA-1] 727 PRF_HMAC_SHA2_384 [TBA-2] 729 PRF_HMAC_SHA2_512 [TBA-3] 731 For the use of HMAC-SHA-256+ algorithms for data origin 732 authentication and integrity verification in IKEv2, ESP or AH, IANA 733 has assigned the following IKEv2 integrity (type 3) transform 734 identifiers: 736 AUTH_HMAC_SHA2_256_128 [TBA-4] 738 AUTH_HMAC_SHA2_384_192 [TBA-5] 740 AUTH_HMAC_SHA2_512_256 [TBA-6] 742 5. Acknowledgements 744 Portions of this text were unabashedly borrowed from [HMAC-SHA1], and 745 from [HMAC-TEST]. Thanks to Hugo Krawczyk for comments and 746 recommendations on early revisions of this document, and thanks also 747 to Russ Housley and Steve Bellovin for various security-related 748 comments and recommendations. 750 6. Normative References 752 [AH] Kent, S., "IP Authentication Header", RFC 4302, 753 December 2005. 755 [ARCH] Kent, S. and K. Seo, "Security Architecture for the 756 Internet Protocol", RFC 4301, December 2005. 758 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 759 RFC 4303, December 2005. 761 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 762 Hashing for Message Authentication", RFC 2104, 763 February 1997. 765 [HMAC-SHA1] 766 Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 767 ESP and AH", RFC 2404, November 1998. 769 [HMAC-TEST] 770 Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 771 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 772 RFC 4231, December 2005. 774 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 775 (IKE)", RFC 2409, November 1998. 777 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 778 RFC 4306, December 2005. 780 [SHA2-1] NIST, "FIPS PUB 180-2 'Specifications for the Secure Hash 781 Standard'", 2004 FEB, . 784 [SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512", 785 2001 MAY, 786 . 788 [SHA256+] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 789 (SHA and HMAC-SHA)", RFC 4634, July 2006. 791 Authors' Addresses 793 Scott G. Kelly 794 Aruba Networks 795 1322 Crossman Ave 796 Sunnyvale, CA 94089 797 US 799 Email: scott@hyperthought.com 800 Sheila Frankel 801 NIST 802 Bldg. 222 Room B264 803 Gaithersburg, MD 20899 804 US 806 Email: sheila.frankel@nist.gov 808 Full Copyright Statement 810 Copyright (C) The Internet Society (2007). 812 This document is subject to the rights, licenses and restrictions 813 contained in BCP 78, and except as set forth therein, the authors 814 retain all their rights. 816 This document and the information contained herein are provided on an 817 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 818 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 819 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 820 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 821 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 822 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 824 Intellectual Property 826 The IETF takes no position regarding the validity or scope of any 827 Intellectual Property Rights or other rights that might be claimed to 828 pertain to the implementation or use of the technology described in 829 this document or the extent to which any license under such rights 830 might or might not be available; nor does it represent that it has 831 made any independent effort to identify any such rights. Information 832 on the procedures with respect to rights in RFC documents can be 833 found in BCP 78 and BCP 79. 835 Copies of IPR disclosures made to the IETF Secretariat and any 836 assurances of licenses to be made available, or the result of an 837 attempt made to obtain a general license or permission for the use of 838 such proprietary rights by implementers or users of this 839 specification can be obtained from the IETF on-line IPR repository at 840 http://www.ietf.org/ipr. 842 The IETF invites any interested party to bring to its attention any 843 copyrights, patents or patent applications, or other proprietary 844 rights that may cover technology that may be required to implement 845 this standard. Please address the information to the IETF at 846 ietf-ipr@ietf.org. 848 Acknowledgment 850 Funding for the RFC Editor function is provided by the IETF 851 Administrative Support Activity (IASA).