YANG Data Model for a "Keystore" MechanismJuniper Networkskwatsen@juniper.net
Operations
NETCONF Working GroupThis document defines a YANG module called a "keystore",
containing pinned certificates and pinned SSH host-keys.
The module also defines a grouping for configuring
public key pairs and a grouping for configuring
certificates. The module also defines a notification
that a system can use when one of its configured
certificates is about to expire. This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
VVVV --> the assigned RFC value for this draftArtwork in this document contains placeholder values for the date of publication of this
draft. Please apply the following replacement:
2017-10-30 --> the publication date of this draftThe following Appendix section is to be removed prior to publication:
Appendix A. Change LogThis document defines a YANG module
for a system-level mechanism, herein called a "keystore". The
keystore provides a centralized location for security sensitive
data, as described below.This module has the following characteristics:
A 'grouping' for a public/private key pair, and an 'action' for requesting
the system to generate a new private key.A 'grouping' for a list of certificates that might be associated with a
public/private key pair, and an 'action' the requesting a system to generate
a certificate signing request.An unordered list of pinned certificate sets, where each pinned certificate set
contains an unordered list of pinned certificates. This structure enables a server
to use specific sets of pinned certificates on a case-by-case basis. For instance,
one set of pinned certificates might be used by an HTTPS-client when connecting
to particular HTTPS servers, while another set of pinned certificates might be
used by a server when authenticating client connections (e.g., certificate-based
client authentication).An unordered list of pinned SSH host key sets, where each pinned SSH host key
set contains an unordered list of pinned SSH host keys. This structure enables a server
to use specific sets of pinned SSH host-keys on a case-by-case basis. For
instance, SSH clients can be configured to use different sets of pinned SSH host
keys when connecting to different SSH servers.A notification to indicate when a certificate is about to expire.Special consideration has been given for systems that have
Trusted Protection Modules (TPMs). These systems are unique in
that the TPM must be directed to generate new keys (it is
not possible to load a key into a TPM) and it is not
possible to backup/restore the TPM's private keys as configuration.It is not required that a system has an operating system level
keystore utility to implement this module.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.The following tree diagram
provides an overview of the data model for the "ietf-keystore" module.The following example illustrates what a configured keystore
might look like.The following example illustrates the "certificate-expiration"
notification in use with the NETCONF protocol.The following example module has been constructed to illustrate
the groupings defined in the "ietf-keystore" module.The following example illustrates what a configured key
might look like. This example uses the "ex-keystore-usage"
module above.The following example illustrates the "generate-certificate-signing-request"
action in use with the NETCONF protocol. This example uses the "ex-keystore-usage"
module above.The following example illustrates the "generate-private-key" action
in use with the NETCONF protocol. This example uses the "ex-keystore-usage"
module above.This YANG module imports modules defined in
and . This module uses data types defined in
, , ,
, , ,
and . This module uses algorithms defined in
and .The YANG module defined in this document is designed to be accessed via YANG
based management protocols, such as NETCONF and
RESTCONF . Both of these protocols have mandatory-to-implement
secure transport layers (e.g., SSH, TLS) with mutual authentication.The NETCONF access control model (NACM) provides the means
to restrict access for particular users to a pre-configured subset of all available
protocol operations and content.There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). These data
nodes may be considered sensitive or vulnerable in some network environments. Write
operations (e.g., edit-config) to these data nodes without proper protection can
have a negative effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
The entire data tree defined by this module is sensitive to
write operations. For instance, the addition or removal of keys, certificates,
trusted anchors, etc., can dramatically alter the implemented security policy.
This being the case, the top-level node in this module is marked with the NACM
value 'default-deny-write'.When writing this node,
implementations MUST ensure that the strength of the key being configured
is not greater than the strength of the underlying secure transport
connection over which it is communicated. Implementations SHOULD fail the
write-request if ever the strength of the private key is greater then
the strength of the underlying transport, and alert the client that the
strength of the key may have been compromised. Additionally, when deleting
this node, implementations SHOULD automatically (without explicit request)
zeroize these keys in the most secure manner available, so as to prevent
the remnants of their persisted storage locations from being analyzed in
any meaningful way.Some of the readable data nodes in this YANG module may be considered sensitive
or vulnerable in some network environments. It is thus important to control read
access (e.g., via get, get-config, or notification) to these data nodes. These are
the subtrees and data nodes and their sensitivity/vulnerability:
This node is additionally
sensitive to read operations such that, in normal use cases, it should never
be returned to a client. The best reason for returning this node is to support
backup/restore type workflows. This being the case, this node is marked
with the NACM value 'default-deny-all'.Some of the operations in this YANG module may be considered sensitive or
vulnerable in some network environments. It is thus important to control access
to these operations. These are the operations and their sensitivity/vulnerability:
For this action,
it is RECOMMENDED that implementations assert channel binding ,
so as to ensure that the application layer that sent the request is the same
as the device authenticated when the secure transport layer was established.This document registers one URI in the IETF XML
registry . Following the format in
, the following registration is
requested:This document registers one YANG module in the
YANG Module Names registry .
Following the format in , the
the following registration is requested:The authors would like to thank for following for
lively discussions on list and in the halls (ordered
by last name): Andy Bierman, Martin Bjorklund, Benoit Claise,
Mehmet Ersue, Balázs Kovács, David Lamparter, Alan Luchuk, Ladislav Lhotka,
Radek Krejci, Tom Petch, Juergen Schoenwaelder; Phil Shafer,
Sean Turner, and Bert Wijnen.IEEE Standard for Local and metropolitan area networks - Secure Device IdentityIEEE SA-Standards BoardReplaced the 'certificate-chain' structures with PKCS#7 structures.
(Issue #1)Added 'private-key' as a configurable data node, and removed the
'generate-private-key' and 'load-private-key' actions. (Issue #2)Moved 'user-auth-credentials' to the ietf-ssh-client module.
(Issues #4 and #5)Added back 'generate-private-key' action.Removed 'RESTRICTED' enum from the 'private-key' leaf type.Fixed up a few description statements.Changed draft's title.Added missing references.Collapsed sections and levels.Added RFC 8174 to Requirements Language Section.Renamed 'trusted-certificates' to 'pinned-certificates'.Changed 'public-key' from config false to config true.Switched 'host-key' from OneAsymmetricKey to definition from RFC 4253.Added typedefs around leafrefs to common keystore pathsNow tree diagrams reference ietf-netmod-yang-tree-diagramsRemoved Design Considerations sectionMoved key and certificate definitions from data tree to groupings