Network Working Group S. Kelly Internet-Draft ArubaWirelessNetworks Intended status: Standards Track S. Frankel Expires:April 1,July 9, 2007 NISTSeptember 28, 2006January 5, 2007 UsingHMAC-SHA-256HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsecdraft-kelly-ipsec-ciph-sha2-00draft-kelly-ipsec-ciph-sha2-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onApril 1,July 9, 2007. Copyright Notice Copyright (C) The Internet Society(2006).(2007). Abstract This specification describes the use ofthe SHA-256 algorithmHMAC in conjunction withHMACthe SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used asathe basis for data origin authentication and integrity verificationmechanismmechanisms for theIPsecAH, ESP, IKE and IKEv2 protocols, and also asa PRFPseudo-Random Functions (PRFs) for IKE and IKEv2.TwoTruncated outputtruncationlengths are specified fordata origin authentication and integrity verification usage,the authentication-related variants, with the corresponding algorithms designated asHMAC-SHA-256- 128HMAC-SHA-256-128, HMAC-SHA-384-192, andHMAC-SHA-256-192. No truncation is specified forHMAC-SHA-512-256. The PRFusage,variants are not truncated, andthe resulting algorithm is designated as HMAC-SHA-PRF-256.are called HMAC-SHA-PRF-256, HMAC-SHA-PRF-384, and HMAC-SHA-PRF-512. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. TheHMAC-SHA-256HMAC-SHA-256+ Algorithms . . . . . . . . . . . . . . . . . 3 2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Data Origin Authentication and Integrity Verification Usage . . . . . . . . . . . . . . . . . .34 2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4 2.1.3. Randomness and Key Strength . . . . . . . . . . . . .45 2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . .45 2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . .45 2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . .56 2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . .56 2.4. UsingHMAC-SHA-256HMAC-SHA-256+ Asa PRFPRFs in IKE and IKEv2 . . . . . . .. . . .6 2.5. Interactions with theESPESP, IKE, or IKEv2 Cipher Mechanisms . . .6 2.6. Test Vectors. . . . . . . . . . . . . . . . . . . . . 7 2.6. HMAC-SHA-256+ Parameter Summary . .6 3. Security Considerations. . . . . . . . . . . 7 2.7. Test Vectors . . . . . . . .10 3.1. HMAC Key Length vs Truncation Length. . . . . . . . . . .10 4. IANA Considerations. . . . 7 2.7.1. PRF Test Vectors . . . . . . . . . . . . . . . . . . . 7 2.7.2. Authenticator Test Vectors . . . . . . . . . . . . . . 115. Acknowledgements3. Security Considerations . . . . . . . . . . . . . . . . . . . 16 3.1. HMAC Key Length vs Truncation Length . . . . . . . . . .12 6. References. 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . .12 6.1. Normative References. . . . . . . . . . . . . . . . . . .12 6.2. Informative18 6. Normative References . . . . . . . . . . . . . . . . . .12. . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1319 Intellectual Property and Copyright Statements . . . . . . . . . .1421 1. Introduction This document specifies the use ofSHA-256SHA-256, SHA-384, and SHA-512 [SHA2-1] combined with HMAC [HMAC] asadata origin authentication and integrity verificationmechanismmechanisms for the IPsec AH [AH], ESP [ESP], IKE [IKE], and IKEv2 [IKEv2] protocols.For flexibility, two outputOutput truncationlengths areis specified forthe authentication-relatedthese variants, with the corresponding algorithms designated asHMAC-SHA-256-128HMAC-SHA-256-128, HMAC-SHA-384-192, andHMAC-SHA- 256-192. In addition, this document specifies use ofHMAC-SHA-512- 256. These truncation lengths are chosen in accordance with theunderlying HMAC-SHA-256 algorithm (without truncation)birthday bound for each algorithm. This specification also describes untruncated variants of these algorithms asa PRF withinPRFs for use with IKE and IKEv2, andthat variant is designated as HMAC-SHA-PRF-256. Thesethose algorithms are called HMAC-SHA-PRF-256, HMAC-SHA-PRF-384, and HMAC-SHA-PRF-512. For ease of reference, these PRF algorithms and the authentication variants described above are collectively referred to below as "theHMAC-SHA-256HMAC-SHA-256+ algorithms." The goal of the PRFvariantvariants is to provideasecure pseudo-randomfunctionfunctions suitable for generation of keying material and other protocol-specific numeric quantities, while the goal of the authentication variants is to ensure that packets are authentic and cannot be modified in transit. The relative security ofHMAC-SHA-256HMAC-SHA- 256+ when used in either case is dependent on thescope ofdistribution scope andtheunpredictability of the associated secret key. If the key isnot predictableunpredictable and known only by thesourcesender anddestination,recipient, these algorithms ensure that only parties holding an identical key can derive the associated values. 2. TheHMAC-SHA-256HMAC-SHA-256+ Algorithms [SHA2-1] and [SHA2-2] describe the underlyingSHA-256 algorithm,SHA-256, SHA-384, and SHA-512 algorithms, while [HMAC] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such asSHA-256.SHA-256, and [SHA256+] describes combined usage of these algorithms. The following sections describe the various characteristics and requirements of theHMAC-SHA-256 algorithms.HMAC-SHA-256+ algorithms when used with IPsec. 2.1. Keying Material Requirements for keying material vary depending onusage.whether the algorithm is functioning as a PRF or as an authentication/integrity mechanism. In the case of authentication/integrity, key lengths are fixed according to the output length of the algorithm in use. In the case of PRFs, key lengths are variable, but guidance is given to ensure interoperability. These distinctions are described further below. Before describing key requirements for each usage, it is important to clarify some terms we use below: Block size: the size of the data block the underlying hash algorithm operates upon; for SHA-256, this is 512 bits. For SHA-384 and SHA-512, this is 1024 bits. Output length: the size of the hash value produced by the underlying hash algorithm. For SHA-256, this is 256 bits, for SHA-384 this is 384 bits, and for SHA-512, this is 512 bits. Authenticator length: the size of the "authenticator" in bits. This only applies to authentication/integrity related algorithms, and refers to thefollowing sections.bit length remaining after truncation. In this specification, this is always half the output length of the underlying hash algorithm. 2.1.1. Data Origin Authentication and Integrity Verification UsageHMAC-SHA-256 is aHMAC-SHA-256+ are secret keyalgorithm.algorithms. While no fixed key length is specified in [HMAC], this specification requires thatfor usewhen used as anintegrityintegrity/authentication algorithm, a fixed key length equal to the output length of256-bitsthe hash functions MUST be supported, and key lengths other than256-bitsthe output length of the associated hash function MUST NOT be supported.The 256-bitThese key lengthis chosenrestrictions are based in part on the recommendations in [HMAC](i.e. key(key lengths less than theauthenticatoroutput length decrease securitystrengthstrength, and keys longer than theauthenticatoroutput length do not significantly increase securitystrength).strength), and in part because allowing variable length keys for IPsec authenticator functions would create interoperability issues. 2.1.2. Pseudo-Random Function (PRF) Usage IKE and IKEv2usesuse PRFs formultiple purposes, most notably forgenerating keying material and for authentication of the IKE_SA. The IKEv2 specification differentiates between PRFs with fixed key sizes and those with variable keysizes.sizes, and so we give some special guidance for this below. Whenthea PRF described in this document is used with IKE or IKEv2, it is considered to have a variable key length, and keys are derived in the followingway (asways (note that we simply reiterate that which is specified in [HMAC]): o If the length of the key is exactly256 bits long,the algorithm block size, use it as-is. o If the keyhas feweris shorter than256 bits,the block size, lengthen it to exactly256 bitsthe block size by padding it on the right with zero bits. However, note that [HMAC] strongly discourages a key length less than256 bits.the output length. Nonetheless, we describe handling of shorter lengths here in recognition of shorter lengths typically chosen for IKE or IKEv2 preshared keys. o If the key is257 bits or longer,longer than the block size, shorten itto exactly 256 bitsby computing theSHA2-256corresponding hashofalgorithm output over the entire key value, andusetreat the resulting output value as your HMAC key. Note that this will always result in a key that is less than the block size in length, and this key value will therefore require 0-padding (as described above) prior to use. 2.1.3. Randomness and Key Strength [HMAC] discusses requirements for key material, including a requirement for strong randomness. Therefore, a strong pseudo-random function MUST be used to generate the required256-bitkey for use witheither HMAC-SHA-256-128 or HMAC-SHA-256-192.HMAC- SHA-256+. At the time of this writing there are no published weak keys for use withHMAC-SHA- 256.any HMAC-SHA-256+ algorithms. 2.1.4. Key Distribution [ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication). In order to provide data origin authentication and integrity verification, the key distribution mechanism must ensure that unique keys are allocated and that they are distributed only to the parties participating in the communication. 2.1.5. Refreshing Keys[HMAC] makes the following recommendation with regard to rekeying: "CurrentThere are no currently practical attacksdo not indicate a specificagainst the algorithms recommendedfrequency forhere, and especially against the keychanges ...sizes recommended here. However,periodicas noted in [HMAC] "...periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key." Putting this into perspective, this specification requires256-bit256, 384, or 512-bit keys produced by a strong PRF for use as a MAC. A brute force attack on such keys would takemore yearslonger to mount than the universe has been in existence. On the other hand, weak keys (e.g. dictionary words) would be dramatically less resistant to attack. It is important to takethis,these points, along with the specific threat model for your particular application and the current state of the art with respect to attacks on SHA-256, SHA-384, and SHA-512 into account when determining an appropriate upper bound for HMAC key lifetimes 2.2. Padding The HMAC-SHA-256 algorithms operate on 512-bit blocks of data, while the HMAC-SHA-384 and HMAC-SHA-512 algorithms operate on 1024-bit blocks of data. Padding requirements are specified in [SHA2-1]and areas part of theSHA-256 algorithm,underlying SHA-256, SHA-384, and SHA-512 algorithms, so if youbuild SHA-256implement according to [SHA2-1], you do not need to add any additional padding as far as theHMAC-SHA-256HMAC-SHA-256+ algorithms specified here are concerned. With regard to "implicit packet padding" as defined in [AH], no implicit packet padding is required. 2.3. Truncation TheHMAC-SHA-256HMAC-SHA-256+ algorithms each produce a256-bit authenticatornnn-bit value,andwhere nnn corresponds to the output bit length of the algorithm, e.g. HMAC- SHA-nnn. For use as an authenticator, this256-bitnnn-bit value can be truncated as described in [HMAC]. When used as a data origin authentication and integrity verification algorithm in ESP, AH, IKE, or IKEv2, a truncated value using the first128 or 192nnn/2 bits -- exactly half the algorithm output size -- MUST be supported. No other authenticator value lengths are supported by this specification. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire256-bitnnn-bit value is computed and the first128 or 192nnn/2 bits are compared to the value stored in the authenticator field, with the value of 'nnn' depending onwhetherthe negotiatedalgorithm is HMAC-SHA-256-128 or HMAC-SHA-256-192.algorithm. [HMAC] discusses potential security benefits resulting from truncation of the output MAC value, and in general, encourages HMAC users to perform MAC truncation. In the context of IPsec, aminimumtruncation length of128nnn/2 bits is selected because it corresponds to the birthday attackbound,bound for each of the HMAC-SHA-256+ algorithms, and it simultaneously serves to minimize the additional bits on the wire resulting from use of this facility.This specification also defines a truncation length of 192 in order to provide an alternative to those whose security needs outweigh their concern for minimizing bits on the wire.2.4. UsingHMAC-SHA-256HMAC-SHA-256+ Asa PRFPRFs in IKE and IKEv2 The HMAC-SHA-PRF-256 algorithm is identical toHMAC-SHA-256-128 and HMAC-SHA-256-192HMAC-SHA-256-128, except that variable-length keys are permitted, and the truncation step is NOT performed.The test vectors below whichLikewise, the implementations of HMAC-SHA- PRF-384 and HMAC-SHA-PRF-512 aresimply labeled HMAC-SHA-256 may be usedidentical tovalidate implementationsthose ofHMAC-SHA-PRF-256.HMAC-SHA-384- 192 and HMAC-SHA-512-256 respectively, except that again, truncation is NOT performed. 2.5. Interactions with theESPESP, IKE, or IKEv2 Cipher Mechanisms As of this writing, there are no known issues which preclude the use of theHMAC-SHA-256HMAC-SHA-256+ algorithms with any specific cipher algorithm. 2.6. HMAC-SHA-256+ Parameter Summary The following table serves to summarize the various quantities associated with the HMAC-SHA-256+ algorithms. +------------------+--------+--------+--------+----------+------------+ | Algorithm | Block | Output | Trunc. | Key | Algorithm | | ID | Size | Length | Length | Length | Type | +==================+========+========+========+==========+============+ | HMAC-SHA-256-128 | 512 | 256 | 128 | 256 | auth/integ | +------------------+--------+--------+--------+----------+------------+ | HMAC-SHA-384-192 | 1024 | 384 | 192 | 384 | auth/integ | +------------------+--------+--------+--------+----------+------------+ | HMAC-SHA-512-256 | 1024 | 512 | 256 | 512 | auth/integ | +------------------+--------+--------+--------+----------+------------+ | HMAC-SHA-256-PRF | 512 | 256 | (none) | variable | PRF | +------------------+--------+--------+--------+----------+------------+ | HMAC-SHA-384-PRF | 1024 | 384 | (none) | variable | PRF | +------------------+--------+--------+--------+----------+------------+ | HMAC-SHA-512-PRF | 1024 | 512 | (none) | variable | PRF | +------------------+--------+--------+--------+----------+------------+ 2.7. Test Vectors The following test casesfor HMAC-SHA-256-192 and HMAC-SHA-256-128include the key, the data, and the resultingHMAC.authenticator and/or PRF values for each algorithm. The values of keys and data are eitherhexadecimal numbers (prefixed by "0x") orASCII character strings (surrounded by doublequotes).quotes) or hexadecimal numbers. If a value is an ASCII character string, then the HMAC computation for the corresponding test case DOES NOT include the trailing null character ('\0') of the string. The computed HMAC values are all hexadecimal numbers. 2.7.1. PRF Test Vectors These test cases wereverified using 3 independent implementations: an HMAC wrapper on topborrowed from RFC 4231 [HMAC-TEST]. For reference implementations ofAaron Gifford's SHA256 implementation (http://www.adg.us/computers/sha.html),theBeeCrypt crypto library (http://beecrypt.sourceforge.net/) andunderlying hash algorithms, see [SHA256+]. Note that for testing purposes, PRF output is considered to be simply theNettle cryptographic library (www.lysator.liu.se/~nisse/nettle). Partial blocks were padded as specified in [SHA2-1].untruncated algorithm output. Testcases 1 and 2 were taken from the SHA-2 FIPS [SHA2-1] andCase PRF-1: Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b (20 bytes) Data = 4869205468657265 ("Hi There") HMAC-SHA-256-PRF = b0344c61d8db38535ca8afceaf0bf12b 881dc200c9833da726e9376c2e32cff7 HMAC-SHA-384-PRF = afd03944d84895626b0825f4ab46907f 15f9dadbe4101ec682aa034c7cebc59c faea9ea9076ede7f4af152e8b2fa9cb6 HMAC-SHA-512-PRF = 87aa7cdea5ef619d4ff0b4241a1d6cb0 2379f4e2ce4ec2787ad0b30545e17cde daa833b7d6b8a702038b274eaea3f4e4 be9d914eeb61f1702e696c203a126854 Test Case PRF-2: Key = 4a656665 ("Jefe") Data = 7768617420646f2079612077616e7420 ("what do ya want ") 666f72206e6f7468696e673f ("for nothing?") HMAC-SHA-256-PRF = 5bdcc146bf60754e6a042426089575c7 5a003f089d2739839dec58b964ec3843 HMAC-SHA-384-PRF = af45d2e376484031617f78d2b58a6b1b 9c7ef464f5a01b47e42ec3736322445e 8e2240ca5e69e2c78b3239ecfab21649 HMAC-SHA-512-PRF = 164b7a7bfcf819e2e395fbe73b56e0a3 87bd64222e831fd610270cd7ea250554 9758bf75c05a994a6d034f65f8f0e6fd caeab1a34d4a6b4b636e070a38bce737 Test Case PRF-3: Key aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa (20 bytes) Data = dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddd (50 bytes) HMAC-SHA-256-PRF = 773ea91e36800e46854db8ebd09181a7 2959098b3ef8c122d9635514ced565fe HMAC-SHA-384-PRF = 88062608d3e6ad8a0aa2ace014c8a86f 0aa635d947ac9febe83ef4e55966144b 2a5ab39dc13814b94e3ab6e101a34f27 HMAC-SHA-512-PRF = fa73b0089d56a284efb0f0756c890be9 b1b5dbdd8ee81a3655f83e33b2279d39 bf3e848279a722c806b485a47e67c807 b946a337bee8942674278859e13292fb Test Case PRF-4: Key = 0102030405060708090a0b0c0d0e0f10 111213141516171819 (25 bytes) Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcd (50 bytes) HMAC-SHA-256-PRF = 82558a389a443c0ea4cc819899f2083a 85f0faa3e578f8077a2e3ff46729665b HMAC-SHA-384-PRF = 3e8a69b7783c25851933ab6290af6ca7 7a9981480850009cc5577c6e1f573b4e 6801dd23c4a7d679ccf8a386c674cffb HMAC-SHA-512-PRF = b0ba465637458c6990e5a8c5f61d4af7 e576d97ff94b872de76f8050361ee3db a91ca5c11aa25eb4d679275cc5788063 a5f19741120c4f2de2adebeb10a298dd Test Case PRF-5: Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaa (131 bytes) Data = 54657374205573696e67204c61726765 ("Test Using Large") 72205468616e20426c6f636b2d53697a ("r Than Block-Siz") 65204b6579202d2048617368204b6579 ("e Key - Hash Key") 204669727374 (" First") HMAC-SHA-256-PRF = 60e431591ee0b67f0d8a26aacbf5b77f 8e0bc6213728c5140546040f0ee37f54 HMAC-SHA-384-PRF = 4ece084485813e9088d2c63a041bc5b4 4f9ef1012a2b588f3cd11f05033ac4c6 0c2ef6ab4030fe8296248df163f44952 HMAC-SHA-512-PRF = 80b24263c7c1a3ebb71493c1dd7be8b4 9b46d1f41b4aeec1121b013783f8f352 6b56d037e05f2598bd0fd2215d6a1e52 95e64f73f63f0aec8b915a985d786598 Test Case PRF-6: Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaa (131 bytes) Data = 54686973206973206120746573742075 ("This is a testcases 4-10 were borrowed from [HMAC-TEST] with someu") 73696e672061206c6172676572207468 ("sing a larger th") 616e20626c6f636b2d73697a65206b65 ("an block-size ke") 7920616e642061206c61726765722074 ("y and a larger t") 68616e20626c6f636b2d73697a652064 ("han block-size d") 6174612e20546865206b6579206e6565 ("ata. The keysizes adjust- ed for HMAC-SHA-256. Thesenee") 647320746f2062652068617368656420 ("ds to be hashed ") 6265666f7265206265696e6720757365 ("before being use") 642062792074686520484d414320616c ("d by the HMAC al") 676f726974686d2e ("gorithm.") HMAC-SHA-256-PRF = 9b09ffa71b942fcb27635fbcd5b0e944 bfdc63644f0713938a7f51535c3a35e2 HMAC-SHA-384-PRF = 6617178e941f020d351e2f254e8fd32c 602420feb0b8fb9adccebb82461e99c5 a678cc31e799176d3860e6110c46523e HMAC-SHA-512-PRF = e37b6a775dc87dbaa4dfa9f96e5e3ffd debd71f8867289865df5a32d20cdc944 b6022cac3c4982b10d5eeb55c3e4de15 134676fb6de0446065c97440fa8c6a58 2.7.2. Authenticator Test Vectors In the following sections are test casesillustrate HMAC-SHA-256 with various combinations of inputfor HMAC-SHA256-128, HMAC- SHA384-192, andkeysize. AllHMAC-SHA512-256. PRF outputs are also included for convenience. These test casesinclude the computed HMAC-SHA-256; only those with a keysize of 32 bytes (256 bits) also includewere generated using thetruncatedSHA256+ reference code provided in [SHA256+]. 2.7.2.1. SHA256 Authentication Test Vectors Test Case AUTH256-1: Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (32 bytes) Data = 4869205468657265 ("Hi There") HMAC-SHA-256-PRF = 198a607eb44bfbc69903a0f1cf2bbdc5 ba0aa3f3d9ae3c1c7a3b1696a0b68cf7 HMAC-SHA-256-128and HMAC-SHA-256- 192.= 198a607eb44bfbc69903a0f1cf2bbdc5 Test Case#1: HMAC-SHA-256 with 3-byte input and 32-byte key Key_len : 32AUTH256-2: Key: 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 Data_len : 3= 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") Data: "abc" HMAC-SHA-256 : 0xa21b1f5d4cf4f73a4dd939750f7a066a 7f98cc131cb16a6692759021cfab8181 HMAC-SHA-256-128: 0xa21b1f5d4cf4f73a4dd939750f7a066a HMAC-SHA-256-192: 0xa21b1f5d4cf4f73a4dd939750f7a066a 7f98cc131cb16a66= 7768617420646f2079612077616e7420 ("what do ya want ") 666f72206e6f7468696e673f ("for nothing?") HMAC-SHA-256-PRF = 167f928588c5cc2eef8e3093caa0e87c 9ff566a14794aa61648d81621a2a40c6 HMAC-SHA-256-128 = 167f928588c5cc2eef8e3093caa0e87c Test Case#2: HMAC-SHA-256 with 56-byte input and 32-byte key Key_len : 32AUTH256-3: Key: 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 Data_len : 56= aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (32 bytes) Data: "abcdbcdecdefdefgefghfghighijhijk ijkljklmklmnlmnomnopnopq" HMAC-SHA-256 : 0x104fdc1257328f08184ba73131c53cae e698e36119421149ea8c712456697d30 HMAC-SHA-256-128: 0x104fdc1257328f08184ba73131c53cae HMAC-SHA-256-192: 0x104fdc1257328f08184ba73131c53cae e698e36119421149= dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddd (50 bytes) HMAC-SHA-256-PRF = cdcb1220d1ecccea91e53aba3092f962 e549fe6ce9ed7fdc43191fbde45c30b0 HMAC-SHA-256-128 = cdcb1220d1ecccea91e53aba3092f962 Test Case#3: HMAC-SHA-256 with 112-byte (multi-block) input and 32-byte key Key_len : 32AUTH256-4: Key: 0x0102030405060708090a0b0c0d0e0f10= 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20Data_len : 112(32 bytes) Data: "abcdbcdecdefdefgefghfghighijhijk ijkljklmklmnlmnomnopnopqabcdbcde cdefdefgefghfghighijhijkijkljklm klmnlmnomnopnopq" HMAC-SHA-256 : 0x470305fc7e40fe34d3eeb3e773d95aab 73acf0fd060447a5eb4595bf33a9d1a3 HMAC-SHA-256-128: 0x470305fc7e40fe34d3eeb3e773d95aab HMAC-SHA-256-192: 0x470305fc7e40fe34d3eeb3e773d95aab 73acf0fd060447a5= cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcd (50 bytes) HMAC-SHA-256-PRF = 372efcf9b40b35c2115b1346903d2ef4 2fced46f0846e7257bb156d3d7b30d3f HMAC-SHA-256-128 = 372efcf9b40b35c2115b1346903d2ef4 2.7.2.2. SHA384 Authentication Test Vectors Test Case#4: HMAC-SHA-256 with 8-byte input and 32-byte key Key_len : 32 Key : 0x0b repeated 32 times Data_len : 8 Data : 0x4869205468657265AUTH384-1: Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (48 bytes) Data: "Hi There" HMAC-SHA-256 : 0x198a607eb44bfbc69903a0f1cf2bbdc5 ba0aa3f3d9ae3c1c7a3b1696a0b68cf7 HMAC-SHA-256-128: 0x198a607eb44bfbc69903a0f1cf2bbdc5 HMAC-SHA-256-192: 0x198a607eb44bfbc69903a0f1cf2bbdc5 ba0aa3f3d9ae3c1c= 4869205468657265 ("Hi There") HMAC-SHA-384-PRF = b6a8d5636f5c6a7224f9977dcf7ee6c7 fb6d0c48cbdee9737a959796489bddbc 4c5df61d5b3297b4fb68dab9f1b582c2 HMAC-SHA-384-128 = b6a8d5636f5c6a7224f9977dcf7ee6c7 fb6d0c48cbdee973 Test Case#5: HMAC-SHA-256 with 28-byte input and 4-byte key Key_len : 4AUTH384-2: Key: "Jefe" Data_len : 28= 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") Data: "what= 7768617420646f2079612077616e7420 ("what do ya wantfor nothing?" HMAC-SHA-256 : 0x5bdcc146bf60754e6a042426089575c7 5a003f089d2739839dec58b964ec3843") 666f72206e6f7468696e673f ("for nothing?") HMAC-SHA-384-PRF = 2c7353974f1842fd66d53c452ca42122 b28c0b594cfb184da86a368e9b8e16f5 349524ca4e82400cbde0686d403371c9 HMAC-SHA-384-192 = 2c7353974f1842fd66d53c452ca42122 b28c0b594cfb184d Test Case#6: HMAC-SHA-256 with 50-byte input and 32-byte key Key_len : 32 Key : 0xaa repeated 32 times Data_len : 50AUTH384-3: Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (48 bytes) Data: 0xdd repeated 50 times HMAC-SHA-256 : 0xcdcb1220d1ecccea91e53aba3092f962 e549fe6ce9ed7fdc43191fbde45c30b0 HMAC-SHA-256-128: 0xcdcb1220d1ecccea91e53aba3092f962 HMAC-SHA-256-192: 0xcdcb1220d1ecccea91e53aba3092f962 e549fe6ce9ed7fdc= dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddd (50 bytes) HMAC-SHA-384-PRF = 809f439be00274321d4a538652164b53 554a508184a0c3160353e3428597003d 35914a18770f9443987054944b7c4b4a HMAC-SHA-384-192 = 809f439be00274321d4a538652164b53 554a508184a0c316 Test Case#7: HMAC-SHA-256 with 50-byte input and 37-byte key Key_len : 37AUTH384-4: Key: 0x0102030405060708090a0b0c0d0e0f10= 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f202122232425 Data_len : 500a0b0c0d0e0f10111213141516171819 (48 bytes) Data: 0xcd repeated 50 times HMAC-SHA-256 : 0xd4633c17f6fb8d744c66dee0f8f07455 6ec4af55ef07998541468eb49bd2e917= cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcd (50 bytes) HMAC-SHA-384-PRF = 5b540085c6e6358096532b2493609ed1 cb298f774f87bb5c2ebf182c83cc7428 707fb92eab2536a5812258228bc96687 HMAC-SHA-384-192 = 5b540085c6e6358096532b2493609ed1 cb298f774f87bb5c 2.7.2.3. SHA512 Authentication Test Vectors Test Case#8: HMAC-SHA-256 with 20-byte input and 32-byte key Key_len : 32 Key : 0x0c repeated 32 times Data_len : 20AUTH512-1: Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (64 bytes) Data: "Test With Truncation" HMAC-SHA-256 : 0x7546af01841fc09b1ab9c3749a5f1c17 d4f589668a587b2700a9c97c1193cf42 HMAC-SHA-256-128: 0x7546af01841fc09b1ab9c3749a5f1c17 HMAC-SHA-256-192: 0x7546af01841fc09b1ab9c3749a5f1c17 d4f589668a587b27= 4869205468657265 ("Hi There") HMAC-SHA-512-PRF = 637edc6e01dce7e6742a99451aae82df 23da3e92439e590e43e761b33e910fb8 ac2878ebd5803f6f0b61dbce5e251ff8 789a4722c1be65aea45fd464e89f8f5b HMAC-SHA-512-256 = 637edc6e01dce7e6742a99451aae82df 23da3e92439e590e43e761b33e910fb8 Test Case#9: HMAC-SHA-256 with 54-byte input and 80-byte key Key_len : 80 Key : 0xaa repeated 80 times Data_len : 54 Data : "Test Using Larger Than Block-Size Key - HashAUTH512-2: KeyFirst" HMAC-SHA-256 : 0x6953025ed96f0c09f80a96f78e6538db e2e7b820e3dd970e7ddd39091b32352f= 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe") Data = 7768617420646f2079612077616e7420 ("what do ya want ") 666f72206e6f7468696e673f ("for nothing?") HMAC-SHA-512-PRF = cb370917ae8a7ce28cfd1d8f4705d614 1c173b2a9362c15df235dfb251b15454 6aa334ae9fb9afc2184932d8695e397b fa0ffb93466cfcceaae38c833b7dba38 HMAC-SHA-512-256 = cb370917ae8a7ce28cfd1d8f4705d614 1c173b2a9362c15df235dfb251b15454 Test Case#10: HMAC-SHA-256 with 73-byte (multi-block) input and 80-byte key Key_len : 80 Key : 0xaa repeated 80 times Data_len : 73AUTH512-3: Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (64 bytes) Data: "Test Using Larger Than Block-Size= dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddd dddd (50 bytes) HMAC-SHA-512-PRF = 2ee7acd783624ca9398710f3ee05ae41 b9f9b0510c87e49e586cc9bf961733d8 623c7b55cebefccf02d5581acc1c9d5f b1ff68a1de45509fbe4da9a433922655 HMAC-SHA-512-256 = 2ee7acd783624ca9398710f3ee05ae41 b9f9b0510c87e49e586cc9bf961733d8 Test Case AUTH512-4: Keyand Larger Than One Block-Size Data" HMAC-SHA-256 : 0x6355ac22e890d0a3c8481a5ca4825bc8 84d3e7a1ff98a2fc2ac7d8e064c3b2e6= 0a0b0c0d0e0f10111213141516171819 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 2122232425262728292a2b2c2d2e2f30 3132333435363738393a3b3c3d3e3f40 (64 bytes) Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd cdcd (50 bytes) HMAC-SHA-512-PRF = 5e6688e5a3daec826ca32eaea224eff5 e700628947470e13ad01302561bab108 b8c48cbc6b807dcfbd850521a685babc 7eae4a2a2e660dc0e86b931d65503fd2 HMAC-SHA-512-256 = 5e6688e5a3daec826ca32eaea224eff5 e700628947470e13ad01302561bab108 3. Security Considerations In a general sense, the security provided by theHMAC-SHA-256HMAC-SHA-256+ algorithms is based both upon the strength ofSHA-256,the underlying hash algorithm, and upon the additional strength derived from the HMAC construct. At the time of this writing there are no practical cryptographic attacks againsteither SHA-256SHA-256, SHA-384, SHA-512 or HMAC. However, as with any cryptographic algorithm, an important component ofHMAC-SHA-256'sthese algorithms' strength lies in the correctness of the algorithm implementation, the security of the key management mechanism, the strength of the associated secret key, and upon the correctness of the implementation in all of the participating systems. This specification contains test vectors to assist in verifying the correctness ofHMAC-SHA-256 code,the algorithm implementation, but these in no way verify the correctness (or security) of the surrounding security infrastructure. 3.1. HMAC Key Length vs Truncation Length There are important differences between the security levels afforded by HMAC-SHA1-96 and theHMAC-SHA-256-128 and HMAC-SHA-256-192HMAC-SHA-256+ algorithms, but there are also considerations which are somewhat counter-intuitive. There are two different axes along which we gauge the security of these algorithms: HMAC output length and HMAC key length. If we assume the HMAC key is a well-guarded secret which can only be determined through offline attacks on observed values, and that its length is less than or equal to the output length of the underlying hash algorithm, then the key's strength is directly proportional to its length. And if we assume an adversary has no knowledge of the HMAC key, then the probability of guessing a correct MAC value for any given packet is directly proportional to the HMAC output length. This specification defines truncation to output lengths of either 128 192, or192256 bits. It is important to note that at this time, it is not clear that HMAC-SHA-256 with a truncation length of 128 bits is any more secure than HMAC-SHA1 with the same truncation length, assuming the adversary has no knowledge of the HMAC key. This is because in such cases, the adversary must predict only those bits which remain after truncation. Since in both cases that output length is the same (128 bits), the adversary's odds of correctly guessing the value are also the same in either case: 1 in 2^128. Again, if we assume the HMAC key remains unknown to the attacker, then only a bias in one of the algorithms would distinguish one from the other. Currently, no such bias is known to exist in eitherHMAC-SHA1HMAC- SHA1 orHMAC-SHA-256.HMAC-SHA-256+. If, on the other hand, the attacker is focused on guessing the HMAC key, and we assume that the hash algorithms are indistinguishable when viewed as PRF's, then the HMAC key length provides a direct measure of the underlying security: the longer the key, the harder it is to guess. This means that with respect to passive attacks on the HMAC key, size matters - and theHMAC-SHA-256 algorithms, with their 256-bit key lengths,HMAC-SHA-256+ algorithms provide more security in this regard thanHMAC- SHA1 (with its 160-bit key length).HMAC-SHA1-96. 4. IANA Considerations This document does not specify the conventions for using SHA256+ for IKE Phase 1 negotiations. For IKE Phase 2 negotiations, IANA has assigned the following authentication algorithm identifiers: HMAC-SHA2-256: 5 HMAC-SHA2-384: 6 HMAC-SHA2-512: 7 For use ofHMAC-SHA-256HMAC-SHA-256+ as a PRF in IKEv2, IANA has assigned the following IKEv2 Pseudo-random function (type 2) transformidentifier: [TBA-1] foridentifiers: PRF_HMAC_SHA2_256 [TBA-1] PRF_HMAC_SHA2_384 [TBA-2] PRF_HMAC_SHA2_512 [TBA-3] For the use ofthe HMAC-SHA-256HMAC-SHA-256+ algorithms for data origin authentication and integrity verification in IKEv2, ESP or AH, IANA has assigned the following IKEv2 integrity (type 3) transform identifiers:[TBA-2] forAUTH_HMAC_SHA2_256_128[TBA-3] for AUTH_HMAC_SHA2_256_192[TBA-4] AUTH_HMAC_SHA2_384_192 [TBA-5] AUTH_HMAC_SHA2_512_256 [TBA-6] 5. Acknowledgements Portions of this text were unabashedly borrowed from [HMAC-SHA1], andalsofrom[XCBC-PRF].[HMAC-TEST]. Thanks to Hugo Krawczyk for comments and recommendations on early revisions of this document, and thanks also to Russ Housley and Steve Bellovin for various security-related comments and recommendations. 6.References 6.1.Normative References [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [HMAC-SHA1] Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [HMAC-TEST] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005. [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [SHA2-1] NIST,"Draft FIPS"FIPS PUB 180-2 'Specifications for the Secure Hash Standard'",2001 MAY, <http://csrc.nist.gov/ publications/fips/fips180-2/ fips180-2withchangenotice.pdf>.2004 FEB, <http://csrc.nist.gov/publications/ fips/fips180-2/fips180-2withchangenotice.pdf>. [SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512", 2001 MAY, <http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.6.2. Informative References [HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5[SHA256+] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA andHMAC- SHA-1", RFC 2202, September 1997. [XCBC-PRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)",HMAC-SHA)", RFC4434, February4634, July 2006. Authors' Addresses Scott G. Kelly ArubaWirelessNetworks 1322 Crossman Ave Sunnyvale, CA 94089 US Email: scott@hyperthought.com Sheila Frankel NIST Bldg. 222 Room B264 Gaithersburg, MD 20899 US Email: sheila.frankel@nist.gov Full Copyright Statement Copyright (C) The Internet Society(2006).(2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).