< draft-ietf-ipsec-auth-hmac-sha196-01.txt		draft-ietf-ipsec-auth-hmac-sha196-02.txt >
	Network Working Group IPsec Working Group		Network Working Group IPsec Working Group
	INTERNET DRAFT C. Madson		INTERNET DRAFT C. Madson
	Expire in six months Cisco Systems Inc.		Expire in six months Cisco Systems Inc.
	R. Glenn		R. Glenn
	NIST		NIST
	November 1997		February 1998
	The Use of HMAC-SHA-1-96 within ESP and AH		The Use of HMAC-SHA-1-96 within ESP and AH
	<draft-ietf-ipsec-auth-hmac-sha196-01.txt>		<draft-ietf-ipsec-auth-hmac-sha196-02.txt>
	Status of this Memo		Status of this Memo
	This document is a submission to the IETF Internet Protocol Security		This document is a submission to the IETF Internet Protocol Security
	(IPSEC) Working Group. Comments are solicited and should be addressed		(IPSEC) Working Group. Comments are solicited and should be addressed
	to the working group mailing list (ipsec@tis.com) or to the editor.		to the working group mailing list (ipsec@tis.com) or to the editor.
	This document is an Internet-Draft. Internet Drafts are working		This document is an Internet-Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working Groups. Note that other groups may also distribute		and its working Groups. Note that other groups may also distribute
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	document are to be interpreted as described in [RFC 2119].		document are to be interpreted as described in [RFC 2119].
	2. Algorithm and Mode		2. Algorithm and Mode
	[FIPS-180-1] describes the underlying SHA-1 algorithm, while		[FIPS-180-1] describes the underlying SHA-1 algorithm, while
	[RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides		[RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides
	a framework for inserting various hashing algorithms such as SHA-1.		a framework for inserting various hashing algorithms such as SHA-1.
	HMAC-SHA-1-96 operates on 64-byte blocks of data. Padding		HMAC-SHA-1-96 operates on 64-byte blocks of data. Padding
	requirements are specified in [FIPS-180-1] and are part of the SHA-1		requirements are specified in [FIPS-180-1] and are part of the SHA-1
	algorithm. Padding bits are only necessary in computing the HMAC-		algorithm. If you build SHA-1 according to [FIPS-180-1] you do not
	SHA-1 authenticator value and MUST NOT be included in the packet.		need to add any additional padding as far as HMAC-SHA-1-96 is
			concerned. With regard to "implicit packet padding" as defined in
			[AH] no implicit packet padding is required.
	HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit		HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit
	value can be truncated as described in RFC2104. For use with either		value can be truncated as described in RFC2104. For use with either
	ESP or AH, a truncated value using the first 96 bits MUST be		ESP or AH, a truncated value using the first 96 bits MUST be
	supported. Upon sending, the truncated value is stored within the		supported. Upon sending, the truncated value is stored within the
	authenticator field. Upon receipt, the entire 160-bit value is		authenticator field. Upon receipt, the entire 160-bit value is
	computed and the first 96 bits are compared to the value stored in		computed and the first 96 bits are compared to the value stored in
	the authenticator field. No other authenticator value lengths are		the authenticator field. No other authenticator value lengths are
	supported by HMAC-SHA-1-96.		supported by HMAC-SHA-1-96.
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 20 ¶
	with SHA-1.		with SHA-1.
	[RFC-2104] outlines an implementation modification which can improve		[RFC-2104] outlines an implementation modification which can improve
	per-packet performance without affecting interoperability.		per-packet performance without affecting interoperability.
	3. Keying Material		3. Keying Material
	HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is		HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is
	specified in [RFC-2104], for use with either ESP or AH a fixed key		specified in [RFC-2104], for use with either ESP or AH a fixed key
	length of 160-bits MUST be supported. Key lengths other than		length of 160-bits MUST be supported. Key lengths other than
	160-bits SHALL NOT be supported. A key length of 160-bits was chosen		160-bits MUST NOT be supported (i.e. only 160-bit keys are to be used
	based on the recommendations in [RFC-2104] (i.e. key lengths less		by HMAC-SHA-1-96). A key length of 160-bits was chosen based on the
	than the authenticator length decrease security strength and keys		recommendations in [RFC-2104] (i.e. key lengths less than the
	longer than the authenticator length do not significantly increase		authenticator length decrease security strength and keys longer than
	security strength).		the authenticator length do not significantly increase security
			strength).
	[RFC-2104] discusses requirements for key material, which includes a		[RFC-2104] discusses requirements for key material, which includes a
	discussion on requirements for strong randomness. A strong pseudo-		discussion on requirements for strong randomness. A strong pseudo-
	random function MUST be used to generate the required 160-bit key.		random function MUST be used to generate the required 160-bit key.
	At the time of this writing there are no specified weak keys for use		At the time of this writing there are no specified weak keys for use
	with HMAC. This does not mean to imply that weak keys do not exist.		with HMAC. This does not mean to imply that weak keys do not exist.
	If, at some point, a set of weak keys for HMAC are identified, the		If, at some point, a set of weak keys for HMAC are identified, the
	use of these weak keys must be rejected followed by a request for		use of these weak keys must be rejected followed by a request for
	replacement keys or a newly negotiated Security Association.		replacement keys or a newly negotiated Security Association.
	[ESP] describes the general mechanism to obtain keying material for		[ARCH] describes the general mechanism for obtaining keying material
	the ESP transform. The derivation of the key from some amount of		when multiple keys are required for a single SA (e.g. when an ESP SA
	keying material does not differ between the manual and automatic key		requires a key for confidentiality and a key for authentication).
	management mechanisms.
	In order to provide data origin authentication, the key distribution		In order to provide data origin authentication, the key distribution
	mechanism must ensure that unique keys are allocated and that they		mechanism must ensure that unique keys are allocated and that they
	are distributed only to the parties participating in the		are distributed only to the parties participating in the
	communication.		communication.
	[RFC-2104] states that for "minimally reasonable hash functions" the		[RFC-2104] states that for "minimally reasonable hash functions" the
	"birthday attack" is impractical. For a 64-byte block hash such as		"birthday attack" is impractical. For a 64-byte block hash such as
	HMAC-SHA-1-96, an attack involving the successful processing of 2**64		HMAC-SHA-1-96, an attack involving the successful processing of 2**80
	blocks would be infeasible unless it were discovered that the		blocks would be infeasible unless it were discovered that the
	underlying hash had collisions after processing 2**30 blocks. (A		underlying hash had collisions after processing 2**30 blocks. A hash
	hash with such weak collision-resistance characteristics would		with such weak collision-resistance characteristics would generally
	generally be considered to be unusable.) No time-based attacks are		be considered to be unusable. No time-based attacks are discussed in
	discussed in the document.		the document.
	While it it still cryptographically prudent to perform frequent		While it it still cryptographically prudent to perform frequent
	rekeying, current literature does not include any recommended key		rekeying, current literature does not include any recommended key
	lifetimes for HMAC-SHA. When recommendations for HMAC-SHA key		lifetimes for HMAC-SHA-1-96 (i.e. there are too many variable
	lifetimes become available they will be included in a revised version		involved to propose a general recommendation). When any
	of this document.		recommendations for HMAC-SHA-1-96 key lifetimes become available they
			will be included in a revised version of this document.
	4. Interaction with the ESP Cipher Mechanism		4. Interaction with the ESP Cipher Mechanism
	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-1-96 algorithm with any specific cipher algorithm.		of the HMAC-SHA-1-96 algorithm with any specific cipher algorithm.
	5. Security Considerations		5. Security Considerations
	The security provided by HMAC-SHA-1-96 is based upon the strength of		The security provided by HMAC-SHA-1-96 is based upon the strength of
	HMAC, and to a lesser degree, the strength of SHA-1. At the time of		HMAC, and to a lesser degree, the strength of SHA-1. At the time of
	this writing there are no known cryptographic attacks against SHA-1.		this writing there are no known cryptographic attacks against SHA-1
			or HMAC-SHA-1-96.
	It is also important to consider that while SHA-1 was never developed		It is also important to consider that while SHA-1 was never developed
	to be used as a keyed hash algorithm, HMAC had that criteria from the		to be used as a keyed hash algorithm, HMAC had that criteria from the
	onset.		onset.
	[RFC-2104] also discusses the potential additional security which is		[RFC-2104] also discusses the potential additional security which is
	provided by the truncation of the resulting hash. Specifications		provided by the truncation of the resulting hash. Specifications
	which include HMAC are strongly encouraged to perform this hash		which include HMAC are strongly encouraged to perform this hash
	truncation.		truncation.
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 50 ¶
	6. Acknowledgments		6. Acknowledgments
	This document is derived in part from previous works by Jim Hughes,		This document is derived in part from previous works by Jim Hughes,
	those people that worked with Jim on the combined DES/CBC+HMAC-MD5		those people that worked with Jim on the combined DES/CBC+HMAC-MD5
	ESP transforms, the ANX bakeoff participants, and the members of the		ESP transforms, the ANX bakeoff participants, and the members of the
	IPsec working group.		IPsec working group.
	7. References		7. References
	[FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard,		[FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard,
	April 1995.		April 1995.
	http://csrc.nist.gov/fips/fip180-1.txt (ascii)		http://csrc.nist.gov/fips/fip180-1.txt (ascii)
	http://csrc.nist.gov/fips/fip180-1.ps (postscript)		http://csrc.nist.gov/fips/fip180-1.ps (postscript)
	[RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-		[RFC-2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-
	Hashing for Message Authentication", RFC-2104,		Hashing for Message Authentication", RFC-2104,
	February, 1997		February 1997.
	[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying		[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying
	Hash Functions for Message Authentication", Advances		Hash Functions for Message Authentication", Advances
	in Cryptography, Crypto96 Proceeding, June 1996.		in Cryptography, Crypto96 Proceeding, June 1996.
	[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security		[ARCH] Kent, S., Atkinson, R., "Security Architecture for
	Payload", draft-ietf-ipsec-esp-v2-01.txt,		the Internet Protocol",
	work in progress, October, 1997		draft-ietf-ipsec-arch-sec-02.txt, work in progress,
			November 1997.
	[AH] Kent, S., Atkinson, R., "IP Authentication Header",		[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security
	draft-ietf-ipsec-auth-header-02.txt, work in progress,		Payload", draft-ietf-ipsec-esp-v2-02.txt,
	October 1997		work in progress, November 1997.
	[Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security		[AH] Kent, S., Atkinson, R., "IP Authentication Header",
	Document Framework",		draft-ietf-ipsec-auth-header-03.txt, work in progress,
	draft-ietf-ipsec-doc-framework-01.txt, work in		November 1997.
	progress, July 1997.
	[RFC-2202] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and		[Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security
	HMAC-SHA-1", RFC-2202, March 1997.		Document Roadmap",
			draft-ietf-ipsec-doc-roadmap-02.txt, work in
			progress, November 1997.
			[RFC-2202] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and
			HMAC-SHA-1", RFC-2202, March 1997.
	[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC-2119, March 1997.		Requirement Levels", RFC-2119, March 1997.
	8. Editors' Address		8. Editors' Address
	Cheryl Madson		Cheryl Madson
	<cmadson@cisco.com>
	Cisco Systems, Inc.		Cisco Systems, Inc.
			e-mail: <cmadson@cisco.com>
	Rob Glenn		Rob Glenn
	<rob.glenn@nist.gov>
	NIST		NIST
			e-mail: <rob.glenn@nist.gov>
	The IPsec working group can be contacted through the chairs:		The IPsec working group can be contacted through the chairs:
	Robert Moskowitz		Robert Moskowitz
	<rgm3@chrysler.com>		ICSA
	Chrysler Corporation		e-mail: <rgm@icsa.net>
	Ted T'so		Ted T'so
	tytso@mit.edu
	Massachusetts Institute of Technology		Massachusetts Institute of Technology
			e-mail: <tytso@mit.edu>
End of changes. 23 change blocks.
	49 lines changed or deleted		57 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/