idnits 2.17.1
draft-kwatsen-netconf-trust-anchors-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 124 has weird spacing: '...rw name str...'
== Line 125 has weird spacing: '...rw data bin...'
== Line 130 has weird spacing: '...rw name str...'
== Line 131 has weird spacing: '...rw data bin...'
== Line 419 has weird spacing: '... string cer...'
-- The document date (March 5, 2018) is 2243 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RFC7950' is defined on line 506, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994'
** Downref: Normative reference to an Informational RFC: RFC 2315
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Juniper Networks
4 Intended status: Standards Track March 5, 2018
5 Expires: September 6, 2018
7 YANG Data Model for Global Trust Anchors
8 draft-kwatsen-netconf-trust-anchors-00
10 Abstract
12 This document defines a YANG data model for configuring global sets
13 of X.509 certificates and SSH host-keys that can be referenced by
14 other data models for trust. While the SSH host-keys are uniquely
15 for the SSH protocol, the X.509 certificates may be used for multiple
16 uses, including authenticating protocol peers and verifying
17 signatures.
19 Editorial Note (To be removed by RFC Editor)
21 This draft contains many placeholder values that need to be replaced
22 with finalized values at the time of publication. This note
23 summarizes all of the substitutions that are needed. No other RFC
24 Editor instructions are specified elsewhere in this document.
26 Artwork in this document contains shorthand references to drafts in
27 progress. Please apply the following replacements:
29 o "XXXX" --> the assigned RFC value for this draft
31 Artwork in this document contains placeholder values for the date of
32 publication of this draft. Please apply the following replacement:
34 o "2018-03-05" --> the publication date of this draft
36 The following Appendix section is to be removed prior to publication:
38 o Appendix A. Change Log
40 Status of This Memo
42 This Internet-Draft is submitted in full conformance with the
43 provisions of BCP 78 and BCP 79.
45 Internet-Drafts are working documents of the Internet Engineering
46 Task Force (IETF). Note that other groups may also distribute
47 working documents as Internet-Drafts. The list of current Internet-
48 Drafts is at https://datatracker.ietf.org/drafts/current/.
50 Internet-Drafts are draft documents valid for a maximum of six months
51 and may be updated, replaced, or obsoleted by other documents at any
52 time. It is inappropriate to use Internet-Drafts as reference
53 material or to cite them other than as "work in progress."
55 This Internet-Draft will expire on September 6, 2018.
57 Copyright Notice
59 Copyright (c) 2018 IETF Trust and the persons identified as the
60 document authors. All rights reserved.
62 This document is subject to BCP 78 and the IETF Trust's Legal
63 Provisions Relating to IETF Documents
64 (https://trustee.ietf.org/license-info) in effect on the date of
65 publication of this document. Please review these documents
66 carefully, as they describe your rights and restrictions with respect
67 to this document. Code Components extracted from this document must
68 include Simplified BSD License text as described in Section 4.e of
69 the Trust Legal Provisions and are provided without warranty as
70 described in the Simplified BSD License.
72 Table of Contents
74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
76 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 3
77 2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . . . 3
78 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 3
79 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 5
80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
82 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 10
83 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 10
84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
86 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
87 8.2. Informative References . . . . . . . . . . . . . . . . . 11
88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
91 1. Introduction
93 This document defines a YANG data model for configuring global sets
94 of X.509 certificates and SSH host-keys that can be referenced by
95 other data models for trust. While the SSH host-keys are uniquely
96 for the SSH protocol, the X.509 certificates may be used for multiple
97 uses, including authenticating protocol peers and verifying
98 signatures.
100 1.1. Requirements Language
102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
104 "OPTIONAL" in this document are to be interpreted as described in BCP
105 14 [RFC2119] [RFC8174] when, and only when, they appear in all
106 capitals, as shown here.
108 1.2. Tree Diagram Notation
110 Tree diagrams used in this document follow the notation defined in
111 [I-D.ietf-netmod-yang-tree-diagrams].
113 2. Tree Diagram
115 The following tree diagram provides an overview of the "ietf-trust-
116 anchors" module.
118 module: ietf-trust-anchors
119 +--rw trust-anchors
120 +--rw pinned-certificates* [name]
121 | +--rw name string
122 | +--rw description? string
123 | +--rw pinned-certificate* [name]
124 | +--rw name string
125 | +--rw data binary
126 +--rw pinned-host-keys* [name]
127 +--rw name string
128 +--rw description? string
129 +--rw pinned-host-key* [name]
130 +--rw name string
131 +--rw data binary
133 3. Example Usage
135 The following example illustrates configured data.
137
139
140
141 manufacturers-root-ca-certs
142
143 Certificates built into the device for authenticating
144 manufacturer-signed objects, such as TLS server certificates,
145 vouchers, etc.. Note, though listed here, these are not
146 configurable; any attempt to do so will be denied.
147
148
149 Manufacturer Root CA cert 1
150 base64encodedvalue==
151
152
153 Manufacturer Root CA cert 2
154 base64encodedvalue==
155
156
158
159
160 explicitly-trusted-client-certs
161
162 Specific client authentication certificates for explicitly
163 trusted clients. These are needed for client certificates
164 that are not signed by a pinned CA.
165
166
167 George Jetson
168 base64encodedvalue==
169
170
172
173
174 explicitly-trusted-server-certs
175
176 Specific server authentication certificates for explicitly
177 trusted servers. These are needed for server certificates
178 that are not signed by a pinned CA.
179
180
181 Fred Flintstone
182 base64encodedvalue==
183
184
186
187
188 deployment-specific-ca-certs
189
190 Trust anchors (i.e. CA certs) that are used to authenticate
191 client connections. Clients are authenticated if their
192 certificate has a chain of trust to one of these configured
193 CA certificates.
194
195
196 ca.example.com
197 base64encodedvalue==
198
199
201
202
203 common-ca-certs
204
205 Trusted certificates to authenticate common HTTPS servers.
206 These certificates are similar to those that might be
207 shipped with a web browser.
208
209
210 ex-certificate-authority
211 base64encodedvalue==
212
213
215
216
217 explicitly-trusted-ssh-host-keys
218
219 Trusted SSH host keys used to authenticate SSH servers.
220 These host keys would be analogous to those stored in
221 a known_hosts file in OpenSSH.
222
223
224 corp-fw1
225 base64encodedvalue==
226
227
229
231 4. YANG Module
233 This YANG module imports modules defined in [RFC6536]. This module
234 uses data types defined in [RFC2315], [RFC4253], [RFC5280], and
235 [ITU.X690.1994].
237 file "ietf-trust-anchors@2018-03-05.yang"
238 module ietf-trust-anchors {
239 yang-version 1.1;
240 namespace "urn:ietf:params:xml:ns:yang:ietf-trust-anchors";
241 prefix "ta";
243 import ietf-netconf-acm {
244 prefix nacm;
245 reference
246 "RFC 6536: Network Configuration Protocol (NETCONF) Access
247 Control Model";
248 }
250 organization
251 "IETF NETCONF (Network Configuration) Working Group";
253 contact
254 "WG Web:
255 WG List:
257 Author: Kent Watsen
258 ";
260 description
261 "This module defines a data model for configuring global
262 trust anchors used by other data models. The data model
263 actually enables the configuration of sets of trust
264 anchors. This data model supports configuring trust
265 anchors for both X.509 certificates and SSH host keys.
267 This data model does not support the configuring trust
268 anchors for SSH client keys, or pinning of the client
269 keys themselves, as the ability to do so is already
270 supported by ietf-system in RFC 7317.
272 Copyright (c) 2018 IETF Trust and the persons identified
273 as authors of the code. All rights reserved.
275 Redistribution and use in source and binary forms, with
276 or without modification, is permitted pursuant to, and
277 subject to the license terms contained in, the Simplified
278 BSD License set forth in Section 4.c of the IETF Trust's
279 Legal Provisions Relating to IETF Documents
280 (http://trustee.ietf.org/license-info).
282 This version of this YANG module is part of RFC XXXX; see
283 the RFC itself for full legal notices.";
285 revision "2018-03-05" {
286 description
287 "Initial version";
288 reference
289 "RFC XXXX: YANG Data Model for Global Trust Anchors";
290 }
292 // Identities
294 // typedefs
296 typedef pinned-certificates {
297 type leafref {
298 path "/ta:trust-anchors/ta:pinned-certificates/ta:name";
299 }
300 description
301 "This typedef enables importing modules to easily define a
302 reference to pinned-certificates. Use of this type also
303 impacts the YANG tree diagram output.";
304 }
306 typedef pinned-host-keys {
307 type leafref {
308 path "/ta:trust-anchors/ta:pinned-host-keys/ta:name";
309 }
310 description
311 "This typedef enables importing modules to easily define a
312 reference to pinned-host-keys. Use of this type also
313 impacts the YANG tree diagram output.";
314 reference
315 "I-D.ietf-netmod-yang-tree-diagrams: YANG Tree Diagrams";
316 }
318 // protocol accessible nodes
320 container trust-anchors {
321 nacm:default-deny-write;
322 description
323 "Contains sets of X.509 certificates and SSH host keys.";
325 list pinned-certificates {
326 key name;
327 description
328 "A list of pinned certificates. These certificates can be
329 used by a server to authenticate clients, or by a client to
330 authenticate servers. Each list of pinned certificates
331 SHOULD be specific to a purpose, as the list as a whole
332 may be referenced by other modules. For instance, a
333 NETCONF server's configuration might use a specific list
334 of pinned certificates for when authenticating NETCONF
335 client connections.";
336 leaf name {
337 type string;
338 description
339 "An arbitrary name for this list of pinned certificates.";
340 }
341 leaf description {
342 type string;
343 description
344 "An arbitrary description for this list of pinned
345 certificates.";
346 }
347 list pinned-certificate {
348 key name;
349 description
350 "A pinned certificate.";
351 leaf name {
352 type string;
353 description
354 "An arbitrary name for this pinned certificate. The
355 name must be unique across all lists of pinned
356 certificates (not just this list) so that leafrefs
357 from another module can resolve to unique values.";
358 }
359 leaf data {
360 type binary;
361 mandatory true;
362 description
363 "An X.509 v3 certificate structure as specified by RFC
364 5280, Section 4 encoded using the ASN.1 distinguished
365 encoding rules (DER), as specified in ITU-T X.690.";
366 reference
367 "RFC 5280:
368 Internet X.509 Public Key Infrastructure Certificate
369 and Certificate Revocation List (CRL) Profile.
370 ITU-T X.690:
371 Information technology - ASN.1 encoding rules:
372 Specification of Basic Encoding Rules (BER),
373 Canonical Encoding Rules (CER) and Distinguished
374 Encoding Rules (DER).";
375 }
376 }
377 }
379 list pinned-host-keys {
380 key name;
381 description
382 "A list of pinned host keys. These pinned host-keys can
383 be used by clients to authenticate SSH servers. Each
384 list of pinned host keys SHOULD be specific to a purpose,
385 so the list as a whole may be referenced by other modules.
386 For instance, a NETCONF client's configuration might
387 point to a specific list of pinned host keys for when
388 authenticating specific SSH servers.";
389 leaf name {
390 type string;
391 description
392 "An arbitrary name for this list of pinned SSH host keys.";
393 }
394 leaf description {
395 type string;
396 description
397 "An arbitrary description for this list of pinned SSH host
398 keys.";
399 }
400 list pinned-host-key {
401 key name;
402 description
403 "A pinned host key.";
404 leaf name {
405 type string;
406 description
407 "An arbitrary name for this pinned host-key. Must be
408 unique across all lists of pinned host-keys (not just
409 this list) so that a leafref to it from another module
410 can resolve to unique values.";
411 }
412 leaf data {
413 type binary;
414 mandatory true;
415 description
416 "The binary public key data for this SSH key, as
417 specified by RFC 4253, Section 6.6, i.e.:
419 string certificate or public key format
420 identifier
421 byte[n] key/certificate data.";
422 reference
423 "RFC 4253: The Secure Shell (SSH) Transport Layer
424 Protocol";
425 }
426 }
427 }
429 }
431 }
432
434 5. Security Considerations
436 TBD
438 6. IANA Considerations
440 6.1. The IETF XML Registry
442 This document registers one URI in the IETF XML registry [RFC3688].
443 Following the format in [RFC3688], the following registration is
444 requested:
446 URI: urn:ietf:params:xml:ns:yang:ietf-trust-anchors
447 Registrant Contact: The NETCONF WG of the IETF.
448 XML: N/A, the requested URI is an XML namespace.
450 6.2. The YANG Module Names Registry
452 This document registers one YANG module in the YANG Module Names
453 registry [RFC6020]. Following the format in [RFC6020], the the
454 following registration is requested:
456 name: ietf-trust-anchors
457 namespace: urn:ietf:params:xml:ns:yang:ietf-trust-anchors
458 prefix: ta
459 reference: RFC XXXX
461 7. Acknowledgements
463 The authors would like to thank for following for lively discussions
464 on list and in the halls (ordered by last name):
466 8. References
468 8.1. Normative References
470 [ITU.X690.1994]
471 International Telecommunications Union, "Information
472 Technology - ASN.1 encoding rules: Specification of Basic
473 Encoding Rules (BER), Canonical Encoding Rules (CER) and
474 Distinguished Encoding Rules (DER)", ITU-T Recommendation
475 X.690, 1994.
477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
478 Requirement Levels", BCP 14, RFC 2119,
479 DOI 10.17487/RFC2119, March 1997,
480 .
482 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
483 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
484 .
486 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
487 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
488 January 2006, .
490 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
491 Housley, R., and W. Polk, "Internet X.509 Public Key
492 Infrastructure Certificate and Certificate Revocation List
493 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
494 .
496 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
497 the Network Configuration Protocol (NETCONF)", RFC 6020,
498 DOI 10.17487/RFC6020, October 2010,
499 .
501 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
502 Protocol (NETCONF) Access Control Model", RFC 6536,
503 DOI 10.17487/RFC6536, March 2012,
504 .
506 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
507 RFC 7950, DOI 10.17487/RFC7950, August 2016,
508 .
510 8.2. Informative References
512 [I-D.ietf-netmod-yang-tree-diagrams]
513 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
514 ietf-netmod-yang-tree-diagrams-06 (work in progress),
515 February 2018.
517 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
518 DOI 10.17487/RFC3688, January 2004,
519 .
521 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
522 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
523 May 2017, .
525 Appendix A. Change Log
527 TBD
529 Author's Address
531 Kent Watsen
532 Juniper Networks
534 EMail: kwatsen@juniper.net