draft-ietf-rtgwg-yang-key-chain-06.txt   draft-ietf-rtgwg-yang-key-chain-07.txt 
Network Working Group A. Lindem, Ed. Network Working Group A. Lindem, Ed.
Internet-Draft Y. Qu Internet-Draft Y. Qu
Intended status: Standards Track D. Yeung Intended status: Standards Track D. Yeung
Expires: December 30, 2016 Cisco Systems Expires: February 18, 2017 Cisco Systems
I. Chen I. Chen
Ericsson Ericsson
J. Zhang J. Zhang
Juniper Networks Juniper Networks
Y. Yang Y. Yang
Cisco Systems Cisco Systems
June 28, 2016 August 17, 2016
Routing Key Chain YANG Data Model Routing Key Chain YANG Data Model
draft-ietf-rtgwg-yang-key-chain-06.txt draft-ietf-rtgwg-yang-key-chain-07.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. By properly overlapping the send and accept lifetime, and algorithm. By properly overlapping the send and accept
lifetimes of multiple key chain elements, keys and algorithms may be lifetimes of multiple key chain elements, keys and algorithms may be
gracefully updated. By representing them in a YANG data model, key gracefully updated. By representing them in a YANG data model, key
distribution can be automated. Key chains are commonly used for distribution can be automated. Key chains are commonly used for
routing protocol authentication and other applications. In some routing protocol authentication and other applications. In some
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 December 30, 2016. This Internet-Draft will expire on February 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3 2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3
3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4
3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5
3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5 3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5
3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5 3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5
4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8
5. Relationship to other Work . . . . . . . . . . . . . . . . . 17 5. Relationship to other Work . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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. By properly overlapping the send and accept lifetime, and algorithm. By properly overlapping the send and accept
lifetimes of multiple key chain elements, keys and algorithms may be lifetimes of multiple key chain elements, keys and algorithms may be
gracefully updated. By representing them in a YANG data model, key gracefully updated. By representing them in a YANG data model, key
distribution can be automated. Key chains are commonly used for distribution can be automated. Key chains are commonly used for
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 maintained in the key-chain The key chain operational state is maintained in the key-chain
entries along with the configuration state. The key string itself is entries along with the configuration state. The key string itself is
omitted from the operational state to minimize visibility similar to omitted from the operational state to minimize visibility similar to
what was done with keys in SNMP MIBs. This is an area for further what was done with keys in SNMP MIBs. The timestamp of the last key-
discussion. Additionally, the operational state includes an chain modification is also maintained in the operational state.
indication of whether or not a key chain entry is valid for sending Additionally, the operational state includes an indication of whether
or acceptance. or not a key chain entry 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
an acceptance tolerance or configuration of key strings in an acceptance tolerance or configuration of key strings in
hexadecimal. They are also used to support of security requirements hexadecimal. They are also used to support of security requirements
(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by
vendors or only a single vendor. vendors or only a single vendor.
3.3. Key Chain Model Tree 3.3. Key Chain Model Tree
module: ietf-key-chain module: ietf-key-chain
+-rw key-chains +--rw key-chains
+--rw key-chain-list* [name] +--rw key-chain-list* [name]
| +--rw name string | +--rw name string
| +--ro name-state? string | +--ro name-state? string
| +--rw description? string
| +--rw accept-tolerance {accept-tolerance}? | +--rw accept-tolerance {accept-tolerance}?
| | +--rw duration? uint32 | | +--rw duration? uint32
| +--ro accept-tolerance-state | +--ro accept-tolerance-state
| | +--ro duration? uint32 | | +--ro duration? uint32
| +--ro last-modified-timestamp? yang:date-and-time
| +--rw key-chain-entry* [key-id] | +--rw key-chain-entry* [key-id]
| +--rw key-id uint64 | +--rw key-id uint64
| +--ro key-id-state? uint64 | +--ro key-id-state? uint64
| +--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 lifetime | +--rw lifetime
skipping to change at page 6, line 15 skipping to change at page 6, line 17
| | | | +--rw always? empty | | | | +--rw always? empty
| | | +--:(start-end-time) | | | +--:(start-end-time)
| | | +--rw start-date-time? yang:date-and-time | | | +--rw start-date-time? yang:date-and-time
| | | +--rw (end-time)? | | | +--rw (end-time)?
| | | +--:(infinite) | | | +--:(infinite)
| | | | +--rw no-end-time? empty | | | | +--rw no-end-time? empty
| | | +--:(duration) | | | +--:(duration)
| | | | +--rw duration? uint32 | | | | +--rw duration? uint32
| | | +--:(end-date-time) | | | +--:(end-date-time)
| | | +--rw end-date-time? | | | +--rw end-date-time?
| | | yang:date-and-time | | | yang:date-and-time
| | +--:(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? yang:date-and-time | | | +--rw start-date-time? yang:date-and-time
| | | +--rw (end-time)? | | | +--rw (end-time)?
| | | +--:(infinite) | | | +--:(infinite)
| | | | +--rw no-end-time? empty | | | | +--rw no-end-time? empty
| | | +--:(duration) | | | +--:(duration)
| | | | +--rw duration? uint32 | | | | +--rw duration? uint32
| | | +--:(end-date-time) | | | +--:(end-date-time)
| | | +--rw end-date-time? | | | +--rw end-date-time?
| | | yang:date-and-time | | | yang:date-and-time
| | +--rw 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? yang:date-and-time | | +--rw start-date-time? yang:date-and-time
| | +--rw (end-time)? | | +--rw (end-time)?
| | +--:(infinite) | | +--:(infinite)
| | | +--rw no-end-time? empty | | | +--rw no-end-time? empty
| | +--:(duration) | | +--:(duration)
skipping to change at page 8, line 30 skipping to change at page 8, line 32
| | +--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
+--rw aes-key-wrap {aes-key-wrap}? +--rw aes-key-wrap {aes-key-wrap}?
| +--rw enable? boolean | +--rw enable? boolean
+--ro aes-key-wrap-state {aes-key-wrap}? +--ro aes-key-wrap-state {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-06-28.yang" <CODE BEGINS> file "ietf-key-chain@2016-08-17.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";
} }
organization organization
skipping to change at page 9, line 15 skipping to change at page 9, line 17
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 2016-06-28 { revision 2016-08-17 {
description
"Add description and last-modified timestamp leaves.";
reference
"RFC XXXX: A YANG Data Model for key-chain";
}
revision 2016-07-01 {
description description
"Rename module back to ietf-key-chain. "Rename module back to ietf-key-chain.
Added replay-protection-only feature and algorithm."; Added replay-protection-only feature and algorithm.";
reference reference
"RFC XXXX: A YANG Data Model for key-chain"; "RFC XXXX: A YANG Data Model for key-chain";
} }
revision 2016-03-15 { revision 2016-03-15 {
description description
"Rename module from ietf-key-chain to "Rename module from ietf-key-chain to
ietf-routing-key-chain."; ietf-routing-key-chain.";
skipping to change at page 9, line 43 skipping to change at page 9, line 51
reference reference
"RFC XXXX: A YANG Data Model for key-chain"; "RFC XXXX: A YANG Data Model for key-chain";
} }
revision 2015-10-15 { revision 2015-10-15 {
description description
"Updated version, organization, and copyright. "Updated version, organization, and copyright.
Added aes-cmac-prf-128 and aes-key-wrap features."; Added aes-cmac-prf-128 and aes-key-wrap features.";
reference reference
"RFC XXXX: A YANG Data Model for key-chain"; "RFC XXXX: A YANG Data Model for key-chain";
} }
revision 2015-06-28 { revision 2015-06-29 {
description description
"Updated version. Added Operation State following "Updated version. Added Operation State following
draft-openconfig-netmod-opstate-00."; draft-openconfig-netmod-opstate-00.";
reference reference
"RFC XXXX: A YANG Data Model for key-chain"; "RFC XXXX: A YANG Data Model for key-chain";
} }
revision 2015-02-24 { revision 2015-02-24 {
description description
"Initial revision."; "Initial revision.";
reference reference
skipping to change at page 14, line 13 skipping to change at page 14, line 21
type string; type string;
description "Name of the key-chain."; description "Name of the key-chain.";
} }
leaf name-state { leaf name-state {
type string; type string;
config false; config false;
description "Configured name of the key-chain."; description "Configured name of the key-chain.";
} }
leaf description {
type string;
description "A description of the key-chain";
}
container accept-tolerance { container accept-tolerance {
if-feature accept-tolerance; if-feature accept-tolerance;
description description
"Tolerance for key lifetime acceptance (seconds)."; "Tolerance for key lifetime acceptance (seconds).";
leaf duration { leaf duration {
type uint32; type uint32;
units seconds; units seconds;
default "0"; default "0";
description description
"Tolerance range, in seconds."; "Tolerance range, in seconds.";
skipping to change at page 14, line 38 skipping to change at page 14, line 51
description description
"Configured tolerance for key lifetime "Configured tolerance for key lifetime
acceptance (seconds)."; acceptance (seconds).";
leaf duration { leaf duration {
type uint32; type uint32;
description description
"Configured tolerance range, in seconds."; "Configured tolerance range, in seconds.";
} }
} }
leaf last-modified-timestamp {
type yang:date-and-time;
config false;
description "Timestamp of the most recent update
to the key-chain";
}
list key-chain-entry { list key-chain-entry {
key "key-id"; key "key-id";
description "One key."; description "One key.";
leaf key-id { leaf key-id {
type uint64; type uint64;
description "Key ID."; description "Key ID.";
} }
leaf key-id-state { leaf key-id-state {
type uint64; type uint64;
config false; config false;
 End of changes. 19 change blocks. 
22 lines changed or deleted 42 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/