< draft-ietf-rtgwg-yang-key-chain-17.txt		draft-ietf-rtgwg-yang-key-chain-18.txt >
	Network Working Group A. Lindem, Ed.		Network Working Group A. Lindem, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track Y. Qu		Intended status: Standards Track Y. Qu
	Expires: September 28, 2017 Huawei		Expires: October 13, 2017 Huawei
	D. Yeung		D. Yeung
	Arrcus, Inc		Arrcus, Inc
	I. Chen		I. Chen
	Jabil		Jabil
	J. Zhang		J. Zhang
	Juniper Networks		Juniper Networks
	March 27, 2017		April 11, 2017
	Routing Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-17.txt		draft-ietf-rtgwg-yang-key-chain-18.txt
	Abstract		Abstract
	This document describes the key chain YANG data model. Key chains		This document describes the key chain YANG data model. Key chains
	are commonly used for routing protocol authentication and other		are commonly used for routing protocol authentication and other
	applications requiring symmetric keys. A key chain is a list of		applications requiring symmetric keys. A key chain is a list of
	elements each containing a key string, send lifetime, accept		elements each containing a key string, send lifetime, accept
	lifetime, and algorithm (authentication or encryption). By properly		lifetime, and algorithm (authentication or encryption). By properly
	overlapping the send and accept lifetimes of multiple key chain		overlapping the send and accept lifetimes of multiple key chain
	elements, key strings and algorithms may be gracefully updated. By		elements, key strings and algorithms may be gracefully updated. By
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 28, 2017.		This Internet-Draft will expire on October 13, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5		3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5
	3.1. Key Chain Operational State . . . . . . . . . . . . . . . 6		3.1. Key Chain Operational State . . . . . . . . . . . . . . . 6
	3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6		3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6
	3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 6		3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 6
	4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 9		4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 19		8.1. Normative References . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Simple Key Chain with Always Valid Single Key . . . . . . 20		A.1. Simple Key Chain with Always Valid Single Key . . . . . . 21
	A.2. Key Chain with Keys having Different Lifetimes . . . . . 21		A.2. Key Chain with Keys having Different Lifetimes . . . . . 22
	A.3. Key Chain with Independent Send and Accept Lifetimes . . 23		A.3. Key Chain with Independent Send and Accept Lifetimes . . 23
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	This document describes the key chain YANG [YANG] data model. Key		This document describes the key chain YANG [YANG] data model. Key
	chains are commonly used for routing protocol authentication and		chains are commonly used for routing protocol authentication and
	other applications requiring symmetric keys. A key chain is a list		other applications requiring symmetric keys. A key chain is a list
	of elements each containing a key string, send lifetime, accept		of elements each containing a key string, send lifetime, accept
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC-KEYWORDS].		[RFC-KEYWORDS].
	1.2. Tree Diagrams		1.2. Tree Diagrams
	A simplified graphical representation of the complete data tree is		A simplified graphical representation of the complete data tree is
	presented in Section 3.3. The following tree notation is used.		presented in Section 3.3. The following tree notation is used.
	o Brackets "[" and "]" enclose list keys.		o Brackets "[" and "]" enclose YANG list keys. These YANG list keys
			should not be confused with the key-chain keys.
	o Curly braces "{" and "}" contain names of optional features that		o Curly braces "{" and "}" contain names of optional features that
	make the corresponding node conditional.		make the corresponding node conditional.
	o Abbreviations before data node names: "rw" means configuration		o Abbreviations before data node names: "rw" means configuration
	(read-write), "ro" state data (read-only), "-x" RPC operations,		(read-write), "ro" state data (read-only), "-x" RPC operations,
	and "-n" notifications.		and "-n" notifications.
	o Symbols after data node names: "?" means an optional node, "!" a		o Symbols after data node names: "?" means an optional node, "!" a
	container with presence, and "*" denotes a "list" or "leaf-list".		container with presence, and "*" denotes a "list" or "leaf-list".
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 13 ¶
	network equipment vendors. Providing a standard YANG model will		network equipment vendors. Providing a standard YANG model will
	facilitate automated key distribution and non-disruptive key		facilitate automated key distribution and non-disruptive key
	rollover. This will aid in tightening the security of the core		rollover. This will aid in tightening the security of the core
	routing infrastructure as recommended in [IAB-REPORT].		routing infrastructure as recommended in [IAB-REPORT].
	A key chain is a list containing one or more elements containing a		A key chain is a list containing one or more elements containing a
	Key ID, key string, send/accept lifetimes, and the associated		Key ID, key string, send/accept lifetimes, and the associated
	authentication or encryption algorithm. A key chain can be used by		authentication or encryption algorithm. A key chain can be used by
	any service or application requiring authentication or encryption.		any service or application requiring authentication or encryption.
	In essence, the key-chain is a reusable key policy that can be		In essence, the key-chain is a reusable key policy that can be
	referenced whereever it is required. The key-chain construct has		referenced wherever it is required. The key-chain construct has been
	been implemented by most networking vendors and deployed in many		implemented by most networking vendors and deployed in many networks.
	networks.
	A conceptual representation of a crypto key table is described in		A conceptual representation of a crypto key table is described in
	[CRYPTO-KEYTABLE]. The crypto key table also includes keys as well		[CRYPTO-KEYTABLE]. The crypto key table also includes keys as well
	as their corresponding lifetimes and algorithms. Additionally, the		as their corresponding lifetimes and algorithms. Additionally, the
	key table includes key selection criteria and envisions a deployment		key table includes key selection criteria and envisions a deployment
	model where the details of the applications or services requiring		model where the details of the applications or services requiring
	authentication or encryption permeate into the key database. The		authentication or encryption permeate into the key database. The
	YANG key-chain model described herein doesn't include key selection		YANG key-chain model described herein doesn't include key selection
	criteria or support this deployment model. At the same time, it does		criteria or support this deployment model. At the same time, it does
	not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes		not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes
	augmentations to the key chain YANG model in support of key selection		augmentations to the key chain YANG model in support of key selection
	criteria.		criteria.
	2.1. Applicability		2.1. Applicability
	Other YANG modules may reference ietf-key-chain YANG module key-chain		Other YANG modules may reference ietf-key-chain YANG module key-chain
	names for authentication and encryption applications. A YANG type		names for authentication and encryption applications. A YANG type
	has been provided to facilate reference to the key-chain name without		has been provided to facilitate reference to the key-chain name
	having to specify the complete YANG XML Path Language (XPath)		without having to specify the complete YANG XML Path Language (XPath)
	selector.		selector.
	2.2. Graceful Key Rollover using Key Chains		2.2. Graceful Key Rollover using Key Chains
	Key chains may be used to gracefully update the key string and/or		Key chains may be used to gracefully update the key string and/or
	algorithm used by an application for authentication or encryption.		algorithm used by an application for authentication or encryption.
	This MAY be accomplished by accepting all the keys that have a valid		This MAY be accomplished by accepting all the keys that have a valid
	accept lifetime and sending the key with the most recent send		accept lifetime and sending the key with the most recent send
	lifetime. One scenario for facilitating key rollover is to:		lifetime. One scenario for facilitating key rollover is to:
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	the keys used for transmission.		the keys used for transmission.
	2. Assure that all the network devices have been updated with the		2. Assure that all the network devices have been updated with the
	updated key chain and that their system times are roughly		updated key chain and that their system times are roughly
	synchronized. The system times of devices within an		synchronized. The system times of devices within an
	administrative domain are commonly synchronized (e.g., using		administrative domain are commonly synchronized (e.g., using
	Network Time Protocol (NTP) [NTP-PROTO]). This also may be		Network Time Protocol (NTP) [NTP-PROTO]). This also may be
	automated.		automated.
	3. When the send lifetime of the new key becomes valid, the network		3. When the send lifetime of the new key becomes valid, the network
	devices within the domain of key chain will start sending the new		devices within the domain of key chain will using the new key for
	key.		transmissions.
	4. At some point in the future, a new key chain with the old key		4. At some point in the future, a new key chain with the old key
	removed may be distributed to the network devices within the		removed may be distributed to the network devices within the
	domain of the key chain. However, this may be deferred until the		domain of the key chain. However, this may be deferred until the
	next key rollover. If this is done, the key chain will always		next key rollover. If this is done, the key chain will always
	include two keys; either the current and future key (during key		include two keys; either the current and future key (during key
	rollovers) or the current and previous keys (between key		rollovers) or the current and previous keys (between key
	rollovers).		rollovers).
	3. Design of the Key Chain Model		3. Design of the Key Chain Model
	The ietf-key-chain module contains a list of one or more keys indexed		The ietf-key-chain module contains a list of one or more keys indexed
	by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the		by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the
	Key ID is used to identify the key chain key to be used. In addition		Key ID is used to identify the key chain key to be used. In addition
	to the Key ID, each key chain key includes a key-string and a		to the Key ID, each key chain key includes a key-string and a
	cryptographic algorithm. Optionally, the key chain keys include		cryptographic algorithm. Optionally, the key chain keys include
	send/accept lifetimes. If the send/accept lifetime is unspecified,		send/accept lifetimes. If the send/accept lifetime is unspecified,
	the key is always considered valid.		the key is always considered valid.
	Note that asymmetric keys, i.e., a different key value used for		Note that different key values for transmission versus acceptance may
	transmission versus acceptance, may be supported with multiple key		be supported with multiple key chain elements where the accept-
	chain elements where the accept-lifetime or send-lifetime is not		lifetime or send-lifetime is not valid (e.g., has an end-time equal
	valid (e.g., has an end-time equal to the start-time).		to the start-time).
	Due to the differences in key chain implementations across various		Due to the differences in key chain implementations across various
	vendors, some of the data elements are optional. Finally, the crypto		vendors, some of the data elements are optional. Finally, the crypto
	algorithm identities are provided for reuse when configuring legacy		algorithm identities are provided for reuse when configuring legacy
	authentication and encryption not using key-chains.		authentication and encryption not using key-chains.
	A key-chain is identified by a unique name within the scope of the		A key-chain is identified by a unique name within the scope of the
	network device. The "key-chain-ref" typedef SHOULD be used by other		network device. The "key-chain-ref" typedef SHOULD be used by other
	YANG modules when they need to reference a configured key-chain. The		YANG modules when they need to reference a configured key-chain. The
	"key-chain-state=ref" typedef SHOULD be used by other YANG modules		"key-chain-state=ref" typedef SHOULD be used by other YANG modules
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	minimize visibility similar to what was done with keys in SNMP MIBs.		minimize visibility similar to what was done with keys in SNMP MIBs.
	The timestamp of the last key-chain modification is also maintained		The timestamp of the last key-chain modification is also maintained
	in the operational state. Additionally, the operational state		in the operational state. Additionally, the operational state
	includes an indication of whether or not a key chain key is valid for		includes an indication of whether or not a key chain key is valid for
	sending or acceptance.		sending or acceptance.
	3.2. Key Chain Model Features		3.2. Key Chain Model Features
	Features are used to handle differences between vendor		Features are used to handle differences between vendor
	implementations. For example, not all vendors support configuration		implementations. For example, not all vendors support configuration
	an acceptance tolerance or configuration of key strings in		of an acceptance tolerance or configuration of key strings in
	hexadecimal. They are also used to support of security requirements		hexadecimal. They are also used to support of security requirements
	(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by		(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by
	vendors or only a single vendor.		vendors or only a single vendor.
	3.3. Key Chain Model Tree		3.3. Key Chain Model Tree
	+--rw key-chains		+--rw key-chains
	| +--rw key-chain* [name]		| +--rw key-chain* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw description? string		| | +--rw description? string
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 32 ¶
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--rw start-date-time? yang:date-and-time		| | | +--rw start-date-time? yang:date-and-time
	| | | +--rw (end-time)?		| | | +--rw (end-time)?
	| | | +--:(infinite)		| | | +--:(infinite)
	| | | | +--rw no-end-time? empty		| | | | +--rw no-end-time? empty
	| | | +--:(duration)		| | | +--:(duration)
	| | | | +--rw duration? uint32		| | | | +--rw duration? uint32
	| | | +--:(end-date-time)		| | | +--:(end-date-time)
	| | | +--rw end-date-time?		| | | +--rw end-date-time?
	| | | yang:date-and-time		| | | yang:date-and-time
	| | +--rw crypto-algorithm identityref		| | +--rw crypto-algorithm identityref
	| | +--rw key-string		| | +--rw key-string
	| | +--rw (key-string-style)?		| | +--rw (key-string-style)?
	| | +--:(keystring)		| | +--:(keystring)
	| | | +--rw keystring? string		| | | +--rw keystring? string
	| | +--:(hexadecimal) {hex-key-string}?		| | +--:(hexadecimal) {hex-key-string}?
	| | +--rw hexadecimal-string? yang:hex-string		| | +--rw hexadecimal-string? yang:hex-string
	| +--rw aes-key-wrap {aes-key-wrap}?		| +--rw aes-key-wrap {aes-key-wrap}?
	| +--rw enable? boolean		| +--rw enable? boolean
	+--ro key-chains-state		+--ro key-chains-state
	+--ro key-chain* [name]		+--ro key-chain* [name]
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 49 ¶
	| | +--:(start-end-time)		| | +--:(start-end-time)
	| | +--ro start-date-time? yang:date-and-time		| | +--ro start-date-time? yang:date-and-time
	| | +--ro (end-time)?		| | +--ro (end-time)?
	| | +--:(infinite)		| | +--:(infinite)
	| | | +--ro no-end-time? empty		| | | +--ro no-end-time? empty
	| | +--:(duration)		| | +--:(duration)
	| | | +--ro duration? uint32		| | | +--ro duration? uint32
	| | +--:(end-date-time)		| | +--:(end-date-time)
	| | +--ro end-date-time?		| | +--ro end-date-time?
	| | yang:date-and-time		| | yang:date-and-time
	| +--ro crypto-algorithm identityref		| +--ro crypto-algorithm identityref
	| +--ro key-string		| +--ro key-string
	| | +--ro (key-string-style)?		| | +--ro (key-string-style)?
	| | +--:(keystring)		| | +--:(keystring)
	| | | +--ro keystring? string		| | | +--ro keystring? string
	| | +--:(hexadecimal) {hex-key-string}?		| | +--:(hexadecimal) {hex-key-string}?
	| | +--ro hexadecimal-string? yang:hex-string		| | +--ro hexadecimal-string? yang:hex-string
	| +--ro send-lifetime-active? boolean		| +--ro send-lifetime-active? boolean
	| +--ro accept-lifetime-active? boolean		| +--ro accept-lifetime-active? boolean
	+--ro aes-key-wrap {aes-key-wrap}?		+--ro aes-key-wrap {aes-key-wrap}?
	+--ro enable? boolean		+--ro enable? boolean
	skipping to change at page 15, line 22 ¶		skipping to change at page 15, line 22 ¶
	description		description
	"Key string in ASCII format.";		"Key string in ASCII format.";
	}		}
	}		}
	case hexadecimal {		case hexadecimal {
	if-feature "hex-key-string";		if-feature "hex-key-string";
	leaf hexadecimal-string {		leaf hexadecimal-string {
	type yang:hex-string;		type yang:hex-string;
	description		description
	"Key in hexadecimal string format. When compared		"Key in hexadecimal string format. When compared
	to ASCII, specification in hexadecimal affords		to ASCII, specification in hexadecimal affords
	greater key entropy with the same number of		greater key entropy with the same number of
	octets. Additionally, it discourages usage of		octets. Additionally, it discourages usage of
	well-known words or numbers.";		well-known words or numbers.";
	}		}
	}		}
	}		}
	}		}
	}		}
	grouping key-chain-common {		grouping key-chain-common {
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 17 ¶
	The YANG module defined in this document is designed to be accessed		The YANG module defined in this document is designed to be accessed
	via network management protocols such as NETCONF [NETCONF] or		via network management protocols such as NETCONF [NETCONF] or
	RESTCONF [RESTCONF]. The lowest NETCONF layer is the secure		RESTCONF [RESTCONF]. The lowest NETCONF layer is the secure
	transport layer, and the mandatory-to-implement secure transport is		transport layer, and the mandatory-to-implement secure transport is
	Secure Shell (SSH) [NETCONF-SSH]. The lowest RESTCONF layer is		Secure Shell (SSH) [NETCONF-SSH]. The lowest RESTCONF layer is
	HTTPS, and the mandatory-to-implement secure transport is TLS [TLS].		HTTPS, and the mandatory-to-implement secure transport is TLS [TLS].
	The NETCONF access control model [NETCONF-ACM] provides the means to		The NETCONF access control model [NETCONF-ACM] provides the means to
	restrict access for particular NETCONF or RESTCONF users to a pre-		restrict access for particular NETCONF or RESTCONF users to a pre-
	configured subset of all available NETCONF or RESTCONF protocol		configured subset of all available NETCONF or RESTCONF protocol
	operations and content.		operations and content. The key strings are not accessible by
			default and NETCONF Access Control Mode [NETCONF-ACM] rules are
			required to configure or retrieve them.
	When configured, the key-strings can be encrypted using the AES Key		When configured, the key-strings can be encrypted using the AES Key
	Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is		Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is
	not included in the YANG model and must be set or derived independent		not included in the YANG model and must be set or derived independent
	of key-chain configuration.		of key-chain configuration. When AES key-encryption is used, the
			hex-key-string feature is also required since the encrypted keys will
	The key strings are not accessible by default and NETCONF Access		contain characters that are not representable in the YANG string
	Control Mode [NETCONF-ACM] rules are required to configure or		built-in type [YANG]. AES key-encryption MAY be used for added key
	retrieve them.		security in situations where the NETCONF Access Control Mode is not
			available.
	The clear-text algorithm is included as a YANG feature. Usage is NOT		The clear-text algorithm is included as a YANG feature. Usage is NOT
	RECOMMENDED except in cases where the application and device have no		RECOMMENDED except in cases where the application and device have no
	other alternative (e.g., a legacy network device that must		other alternative (e.g., a legacy network device that must
	authenticate packets at intervals of 10 milliseconds or less for many		authenticate packets at intervals of 10 milliseconds or less for many
	peers using Bidirectional Forwarding Detection [BFD]). Keys used		peers using Bidirectional Forwarding Detection [BFD]). Keys used
	with the clear-text algorithm are considered insecure and SHOULD NOT		with the clear-text algorithm are considered insecure and SHOULD NOT
	be reused with more secure algorithms.		be reused with more secure algorithms.
			Similarly, the MD5 and SHA-1 algorithms have been proven to be
			insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]) and usage is NOT
			RECOMMENDED. Usage should be confined to deployments where it is
			required for backward compatibility.
	It is RECOMMENDED that keys be encrypted or otherwise obfuscated when		It is RECOMMENDED that keys be encrypted or otherwise obfuscated when
	stored internally on a network device supporting this specification.		stored internally on a network device supporting this specification.
	6. IANA Considerations		6. IANA Considerations
	This document registers a URI in the IETF XML registry		This document registers a URI in the IETF XML registry
	[XML-REGISTRY]. Following the format in [XML-REGISTRY], the		[XML-REGISTRY]. Following the format in [XML-REGISTRY], the
	following registration is requested to be made:		following registration is requested to be made:
	URI: urn:ietf:params:xml:ns:yang:ietf-key-chain		URI: urn:ietf:params:xml:ns:yang:ietf-key-chain
	skipping to change at page 20, line 9 ¶		skipping to change at page 20, line 19 ¶
	(AES) Key Wrap with Padding Algorithm", RFC 5649, August		(AES) Key Wrap with Padding Algorithm", RFC 5649, August
	2009.		2009.
	[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD)", RFC 5880, June 2010.		(BFD)", RFC 5880, June 2010.
	[CRYPTO-KEYTABLE]		[CRYPTO-KEYTABLE]
	Housley, R., Polk, T., Hartman, S., and D. Zhang,		Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Table of Cryptographic Keys", RFC 7210, April 2014.		"Table of Cryptographic Keys", RFC 7210, April 2014.
			[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical
			Report (Presented at the RUMP Session of EuroCrypt 1996),
			2 May 1996.
			[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack",
			CryptoBytes Vol. 2, No. 2, Summer 1996.
	[IAB-REPORT]		[IAB-REPORT]
	Andersson, L., Davies, E., and L. Zhang, "Report from the		Andersson, L., Davies, E., and L. Zhang, "Report from the
	IAB workshop on Unwanted Traffic March 9-10, 2006", RFC		IAB workshop on Unwanted Traffic March 9-10, 2006", RFC
	4948, August 2007.		4948, August 2007.
	[NETCONF-SSH]		[NETCONF-SSH]
	Wasserman, M., "NETCONF over SSH", RFC 6242, June 2011.		Wasserman, M., "NETCONF over SSH", RFC 6242, June 2011.
	[NTP-PROTO]		[NTP-PROTO]
	Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network		Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
	skipping to change at page 20, line 30 ¶		skipping to change at page 20, line 47 ¶
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, June 2010.
	[OSPFV3-AUTH]		[OSPFV3-AUTH]
	Bhatia, M., Manral, V., and A. Lindem, "Supporting		Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 7166, March 2014.		Authentication Trailer for OSPFv3", RFC 7166, March 2014.
	[RESTCONF]		[RESTCONF]
	Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, January 2017.		Protocol", RFC 8040, January 2017.
			[SHA-SEC-CON]
			Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
			Considerations for the SHA-0 and SHA-1 Message-Digest
			Algorithms", RFC 6194, February 2011.
	[TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP		[TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, June 2010.		Authentication Option", RFC 5925, June 2010.
	[TCP-AO-ALGORITHMS]		[TCP-AO-ALGORITHMS]
	Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms		Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
	for the TCP Authentication Option (TCP-AO)", RFC 5926,		for the TCP Authentication Option (TCP-AO)", RFC 5926,
	June 2010.		June 2010.
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol", RFC 5246, August 2008.		(TLS) Protocol", RFC 5246, August 2008.
	skipping to change at page 24, line 20 ¶		skipping to change at page 24, line 20 ¶
	requirements.		requirements.
	Thanks to Ines Robles for Routing Directorate QA review comments.		Thanks to Ines Robles for Routing Directorate QA review comments.
	Thanks to Ladislav Lhotka for YANG Doctor comments.		Thanks to Ladislav Lhotka for YANG Doctor comments.
	Thanks to Martin Bjorklund for additional YANG Doctor comments.		Thanks to Martin Bjorklund for additional YANG Doctor comments.
	Thanks to Tom Petch for comments during IETF last call.		Thanks to Tom Petch for comments during IETF last call.
			Thanks to Matthew Miller for comments made during the Gen-ART review.
			Thanks to Vincent Roca for comments made during the Security
			Directorate review.
	Authors' Addresses		Authors' Addresses
	Acee Lindem (editor)		Acee Lindem (editor)
	Cisco Systems		Cisco Systems
	301 Midenhall Way		301 Midenhall Way
	Cary, NC 27513		Cary, NC 27513
	USA		USA
	Email: acee@cisco.com		Email: acee@cisco.com
End of changes. 20 change blocks.
	30 lines changed or deleted		55 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/