< draft-kelly-ipsec-ciph-sha2-00.txt		draft-kelly-ipsec-ciph-sha2-01.txt >
	Network Working Group S. Kelly		Network Working Group S. Kelly
	Internet-Draft Aruba Wireless Networks		Internet-Draft Aruba Networks
	Intended status: Standards Track S. Frankel		Intended status: Standards Track S. Frankel
	Expires: April 1, 2007 NIST		Expires: July 9, 2007 NIST
	September 28, 2006		January 5, 2007
	Using HMAC-SHA-256 With IPsec		Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec
	draft-kelly-ipsec-ciph-sha2-00		draft-kelly-ipsec-ciph-sha2-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 1, 2007.		This Internet-Draft will expire on July 9, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2007).
	Abstract		Abstract
	This specification describes the use of the SHA-256 algorithm in		This specification describes the use of HMAC in conjunction with the
	conjunction with HMAC as a data origin authentication and integrity		SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms
	verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,		may be used as the basis for data origin authentication and integrity
	and also as a PRF for IKEv2. Two output truncation lengths are		verification mechanisms for the AH, ESP, IKE and IKEv2 protocols, and
	specified for data origin authentication and integrity verification		also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated
	usage, with the corresponding algorithms designated as HMAC-SHA-256-		output lengths are specified for the authentication-related variants,
	128 and HMAC-SHA-256-192. No truncation is specified for PRF usage,		with the corresponding algorithms designated as HMAC-SHA-256-128,
	and the resulting algorithm is designated as HMAC-SHA-PRF-256.		HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not
			truncated, and are called HMAC-SHA-PRF-256, HMAC-SHA-PRF-384, and
			HMAC-SHA-PRF-512.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The HMAC-SHA-256 Algorithms . . . . . . . . . . . . . . . . . 3		2. The HMAC-SHA-256+ Algorithms . . . . . . . . . . . . . . . . . 3
	2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3		2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3
	2.1.1. Data Origin Authentication and Integrity		2.1.1. Data Origin Authentication and Integrity
	Verification Usage . . . . . . . . . . . . . . . . . . 3		Verification Usage . . . . . . . . . . . . . . . . . . 4
	2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4		2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4
	2.1.3. Randomness and Key Strength . . . . . . . . . . . . . 4		2.1.3. Randomness and Key Strength . . . . . . . . . . . . . 5
	2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . . 4		2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . . 5
	2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . . 4		2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . . 5
	2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. Using HMAC-SHA-256 As a PRF in IKEv2 . . . . . . . . . . . 6		2.4. Using HMAC-SHA-256+ As PRFs in IKE and IKEv2 . . . . . . . 6
	2.5. Interactions with the ESP or IKEv2 Cipher Mechanisms . . . 6		2.5. Interactions with the ESP, IKE, or IKEv2 Cipher
	2.6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 6		Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 10		2.6. HMAC-SHA-256+ Parameter Summary . . . . . . . . . . . . . 7
	3.1. HMAC Key Length vs Truncation Length . . . . . . . . . . . 10		2.7. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		2.7.1. PRF Test Vectors . . . . . . . . . . . . . . . . . . . 7
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		2.7.2. Authenticator Test Vectors . . . . . . . . . . . . . . 11
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 12		3.1. HMAC Key Length vs Truncation Length . . . . . . . . . . . 17
	6.2. Informative References . . . . . . . . . . . . . . . . . . 12		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 14		6. Normative References . . . . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
			Intellectual Property and Copyright Statements . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document specifies the use of SHA-256 [SHA2-1] combined with		This document specifies the use of SHA-256, SHA-384, and SHA-512
	HMAC [HMAC] as a data origin authentication and integrity		[SHA2-1] combined with HMAC [HMAC] as data origin authentication and
	verification mechanism for the IPsec AH [AH], ESP [ESP], and IKEv2		integrity verification mechanisms for the IPsec AH [AH], ESP [ESP],
	[IKEv2] protocols. For flexibility, two output truncation lengths		IKE [IKE], and IKEv2 [IKEv2] protocols. Output truncation is
	are specified for the authentication-related variants, with the		specified for these variants, with the corresponding algorithms
	corresponding algorithms designated as HMAC-SHA-256-128 and HMAC-SHA-		designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-
	256-192. In addition, this document specifies use of the underlying		256. These truncation lengths are chosen in accordance with the
	HMAC-SHA-256 algorithm (without truncation) as a PRF within IKEv2,		birthday bound for each algorithm.
	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		This specification also describes untruncated variants of these
	function suitable for generation of keying material and other		algorithms as PRFs for use with IKE and IKEv2, and those 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 "the
			HMAC-SHA-256+ algorithms."
			The goal of the PRF variants is to provide secure pseudo-random
			functions suitable for generation of keying material and other
	protocol-specific numeric quantities, while the goal of the		protocol-specific numeric quantities, while the goal of the
	authentication variants is to ensure that packets are authentic and		authentication variants is to ensure that packets are authentic and
	cannot be modified in transit. The relative security of HMAC-SHA-256		cannot be modified in transit. The relative security of HMAC-SHA-
	when used in either case is dependent on the scope of distribution		256+ when used in either case is dependent on the distribution scope
	and the unpredictability of the associated secret key. If the key is		and unpredictability of the associated secret key. If the key is
	not predictable and known only by the source and destination, these		unpredictable and known only by the sender and recipient, these
	algorithms ensure that only parties holding an identical key can		algorithms ensure that only parties holding an identical key can
	derive the associated values.		derive the associated values.
	2. The HMAC-SHA-256 Algorithms		2. The HMAC-SHA-256+ Algorithms
	[SHA2-1] and [SHA2-2] describe the underlying SHA-256 algorithm,		[SHA2-1] and [SHA2-2] describe the underlying SHA-256, SHA-384, and
	while [HMAC] describes the HMAC algorithm. The HMAC algorithm		SHA-512 algorithms, while [HMAC] describes the HMAC algorithm. The
	provides a framework for inserting various hashing algorithms such as		HMAC algorithm provides a framework for inserting various hashing
	SHA-256. The following sections describe the various characteristics		algorithms such as SHA-256, and [SHA256+] describes combined usage of
	and requirements of the HMAC-SHA-256 algorithms.		these algorithms. The following sections describe the various
			characteristics and requirements of the HMAC-SHA-256+ algorithms when
			used with IPsec.
	2.1. Keying Material		2.1. Keying Material
	Requirements for keying material vary depending on usage. These		Requirements for keying material vary depending on whether the
	distinctions are described in the following sections.		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 the 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 Usage		2.1.1. Data Origin Authentication and Integrity Verification Usage
	HMAC-SHA-256 is a secret key algorithm. While no fixed key length is		HMAC-SHA-256+ are secret key algorithms. While no fixed key length
	specified in [HMAC], this specification requires that for use as an		is specified in [HMAC], this specification requires that when used as
	integrity algorithm, a fixed key length of 256-bits MUST be		an integrity/authentication algorithm, a fixed key length equal to
	supported, and key lengths other than 256-bits MUST NOT be supported.		the output length of the hash functions MUST be supported, and key
	The 256-bit key length is chosen based on the recommendations in		lengths other than the output length of the associated hash function
	[HMAC] (i.e. key lengths less than the authenticator length decrease		MUST NOT be supported.
	security strength and keys longer than the authenticator length do
	not significantly increase security strength).		These key length restrictions are based in part on the
			recommendations in [HMAC] (key lengths less than the output length
			decrease security strength, and keys longer than the output length do
			not significantly increase security 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		2.1.2. Pseudo-Random Function (PRF) Usage
	IKEv2 uses PRFs for multiple purposes, most notably for generating		IKE and IKEv2 use PRFs for generating keying material and for
	keying material and authentication of the IKE_SA. The IKEv2		authentication of the IKE_SA. The IKEv2 specification differentiates
	specification differentiates between PRFs with fixed key sizes and		between PRFs with fixed key sizes and those with variable key sizes,
	those with variable key sizes.		and so we give some special guidance for this below.
	When the PRF described in this document is used with IKEv2, it is		When a PRF described in this document is used with IKE or IKEv2, it
	considered to have a variable key length, and keys are derived in the		is considered to have a variable key length, and keys are derived in
	following way (as specified in [HMAC]):		the following ways (note that we simply reiterate that which is
			specified in [HMAC]):
	o If the key is exactly 256 bits long, use it as-is.		o If the length of the key is exactly the algorithm block size, use
			it as-is.
	o If the key has fewer than 256 bits, lengthen it to exactly 256		o If the key is shorter than the block size, lengthen it to exactly
	bits by padding it on the right with zero bits. However, note		the block size by padding it on the right with zero bits.
	that [HMAC] strongly discourages a key length less than 256 bits.		However, note that [HMAC] strongly discourages a key length less
			than 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 is 257 bits or longer, shorten it to exactly 256 bits		o If the key is longer than the block size, shorten it by computing
	by computing the SHA2-256 hash of the entire key value, and use		the corresponding hash algorithm output over the entire key value,
	the resulting output value as your HMAC key.		and treat 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		2.1.3. Randomness and Key Strength
	[HMAC] discusses requirements for key material, including a		[HMAC] discusses requirements for key material, including a
	requirement for strong randomness. Therefore, a strong pseudo-random		requirement for strong randomness. Therefore, a strong pseudo-random
	function MUST be used to generate the required 256-bit key for use		function MUST be used to generate the required key for use with HMAC-
	with either HMAC-SHA-256-128 or HMAC-SHA-256-192. At the time of		SHA-256+. At the time of this writing there are no published weak
	this writing there are no published weak keys for use with HMAC-SHA-		keys for use with any HMAC-SHA-256+ algorithms.
	256.
	2.1.4. Key Distribution		2.1.4. Key Distribution
	[ARCH] describes the general mechanism for obtaining keying material		[ARCH] describes the general mechanism for obtaining keying material
	when multiple keys are required for a single SA (e.g. when an ESP SA		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		requires a key for confidentiality and a key for authentication). In
	order to provide data origin authentication and integrity		order to provide data origin authentication and integrity
	verification, the key distribution mechanism must ensure that unique		verification, the key distribution mechanism must ensure that unique
	keys are allocated and that they are distributed only to the parties		keys are allocated and that they are distributed only to the parties
	participating in the communication.		participating in the communication.
	2.1.5. Refreshing Keys		2.1.5. Refreshing Keys
	[HMAC] makes the following recommendation with regard to rekeying:		There are no currently practical attacks against the algorithms
	"Current attacks do not indicate a specific recommended frequency for		recommended here, and especially against the key sizes recommended
	key changes ... However, periodic key refreshment is a fundamental		here. However, as noted in [HMAC] "...periodic key refreshment is a
	security practice that helps against potential weaknesses of the		fundamental security practice that helps against potential weaknesses
	function and keys, and limits the damage of an exposed key."		of the function and keys, and limits the damage of an exposed key."
	Putting this into perspective, this specification requires 256-bit
	keys produced by a strong PRF for use as a MAC. A brute force attack		Putting this into perspective, this specification requires 256, 384,
	on such keys would take more years to mount than the universe has		or 512-bit keys produced by a strong PRF for use as a MAC. A brute
	been in existence. On the other hand, weak keys (e.g. dictionary		force attack on such keys would take longer to mount than the
	words) would be dramatically less resistant to attack. It is		universe has been in existence. On the other hand, weak keys (e.g.
	important to take this, along with the threat model for your		dictionary words) would be dramatically less resistant to attack. It
	particular application and the current state of the art with respect		is important to take these points, along with the specific threat
	to attacks on SHA-256, into account when determining an appropriate		model for your particular application and the current state of the
	upper bound for HMAC key lifetimes		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		2.2. Padding
	The HMAC-SHA-256 algorithms operate on 512-bit blocks of data.		The HMAC-SHA-256 algorithms operate on 512-bit blocks of data, while
	Padding requirements are specified in [SHA2-1] and are part of the		the HMAC-SHA-384 and HMAC-SHA-512 algorithms operate on 1024-bit
	SHA-256 algorithm, so if you build SHA-256 according to [SHA2-1], you		blocks of data. Padding requirements are specified in [SHA2-1] as
	do not need to add any additional padding as far as the HMAC-SHA-256		part of the underlying SHA-256, SHA-384, and SHA-512 algorithms, so
	algorithms specified here are concerned. With regard to "implicit		if you implement according to [SHA2-1], you do not need to add any
	packet padding" as defined in [AH], no implicit packet padding is		additional padding as far as the HMAC-SHA-256+ algorithms specified
	required.		here are concerned. With regard to "implicit packet padding" as
			defined in [AH], no implicit packet padding is required.
	2.3. Truncation		2.3. Truncation
	The HMAC-SHA-256 algorithms produce a 256-bit authenticator value,		The HMAC-SHA-256+ algorithms each produce a nnn-bit value, where nnn
	and this 256-bit value can be truncated as described in [HMAC]. When		corresponds to the output bit length of the algorithm, e.g. HMAC-
	used as a data origin authentication and integrity verification		SHA-nnn. For use as an authenticator, this nnn-bit value can be
	algorithm in ESP, AH, or IKEv2, a truncated value using the first 128		truncated as described in [HMAC]. When used as a data origin
	or 192 bits MUST be supported. No other authenticator value lengths		authentication and integrity verification algorithm in ESP, AH, IKE,
	are supported by this specification.		or IKEv2, a truncated value using the first nnn/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		Upon sending, the truncated value is stored within the authenticator
	field. Upon receipt, the entire 256-bit value is computed and the		field. Upon receipt, the entire nnn-bit value is computed and the
	first 128 or 192 bits are compared to the value stored in the		first nnn/2 bits are compared to the value stored in the
	authenticator field, depending on whether the negotiated algorithm is		authenticator field, with the value of 'nnn' depending on the
	HMAC-SHA-256-128 or HMAC-SHA-256-192.		negotiated algorithm.
	[HMAC] discusses potential security benefits resulting from		[HMAC] discusses potential security benefits resulting from
	truncation of the output MAC value, and in general, encourages HMAC		truncation of the output MAC value, and in general, encourages HMAC
	users to perform MAC truncation. In the context of IPsec, a minimum		users to perform MAC truncation. In the context of IPsec, a
	truncation length of 128 bits is selected because it corresponds to		truncation length of nnn/2 bits is selected because it corresponds to
	the birthday attack bound, and it simultaneously serves to minimize		the birthday attack bound for each of the HMAC-SHA-256+ algorithms,
	the additional bits on the wire resulting from use of this facility.		and it simultaneously serves to minimize the additional bits on the
	This specification also defines a truncation length of 192 in order		wire resulting from use of this facility.
	to provide an alternative to those whose security needs outweigh
	their concern for minimizing bits on the wire.
	2.4. Using HMAC-SHA-256 As a PRF in IKEv2		2.4. Using HMAC-SHA-256+ As PRFs in IKE and IKEv2
	The HMAC-SHA-PRF-256 algorithm is identical to HMAC-SHA-256-128 and		The HMAC-SHA-PRF-256 algorithm is identical to HMAC-SHA-256-128,
	HMAC-SHA-256-192 except that variable-length keys are permitted, and		except that variable-length keys are permitted, and the truncation
	the truncation step is NOT performed. The test vectors below which		step is NOT performed. Likewise, the implementations of HMAC-SHA-
	are simply labeled HMAC-SHA-256 may be used to validate		PRF-384 and HMAC-SHA-PRF-512 are identical to those of HMAC-SHA-384-
	implementations of HMAC-SHA-PRF-256.		192 and HMAC-SHA-512-256 respectively, except that again, truncation
			is NOT performed.
	2.5. Interactions with the ESP or IKEv2 Cipher Mechanisms		2.5. Interactions with the ESP, IKE, or IKEv2 Cipher Mechanisms
	As of this writing, there are no known issues which preclude the use		As of this writing, there are no known issues which preclude the use
	of the HMAC-SHA-256 algorithms with any specific cipher algorithm.		of the HMAC-SHA-256+ algorithms with any specific cipher algorithm.
	2.6. Test Vectors		2.6. HMAC-SHA-256+ Parameter Summary
	The following test cases for HMAC-SHA-256-192 and HMAC-SHA-256-128		The following table serves to summarize the various quantities
	include the key, the data, and the resulting HMAC. The values of		associated with the HMAC-SHA-256+ algorithms.
	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		| Algorithm | Block | Output | Trunc. | Key | Algorithm |
	(http://www.adg.us/computers/sha.html), the BeeCrypt crypto library		| ID | Size | Length | Length | Length | Type |
	(http://beecrypt.sourceforge.net/) and the Nettle cryptographic		+==================+========+========+========+==========+============+
	library (www.lysator.liu.se/~nisse/nettle). Partial blocks were		| HMAC-SHA-256-128 | 512 | 256 | 128 | 256 | auth/integ |
	padded as specified in [SHA2-1].		+------------------+--------+--------+--------+----------+------------+
			| 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 |
			+------------------+--------+--------+--------+----------+------------+
	Test cases 1 and 2 were taken from the SHA-2 FIPS [SHA2-1] and test		2.7. Test Vectors
	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.
	Test Case #1: HMAC-SHA-256 with 3-byte input and 32-byte key		The following test cases include the key, the data, and the resulting
	Key_len : 32		authenticator and/or PRF values for each algorithm. The values of
	Key : 0x0102030405060708090a0b0c0d0e0f10		keys and data are either ASCII character strings (surrounded by
	1112131415161718191a1b1c1d1e1f20		double quotes) or hexadecimal numbers. If a value is an ASCII
	Data_len : 3		character string, then the HMAC computation for the corresponding
	Data : "abc"		test case DOES NOT include the trailing null character ('\0') of the
			string. The computed HMAC values are all hexadecimal numbers.
	HMAC-SHA-256 : 0xa21b1f5d4cf4f73a4dd939750f7a066a		2.7.1. PRF Test Vectors
	7f98cc131cb16a6692759021cfab8181
	HMAC-SHA-256-128: 0xa21b1f5d4cf4f73a4dd939750f7a066a		These test cases were borrowed from RFC 4231 [HMAC-TEST]. For
			reference implementations of the underlying hash algorithms, see
			[SHA256+]. Note that for testing purposes, PRF output is considered
			to be simply the untruncated algorithm output.
	HMAC-SHA-256-192: 0xa21b1f5d4cf4f73a4dd939750f7a066a		Test Case PRF-1:
	7f98cc131cb16a66		Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
			0b0b0b0b (20 bytes)
	Test Case #2: HMAC-SHA-256 with 56-byte input and 32-byte key		Data = 4869205468657265 ("Hi There")
	Key_len : 32
	Key : 0x0102030405060708090a0b0c0d0e0f10
	1112131415161718191a1b1c1d1e1f20
	Data_len : 56
	Data : "abcdbcdecdefdefgefghfghighijhijk
	ijkljklmklmnlmnomnopnopq"
	HMAC-SHA-256 : 0x104fdc1257328f08184ba73131c53cae		HMAC-SHA-256-PRF = b0344c61d8db38535ca8afceaf0bf12b
	e698e36119421149ea8c712456697d30		881dc200c9833da726e9376c2e32cff7
	HMAC-SHA-256-128: 0x104fdc1257328f08184ba73131c53cae		HMAC-SHA-384-PRF = afd03944d84895626b0825f4ab46907f
			15f9dadbe4101ec682aa034c7cebc59c
			faea9ea9076ede7f4af152e8b2fa9cb6
	HMAC-SHA-256-192: 0x104fdc1257328f08184ba73131c53cae		HMAC-SHA-512-PRF = 87aa7cdea5ef619d4ff0b4241a1d6cb0
	e698e36119421149		2379f4e2ce4ec2787ad0b30545e17cde
			daa833b7d6b8a702038b274eaea3f4e4
			be9d914eeb61f1702e696c203a126854
	Test Case #3: HMAC-SHA-256 with 112-byte (multi-block) input		Test Case PRF-2:
	and 32-byte key		Key = 4a656665 ("Jefe")
	Key_len : 32
	Key : 0x0102030405060708090a0b0c0d0e0f10
	1112131415161718191a1b1c1d1e1f20
	Data_len : 112
	Data : "abcdbcdecdefdefgefghfghighijhijk
	ijkljklmklmnlmnomnopnopqabcdbcde
	cdefdefgefghfghighijhijkijkljklm
	klmnlmnomnopnopq"
	HMAC-SHA-256 : 0x470305fc7e40fe34d3eeb3e773d95aab		Data = 7768617420646f2079612077616e7420 ("what do ya want ")
	73acf0fd060447a5eb4595bf33a9d1a3		666f72206e6f7468696e673f ("for nothing?")
	HMAC-SHA-256-128: 0x470305fc7e40fe34d3eeb3e773d95aab		HMAC-SHA-256-PRF = 5bdcc146bf60754e6a042426089575c7
			5a003f089d2739839dec58b964ec3843
	HMAC-SHA-256-192: 0x470305fc7e40fe34d3eeb3e773d95aab		HMAC-SHA-384-PRF = af45d2e376484031617f78d2b58a6b1b
	73acf0fd060447a5		9c7ef464f5a01b47e42ec3736322445e
			8e2240ca5e69e2c78b3239ecfab21649
	Test Case #4: HMAC-SHA-256 with 8-byte input and 32-byte key		HMAC-SHA-512-PRF = 164b7a7bfcf819e2e395fbe73b56e0a3
	Key_len : 32		87bd64222e831fd610270cd7ea250554
	Key : 0x0b repeated 32 times		9758bf75c05a994a6d034f65f8f0e6fd
	Data_len : 8		caeab1a34d4a6b4b636e070a38bce737
	Data : 0x4869205468657265
	Data : "Hi There"
	HMAC-SHA-256 : 0x198a607eb44bfbc69903a0f1cf2bbdc5		Test Case PRF-3:
	ba0aa3f3d9ae3c1c7a3b1696a0b68cf7		Key aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaa (20 bytes)
	HMAC-SHA-256-128: 0x198a607eb44bfbc69903a0f1cf2bbdc5		Data = dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddd (50 bytes)
	HMAC-SHA-256-192: 0x198a607eb44bfbc69903a0f1cf2bbdc5		HMAC-SHA-256-PRF = 773ea91e36800e46854db8ebd09181a7
	ba0aa3f3d9ae3c1c		2959098b3ef8c122d9635514ced565fe
	Test Case #5: HMAC-SHA-256 with 28-byte input and 4-byte key		HMAC-SHA-384-PRF = 88062608d3e6ad8a0aa2ace014c8a86f
	Key_len : 4		0aa635d947ac9febe83ef4e55966144b
	Key : "Jefe"		2a5ab39dc13814b94e3ab6e101a34f27
	Data_len : 28
	Data : "what do ya want for nothing?"
	HMAC-SHA-256 : 0x5bdcc146bf60754e6a042426089575c7		HMAC-SHA-512-PRF = fa73b0089d56a284efb0f0756c890be9
	5a003f089d2739839dec58b964ec3843		b1b5dbdd8ee81a3655f83e33b2279d39
			bf3e848279a722c806b485a47e67c807
			b946a337bee8942674278859e13292fb
	Test Case #6: HMAC-SHA-256 with 50-byte input and 32-byte key		Test Case PRF-4:
	Key_len : 32		Key = 0102030405060708090a0b0c0d0e0f10
	Key : 0xaa repeated 32 times		111213141516171819 (25 bytes)
	Data_len : 50
	Data : 0xdd repeated 50 times
	HMAC-SHA-256 : 0xcdcb1220d1ecccea91e53aba3092f962		Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
	e549fe6ce9ed7fdc43191fbde45c30b0		cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
			cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
			cdcd (50 bytes)
	HMAC-SHA-256-128: 0xcdcb1220d1ecccea91e53aba3092f962		HMAC-SHA-256-PRF = 82558a389a443c0ea4cc819899f2083a
			85f0faa3e578f8077a2e3ff46729665b
	HMAC-SHA-256-192: 0xcdcb1220d1ecccea91e53aba3092f962		HMAC-SHA-384-PRF = 3e8a69b7783c25851933ab6290af6ca7
	e549fe6ce9ed7fdc		7a9981480850009cc5577c6e1f573b4e
			6801dd23c4a7d679ccf8a386c674cffb
	Test Case #7: HMAC-SHA-256 with 50-byte input and 37-byte key		HMAC-SHA-512-PRF = b0ba465637458c6990e5a8c5f61d4af7
	Key_len : 37		e576d97ff94b872de76f8050361ee3db
	Key : 0x0102030405060708090a0b0c0d0e0f10		a91ca5c11aa25eb4d679275cc5788063
	1112131415161718191a1b1c1d1e1f20		a5f19741120c4f2de2adebeb10a298dd
	2122232425
	Data_len : 50
	Data : 0xcd repeated 50 times
	HMAC-SHA-256 : 0xd4633c17f6fb8d744c66dee0f8f07455		Test Case PRF-5:
	6ec4af55ef07998541468eb49bd2e917		Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaa (131 bytes)
	Test Case #8: HMAC-SHA-256 with 20-byte input and 32-byte key		Data = 54657374205573696e67204c61726765 ("Test Using Large")
	Key_len : 32		72205468616e20426c6f636b2d53697a ("r Than Block-Siz")
	Key : 0x0c repeated 32 times		65204b6579202d2048617368204b6579 ("e Key - Hash Key")
	Data_len : 20		204669727374 (" First")
	Data : "Test With Truncation"
	HMAC-SHA-256 : 0x7546af01841fc09b1ab9c3749a5f1c17		HMAC-SHA-256-PRF = 60e431591ee0b67f0d8a26aacbf5b77f
	d4f589668a587b2700a9c97c1193cf42		8e0bc6213728c5140546040f0ee37f54
	HMAC-SHA-256-128: 0x7546af01841fc09b1ab9c3749a5f1c17		HMAC-SHA-384-PRF = 4ece084485813e9088d2c63a041bc5b4
			4f9ef1012a2b588f3cd11f05033ac4c6
			0c2ef6ab4030fe8296248df163f44952
	HMAC-SHA-256-192: 0x7546af01841fc09b1ab9c3749a5f1c17		HMAC-SHA-512-PRF = 80b24263c7c1a3ebb71493c1dd7be8b4
	d4f589668a587b27		9b46d1f41b4aeec1121b013783f8f352
			6b56d037e05f2598bd0fd2215d6a1e52
			95e64f73f63f0aec8b915a985d786598
	Test Case #9: HMAC-SHA-256 with 54-byte input and 80-byte key		Test Case PRF-6:
	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		Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
	e2e7b820e3dd970e7ddd39091b32352f		aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaa (131 bytes)
	Test Case #10: HMAC-SHA-256 with 73-byte (multi-block) input		Data = 54686973206973206120746573742075 ("This is a test u")
	and 80-byte key		73696e672061206c6172676572207468 ("sing a larger th")
	Key_len : 80		616e20626c6f636b2d73697a65206b65 ("an block-size ke")
	Key : 0xaa repeated 80 times		7920616e642061206c61726765722074 ("y and a larger t")
	Data_len : 73		68616e20626c6f636b2d73697a652064 ("han block-size d")
	Data : "Test Using Larger Than Block-Size Key and		6174612e20546865206b6579206e6565 ("ata. The key nee")
	Larger Than One Block-Size Data"		647320746f2062652068617368656420 ("ds to be hashed ")
			6265666f7265206265696e6720757365 ("before being use")
			642062792074686520484d414320616c ("d by the HMAC al")
			676f726974686d2e ("gorithm.")
	HMAC-SHA-256 : 0x6355ac22e890d0a3c8481a5ca4825bc8		HMAC-SHA-256-PRF = 9b09ffa71b942fcb27635fbcd5b0e944
	84d3e7a1ff98a2fc2ac7d8e064c3b2e6		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 cases for HMAC-SHA256-128, HMAC-
			SHA384-192, and HMAC-SHA512-256. PRF outputs are also included for
			convenience. These test cases were generated using the SHA256+
			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-128 = 198a607eb44bfbc69903a0f1cf2bbdc5
			Test Case AUTH256-2:
			Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
			4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
			Data = 7768617420646f2079612077616e7420 ("what do ya want ")
			666f72206e6f7468696e673f ("for nothing?")
			HMAC-SHA-256-PRF = 167f928588c5cc2eef8e3093caa0e87c
			9ff566a14794aa61648d81621a2a40c6
			HMAC-SHA-256-128 = 167f928588c5cc2eef8e3093caa0e87c
			Test Case AUTH256-3:
			Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (32 bytes)
			Data = dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddd (50 bytes)
			HMAC-SHA-256-PRF = cdcb1220d1ecccea91e53aba3092f962
			e549fe6ce9ed7fdc43191fbde45c30b0
			HMAC-SHA-256-128 = cdcb1220d1ecccea91e53aba3092f962
			Test Case AUTH256-4:
			Key = 0102030405060708090a0b0c0d0e0f10
			1112131415161718191a1b1c1d1e1f20 (32 bytes)
			Data = 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 AUTH384-1:
			Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
			0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
			0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (48 bytes)
			Data = 4869205468657265 ("Hi There")
			HMAC-SHA-384-PRF = b6a8d5636f5c6a7224f9977dcf7ee6c7
			fb6d0c48cbdee9737a959796489bddbc
			4c5df61d5b3297b4fb68dab9f1b582c2
			HMAC-SHA-384-128 = b6a8d5636f5c6a7224f9977dcf7ee6c7
			fb6d0c48cbdee973
			Test Case AUTH384-2:
			Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
			4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
			4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
			Data = 7768617420646f2079612077616e7420 ("what do ya want ")
			666f72206e6f7468696e673f ("for nothing?")
			HMAC-SHA-384-PRF = 2c7353974f1842fd66d53c452ca42122
			b28c0b594cfb184da86a368e9b8e16f5
			349524ca4e82400cbde0686d403371c9
			HMAC-SHA-384-192 = 2c7353974f1842fd66d53c452ca42122
			b28c0b594cfb184d
			Test Case AUTH384-3:
			Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (48 bytes)
			Data = dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddd (50 bytes)
			HMAC-SHA-384-PRF = 809f439be00274321d4a538652164b53
			554a508184a0c3160353e3428597003d
			35914a18770f9443987054944b7c4b4a
			HMAC-SHA-384-192 = 809f439be00274321d4a538652164b53
			554a508184a0c316
			Test Case AUTH384-4:
			Key = 0102030405060708090a0b0c0d0e0f10
			1112131415161718191a1b1c1d1e1f20
			0a0b0c0d0e0f10111213141516171819 (48 bytes)
			Data = 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 AUTH512-1:
			Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
			0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
			0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
			0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (64 bytes)
			Data = 4869205468657265 ("Hi There")
			HMAC-SHA-512-PRF = 637edc6e01dce7e6742a99451aae82df
			23da3e92439e590e43e761b33e910fb8
			ac2878ebd5803f6f0b61dbce5e251ff8
			789a4722c1be65aea45fd464e89f8f5b
			HMAC-SHA-512-256 = 637edc6e01dce7e6742a99451aae82df
			23da3e92439e590e43e761b33e910fb8
			Test Case AUTH512-2:
			Key = 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 AUTH512-3:
			Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (64 bytes)
			Data = dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddddddddddddddddddddddddddddddd
			dddd (50 bytes)
			HMAC-SHA-512-PRF = 2ee7acd783624ca9398710f3ee05ae41
			b9f9b0510c87e49e586cc9bf961733d8
			623c7b55cebefccf02d5581acc1c9d5f
			b1ff68a1de45509fbe4da9a433922655
			HMAC-SHA-512-256 = 2ee7acd783624ca9398710f3ee05ae41
			b9f9b0510c87e49e586cc9bf961733d8
			Test Case AUTH512-4:
			Key = 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		3. Security Considerations
	In a general sense, the security provided by the HMAC-SHA-256		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		algorithms is based both upon the strength of the underlying hash
	additional strength derived from the HMAC construct. At the time of		algorithm, and upon the additional strength derived from the HMAC
	this writing there are no practical cryptographic attacks against		construct. At the time of this writing there are no practical
	either SHA-256 or HMAC. However, as with any cryptographic		cryptographic attacks against SHA-256, SHA-384, SHA-512 or HMAC.
	algorithm, an important component of HMAC-SHA-256's strength lies in		However, as with any cryptographic algorithm, an important component
	the correctness of the algorithm implementation, the security of the		of these algorithms' strength lies in the correctness of the
	key management mechanism, the strength of the associated secret key,		algorithm implementation, the security of the key management
	and upon the correctness of the implementation in all of the		mechanism, the strength of the associated secret key, and upon the
	participating systems. This specification contains test vectors to		correctness of the implementation in all of the participating
	assist in verifying the correctness of HMAC-SHA-256 code, but these		systems. This specification contains test vectors to assist in
	in no way verify the correctness (or security) of surrounding		verifying the correctness of the algorithm implementation, but these
			in no way verify the correctness (or security) of the surrounding
	security infrastructure.		security infrastructure.
	3.1. HMAC Key Length vs Truncation Length		3.1. HMAC Key Length vs Truncation Length
	There are important differences between the security levels afforded		There are important differences between the security levels afforded
	by HMAC-SHA1-96 and the HMAC-SHA-256-128 and HMAC-SHA-256-192		by HMAC-SHA1-96 and the HMAC-SHA-256+ algorithms, but there are also
	algorithms, but there are also considerations which are somewhat		considerations which are somewhat counter-intuitive. There are two
	counter-intuitive. There are two different axes along which we gauge		different axes along which we gauge the security of these algorithms:
	the security of these algorithms: HMAC output length and HMAC key		HMAC output length and HMAC key length. If we assume the HMAC key is
	length. If we assume the HMAC key is a well-guarded secret which can		a well-guarded secret which can only be determined through offline
	only be determined through offline attacks on observed values, and		attacks on observed values, and that its length is less than or equal
	that its length is less than or equal to the output length of the		to the output length of the underlying hash algorithm, then the key's
	underlying hash algorithm, then the key's strength is directly		strength is directly proportional to its length. And if we assume an
	proportional to its length. And if we assume an adversary has no		adversary has no knowledge of the HMAC key, then the probability of
	knowledge of the HMAC key, then the probability of guessing a correct		guessing a correct MAC value for any given packet is directly
	MAC value for any given packet is directly proportional to the HMAC		proportional to the HMAC output length.
	output length.
	This specification defines truncation to output lengths of either 128		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		192, or 256 bits. It is important to note that at this time, it is
	clear that HMAC-SHA-256 with a truncation length of 128 bits is any		not clear that HMAC-SHA-256 with a truncation length of 128 bits is
	more secure than HMAC-SHA1 with the same truncation length, assuming		any more secure than HMAC-SHA1 with the same truncation length,
	the adversary has no knowledge of the HMAC key. This is because in		assuming the adversary has no knowledge of the HMAC key. This is
	such cases, the adversary must predict only those bits which remain		because in such cases, the adversary must predict only those bits
	after truncation. Since in both cases that output length is the same		which remain after truncation. Since in both cases that output
	(128 bits), the adversary's odds of correctly guessing the value are		length is the same (128 bits), the adversary's odds of correctly
	also the same in either case: 1 in 2^128. Again, if we assume the		guessing the value are also the same in either case: 1 in 2^128.
	HMAC key remains unknown to the attacker, then only a bias in one of		Again, if we assume the HMAC key remains unknown to the attacker,
	the algorithms would distinguish one from the other. Currently, no		then only a bias in one of the algorithms would distinguish one from
	such bias is known to exist in either HMAC-SHA1 or HMAC-SHA-256.		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		If, on the other hand, the attacker is focused on guessing the HMAC
	key, and we assume that the hash algorithms are indistinguishable		key, and we assume that the hash algorithms are indistinguishable
	when viewed as PRF's, then the HMAC key length provides a direct		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		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		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		HMAC key, size matters - and the HMAC-SHA-256+ algorithms provide
	256-bit key lengths, provide more security in this regard than HMAC-		more security in this regard than HMAC-SHA1-96.
	SHA1 (with its 160-bit key length).
	4. IANA Considerations		4. IANA Considerations
	For use of HMAC-SHA-256 as a PRF in IKEv2, IANA has assigned the		This document does not specify the conventions for using SHA256+ for
	following IKEv2 Pseudo-random function (type 2) transform identifier:		IKE Phase 1 negotiations. For IKE Phase 2 negotiations, IANA has
			assigned the following authentication algorithm identifiers:
	[TBA-1] for PRF_HMAC_SHA2_256		HMAC-SHA2-256: 5
	For the use of the HMAC-SHA-256 algorithms for data origin		HMAC-SHA2-384: 6
			HMAC-SHA2-512: 7
			For use of HMAC-SHA-256+ as a PRF in IKEv2, IANA has assigned the
			following IKEv2 Pseudo-random function (type 2) transform
			identifiers:
			PRF_HMAC_SHA2_256 [TBA-1]
			PRF_HMAC_SHA2_384 [TBA-2]
			PRF_HMAC_SHA2_512 [TBA-3]
			For the use of HMAC-SHA-256+ algorithms for data origin
	authentication and integrity verification in IKEv2, ESP or AH, IANA		authentication and integrity verification in IKEv2, ESP or AH, IANA
	has assigned the following IKEv2 integrity (type 3) transform		has assigned the following IKEv2 integrity (type 3) transform
	identifiers:		identifiers:
	[TBA-2] for AUTH_HMAC_SHA2_256_128		AUTH_HMAC_SHA2_256_128 [TBA-4]
	[TBA-3] for AUTH_HMAC_SHA2_256_192		AUTH_HMAC_SHA2_384_192 [TBA-5]
			AUTH_HMAC_SHA2_512_256 [TBA-6]
	5. Acknowledgements		5. Acknowledgements
	Portions of this text were unabashedly borrowed from [HMAC-SHA1], and		Portions of this text were unabashedly borrowed from [HMAC-SHA1], and
	also from [XCBC-PRF]. Thanks to Hugo Krawczyk for comments and		from [HMAC-TEST]. Thanks to Hugo Krawczyk for comments and
	recommendations on early revisions of this document, and thanks to		recommendations on early revisions of this document, and thanks also
	Russ Housley for security-related comments and recommendations.		to Russ Housley and Steve Bellovin for various security-related
			comments and recommendations.
	6. References
	6.1. Normative References		6. Normative References
	[AH] Kent, S., "IP Authentication Header", RFC 4302,		[AH] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005.		December 2005.
	[ARCH] Kent, S. and K. Seo, "Security Architecture for the		[ARCH] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",		[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	[HMAC-SHA1]		[HMAC-SHA1]
	Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within		Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
	ESP and AH", RFC 2404, November 1998.		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",		[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[SHA2-1] NIST, "Draft FIPS PUB 180-2 'Specifications for the Secure		[SHA2-1] NIST, "FIPS PUB 180-2 'Specifications for the Secure Hash
	Hash Standard'", 2001 MAY, <http://csrc.nist.gov/		Standard'", 2004 FEB, <http://csrc.nist.gov/publications/
	publications/fips/fips180-2/		fips/fips180-2/fips180-2withchangenotice.pdf>.
	fips180-2withchangenotice.pdf>.
	[SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",		[SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",
	2001 MAY,		2001 MAY,
	<http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.		<http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.
	6.2. Informative References		[SHA256+] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
			(SHA and HMAC-SHA)", RFC 4634, July 2006.
	[HMAC-TEST]
	Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
	SHA-1", RFC 2202, September 1997.
	[XCBC-PRF]
	Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
	Internet Key Exchange Protocol (IKE)", RFC 4434,
	February 2006.
	Authors' Addresses		Authors' Addresses
	Scott G. Kelly		Scott G. Kelly
	Aruba Wireless Networks		Aruba Networks
	1322 Crossman Ave		1322 Crossman Ave
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	US		US
	Email: scott@hyperthought.com		Email: scott@hyperthought.com
	Sheila Frankel		Sheila Frankel
	NIST		NIST
	Bldg. 222 Room B264		Bldg. 222 Room B264
	Gaithersburg, MD 20899		Gaithersburg, MD 20899
	US		US
	Email: sheila.frankel@nist.gov		Email: sheila.frankel@nist.gov
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
End of changes. 84 change blocks.
	321 lines changed or deleted		600 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/