< draft-ietf-ospf-hmac-sha-06.txt		draft-ietf-ospf-hmac-sha-07.txt >
	Internet Draft M. Bhatia		Internet Draft M. Bhatia
	<draft-ietf-ospf-hmac-sha-06.txt> Alcatel-Lucent		<draft-ietf-ospf-hmac-sha-07.txt> Alcatel-Lucent
	Category: Standards-Track V. Manral		Category: Standards-Track V. Manral
	Expires: 11 Jan 2010 IP Infusion		Expires: 31 Jan 2010 IP Infusion
	Updates: RFC 2328 M. Fanto		Updates: RFC 2328 M. Fanto
	Aegis Data Security		Aegis Data Security
	R. White		R. White
	Cisco Systems		Cisco Systems
	T. Li		T. Li
	Ericsson		Ericsson
	M. Barnes		M. Barnes
	Cisco Systems		Cisco Systems
	R. Atkinson		R. Atkinson
	Extreme Networks		Extreme Networks
	11 August 2009		31 August 2009
	OSPFv2 HMAC-SHA Cryptographic Authentication		OSPFv2 HMAC-SHA Cryptographic Authentication
	<draft-ietf-ospf-hmac-sha-06.txt>		<draft-ietf-ospf-hmac-sha-07.txt>
	Status of this Memo		Status of this Memo
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	This Internet-Draft is submitted to IETF in full conformance		This Internet-Draft is submitted to IETF in full conformance
	with the provisions of BCP 78 and BCP 79.		with the provisions of BCP 78 and BCP 79.
	Copyright (c) 2009 IETF Trust and the persons identified		Copyright (c) 2009 IETF Trust and the persons identified
	as the document authors. All rights reserved.		as the document authors. All rights reserved.
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	RFC 2328. OSPFv2 itself is defined in RFC 2328. [RFC 2328]		RFC 2328. OSPFv2 itself is defined in RFC 2328. [RFC 2328]
	This document adds support for Secure Hash Algorithms defined in		This document adds support for Secure Hash Algorithms defined in
	the US NIST Secure Hash Standard (SHS) as defined by NIST FIPS		the US NIST Secure Hash Standard (SHS) as defined by NIST FIPS
	180-2. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384,		180-2. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384,
	and SHA-512. The HMAC authentication mode defined in NIST FIPS		and SHA-512. The HMAC authentication mode defined in NIST FIPS
	198 is used. [FIPS-198]		198 is used. [FIPS-198]
	It is believed that [RFC 2104] is mathematically identical to		It is believed that [RFC 2104] is mathematically identical to
	[FIPS-198] and also believed that algorithms in [RFC 4684] are		[FIPS-198] and also believed that algorithms in [RFC 4684] are
	mathematically identical to [FIPS-180-2]. It is believed that		mathematically identical to [FIPS-180-2].
	[RFC 3874] is mathematically identical to SHA-224 as specified
	in [FIPS-180-2].
	The creation of this addition to OSPFv2 was driven by operator		The creation of this addition to OSPFv2 was driven by operator
	requests that they be able to use the NIST SHS family of		requests that they be able to use the NIST SHS family of
	algorithms in the NIST HMAC mode, instead of being forced		algorithms in the NIST HMAC mode, instead of being forced
	to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic		to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic
	Authentication. Cryptographic matters are discussed in more		Authentication. Cryptographic matters are discussed in more
	detail in the Security Considerations section of this document.		detail in the Security Considerations section of this document.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" in this document are to be interpreted as		and "OPTIONAL" in this document are to be interpreted as
	described in RFC 2119. [RFC 2119]		described in RFC 2119. [RFC 2119]
	2. Background		2. Background
	All OSPF protocol exchanges are authenticated. The OSPF packet		All OSPF protocol exchanges can be authenticated. The OSPF
	header (see Section A.3.1 of RFC-2328) includes an Authentication		packet header (see Section A.3.1 of RFC-2328) includes an
	Type field, and 64-bits of data for use by the appropriate		Authentication Type field, and 64-bits of data for use by
	authentication scheme (determined by the type field).		the appropriate authentication scheme (determined by the
			type field).
	The authentication type is configurable on a per-interface		The authentication type is configurable on a per-interface
	(or equivalently, on a per-network/subnet) basis. Additional		(or equivalently, on a per-network/subnet) basis. Additional
	authentication data is also configurable on a per-interface basis.		authentication data is also configurable on a per-interface
			basis.
	OSPF Authentication types 0, 1, and 2 are defined by RFC 2328.		OSPF Authentication types 0, 1, and 2 are defined by RFC 2328.
	This document provides an update to RFC 2328 that is only		This document provides an update to RFC 2328 that is only
	applicable to Authentication Type 2, "Cryptographic		applicable to Authentication Type 2, "Cryptographic
	Authentication".		Authentication".
	3. Cryptographic authentication with NIST SHS in HMAC mode		3. Cryptographic authentication with NIST SHS in HMAC mode
	Using this authentication type, a shared secret key is configured		Using this authentication type, a shared secret key is configured
	in all routers attached to a common network/subnet. For each		in all routers attached to a common network/subnet. For each
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	are specified implicitly by the secret key. This specification		are specified implicitly by the secret key. This specification
	discusses the computation of OSPF Cryptographic Authentication		discusses the computation of OSPF Cryptographic Authentication
	data when any of the NIST SHS family of algorithms is used in		data when any of the NIST SHS family of algorithms is used in
	the Hashed Message Authentication Code (HMAC) mode.		the Hashed Message Authentication Code (HMAC) mode.
	Please also see RFC 2328, Appendix D.		Please also see RFC 2328, Appendix D.
	With the additions in this document, the currently valid algorithms		With the additions in this document, the currently valid algorithms
	(including mode) for OSPFv2 Cryptographic Authentication include:		(including mode) for OSPFv2 Cryptographic Authentication include:
	Keyed-MD5 (defined in RFC-2328, Appendix D)		Keyed-MD5 (defined in RFC-2328, Appendix D)
	HMAC-SHA-1 (defined here)		HMAC-SHA-1 (defined here)
	HMAC-SHA-224 (defined here)
	HMAC-SHA-256 (defined here)		HMAC-SHA-256 (defined here)
	HMAC-SHA-384 (defined here)		HMAC-SHA-384 (defined here)
	HMAC-SHA-512 (defined here)		HMAC-SHA-512 (defined here)
	Of the above, implementations of this specification MUST		Of the above, implementations of this specification MUST
	include support for at least:		include support for at least:
	HMAC-SHA-256		HMAC-SHA-256
	and SHOULD include support for:		and SHOULD include support for:
	HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, & HMAC-SHA-512		HMAC-SHA-1
	and SHOULD also (for backwards compatibility with existing		and SHOULD also (for backwards compatibility with existing
	implementations and deployments) include support for:		implementations and deployments) include support for:
	Keyed-MD5		Keyed-MD5
			and MAY also include support for:
			HMAC-SHA-384
			HMAC-SHA-512
	An implementation of this specification MUST allow network		An implementation of this specification MUST allow network
	operators to configure ANY algorithm and mode supported		operators to configure ANY authentication algorithm supported
	by that implementation for use with ANY given Key-ID value		by that implementation for use with ANY given Key-ID value
	that is configured into that OSPFv2 router.		that is configured into that OSPFv2 router.
	3.1. Generating Cryptographic Authentication		3.1. Generating Cryptographic Authentication
	The overall cryptographic authentication process defined in		The overall cryptographic authentication process defined in
	Appendix D of RFC 2328 remains unchanged. However, the specific		Appendix D of RFC 2328 remains unchanged. However, the specific
	cryptographic details (i.e. SHA rather than MD5, HMAC rather		cryptographic details (i.e. SHA rather than MD5, HMAC rather
	than Keyed-Hash) are defined herein. To reduce the potential for		than Keyed-Hash) are defined herein. To reduce the potential for
	confusion, this section minimises the repetition of text from RFC		confusion, this section minimises the repetition of text from RFC
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 10 ¶
	HMAC mode with OSPFv2 Cryptographic Authentication, the		HMAC mode with OSPFv2 Cryptographic Authentication, the
	Authentication Data Length is equal to the normal hash output		Authentication Data Length is equal to the normal hash output
	length (measured in bytes) for the specific NIST SHS algorithm in		length (measured in bytes) for the specific NIST SHS algorithm in
	use. For example, with NIST SHA-256, the Authentication Data		use. For example, with NIST SHA-256, the Authentication Data
	Length is 32 bytes.		Length is 32 bytes.
	Third, The 32-bit Cryptographic sequence number is set in		Third, The 32-bit Cryptographic sequence number is set in
	accordance with the procedures in RFC 2328, Appendix D		accordance with the procedures in RFC 2328, Appendix D
	applicable to the Cryptographic Authentication type.		applicable to the Cryptographic Authentication type.
	Fourth, The message digest is then calculated and appended to		Fourth, The message digest is then calculated and appended
	the OSPF packet, as described below in Section 3.3. The KeyID,		to the OSPF packet, as described below in Section 3.3. The
	Authentication Algorithm, Algorithm Mode, and Key to be used		KeyID, Authentication Algorithm, and Key to be used for
	for calculating the digest are all components of the selected		calculating the digest are all components of the selected
	OSPFv2 Security Association. Input to the authentication		OSPFv2 Security Association. Input to the authentication
	algorithm consists of the OSPF packet and the secret key.		algorithm consists of the OSPF packet and the secret key.
	3.2 OSPFv2 Security Association		3.2 OSPFv2 Security Association
	RFC 2328 defined an OSPFv2 Security Association (OSPFv2 SA) in		This document uses the term OSPFv2 Security Association
	Section D.3, pages 228 and 229. However, the term is new to		(OSPFv2 SA) to refer to the authentication key information
	this document. The OSPFv2 protocol does not include an in-band		defined in Section D.3, pages 228 and 229, of RFC 2328.
	mechanism to create or manage OSPFv2 Security Associations.		The OSPFv2 protocol does not include an in-band mechanism
	The parameters of an OSPFv2 Security Association are updated		to create or manage OSPFv2 Security Associations. The
			parameters of an OSPFv2 Security Association are updated
	to be:		to be:
	Key Identifier (KeyID)		Key Identifier (KeyID)
	This is an 8-bit unsigned value used to		This is an 8-bit unsigned value used to
	uniquely identify an OSPFv2 SA and is		uniquely identify an OSPFv2 SA and is
	configured either by the router administrator		configured either by the router administrator
	(or, in the future, possibly by some key		(or, in the future, possibly by some key
	management protocol specified by the		management protocol specified by the
	IETF). The receiver uses this to locate		IETF). The receiver uses this to locate
	the appropriate OSPFv2 SA to use. The		the appropriate OSPFv2 SA to use. The
	sender puts this KeyID value in the OSPF		sender puts this KeyID value in the OSPF
	packet based on the active OSPF configuration.		packet based on the active OSPF configuration.
	Authentication Algorithm		Authentication Algorithm
	This indicates the authentication algorithm		This indicates the authentication algorithm
	to be used. THis information should never		(and also the cryptographic mode, such as HMAC)
	be sent over the wire in cleartext form.		to be used. This information SHOULD never be
	Currently valid values are: MD5, SHA-1,		sent over the wire in cleartext form.
	SHA-224, SHA-256, SHA-384, and SHA-512.		At present valid values are: Keyed-MD5,
			HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384,
	Authentication Mode		and HMAC-SHA-512.
	This indicates the authentication mode to
	be used with this OSPFv2 SA. For MD5,
	the only currently valid value is Keyed-Hash.
	For the SHA family of algorithms, the only
	currently valid value is HMAC.
	Authentication Key		Authentication Key
	This is the cryptographic key used for		This is the cryptographic key used for
	cryptographic authentication with this		cryptographic authentication with this
	OSPFv2 SA. This value should never be		OSPFv2 SA. This value SHOULD never be
	sent over the wire in cleartext form.		sent over the wire in cleartext form.
	This is noted as "K" in Section 3.3 below.		This is noted as "K" in Section 3.3 below.
	Key Start Accept		Key Start Accept
	The time that this OSPF router will accept		The time that this OSPF router will accept
	packets that have been created with this		packets that have been created with this
	OSPF Security Association.		OSPF Security Association.
	Key Start Generate		Key Start Generate
	The time that this OSPF router will begin		The time that this OSPF router will begin
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 27 ¶
	Key Stop Generate		Key Stop Generate
	The time that this OSPF router will stop		The time that this OSPF router will stop
	using this OSPF Security Association for		using this OSPF Security Association for
	OSPF packet generation.		OSPF packet generation.
	Key Stop Accept		Key Stop Accept
	The time that this OSPF router will stop		The time that this OSPF router will stop
	accepting packets generated with this		accepting packets generated with this
	OSPF Security Association.		OSPF Security Association.
	In order to achieve smooth key transition, KeyStartAccept should		In order to achieve smooth key transition, KeyStartAccept SHOULD
	be less than KeyStartGenerate and KeyStopGenerate should be less		be less than KeyStartGenerate and KeyStopGenerate SHOULD be less
	than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left		than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left
	unspecified, the key's lifetime is infinite. When a new key		unspecified, the key's lifetime is infinite. When a new key
	replaces an old, the KeyStartGenerate time for the new key must		replaces an old, the KeyStartGenerate time for the new key MUST
	be less than or equal to the KeyStopGenerate time of the old key.		be less than or equal to the KeyStopGenerate time of the old key.
	Key storage should persist across a system restart, warm or cold,		Key storage SHOULD persist across a system restart, warm or cold,
	to avoid operational issues. In the event that the last key		to avoid operational issues. In the event that the last key
	associated with an interface expires, it is unacceptable to		associated with an interface expires, it is unacceptable to
	revert to an unauthenticated condition, and not advisable to		revert to an unauthenticated condition, and not advisable to
	disrupt routing. Therefore, the router should send a "last		disrupt routing. Therefore, the router should send a "last
	authentication key expiration" notification to the network		authentication key expiration" notification to the network
	manager and treat the key as having an infinite lifetime until		manager and treat the key as having an infinite lifetime until
	the lifetime is extended, the key is deleted by network		the lifetime is extended, the key is deleted by network
	management, or a new key is configured.		management, or a new key is configured.
	3.3 Cryptographic Aspects		3.3 Cryptographic Aspects
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 12 ¶
	In the algorithm description below, the following nomenclature,		In the algorithm description below, the following nomenclature,
	which is consistent with [FIPS-198], is used:		which is consistent with [FIPS-198], is used:
	H is the specific hashing algorithm (e.g. SHA-256).		H is the specific hashing algorithm (e.g. SHA-256).
	K is the authentication key for the OSPFv2 security		K is the authentication key for the OSPFv2 security
	association.		association.
	Ko is the cryptographic key used with the hash algorithm.		Ko is the cryptographic key used with the hash algorithm.
	B is the block size of H, measured in octets,		B is the block size of H, measured in octets,
	rather than bits. Note well that B is the		rather than bits. Note well that B is the
	internal block size, not the hash size.		internal block size, not the hash size.
	For SHA-1, SHA-224, and SHA-256: B == 64		For SHA-1 and SHA-256: B == 64
	For SHA-384 and SHA-512: B == 128		For SHA-384 and SHA-512: B == 128
	L is the length of the hash, measured in octets,		L is the length of the hash, measured in octets,
	rather than bits.		rather than bits.
	XOR is the exclusive-or operation.		XOR is the exclusive-or operation.
	Opad is the hexadecimal value 0x5c repeated B times.		Opad is the hexadecimal value 0x5c repeated B times.
	Ipad is the hexadecimal value 0x36 repeated B times.		Ipad is the hexadecimal value 0x36 repeated B times.
	Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.		Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
	Implementation note:		Implementation note:
	This definition of Apad means that Apad always		This definition of Apad means that Apad always
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 6 ¶
	Implementation Notes:		Implementation Notes:
	Note that the First-Hash above includes the Authentication		Note that the First-Hash above includes the Authentication
	Trailer containing the Apad value, as well as the OSPF		Trailer containing the Apad value, as well as the OSPF
	packet, as per RFC 2328, Section D.4.3.		packet, as per RFC 2328, Section D.4.3.
	The definition of Apad (above) ensures it is always the same		The definition of Apad (above) ensures it is always the same
	length as the hash output. This is consistent with RFC 2328.		length as the hash output. This is consistent with RFC 2328.
	The "(OSPFv2 Packet)" mentioned in the First Hash (above)		The "(OSPFv2 Packet)" mentioned in the First Hash (above)
	does include the OSPF Authentication Trailer.		does include the OSPF Authentication Trailer.
	The digest length for SHA-1 is 20 bytes, for SHA-224 is		The digest length for SHA-1 is 20 bytes, for SHA-256 is
	28 bytes, for SHA-256 is 32 bytes, for SHA-384 is 48 bytes,		32 bytes, for SHA-384 is 48 bytes, and for SHA-512 is
	and for SHA-512 is 64-bytes.		64-bytes.
	(3) SECOND HASH		(3) SECOND HASH
	Then a second hash, also known as the outer hash, is computed		Then a second hash, also known as the outer hash, is computed
	as follows:		as follows:
	Second-Hash = H(Ko XOR Opad || First-Hash)		Second-Hash = H(Ko XOR Opad || First-Hash)
	(4) RESULT		(4) RESULT
	The result Second-Hash becomes the Authentication Data that		The result Second-Hash becomes the Authentication Data that
	is sent in the Authentication Trailer of the OSPFv2 packet.		is sent in the Authentication Trailer of the OSPFv2 packet.
	The length of the Authentication Trailer is always identical		The length of the Authentication Trailer is always identical
	skipping to change at page 11, line 31 ¶		skipping to change at page 11, line 30 ¶
	functions. Also, some large network operators have indicated		functions. Also, some large network operators have indicated
	they prefer to retain the basic mechanism defined in RFC 2328,		they prefer to retain the basic mechanism defined in RFC 2328,
	rather than migrate to IP Security, due to deployment and		rather than migrate to IP Security, due to deployment and
	operational considerations. If all the OSPFv2 routers		operational considerations. If all the OSPFv2 routers
	supported IPsec, then IPsec tunnels could be used in lieu		supported IPsec, then IPsec tunnels could be used in lieu
	of this mechanism.[RFC 4301] This would, however, relegate		of this mechanism.[RFC 4301] This would, however, relegate
	the topology to point-to-point adjacencies over the mesh		the topology to point-to-point adjacencies over the mesh
	of IPsec tunnels.		of IPsec tunnels.
	If a stronger authentication were believed to be required,		If a stronger authentication were believed to be required,
	then the use of a full digital signature [RFC 2154] would		then the use of a full digital signature [RFC 2154] would be
	be an approach that should be seriously considered. Use		an approach that should be seriously considered. Use of full
	of full digital signatures would enable precise		digital signatures would enable precise authentication of the
	authentication of the OSPF router originating each OSPF		OSPF router originating each OSPF link-state advertisement,
	link-state advertisement, in addition to eliminating the		and thereby provide much stronger integrity protection for
	replay issue that was noted above.		the OSPF routing domain.
	5. IANA CONSIDERATIONS		5. IANA CONSIDERATIONS
	There are no IANA considerations for this document.		The OSPF Authentication Codes registry entry for Cryptographic
			Authentication (Registry Code 2) must be updated to refer to
			this document as well as RFC 2328.
	6. ACKNOWLEDGEMENTS		6. ACKNOWLEDGEMENTS
	The authors would like to thank Bill Burr, Tim Polk, John Kelsey,		The authors would like to thank Bill Burr, Tim Polk, John Kelsey,
	and Morris Dworkin of (US) NIST for review of portions of this		and Morris Dworkin of (US) NIST for review of portions of this
	document that are directly derived from the closely related work		document that are directly derived from the closely related work
	on RIPv2 Cryptographic Authentication [RFC 4822].		on RIPv2 Cryptographic Authentication [RFC 4822].
	David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (in		David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (in
	alphabetical order by last name) provided feedback on earlier		alphabetical order by last name) provided feedback on earlier
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	[RFC 1704] N. Haller and R. Atkinson, "On Internet		[RFC 1704] N. Haller and R. Atkinson, "On Internet
	Authentication", RFC 1704, October 1994.		Authentication", RFC 1704, October 1994.
	[RFC 2104] Krawczyk, H. et alia, "HMAC: Keyed-Hashing		[RFC 2104] Krawczyk, H. et alia, "HMAC: Keyed-Hashing
	for Message Authentication", RFC 2104,		for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	[RFC 2154] Murphy, S., Badger, M. and B. Wellington,		[RFC 2154] Murphy, S., Badger, M. and B. Wellington,
	"OSPF with Digital Signatures", RFC 2154, June 1997.		"OSPF with Digital Signatures", RFC 2154, June 1997.
	[RFC 3874] R. Housley, "A 224-bit One-way Hash Function:
	SHA-224", RFC 3874, September 2004.
	[RFC 4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,		[RFC 4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP-106,		"Randomness Requirements for Security", BCP-106,
	RFC 4086, June 2005.		RFC 4086, June 2005.
	[RFC 4301] Kent, S. & K. Seo, "Security Architecture for		[RFC 4301] Kent, S. & K. Seo, "Security Architecture for
	the Internet Protocol", RFC 4301, December 2005.		the Internet Protocol", RFC 4301, December 2005.
	[RFC 4684] Eastlake 3rd, D., & T. Hansen, "US Secure Hash		[RFC 4684] Eastlake 3rd, D., & T. Hansen, "US Secure Hash
	Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.		Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
	skipping to change at page 15, line 4 ¶		skipping to change at page 14, line 44 ¶
	Email: tony.li@tony.li		Email: tony.li@tony.li
	M. Barnes		M. Barnes
	Cisco Systems		Cisco Systems
	225 West Tasman Drive		225 West Tasman Drive
	San Jose, CA		San Jose, CA
	95134 USA		95134 USA
	Email: mjbarnes@cisco.com		Email: mjbarnes@cisco.com
	Randall J. Atkinson		Randall J. Atkinson
	Extreme Networks		Extreme Networks
	3585 Monroe Street		3585 Monroe Street
	Santa Clara, CA		Santa Clara, CA
	95051 USA		95051 USA
	Phone: +1 (408) 579-2800		Phone: +1 (408) 579-2800
	EMail: rja@extremenetworks.com		EMail: rja@extremenetworks.com
	Expires: 11 JAN 2010		Expires: 31 JAN 2010
End of changes. 25 change blocks.
	54 lines changed or deleted		53 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/