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