< draft-ietf-rtgwg-yang-key-chain-11.txt		draft-ietf-rtgwg-yang-key-chain-12.txt >
	Network Working Group A. Lindem, Ed.		Network Working Group A. Lindem, Ed.
	Internet-Draft Y. Qu		Internet-Draft Cisco Systems
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Y. Qu
	Expires: May 18, 2017 D. Yeung		Expires: July 22, 2017 Huawei
			D. Yeung
	Arrcus, Inc		Arrcus, Inc
	I. Chen		I. Chen
	Ericsson		Ericsson
	J. Zhang		J. Zhang
	Juniper Networks		Juniper Networks
	Y. Yang		Y. Yang
	Individual Contributor		SockRate
	November 14, 2016		January 18, 2017
	Routing Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-11.txt		draft-ietf-rtgwg-yang-key-chain-12.txt
	Abstract		Abstract
	This document describes the key chain YANG data model. A key chain		This document describes the key chain YANG data model. A key chain
	is a list of elements each containing a key, send lifetime, accept		is a list of elements each containing a key, 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, keys and algorithms may be gracefully updated. By		elements, keys 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. Key chains are commonly used for routing protocol		automated. Key chains are commonly used for routing protocol
	skipping to change at page 1, line 48 ¶		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 July 22, 2017.
	This Internet-Draft will expire on May 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 33 ¶
	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 . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 20		5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Normative References . . . . . . . . . . . . . . . . . . 21		7.1. Normative References . . . . . . . . . . . . . . . . . . 21
	7.2. Informative References . . . . . . . . . . . . . . . . . 21		7.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	This document describes the key chain YANG data model. A key chain		This document describes the key chain YANG data model. A key chain
	is a list of elements each containing a key, send lifetime, accept		is a list of elements each containing a key, 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, keys and algorithms may be gracefully updated. By		elements, keys 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. Key chains are commonly used for routing protocol		automated. Key chains are commonly used for routing protocol
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 35 ¶
	| | +--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		| | +--rw crypto-algorithm
	| | | +--rw (algorithm)?		| | | +--rw (algorithm)?
	| | | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?		| | | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?
	| | | | +--rw hmac-sha1-12? empty		| | | | +--rw hmac-sha1-12? empty
	| | | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?		| | | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?
	| | | | +--rw aes-cmac-prf-128? empty		| | | | +--rw aes-cmac-prf-128? empty
	| | | +--:(md5)		| | | +--:(md5)
	| | | | +--rw md5? empty		| | | | +--rw md5? empty
	| | | +--:(sha-1)		| | | +--:(sha-1)
	| | | | +--rw sha-1? empty		| | | | +--rw sha-1? empty
	| | | +--:(hmac-sha-1)		| | | +--:(hmac-sha-1)
	| | | | +--rw hmac-sha-1? empty		| | | | +--rw hmac-sha-1? empty
	| | | +--:(hmac-sha-256)		| | | +--:(hmac-sha-256)
	| | | | +--rw hmac-sha-256? empty		| | | | +--rw hmac-sha-256? empty
	| | | +--:(hmac-sha-384)		| | | +--:(hmac-sha-384)
	| | | | +--rw hmac-sha-384? empty		| | | | +--rw hmac-sha-384? empty
	| | | +--:(hmac-sha-512)		| | | +--:(hmac-sha-512)
	| | | | +--rw hmac-sha-512? empty		| | | | +--rw hmac-sha-512? empty
	| | | +--:(clear-text) {clear-text}?		| | | +--:(clear-text) {clear-text}?
	| | | | +--rw clear-text? empty		| | | | +--rw clear-text? empty
	| | | +--:(replay-protection-only) {replay-protection-only}?		| | | +--:(replay-protection-only)
			| | | {replay-protection-only}?
	| | | +--rw replay-protection-only? empty		| | | +--rw replay-protection-only? empty
	| | +--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-chain-state		+--ro key-chain-state
	+--ro key-chain-list* [name]		+--ro key-chain-list* [name]
	| +--ro name string		| +--ro name string
	| +--ro description? string		| +--ro description? string
	| +--ro accept-tolerance {accept-tolerance}?		| +--ro accept-tolerance {accept-tolerance}?
	| | +--ro duration? uint32		| | +--ro duration? uint32
	| +--ro last-modified-timestamp? yang:date-and-time		| +--ro last-modified-timestamp? yang:date-and-time
	| +--ro key-chain-entries* [key-id]		| +--ro key-chain-entries* [key-id]
	| +--ro key-id uint64		| +--ro key-id uint64
	| +--ro lifetime		| +--ro lifetime
	| | +--ro (lifetime)?		| | +--ro (lifetime)?
	| | +--:(send-and-accept-lifetime)		| | +--:(send-and-accept-lifetime)
	| | | +--ro send-accept-lifetime		| | | +--ro send-accept-lifetime
	| | | +--ro (lifetime)?		| | | +--ro (lifetime)?
	| | | +--:(always)		| | | +--:(always)
	| | | | +--ro always? empty		| | | | +--ro always? empty
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--ro start-date-time?		| | | +--ro start-date-time?
	| | | | yang:date-and-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
	| | +--:(independent-send-accept-lifetime)		| | +--:(independent-send-accept-lifetime)
	| | {independent-send-accept-lifetime}?		| | | {independent-send-accept-lifetime}?
	| | +--ro send-lifetime		| | +--ro send-lifetime
	| | | +--ro (lifetime)?		| | | +--ro (lifetime)?
	| | | +--:(always)		| | | +--:(always)
	| | | | +--ro always? empty		| | | | +--ro always? empty
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--ro start-date-time?		| | | +--ro start-date-time?
	| | | yang:date-and-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 accept-lifetime		| | +--ro accept-lifetime
	| | +--ro (lifetime)?		| | +--ro (lifetime)?
	| | +--:(always)		| | +--:(always)
	| | | +--ro always? empty		| | | +--ro always? empty
	| | +--:(start-end-time)		| | +--:(start-end-time)
	| | +--ro start-date-time?		| | +--ro start-date-time? yang:date-and-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		| +--ro crypto-algorithm
	| | +--ro (algorithm)?		| | +--ro (algorithm)?
	| | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?		| | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?
	| | | +--ro hmac-sha1-12? empty		| | | +--ro hmac-sha1-12? empty
	| | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?		| | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?
	| | | +--ro aes-cmac-prf-128? empty		| | | +--ro aes-cmac-prf-128? empty
	| | +--:(md5)		| | +--:(md5)
	| | | +--ro md5? empty		| | | +--ro md5? empty
	| | +--:(sha-1)		| | +--:(sha-1)
	| | | +--ro sha-1? empty		| | | +--ro sha-1? empty
	| | +--:(hmac-sha-1)		| | +--:(hmac-sha-1)
	| | | +--ro hmac-sha-1? empty		| | | +--ro hmac-sha-1? empty
	| | +--:(hmac-sha-256)		| | +--:(hmac-sha-256)
	| | | +--ro hmac-sha-256? empty		| | | +--ro hmac-sha-256? empty
	| | +--:(hmac-sha-384)		| | +--:(hmac-sha-384)
	| | | +--ro hmac-sha-384? empty		| | | +--ro hmac-sha-384? empty
	| | +--:(hmac-sha-512)		| | +--:(hmac-sha-512)
	| | | +--ro hmac-sha-512? empty		| | | +--ro hmac-sha-512? empty
	| | +--:(clear-text) {clear-text}?		| | +--:(clear-text) {clear-text}?
	| | | +--ro clear-text? empty		| | | +--ro clear-text? empty
	| | +--:(replay-protection-only) {replay-protection-only}?		| | +--:(replay-protection-only)
			| | | {replay-protection-only}?
	| | +--ro replay-protection-only? empty		| | +--ro replay-protection-only? empty
			| +--ro key-string
			| +--ro (key-string-style)?
			| +--:(keystring)
			| | +--ro keystring? string
			| +--:(hexadecimal) {hex-key-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
	4. Key Chain YANG Model		4. Key Chain YANG Model
	<CODE BEGINS> file "ietf-key-chain@2016-11-14.yang"		<CODE BEGINS> file "ietf-key-chain@2017-01-20.yang" <
	module ietf-key-chain {		<module ietf-key-chain {
	namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";		namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";
	// replace with IANA namespace when assigned		// replace with IANA namespace when assigned
	prefix "key-chain";		prefix "key-chain";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
			import ietf-netconf-acm {
			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.
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 45 ¶
	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.";
			revision 2017-01-20 {
			description
			"Add support of using NETCONF Access Control for
			key-string.";
			reference
			"RFC XXXX: A YANG Data Model for key-chain";
			}
	revision 2016-11-14 {		revision 2016-11-14 {
	description		description
	"Restore last-modified timestamp leaf.";		"Restore last-modified timestamp leaf.";
	reference		reference
	"RFC XXXX: A YANG Data Model for key-chain";		"RFC XXXX: A YANG Data Model for key-chain";
	}		}
	revision 2016-10-27 {		revision 2016-10-27 {
	description		description
	"Restructure into separate config and state trees to		"Restructure into separate config and state trees to
	match YANG structure.";		match YANG structure.";
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 25 ¶
	}		}
	grouping key-chain-common-entry {		grouping key-chain-common-entry {
	description "Key-chain entry data nodes common to		description "Key-chain entry data nodes common to
	configuration and state.";		configuration and state.";
	container lifetime {		container lifetime {
	description "Specify a key's lifetime.";		description "Specify a key's lifetime.";
	choice lifetime {		choice lifetime {
	description		description
	"Options for specification of send and accept		"Options for specification of send and accept
			lifetimes.";
	lifetimes.";
	case send-and-accept-lifetime {		case send-and-accept-lifetime {
	description		description
	"Send and accept key have the same		"Send and accept key have the same
	lifetime.";		lifetime.";
	container send-accept-lifetime {		container send-accept-lifetime {
	uses lifetime;		uses lifetime;
	description		description
	"Single lifetime specification for both		"Single lifetime specification for both
	send and accept lifetimes.";		send and accept lifetimes.";
	}		}
	skipping to change at page 16, line 32 ¶		skipping to change at page 17, line 4 ¶
	uses lifetime;		uses lifetime;
	description		description
	"Separate lifetime specification for send		"Separate lifetime specification for send
	lifetime.";		lifetime.";
	}		}
	container accept-lifetime {		container accept-lifetime {
	uses lifetime;		uses lifetime;
	description		description
	"Separate lifetime specification for		"Separate lifetime specification for
	accept lifetime.";		accept lifetime.";
	}		}
	}		}
	}		}
	}		}
	container crypto-algorithm {		container crypto-algorithm {
	uses crypto-algorithm-types;		uses crypto-algorithm-types;
	description		description
	"Cryptographic algorithm associated with key.";		"Cryptographic algorithm associated with key.";
	}		}
	}
	grouping key-chain-config-entry {
	description "Key-chain configuration entry.";
	uses key-chain-common-entry;
	container key-string {		container key-string {
	description "The key string.";		description "The key string.";
			nacm:default-deny-all;
	choice key-string-style {		choice key-string-style {
	description		description
	"Key string styles";		"Key string styles";
	case keystring {		case keystring {
	leaf keystring {		leaf keystring {
	type string;		type string;
	description		description
	"Key string in ASCII format.";		"Key string in ASCII format.";
	}		}
	}		}
	skipping to change at page 17, line 21 ¶		skipping to change at page 17, line 39 ¶
	leaf hexadecimal-string {		leaf hexadecimal-string {
	type yang:hex-string;		type yang:hex-string;
	description		description
	"Key in hexadecimal string format.";		"Key in hexadecimal string format.";
	}		}
	}		}
	}		}
	}		}
	}		}
			grouping key-chain-config-entry {
			description "Key-chain configuration entry.";
			uses key-chain-common-entry;
			}
	grouping key-chain-state-entry {		grouping key-chain-state-entry {
	description "Key-chain state entry.";		description "Key-chain state entry.";
	uses key-chain-common-entry;		uses key-chain-common-entry;
	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 entry is currently active.";		key-chain entry is currently active.";
	}		}
	skipping to change at page 19, line 50 ¶		skipping to change at page 20, line 22 ¶
	type boolean;		type boolean;
	description		description
	"Indicates whether AES Key Wrap encryption		"Indicates whether AES Key Wrap encryption
	is enabled.";		is enabled.";
	}		}
	}		}
	description "State for all configured key-chains		description "State for all configured key-chains
	on the device.";		on the device.";
	}		}
	}		}
	<CODE ENDS>		CODE ENDS>
	5. Security Considerations		5. Security Considerations
	This document enables the automated distribution of industry standard		This document enables the automated distribution of industry standard
	key chains using the NETCONF [NETCONF] protocol. As such, the		key chains using the NETCONF [NETCONF] protocol. As such, the
	security considerations for the NETCONF protocol are applicable.		security considerations for the NETCONF protocol are applicable.
	Given that the key chains themselves are sensitive data, it is		Given that the key chains themselves are sensitive data, it is
	RECOMMENDED that the NETCONF communication channel be encrypted. One		RECOMMENDED that the NETCONF communication channel be encrypted. One
	way to do accomplish this would be to invoke and run NETCONF over SSH		way to do accomplish this would be to invoke and run NETCONF over SSH
	as described in [NETCONF-SSH].		as described in [NETCONF-SSH].
	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.
	The key strings are not included in the operational state. This is a		The key strings are not accessible by default and NETCONF Access
	practice carried over from SNMP MIB modules and is an area for		Control Mode [NETCONF-ACM] rules are required to configure or
	further discussion.		retrieve them.
	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.
	6. IANA Considerations		6. IANA Considerations
	skipping to change at page 21, line 13 ¶		skipping to change at page 21, line 31 ¶
	key-chain prefix: ietf-key-chain reference: RFC XXXX		key-chain prefix: ietf-key-chain reference: RFC XXXX
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.		[NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	Bierman, "Network Configuration Protocol (NETCONF)", RFC		Bierman, "Network Configuration Protocol (NETCONF)", RFC
	6241, June 2011.		6241, June 2011.
			[NETCONF-ACM]
			Bierman, A. and M. Bjorklund, "Network Configuration
			Protocol (NETCONF) Access Control Model", RFC 6536, March
			2012.
	[NETCONF-SSH]		[NETCONF-SSH]
	Wasserman, M., "Using NETCONF Protocol over Secure Shell		Wasserman, M., "Using NETCONF Protocol over Secure Shell
	(SSH)", RFC 6242, June 2011.		(SSH)", RFC 6242, June 2011.
	[RFC-KEYWORDS]		[RFC-KEYWORDS]
	Bradner, S., "Key words for use in RFC's to Indicate		Bradner, S., "Key words for use in RFC's to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[XML-REGISTRY]		[XML-REGISTRY]
	Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 20 ¶
	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
	Yingzhen Qu		Yingzhen Qu
	Cisco Systems		Huawei
	170 West Tasman Drive
	San Jose, CA 95134
	USA
	Email: yiqu@cisco.com		Email: yingzhen.qu@huawei.com
	Derek Yeung		Derek Yeung
	Arrcus, Inc		Arrcus, Inc
	Email: derek@arrcus.com		Email: derek@arrcus.com
	Ing-Wher Chen		Ing-Wher Chen
	Ericsson		Ericsson
	Email: ichen@kuatrotech.com		Email: ichen@kuatrotech.com
	skipping to change at page 23, line 29 ¶		skipping to change at page 24, line 4 ¶
	Email: ichen@kuatrotech.com		Email: ichen@kuatrotech.com
	Jeffrey Zhang		Jeffrey Zhang
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: zzhang@juniper.net		Email: zzhang@juniper.net
	Yi Yang		Yi Yang
	Individual Contributor		SockRate
	Email: yiyang1998@gmail.com		Email: yi.yang@sockrate.com
End of changes. 45 change blocks.
	53 lines changed or deleted		72 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/