Common YANG Data Types for CryptographyWatsen Networkskent+ietf@watsen.netHuaweiwang.haiguang.shieldlab@huawei.com
Operations
NETCONF Working GroupThis document defines four YANG modules for types useful to
cryptographic applications. The modules defined include:
ietf-crypto-typesiana-symmetric-algsiana-asymmetric-algsiana-hash-algsThis 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:
XXXX --> 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:
2019-11-02 --> the publication date of this draftThe following Appendix section is to be removed prior to publication:
Appendix B. Change LogThis document defines four YANG 1.1 modules
for types useful to cryptographic applications. The modules defined
include:ietf-crypto-typesiana-symmetric-algsiana-asymmetric-algsiana-hash-algsThe 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.This section provides a tree diagram for
the "ietf-crypto-types" module. Only "grouping" statements are represented,
as tree diagrams have no means to represent identities or typedefs.This module has normative references to ,
, , ,
, , ,
, , ,
, , ,
, , ,
, , ,
, , and .This module has an informational reference to ,
, , ,
, , ,
, , ,
.The following example module illustrates the use of both the "symmetric-key-grouping"
and the "asymmetric-key-pair-with-certs-grouping" groupings defined in the
"ietf-crypto-types" module.Given the above example usage module, the following example
illustrates some configured keys.The following example illustrates the "generate-certificate-signing-request"
action with the NETCONF protocol.The following example illustrates the "certificate-expiration"
notification with the NETCONF protocol.This section provides a tree diagram for
the "iana-symmetric-algs" module. Only the "container" statement is represented,
as tree diagrams have no means to represent "typedef" statements.This module has normative references to FIXME...The following example illustrates the "supported-symmetric-algorithms"
"container" statement with the NETCONF protocol.This section provides a tree diagram for
the "iana-asymmetric-algs" module. Only the "container" statement is represented,
as tree diagrams have no means to represent "typedef" statements.This module has normative references to FIXME...The following example illustrates the "supported-asymmetric-algorithms"
"container" statement with the NETCONF protocol.This section provides a tree diagram for
the "iana-hash-algs" module. Only the "container" statement is represented,
as tree diagrams have no means to represent "typedef" statements.This module has normative references to FIXME...The following example illustrates the "supported-hash-algorithms"
"container" statement with the NETCONF protocol.In order to use YANG identities for algorithm identifiers, only
the most commonly used RSA key lengths are supported for the RSA
algorithm. Additional key lengths can be defined in another module
or added into a future version of this document.This document limits the number of elliptical curves supported.
This was done to match industry trends and IETF best practice (e.g.,
matching work being done in TLS 1.3). If additional algorithms are
needed, they can be defined by another module or added into a future
version of this document.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. If it is desired
to support CRMF in the future, a backwards compatible solution can be
defined at that time.The YANG module in this document defines "grouping" statements
that are 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.Since the module in this document only define groupings,
these considerations are primarily for the designers of other
modules that use these groupings.There are a number of data nodes defined by the grouping
statements that are writable/creatable/deletable (i.e., config
true, which is the default). Some of 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:
All of the data nodes defined by
all the groupings are considered sensitive to write
operations. For instance, the modification of a
public key or a certificate can dramatically alter
the implemented security policy. For this reason,
the NACM extension "default-deny-write" has been
applied to all the data nodes defined by all the
groupings.Some of the readable data nodes in the 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:
The "private-key" node
defined in the "asymmetric-key-pair-grouping" grouping
is additionally sensitive to read operations such that,
in normal use cases, it should never be returned to a
client. For this reason, the NACM extension
"default-deny-all" has been applied to it here.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:
All of the "action" statements defined by
groupings SHOULD only be executed by authorized users. For
this reason, the NACM extension "default-deny-all" has been
applied to all of them. Note that NACM uses "default-deny-all"
to protect "RPC" and "action" statements; it does not define,
e.g., an extension called "default-deny-execute".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 four URIs in the "ns" subregistry
of the IETF XML Registry . Following
the format in , the following
registrations are requested:This document registers four YANG modules in the
YANG Module Names registry .
Following the format in , the
the following registrations are requested:Information Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)International Telecommunication UnionRemoved groupings and notifications.Added typedefs for identityrefs.Added typedefs for other RFC 5280 structures.Added typedefs for other RFC 5652 structures.Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652.Moved groupings from the draft-ietf-netconf-keystore here.Removed unwanted "mandatory" and "must" statements.Added many new crypto algorithms (thanks Haiguang!)Clarified in asymmetric-key-pair-with-certs-grouping,
in certificates/certificate/name/description, that
if the name MUST NOT match the name of a certificate
that exists independently in <operational>, enabling
certs installed by the manufacturer (e.g., an IDevID).renamed base identity 'asymmetric-key-encryption-algorithm' to 'asymmetric-key-algorithm'.added new 'asymmetric-key-algorithm' identities for secp192r1, secp224r1, secp256r1,
secp384r1, and secp521r1.removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes-192-ccm, mac-aes-256-ccm,
mac-aes-128-gcm, mac-aes-192-gcm, mac-aes-256-gcm, and mac-chacha20-poly1305.for all -cbc and -ctr identities, renamed base identity 'symmetric-key-encryption-algorithm'
to 'encryption-algorithm'.for all -ccm and -gcm identities, renamed base identity 'symmetric-key-encryption-algorithm'
to 'encryption-and-mac-algorithm' and renamed the identity to remove the "enc-" prefix.for all the 'signature-algorithm' based identities, renamed from 'rsa-*' to 'rsassa-*'.removed all of the "x509v3-" prefixed 'signature-algorithm' based identities.added 'key-exchange-algorithm' based identities for 'rsaes-oaep' and 'rsaes-pkcs1-v1_5'.renamed typedef 'symmetric-key-encryption-algorithm-ref' to 'symmetric-key-algorithm-ref'.renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 'asymmetric-key-algorithm-ref'.added typedef 'encryption-and-mac-algorithm-ref'.Updated copyright date, boilerplate template, affiliation, and folding algorithm.ran YANG module through formatter.fixed broken symlink causing reformatted YANG module to not show.Added NACM annotations.Updated Security Considerations section.Added 'asymmetric-key-pair-with-cert-grouping' grouping.Removed text from 'permanently-hidden' enum regarding
such keys not being backed up or restored.Updated the boilerplate text in module-level "description"
statement to match copyeditor convention.Added an explanation to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements as for why the
nodes are not mandatory (e.g., because they may exist only
in <operational>.Added 'must' expressions to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements ensuring sibling
nodes are either all exist or do not all exist.Added an explanation to the 'permanently-hidden' that the
value cannot be configured directly by clients and servers
MUST fail any attempt to do so.Added 'trust-anchor-certs-grouping' and 'end-entity-certs-grouping'
(the plural form of existing groupings).Now states that keys created in <operational> by the
*-hidden-key actions are bound to the lifetime of the parent
'config true' node, and that subsequent invocations of either
action results in a failure.Added clarifications that implementations SHOULD assert that
configured certificates contain the matching public key.Replaced the 'generate-hidden-key' and 'install-hidden-key' actions
with special 'crypt-hash' -like input/output values.Removed the 'generate-key and 'hidden-key' features.Added grouping symmetric-key-groupingModified 'asymmetric-key-pair-grouping' to have a 'choice'
statement for the keystone module to augment into, as well
as replacing the 'union' with leafs (having different NACM
settings.Converting algorithm from identities to enumerations.All of the below changes are to the algorithm enumerations defined in ietf-crypto-types.Add in support for key exchange over x.25519 and x.448 based on RFC 8418.Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512Revise/add in enum of signature algorithm for x25519 and x448Add in des3-cbc-sha1 for IPSecAdd in sha1-des3-kd for IPSecAdd in definit for rc4-hmac and rc4-hmac-exp. These two algorithms have been deprecated in RFC 8429. But some existing draft in i2nsf may still want to use them.Add x25519 and x448 curve for asymmetric algorithmsAdd signature algorithms ed25519, ed25519-cts, ed25519phadd signature algorithms ed448, ed448phAdd in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332)Added a "key-format" identity.Added symmetric keys to the example in .Removed all non-essential (to NC/RC) algorithm types.Moved remaining algorithm types each into its own module.Added a 'config false' "algorithms-supported" list to each of the algorithm-type modules.The authors would like to thank for following for
lively discussions on list and in the halls (ordered
by last name):
Martin Bjorklund,
Nick Hancock,
Balázs Kovács,
Juergen Schoenwaelder,
Eric Voit,
and Liang Xia.