draft-ietf-bfd-hmac-sha-01.txt		draft-ietf-bfd-hmac-sha-02.txt
	Network Working Group D. Zhang		Network Working Group D. Zhang
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track M. Bhatia		Intended status: Standards Track M. Bhatia
	Expires: January 4, 2013 Alcatel-Lucent		Expires: April 22, 2013 Alcatel-Lucent
	V. Manral		V. Manral
	Hewlett-Packard Co.		Hewlett-Packard Co.
	July 03, 2012		October 19, 2012
	Authenticating BFD using HMAC-SHA-2 procedures		Authenticating BFD using HMAC-SHA-2 procedures
	draft-ietf-bfd-hmac-sha-01		draft-ietf-bfd-hmac-sha-02
	Abstract		Abstract
	This document describes the mechanism to authenticate Bidirectional		This document describes the mechanism to authenticate Bidirectional
	Forwarding Detection (BFD) protocol packets using Hashed Message		Forwarding Detection (BFD) protocol packets using Hashed Message
	Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512		Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512
	algorithms. The mechanism described uses the Generic Cryptographic		algorithms. The described mechanism uses the Generic Cryptographic
	Authentication and Generic Meticulous Cryptographic Authentication		Authentication and Generic Meticulous Cryptographic Authentication
	sections to carry the authentication data. This document updates,		sections to carry the authentication data. This document updates,
	but does not supercede, the cryptographic authentication mechanism		but does not supercede, the cryptographic authentication mechanism
	specified in RFC 5880.		specified in RFC 5880.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 4, 2013.		This Internet-Draft will expire on April 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . . 3		2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . . 3
	3. Procedures at the Sending Side . . . . . . . . . . . . . . . . 5		3. Procedures at the Sending Side . . . . . . . . . . . . . . . . 5
	4. Procedure at the Receiving Side . . . . . . . . . . . . . . . . 5		4. Procedure at the Receiving Side . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The cryptographic authentication mechanisms specified in BFD		The cryptographic authentication mechanisms specified in [RFC5880]
	[RFC5880] defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1)		defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) algorithms to
	algorithms to authenticate BFD packets. The recent escalating series		authenticate BFD packets. The recent escalating series of attacks on
	of attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise		MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise concerns about
	concerns about their remaining useful lifetime [RFC6151] [RFC6194].		their remaining useful lifetime [RFC6151] [RFC6194].
	These attacks may not necessarily result in direct vulnerabilities		These attacks may not necessarily result in direct vulnerabilities
	for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes		for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes
	because the colliding message may not correspond to a syntactically		because the colliding message may not correspond to a syntactically
	correct BFD protocol packet. Regardless, there is a need felt to		correct BFD protocol packet. Regardless, there is a need felt to
	deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor		deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor
	of stronger digest algorithms.		of stronger digest algorithms.
	This document adds support for Secure Hash Algorithms (SHA) defined		This document adds support for Secure Hash Algorithms (SHA) defined
	in the US NIST Secure Hash Standard (SHS), which is defined by NIST		in the US NIST Secure Hash Standard (SHS), which is defined by NIST
	FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA-		FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA-
	256, SHA-384, and SHA-512. The HMAC authentication mode defined in		256, SHA-384, and SHA-512. The HMAC authentication mode defined in
	NIST FIPS 198 is used [FIPS-198].		NIST FIPS 198 is used [FIPS-198].
	It is believed that [RFC2104] is mathematically identical to		It is believed that the HMAC algorithms defined in [RFC2104] is
	[FIPS-198] and it is also believed that algorithms in [RFC6234] are		mathematically identical to their counterparts in [FIPS-198] and it
	mathematically identical to [FIPS-180-2].		is also believed that algorithms in [RFC6234] are mathematically
			identical to those defined in [FIPS-180-2].
	It should be noted that if SHA-1 is used in the HMAC construction		It should be noted that the collision attacks currently known against
	then collision attacks currently known against SHA-1 do not apply.		SHA-1 do not apply when SHA-1 is used in the HMAC construction. NIST
	The new attacks on SHA-1 have no impact on the security of		will be supporting HMAC-SHA-1 even after 2010 [NIST-HMAC-SHA] ,
	HMAC-SHA-1. NIST will be supporting HMAC-SHA-1 even after 2010		whereas it would be dropping support for SHA-1 in digital signatures.
	[NIST-HMAC-SHA] , whereas it would be dropping support for SHA-1 in
	digital signatures.
	[I-D.ietf-bfd-generic-crypto-auth] defines new authentication types -		[I-D.ietf-bfd-generic-crypto-auth] defines new authentication types -
	Generic Cryptographic Authentication and Generic Meticulous		Generic Cryptographic Authentication and Generic Meticulous
	Cryptographic Authenticationan extension that can be used for		Cryptographic Authentication that can be used for carrying the
	carrying the authentication digests defined in this document.		authentication digests defined in this document.
	Implementations of this specification must include support for at		Implementations of this specification must include support for at
	least HMAC-SHA-256 and may include support for either of HMAC-SHA-384		least HMAC-SHA-256 and may include support for either of HMAC-SHA-384
	or HMAC-SHA-512.		or HMAC-SHA-512.
	2. Cryptographic Aspects		2. Cryptographic Aspects
	In the algorithm description below, the following nomenclature, which		In the algorithm description below, the following nomenclature, which
	is consistent with [FIPS-198], is used:		is consistent with [FIPS-198], is used:
	skipping to change at page 4, line 36		skipping to change at page 4, line 36
	If the Authentication Key (K) is L octets long, then Ko is equal to		If the Authentication Key (K) is L octets long, then Ko is equal to
	K. If the Authentication Key (K) is more than L octets long, then Ko		K. If the Authentication Key (K) is more than L octets long, then Ko
	is set to H(K). If the Authentication Key (K) is less than L octets		is set to H(K). If the Authentication Key (K) is less than L octets
	long, then Ko is set to the Authentication Key (K) with zeros		long, then Ko is set to the Authentication Key (K) with zeros
	appended to the end of the Authentication Key (K) such that Ko is L		appended to the end of the Authentication Key (K) such that Ko is L
	octets long.		octets long.
	(2) First Hash		(2) First Hash
	First, the Authentication Data field in the Generic Authentication		First, the Authentication Data field in the Generic Authentication
	Section is filled with the value Apad and the Authentication Type		Section is filled with the value of Apad and the Authentication Type
	field is set to 6 or 7 depending upon which Authentication Type is		field is set to 6 or 7 depending upon which Authentication Type is
	being used. The Sequence Number field MUST be set to		being used. The Sequence Number field MUST be set to
	bfd.XmitAuthSeq.		bfd.XmitAuthSeq.
	Then, a first hash, also known as the inner hash, is computed as		Then, a first hash, also known as the inner hash, is computed as
	follows:		follows:
	First-Hash = H(Ko XOR Ipad || (BFD Packet))		First-Hash = H(Ko XOR Ipad || (BFD Packet))
	(3) Second Hash T		(3) Second Hash T
	skipping to change at page 5, line 29		skipping to change at page 5, line 29
	select an appropriate BFD SA from its local key table if a keyed		select an appropriate BFD SA from its local key table if a keyed
	digest for the packet is required. If no appropriate SA is		digest for the packet is required. If no appropriate SA is
	avaliable, the BFD packet MUST be discarded.		avaliable, the BFD packet MUST be discarded.
	If an appropriate SA is avaliable, the device then derives the key		If an appropriate SA is avaliable, the device then derives the key
	and the associated authentication algorithm (HMAC-SHA-256, HMAC-SHA-		and the associated authentication algorithm (HMAC-SHA-256, HMAC-SHA-
	384 or HMAC-SHA-512) from the SA.		384 or HMAC-SHA-512) from the SA.
	The device then start performing the operations illustrated in		The device then start performing the operations illustrated in
	Section 2. Before the authentication data is computed, the device		Section 2. Before the authentication data is computed, the device
	MUST fill the Auth Type and the Auth length . The Sequence Number		MUST fill the Auth Type field and the Auth length field. The
	field MUST be set to bfd.XmitAuthSeq.		Sequence Number field MUST be set to bfd.XmitAuthSeq.
	The value of Auth Length in the generic authentication section is		The value of Auth Length in the generic authentication section is
	various according to different authentication algorithms being used.		various according to different authentication algorithms being used.
	Specifically, the value is 40 for HMAC-SHA-256, 56 for HMAC-SHA-384		Specifically, the value is 40 for HMAC-SHA-256, 56 for HMAC-SHA-384,
	and 72 for HMAC- SHA-512.		and 72 for HMAC- SHA-512.
	The Key ID is then filled.		The Key ID is then filled.
	After that, the authentication data is computed as illustrated in		After that, the authentication data is computed as illustrated in
	Section 3.		Section 2.
	The result of the authentication algorithm is placed in the		The result of the authentication algorithm is placed in the
	Authentication data, following the Key ID.		Authentication data, following the Key ID.
	4. Procedure at the Receiving Side		4. Procedure at the Receiving Side
	Upon receiving a BFD packet with an generic authentication section		Upon receiving a BFD packet with an generic authentication section
	appended, the receiving device needs to find an appropriate BFD SA		appended, a device needs to find an appropriate BFD SA from its local
	from its local key table to verify the packet. The SA is located by		key table to verify the packet. The SA is located by the Key ID in
	the Key ID in the authentication section of the packet.		the authentication section of the packet.
	If there is no SA is associated with the Key ID, the received packet		If there is no SA is associated with the Key ID, the received packet
	MUST be discarded.		MUST be discarded.
	If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For		If bfd.AuthSeqKnown is 1, the Sequence Number field is examined. For
	Cryptographic Authentication, if the Sequence Number lies outside of		Cryptographic Authentication, if the Sequence Number lies outside of
	the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)		the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)
	inclusive (when treated as an unsigned 32 bit circular number space),		inclusive (when treated as an unsigned 32 bit circular number space),
	the received packet MUST be discarded. For Meticulous Cryptographic		the received packet MUST be discarded. For Meticulous Cryptographic
	Authentication, if the Sequence Number lies outside of the range of		Authentication, if the Sequence Number lies outside of the range of
	bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when		bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
	treated as an unsigned 32 bit circular number space, the received		treated as an unsigned 32 bit circular number space, the received
	packet MUST be discarded.		packet MUST be discarded.
	Authentication Algorithm dependent processing, needs to be performed,		An authentication Algorithm dependent process then needs to be
	using the algorithm specified by the appropriate BFD SA for the		performed by using the algorithm specified by the appropriate BFD SA
	received packet.		for the received packet.
	Before the device performs any processing, it needs to save the		Before the device performs any processing, it needs to save the
	values of the Authentication Value field.		content of the Authentication Value field and set the Authentication
			Value field with Apad.
	The device then needs to set the Authentication Value field with Apad		The device then computes the authentication data as illustrated in
	before the authentication data is computed. The calculated data is		Section 2. The calculated data is compared with the received
	compared with the received authentication data in the packet.		authentication data in the packet.
	The packet MUST be discarded if the calculated data and the received		The packet MUST be discarded if the calculated and the received
	authentication data do not match each other. In such a case, an		authentication data do not match. In this case, an error event
	error event SHOULD be logged.		SHOULD be logged.
	A BFD implementation MAY be in a transition mode where it includes		A BFD implementation MAY be in a transition mode where it includes
	CRYPTO_AUTH or the MET_CRYPTO_AUTH information in packets but never		CRYPTO_AUTH or the MET_CRYPTO_AUTH information in packets but never
	verifies it. This is provided as a transition aid for networks in		verifies it. This is provided as a transition aid for networks in
	the process of migrating to the new CRYPTO_AUTH and MET_CRYPTO_AUTH		the process of migrating to the new CRYPTO_AUTH and MET_CRYPTO_AUTH
	based authentication schemes.		based authentication schemes.
	5. IANA Considerations		5. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	skipping to change at page 8, line 40		skipping to change at page 8, line 43
	draft-ietf-karp-design-guide-10 (work in progress),		draft-ietf-karp-design-guide-10 (work in progress),
	December 2011.		December 2011.
	[MD5-attack]		[MD5-attack]
	Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for		Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for
	Hash Functions MD4, MD5, HAVAL-128 and RIPEMD",		Hash Functions MD4, MD5, HAVAL-128 and RIPEMD",
	August 2004.		August 2004.
	[NIST-HMAC-SHA]		[NIST-HMAC-SHA]
	National Institute of Standards and Technology, Available		National Institute of Standards and Technology, Available
	online at		online at http://csrc.nist.gov/groups/ST/hash/policy.html,
	http://csrc.nist.gov/groups/ST/hash/policy.html, "NIST's		"NIST's Policy on Hash Functions", 2006.
	Policy on Hash Functions", 2006.
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] 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.
	[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", BCP 106, RFC 4086, June 2005.		Requirements for Security", BCP 106, RFC 4086, June 2005.
End of changes. 21 change blocks.
	44 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/