< draft-ietf-ipsec-auth-hmac-md5-96-01.txt		draft-ietf-ipsec-auth-hmac-md5-96-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-MD5-96 within ESP and AH		The Use of HMAC-MD5-96 within ESP and AH
	<draft-ietf-ipsec-auth-hmac-md5-96-01.txt>		<draft-ietf-ipsec-auth-hmac-md5-96-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 38 ¶		skipping to change at page 2, line 38 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	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
	[RFC-1321] describes the underlying MD5 algorithm, while [RFC-2104]		[RFC-1321] describes the underlying MD5 algorithm, while [RFC-2104]
	describes the HMAC algorithm. The HMAC algorithm provides a framework		describes the HMAC algorithm. The HMAC algorithm provides a framework
	for inserting various hashing algorithms such as MD5.		for inserting various hashing algorithms such as MD5.
	HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements		HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements
	are specified in [RFC-1321] and are part of the MD5 algorithm.		are specified in [RFC-1321] and are part of the MD5 algorithm. If
	Padding bits are only necessary in computing the HMAC-MD5		MD5 is built according to [RFC-1321], there is no need to add any
	authenticator value and MUST NOT be included in the packet.		additional padding as far as HMAC-MD5-96 is concerned. With regard
			to "implicit packet padding" as defined in [AH], no implicit packet
			padding is required.
	HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit		HMAC-MD5-96 produces a 128-bit authenticator value. This 128-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 128-bit value is		authenticator field. Upon receipt, the entire 128-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-MD5-96.		supported by HMAC-MD5-96.
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 21 ¶
	of HMAC or HMAC combined with MD5.		of HMAC or HMAC combined with MD5.
	[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-MD5-96 is a secret key algorithm. While no fixed key length is		HMAC-MD5-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 128-bits MUST be supported. Key lengths other than		length of 128-bits MUST be supported. Key lengths other than
	128-bits SHALL NOT be supported. A key length of 128-bits was chosen		128-bits MUST NOT be supported (i.e. only 128-bit keys are to be used
	based on the recommendations in [RFC-2104] (i.e. key lengths less		by HMAC-MD5-96). A key length of 128-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 128-bit key.		random function MUST be used to generate the required 128-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-MD5-96, an attack involving the successful processing of 2**64		HMAC-MD5-96, an attack involving the successful processing of 2**64
	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-MD5. When recommendations for HMAC-MD5 key		lifetimes for HMAC-MD5-96 (i.e. there are too many variables involved
	lifetimes become available they will be included in a revised version		to propose a general recommendation). When any recommendations for
	of this document.		HMAC-MD5-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-MD5-96 algorithm with any specific cipher algorithm.		of the HMAC-MD5-96 algorithm with any specific cipher algorithm.
	5. Security Considerations		5. Security Considerations
	The security provided by HMAC-MD5-96 is based upon the strength of		The security provided by HMAC-MD5-96 is based upon the strength of
	HMAC, and to a lesser degree, the strength of MD5. [RFC-2104] claims		HMAC, and to a lesser degree, the strength of MD5. [RFC-2104] claims
	that HMAC does not depend upon the property of strong collision		that HMAC does not depend upon the property of strong collision
	resistance, which is important to consider when evaluating the use of		resistance, which is important to consider when evaluating the use of
	MD5, an algorithm which has, under recent scrutiny, been shown to be		MD5, an algorithm which has, under recent scrutiny, been shown to be
	much less collision-resistant than was first thought.		much less collision-resistant than was first thought. At the time of
			this writing there are no known cryptographic attacks against HMAC-
			MD5-96.
	It is also important to consider that while MD5 was never developed		It is also important to consider that while MD5 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. While the use of MD5 in the context of data security is		onset. While the use of MD5 in the context of data security is
	undergoing reevaluation, the combined HMAC with MD5 algorithm has		undergoing reevaluation, the combined HMAC with MD5 algorithm has
	held up to cryptographic scrutiny.		held up to cryptographic scrutiny.
	[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
	skipping to change at page 4, line 56 ¶		skipping to change at page 5, line 11 ¶
	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
	[RFC-1321] Rivest, R., "MD5 Digest Algorithm", RFC-1321, April 1992.		[RFC-1321] Rivest, R., "MD5 Digest Algorithm", RFC-1321, April 1992.
	[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.
	[RFC-1810] Touch, J. "Report on MD5 Performance", RFC-1810,		[RFC-1810] Touch, J. "Report on MD5 Performance", RFC-1810,
	June 1995.		June 1995.
	[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying		[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying
	Hash Functions for Message Authentication", Advances in		Hash Functions for Message Authentication", Advances in
	Cryptography, Crypto96 Proceeding, June 1996.		Cryptography, Crypto96 Proceeding, June 1996.
			[ARCH] Kent, S., Atkinson, R., "Security Architecture for
			the Internet Protocol", draft-ietf-ipsec-arch-sec-02.txt,
			work in progress, November 1997.
	[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security		[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security
	Payload", draft-ietf-ipsec-esp-v2-01.txt, work in progress,		Payload", draft-ietf-ipsec-esp-v2-02.txt, work in progress,
	October 1997.		November 1997.
	[AH] Kent, S., Atkinson, R., "IP Authentication Header",		[AH] Kent, S., Atkinson, R., "IP Authentication Header",
	draft-ietf-ipsec-auth-header-02.txt, work in progress,		draft-ietf-ipsec-auth-header-03.txt, work in progress,
	October 1997.		November 1997.
	[Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security		[Thayer97a] Thayer, R., Doraswamy, N., Glenn, R., "IP Security
	Document Framework",		Document Roadmap",
	draft-ietf-ipsec-doc-framework-01.txt, work in progress,		draft-ietf-ipsec-doc-roadmap-02.txt, work in progress,
	July 1997.		November 1997.
	[RFC-2202] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and		[RFC-2202] Cheng, P., Glenn, R., "Test Cases for HMAC-MD5 and
	HMAC-SHA-1", RFC-2202, March 1997.		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. 21 change blocks.
	37 lines changed or deleted		44 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/