< draft-ietf-karp-crypto-key-table-03.txt		draft-ietf-karp-crypto-key-table-04.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: 29 December 2012 29 June 2012		Expires: 22 April 2013 22 October 2012
	Database of Long-Lived Symmetric Cryptographic Keys		Database of Long-Lived Symmetric Cryptographic Keys
	<draft-ietf-karp-crypto-key-table-03.txt>		<draft-ietf-karp-crypto-key-table-04.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 4 ¶
	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
	single long-lived symmetric cryptographic key. Normally, each key		represents a
	should only have one row. Only in the (hopefully) very rare cases		single long-lived symmetric cryptographic key. Normally, each key
	where a key is used for more than one purpose, multiple rows will		should only have one row. Only in the (hopefully) very rare cases
	contain the same key value. The columns in the table represent the		where a key is used for more than one purpose, or where the same
	key value and attributes of the key.		key
			is used with multiple key derivation functions (KDFs) will
			multiple
			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.
	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		LocalKeyName is a string identifying the key when it is
	received in a packet. A protocol may restrict the form of a		received in a packet. A protocol may restrict the form of a
	key name. For example, many routing protocols will restrict key		key name. For example, many routing protocols will restrict key
	names to integers that can be represented in 16 or 32 bits.		names to integers that can be represented in 16 or 32 bits.
	PeerKeyName		PeerKeyName
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	considered for use when sending traffic. The format is		considered for use when sending traffic. The format is
	YYYYMMDDHHSSZ, where four digits specify the year, two digits		YYYYMMDDHHSSZ, where four digits specify the year, two digits
	specify the month, two digits specify the day, two digits		specify the month, two digits specify the day, two digits
	specify the hour, two digits specify the minute, and two		specify the hour, two digits specify the minute, and two
	digits specify the second. The "Z" is included as a clear		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		SendNotAfter
	The SendNotAfter field specifies the latest date and time at		The SendNotAfter 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 NotBefore field.		traffic. The format is the same as the SendNotBefore field.
	RcvNotBefore		RcvNotBefore
	The RcvNotBefore field specifies the earliest date and time in		The RcvNotBefore field specifies the earliest date and time in
	Universal Coordinated Time (UTC) at which this key should be		Universal Coordinated Time (UTC) at which this key should be
	considered for use when processing received traffic. The		considered for use when processing received traffic. The
	format is YYYYMMDDHHSSZ, where four digits specify the year,		format is YYYYMMDDHHSSZ, where four digits specify the year,
	two digits specify the month, two digits specify the day, two		two digits specify the month, two digits specify the day, two
	digits specify the hour, two digits specify the minute, and two		digits specify the hour, two digits specify the minute, and two
	digits specify the second. The "Z" is included as a clear		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.
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	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 Peer 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) SendNotBefore <= current time <= SendNotAfter.
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 42 ¶
	exist associated with different cryptographic algorithms or		exist associated with different cryptographic algorithms or
	ciphersuites. Systems should support selection of keys based on		ciphersuites. Systems should support selection of keys based on
	algorithm preference.		algorithm preference.
	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 employed to provide orderly key rollover. In these
	cases, the expectation is that systems will transition to the newest		cases, the expectation is that systems will transition to the newest
	key available. To meet this requirement, this specification		key available. To meet this requirement, this specification
	recommends supplementing the key selection algorithm with the		recommends supplementing the key selection algorithm with the
	following differentiation: select the long-lived key specifying the		following differentiation: select the long-lived key specifying the
	most recent time in the NotBefore field.		most recent time in the SendNotBefore 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) RcvNotBefore <= current time <= RcvNotAfter.
	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 NotBefore and NotAfter fields. New security associations should		the RcvNotBefore and RcvNotAfter fields. New security associations
	not be established except within the period of use specified by these		should not be established except within the period of use specified
	fields, while allowing some grace time for clock skew. However, if a		by these fields, while allowing some grace time for clock skew.
	security association has already been established based on a		However, if a security association has already been established based
	particular long-lived key, exceeding the lifetime does not have any		on a particular long-lived key, exceeding the lifetime does not have
	direct impact. The implementations of security protocols that		any direct impact. The implementations of security protocols that
	involve long-lived security association should be designed to		involve long-lived security association should be designed to
	periodically interrogate the database and rollover to new keys		periodically interrogate the database and rollover to new keys
	without tearing down the security association.		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
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 39 ¶
	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 NotAfter field of the preceding key to		operators should configure the SendNotBefore field of the key to be
	be several days after the NotBefore field of the subsequent key to		several days after the RcvNotBefore field of the key to address the
	address the clock skew issue.		clock skew issue and guarantee there is some overlap.
	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.
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 33 ¶
	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		This document requests establishment of a registry called "KeyTable
	Protocols". The following subsection describes the registry; the		Protocols". The following subsection describes the registry; the
	second subsection provides initial values for IEEE 802.1X.		second subsection provides initial values for IEEE 802.1X CAK.
	8.1.1. KeyTable Protocols Registry Definition		8.1.1. KeyTable Protocols Registry Definition
	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
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 21 ¶
	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. For existing
	protocols, this typically means that the specification will focus		protocols, this typically means that the specification will focus
	more on the application of the protocol with the key tables rather		more on the application of the protocol with the key tables rather
	than being a general specification of the security protocol. New		than being a general specification of the security protocol. New
	protocols may of course combine information on how to use the key		protocols may of course combine information on how to use the key
	tables database with the protocol specification.		tables database with the protocol specification.
	8.1.2. KeyTable Protocols Registry Initial Values		8.1.2. KeyTable Protocols Registry Initial Values
	Protocol Name: IEEE 802.1X		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:
	- A Key Management Domain (KMD).		- A Key Management Domain (KMD).
	A string of up to 253 UTF-8 characters that names the		A string of up to 253 UTF-8 characters that names the
	transmitting authenticator's key management domain.		transmitting authenticator's key management domain.
End of changes. 11 change blocks.
	23 lines changed or deleted		28 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/