Keystore Model
draft-ietf-netconf-keystore-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
---|---|---|---|
Author | Kent Watsen | ||
Last updated | 2017-06-13 (Latest revision 2017-03-13) | ||
Replaces | draft-ietf-netconf-system-keychain | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-29)
by Reese Enghardt
Ready w/issues
YANGDOCTORS Last Call review
(of
-20)
by Jürgen Schönwälder
Ready w/issues
OPSDIR Last Call Review due 2024-01-24
Incomplete
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | I-D Exists | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-netconf-keystore-02
"An arbitrary name for this trusted host-key. Must be unique across all lists of trusted host-keys (not just this list) so that a leafref to it from another module can resolve to unique values. Note that, for when the SSH client is able to listen for call-home connections as well, there is no reference identifier (e.g., hostname, IP address, etc.) that it can use to uniquely identify the server with. The call-home draft recommends SSH servers use X.509v3 certificates (RFC6187) when calling home."; } leaf host-key { // rename to 'data'? type binary; mandatory true; description // is this the correct type? "An OneAsymmetricKey 'publicKey' structure as specified by RFC 5958, Section 2 encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; reference "RFC 5958: Asymmetric Key Packages ITU-T X.690: Watsen Expires December 15, 2017 [Page 20] Internet-Draft Keystore Model June 2017 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } } } } notification certificate-expiration { description "A notification indicating that a configured certificate is either about to expire or has already expired. When to send notifications is an implementation specific decision, but it is RECOMMENDED that a notification be sent once a month for 3 months, then once a week for four weeks, and then once a day thereafter."; leaf certificate { type instance-identifier; mandatory true; description "Identifies which certificate is expiring or is expired."; } leaf expiration-date { type yang:date-and-time; mandatory true; description "Identifies the expiration date on the certificate."; } } } <CODE ENDS> 3. Design Considerations This document uses PKCS #10 [RFC2986] for the "generate-certificate- signing-request" action. The use of Certificate Request Message Format (CRMF) [RFC4211] 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. Watsen Expires December 15, 2017 [Page 21] Internet-Draft Keystore Model June 2017 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 [RFC5914] 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. 4. Security Considerations The YANG module defined in this document is designed to be accessed via YANG based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols have mandatory-to- implement secure transport layers (e.g., SSH, TLS) with mutual authentication. The NETCONF access control model (NACM) [RFC6536] 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'. /keystore/keys/key/private-key: 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 Watsen Expires December 15, 2017 [Page 22] Internet-Draft Keystore Model June 2017 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: /keystore/keys/key/private-key: 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: generate-certificate-signing-request: For this RPC operation, it is RECOMMENDED that implementations assert channel binding [RFC5056], 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. 5. IANA Considerations 5.1. The IETF XML Registry This document registers one URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested: URI: urn:ietf:params:xml:ns:yang:ietf-keystore Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. 5.2. The YANG Module Names Registry This document registers one YANG module in the YANG Module Names registry [RFC6020]. Following the format in [RFC6020], the the following registration is requested: Watsen Expires December 15, 2017 [Page 23] Internet-Draft Keystore Model June 2017 name: ietf-keystore namespace: urn:ietf:params:xml:ns:yang:ietf-keystore prefix: kc reference: RFC VVVV 6. Acknowledgements 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, Balazs Kovacs, David Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder; Phil Shafer, Sean Turner, and Bert Wijnen. 7. References 7.1. Normative References [RFC2119] 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>. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <http://www.rfc-editor.org/info/rfc2986>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>. [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <http://www.rfc-editor.org/info/rfc5958>. [RFC6020] 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>. [RFC6536] 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>. Watsen Expires December 15, 2017 [Page 24] Internet-Draft Keystore Model June 2017 7.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>. [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <http://www.rfc-editor.org/info/rfc4211>. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, <http://www.rfc-editor.org/info/rfc5056>. [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, <http://www.rfc-editor.org/info/rfc5914>. [RFC6241] 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>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <http://www.rfc-editor.org/info/rfc8040>. [Std-802.1AR-2009] IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, <http://standards.ieee.org/findstds/ standard/802.1AR-2009.html>. Watsen Expires December 15, 2017 [Page 25] Internet-Draft Keystore Model June 2017 Appendix A. Change Log A.1. server-model-09 to 00 o This draft was split out from draft-ietf-netconf-server-model-09. o Removed key-usage parameter from generate-private-key action. o Now /private-keys/private-key/certificates/certificate/name must be globally unique (unique across all private keys). o Added top-level 'trusted-ssh-host-keys' and 'user-auth- credentials' to support SSH client modules. A.2. keychain-00 to keystore-00 o Renamed module from "keychain" to "keystore" (Issue #3) A.3. 00 to 01 o Replaced the 'certificate-chain' structures with PKCS#7 structures. (Issue #1) o Added 'private-key' as a configurable data node, and removed the 'generate-private-key' and 'load-private-key' actions. (Issue #2) o Moved 'user-auth-credentials' to the ietf-ssh-client module. (Issues #4 and #5) A.4. 01 to 02 o Added back 'generate-private-key' action. o Removed 'RESTRICTED' enum from the 'private-key' leaf type. o Fixed up a few description statements. Author's Address Kent Watsen Juniper Networks EMail: kwatsen@juniper.net Watsen Expires December 15, 2017 [Page 26]