< draft-ietf-karp-crypto-key-table-08.txt		draft-ietf-karp-crypto-key-table-09.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Internet Engineering Task Force (IETF) Vigil Security		Internet Engineering Task Force (IETF) Vigil Security
	Intended Status: Standards Track T. Polk		Intended Status: Standards Track T. Polk
	NIST		NIST
	S. Hartman		S. Hartman
	Painless Security		Painless Security
	D. Zhang		D. Zhang
	Huawei		Huawei
	Expires: 15 January 2014 15 July 2013		Expires: 22 April 2014 22 October 2013
	Database of Long-Lived Symmetric Cryptographic Keys		Database of Long-Lived Symmetric Cryptographic Keys
	<draft-ietf-karp-crypto-key-table-08.txt>		<draft-ietf-karp-crypto-key-table-09.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		Abstract
	This document specifies the information contained in a conceptual		This document specifies the information contained in a conceptual
	database of long-lived cryptographic keys used by many different		database of long-lived cryptographic keys used by many different
	security protocols. The database is designed to support both manual		routing protocols for message security. The database is designed to
	and automated key management. In addition to describing the schema		support both manual and automated key management. In addition to
	for the database, this document describes the operations that can be		describing the schema for the database, this document describes the
	performed on the database as well as the requirements for the		operations that can be performed on the database as well as the
	security protocols that wish to use the database. In many typical		requirements for the routing protocols that wish to use the database.
	scenarios, the security protocols do not directly use the long-lived		In many typical scenarios, the protocols do not directly use the
	key, but rather a key derivation function is used to derive a short-		long-lived key, but rather a key derivation function is used to
	lived key from a long-lived key.		derive a short-lived key from a long-lived key.
	1. Introduction		1. Introduction
	This document specifies the information that needs to be included in		This document specifies the information that needs to be included in
	a database of long-lived cryptographic keys in order to key the		a database of long-lived cryptographic keys in order to key the
	authentication of security protocols such as cryptographic		authentication of cryptographic authentication for routing protocols.
	authentication for routing protocols. This conceptual database is		This conceptual database is designed to separate protocol-specific
	designed to separate protocol-specific aspects from both manual and		aspects from both manual and automated key management. The intent is
	automated key management. The intent is to allow many different		to allow many different implementation approaches to the specified
	implementation approaches to the specified cryptographic key		cryptographic key database, while simplifying specification and
	database, while simplifying specification and heterogeneous		heterogeneous deployments. This conceptual database avoids the need
	deployments. This conceptual database avoids the need to build		to build knowledge of any security protocol into key management
	knowledge of any security protocol into key management protocols. It		protocols. It minimizes protocol-specific knowledge in
	minimizes protocol-specific knowledge in operational/management		operational/management interfaces, but it constrains where that
	interfaces, but it constrains where that knowledge can appear.		knowledge can appear. Textual conventions are provided for the
	Textual conventions are provided for the representation of keys and		representation of keys and other identifiers. These conventions
	other identifiers. These conventions should be used when presenting		should be used when presenting keys and identifiers to
	keys and identifiers to operational/management interfaces or reading		operational/management interfaces or reading keys/identifiers from
	keys/identifiers from these interfaces. It is an operational		these interfaces. It is an operational requirement that all
	requirement that all implementations represent the keys and key		implementations represent the keys and key identifiers in the same
	identifiers in the same way so that cross-vendor configuration		way so that cross-vendor configuration instructions can be provided.
	instructions can be provided.
	Security protocols such as TCP-AO [RFC5925] are expected to use per-		Routing protocols can employ the services of more generic security
	connection state. Implementations may need to supply keys to the		protocols such as TCP-AO [RFC5925]. Implementations of routing
	protocol-specific databases as the associated entries in the		protocols may need to supply keys to databases specific to these
	conceptual database are manipulated. In many instances, the long-		security protocols as the associated entries in this document's
	lived keys are not used directly in security protocols, but rather a		conceptual database are manipulated.
	key derivation function is used to derive short-lived key from the
	long-lived keys in the database. In other instances, security		In many instances, the long-lived keys are not used directly in
	protocols will directly use the long-lived key from the database.		security protocols, but rather a key derivation function is used to
	The database design supports both use cases.		derive short-lived key from the long-lived keys in the database. In
			other instances, security protocols will directly use the long-lived
			key from the database. The database design supports both use cases.
			1.1. Requirements Notation
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Conceptual Database Structure		2. Conceptual Database Structure
	The database is characterized as a table, where each row represents a		The database is characterized as a table, where each row represents a
	single long-lived symmetric cryptographic key. Normally, each key		single long-lived symmetric cryptographic key. Normally, each key
	should only have one row. Only in the (hopefully) very rare cases		should only have one row. Only in the (hopefully) very rare cases
	where a key is used for more than one purpose, or where the same key		where a key is used for more than one purpose, or where the same key
	is used with multiple key derivation functions (KDFs) will multiple		is used with multiple key derivation functions (KDFs) will multiple
	rows contain the same key value. The columns in the table represent		rows contain the same key value. The columns in the table represent
	the key value and attributes of the key.		the key value and attributes of the key.
	To accommodate manual key management, the format of the fields has		To accommodate manual key management, the format of the fields has
	been purposefully chosen to allow updates with a plain text editor		been purposefully chosen to allow updates with a plain text editor
	and to provide equivalent display on multiple systems.		and to provide equivalent display on multiple systems.
	The columns that the table consists of are listed as follows:		The columns that the table consists of are listed as follows:
	AdminKeyName		AdminKeyName
	The AdminKeyName field contains a string identifying		The AdminKeyName field contains a string identifying the key by
	the key		humans. The same string can be used on the local system and
	by humans. The same string can be used on the local		peer systems, but this is not required. Protocols do not make
	system		use of this string; protocols use the LocalKeyName and the
	and peer systems, but this is not required. Protocols		PeerKeyName. Implementations can use this field to uniquely
	do not		identify rows in the key table.
	make use of this string; protocols use the
	LocalKeyName and
	the PeerKeyName. Implementations can use this field to
	uniquely identify rows in the key table.
	LocalKeyName		LocalKeyName
	The LocalKeyName field contains a string identifying the key.		The LocalKeyName field contains a string identifying the key.
	It can be used to retrieve the key in the local database when		It can be used to retrieve the key in the local database when
	received in a message. As discussed in Section 4, the		received in a message. As discussed in Section 4, the
	protocol defines the form of this field. For example, many		protocol defines the form of this field. For example, many
	routing protocols restrict the format of their key names to		routing protocols restrict the format of their key names to
	integers that can be represented in 16 or 32 bits. Typically		integers that can be represented in 16 or 32 bits. Typically
	this field does not contain data in human character sets		this field does not contain data in human character sets
	requiring internationalization. If there ever are any		requiring internationalization. If there ever are any
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 6 ¶
	specification establishes a registry for this field; the		specification establishes a registry for this field; the
	registry also specifies the format of the following field,		registry also specifies the format of the following field,
	ProtocolSpecificInfo, for each registered protocol.		ProtocolSpecificInfo, for each registered protocol.
	ProtocolSpecificInfo		ProtocolSpecificInfo
	This field contains the protocol-specified information which		This field contains the protocol-specified information which
	may be useful for a protocol to apply the key correctly. Note		may be useful for a protocol to apply the key correctly. Note
	that such information must not be required for a protocol to		that such information must not be required for a protocol to
	locate an appropriate key. When a protocol does not need the		locate an appropriate key. When a protocol does not need the
	information in ProtocolSpecificInfo, it will require this field		information in ProtocolSpecificInfo, it will require this field
	be empty.		be empty. Key table rows MAY specify a direction of "both".
			As a result, the encoding of this field needs to support
			encoding protocol specific information for sending and
			receiving in the same row.
	KDF		KDF
	The KDF field indicates the key derivation function which is		The KDF field indicates the key derivation function which is
	used to generate short-lived keys from the long-lived value in		used to generate short-lived keys from the long-lived value in
	the Key field. When the long-lived value in the Key field is		the Key field. When the long-lived value in the Key field is
	intended for direct use, the KDF field is set to "none". A key		intended for direct use, the KDF field is set to "none". A key
	derivation function is a one-way function that provides		derivation function is a one-way function that provides
	cryptographic separation of key material. The KDF MAY use		cryptographic separation of key material. The KDF MAY use
	inputs from the row in the key table and the message being sent		inputs from the row in the key table and the message being sent
	or received but MUST NOT depend on other configuration state.		or received but MUST NOT depend on other configuration state.
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 4 ¶
	A protocol may directly consult the key table to find the key to use		A protocol may directly consult the key table to find the key to use
	on an outgoing message. The protocol provides a protocol (P) and a		on an outgoing message. The protocol provides a protocol (P) and a
	peer identifier (H) into the key selection function. Optionally, an		peer identifier (H) into the key selection function. Optionally, an
	interface identifier (I) may also need to be provided. Any key that		interface identifier (I) may also need to be provided. Any key that
	satisfies the following conditions may be selected:		satisfies the following conditions may be selected:
	(1) the Peers field includes H;		(1) the Peers field includes H;
	(2) the Protocol field matches P;		(2) the Protocol field matches P;
			(3) If an interface is specified by the protocol, the Interfaces
	(3) If an interface is specified, the Interfaces field includes I		field in the key table row includes I or "all";
	or "all";
	(4) the Direction field is either "out" or "both"; and		(4) the Direction field is either "out" or "both"; and
	(5) SendLifetimeStart <= current time <= SendLifeTimeEnd.		(5) SendLifetimeStart <= current time <= SendLifeTimeEnd.
	During key selection, multiple entries may simultaneously exist		During key selection, multiple entries may simultaneously exist
	associated with different cryptographic algorithms or ciphersuites.		associated with different cryptographic algorithms or ciphersuites.
	Systems should support selection of keys based on algorithm		Systems should support selection of keys based on algorithm
	preference to facilitate algorithm transition.		preference to facilitate algorithm transition.
	In addition, multiple entries with overlapping valid periods are		In addition, multiple entries with overlapping valid periods are
	expected to be available for orderly key rollover. In these cases,		expected to be available for orderly key rollover. In these cases,
	the expectation is that systems will transition to the newest key		the expectation is that systems will transition to the newest key
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	clock skew. However, if a security association has already been		clock skew. However, if a security association has already been
	established based on a particular long-lived key, exceeding the		established based on a particular long-lived key, exceeding the
	lifetime does not have any direct impact. The implementations of		lifetime does not have any direct impact. The implementations of
	security protocols that involve long-lived security association		security protocols that involve long-lived security association
	should be designed to periodically interrogate the database and		should be designed to periodically interrogate the database and
	rollover to new keys without tearing down the security association.		rollover to new keys without tearing down the security association.
	Rather than consulting the conceptual database, a security protocol		Rather than consulting the conceptual database, a security protocol
	such as TCP-AO may update its own tables as keys are added and		such as TCP-AO may update its own tables as keys are added and
	removed. In this case, the protocol needs to maintain its own key		removed. In this case, the protocol needs to maintain its own key
	information.		information. Some routing protocols use IP Security (IPsec) to
			provide integrity. If a specification describes how to use the
			conceptual database described in this document to configure keys for
			these routing protocols, similar concerns apply. The specification
			mapping those routing protocols onto this conceptual database needs
			to describe how the Security Policy Database is manipulated as rows
			are added and removed from the conceptual database.
	4. Application of the Database in a Security Protocol		4. Application of the Database in a Security Protocol
	In order to use the key table database in a protocol specification, a		In order to use the key table database in a protocol specification, a
	protocol needs to specify certain information. This section		protocol needs to specify certain information. This section
	enumerates items that a protocol must specify.		enumerates items that a protocol must specify.
	(1) The ways of mapping the information in a key table row to the		(1) The ways of mapping the information in a key table row to the
	information needed to produce an outgoing message; specified		information needed to produce an outgoing message; specified
	either as an explanation of how to fill in authentication-related		either as an explanation of how to fill in authentication-related
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 10 ¶
	protocol can improve the interoperability by including negotiation		protocol can improve the interoperability by including negotiation
	mechanisms for cryptographic algorithms. These valuable features		mechanisms for cryptographic algorithms. These valuable features
	are impossible or extremely cumbersome to accomplish with manual		are impossible or extremely cumbersome to accomplish with manual
	key management.		key management.
	8. IANA Considerations		8. IANA Considerations
	This specification defines three registries.		This specification defines three registries.
	8.1. KeyTable Protocols		8.1. KeyTable Protocols
	This document requests establishment of a registry called "KeyTable
	Protocols". The following subsection describes the registry; the
	second subsection provides initial values for IEEE 802.1X CAK.
	8.1.1. KeyTable Protocols Registry Definition		This document requests establishment of a registry called "KeyTable
			Protocols".
	All assignments to the KeyTable Protocols registry are made on a		All assignments to the KeyTable Protocols registry are made on a
	specification required basis per Section 4.1 of [RFC5226].		specification required basis per Section 4.1 of [RFC5226].
	Each registration entry must contain the three fields:		Each registration entry must contain the three fields:
	- Protocol Name (unique within the registry);		- Protocol Name (unique within the registry);
	- Specification; and		- Protocol Specific Info; and
	- Protocol Specific Info.		- Specification.
	The specification needs to describe parameters required for using the		The specification needs to describe parameters required for using the
	conceptual database as outlined in Section 4. This typically means		conceptual database as outlined in Section 4. This typically means
	that the specification focuses more on the application of security		that the specification focuses more on the application of security
	protocols with the key tables rather than being a new security		protocols with the key tables rather than being a new security
	protocol specification for general purposes. New protocols may of		protocol specification for general purposes. New protocols may of
	course combine information on how to use the key tables database with		course combine information on how to use the key tables database with
	the protocol specification.		the protocol specification.
	8.1.2. KeyTable Protocols Registry Initial Values
	The registry has three columns. The first column is a string of UTF-8		The registry has three columns. The first column is a string of UTF-8
	characters representing the name protocol. The second column is a		characters representing the name protocol. The second column is a
	string of UTF-8 characters providing a brief description of Protocol		string of UTF-8 characters providing a brief description of Protocol
	Specific Info. The third column is a reference to a specification		Specific Info. The third column is a reference to a specification
	defining the protocol.		defining how the protocol is used with the key table.
	Protocol Protocol Specific Info Reference		There are no initial registrations.
	-------- ---------------------- ---------
	IEEE 802.1X CAK KMD (A string of up to [IEEE802.1X-2010]
	253 UTF-8 characters
	that names the trans-
	mitting authentica-
	tor's key management
	domain, or null) and
	NID (A string of up to
	100 UTF-8 characters
	that identifies a net-
	work service or null,
	indicating the key is
	associated with a
	default service.)
	8.2. KeyTable KDFs		8.2. KeyTable KDFs
	This document requests the establishment of a registry called		This document requests the establishment of a registry called
	"KeyTable KDFs". The remainder of this section describes the reg-		"KeyTable KDFs". The remainder of this section describes the
	istry.		registry.
	All assignments to the KeyTable KDFs registry are made on a First		All assignments to the KeyTable KDFs registry are made on a First
	Come First Served basis per Section 4.1 of RFC 5226.		Come First Served basis per Section 4.1 of RFC 5226.
	The registry has three columns. The first column is a string of UTF-8		The registry has three columns. The first column is a string of UTF-8
	characters representing the name of a KDF. The second column is a		characters representing the name of a KDF. The second column is a
	string of UTF-8 characters providing a brief description of the KDF.		string of UTF-8 characters providing a brief description of the KDF.
	The third column is a reference to a specification defining the KDF,		The third column is a reference to a specification defining the KDF,
	if available.		if available.
	KDF Description Reference		KDF Description Reference
	--- ----------- ---------		--- ----------- ---------
	none No KDF is used with this key		none No KDF is used with this key
	802.1X-01 IEEE 802.1X Table 9.1 [IEEE802.1X-2010]		802.1X-01 IEEE 802.1X Table 9.1 [IEEE802.1X-2010]
	8.3. KeyTable AlgIDs		8.3. KeyTable AlgIDs
	This document requests establishment of a registry called "KeyTable		This document requests establishment of a registry called "KeyTable
	AlgIDs". The remainder of this section describes the registry.		AlgIDs". The remainder of this section describes the registry.
	All assignments to the KeyTable AlgIDs registry are made on a First		All assignments to the KeyTable AlgIDs registry are made on a First
	Come First Served basis per Section 4.1 of RFC 5226.		Come First Served basis per Section 4.1 of RFC 5226.
	The registry has three columns. The first column is a string of UTF-8		The registry has three columns. The first column is a string of UTF-8
	skipping to change at page 13, line 23 ¶		skipping to change at page 12, line 41 ¶
	This document reflects many discussions with many different people		This document reflects many discussions with many different people
	over many years. In particular, the authors thank Jari Arkko, Ran		over many years. In particular, the authors thank Jari Arkko, Ran
	Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian		Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian
	Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla,		Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla,
	Mike Shand, Dave Ward, and Brian Weis for their insights. The		Mike Shand, Dave Ward, and Brian Weis for their insights. The
	authors additionally thank Brian Weis for supplying text to address		authors additionally thank Brian Weis for supplying text to address
	IANA concerns and for help with formatting.		IANA concerns and for help with formatting.
	Sam Hartman's work on this draft is funded by Huawei.		Sam Hartman's work on this draft is funded by Huawei.
	10. Informational References		10. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			11. Informational References
	[IEEE802.1X-2010] IEEE Standard for Local and Metropolitan Area Networks --		[IEEE802.1X-2010] IEEE Standard for Local and Metropolitan Area Networks --
	Port-Based Network Access Control", February 2010.		Port-Based Network Access Control", February 2010.
	[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5		[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
	Signature Option", RFC 3562, July 2003.		Signature Option", RFC 3562, July 2003.
	[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic		[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
	Key Management", RFC 4107, BCP 107, June 2005.		Key Management", RFC 4107, BCP 107, June 2005.
End of changes. 19 change blocks.
	83 lines changed or deleted		82 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/