Network Working Group S. Kelly Internet-Draft Aruba Wireless Networks Intended status: Standards Track S. Frankel Expires: April 1, 2007 NIST September 28, 2006 Using HMAC-SHA-256 With IPsec draft-kelly-ipsec-ciph-sha2-00 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 on April 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This specification describes the use of the SHA-256 algorithm in conjunction with HMAC as a data origin authentication and integrity verification mechanism for the IPsec AH, ESP, and IKEv2 protocols, and also as a PRF for IKEv2. Two output truncation lengths are specified for data origin authentication and integrity verification usage, with the corresponding algorithms designated as HMAC-SHA-256- 128 and HMAC-SHA-256-192. No truncation is specified for PRF usage, Kelly & Frankel Expires April 1, 2007 [Page 1] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 and the resulting algorithm is designated as HMAC-SHA-PRF-256. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The HMAC-SHA-256 Algorithms . . . . . . . . . . . . . . . . . 3 2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Data Origin Authentication and Integrity Verification Usage . . . . . . . . . . . . . . . . . . 3 2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4 2.1.3. Randomness and Key Strength . . . . . . . . . . . . . 4 2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . . 4 2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . . 4 2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Using HMAC-SHA-256 As a PRF in IKEv2 . . . . . . . . . . . 6 2.5. Interactions with the ESP or IKEv2 Cipher Mechanisms . . . 6 2.6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 3.1. HMAC Key Length vs Truncation Length . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Kelly & Frankel Expires April 1, 2007 [Page 2] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 1. Introduction This document specifies the use of SHA-256 [SHA2-1] combined with HMAC [HMAC] as a data origin authentication and integrity verification mechanism for the IPsec AH [AH], ESP [ESP], and IKEv2 [IKEv2] protocols. For flexibility, two output truncation lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128 and HMAC-SHA- 256-192. In addition, this document specifies use of the underlying HMAC-SHA-256 algorithm (without truncation) as a PRF within IKEv2, and that variant is designated as HMAC-SHA-PRF-256. These algorithms are collectively referred to below as "the HMAC-SHA-256 algorithms." The goal of the PRF variant is to provide a secure pseudo-random function 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 of HMAC-SHA-256 when used in either case is dependent on the scope of distribution and the unpredictability of the associated secret key. If the key is not predictable and known only by the source and destination, these algorithms ensure that only parties holding an identical key can derive the associated values. 2. The HMAC-SHA-256 Algorithms [SHA2-1] and [SHA2-2] describe the underlying SHA-256 algorithm, while [HMAC] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such as SHA-256. The following sections describe the various characteristics and requirements of the HMAC-SHA-256 algorithms. 2.1. Keying Material Requirements for keying material vary depending on usage. These distinctions are described in the following sections. 2.1.1. Data Origin Authentication and Integrity Verification Usage HMAC-SHA-256 is a secret key algorithm. While no fixed key length is specified in [HMAC], this specification requires that for use as an integrity algorithm, a fixed key length of 256-bits MUST be supported, and key lengths other than 256-bits MUST NOT be supported. The 256-bit key length is chosen based on the recommendations in [HMAC] (i.e. key lengths less than the authenticator length decrease security strength and keys longer than the authenticator length do not significantly increase security strength). Kelly & Frankel Expires April 1, 2007 [Page 3] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 2.1.2. Pseudo-Random Function (PRF) Usage IKEv2 uses PRFs for multiple purposes, most notably for generating keying material and authentication of the IKE_SA. The IKEv2 specification differentiates between PRFs with fixed key sizes and those with variable key sizes. When the PRF described in this document is used with IKEv2, it is considered to have a variable key length, and keys are derived in the following way (as specified in [HMAC]): o If the key is exactly 256 bits long, use it as-is. o If the key has fewer than 256 bits, lengthen it to exactly 256 bits by padding it on the right with zero bits. However, note that [HMAC] strongly discourages a key length less than 256 bits. o If the key is 257 bits or longer, shorten it to exactly 256 bits by computing the SHA2-256 hash of the entire key value, and use the resulting output value as your HMAC key. 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 required 256-bit key for use with either HMAC-SHA-256-128 or HMAC-SHA-256-192. At the time of this writing there are no published weak keys for use with HMAC-SHA- 256. 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: "Current attacks do not indicate a specific recommended frequency for key changes ... However, 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." Kelly & Frankel Expires April 1, 2007 [Page 4] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 Putting this into perspective, this specification requires 256-bit keys produced by a strong PRF for use as a MAC. A brute force attack on such keys would take more years 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 take this, along with the threat model for your particular application and the current state of the art with respect to attacks on SHA-256, 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. Padding requirements are specified in [SHA2-1] and are part of the SHA-256 algorithm, so if you build SHA-256 according to [SHA2-1], you do not need to add any additional padding as far as the HMAC-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 The HMAC-SHA-256 algorithms produce a 256-bit authenticator value, and this 256-bit value can be truncated as described in [HMAC]. When used as a data origin authentication and integrity verification algorithm in ESP, AH, or IKEv2, a truncated value using the first 128 or 192 bits 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 entire 256-bit value is computed and the first 128 or 192 bits are compared to the value stored in the authenticator field, depending on whether the negotiated algorithm is HMAC-SHA-256-128 or HMAC-SHA-256-192. [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, a minimum truncation length of 128 bits is selected because it corresponds to the birthday attack bound, 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. Kelly & Frankel Expires April 1, 2007 [Page 5] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 2.4. Using HMAC-SHA-256 As a PRF in IKEv2 The HMAC-SHA-PRF-256 algorithm is identical to HMAC-SHA-256-128 and HMAC-SHA-256-192 except that variable-length keys are permitted, and the truncation step is NOT performed. The test vectors below which are simply labeled HMAC-SHA-256 may be used to validate implementations of HMAC-SHA-PRF-256. 2.5. Interactions with the ESP or IKEv2 Cipher Mechanisms As of this writing, there are no known issues which preclude the use of the HMAC-SHA-256 algorithms with any specific cipher algorithm. 2.6. Test Vectors The following test cases for HMAC-SHA-256-192 and HMAC-SHA-256-128 include the key, the data, and the resulting HMAC. The values of keys and data are either hexadecimal numbers (prefixed by "0x") or ASCII character strings (surrounded by double quotes). 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. These test cases were verified using 3 independent implementations: an HMAC wrapper on top of Aaron Gifford's SHA256 implementation (http://www.adg.us/computers/sha.html), the BeeCrypt crypto library (http://beecrypt.sourceforge.net/) and the Nettle cryptographic library (www.lysator.liu.se/~nisse/nettle). Partial blocks were padded as specified in [SHA2-1]. Test cases 1 and 2 were taken from the SHA-2 FIPS [SHA2-1] and test cases 4-10 were borrowed from [HMAC-TEST] with some key sizes adjust- ed for HMAC-SHA-256. These test cases illustrate HMAC-SHA-256 with various combinations of input and keysize. All test cases include the computed HMAC-SHA-256; only those with a keysize of 32 bytes (256 bits) also include the truncated HMAC-SHA-256-128 and HMAC-SHA-256- 192. Kelly & Frankel Expires April 1, 2007 [Page 6] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 Test Case #1: HMAC-SHA-256 with 3-byte input and 32-byte key Key_len : 32 Key : 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 Data_len : 3 Data : "abc" HMAC-SHA-256 : 0xa21b1f5d4cf4f73a4dd939750f7a066a 7f98cc131cb16a6692759021cfab8181 HMAC-SHA-256-128: 0xa21b1f5d4cf4f73a4dd939750f7a066a HMAC-SHA-256-192: 0xa21b1f5d4cf4f73a4dd939750f7a066a 7f98cc131cb16a66 Test Case #2: HMAC-SHA-256 with 56-byte input and 32-byte key Key_len : 32 Key : 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 Data_len : 56 Data : "abcdbcdecdefdefgefghfghighijhijk ijkljklmklmnlmnomnopnopq" HMAC-SHA-256 : 0x104fdc1257328f08184ba73131c53cae e698e36119421149ea8c712456697d30 HMAC-SHA-256-128: 0x104fdc1257328f08184ba73131c53cae HMAC-SHA-256-192: 0x104fdc1257328f08184ba73131c53cae e698e36119421149 Kelly & Frankel Expires April 1, 2007 [Page 7] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 Test Case #3: HMAC-SHA-256 with 112-byte (multi-block) input and 32-byte key Key_len : 32 Key : 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 Data_len : 112 Data : "abcdbcdecdefdefgefghfghighijhijk ijkljklmklmnlmnomnopnopqabcdbcde cdefdefgefghfghighijhijkijkljklm klmnlmnomnopnopq" HMAC-SHA-256 : 0x470305fc7e40fe34d3eeb3e773d95aab 73acf0fd060447a5eb4595bf33a9d1a3 HMAC-SHA-256-128: 0x470305fc7e40fe34d3eeb3e773d95aab HMAC-SHA-256-192: 0x470305fc7e40fe34d3eeb3e773d95aab 73acf0fd060447a5 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 : 0x4869205468657265 Data : "Hi There" HMAC-SHA-256 : 0x198a607eb44bfbc69903a0f1cf2bbdc5 ba0aa3f3d9ae3c1c7a3b1696a0b68cf7 HMAC-SHA-256-128: 0x198a607eb44bfbc69903a0f1cf2bbdc5 HMAC-SHA-256-192: 0x198a607eb44bfbc69903a0f1cf2bbdc5 ba0aa3f3d9ae3c1c Test Case #5: HMAC-SHA-256 with 28-byte input and 4-byte key Key_len : 4 Key : "Jefe" Data_len : 28 Data : "what do ya want for nothing?" HMAC-SHA-256 : 0x5bdcc146bf60754e6a042426089575c7 5a003f089d2739839dec58b964ec3843 Kelly & Frankel Expires April 1, 2007 [Page 8] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 Test Case #6: HMAC-SHA-256 with 50-byte input and 32-byte key Key_len : 32 Key : 0xaa repeated 32 times Data_len : 50 Data : 0xdd repeated 50 times HMAC-SHA-256 : 0xcdcb1220d1ecccea91e53aba3092f962 e549fe6ce9ed7fdc43191fbde45c30b0 HMAC-SHA-256-128: 0xcdcb1220d1ecccea91e53aba3092f962 HMAC-SHA-256-192: 0xcdcb1220d1ecccea91e53aba3092f962 e549fe6ce9ed7fdc Test Case #7: HMAC-SHA-256 with 50-byte input and 37-byte key Key_len : 37 Key : 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 2122232425 Data_len : 50 Data : 0xcd repeated 50 times HMAC-SHA-256 : 0xd4633c17f6fb8d744c66dee0f8f07455 6ec4af55ef07998541468eb49bd2e917 Test Case #8: HMAC-SHA-256 with 20-byte input and 32-byte key Key_len : 32 Key : 0x0c repeated 32 times Data_len : 20 Data : "Test With Truncation" HMAC-SHA-256 : 0x7546af01841fc09b1ab9c3749a5f1c17 d4f589668a587b2700a9c97c1193cf42 HMAC-SHA-256-128: 0x7546af01841fc09b1ab9c3749a5f1c17 HMAC-SHA-256-192: 0x7546af01841fc09b1ab9c3749a5f1c17 d4f589668a587b27 Kelly & Frankel Expires April 1, 2007 [Page 9] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 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 - Hash Key First" HMAC-SHA-256 : 0x6953025ed96f0c09f80a96f78e6538db e2e7b820e3dd970e7ddd39091b32352f 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 : 73 Data : "Test Using Larger Than Block-Size Key and Larger Than One Block-Size Data" HMAC-SHA-256 : 0x6355ac22e890d0a3c8481a5ca4825bc8 84d3e7a1ff98a2fc2ac7d8e064c3b2e6 3. Security Considerations In a general sense, the security provided by the HMAC-SHA-256 algorithms is based both upon the strength of SHA-256, and upon the additional strength derived from the HMAC construct. At the time of this writing there are no practical cryptographic attacks against either SHA-256 or HMAC. However, as with any cryptographic algorithm, an important component of HMAC-SHA-256's 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 of HMAC-SHA-256 code, but these in no way verify the correctness (or security) of 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 the HMAC-SHA-256-128 and HMAC-SHA-256-192 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 Kelly & Frankel Expires April 1, 2007 [Page 10] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 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 or 192 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 either HMAC-SHA1 or 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 the HMAC-SHA-256 algorithms, with their 256-bit key lengths, provide more security in this regard than HMAC- SHA1 (with its 160-bit key length). 4. IANA Considerations For use of HMAC-SHA-256 as a PRF in IKEv2, IANA has assigned the following IKEv2 Pseudo-random function (type 2) transform identifier: [TBA-1] for PRF_HMAC_SHA2_256 For the use of the HMAC-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] for AUTH_HMAC_SHA2_256_128 [TBA-3] for AUTH_HMAC_SHA2_256_192 Kelly & Frankel Expires April 1, 2007 [Page 11] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 5. Acknowledgements Portions of this text were unabashedly borrowed from [HMAC-SHA1], and also from [XCBC-PRF]. Thanks to Hugo Krawczyk for comments and recommendations on early revisions of this document, and thanks to Russ Housley for 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. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [SHA2-1] NIST, "Draft FIPS PUB 180-2 'Specifications for the Secure Hash Standard'", 2001 MAY, . [SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512", 2001 MAY, . 6.2. Informative References [HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- SHA-1", RFC 2202, September 1997. [XCBC-PRF] Kelly & Frankel Expires April 1, 2007 [Page 12] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006. Authors' Addresses Scott G. Kelly Aruba Wireless Networks 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 Kelly & Frankel Expires April 1, 2007 [Page 13] Internet-Draft Using HMAC-SHA-256 With IPsec September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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). Kelly & Frankel Expires April 1, 2007 [Page 14]