YANG Data Model for Key ChainsCisco Systems301 Midenhall WayCaryNCUnited States of America27513acee@cisco.comHuaweiyingzhen.qu@huawei.comArrcus, Incderek@arrcus.comJabilIng-Wher_Chen@jabil.comJuniper Networks10 Technology Park DriveWestfordMAUnited States of America01886zzhang@juniper.netThis document describes the key chain YANG data model.
Key chains are commonly used for routing protocol
authentication and other applications requiring symmetric keys.
A key chain is a list containing one or more elements containing a
Key ID, key string, send/accept lifetimes, and the associated
authentication or encryption algorithm. By properly overlapping the send and accept lifetimes
of multiple key chain elements, key strings and algorithms may be
gracefully updated. By representing them in a YANG data model, key
distribution can be automated.This document describes the key chain YANG
data model. Key chains are commonly used for routing protocol
authentication and other applications requiring symmetric keys.
A key chain is a list containing one or more elements containing a
Key ID, key string, send/accept lifetimes, and the associated
authentication or encryption algorithm.
By properly overlapping the send and accept lifetimes
of multiple key chain elements, key strings and algorithms may be
gracefully updated. By representing them in a YANG data model, key
distribution can be automated.In some applications, the protocols
do not use the key chain element key directly, but rather a key
derivation function is used to derive a short-lived key from the
key chain element key (e.g., the master keys
used in ).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.A simplified graphical representation of the complete data
tree is presented in . The
following tree notation is used.Brackets "[" and "]" enclose YANG list keys. These YANG list keys
should not be confused with the key chain keys.Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.Abbreviations before data node names: "rw" means configuration
(read-write), "ro" means state data (read-only), "-x" means RPC
operations, and "-n" means notifications.Symbols after data node names: "?" means an optional node, "!" denotes a
container with presence, and "*" denotes a "list" or "leaf-list".Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").Ellipsis ("...") stands for contents of subtrees that are not
shown.This document describes a YANG data model for key chains. Key chains
have been implemented and deployed by a large percentage of network equipment vendors. Providing
a standard YANG model will facilitate automated key distribution and non-disruptive key rollover.
This will aid in tightening the security of the core routing infrastructure as
recommended in . A key chain is a list containing one or more elements containing a Key ID,
key string, send/accept lifetimes, and the associated authentication or
encryption algorithm. A key chain can be used by any service or application
requiring authentication or encryption using symmetric keys.
In essence, the
key chain is a reusable key policy that can be referenced wherever it is required. The
key chain construct has been implemented by most networking vendors and deployed
in many networks.A conceptual representation of a crypto key table is described in
. The crypto key table includes keys as well
as their corresponding lifetimes and algorithms. Additionally, the
key table includes key selection criteria and is designed for a deployment
model where the details of the applications or services requiring
authentication or encryption permeate into the key database. The
YANG key chain model described herein doesn't include key selection criteria or
support this deployment model. At the same time, it does not preclude it.
describes augmentations to the key chain YANG
model in support of key selection criteria.Other YANG modules may reference ietf-key-chain YANG module key-chain names for authentication and
encryption applications. A YANG type has been provided to facilitate reference to the key-chain name
without having to specify the complete YANG XML Path Language (XPath) expression.Key chains may be used to gracefully update the key string and/or algorithm used by an application
for authentication or encryption. To achieve graceful key 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.
One scenario for facilitating key rollover is to:
Distribute a key chain with a new key to all the routers or other network devices in the domain of
that key chain. The new key's accept lifetime should be such that it is accepted during the key rollover period.
The send lifetime should be a time in the future when it can be assured that all the routers in the domain of
that key are upgraded. This will have no immediate impact on the keys used for transmission.Assure that all the network devices have been updated with the updated key chain and that their system
times are roughly synchronized. The system times of devices within an administrative domain are commonly
synchronized (e.g., using the Network Time Protocol (NTP) ). This also may be automated.When the send lifetime of the new key becomes valid, the network devices
within the domain of that
key chain will use the new key for transmissions.At some point in the future, a new key chain with the old key removed may be distributed to
the network devices within the domain of the key chain. However, this may be deferred until the next
key rollover. If this is done, the key chain will always include two keys: either the current and future key
(during key rollovers) or the current and previous keys (between key rollovers).Since the most recent send lifetime is defined as the one with the latest start-time,
specification of "always" will prevent using the graceful key rollover technique described above. Other
key configuration and usage scenarios are possible, but these are beyond the scope of this document.The ietf-key-chain module contains a list of one or more keys indexed by a Key ID. For some
applications (e.g., OSPFv3 ),
the Key ID is used to identify the key chain key to be used. In addition to the Key ID, each key chain
key includes a key string and a cryptographic algorithm.
Optionally, the key chain keys include send/accept lifetimes. If the send/accept lifetime is
unspecified, the key is always considered valid.Note that different key values for transmission versus acceptance may be supported with
multiple key chain elements. The key used for transmission will have a valid send-lifetime and invalid accept-lifetime
(e.g., has an end-time equal to the start-time). The key used for acceptance will have a valid accept-lifetime and
invalid send-lifetime.Due to the differences in key chain implementations across various vendors, some of the data elements are
optional. Finally, the crypto algorithm identities are provided for reuse when configuring
legacy authentication and encryption not using 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.The key chain operational state is included in the same tree as key chain configuration
consistent with Network Management Datastore Architecture .
The timestamp of the last key chain modification is also maintained in the operational state.
Additionally, the operational state includes an indication of whether or not a
key chain key is valid for transmission or acceptance.
Features are used to handle differences between vendor implementations. For example, not all vendors
support configuration of an acceptance tolerance or configuration of key strings in hexadecimal.
They are also used to support security requirements
(e.g., TCP-AO algorithms ) not yet implemented by
vendors or implemented by only a single vendor.
It is common for an entity with sufficient permissions to read and store a device's configuration,
which 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
described in the Security
Considerations ().The YANG module defined in this document is designed to be
accessed via network management protocols such as
NETCONF or RESTCONF .
The lowest NETCONF layer is the
secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) .
The lowest RESTCONF
layer is HTTPS, and the mandatory-to-implement secure transport is
TLS .The NETCONF access control model provides
the means to restrict access for particular NETCONF or RESTCONF users to a
pre-configured subset of all available NETCONF or RESTCONF
protocol operations and content. The key strings are not accessible by
default, and NETCONF access control model rules
are required to configure or retrieve them.When configured, the key strings can be encrypted using the AES Key
Wrap algorithm . The AES key-encryption key (KEK)
is not included in the YANG model and must be set or derived independent of
key chain configuration. When AES key encryption is used, the hex-key-string
feature is also required since the encrypted keys will contain
characters that are not representable in the YANG string built-in
type . It is RECOMMENDED that key strings be encrypted using
AES key encryption to prevent key chains from being retrieved
and stored with the key strings in cleartext. This recommendation is
independent of the access protection that is availed from the NETCONF access
control model (NACM) .The cleartext algorithm is included as a YANG feature. Usage is NOT RECOMMENDED
except in cases where the application and device have no other alternative
(e.g., a legacy network device that must authenticate packets at intervals of
10 milliseconds or less for many peers using Bidirectional Forwarding Detection
). Keys used with the
cleartext algorithm are considered insecure and SHOULD NOT be reused
with more secure algorithms.Similarly, the MD5 and SHA-1 algorithms have been proven to be insecure
(, , and ),
and usage is NOT RECOMMENDED. Usage should be confined to deployments
where it is required for backward compatibility.Implementations with keys provided via this model should store them
using best current security practices.This document registers a URI in the "IETF XML Registry"
. It follows the format in .
This document registers a YANG module in the "YANG Module Names"
registry .
RESTCONF ProtocolUsing the NETCONF Protocol over Secure Shell (SSH)Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF) Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]Database of Long-Lived Symmetric Cryptographic KeysThis document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.YANG Data Model for RFC 7210 Key TableThis document defines a YANG data model to describe the key table defined in RFC 7210. The data model defined in this document augments the existing key-chain model with additional key attributes specified in RFC 7210.The TCP Authentication OptionThis document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]Advanced Encryption Standard (AES) Key Wrap with Padding AlgorithmThis document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.Report from the IAB workshop on Unwanted Traffic March 9-10, 2006This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. This memo provides information for the Internet community.Supporting Authentication Trailer for OSPFv3Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.Network Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD)This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]Cryptanalysis of MD5 CompressThe Status of MD5 After a Recent AttackSecurity Considerations for the SHA-0 and SHA-1 Message-Digest AlgorithmsThis document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.Network Management Datastore ArchitectureTail-F SystemsJacobs UniversityJuniper NetworksJuniper NetworksCisco SystemsThanks 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.