< draft-ietf-karp-crypto-key-table-09.txt		draft-ietf-karp-crypto-key-table-10.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 2014 22 October 2013		Expires: 4 June 2014 4 December 2013
	Database of Long-Lived Symmetric Cryptographic Keys		Database of Long-Lived Symmetric Cryptographic Keys
	<draft-ietf-karp-crypto-key-table-09.txt>		<draft-ietf-karp-crypto-key-table-10.txt>
			Abstract
			This document specifies the information contained in a conceptual
			database of long-lived cryptographic keys used by many different
			routing protocols for message security. The database is designed to
			support both manual and automated key management. In addition to
			describing the schema for the database, this document describes the
			operations that can be performed on the database as well as the
			requirements for the routing protocols that wish to use the database.
			In many typical scenarios, the protocols do not directly use the
			long-lived key, but rather a key derivation function is used to
			derive a short-lived key from a long-lived key.
	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 1, line 38 ¶		skipping to change at page 2, line 7 ¶
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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
	This document specifies the information contained in a conceptual
	database of long-lived cryptographic keys used by many different
	routing protocols for message security. The database is designed to
	support both manual and automated key management. In addition to
	describing the schema for the database, this document describes the
	operations that can be performed on the database as well as the
	requirements for the routing protocols that wish to use the database.
	In many typical scenarios, the protocols do not directly use the
	long-lived key, but rather a key derivation function is used to
	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 cryptographic authentication for routing protocols.		cryptographic authentication of routing protocols. This conceptual
	This conceptual database is designed to separate protocol-specific		database is designed to separate protocol-specific aspects from both
	aspects from both manual and automated key management. The intent is		manual and automated key management. The intent is to allow many
	to allow many different implementation approaches to the specified		different implementation approaches to the specified cryptographic
	cryptographic key database, while simplifying specification and		key 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. This satisfies the
	these interfaces. It is an operational requirement that all		operational requirement that all implementations represent the keys
	implementations represent the keys and key identifiers in the same		and key identifiers in the same way so that cross-vendor
	way so that cross-vendor configuration instructions can be provided.		configuration instructions can be provided.
	Routing protocols can employ the services of more generic security		Routing protocols can employ the services of more generic security
	protocols such as TCP-AO [RFC5925]. Implementations of routing		protocols such as TCP-AO [RFC5925]. Implementations of routing
	protocols may need to supply keys to databases specific to these		protocols may need to supply keys to databases specific to these
	security protocols as the associated entries in this document's		security protocols as the associated entries in this document's
	conceptual database are manipulated.		conceptual database are manipulated.
	In many instances, the long-lived keys are not used directly in		In many instances, the long-lived keys are not used directly in
	security protocols, but rather a key derivation function is used to		security protocols, but rather a key derivation function is used to
	derive short-lived key from the long-lived keys in the database. In		derive short-lived keys from the long-lived key in the database. In
	other instances, security protocols will directly use the long-lived		other instances, security protocols will directly use the long-lived
	key from the database. The database design supports both use cases.		key from the database. The database design supports both use cases.
	1.1. Requirements Notation		1.1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Conceptual Database Structure		2. Conceptual Database Structure
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	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 key by		The AdminKeyName field contains a human-readable string meant
	humans. The same string can be used on the local system and		to identify the key for the user. Implementations can use this
	peer systems, but this is not required. Protocols do not make		field to uniquely identify rows in the key table. The same
	use of this string; protocols use the LocalKeyName and the		string can be used on the local system and peer systems, but
	PeerKeyName. Implementations can use this field to uniquely		this is not required. Routing protocols do not make use of this
	identify rows in the key table.		string; they use the LocalKeyName and the PeerKeyName. However,
			if these strings are to be used as protocol elements in other
			protocols or otherwise transferred between systems, they will
			need to follow the requirements of section 5.1.
	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 routing
	Protocols with key names requiring internationalization, those		Protocols with key names requiring internationalization, those
	specifications need to address issues of canonicalization and		specifications need to address issues of canonicalization and
	normalization so that key names can be compared using binary		normalization so that key names can be compared using binary
	comparison.		comparison.
	PeerKeyName		PeerKeyName
	For unicast communication, the PeerKeyName of a key on a system		PeerKeyName is the name of the key used by the local system in
	matches the LocalKeyName of the identical key that is		an outgoing message. For unicast communication, the PeerKeyName
	maintained on one or multiple peer systems. Similar to		of a key on a system matches the LocalKeyName of the identical
	LocalKeyName, a protocol defines the form of this identifier		key that is maintained on one or multiple peer systems. Similar
			to LocalKeyName, a protocol defines the form of this identifier
	and will often restrict it to be an integer. For group keys,		and will often restrict it to be an integer. For group keys,
	the protocol will typically require this field be an empty		the protocol will typically require this field be an empty
	string as the sending and the receiving key names need to be		string as the sending and the receiving key names need to be
	the same.		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
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 43 ¶
	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
	keys based on interface is not required. As an example, TCP-AO		keys based on interface is not required. As an example, TCP-AO
	implementations are unlikely to make the decision of what		implementations are unlikely to make the decision of what
	interface to use prior to key selection. In this case, the		interface to use prior to key selection. In this case, the
	implementations are expected to use the same keying material		implementations are expected to use the same keying material
	across all of the interfaces and then require the "all"		across all of the interfaces and then require the "all"
	setting.		setting.
	Protocol		Protocol
	The Protocol field identifies a single security protocol where		The Protocol field identifies a single routing protocol where
	this key may be used to provide cryptographic protection. This		this key may be used to provide cryptographic protection. This
	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 that may
	may be useful for a protocol to apply the key correctly. Note		be useful for a protocol to apply the key correctly. Note that
	that such information must not be required for a protocol to		such information MUST NOT be required for a protocol to locate
	locate an appropriate key. When a protocol does not need the		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. Key table rows MAY specify a direction of "both".		be empty. Key table rows MAY specify a Direction of "both".
	As a result, the encoding of this field needs to support		As a result, the encoding of this field needs to support
	encoding protocol specific information for sending and		encoding protocol specific information for sending and
	receiving in the same row.		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
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 41 ¶
	used with the security protocol for the specified peer or		used with the security protocol for the specified peer or
	peers. Such an algorithm can be an encryption algorithm and		peers. Such an algorithm can be an encryption algorithm and
	mode (e.g., AES-128-CBC), an authentication algorithm (e.g.,		mode (e.g., AES-128-CBC), an authentication algorithm (e.g.,
	HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric		HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric
	cryptographic algorithm needed by a security protocol. If the		cryptographic algorithm needed by a security protocol. If the
	KDF field contains "none", then the long-lived key is used		KDF field contains "none", then the long-lived key is used
	directly with this algorithm, otherwise the derived short-lived		directly with this algorithm, otherwise the derived short-lived
	key is used with this algorithm. When the long-lived key is		key is used with this algorithm. When the long-lived key is
	used to generate a set of short-lived keys for use with the		used to generate a set of short-lived keys for use with the
	security protocol, the AlgID field identifies a ciphersuite		security protocol, the AlgID field identifies a ciphersuite
	rather than a single cryptographic algorithm. This document		rather than a single cryptographic algorithm. This document
	establishes an IANA registry for the values in the AlgID field		establishes an IANA registry for the values in the AlgID field
	to simplify references in future specifications. Protocols		to simplify references in future specifications. Protocols
	indicate which 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
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 9 ¶
	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 by the protocol, the Interfaces
	field in the key table row includes I or "all";		field in the key table row includes I 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
	available. To meet this requirement, this specification recommends		available. To meet this requirement, this specification recommends
	supplementing the key selection algorithm with the following		supplementing the key selection algorithm with the following
	differentiation: select the long-lived key specifying the most recent		differentiation: select the long-lived key specifying the most recent
	time in the SendLifetimeStart field.		time in the SendLifetimeStart field.
	In order to look up a key for verifying an incoming message, the		In order to look up a key for validating an incoming message, 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";
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 26 ¶
	interfaces field to refer to all instances of a protocol on a link		interfaces field to refer to all instances of a protocol on a link
	without having to specify both generic interfaces information and		without having to specify both generic interfaces information and
	protocol-specific peer information.		protocol-specific peer information.
	5. Textual Conventions		5. Textual Conventions
	5.1 Key Names		5.1 Key Names
	When a key for a given protocol is identified by an integer key		When a key for a given protocol is identified by an integer key
	identifier, the associated key name will be represented as lower case		identifier, the associated key name will be represented as lower case
	hexadecimal integers with the most significant octet first. This		hexadecimal digits with the most significant octet first. This
	integer is padded with leading 0's until the width of the key		integer is padded with leading zero digits until the width of the key
	identifier field in the protocol is reached.		identifier field in the protocol is reached. If a key name contains
			non-integer human-readable text, its format and encoding may be an
			issue, particularly if it is used in protocol between two different
			types of systems. If characters from the ASCII range [RFC20] are
			sufficient for a key name, then they SHOULD be used. If characters
			outside of that range are desirable or required, then they MUST be in
			an encoding of Unicode [UNICODE].
			In the case of an AdminKeyName that uses characters outside of the
			ASCII range, the AdminKeyName MUST be encoded using UTF-8 [RFC3629]
			and SHOULD be normalized using Unicode Normalization Form KC [UAX15]
			to maximize the chance that the strings will compare correctly.
			However, simply using Unicode Normalization Form KC is not sufficient
			to account for all issues of string comparison; refer to [draft-ietf-
			precis-framework] for additional information.
	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
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 23 ¶
	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);
	- Protocol Specific Info; and		- Protocol Specific Info; and
	- Specification.		- 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.
	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 how the protocol is used with the key table.		defining how the protocol is used with the key table.
	There are no initial registrations.		There are no initial registrations.
	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		"KeyTable KDFs".
	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 N/A
	802.1X-01 IEEE 802.1X Table 9.1 [IEEE802.1X-2010]		AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]
			HMAC-SHA-1 HMAC using the SHA-1 hash [RFC 2104]
	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".
	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
	characters representing the name of an AlgID. The second column is a		UTF-8 characters representing the algorithm identifier (AlgID). The
	string of UTF-8 characters providing a brief description of the		second column is a string of UTF-8 characters providing a brief
	AlgID. The third column is a reference to a specification defining		description of the identified algorithm. The third column is a
	the AlgID, if available.		reference to a specification defining the identified algorithm.
	AlgID Description Reference		AlgID Description Reference
	----- ----------- ---------		------------ --------------------------------- ---------
	AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]		AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]
			AES-128-CMAC-96 AES-128-CMAc truncated to 96-bits [RFC5926]
			HMAC-SHA-1-96 HMAC SHA-1 truncated to 96-bits [RFC2104]
	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, 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. Normative References		10. References
			10.1. Normative References
			[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
			October 1969.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	11. Informational References		[UAX15] The Unicode Consortium, "Unicode Standard Annex #15:
			Unicode Normalization Forms", August 2012,
			<http://unicode.org/reports/tr15/>.
	[IEEE802.1X-2010] IEEE Standard for Local and Metropolitan Area Networks --		[UNICODE] The Unicode Consortium, "The Unicode Standard", 2013,
			<http://www.unicode.org/versions/latest/>.
			10.2. Informational References
			[draft-ietf-precis-framework]
			Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
			Preparation and Comparison of Internationalized Strings
			in Application Protocols", work-in-progress,
			November 21, 2013.
			[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.
	[RFC4493] Song, J., Lee, J., Poovendran, R., and T. Iwata, "The AES-CMAC		[RFC4493] Song, J., Lee, J., Poovendran, R., and T. Iwata, "The AES-CMAC
	Algorithm", RFC 4493, June 2006.		Algorithm", RFC 4493, June 2006.
End of changes. 30 change blocks.
	79 lines changed or deleted		119 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/