< draft-rja-ospf-hmac-shs-00.txt		draft-rja-ospf-hmac-shs-01.txt >
	Internet Draft R. Atkinson		Internet Draft R. Atkinson
	<draft-rja-ospf-hmac-shs-00.txt> Extreme Networks		<draft-rja-ospf-hmac-shs-01.txt> Extreme Networks
	Category: Informational M. Fanto		Category: Informational M. Fanto
	Expires 16 Aug 2007 Ford Motor Company		Expires 28 Aug 2007 Ford Motor Company
	Updates: RFC-2328 T. Li		Updates: RFC-2328 T. Li
	Cisco Systems		Cisco Systems
	22 February 2007		28 February 2007
	OSPFv2 Authentication with HMAC-SHS		OSPFv2 Authentication with HMAC-SHS
	<draft-rja-ospf-hmac-shs-00.txt>		<draft-rja-ospf-hmac-shs-01.txt>
	Status of this Memo		Status of this Memo
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	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.
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	algorithms can be used with OSPF version 2's built-in cryptographic		algorithms can be used with OSPF version 2's built-in cryptographic
	authentication mechanism. This updates, but does not supercede,		authentication mechanism. This updates, but does not supercede,
	the cryptographic authentication mechanism specified in RFC-2328.		the cryptographic authentication mechanism specified in RFC-2328.
	1. INTRODUCTION		1. INTRODUCTION
	This document provides an update to OSPFv2 Cryptographic Authentication,		This document provides an update to OSPFv2 Cryptographic Authentication,
	which is specified in Appendix D of RFC-2328. This document does not		which is specified in Appendix D of RFC-2328. This document does not
	deprecate or supercede RFC-2328. OSPFv2 itself is defined in RFC-2328.		deprecate or supercede RFC-2328. OSPFv2 itself is defined in RFC-2328.
	This document adds support for Secure Hash Algorithms defined in the US		This document adds support for Secure Hash Algorithms defined in the
	NIST Secure Hash Standard (SHS) as defined by NIST FIPS 180-2.		US NIST Secure Hash Standard (SHS) as defined by NIST FIPS 180-2.
	[FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512. The HMAC		[FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512. The
	authentication mode defined in NIST FIPS 198 is used.[FIPS-198]		HMAC authentication mode defined in NIST FIPS 198 is used.[FIPS-198]
	The creation of this addition to OSPFv2 was driven by operator requests		The creation of this addition to OSPFv2 was driven by operator
	that they be able to use the NIST SHS family of algorithms in the NIST		requests that they be able to use the NIST SHS family of algorithms
	HMAC mode, instead of being forced to use the Keyed-MD5 algorithm and		in the NIST HMAC mode, instead of being forced to use the Keyed-MD5
	mode with OSPFv2 Cryptographic Authentication.		algorithm and mode with OSPFv2 Cryptographic Authentication.
	While there are no openly published attacks on the Keyed-MD5		While there are no openly published attacks on the Keyed-MD5
	mechanism specified in RFC-2328, some reports [Dobb96a, Dobb96b]		mechanism specified in RFC-2328, some reports [Dobb96a, Dobb96b]
	create concern about the ultimate strength of the MD5 cryptographic		create concern about the ultimate strength of the MD5 cryptographic
	hash function.		hash function.
	2. Background		2. Background
	All OSPF protocol exchanges are authenticated. The OSPF packet header		All OSPF protocol exchanges are authenticated. The OSPF packet
	(see Section A.3.1 of RFC-2328) includes an Authentication Type field,		header (see Section A.3.1 of RFC-2328) includes an Authentication
	and 64-bits of data for use by the appropriate authentication scheme		Type field, and 64-bits of data for use by the appropriate
	(determined by the type field).		authentication scheme (determined by the type field).
	The authentication type is configurable on a per-interface (or		The authentication type is configurable on a per-interface
	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.
	Authentication types 0, 1, and 2 are defined by RFC-2328. This document		Authentication types 0, 1, and 2 are defined by RFC-2328. This
	provides an update to RFC-2328 that is only applicable to Authentication		document provides an update to RFC-2328 that is only applicable
	Type 2, "Cryptographic Authentication".		to Authentication Type 2, "Cryptographic 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 in all		Using this authentication type, a shared secret key is configured
	routers attached to a common network/subnet. For each OSPF protocol		in all routers attached to a common network/subnet. For each OSPF
	packet, the key is used to generate/verify a "message digest" that is		protocol packet, the key is used to generate/verify a "message digest"
	appended to the end of the OSPF packet. The message digest is a one-way		that is appended to the end of the OSPF packet. The message digest
	function of the OSPF protocol packet and the secret key. Since the secret		is a one-way function of the OSPF protocol packet and the secret key.
	key is never sent over the network in the clear, protection is provided		Since the secret key is never sent over the network in the clear,
	against passive attacks.		protection is provided against passive attacks.
	The algorithms used to generate and verify the message digest are specified		The algorithms used to generate and verify the message digest are
	implicitly by the secret key. This specification discusses the computation		specified implicitly by the secret key. This specification discusses
	of OSPF Cryptographic Authentication data when any of the NIST SHS family		the computation of OSPF Cryptographic Authentication data when
	of algorithms is used in the Hashed Message Authentication Code (HMAC)		any of the NIST SHS family of algorithms is used in the
	mode. Please also see RFC-2328, Appendix D.		Hashed Message Authentication Code (HMAC) mode.
			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-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)
	An implementation of this specification must enhance allow network		An implementation of this specification must enhance allow network
	operators to specify any one of the above algorithms for use with		operators to specify any one of the above algorithms for use with
	each given Key-ID value that is configured into an OSPFv2 implementation.		each given Key-ID value that is configured into an OSPFv2
			implementation.
	3.1. Generating Cryptographic Authentication		3.1. Generating Cryptographic Authentication
	First, following the procedure defined in RFC-2328, Appendix D,		First, following the procedure defined in RFC-2328, Appendix D,
	select the appropriate key for use with this packet and set the		select the appropriate key for use with this packet and set the
	Key-ID field to the chosen key's Key-ID value.		Key-ID field to the chosen key's Key-ID value.
	Second, set the Authentication Data Length field to the length		Second, set the Authentication Data Length field to the length
	(measured in bytes, not bits) of the cryptographic hash that will be		(measured in bytes, not bits) of the cryptographic hash that will be
	used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2		used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 11 ¶
	This also means that the use of hash functions with larger		This also means that the use of hash functions with larger
	output sizes will also increase the size of the OSPFv2 packet		output sizes will also increase the size of the OSPFv2 packet
	as transmitted on the wire.		as transmitted on the wire.
	Implementation Note: RFC-2328, Appendix D specifies that the		Implementation Note: RFC-2328, Appendix D specifies that the
	Authentication Data is not counted in the OSPF packet's own		Authentication Data is not counted in the OSPF packet's own
	length field, but is included in the packet's IP length field.		length field, but is included in the packet's IP length field.
	3.3. Message verification		3.3. Message verification
	Message verification follows the procedure defined in RFC-2328, except		Message verification follows the procedure defined in RFC-2328,
	that the cryptographic calculation of the message digest follows the		except that the cryptographic calculation of the message digest
	procedure above when any NIST SHS algorithm in the HMAC mode is in use.		follows the procedure above when any NIST SHS algorithm in the
	Kindly recall that the cryptographic algorithm/mode in use is indicated		HMAC mode is in use. Kindly recall that the cryptographic
	implicitly by the Key-ID of the received OSPFv2 packet.		algorithm/mode in use is indicated implicitly by the Key-ID
			of the received OSPFv2 packet.
	4. Security Considerations		4. Security Considerations
	This document enhances the security of the OSPFv2 routing protocol		This document enhances the security of the OSPFv2 routing protocol
	by adding support for additional cryptographic hash functions. This		by adding support for additional cryptographic hash functions.
	document adds support for the algorithms defined in the NIST Secure		This document adds support for the algorithms defined in the
	Hash Standard (SHS) using the NIST Hashed Message Authentication Code		NIST Secure Hash Standard (SHS) using the NIST Hashed Message
	(HMAC) mode to the existing OSPFv2 Cryptographic Authentication method.		Authentication Code (HMAC) mode to the existing OSPFv2 Cryptographic
			Authentication method.
	This provides several alternatives to the existing Keyed-MD5 mechanism.		This provides several alternatives to the existing Keyed-MD5
	Although there are no published attacks on the MD5 algorithm as used in		mechanism. Although there are no published attacks on the
	RFC-2328, there are published concerns about the overall strength of the		MD5 algorithm as used in RFC-2328, there are published concerns
	MD5 algorithm. [Dobb96a, Dobb96b]		about the overall strength of the MD5 algorithm. [Dobb96a, Dobb96b]
	The quality of the security provided by the Cryptographic Authentication		The quality of the security provided by the Cryptographic
	option depends completely on the strength of the cryptographic algorithm		Authentication option depends completely on the strength
	and cryptographic mode in use, the strength of the key being used, and the		of the cryptographic algorithm and cryptographic mode in use,
	correct implementation of the security mechanism in all communicating OSPF		the strength of the key being used, and the correct implementation
	implementations. Accordingly, the use of high assurance development		of the security mechanism in all communicating OSPF implementations.
	methods is recommended. It also requires that all parties maintain the		Accordingly, the use of high assurance development methods is
			recommended. It also requires that all parties maintain the
	secrecy of the shared secret key.		secrecy of the shared secret key.
	Because a routing protocol contains information that need not be kept		Because a routing protocol contains information that need not be
	secret, privacy is not a requirement. However, authentication of the		kept secret, privacy is not a requirement. However, authentication
	messages within the protocol is of interest, to reduce the risk of an		of the messages within the protocol is of interest, to reduce the
	adversary compromising the routing system by deliberately injecting		risk of an adversary compromising the routing system by deliberately
	false information into the routing system.		injecting false information into the routing system.
	The technology in this document enhances an authentication mechanism		The technology in this document enhances an authentication mechanism
	for OSPFv2. The mechanism described here is not perfect and does not		for OSPFv2. The mechanism described here is not perfect and need
	need to be perfect. Instead, this mechanism represents a significant		not be perfect. Instead, this mechanism represents a significant
	increase in the work function of an adversary attacking OSPFv2,		increase in the work function of an adversary attacking OSPFv2,
	as compared with plain-text authentication or null authentication,		as compared with plain-text authentication or null authentication,
	while not causing undue implementation, deployment, or operational		while not causing undue implementation, deployment, or operational
	complexity. Denial of service attacks are not generally preventable		complexity. Denial of service attacks are not generally preventable
	in a useful networking protocol. [VK83]		in a useful networking protocol. [VK83]
	Because of implementation considerations, including the need for		Because of implementation considerations, including the need for
	backwards compatibility, this specification uses the same mechanism		backwards compatibility, this specification uses the same mechanism
	as specified in RFC-2328 and limits itself to adding support for		as specified in RFC-2328 and limits itself to adding support for
	additional cryptographic hash functions. Also, some large network		additional cryptographic hash functions. Also, some large network
	operators have indicated they strongly prefer to retain the basic		operators have indicated they strongly prefer to retain the basic
	mechanism defined in RFC-2328 due to deployment and operational		mechanism defined in RFC-2328 due to deployment and operational
	considerations. If all the OSPFv2 systems deployed by a given		considerations. If all the OSPFv2 systems deployed by a given
	network operator also supported using the IP Authentication Header		network operator also supported using the IP Authentication Header
	to protect OSPFv2, then such a network operator might consider using		to protect OSPFv2, then such a network operator might consider
	the IP Authentication Header in lieu of this mechanism.		using the IP Authentication Header in lieu of this mechanism.
	If a stronger authentication were believed to be required, then the use		If a stronger authentication were believed to be required,
	of a full digital signature [RFC-2154] would be an approach that should be		then the use of a full digital signature [RFC-2154] would be
	seriously considered. It was rejected for this purpose at this time		an approach that should be seriously considered. It was
	because the computational burden of full digital signatures is believed		rejected for this purpose at this time because the computational
	to be much higher than is reasonable given the current threat environment		burden of full digital signatures is believed to be much higher
	in operational commercial networks. Also, moving to full digital signatures		than is reasonable given the current threat environment in
	significantly increases the deployment complexity and operational burden		operational commercial networks. Also, moving to full digital
	for network operators.		signatures significantly increases the deployment complexity and
			operational burden for network operators.
	5. IANA CONSIDERATIONS		5. IANA CONSIDERATIONS
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	6. ACKNOWLEDGEMENTS		6. ACKNOWLEDGEMENTS
	TBD		The authors would like to thank Bill Burr, Tim Polk, John Kelsey,
			and Morris Dworkin of (US) NIST for review of portions of this
			document that are directly derived from the closely related work
			on RIPv2 Cryptographic Authentication [RFC-4822].
	7. REFERENCES		7. REFERENCES
	7.1 Normative References		7.1 Normative References
	[FIPS-180-2] US National Institute of Standards & Technology,		[FIPS-180-2] US National Institute of Standards & Technology,
	"Secure Hash Standard (SHS)", FIPS PUB 180-2,		"Secure Hash Standard (SHS)", FIPS PUB 180-2,
	August 2002.		August 2002.
	[FIPS-198] US National Institute of Standards & Technology,		[FIPS-198] US National Institute of Standards & Technology,
	"The Keyed-Hash Message Authentication Code (HMAC)",		"The Keyed-Hash Message Authentication Code (HMAC)",
	FIPS PUB 198, March 2002.		FIPS PUB 198, March 2002.
			[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
			Requirement Levels", RFC-2119, BCP-14, March 1997.
	[RFC-2328] Moy, J., "OSPF Version 2", RFC-2328, April 1998.		[RFC-2328] Moy, J., "OSPF Version 2", RFC-2328, April 1998.
	7.2 Informative References		7.2 Informative References
			[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol
			Suite", ACM Computer Communications Review, Volume 19,
			Number 2, pp. 32-48, April 1989.
	[Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress",		[Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress",
	Technical Report, 2 May 1996. (Presented at the		Technical Report, 2 May 1996. (Presented at the
	Rump Session of EuroCrypt 1996.)		Rump Session of EuroCrypt 1996.)
	[Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent		[Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent
	Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.		Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
	[RFC-2154] Murphy, S., Badger, M. and B. Wellington,		[RFC-1704] N. Haller and R. Atkinson, "On Internet
			Authentication", RFC 1704, October 1994.
			[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-4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
			"Randomness Requirements for Security", BCP-106,
			RFC-4086, June 2005.
			[RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic Authentication",
			RFC-4822, February 2007.
	[VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level		[VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level
	Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.		Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
	AUTHORS		AUTHORS
	Randall J. Atkinson		Randall J. Atkinson
	Extreme Networks		Extreme Networks
	3585 Monroe Street		3585 Monroe Street
	Santa Clara, CA 95051 USA		Santa Clara, CA 95051 USA
End of changes. 26 change blocks.
	72 lines changed or deleted		99 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/