Keystore ModelJuniper Networkskwatsen@juniper.net
Operations
NETCONF Working GroupThis document defines a YANG data module for a system-level keystore
mechanism, that might be used to hold onto private keys and certificates
that are trusted by the system advertising support for this module.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-06-13 --> the publication date of this draftThe following Appendix section is to be removed prior to publication:
Appendix A. Change LogThis document defines a YANG data module for
a system-level keystore mechanism, which can be used to hold onto
private keys and certificates that are trusted by the system advertising
support for this module.This module provides a centralized location for security sensitive
data, so that the data can be then referenced by other modules.
There are two types of data that are maintained by this module:
Private keys, and any associated public certificates.Sets of trusted certificates.This document extends special consideration for systems that have
Trusted Protection Modules (TPMs). These systems are unique in
that the TPM must be directed to generate new private keys (it is
not possible to load a private 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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 .A simplified graphical representation of the data models
is used in this document. The meaning of the symbols in
these diagrams is as follows:
Brackets "[" and "]" enclose list keys.Braces "{" and "}" enclose feature names, and indicate
that the named feature must be present for the subtree
to be present.Abbreviations before data node names: "rw" means
configuration (read-write) and "ro" state data
(read-only).Symbols after data node names: "?" means an optional
node, "!" means a presence container, and "*" denotes a
list and 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.The keystore module defined in this section provides a configurable
object having the following characteristics:
A semi-configurable list of private keys, each with one or more associated
certificates. Private keys MUST be either preinstalled (e.g., a key associated
to an IDevID certificate),
be generated by request, or be loaded by request. Each private key is MAY have
associated certificates, either preinstalled or configured after creation.A configurable list of lists of trust anchor certificates. This enables
the server to have use-case specific trust anchors. For instance, one list of
trust anchors might be used to authenticate management connections (e.g.,
client certificate-based authentication for NETCONF or RESTCONF connections),
and a different list of trust anchors might be used for when connecting to a
specific Internet-based service (e.g., a zero touch bootstrap server).An RPC to generate a certificate signing request for an existing private
key, a passed subject, and an optional attributes. The signed certificate
returned from an external certificate authority (CA) can be later set using
a standard configuration change request (e.g., <edit-config>).An RPC to request the server to generate a new private key using the
specified algorithm and key length.An RPC to request the server to load a new private key.The keystore module has the following tree diagram. Please see for information on how to interpret this diagram.
The following example illustrates what a fully configured keystore object
might look like. The private-key shown below is consistent with the
generate-private-key and generate-certificate-signing-request examples above.
This example also assumes that the resulting CA-signed certificate has been
configured back onto the server. Lastly, this example shows that three
lists of trusted certificates having been configured.The following example illustrates the "generate-certificate-signing-request"
action in use with the NETCONF protocol.The following example illustrates the "generate-private-key" action
in use with the RESTCONF protocol and JSON encoding.The following example illustrates a "certificate-expiration"
notification in XML.This YANG module makes extensive use of data types defined in
and .This document uses PKCS #10 for the
"generate-certificate-signing-request" action. The use of Certificate
Request Message Format (CRMF) was considered,
but is was unclear if there was market demand for it, and so support
for CRMF has been left out of this specification. If it is desired
to support CRMF in the future, placing a "choice" statement in both
the input and output statements, along with an "if-feature" statement
on the CRMF option, would enable a backwards compatible solution.This document puts a limit of the number of elliptical curves
supported by default. This was done to match industry trends in IETF best
practice (e.g., matching work being done in TLS 1.3). If additional
algorithms are needed, they MAY be augmented in by another module,
or added directly in a future version of this document.For the trusted-certificates list, Trust Anchor Format
was evaluated and deemed inappropriate due to this document's need to also support
pinning. That is, pinning a client-certificate to support NETCONF over TLS
client authentication.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 RPC 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 RPC operation,
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 BoardThis draft was split out from draft-ietf-netconf-server-model-09.Removed key-usage parameter from generate-private-key action.Now /private-keys/private-key/certificates/certificate/name
must be globally unique (unique across all private keys).Added top-level 'trusted-ssh-host-keys' and 'user-auth-credentials'
to support SSH client modules.Renamed module from "keychain" to "keystore" (Issue #3)Replaced 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.