RFC 8177
YANG Data Model for Key Chains
RFC 8177: YANG Data Model for Key Chains 🎀
Okay bestie, RFC 8177 is the IETF spec for a YANG data model for key chains, and it's giving very organized. The header says it's a Standards Track document (ISSN 2070-1721) dated June 2017. The authors are A. Lindem (editor, Cisco Systems), Y. Qu (Huawei), D. Yeung (Arrcus, Inc), I. Chen (Jabil), and J. Zhang (Juniper Networks). The header doesn't list anything it obsoletes or updates, so it's a clean slate 🧚
Abstract ✨
This doc describes the key chain YANG model 💖 Key chains are used a lot for routing protocol authentication and other stuff that needs symmetric keys. A key chain is a list of one or more elements, and each element has a Key ID, a key string, send/accept lifetimes, and the authentication or encryption algorithm it goes with. If you overlap the send and accept lifetimes of several elements properly, you can update key strings and algorithms gracefully, no drama. And since it's all represented in a YANG data model, key distribution can be automated 🤖✨
Status of This Memo 🌸
This is an Internet Standards Track document.
This doc is a product of the Internet Engineering Task Force (IETF), so it represents IETF community consensus. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 📚
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8177.
Copyright Notice 💜
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🦋
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Graceful Key Rollover Using Key Chains . . . . . . . . . 4
3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5
3.1. Key Chain Operational State . . . . . . . . . . . . . . . 6
3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6
3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 7
4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Simple Key Chain with an Always Valid Single Key . . . . 21
A.2. Key Chain with Keys Having Different Lifetimes . . . . . 21
A.3. Key Chain with Independent Send and Accept Lifetimes . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 251. Introduction ✨
Okay so this doc describes the key chain YANG [YANG-1.1] data model. Key chains are commonly used for routing protocol authentication and other apps that need symmetric keys 🔑 A key chain is a list of one or more elements, and each element holds a Key ID, a key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple elements, key strings and algorithms can be gracefully updated. And representing all of this in a YANG data model means key distribution can be automated 🤖
In some applications, the protocols don't use the key chain element key directly. Instead, a key derivation function derives a short-lived key from the key chain element key, like the master keys used in [TCP-AO] 🧁
1.1. Requirements Notation
Here's the key word rule 📖 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [KEYWORDS] [KEYWORDS-UPD], but only when they show up in all capitals, like they do here 💅
1.2. Tree Diagrams
The complete data tree gets a simplified picture in Section 3.3, and here's how the tree notation works 🌳
- Brackets
[and]enclose YANG list keys. Don't mix these up with the key chain keys. - Curly braces
{and}hold the names of optional features that make the matching node conditional. - Abbreviations go before data node names:
rwmeans configuration (read-write),romeans state data (read-only),-xmeans RPC operations, and-nmeans notifications. - Symbols go after data node names:
?means an optional node,!means a container with presence, and*means a "list" or "leaf-list". - Parentheses enclose choice and case nodes, and case nodes also get a colon (
:). - An ellipsis (
...) stands for the contents of subtrees that aren't shown.
2. Problem Statement 🔥
This doc describes a YANG [YANG-1.1] data model for key chains. Key chains have already been implemented and deployed by a big chunk of network equipment vendors 🏆 Having a standard YANG model makes automated key distribution and non-disruptive key rollover way easier. That helps tighten the security of the core routing infrastructure, as [IAB-REPORT] recommends 🛡️
A key chain is a list of one or more elements, and each element has a Key ID, a key string, send/accept lifetimes, and the associated authentication or encryption algorithm. Any service or application that needs authentication or encryption with symmetric keys can use a key chain. Basically, the key chain is a reusable key policy you can reference wherever you need it. Most networking vendors have implemented the construct, and plenty of networks have deployed it 🌈
A conceptual version of a crypto key table is described in [CRYPTO-KEYTABLE]. That table holds keys, their lifetimes, and their algorithms. It also has key selection criteria, and it's built for a deployment model where the details of the apps or services that need authentication or encryption seep right into the key database 🧠 The YANG key chain model in this document doesn't include key selection criteria or support that deployment model. It doesn't rule it out either. [YANG-CRYPTO-KEYTABLE] describes augmentations to the key chain YANG model that add key selection criteria 💜
2.1. Applicability
Other YANG modules can reference ietf-key-chain YANG module key-chain names for authentication and encryption apps. There's a YANG type made just for this, so you don't have to write out the full YANG XML Path Language (XPath) expression every time 🧚
2.2. Graceful Key Rollover Using Key Chains
Key chains can gracefully update the key string and/or algorithm an application uses for authentication or encryption 🦋 For a graceful rollover, the receiver MAY accept all the keys that have a valid accept lifetime, and the sender MAY send the key with the most recent send lifetime. Here's one scenario for making a rollover happen:
- Distribute a key chain with a new key to all the routers or other network devices in that key chain's domain. The new key's accept lifetime should be set so it gets accepted during the rollover period. The send lifetime should be a time in the future, when you can be sure every router in the key's domain has been upgraded. This has no immediate impact on the keys used for transmission 📦
- Make sure all the network devices have the updated key chain and that their system times are roughly synchronized. Devices within an administrative domain are commonly synchronized, for example with the Network Time Protocol (NTP) [NTP-PROTO]. This step can also be automated ⏰
- When the send lifetime of the new key becomes valid, the network devices in that key chain's domain start using the new key for transmissions 🚀
- At some point later, a new key chain with the old key removed can be distributed to the network devices in the domain. This can also wait until the next rollover. If you do it this way, the key chain always includes two keys: either the current and future keys (during rollovers) or the current and previous keys (between rollovers) 👑
Since the most recent send lifetime is defined as the one with the latest start-time, specifying "always" will stop you from using the graceful key rollover technique described above 🙈 Other key configuration and usage scenarios are possible, but they're beyond the scope of this document.
- Design of the Key Chain Model ✨
okay so the ietf-key-chain module holds a list of one or more keys, and each one is indexed by a Key ID 🔑 bestie. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the Key ID is the thing that tells you which key chain key to use 🫶 Along with the Key ID, every key chain key has a key string and a cryptographic algorithm 💅 Send/accept lifetimes are optional, and if you don't set a send/accept lifetime, the key is always considered valid ✨
Note that different key values for transmission versus acceptance can be supported with multiple key chain elements 🦋 The key used for transmission has a valid send-lifetime and an invalid accept-lifetime (e.g., it has an end-time equal to the start-time) 🌸 The key used for acceptance has a valid accept-lifetime and an invalid send-lifetime 💜
Vendors do key chains differently, so some of the data elements are optional 🙈 And the crypto algorithm identities are provided so you can reuse them when you configure legacy authentication and encryption that doesn't use key chains 🎀
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 YANG modules when they need to reference a configured key chain 💖
3.1. Key Chain Operational State 🌈
The key chain operational state lives in the same tree as the key chain configuration, consistent with the Network Management Datastore Architecture [NMDA] 🍓 The timestamp of the last key chain modification is also kept in the operational state 💅 On top of that, the operational state shows whether or not a key chain key is valid for transmission or acceptance 👑
3.2. Key Chain Model Features ✨
Features are how we handle differences between vendor implementations 🦋 For example, not all vendors support configuring an acceptance tolerance or configuring key strings in hexadecimal 🙈 Features are also used to support security requirements (e.g., TCP-AO algorithms [TCP-AO-ALGORITHMS]) that vendors haven't implemented yet, or that only a single vendor has implemented 💀
It's super common for an entity with sufficient permissions to read and store a device's configuration, and that would include the contents of this model 😭 To avoid unnecessarily seeing and storing the keys in cleartext, this model provides the aes-key-wrap feature 🔥 More details are in the Security Considerations (Section 5) 🫶
3.3. Key Chain Model Tree 🎀
Here's the whole tree, bestie 💅
+--rw key-chains
+--rw key-chain* [name]
| +--rw name string
| +--rw description? string
| +--rw accept-tolerance {accept-tolerance}?
| | +--rw duration? uint32
| +--ro last-modified-timestamp? yang:date-and-time
| +--rw key* [key-id]
| +--rw key-id uint64
| +--rw lifetime
| | +--rw (lifetime)?
| | +--:(send-and-accept-lifetime)
| | | +--rw send-accept-lifetime
| | | +--rw (lifetime)?
| | | +--:(always)
| | | | +--rw always? empty
| | | +--:(start-end-time)
| | | +--rw start-date-time?
| | | | yang:date-and-time
| | | +--rw (end-time)?
| | | +--:(infinite)
| | | | +--rw no-end-time? empty
| | | +--:(duration)
| | | | +--rw duration? uint32
| | | +--:(end-date-time)
| | | +--rw end-date-time?
| | | yang:date-and-time
| | +--:(independent-send-accept-lifetime)
| | | {independent-send-accept-lifetime}?
| | +--rw send-lifetime
| | | +--rw (lifetime)?
| | | +--:(always)
| | | | +--rw always? empty
| | | +--:(start-end-time)
| | | +--rw start-date-time?
| | | | yang:date-and-time
| | | +--rw (end-time)?
| | | +--:(infinite)
| | | | +--rw no-end-time? empty
| | | +--:(duration)
| | | | +--rw duration? uint32
| | | +--:(end-date-time)
| | | +--rw end-date-time?
| | | yang:date-and-time
| | +--rw accept-lifetime
| | +--rw (lifetime)?
| | +--:(always)
| | | +--rw always? empty
| | +--:(start-end-time)
| | +--rw start-date-time?
| | | yang:date-and-time
| | +--rw (end-time)?
| | +--:(infinite)
| | | +--rw no-end-time? empty
| | +--:(duration)
| | | +--rw duration? uint32
| | +--:(end-date-time)
| | +--rw end-date-time?
| | yang:date-and-time
| +--rw crypto-algorithm identityref
| +--rw key-string
| | +--rw (key-string-style)?
| | +--:(keystring)
| | | +--rw keystring? string
| | +--:(hexadecimal) {hex-key-string}?
| | +--rw hexadecimal-string? yang:hex-string
| +--ro send-lifetime-active? boolean
| +--ro accept-lifetime-active? boolean
+--rw aes-key-wrap {aes-key-wrap}?
+--rw enable? boolean4. Key Chain YANG Model ✨
okay bestie, this is the good part 💅 Section 4 is the actual YANG module, the machine-readable blueprint for key chains. YANG is the data modeling language, so this file says exactly what a key chain config looks like: the names, the keys, the lifetimes, the algorithms, all of it. The module is named ietf-key-chain and it's revision 2017-06-15 🎀 It's giving "generic starter kit," because the description says vendors are meant to extend it with their own parameters 🌸
Here's the whole module, copied exactly as written 🫶
<CODE BEGINS> file "ietf-key-chain@2017-06-15.yang"
module ietf-key-chain {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";
prefix key-chain;
import ietf-yang-types {
prefix yang;
}
import ietf-netconf-acm {
prefix nacm;
}
organization
"IETF RTGWG - Routing Area Working Group";
contact
"WG Web: <https://datatracker.ietf.org/group/rtgwg>
WG List: <mailto:rtgwg@ietf.org>
Editor: Acee Lindem
<mailto:acee@cisco.com>
Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>
Derek Yeung
<mailto:derek@arrcus.com>
Ing-Wher Chen
<mailto:Ing-Wher_Chen@jabail.com>
Jeffrey Zhang
<mailto:zzhang@juniper.net>";
description
"This YANG module defines the generic configuration
data for key chains. It is intended that the module
will be extended by vendors to define vendor-specific
key chain configuration parameters.
Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8177;
see the RFC itself for full legal notices.";
reference "RFC 8177";
revision 2017-06-15 {
description
"Initial RFC Revision";
reference "RFC 8177: YANG Data Model for Key Chains";
}
feature hex-key-string {
description
"Support hexadecimal key string.";
}
feature accept-tolerance {
description
"Support the tolerance or acceptance limit.";
}
feature independent-send-accept-lifetime {
description
"Support for independent send and accept key lifetimes.";
}
feature crypto-hmac-sha-1-12 {
description
"Support for TCP HMAC-SHA-1 12-byte digest hack.";
}
feature cleartext {
description
"Support for cleartext algorithm. Usage is
NOT RECOMMENDED.";
}
feature aes-cmac-prf-128 {
description
"Support for AES Cipher-based Message Authentication
Code Pseudorandom Function.";
}
feature aes-key-wrap {
description
"Support for Advanced Encryption Standard (AES) Key Wrap.";
}
feature replay-protection-only {
description
"Provide replay protection without any authentication
as required by protocols such as Bidirectional
Forwarding Detection (BFD).";
}
identity crypto-algorithm {
description
"Base identity of cryptographic algorithm options.";
}
identity hmac-sha-1-12 {
base crypto-algorithm;
if-feature "crypto-hmac-sha-1-12";
description
"The HMAC-SHA1-12 algorithm.";
}
identity aes-cmac-prf-128 {
base crypto-algorithm;
if-feature "aes-cmac-prf-128";
description
"The AES-CMAC-PRF-128 algorithm - required by
RFC 5926 for TCP-AO key derivation functions.";
}
identity md5 {
base crypto-algorithm;
description
"The MD5 algorithm.";
}
identity sha-1 {
base crypto-algorithm;
description
"The SHA-1 algorithm.";
}
identity hmac-sha-1 {
base crypto-algorithm;
description
"HMAC-SHA-1 authentication algorithm.";
}
identity hmac-sha-256 {
base crypto-algorithm;
description
"HMAC-SHA-256 authentication algorithm.";
}
identity hmac-sha-384 {
base crypto-algorithm;
description
"HMAC-SHA-384 authentication algorithm.";
}
identity hmac-sha-512 {
base crypto-algorithm;
description
"HMAC-SHA-512 authentication algorithm.";
}
identity cleartext {
base crypto-algorithm;
if-feature "cleartext";
description
"cleartext.";
}
identity replay-protection-only {
base crypto-algorithm;
if-feature "replay-protection-only";
description
"Provide replay protection without any authentication as
required by protocols such as Bidirectional Forwarding
Detection (BFD).";
}
typedef key-chain-ref {
type leafref {
path
"/key-chain:key-chains/key-chain:key-chain/key-chain:name";
}
description
"This type is used by data models that need to reference
configured key chains.";
}
grouping lifetime {
description
"Key lifetime specification.";
choice lifetime {
default "always";
description
"Options for specifying key accept or send lifetimes";
case always {
leaf always {
type empty;
description
"Indicates key lifetime is always valid.";
}
}
case start-end-time {
leaf start-date-time {
type yang:date-and-time;
description
"Start time.";
}
choice end-time {
default "infinite";
description
"End-time setting.";
case infinite {
leaf no-end-time {
type empty;
description
"Indicates key lifetime end-time is infinite.";
}
}
case duration {
leaf duration {
type uint32 {
range "1..2147483646";
}
units "seconds";
description
"Key lifetime duration, in seconds";
}
}
case end-date-time {
leaf end-date-time {
type yang:date-and-time;
description
"End time.";
}
}
}
}
}
}
container key-chains {
description
"All configured key-chains on the device.";
list key-chain {
key "name";
description
"List of key-chains.";
leaf name {
type string;
description
"Name of the key-chain.";
}
leaf description {
type string;
description
"A description of the key-chain";
}
container accept-tolerance {
if-feature "accept-tolerance";
description
"Tolerance for key lifetime acceptance (seconds).";
leaf duration {
type uint32;
units "seconds";
default "0";
description
"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 {
key "key-id";
description
"Single key in key chain.";
leaf key-id {
type uint64;
description
"Numeric value uniquely identifying the key";
}
container lifetime {
description
"Specify a key's lifetime.";
choice lifetime {
description
"Options for specification of send and accept
lifetimes.";
case send-and-accept-lifetime {
description
"Send and accept key have the same lifetime.";
container send-accept-lifetime {
description
"Single lifetime specification for both
send and accept lifetimes.";
uses lifetime;
}
}
case independent-send-accept-lifetime {
if-feature "independent-send-accept-lifetime";
description
"Independent send and accept key lifetimes.";
container send-lifetime {
description
"Separate lifetime specification for send
lifetime.";
uses lifetime;
}
container accept-lifetime {
description
"Separate lifetime specification for accept
lifetime.";
uses lifetime;
}
}
}
}
leaf crypto-algorithm {
type identityref {
base crypto-algorithm;
}
mandatory true;
description
"Cryptographic algorithm associated with key.";
}
container key-string {
description
"The key string.";
nacm:default-deny-all;
choice key-string-style {
description
"Key string styles";
case keystring {
leaf keystring {
type string;
description
"Key string in ASCII format.";
}
}
case hexadecimal {
if-feature "hex-key-string";
leaf hexadecimal-string {
type yang:hex-string;
description
"Key in hexadecimal string format. When compared
to ASCII, specification in hexadecimal affords
greater key entropy with the same number of
internal key-string octets. Additionally, it
discourages usage of well-known words or
numbers.";
}
}
}
}
leaf send-lifetime-active {
type boolean;
config false;
description
"Indicates if the send lifetime of the
key-chain key is currently active.";
}
leaf accept-lifetime-active {
type boolean;
config false;
description
"Indicates if the accept lifetime of the
key-chain key is currently active.";
}
}
}
container aes-key-wrap {
if-feature "aes-key-wrap";
description
"AES Key Wrap encryption for key-chain key-strings. The
encrypted key-strings are encoded as hexadecimal key
strings using the hex-key-string leaf.";
leaf enable {
type boolean;
default "false";
description
"Enable AES Key Wrap encryption.";
}
}
}
}
<CODE ENDS>5. Security Considerations 🔐
Okay bestie, this part is serious business, so let's gooo 💅 The YANG module in this document is built to be accessed through network management protocols like NETCONF [NETCONF] or RESTCONF [RESTCONF]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [NETCONF-SSH]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [TLS] 🔒
The NETCONF access control model [NETCONF-ACM] is the bouncer 🚪 It lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of all the available NETCONF or RESTCONF protocol operations and content. The key strings are not accessible by default, so you need NETCONF access control model [NETCONF-ACM] rules before you can configure or retrieve them. No peeking, periodt 🙈
Now, encryption. When it's 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, so it has to be set or derived independently of the key chain configuration. When AES key encryption is used, the hex-key-string feature is also required, because the encrypted keys contain characters that aren't representable in the YANG string built-in type [YANG-1.1]. It is RECOMMENDED that key strings be encrypted using AES key encryption, so key chains aren't retrieved and stored with the key strings in cleartext. This recommendation is separate from the access protection provided by the NETCONF access control model (NACM) [NETCONF-ACM], so you get both layers 🧁
⚠️ Cleartext is the spicy one. The cleartext algorithm is included as a YANG feature. Usage is NOT RECOMMENDED, except where the application and device have no other alternative. Think of a legacy network device that must authenticate packets at intervals of 10 milliseconds or less for many peers using Bidirectional Forwarding Detection [BFD]. Keys used with the cleartext algorithm are considered insecure and SHOULD NOT be reused with more secure algorithms. Don't recycle a cleartext key into your good algorithms, it's giving danger 💀
The MD5 and SHA-1 algorithms have also been proven to be insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]), so usage is NOT RECOMMENDED 🙅♀️ Usage should be confined to deployments where it is required for backward compatibility, and nowhere else.
Last but not least, implementations with keys provided via this model should store them using best current security practices. Keep those keys locked up tight 🔐✨
6. IANA Considerations 🌸
This document registers a URI in the "IETF XML Registry" [XML-REGISTRY]. It follows the format in [XML-REGISTRY]. Here's the entry:
URI: urn:ietf:params:xml:ns:yang:ietf-key-chain
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.This document also registers a YANG module in the "YANG Module Names" registry [YANG-1.0]. The entry looks like this:
name: ietf-key-chain
namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain
prefix: key-chain
reference: RFC 81777. References 📚
Every single source the document leans on lives here, so let's line them up 🧚
7.1. Normative References
These are the ones you really need to read to get the full picture 💜
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[KEYWORDS-UPD]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[NETCONF] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[NETCONF-ACM]
Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>.
[NETCONF-SSH]
Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<http://www.rfc-editor.org/info/rfc6242>.
[RESTCONF]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[XML-REGISTRY]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[YANG-1.0]
Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[YANG-1.1]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>.7.2. Informative References
These are the extra-credit reads that give you more background 🦋
[AES-KEY-WRAP]
Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009,
<http://www.rfc-editor.org/info/rfc5649>.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
[CRYPTO-KEYTABLE]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
RFC 7210, DOI 10.17487/RFC7210, April 2014,
<http://www.rfc-editor.org/info/rfc7210>.
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical
Report Presented at the Rump Session of EuroCrypt '96, May
1996.
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol. 2, No. 2, Summer 1996.
[IAB-REPORT]
Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, DOI 10.17487/RFC4948, August 2007,
<http://www.rfc-editor.org/info/rfc4948>.
[NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore
Architecture", Work in Progress, draft-ietf-netmod-
revised-datastores-02, May 2017.
[NTP-PROTO]
Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[OSPFV3-AUTH]
Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<http://www.rfc-editor.org/info/rfc7166>.
[SHA-SEC-CON]
Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>.
[TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[TCP-AO-ALGORITHMS]
Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926,
DOI 10.17487/RFC5926, June 2010,
<http://www.rfc-editor.org/info/rfc5926>.
[YANG-CRYPTO-KEYTABLE]
Chen, I., "YANG Data Model for RFC 7210 Key Table", Work
in Progress, draft-chen-rtg-key-table-yang-00, March 2015.Appendix A. Examples 🧁
Time for the fun part, the examples! These show what the XML looks like in action 🎀
A.1. Simple Key Chain with an Always Valid Single Key
This one is a key chain with a single key that's always valid for transmission and reception. Super chill, no expiry drama ✨
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
<key-chain>
<name>keychain-no-end-time</name>
<description>
A key chain with a single key that is always valid for
transmission and reception.
</description>
<key>
<key-id>100</key-id>
<lifetime>
<send-accept-lifetime>
<always/>
</send-accept-lifetime>
</lifetime>
<crypto-algorithm>hmac-sha-256</crypto-algorithm>
<key-string>
<keystring>keystring_in_ascii_100</keystring>
</key-string>
</key>
</key-chain>
</key-chains>
</data>A.2. Key Chain with Keys Having Different Lifetimes
Now we're getting into the glow-up era 🦋 This key chain has keys that each get their own send time and accept time, plus different algorithms, which shows off algorithm agility. Literal main character energy 👑
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
<key-chain>
<name>keychain2</name>
<description>
A key chain where each key contains a different send time
and accept time and a different algorithm illustrating
algorithm agility.
</description>
<key>
<key-id>35</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2017-01-01T00:00:00Z</start-date-time>
<end-date-time>2017-02-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2016-12-31T23:59:55Z</start-date-time>
<end-date-time>2017-02-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>hmac-sha-256</crypto-algorithm>
<key-string>
<keystring>keystring_in_ascii_35</keystring>
</key-string>
</key>
<key>
<key-id>36</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2017-02-01T00:00:00Z</start-date-time>
<end-date-time>2017-03-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2017-01-31T23:59:55Z</start-date-time>
<end-date-time>2017-03-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>hmac-sha-512</crypto-algorithm>
<key-string>
<hexadecimal-string>fe:ed:be:af:36</hexadecimal-string>
</key-string>
</key>
</key-chain>
</key-chains>
</data>A.3. Key Chain with Independent Send and Accept Lifetimes 🦋
Okay bestie, this last example is giving "two schedules, one key chain" 💅. Each key gets its own send window and its own accept window, and those windows don't have to line up. Here's the XML:
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
<key-chain>
<name>keychain2</name>
<description>
A key chain where each key contains different send times
and accept times.
</description>
<key>
<key-id>35</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2017-01-01T00:00:00Z</start-date-time>
<end-date-time>2017-02-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2016-12-31T23:59:55Z</start-date-time>
<end-date-time>2017-02-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>hmac-sha-256</crypto-algorithm>
<key-string>
<keystring>keystring_in_ascii_35</keystring>
</key-string>
</key>
<key>
<key-id>36</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2017-02-01T00:00:00Z</start-date-time>
<end-date-time>2017-03-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2017-01-31T23:59:55Z</start-date-time>
<end-date-time>2017-03-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>hmac-sha-256</crypto-algorithm>
<key-string>
<hexadecimal-string>fe:ed:be:af:36</hexadecimal-string>
</key-string>
</key>
</key-chain>
</key-chains>
</data>Look at key 35 and key 36 and you'll see the pattern ✨. Key 35 can be sent from 2017-01-01 until 2017-02-01, but it can be accepted a little earlier and a little later, from 2016-12-31T23:59:55Z until 2017-02-01T00:00:05Z. Key 36 does the same dance one month later 💖. Also notice that key 36 uses a hexadecimal key string, while key 35 uses an ASCII one. Two keys, two vibes 🌈.
Contributors 🎀
Yi Yang SockRate
Email: yi.yang@sockrate.com
Acknowledgments 🫶
Thanks to Brian Weis for fruitful discussions on security requirements 🔐.
Thanks to Ines Robles for Routing Directorate QA review comments 🌸.
Thanks to Ladislav Lhotka for YANG Doctor comments 📝.
Thanks to Martin Bjorklund for additional YANG Doctor comments 📝.
Thanks to Tom Petch for comments during IETF last call 📣.
Thanks to Matthew Miller for comments made during the Gen-ART review 💜.
Thanks to Vincent Roca for comments made during the Security Directorate review 🛡️.
Thanks to Warren Kumari, Ben Campbell, Adam Roach, and Benoit Claise for comments received during the IESG review 👑.
Authors' Addresses 💌
Acee Lindem (editor)
Cisco Systems
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee@cisco.com
Yingzhen Qu
Huawei
Email: yingzhen.qu@huawei.com
Derek Yeung
Arrcus, Inc
Email: derek@arrcus.com
Ing-Wher Chen
Jabil
Email: Ing-Wher_Chen@jabil.com
Jeffrey Zhang
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: zzhang@juniper.netThat's the whole spec, bestie!! 🌈✨ Every key, every window, every name is exactly where the authors put it, and the team that made this is iconic 👑💅🦋
📦 where this page comes from
- ietf: rfc8177 2017-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms