< draft-ietf-rtgwg-yang-key-chain-22.txt		draft-ietf-rtgwg-yang-key-chain-23.txt >
	skipping to change at page 1, line 16 ¶		skipping to change at page 1, line 16 ¶
	Expires: October 30, 2017 Huawei		Expires: October 30, 2017 Huawei
	D. Yeung		D. Yeung
	Arrcus, Inc		Arrcus, Inc
	I. Chen		I. Chen
	Jabil		Jabil
	J. Zhang		J. Zhang
	Juniper Networks		Juniper Networks
	April 28, 2017		April 28, 2017
	Routing Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-22.txt		draft-ietf-rtgwg-yang-key-chain-23.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 33 ¶		skipping to change at page 2, line 33 ¶
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Graceful Key Rollover using Key Chains . . . . . . . . . 4		2.2. Graceful Key Rollover using Key Chains . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . . . . . 8		4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
	A.1. Simple Key Chain with Always Valid Single Key . . . . . . 19		A.1. Simple Key Chain with Always Valid Single Key . . . . . . 19
	A.2. Key Chain with Keys having Different Lifetimes . . . . . 19		A.2. Key Chain with Keys having Different Lifetimes . . . . . 20
	A.3. Key Chain with Independent Send and Accept Lifetimes . . 21		A.3. Key Chain with Independent Send and Accept Lifetimes . . 22
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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
	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 6, line 27 ¶		skipping to change at page 6, line 27 ¶
	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
	of 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 yet implemented by		(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not yet implemented by
	vendors or only a single vendor.		vendors or only a single vendor.
			It is common for an entity with sufficient permissions to read and
			store a device's configuration which would include the contents of
			this model. To avoid unnecessarily seeing and storing the keys in
			clear-text, this model provides the aes-key-wrap feature. More
			details are described in Security Considerations Section 5.
	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
	| +--rw accept-tolerance {accept-tolerance}?		| +--rw accept-tolerance {accept-tolerance}?
	| | +--rw duration? uint32		| | +--rw duration? uint32
	| +--ro last-modified-timestamp? yang:date-and-time		| +--ro last-modified-timestamp? yang:date-and-time
	| +--rw key* [key-id]		| +--rw key* [key-id]
	skipping to change at page 16, line 39 ¶		skipping to change at page 16, line 46 ¶
	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		Similarly, the MD5 and SHA-1 algorithms have been proven to be
	insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]) and usage is NOT		insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]) and usage is NOT
	RECOMMENDED. Usage should be confined to deployments where it is		RECOMMENDED. Usage should be confined to deployments where it is
	required for backward compatibility.		required for backward compatibility.
			Implementations with keys provided via this model should store them
			using best current security practices.
	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
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names		This document registers a YANG module in the YANG Module Names
	registry [YANG].		registry [YANG].
	name: key-chain		name: ietf-key-chain
	namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain		namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain
	prefix: key-chain		prefix: key-chain
	reference: RFC XXXX		reference: RFC XXXX
	7. Contributors		7. Contributors
	Contributors' Addresses		Contributors' Addresses
	Yi Yang		Yi Yang
	SockRate		SockRate
End of changes. 7 change blocks.
	9 lines changed or deleted		18 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/