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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/