< draft-ietf-isis-hmac-00.txt		draft-ietf-isis-hmac-01.txt >
			Network Working Group T. Li
			Internet-Draft Procket Networks
			Category: Standards Track R. Atkinson
			draft-ietf-isis-hmac-01.txt 10 April 2000
	Network Working Group Tony Li		IS-IS Cryptographic Authentication
	INTERNET DRAFT Juniper Networks
	January 1999
	IS-IS HMAC-MD5 Authentication
	<draft-ietf-isis-hmac-00.txt>		Status of this Memo
	Status		This document is an Internet-Draft and is in full conformance with
			all provisions of Section 10 of RFC-2026. This document is a
			submission to the IETF IS-IS Working Group.
	This document is an Internet-Draft. Internet-Drafts are working		Internet-Drafts are working documents of the Internet Engineering
	documents of the Internet Engineering Task Force (IETF), its areas,		Task Force (IETF) and its working groups. Note that other groups may
	and its working groups. Note that other groups may also distribute		also distribute working documents as Internet-Drafts.
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of 6 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".
	To view the entire list of current Internet-Drafts, please check the		The list of current Internet-Drafts can be accessed at
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		http://www.ietf.org/ietf/1id-abstracts.txt
	Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
	ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
	1.0 Abstract		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/ietf/shadow.html
	This document describes the authentication of IS-IS PDUs using the		ABSTRACT
	HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions
	to support IPv4 described in [3]. The base specification includes an
	authentication mechanism that allows for multiple authentication
	algorithms. The base specification only specifies the algorithm for
	cleartext passwords.
	This document proposes an extension to that specification that allows		This document specifies an algorithm-independent cryptographic
	the use of the HMAC-MD5 authentication algorithm to be used in		authentication mechanism for use with the IS-IS routing protocol.
	conjunction with the existing authentication mechanisms.
	2.0 Introduction		1. Use of Imperatives
	The IS-IS protocol, as specified in ISO 10589, provides for the		Throughout this document, the words that are used to define the
	authentication of Link State PDUs (LSPs) through the inclusion of		significance of particular requirements are capitalized. These words
			have the meaning defined in RFC-2119, which is hereby incorporated by
			reference. [7]
			2. Introduction
			Growth in the Internet has made us aware of the need for improved
			authentication of routing information. Other routing protocols are
			known to have been the subject of both active and passive attacks.
			At present, IS-IS provides for unauthenticated service or password
			authentication. Both are vulnerable to passive attacks currently
			widespread in the Internet. Well-understood security issues exist in
			routing protocols [3]. Clear text passwords, currently specified for
			use with IS-IS, are no longer considered sufficient [4] in the
			Internet.
			If authentication is disabled, then only simple misconfigurations
			are detected. Simple passwords transmitted in the clear will further
			protect against the honest neighbor, but are useless in the general
			case. By simply capturing information on the wire - straightforward
			even in a remote environment - a hostile process can learn the
			password and overcome the network. While IS-IS packets aren't
			themselves routed, anyone with access to a system on the physical
			link can inject forged packets (unless a cryptographic authentication
			method is in use).
			We propose that IS-IS use an authentication algorithm, as was
			originally proposed for SNMP Version 2. Keyed MD5 is proposed as the
			standard authentication algorithm for IS-IS, but the authentication
			mechanism is believed to be algorithm-independent.
			While this mechanism is not unbreakable (no known mechanism
			is), it provides a greatly enhanced probability that a system being
			attacked will detect and ignore hostile messages. This is because we
			transmit the output of an authentication algorithm (e.g., Keyed MD5)
			rather than the secret IS-IS Authentication Key. This output is a
			one-way function of a message and a secret IS-IS Authentication Key.
			This IS-IS Authentication Key is never sent over the network in the
			clear, thus providing protection against the passive attacks now
			commonplace in the Internet.
			In this way, protection is afforded against forgery or message
			modification. It is possible to replay a LSP until the LSP sequence
			number changes, but the normal dynamics of the protocol make LSP
			replay less of an issue in the long-term. The mechanism does not
			afford confidentiality, since messages stay in the clear; however,
			the mechanism is also exportable from most countries, which test a
			privacy algorithm would fail.
			Other relevant rationales for the approach are that Keyed MD5 is
			being used for RIPv2 and OSPF cryptographic authentication, and is
			therefore present in routers already, as is some form of password
			management. In the interest of code reuse, this IS-IS extension
			specifies Keyed-MD5 as the mandatory-to-implement algorithm. There
			are no specific known vulnerabilities in Keyed-MD5 as used in this
			context. A similar approach has been standardized for use in IP-
			layer authentication. [6]
			This document is a publication of the IS-IS Working Group
			within the IETF. It is also a contribution to ISO IEC JTC1/SC6, for
			eventual inclusion with ISO 10589.
			3. Implementation Approach
			Implementation requires three issues to be addressed:
			(1) TLV format for use with cryptographic authentication,
			(2) Authentication procedures, and
			(3) Management controls.
			3.1. IS-IS PDU Format
			The IS-IS protocol, as specified in ISO 10589, provides for the
			authentication of Link-State PDUs (LSPs) through the inclusion of
	authentication information as part of the LSP. This authentication		authentication information as part of the LSP. This authentication
	information is encoded as a Type-Length-Value (TLV) tuple. The type		information is encoded as a Type-Length-Value triple.
	of the TLV is specified as 10. The length of the TLV is variable.
	The value of the TLV depends on the authentication algorithm and
	related secrets being used. The first octet of the value is used to
	specify the authentication type. Type 0 is reserved, type 1
	indicates a cleartext password, and type 255 is used for routing
	domain private authentication methods. The remainder of the TLV
	value is known as the Authentication Value.
	This document extends the above situation by allocating a new		The type of the Authentication TLV is 10. The length of the
	authentication type for HMAC-MD5 and specifying the algorithms for		TLV is variable. The value of the TLV depends on the Authentication
	the computation of the Authentication Value. This document also		Type being used.
	describes modifications to the base protocol to insure that the
	authentication mechanisms described in this document are effective.
	This document is a publication of the IS-IS Working Group within the		The first octet of the value field indicates the
	IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual		Authentication Type. Authentication Type 0 is reserved. Type 1
	inclusion with ISO 10589.		indicates a clear-text password, and Type 255 is used for routing
			domain private authentication methods.
	3.0 Authentication Procedures		This document specifies an extension for cryptographic
			authentication. When cryptographic authentication is in use, the
			Authentication Type in the first octet of the Value field is set to
			54 and the second octet of the Value field contains a Key Identifier
			(Key-ID). The Key Identifier is used by the recipient to select the
			particular IS-IS Security Association in use for this PDU. The
			remainder of the Value field contains the Authentication Data itself.
			Thus, the Length of the TLV is (2 + sizeof(authentication data)),
			when the Authentication Type is cryptographic authentication.
	The authentication type used for HMAC-MD5 is 54 (0x36). The length		0 1 2 3
	of the Authentication Value for HMAC-MD5 is 16, and the length field		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	in the TLV is 17.		+---------------+---------------+---------------+---------------+
			| TLV Type=10 | TLV Length | AuthType = 54 | Key Identifier|
			+---------------+---------------+---------------+---------------+
			| Authentication Data (Length varies with Crypto Algorithm) |
			+---------------+---------------+---------------+---------------+
			Figure 1: Authentication TLV Format,
			when Cryptographic Authentication is in use
	The HMAC-MD5 algorithm requires a key K and text T as input. The key		3.2 Authentication Procedures
	K is the password for the PDU type, as specified in ISO 10589. The
	text T is the PDU to be authenticated with the Authentication Value
	field inside of the Authentication Information TLV set to zero. Note
	that the Authentication Type is set to 54 and the length of the TLV
	is set to 17 before authentication is computed. When LSPs are
	authenticated, the Checksum and Remaining Lifetime fields are set to
	zero (0) before authentication is computed. The result of the
	algorithm is placed in the Authentication Value field.
	An implementations that implements HMAC-MD5 authentication and		Conforming or compliant implementations MUST implement the
	receives HMAC-MD5 Authentication Information MUST discard the PDU if		HMAC-MD5 cryptographic algorithm with this extension. The
	the Authentication Value is incorrect.		algorithm-dependent details of HMAC-MD5 are specified in Appendix A.
	An implementation MAY include HMAC-MD5 Authentication Information in		A fundamental concept of IS-IS Cryptographic Authentication
	PDUs even if it does not fully implement HMAC-MD5 authentication.		is the "IS-IS Security Association". An IS-IS Security Association
	This allows an implementation to generate authentication information		contains a Key Identifier, the Cryptographic Authentication Algorithm
	without verifying the authentication information. This is a		(e.g. HMAC-MD5) to use, a Lifetime, and the Cryptographic
	transition aid for networks in the process of deploying		Authentication Key to use. The Cryptographic Authentication Key is
	authentication.		also the password for the PDU Type, as specified in ISO 10589.
	An implementation MAY check a set of passwords when verifying the		An implementation MAY include cryptographic authentication
	Authentication Value. This provides a mechanism for incrementally		information in PDUs even if it does not fully implement cryptographic
	changing passwords in a network.		authentication. This allows an implementation to generate
			authentication information without verifying the authentication
			information as a transition aid for networks in the process of
			deploying authentication.
	An implementation that does not implement HMAC-MD5 authentication MAY		An implementation that does not implement cryptographic
	accept a PDU that contains the HMAC-MD5 Authentication Type.		authentication MAY accept a PDU that contains the cryptographic
			authentication type.
	ISes (routers) that implement HMAC-MD5 authentication and initiating		The remainder of this section describes the algorithm-
	LSP purges MUST remove the body of the LSP and add the authentication		independent processing for IS-IS Cryptographic Authentication.
	TLV. ISes MUST NOT accept unauthenticated purges. ISes MUST NOT
	accept purges that contain TLVs other than the authentication TLV.
	These restrictions are necessary to prevent a hostile system from
	receiving an LSP, setting the Remaining Lifetime field to zero, and
	flooding it, thereby initiating a purge without knowing the
	authentication password.
	4.0 Security Considerations		The Type, Length, Authentication Type, and Key Identifier
			fields are filled with their final values prior to calculation of the
			cryptographic Authentication Data. The Authentication Data field,
			the Checksum field, and the Remaining Lifetime fields are all filled
			with all zeros for the calculation of the cryptographic
			Authentication Data for a given LSP. Sending systems calculate the
			Checksum value after the Authentication Data field has been filled
			in. After the Checksum value has been calculated, it is placed in
			the IS-IS packet.
	This document enhances the security of the IS-IS routing protocol.		[New paragraph discussing how contents are dealt with for non-LSPs
	Because a routing protocol contains information that is not of		(e.g. CSNPs, IIHs) coming here soon.]
	significant value, privacy is not a requirement. However,
	authentication of the messages within the protocol is of interest.
	The technology in this document provides an authentication mechanism		When multiple valid IS-IS Security Associations exist for a
	for IS-IS. This mechanism does not prevent replay attacks, however		given IS-IS system, sending systems SHOULD pick an IS-IS Security
	such attacks would trigger mechanisms in the protocol that would		Association that is not about to expire in order to facilitate smooth
	effectively reject old information. This document does not address		key rollover.
	denial-of-service attacks.
	5.0 Acknowledgments		Receiving systems first check the Key-ID field and use its
			value to locate the appropriate IS-IS Security Association. If no
			IS-IS Security Association exists, the packet is discarded as not
			authentic, without any further processing. If the matching IS-IS
			Security Association is located, then the receiving system
			independently computes the cryptographic Authentication Data using
			the key contained in that IS-IS Security Association and the values
			in the received IS-IS packet. For receive-side authentication
			computations, the Authentication Data field itself, the Checksum
			field, and the Remaining Lifetime fields are each assumed to be zero.
			If the computed cryptographic Authentication Data is identical to the
			received Authentication Data, the packet is accepted as authentic and
			undergoes normal IS-IS receive-side processing. If there is any
			difference, the packet is discarded as not authentic, without any
			further processing.
	The author would like to thank Henk Smit, Dave Katz and Tony		An implementation SHOULD log authentication failures of
	Przygienda for their comments on this work.		received IS-IS PDUs if this can be done without creating a denial of
			service attack on the Intermediate System. Details of this are
			unspecified here.
	6.0 References		Intermediate Systems (i.e. routers) that implement
			cryptographic authentication and initiating LSP purges MUST remove
			the body of the LSP and add the authentication TLV. Intermediate
			Systems MUST NOT accept unauthenticated purges. Intermediate Systems
			MUST NOT accept purges that contain TLVs other than the
			Authentication TLV. These restrictions are necessary to prevent a
			hostile system from receiving an LSP, setting the Remaining Lifetime
			field to zero, and flooding it, thereby initiating a purge without
			knowing any authentication information.
	[1] RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", H.		3.3. Key Management Requirements
	Krawczyk, M. Bellare, R. Canetti, February 1997
	[2] ISO 10589, "Intermediate System to Intermediate System Intra-		It is strongly desirable that a hypothetical security breach in
	Domain Routeing Exchange Protocol for use in Conjunction with the		one Internet protocol not automatically compromise other Internet
	Protocol for Providing the Connectionless-mode Network Service (ISO		protocols. The Cryptographic Authentication Key of this
	8473)" [Also republished as RFC 1142]		specification SHOULD NOT be stored or transmitted using protocols or
			algorithms that have known flaws.
	[3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual		Implementations MUST support the storage and use of at least two
	environments", R.W. Callon, Dec. 1990		IS-IS Security Associations at the same time. During normal
			operation, only one IS-IS Security Association (i.e. one key) will
			usually be active in a given IS-IS system. However, during the key
			change period, both the old IS-IS Security Association and the new
			IS-IS Security Association (i.e. two keys) will be active in the same
			system at the same time.
	10.0 Author's Address		An IS-IS Security Association MUST contain at least the
			lifetime of the IS-IS Security Association (e.g. date/time first
			valid and date/time no longer valid), the Key Identifier, the
			Cryptographic Authentication Algorithm, and the Cryptographic Key
			itself. The IS-IS Security Association lifetime MAY be infinite or
			MAY have a specific date/time for start and end.
			Implementations MUST support manual key distribution (e.g.,
			the privileged user manually typing in the parameters for the IS-IS
			Security Association (i.e. key, key lifetime, and key identifier) on
			the router console. If more than one algorithm is supported, then
			the implementation MUST require that the algorithm be specified for
			each IS-IS Security Association at the time the other IS-IS Security
			Association information is entered. IS-IS Security Associations that
			are out of date MAY be deleted at will by the implementation without
			requiring human intervention. Manual deletion of active IS-IS
			Security Associations by the privileged operator SHOULD also be
			supported.
			It is desirable to use a key management protocol to
			distribute IS-IS Authentication Keys among communicating IS-IS
			implementations. Such a protocol would provide scalability and
			significantly reduce the human administrative burden. The Key ID can
			be used as a hook between IS-IS and such a future protocol. Key
			management protocols have a long history of subtle flaws that are
			often discovered long after the protocol was first described in
			public. To avoid having to change all IS-IS implementations should
			such a flaw be discovered, integrated key management protocol
			techniques were deliberately omitted from this specification.
			4.0. Key Management Procedures
			As with all security methods using keys, it is necessary to
			change the IS-IS Authentication Key on a regular basis. To maintain
			routing stability during such changes, implementations MUST be able
			to store and use at least two IS-IS Security Associations (hence:
			authentication keys) in any given system at the same time.
			Each IS-IS Security Association has its own Key Identifier,
			which is stored locally. The Key Identifier uniquely identifies the
			IS-IS Security Association in use.
			The intermediate system creating the IS-IS message will
			select a valid key from the set of valid keys for that interface.
			The receiver will use the Key Identifier to determine which IS-IS
			Security Association to use for authentication of the received
			message. The receiver MUST NOT ignore the Key Identifier and try all
			known keys on an incoming packet as this creates an easily prevented
			denial-of-service attack on the IS-IS implementation. More than one
			IS-IS Security Association (hence: more than one key) MAY be
			associated with an interface at the same time.
			Hence it is possible to have fairly smooth IS-IS
			Authentication Key rollovers without losing legitimate LSPs because
			the stored authentication key is incorrect and without requiring
			people to change all the keys at once. To ensure a smooth rollover,
			each communicating IS-IS system must be updated with the new key
			several minutes before the current key will expire and several
			minutes before the new key lifetime begins. The new key should have a
			lifetime that starts several minutes before the old key expires. This
			gives time for each system to learn of the new IS-IS Authentication
			Key before that key will be used. It also ensures that the new key
			will begin being used and the current key will go out of use before
			the current key's lifetime expires. For the duration of the overlap
			in key lifetimes, a system may receive messages using either key and
			authenticate the message as indicated by the Key ID.
			4.3. Pathological Cases
			Two pathological cases exist which must be handled, which are
			failures of the network manager. Both of these should be exceedingly
			rare.
			During key rollover, devices may exist which have not yet been
			successfully configured with the new key. Therefore, routers SHOULD
			implement (and would be well advised to implement) an algorithm that
			detects the set of keys being used by its neighbors, and transmits
			its messages using both the new and old keys until all of the
			neighbors are using the new key or the lifetime of the old key
			expires. Under normal circumstances, this elevated transmission rate
			will exist for a single update interval.
			In the event that the last key associated with a system, it is
			unacceptable to revert to an unauthenticated condition, and not
			advisable to disrupt routing. Therefore, the router should send a
			"last authentication key expiration" notification to the network
			manager and treat the key as having an infinite lifetime until the
			lifetime is extended, the key is deleted by network management, or a
			new key is configured.
			5. Conformance Requirements
			To conform to this specification, an implementation MUST support
			all of its aspects. The HMAC-MD5 authentication algorithm MUST be
			implemented by all conforming implementations. MD5 is defined in
			RFC-1321. A conforming implementation MAY also support other
			authentication algorithms such as Keyed Secure Hash Algorithm (SHA).
			Manual key distribution as described above MUST be supported
			by all conforming implementations. All conforming implementations
			MUST support the smooth key rollover described under "Key Change
			Procedures."
			6. Acknowledgments
			This work is derived directly from RFC-2082 and the similar work
			done for OSPFv2 Cryptographic Authentication.
			7. References
			[1] ISO-10589
			[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
			1992.
			[3] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
			ACM Computer Communications Review, Volume 19, Number 2,
			pp.32-48, April 1989.
			[4] Haller, N., and R. Atkinson, "Internet Authentication
			Guidelines", RFC 1704, October 1994.
			[5] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
			of IAB Workshop on Security in the Internet Architecture",
			RFC 1636, June 1994.
			[6] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
			[7] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC-2119, March 1997.
			8. Security Considerations
			This entire memo describes and specifies an authentication
			mechanism for the IS-IS routing protocol that is believed to be
			reasonably secure against active and passive attacks. Passive attacks
			are clearly widespread in the Internet at present. Protection
			against active attacks is also needed because active attacks are
			becoming more common.
			Users need to understand that the quality of the security provided
			by this mechanism depends completely on the strength of the
			implemented authentication algorithms, the strength of the key being
			used, and the correct implementation of the security mechanism in all
			communicating IS-IS implementations. This mechanism also depends on
			the IS-IS Cryptographic Authentication Key being kept confidential by
			all parties. If any of these incorrect or insufficiently secure,
			then no real security will be provided to the users of this
			mechanism.
			Specifically with respect to the use of SNMP, compromise of SNMP
			security has the necessary result that the various IS-IS
			configuration parameters (e.g. routing table, IS-IS Authentication
			Key) manageable via SNMP could be compromised as well. Changing
			Authentication Keys using non-encrypted SNMP is no more secure than
			sending passwords in the clear.
			Confidentiality is not provided by this mechanism. Protection
			against traffic analysis is also not provided. Mechanisms such as
			bulk link encryption might be used when protection against traffic
			analysis is required. Finally, this technique does not prevent
			replay attacks. Appropriate use of key management can reduce the
			residual risk associated with replay attacks if desired by the
			operator.
			10. Authors' Addresses
	Tony Li		Tony Li
	Juniper Networks, Inc.		Procket Networks
	385 Ravendale Dr.		San Jose, CA
	Mountain View, CA 94043
	Email: tli@juniper.net		Email: tli@procket.com
	Fax: +1 650 526 8001
	Voice: +1 650 526 8006		Randall Atkinson
			Engineer at large
End of changes. 35 change blocks.
	106 lines changed or deleted		369 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/