< draft-ietf-rtgwg-yang-key-chain-20.txt		draft-ietf-rtgwg-yang-key-chain-21.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: October 20, 2017 Huawei		Expires: October 28, 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 18, 2017		April 26, 2017
	Routing Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-20.txt		draft-ietf-rtgwg-yang-key-chain-21.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
	representing them in a YANG data model, key distribution can be		representing them in a YANG data model, key distribution can be
	automated.		automated.
	In some applications, the protocols do not use the key chain element
	key directly, but rather a key derivation function is used to derive
	a short-lived key from the key chain element key (e.g., the Master
	Keys used in the TCP Authentication Option(TCP-AO)).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). 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 October 20, 2017.
			This Internet-Draft will expire on October 28, 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 30 ¶		skipping to change at page 2, line 29 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	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 . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . . 7		4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.1. Normative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 16
	8.2. Informative References . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
	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 . . . . . 19
	A.3. Key Chain with Independent Send and Accept Lifetimes . . 21		A.3. Key Chain with Independent Send and Accept Lifetimes . . 21
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	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
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 10 ¶
	This document describes a YANG [YANG] data model for key chains. Key		This document describes a YANG [YANG] data model for key chains. Key
	chains have been implemented and deployed by a large percentage of		chains have been implemented and deployed by a large percentage of
	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		using symmetric keys. In essence, the key-chain is a reusable key
	referenced wherever it is required. The key-chain construct has been		policy that can be referenced wherever it is required. The key-chain
	implemented by most networking vendors and deployed in many networks.		construct has been implemented by most networking vendors and
			deployed in many 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
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	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 facilitate reference to the key-chain name		has been provided to facilitate reference to the key-chain name
	without 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		To achieve graceful key rollover, the receiver MAY accept all the
	accept lifetime and sending the key with the most recent send		keys that have a valid accept lifetime and the sender MAY send the
	lifetime. One scenario for facilitating key rollover is to:		key with the most recent send lifetime. One scenario for
			facilitating key rollover is to:
	1. Distribute a key chain with a new key to all the routers or other		1. Distribute a key chain with a new key to all the routers or other
	network devices in the domain of that key chain. The new key's		network devices in the domain of that key chain. The new key's
	accept lifetime should be such that it is accepted during the key		accept lifetime should be such that it is accepted during the key
	rollover period. The send lifetime should be a time in the		rollover period. The send lifetime should be a time in the
	future when it can be assured that all the routers in the domain		future when it can be assured that all the routers in the domain
	of that key are upgraded. This will have no immediate impact on		of that key are upgraded. This will have no immediate impact on
	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
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	transmissions.		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).
			Since the most recent send lifetime is defined as the one with the
			latest start-time, specification of "always" will prevent using the
			graceful key rollover technique described above. Other key
			configuration and usage scenarios are possible but these are beyond
			the scope of this document.
	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 different key values for transmission versus acceptance may		Note that different key values for transmission versus acceptance may
	be supported with multiple key chain elements where the accept-		be supported with multiple key chain elements. The key used for
	lifetime or send-lifetime is not valid (e.g., has an end-time equal		transmission will have a valid send-lifetime and invalid accept-
	to the start-time).		lifetime (e.g., has an end-time equal to the start-time). The key
			used for acceptance will have a valid accept-lifetime and invalid
			send-lifetime.
	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.		YANG modules when they need to reference a configured key-chain.
	3.1. Key Chain Operational State		3.1. Key Chain Operational State
	The key chain operational state is included in the same tree as key		The key chain operational state is included in the same tree as key
	chain configuration consistent with [NMDA]. The timestamp of the		chain configuration consistent with Network Management Datastore
	last key chain modification is also maintained in the operational		Architecture [NMDA]. The timestamp of the last key chain
	state. Additionally, the operational state includes an indication of		modification is also maintained in the operational state.
	whether or not a key chain key is valid for sending or acceptance.		Additionally, the operational state includes an indication of whether
			or not a key chain key is valid for 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
	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 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.
	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]
	| +--rw key-id uint64		+--rw key-id uint64
	| +--rw lifetime		+--rw lifetime
	| | +--rw (lifetime)?		| +--rw (lifetime)?
	| | +--:(send-and-accept-lifetime)		| +--:(send-and-accept-lifetime)
	| | | +--rw send-accept-lifetime		| | +--rw send-accept-lifetime
	| | | +--rw (lifetime)?		| | +--rw (lifetime)?
	| | | +--:(always)		| | +--:(always)
	| | | | +--rw always? empty		| | | +--rw always? empty
	| | | +--:(start-end-time)		| | +--:(start-end-time)
	| | | +--rw start-date-time?		| | +--rw start-date-time?
	| | | | yang:date-and-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
	| | +--:(independent-send-accept-lifetime)		| +--:(independent-send-accept-lifetime)
	| | | {independent-send-accept-lifetime}?		| | {independent-send-accept-lifetime}?
	| | +--rw send-lifetime		| +--rw send-lifetime
	| | | +--rw (lifetime)?		| | +--rw (lifetime)?
	| | | +--:(always)		| | +--:(always)
	| | | | +--rw always? empty		| | | +--rw always? empty
	| | | +--:(start-end-time)		| | +--:(start-end-time)
	| | | +--rw start-date-time?		| | +--rw start-date-time?
	| | | | yang:date-and-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 accept-lifetime		| +--rw accept-lifetime
	| | +--rw (lifetime)?		| +--rw (lifetime)?
	| | +--:(always)		| +--:(always)
	| | | +--rw always? empty		| | +--rw always? empty
	| | +--:(start-end-time)		| +--:(start-end-time)
	| | +--rw start-date-time?		| +--rw start-date-time?
	| | | yang:date-and-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
	| +--ro send-lifetime-active? boolean		+--ro send-lifetime-active? boolean
	| +--ro accept-lifetime-active? boolean		+--ro accept-lifetime-active? boolean
	+--rw aes-key-wrap {aes-key-wrap}?
	+--rw enable? boolean
	4. Key Chain YANG Model		4. Key Chain YANG Model
	<CODE BEGINS> file "ietf-key-chain@2017-04-18.yang"		<CODE BEGINS> file "ietf-key-chain@2017-04-18.yang"
	module ietf-key-chain {		module ietf-key-chain {
	yang-version 1.1;		yang-version 1.1;
	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;
	import ietf-yang-types {		import ietf-yang-types {
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 15 ¶
	4. Key Chain YANG Model		4. Key Chain YANG Model
	<CODE BEGINS> file "ietf-key-chain@2017-04-18.yang"		<CODE BEGINS> file "ietf-key-chain@2017-04-18.yang"
	module ietf-key-chain {		module ietf-key-chain {
	yang-version 1.1;		yang-version 1.1;
	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;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	}		}
	import ietf-netconf-acm {		import ietf-netconf-acm {
	prefix nacm;		prefix nacm;
	}		}
	organization		organization
	"IETF RTG (Routing) Working Group";		"IETF RTG (Routing) Working Group";
	contact		contact
	"Acee Lindem - acee@cisco.com";		"Acee Lindem - acee@cisco.com";
	description		description
	"This YANG module defines the generic configuration		"This YANG module defines the generic configuration
	data for key-chain. It is intended that the module		data for key-chain. It is intended that the module
	will be extended by vendors to define vendor-specific		will be extended by vendors to define vendor-specific
	key-chain configuration parameters.		key-chain configuration parameters.
	Copyright (c) 2015 IETF Trust and the persons identified as		Copyright (c) 2017 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	skipping to change at page 8, line 42 ¶		skipping to change at page 9, line 4 ¶
	revision 2017-04-18 {		revision 2017-04-18 {
	description		description
	"Initial RFC Revision";		"Initial RFC Revision";
	reference "RFC XXXX: A YANG Data Model for key-chain";		reference "RFC XXXX: A YANG Data Model for key-chain";
	}		}
	feature hex-key-string {		feature hex-key-string {
	description		description
	"Support hexadecimal key string.";		"Support hexadecimal key string.";
	}		}
	feature accept-tolerance {		feature accept-tolerance {
	description		description
	"To specify the tolerance or acceptance limit.";		"Support the tolerance or acceptance limit.";
	}		}
	feature independent-send-accept-lifetime {		feature independent-send-accept-lifetime {
	description		description
	"Support for independent send and accept key lifetimes.";		"Support for independent send and accept key lifetimes.";
	}		}
	feature crypto-hmac-sha-1-12 {		feature crypto-hmac-sha-1-12 {
	description		description
	"Support for TCP HMAC-SHA-1 12 byte digest hack.";		"Support for TCP HMAC-SHA-1 12 byte digest hack.";
	}		}
	feature clear-text {		feature clear-text {
	description		description
	"Support for clear-text algorithm. Usage is		"Support for clear-text algorithm. Usage is
	NOT RECOMMENDED.";		NOT RECOMMENDED.";
	}		}
	feature aes-cmac-prf-128 {		feature aes-cmac-prf-128 {
	description		description
	"Support for AES Cipher based Message Authentication		"Support for AES Cipher based Message Authentication
	Code Pseudo Random Function.";		Code Pseudo Random Function.";
	}		}
	feature aes-key-wrap {
	description
	"Support for Advanced Encryption Standard (AES) Key Wrap.";
	}
	feature replay-protection-only {		feature replay-protection-only {
	description		description
	"Provide replay-protection without any authentication		"Provide replay-protection without any authentication
	as required by protocols such as Bidirectional		as required by protocols such as Bidirectional
	Forwarding Detection (BFD).";		Forwarding Detection (BFD).";
	}		}
	identity crypto-algorithm {		identity crypto-algorithm {
	description		description
	"Base identity of cryptographic algorithm options.";		"Base identity of cryptographic algorithm options.";
	}		}
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 51 ¶
	"Start time.";		"Start time.";
	}		}
	choice end-time {		choice end-time {
	default "infinite";		default "infinite";
	description		description
	"End-time setting.";		"End-time setting.";
	case infinite {		case infinite {
	leaf no-end-time {		leaf no-end-time {
	type empty;		type empty;
	description		description
	"Indicates key lifetime end-time in infinite.";		"Indicates key lifetime end-time is infinite.";
	}		}
	}		}
	case duration {		case duration {
	leaf duration {		leaf duration {
	type uint32 {		type uint32 {
	range "1..2147483646";		range "1..2147483646";
	}		}
	units "seconds";		units "seconds";
	description		description
	"Key lifetime duration, in seconds";		"Key lifetime duration, in seconds";
	skipping to change at page 14, line 42 ¶		skipping to change at page 14, line 47 ¶
	}		}
	}		}
	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		internal key-string octets. Additionally, it
	well-known words or numbers.";		discourages usage of well-known words or
			numbers.";
	}		}
	}		}
	}		}
	}		}
	leaf send-lifetime-active {		leaf send-lifetime-active {
	type boolean;		type boolean;
	config false;		config false;
	description		description
	"Indicates if the send lifetime of the		"Indicates if the send lifetime of the
	key-chain key is currently active.";		key-chain key is currently active.";
	}		}
	leaf accept-lifetime-active {		leaf accept-lifetime-active {
	type boolean;		type boolean;
	config false;		config false;
	description		description
	"Indicates if the accept lifetime of the		"Indicates if the accept lifetime of the
	key-chain key is currently active.";		key-chain key is currently active.";
	}		}
	}		}
	}		}
	container aes-key-wrap {
	if-feature "aes-key-wrap";
	description
	"AES Key Wrap password encryption.";
	leaf enable {
	type boolean;
	default "false";
	description
	"Enable AES Key Wrap encryption.";
	}
	}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	5. Security Considerations		5. Security Considerations
	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. The key strings are not accessible by		operations and content. The key strings are not accessible by
	default and NETCONF Access Control Mode [NETCONF-ACM] rules are		default and NETCONF Access Control Mode [NETCONF-ACM] rules are
	required to configure or retrieve them.		required to configure or retrieve them.
	When configured, the key-strings can be encrypted using the AES Key
	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
	of key-chain configuration. When AES key-encryption is used, the
	hex-key-string feature is also required since the encrypted keys will
	contain characters that are not representable in the YANG string
	built-in type [YANG]. AES key-encryption MAY be used for added key
	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		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
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 28 ¶
	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: ietf-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: ietf-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
	Email: yi.yang@sockrate.com		Email: yi.yang@sockrate.com
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	skipping to change at page 17, line 37 ¶		skipping to change at page 17, line 18 ¶
	[XML-REGISTRY]		[XML-REGISTRY]
	Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[YANG] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC		[YANG] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC
	7950, August 2016.		7950, August 2016.
	8.2. Informative References		8.2. Informative References
	[AES-KEY-WRAP]
	Housley, R. and M. Dworkin, "Advanced Encryption Standard
	(AES) Key Wrap with Padding Algorithm", RFC 5649, August
	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		[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical
	Report (Presented at the RUMP Session of EuroCrypt 1996),		Report (Presented at the RUMP Session of EuroCrypt 1996),
	2 May 1996.		2 May 1996.
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 10 ¶
	</key-chains>		</key-chains>
	</data>		</data>
	A.2. Key Chain with Keys having Different Lifetimes		A.2. Key Chain with Keys having Different Lifetimes
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">		<key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
	<key-chain>		<key-chain>
	<name>keychain2</name>		<name>keychain2</name>
	<description>		<description>
	A key chain where each key contains different send time		A key chain where each key contains a different send time
	and accept time and a different algorithm illustrating		and accept time and a different algorithm illustrating
	algorithm agility		algorithm agility
	</description>		</description>
	<key>		<key>
	<key-id>35</key-id>		<key-id>35</key-id>
	<lifetime>		<lifetime>
	<send-lifetime>		<send-lifetime>
	<start-date-time>2017-01-01T00:00:00Z</start-date-time>		<start-date-time>2017-01-01T00:00:00Z</start-date-time>
	<end-date-time>2017-02-01T00:00:00Z</end-date-time>		<end-date-time>2017-02-01T00:00:00Z</end-date-time>
	</send-lifetime>		</send-lifetime>
	skipping to change at page 22, line 25 ¶		skipping to change at page 22, line 25 ¶
	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 Matthew Miller for comments made during the Gen-ART review.
	Thanks to Vincent Roca for comments made during the Security		Thanks to Vincent Roca for comments made during the Security
	Directorate review.		Directorate review.
			Thanks to Warren Kumari, Ben Campbell, Adam Roach, and Benoit Claise
			for comments received during the IESG 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. 32 change blocks.
	137 lines changed or deleted		117 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/