< draft-li-isis-hmac-shs-00.txt		draft-li-isis-hmac-shs-01.txt >
	Internet Draft R. Atkinson		Internet Draft R. Atkinson
	<draft-li-isis-hmac-shs-00.txt> Extreme Networks		<draft-li-isis-hmac-shs-01.txt> Extreme Networks
	Category: Informational T. Li		Category: Informational T. Li
	Expires 16 Aug 2007 cisco Systems		Expires 28 Aug 2007 Cisco Systems
	M. Fanto		Updates: RFC-3567 M. Fanto
	Ford Motor Company		Ford Motor Company
	16 February 2007		28 February 2007
	IS-IS Authentication with HMAC-SHS		IS-IS Authentication with HMAC-SHS
	<draft-li-isis-hmac-shs-00.txt>		<draft-li-isis-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 line 48 ¶		skipping to change at page 1, line 50 ¶
	This document describes how the NIST Secure Hash Standard		This document describes how the NIST Secure Hash Standard
	family of algorithms are used for IS-IS authentication.		family of algorithms are used for IS-IS authentication.
	1. INTRODUCTION		1. INTRODUCTION
	This document provides an update to IS-IS Cryptographic		This document provides an update to IS-IS Cryptographic
	Authentication, which is specified in RFC-3567. This document		Authentication, which is specified in RFC-3567. This document
	does not deprecate RFC-3567. IS-IS as deployed in the Internet		does not deprecate RFC-3567. IS-IS as deployed in the Internet
	is defined by RFC-1195 and ISO 10589.		is defined by RFC-1195 and ISO 10589.
	This document adds support for all algorithms defined in the US		This document adds support for all algorithms defined in the
	NIST Secure Hash Standard (SHS) as defined in NIST FIPS 180-2.
	[FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512. The		US NIST Secure Hash Standard (SHS) as defined in NIST FIPS 180-2.
	HMAC authentication mode as defined in NIST FIPS 198 is used.		[FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512.
			The HMAC authentication mode as defined in NIST FIPS 198 is used.
	[FIPS-198]		[FIPS-198]
	This creation of this addition to IS-IS was driven by operator		This creation of this addition to IS-IS was driven by operator
	requests that they be able to use the NIST SHS family of algorithms,		requests that they be able to use the NIST SHS family of algorithms,
	instead of being forced to use the MD5 algorithm.		in the NIST HMAC mode, instead of being forced to use the
			Keyed-MD5 algorithm and mode.
	While there are no openly published attacks on the HMAC-MD5		While there are no openly published attacks on the HMAC-MD5
	mechanism, some reports [Dobb96a, Dobb96b] create concern		mechanism, some reports [Dobb96a, Dobb96b] create concern
	about the ultimate strength of the MD5 cryptographic hash		about the ultimate strength of the MD5 cryptographic hash
	function.		function.
	2. AUTHENTICATION PROCEDURES		2. AUTHENTICATION PROCEDURES
	The authentication type used for any of the HMAC-SHS algorithms		The authentication type used for any of the HMAC-SHS algorithms
	is 54 (0x36), which is the same authentication type used for the		is XX.
	existing HMAC-MD5 algorithm.
	The length of the Authentication Value varies with the specific		The length of the Authentication Value varies with the specific
	hashing algorithm used. The length field in the TLV is the sum		hashing algorithm used. The length field in the TLV is the sum
	of the length of the Authentication Value field and the number 1.		of the length of the Authentication Value field and the number 1.
	For example, when SHA-256 is in use, the length of the Authentication		For example, when SHA-256 is in use, the length of the Authentication
	Value is 32 and the length field in the TLV is 33.		Value is 32 and the length field in the TLV is 33.
	2.1 Authentication Process.		2.1 Authentication Process.
	When calculating the HMAC-SHS result for Sequence Number PDUs,		When calculating the HMAC-SHS result for Sequence Number PDUs,
	Level 1 Sequence Number PDUs SHALL use the Area Authentication string		Level 1 Sequence Number PDUs SHALL use the Area Authentication string
	as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use		as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall
	the domain authentication string as in Level 2 Link State PDUs.		use the domain authentication string as in Level 2 Link State PDUs.
	IS-IS HELLO PDUs SHALL use the Link Level Authentication String,		IS-IS HELLO PDUs SHALL use the Link Level Authentication String,
	which MAY be different from that of Link State PDUs. The HMAC-SHS		which MAY be different from that of Link State PDUs. The HMAC-SHS
	result for the IS-IS HELLO PDUs SHALL be calculated after the Packet		result for the IS-IS HELLO PDUs SHALL be calculated after the Packet
	is padded to the MTU size, if padding is not disabled. Implementations		is padded to the MTU size, if padding is not disabled. Implementations
	that support the optional checksum for the Sequence Number PDUs and		that support the optional checksum for the Sequence Number PDUs and
	IS-IS HELLO PDUs MUST NOT include the Checksum TLV.		IS-IS HELLO PDUs MUST NOT include the Checksum TLV.
	2.2 Cryptographic Aspects		2.2 Cryptographic Aspects
	In the algorithm description below, the following nomenclature,		In the algorithm description below, the following nomenclature,
	skipping to change at line 119 ¶		skipping to change at page 3, line 28 ¶
	If the Authentication Key (K) is L octets long, then Ko is equal		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,		to 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		then Ko 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)		than L octets long, then Ko is set to the Authentication Key (K)
	with zeros appended to the end of the Authentication Key (K) such		with zeros appended to the end of the Authentication Key (K) such
	that Ko is L octets long.		that Ko is L octets long.
	(2) FIRST HASH		(2) FIRST HASH
	First, the IS-IS packet's Authentication Data field is filled		First, the IS-IS packet's Authentication Data field is filled
	with the value Apad and the Authentication Type field is set		with the value Apad and the Authentication Type field is set
	to 54.		to XX.
	Then, a first hash, also known as the inner hash, is computed		Then, a first hash, also known as the inner hash, is computed
	as follows:		as follows:
	First-Hash = H(Ko XOR Ipad || (IS-IS Packet))		First-Hash = H(Ko XOR Ipad || (IS-IS Packet))
	(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)
	skipping to change at line 144 ¶		skipping to change at page 4, line 4 ¶
	the message digest size of the specific hash function H that is		the message digest size of the specific hash function H that is
	being used.		being used.
	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 IS-IS packet		output sizes will also increase the size of the IS-IS packet
	as transmitted on the wire.		as transmitted on the wire.
	2.3 Accepting Authenticated IS-IS Packets		2.3 Accepting Authenticated IS-IS Packets
	To authenticate an incoming PDU, a system should save the value		To authenticate an incoming PDU, a system should save the value
	of the Authentication Value field, the Checksum, and the Remaining		of the Authentication Value field, the Checksum, and the Remaining
	Lifetime fields. Then set the Authentication Value equal to Apad		Lifetime fields. Then set the Authentication Value equal to Apad
	and zero the Checksum and Remaining Lifetime fields. The Authentication		and zero the Checksum and Remaining Lifetime fields. The
	Value is then computed as described above, then the values of these		Authentication Value is then computed as described above,
	three fields is restored.		and finally the values of these three fields is restored.
	An implementation that implements HMAC-SHS authentication and		An implementation that implements HMAC-SHS authentication and
	receives HMAC-SHS Authentication Information MUST discard the PDU		receives HMAC-SHS Authentication Information MUST discard the PDU
	if the Authentication Value is incorrect.		if the Authentication Value is incorrect. The implementation
			SHOULD log such authentication failures in some implementation
			specific manner.
	An implementation MAY have a transition mode where it includes		An implementation MAY have a transition mode where it includes
	HMAC-SHS Authentication Information in PDUs but does not verify		HMAC-SHS Authentication Information in PDUs but does not verify
	the HMAC-SHS authentication information. This is a transition aid		the HMAC-SHS authentication information. This is a transition aid
	for networks in the process of deploying authentication.		for networks in the process of deploying authentication.
	An implementation MAY check a set of passwords when verifying the		An implementation MAY check a set of passwords when verifying the
	Authentication Value. This provides a mechanism for incrementally		Authentication Value. This provides a mechanism for incrementally
	changing passwords in a network.		changing passwords in a network.
	skipping to change at line 176 ¶		skipping to change at page 4, line 39 ¶
	LSP purges MUST remove the body of the LSP and add the authentication		LSP purges MUST remove the body of the LSP and add the authentication
	TLV. ISes implementing HMAC-SHS authentication MUST NOT accept		TLV. ISes implementing HMAC-SHS authentication MUST NOT accept
	unauthenticated purges. ISes MUST NOT accept purges that contain		unauthenticated purges. ISes MUST NOT accept purges that contain
	TLVs other than the authentication TLV. These restrictions are		TLVs other than the authentication TLV. These restrictions are
	necessary to prevent a hostile system from receiving an LSP, setting		necessary to prevent a hostile system from receiving an LSP, setting
	the Remaining Lifetime field to zero, and flooding it, thereby		the Remaining Lifetime field to zero, and flooding it, thereby
	initiating a purge without knowing the authentication password.		initiating a purge without knowing the authentication password.
	2.4 Implementation Considerations		2.4 Implementation Considerations
			Conceptually, there is an "IS-IS Security Association", both
			in this specification and in RFC-3567. This security association
			consists of a cryptographic key (K), an authentication algorithm
			(e.g. SHA-256), a cryptographic mode (e.g. HMAC), a start time,
			and a stop time. Start Time is a local representation of the
			day and time when the security association first becomes valid.
			Stop Time is a local representation of the day and time when the
			security association ceases to be valid. However, this is an
			architectural concept and does not strictly constrain the
			implementation to follow precisely that representation internally.
			For example, one might choose to combine the authentication algorithm
			with the cryptographic mode as a single integrated datum inside
			a particular IS-IS implementation. Similarly, one might choose
			to store the Start Time and a time duration, in lieu of storing
			the literal Start Time and Stop Time. In such a case, the Stop
			Time could be computed by adding the time duration to the Start
			Time. Note that it is permitted for an IS-IS Security Association
			to have infinite lifetime, although this is not recommended
			operational practice. In order to support smooth key rollover,
			an implementation MUST be able to support at least 2 concurrent
			IS-IS Security Associations.
	There is an implementation issue just after password rollover		There is an implementation issue just after password rollover
	on an IS-IS router that might benefit from additional commentary.		on an IS-IS router that might benefit from additional commentary.
	Immediately after password rollover on the router, the router or		Immediately after password rollover on the router, the router or
	IS-IS process may restart. If this happens, this causes the LSP		IS-IS process may restart. If this happens, this causes the LSP
	Sequence Number restarts from the value 1 using the new password.		Sequence Number restarts from the value 1 using the new password.
	However, neighbors will reject those new LSPs because the Sequence		However, neighbors will reject those new LSPs because the Sequence
	Number is smaller. The router can not increase its own LSP		Number is smaller. The router can not increase its own LSP
	Sequence Number because it fails to authenticate its own old LSP		Sequence Number because it fails to authenticate its own old LSP
	that neighbors keep sending to it. So the router can not update		that neighbors keep sending to it. So the router can not update
	its LSP Sequence Number to its neighbors until all the neighbors		its LSP Sequence Number to its neighbors until all the neighbors
	skipping to change at line 201 ¶		skipping to change at page 5, line 37 ¶
	accordingly and re-flood the LSPs. However, as this scenario		accordingly and re-flood the LSPs. However, as this scenario
	could also be triggered by an active attack by an adversary,		could also be triggered by an active attack by an adversary,
	it is recommended that a counter also be kept on this case		it is recommended that a counter also be kept on this case
	to mitigate the risk from such an active attack.		to mitigate the risk from such an active attack.
	3. SECURITY CONSIDERATIONS		3. SECURITY CONSIDERATIONS
	This document enhances the security of the IS-IS routing protocol		This document enhances the security of the IS-IS routing protocol
	by adding support for additional cryptographic hash functions.		by adding support for additional cryptographic hash functions.
	Because a routing protocol contains information that need not be kept		Because a routing protocol contains information that need not
	secret, privacy is not a requirement. However, authentication of the		remain 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 provides an authentication mechanism		The technology in this document provides an authentication mechanism
	for IS-IS. The mechanism described here is not perfect and does not		for IS-IS. The mechanism described here is not perfect and does not
	need to be perfect. Instead, this mechanism represents a significant		need to be perfect. Instead, this mechanism represents a significant
	increase in the work function of an adversary attacking the IS-IS		increase in the work function of an adversary attacking the IS-IS
	protocol, while not causing undue implementation, deployment, or		protocol, while not causing undue implementation, deployment, or
	operational complexity.		operational complexity.
	This mechanism does not prevent replay attacks, however, in most		This mechanism does not prevent replay attacks, however, in most
	cases, such attacks would trigger existing mechanisms in the IS-IS		cases, such attacks would trigger existing mechanisms in the IS-IS
	protocol that would effectively reject old information. Denial of		protocol that would effectively reject old information. Denial of
	service attacks are not generally preventable in a useful networking		service attacks are not generally preventable in a useful networking
	protocol [VK83].		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-3567 and limits itself to adding support for		as specified in RFC-3567 and limits itself to adding support for
	additional cryptographic hash functions. Network operators have		additional cryptographic hash functions. Network operators have
	indicated they strongly prefer to retain the basic mechanism		indicated they strongly prefer to retain the basic mechanism
	defined in RFC-3567.		defined in RFC-3567. In particular, network operators have
			indicated a preference for omitting the Key-ID field used with
			OSPFv2 or RIPv2 authentication. They do not consider the absence
			of a Key-ID field in the packet problematic, given the existing
			successful deployments of "keychains" with IS-IS cryptographic
			authentication.
	If a stronger authentication were believed to be required, then the		If a stronger authentication were believed to be required, then
	use of a full digital signature [RFC-2154] would be an approach that		the use of a full digital signature [RFC-2154] would be an approach
	should be seriously considered. It was rejected for this purpose		that should be seriously considered. It was rejected for this purpose
	at this time because the computational burden of full digital signatures		at this time because the computational burden of full digital signatures
	is believed to be much higher than is reasonable given the current		is believed to be much higher than is reasonable given the current
	threat environment in operational commercial networks.		threat environment in operational commercial networks.
	4. IANA CONSIDERATIONS		4. IANA CONSIDERATIONS
	There are no IANA considerations for this document.		ISO 10589 created an Authentication Information TLV (code 10) for use
			in IS-IS routing protocol packets (PDUs). The first octet in the TLV
			is defined as the Authentication Type. ISO 10589 reserves the
			following IS-IS authentication code points:
			0 - Reserved
			1 - Cleartext Password
			255 - Routeing Domain private authentication method
			ISO 10589 also reserves code points 2-254.
			This document requests that IANA create a new code point registry
			to administer the Authentication Type code points for TLV 10.
			This registry would be part of the existing IS-IS code points
			registry as established by RFC 3563 and RFC 3359. This registry
			should be managed using the Designated Expert policy as described
			in [RFC-2434].
			This document also requests that IANA populate the registry with
			the code points described above and also reserve code point 54 for
			HMAC-MD5 authentication, as described by RFC 3567. This document
			also requests that IANA reserve a code point for HMAC-SHA
			authentication, as described by this document. The value for this
			HMAC-SHA code point should be inserted into this document in
			Section 2 above, to replace the value XX found therein.
			[RFC Editor note: This section should be removed prior
			to RFC publication.]
	5. ACKNOWLEDGEMENTS		5. 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].
	6. REFERENCES		6. REFERENCES
	6.1 Normative References		6.1 Normative References
	[ISO-10589] International Standards Organisation, "Intermediate		[ISO-10589] International Standards Organisation, "Intermediate
	System to Intermediate System Routing Information		System to Intermediate System Routing Information
	Exchange Protocol for use in Conjunction with the		Exchange Protocol for use in Conjunction with the
	Protocol for Providing the Connectionless-mode		Protocol for Providing the Connectionless-mode
	Network Service (ISO 8473)", ISO/IEC 10589:2002,		Network Service (ISO 8473)", ISO/IEC 10589:2002,
	Second Edition, 2002.		Second Edition, 2002.
	[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-2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", RFC-2434, October 1998.
			[RFC-3692] T. Narten, "Assigning Experimental and Testing Numbers
			Considered Useful. RFC-3692, January 2004.
	6.2 Informative References		6.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-1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP		[RFC-1195] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP
	and Dual Environments", RFC 1195, December 1990.		and Dual Environments", RFC 1195, December 1990.
	[RFC-2154] Murphy, S., Badger, M. and B. Wellington,		[RFC-1704] Haller, N. and R. Atkinson, "On Internet
	"OSPF with Digital Signatures", RFC 2154, June 1997.		Authentication", RFC 1704, October 1994.
			[RFC-2154] S. Murphy, M. Badger, and B. Wellington,
			"OSPF with Digital Signatures", RFC 2154, June 1997.
			[RFC-3359] T. Przygienda, "Reserved Type, Length and Value (TLV)
			Codepoints in Intermediate System to Intermediate System",
			RFC-3359, August 2002.
			[RFC-3563] A. Zinin, "Cooperative Agreement Between the ISOC/IETF
			and ISO/IEC Joint Technical Committee 1/Sub Committee 6
			(JTC1/SC6) on IS-IS Routing Protocol Development",
			RFC-3563, July 2003.
			[RFC-3567] T. Li, R. Atkinson, "Intermediate System to Intermediate
			System (IS-IS) Cryptographic Authentication", RFC-3567,
			July 2003.
			[RFC-4086] D. Eastlake III, J. Schiller, 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. 23 change blocks.
	34 lines changed or deleted		132 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/