< draft-ietf-karp-crypto-key-table-04.txt		draft-ietf-karp-crypto-key-table-05.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: 22 April 2013 22 October 2012		Expires: 14 August 2013 14 February 2013
	Database of Long-Lived Symmetric Cryptographic Keys		Database of Long-Lived Symmetric Cryptographic Keys
	<draft-ietf-karp-crypto-key-table-04.txt>		<draft-ietf-karp-crypto-key-table-05.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 3, line 4 ¶		skipping to change at page 3, line 6 ¶
	connection state. Implementations may need to supply keys to the		connection state. Implementations may need to supply keys to the
	protocol-specific databases as the associated entries in the		protocol-specific databases as the associated entries in the
	conceptual database are manipulated. In many instances, the long-		conceptual database are manipulated. In many instances, the long-
	lived keys are not used directly in security protocols, but rather a		lived keys are not used directly in security protocols, but rather a
	key derivation function is used to derive short-lived key from the		key derivation function is used to derive short-lived key from the
	long-lived keys in the database. In other instances, security		long-lived keys in the database. In other instances, security
	protocols will directly use the long-lived key from the database.		protocols will directly use the long-lived key from the database.
	The database design supports both use cases.		The database design supports both use cases.
	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		where a key is used for more than one purpose, or where the same key
	key		is used with multiple key derivation functions (KDFs) will multiple
	is used with multiple key derivation functions (KDFs) will		rows will contain the same key value. The columns in the table
	multiple		represent the key value and attributes of the key.
	rows will contain the same key value. The columns in the table
	represent 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:
	LocalKeyName		LocalKeyName
	LocalKeyName is a string identifying the key when it is		The LocalKeyName field contains a string identifying the key.
	received in a packet. A protocol may restrict the form of a		It can be used to retrieve the key in the local database when
	key name. For example, many routing protocols will restrict key		received in a packet. A protocol may restrict the form of this
	names to integers that can be represented in 16 or 32 bits.		field. For example, many routing protocols restrict the format
			of their key names to integers that can be represented in 16 or
			32 bits.
	PeerKeyName		PeerKeyName
	For unicast communication, PeerKeyName on one system matches		For unicast communication, the PeerKeyName of a key on a system
	LocalKeyName on the other system. Similar to LocalKeyName, the		matches the LocalKeyName of the identical key that is
	protocol may restrict the form of this identifier and will		maintained on one or multiple peer systems. Similar to
	often restrict it to be an integer. For group keys, the		LocalKeyName, a protocol may restrict the form of this
	protocol will typically require this field be an empty string		identifier and will often restrict it to be an integer. For
	as the sending and the receiving key names need to be the same.		group keys, the protocol will typically require this field be
			an empty string as the sending and the receiving key names need
			to be the same.
	Peers		Peers
	Typically for unicast keys, this field lists the peer systems		Typically for unicast keys, this field lists the peer systems
	that have this key in their database. For group keys this field		that have this key in their database. For group keys this field
	names the groups for which the key is appropriate. For example,		names the groups for which the key is appropriate. For example,
	this might name a routing area for a multicast routing		this might name a routing area for a multicast routing
	protocol. Formally, this field provides a protocol-specific set		protocol. Formally, this field provides a protocol-specific set
	of restrictions on the scope in which the key is appropriate.		of restrictions on the scope in which the key is appropriate.
	The form of the identifiers in the Peers field is specified by		The format of the identifiers in the Peers field is specified
	the protocol.		by the protocol.
	Interfaces		Interfaces
	The Interfaces field identifies the set of physical and/or		The Interfaces field identifies the set of physical and/or
	virtual interfaces for which it is appropriate to use this key.		virtual interfaces for which it is appropriate to use this key.
	When the long-lived value in the Key field is intended for use		When the long-lived value in the Key field is intended for use
	on any interface, this field is set to "all". The interfaces		on any interface, this field is set to "all". The interfaces
	field consists of a set of strings; the form of these strings		field consists of a set of strings; the form of these strings
	is specified by the implementation and is independent of the		is specified by the implementation and is independent of the
	protocol in question. Protocols may require support for the		protocol in question. Protocols may require support for the
	interfaces field or may indicate that support for constraining		interfaces field or may indicate that support for constraining
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	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.
	KDF		KDF
	The KDF field indicates which key derivation function is used		The KDF field indicates the key derivation function which is
	to generate short-lived keys from the long-lived value in the		used to generate short-lived keys from the long-lived value in
	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". This		intended for direct use, the KDF field is set to "none". This
	document establishes an IANA registry for the values in the KDF		document establishes an IANA registry for the values in the KDF
	field to simplify references in future specifications. The		field to simplify references in future specifications. The
	protocol indicates what (if any) KDFs are valid.		protocol indicates what (if any) KDFs are valid.
	AlgID		AlgID
	The AlgID field indicates the cryptographic algorithm used with		The AlgID field indicates which cryptographic algorithm to be
	the security protocol for the specified peer. The algorithm		used with the security protocol for the specified peer or
	may be an encryption algorithm and mode (such as AES-128-CBC),		peers. Such an algorithm can be an encryption algorithm and
	an authentication algorithm (such as HMAC-SHA1-96 or		mode (e.g., AES-128-CBC), an authentication algorithm (e.g.,
	AES-128-CMAC), or any other symmetric cryptographic algorithm		HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric
	needed by a security protocol. If the KDF field contains		cryptographic algorithm needed by a security protocol. If the
	"none", then the long-lived key is used directly with this		KDF field contains "none", then the long-lived key is used
	algorithm, otherwise the derived short-lived key is used with		directly with this algorithm, otherwise the derived short-lived
	this algorithm. When the long-lived key is used to generate a		key is used with this algorithm. When the long-lived key is
	set of short-lived keys for use with the security protocol, the		used to generate a set of short-lived keys for use with the
	AlgID field identifies a ciphersuite rather than a single		security protocol, the AlgID field identifies a ciphersuite
	cryptographic algorithm. This document establishes an IANA		rather than a single cryptographic algorithm. This document
	registry for the values in the AlgID field to simplify		establishes an IANA registry for the values in the AlgID field
	references in future specifications. Protocols indicate which		to simplify references in future specifications. Protocols
	algorithms are appropriate.		indicate which algorithms are appropriate.
	Key		Key
	The Key field contains a long-lived symmetric cryptographic key		The Key field contains a long-lived symmetric cryptographic key
	in the format of a lower-case hexadecimal string. The size of		in the format of a lower-case hexadecimal string. The size of
	the Key depends on the KDF and the AlgID. For instance, a		the Key depends on the KDF and the AlgID. For instance, a
	KDF=none and AlgID=AES128 requires a 128-bit key, which is		KDF=none and AlgID=AES128 requires a 128-bit key, which is
	represented by 32 hexadecimal digits.		represented by 32 hexadecimal digits.
	Direction		Direction
	The Direction field indicates whether this key may be used for		The Direction field indicates whether this key may be used for
	inbound traffic, outbound traffic, both, or whether the key		inbound traffic, outbound traffic, both, or whether the key
	has been disabled and may not currently be used at all. The		has been disabled and may not currently be used at all. The
	supported values are "in", "out", "both", and "disabled",		supported values are "in", "out", "both", and "disabled",
	respectively. The Protocol field will determine which of these		respectively. The Protocol field will determine which of these
	values are valid.		values are valid.
	SendNotBefore		SendLifetimeStart
	The NotBefore field specifies the earliest date and time in		The SendLifetimeStart field specifies the earliest date and
	Universal Coordinated Time (UTC) at which this key should be		time in Coordinated Universal Time (UTC) at which this key
	considered for use when sending traffic. The format is		should be considered for use when sending traffic. The format
	YYYYMMDDHHSSZ, where four digits specify the year, two digits		is YYYYMMDDHHSSZ, where four digits specify the year, two
	specify the month, two digits specify the day, two digits		digits specify the month, two digits specify the day, two
	specify the hour, two digits specify the minute, and two		digits specify the hour, two digits specify the minute, and
	digits specify the second. The "Z" is included as a clear		two digits specify the second. The "Z" is included as a clear
	indication that the time is in UTC.		indication that the time is in UTC.
	SendNotAfter		SendLifeTimeEnd
	The SendNotAfter field specifies the latest date and time at		The SendLifeTimeEnd field specifies the latest date and time at
	which this key should be considered for use when sending		which this key should be considered for use when sending
	traffic. The format is the same as the SendNotBefore field.		traffic. The format is the same as the SendLifetimeStart
			field.
	RcvNotBefore		AcceptLifeTimeStart
	The RcvNotBefore field specifies the earliest date and time in		The AcceptLifeTimeStart field specifies the earliest date and
	Universal Coordinated Time (UTC) at which this key should be		time in Coordinated Universal Time (UTC) at which this key
	considered for use when processing received traffic. The		should be considered for use when processing received traffic.
	format is YYYYMMDDHHSSZ, where four digits specify the year,		The format is YYYYMMDDHHSSZ, where four digits specify the
	two digits specify the month, two digits specify the day, two		year, two digits specify the month, two digits specify the day,
	digits specify the hour, two digits specify the minute, and two		two digits specify the hour, two digits specify the minute, and
	digits specify the second. The "Z" is included as a clear		two digits specify the second. The "Z" is included as a clear
	indication that the time is in UTC.		indication that the time is in UTC.
	RcvNotAfter		AcceptLifeTimeEnd
	The RcvNotAfter field specifies the latest date and time at		The AcceptLifeTimeEnd field specifies the latest date and time
	which this key should be considered for use when processing		at which this key should be considered for use when processing
	received traffic. The format of this field is identical to the		the received traffic. The format of this field is identical to
	format of NotBefore.		the format of AcceptLifeTimeStart.
	3. Key Selection and Rollover		3. Key Selection and Rollover
	A protocol may directly consult the key table to find the key		A protocol may directly consult the key table to find the key
	to use on an outgoing packet. The protocol provides a protocol		to use on an outgoing packet. The protocol provides a protocol
	(P) and a peer identifier (H) into the key selection function.		(P) and a peer identifier (H) into the key selection function.
	Optionally, an interface identifier (I) may also need to be		Optionally, an interface identifier (I) may also need to be
	provided. Any key that satisfies the following conditions may		provided. Any key that satisfies the following conditions may
	be selected:		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, the Interfaces field includes I		(3) If an interface is specified, the Interfaces field 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) SendNotBefore <= current time <= SendNotAfter.		(5) SendLifetimeStart <= current time <= SendLifeTimeEnd.
	During algorithm transition, multiple entries may simultaneously		During key selection, multiple entries may simultaneously exist
	exist associated with different cryptographic algorithms or		associated with different cryptographic algorithms or ciphersuites.
	ciphersuites. Systems should support selection of keys based on		Systems should support selection of keys based on algorithm
	algorithm preference.		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 employed to provide orderly key rollover. In these		expected to be available for orderly key rollover. In these cases,
	cases, the expectation is that systems will transition to the newest		the expectation is that systems will transition to the newest key
	key available. To meet this requirement, this specification		available. To meet this requirement, this specification recommends
	recommends supplementing the key selection algorithm with the		supplementing the key selection algorithm with the following
	following differentiation: select the long-lived key specifying the		differentiation: select the long-lived key specifying the most recent
	most recent time in the SendNotBefore field.		time in the SendLifetimeStart field.
	In order to look up a key for verifying an incoming packet, the		In order to look up a key for verifying an incoming packet, the
	protocol provides its protocol (P), the peer identifier (H), the key		protocol provides its protocol (P), the peer identifier (H), the key
	identifier (L), and optionally the interface (I). If one key matches		identifier (L), and optionally the interface (I). If one key matches
	the following conditions it is selected:		the following conditions it is selected:
	(1) the Peer field includes H;		(1) the Peer field includes H;
	(2) the Protocol field matches P;		(2) the Protocol field matches P;
	(3) if the Interface field is provided, it includes I or is		(3) if the Interface field is provided, it includes I or is
	"all";		"all";
	(4) the Direction field is either "in" or "both";		(4) the Direction field is either "in" or "both";
	(5) the LocalKeyName is L; and		(5) the LocalKeyName is L; and
	(5) RcvNotBefore <= current time <= RcvNotAfter.		(5) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd.
	Note that the key usage is loosely bound by the times specified in		Note that the key usage is loosely bound by the times specified in
	the RcvNotBefore and RcvNotAfter fields. New security associations		the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security
	should not be established except within the period of use specified		associations should not be established except within the period of
	by these fields, while allowing some grace time for clock skew.		use specified by these fields, while allowing some grace time for
	However, if a security association has already been established based		clock skew. However, if a security association has already been
	on a particular long-lived key, exceeding the lifetime does not have		established based on a particular long-lived key, exceeding the
	any direct impact. The implementations of security protocols that		lifetime does not have any direct impact. The implementations of
	involve long-lived security association should be designed to		security protocols that involve long-lived security association
	periodically interrogate the database and rollover to new keys		should be designed to periodically interrogate the database and
	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.
	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
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 41 ¶
	5.2 Keys		5.2 Keys
	A key is represented as a lower-case hexadecimal string with the most		A key is represented as a lower-case hexadecimal string with the most
	significant octet of the key first. As discussed in Section 2, the		significant octet of the key first. As discussed in Section 2, the
	length of this string depends on the associated algorithm and KDF.		length of this string depends on the associated algorithm and KDF.
	6. Operational Considerations		6. Operational Considerations
	If the valid periods for long-lived keys do not overlap or the system		If the valid periods for long-lived keys do not overlap or the system
	clocks are inconsistent, it is possible to construct scenarios where		clocks are inconsistent, it is possible to construct scenarios where
	systems cannot agree upon a long-lived key. When installing a series		systems cannot agree upon a long-lived key. When installing a series
	of keys to be used one after another (sometimes called a key chain),		of keys to be used one after another (sometimes called a key chain),
	operators should configure the SendNotBefore field of the key to be		operators should configure the SendLifetimeStart field of the key to
	several days after the RcvNotBefore field of the key to address the		be several hours after the AcceptLifeTimeStart field of the key to
	clock skew issue and guarantee there is some overlap.		guarantee there is some overlap. This overlap is intended to address
			the clock skew issue and allow for basic operational considerations.
			Operators may choose to specify a longer overlap (e.g., several
			hours) to allow for exceptional circumstances.
	7. Security Considerations		7. Security Considerations
	Management of encryption and authentication keys has been a		Management of encryption and authentication keys has been a
	significant operational problem, both in terms of key synchronization		significant operational problem, both in terms of key synchronization
	and key selection. For instance, the current guidance [RFC3562]		and key selection. For instance, the current guidance [RFC3562]
	warns against sharing TCP MD5 keying material between systems, and		warns against sharing TCP MD5 keying material between systems, and
	recommends changing keys according to a schedule. The same general		recommends changing keys according to a schedule. The same general
	operational issues are relevant for the management of other		operational issues are relevant for the management of other
	cryptographic keys.		cryptographic keys.
	It has been recognized in [RFC4107] that automated key management is		It has been recognized in [RFC4107] that automated key management is
	not viable in multiple scenarios. The conceptual database specified		not viable in multiple scenarios. The conceptual database specified
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 12 ¶
	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		- Specification; and
	- Protocol Specific Values.		- Protocol Specific Values.
	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. For existing		conceptual database as outlined in Section 4. This typically means
	protocols, this typically means that the specification will focus		that the specification focuses more on the application of security
	more on the application of the protocol with the key tables rather		protocols with the key tables rather than being a new security
	than being a general specification of the security protocol. New		protocol specification for general purposes. New protocols may of
	protocols may of course combine information on how to use the key		course combine information on how to use the key tables database with
	tables database with the protocol specification.		the protocol specification.
	8.1.2. KeyTable Protocols Registry Initial Values		8.1.2. KeyTable Protocols Registry Initial Values
	Protocol Name: IEEE 802.1X CAK		Protocol Name: IEEE 802.1X CAK
	Specification: IEEE Std 802.1X-2010, "IEEE Standard for Local		Specification: IEEE Std 802.1X-2010, "IEEE Standard for Local
	and Metropolitan Area Networks -- Port-Based Network Access		and Metropolitan Area Networks -- Port-Based Network Access
	Control".		Control".
	Protocol Specific Values: there are two:		Protocol Specific Values: there are two:
	skipping to change at page 10, line 52 ¶		skipping to change at page 10, line 52 ¶
	registry.		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.
	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 KDFs 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.
	9. Acknowledgments		9. Acknowledgments
	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, Sam Hartman, Gregory Lebovitz, Sandy Murphy, Eric Rescorla,		Farrel, Gregory Lebovitz, Sandy Murphy, Eric Rescorla, Mike Shand,
	Mike Shand, Dave Ward, and Brian Weis for their insights.		Dave Ward, and Brian Weis for their insights.
	10. Informational References		10. Informational References
	[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.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
End of changes. 25 change blocks.
	101 lines changed or deleted		107 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/