idnits 2.17.1 draft-ietf-netconf-system-keychain-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 229 has weird spacing: '...request bin...' == Line 238 has weird spacing: '...ate-key bin...' == Line 250 has weird spacing: '...ost-key bin...' == Line 270 has weird spacing: '...on-date yan...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2016) is 2848 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) -- Looks like a reference, but probably isn't: '3' on line 725 == Unused Reference: 'RFC6241' is defined on line 1420, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2986 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 G. Wu 5 Expires: January 9, 2017 Cisco Networks 6 July 8, 2016 8 System Keychain Model 9 draft-ietf-netconf-system-keychain-00 11 Abstract 13 This document defines a YANG data module for a system-level keychain 14 mechanism, that might be used to hold onto private keys and 15 certificates that are trusted by the system advertising support for 16 this module. 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. No other RFC 23 Editor instructions are specified elsewhere in this document. 25 This document contains references to other drafts in progress, both 26 in the Normative References section, as well as in body text 27 throughout. Please update the following references to reflect their 28 final RFC assignments: 30 o draft-ietf-netconf-restconf 32 o draft-ietf-netconf-call-home 34 o draft-ietf-rtgwg-yang-key-chain 36 Artwork in this document contains shorthand references to drafts in 37 progress. Please apply the following replacements: 39 o "VVVV" --> the assigned RFC value for this draft 41 o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf 43 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home 45 Artwork in this document contains placeholder values for ports 46 pending IANA assignment from "draft-ietf-netconf-call-home". Please 47 apply the following replacements: 49 o "7777" --> the assigned port value for "netconf-ch-ssh" 51 o "8888" --> the assigned port value for "netconf-ch-tls" 53 o "9999" --> the assigned port value for "restconf-ch-tls" 55 Artwork in this document contains placeholder values for the date of 56 publication of this draft. Please apply the following replacement: 58 o "2016-07-08" --> the publication date of this draft 60 The following two Appendix sections are to be removed prior to 61 publication: 63 o Appendix A. Change Log 65 o Appendix B. Open Issues 67 Status of This Memo 69 This Internet-Draft is submitted in full conformance with the 70 provisions of BCP 78 and BCP 79. 72 Internet-Drafts are working documents of the Internet Engineering 73 Task Force (IETF). Note that other groups may also distribute 74 working documents as Internet-Drafts. The list of current Internet- 75 Drafts is at http://datatracker.ietf.org/drafts/current/. 77 Internet-Drafts are draft documents valid for a maximum of six months 78 and may be updated, replaced, or obsoleted by other documents at any 79 time. It is inappropriate to use Internet-Drafts as reference 80 material or to cite them other than as "work in progress." 82 This Internet-Draft will expire on January 9, 2017. 84 Copyright Notice 86 Copyright (c) 2016 IETF Trust and the persons identified as the 87 document authors. All rights reserved. 89 This document is subject to BCP 78 and the IETF Trust's Legal 90 Provisions Relating to IETF Documents 91 (http://trustee.ietf.org/license-info) in effect on the date of 92 publication of this document. Please review these documents 93 carefully, as they describe your rights and restrictions with respect 94 to this document. Code Components extracted from this document must 95 include Simplified BSD License text as described in Section 4.e of 96 the Trust Legal Provisions and are provided without warranty as 97 described in the Simplified BSD License. 99 Table of Contents 101 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 102 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 103 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 104 2. The System Keychain Model . . . . . . . . . . . . . . . . . . 4 105 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 106 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 107 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 108 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 28 109 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 110 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 111 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 30 112 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 30 113 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 114 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 115 7.1. Normative References . . . . . . . . . . . . . . . . . . 30 116 7.2. Informative References . . . . . . . . . . . . . . . . . 31 117 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 118 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 33 119 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 33 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 122 1. Introduction 124 This document defines a YANG [RFC6020] data module for a system-level 125 keychain mechanism, which can be used to hold onto private keys and 126 certificates that are trusted by the system advertising support for 127 this module. 129 This module provides a centralized location for security sensitive 130 data, so that the data can be then referenced by other modules. 131 There are two types of data that are maintained by this module: 133 o Private keys, and any associated public certificates. 135 o Sets of trusted certificates. 137 This document extends special consideration for systems that have 138 Trusted Protection Modules (TPMs). These systems are unique in that 139 the TPM must be directed to generate new private keys (it is not 140 possible to load a private key into a TPM) and it is not possible to 141 backup/restore the TPM's private keys as configuration. 143 It is not required that a system has an operating system level 144 keychain utility to implement this module. 146 1.1. Terminology 148 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 1.2. Tree Diagrams 154 A simplified graphical representation of the data models is used in 155 this document. The meaning of the symbols in these diagrams is as 156 follows: 158 o Brackets "[" and "]" enclose list keys. 160 o Braces "{" and "}" enclose feature names, and indicate that the 161 named feature must be present for the subtree to be present. 163 o Abbreviations before data node names: "rw" means configuration 164 (read-write) and "ro" state data (read-only). 166 o Symbols after data node names: "?" means an optional node, "!" 167 means a presence container, and "*" denotes a list and leaf-list. 169 o Parentheses enclose choice and case nodes, and case nodes are also 170 marked with a colon (":"). 172 o Ellipsis ("...") stands for contents of subtrees that are not 173 shown. 175 2. The System Keychain Model 177 The system keychain module defined in this section provides a 178 configurable object having the following characteristics: 180 o A semi-configurable list of private keys, each with one or more 181 associated certificates. Private keys MUST be either preinstalled 182 (e.g., a key associated to an IDevID [Std-802.1AR-2009] 183 certificate), be generated by request, or be loaded by request. 184 Each private key is MAY have associated certificates, either 185 preinstalled or configured after creation. 187 o A configurable list of lists of trust anchor certificates. This 188 enables the server to have use-case specific trust anchors. For 189 instance, one list of trust anchors might be used to authenticate 190 management connections (e.g., client certificate-based 191 authentication for NETCONF or RESTCONF connections), and a 192 different list of trust anchors might be used for when connecting 193 to a specific Internet-based service (e.g., a zero touch bootstrap 194 server). 196 o An RPC to generate a certificate signing request for an existing 197 private key, a passed subject, and an optional attributes. The 198 signed certificate returned from an external certificate authority 199 (CA) can be later set using a standard configuration change 200 request (e.g., ). 202 o An RPC to request the server to generate a new private key using 203 the specified algorithm and key length. 205 o An RPC to request the server to load a new private key. 207 2.1. Overview 209 The system keychain module has the following tree diagram. Please 210 see Section 1.2 for information on how to interpret this diagram. 212 module: ietf-system-keychain 213 +--rw keychain 214 +--rw private-keys 215 | +--rw private-key* [name] 216 | | +--rw name string 217 | | +--ro algorithm? identityref 218 | | +--ro key-length? uint32 219 | | +--ro public-key binary 220 | | +--rw certificate-chains 221 | | | +--rw certificate-chain* [name] 222 | | | +--rw name string 223 | | | +--rw certificate* binary 224 | | +---x generate-certificate-signing-request 225 | | +---w input 226 | | | +---w subject binary 227 | | | +---w attributes? binary 228 | | +--ro output 229 | | +--ro certificate-signing-request binary 230 | +---x generate-private-key 231 | | +---w input 232 | | +---w name string 233 | | +---w algorithm identityref 234 | | +---w key-length? uint32 235 | +---x load-private-key 236 | +---w input 237 | +---w name string 238 | +---w private-key binary 239 +--rw trusted-certificates* [name] 240 | +--rw name string 241 | +--rw description? string 242 | +--rw trusted-certificate* [name] 243 | +--rw name string 244 | +--rw certificate? binary 245 +--rw trusted-ssh-host-keys* [name] 246 | +--rw name string 247 | +--rw description? string 248 | +--rw trusted-host-key* [name] 249 | +--rw name string 250 | +--rw host-key binary 251 +--rw user-auth-credentials 252 +--rw user-auth-credential* [username] 253 +--rw username string 254 +--rw auth-method* [priority] 255 +--rw priority uint8 256 +--rw (auth-type)? 257 +--:(certificate) 258 | +--rw certificate* -> /keychain/private- 259 keys/private-key/certificate-chains/certificate-chain/name 260 +--:(public-key) 261 | +--rw public-key* -> /keychain/private- 262 keys/private-key/name 263 +--:(ciphertext-password) 264 | +--rw ciphertext-password? string 265 +--:(cleartext-password) 266 +--rw cleartext-password? string 267 notifications: 268 +---n certificate-expiration 269 +--ro certificate instance-identifier 270 +--ro expiration-date yang:date-and-time 272 2.2. Example Usage 274 The following example illustrates the "generate-private-key" action 275 in use with the RESTCONF protocol and JSON encoding. 277 REQUEST 278 ------- 280 ['\' line wrapping added for formatting only] 282 POST https://example.com/restconf/data/ietf-system-keychain:keychain/\ 283 private-keys/generate-private-key HTTP/1.1 284 HOST: example.com 285 Content-Type: application/yang.operation+json 287 { 288 "ietf-system-keychain:input" : { 289 "name" : "ex-key-sect571r1", 290 "algorithm" : "sect571r1" 291 } 292 } 294 RESPONSE 295 -------- 297 HTTP/1.1 204 No Content 298 Date: Mon, 31 Oct 2015 11:01:00 GMT 299 Server: example-server 301 The following example illustrates the "load-private-key" action in 302 use with the RESTCONF protocol and JSON encoding. 304 REQUEST 305 ------- 307 ['\' line wrapping added for formatting only] 309 POST https://example.com/restconf/data/ietf-system-keychain:keychain/\ 310 private-keys/load-private-key HTTP/1.1 311 HOST: example.com 312 Content-Type: application/yang.operation+xml 314 315 ex-key-sect571r1 316 317 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 318 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 319 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 320 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 321 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 322 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 323 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 324 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 325 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 326 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 327 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 328 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 329 330 332 RESPONSE 333 -------- 335 HTTP/1.1 204 No Content 336 Date: Mon, 31 Oct 2015 11:01:00 GMT 337 Server: example-server 339 The following example illustrates the "generate-certificate-signing- 340 request" action in use with the NETCONF protocol. 342 REQUEST 343 ------- 345 347 348 350 351 352 ex-key-sect571r1 353 354 355 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2R 356 manZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNlmO 357 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmR6Zgo= 358 359 360 bwtakWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvut4 361 arnZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYm 362 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmC6Rhp= 363 364 365 366 367 368 369 371 RESPONSE 372 -------- 374 376 378 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 379 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 380 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 381 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 382 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 383 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 384 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 385 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 386 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 387 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 388 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 389 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 390 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 391 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 392 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 393 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 394 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 395 396 398 The following example illustrates what a fully configured keychain 399 object might look like. The private-key shown below is consistent 400 with the generate-private-key and generate-certificate-signing- 401 request examples above. This example also assumes that the resulting 402 CA-signed certificate has been configured back onto the server. 403 Lastly, this example shows that three lists of trusted certificates 404 having been configured. 406 408 409 410 411 my-rsa-user-key 412 rsa 413 414 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 415 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 416 JvO3NkZ25iO29pLmR6Zgo= 417 418 419 420 my-rsa-chain 421 422 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 423 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 424 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 425 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 426 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 427 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 428 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 429 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 430 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 431 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 432 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 433 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 434 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 435 436 437 438 440 441 my-ec-user-key 442 secp256r1 443 444 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 445 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 446 JvO3NkZ25iO29pLmR6Zgo= 447 448 449 450 my-ec-chain 451 452 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 453 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 454 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 455 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 456 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 457 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 458 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 459 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 460 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 461 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 462 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 463 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 464 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 465 466 467 468 470 471 tpm-protected-key 472 sect571r1 473 474 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 475 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 476 JvO3NkZ25iO29pLmR6Zgo= 477 478 479 480 default-idevid-chain 481 482 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 483 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 484 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 485 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 486 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 487 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 488 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 489 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 490 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 491 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 492 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 493 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 494 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 495 496 497 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 498 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 499 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 500 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 501 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 502 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 503 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 504 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 505 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 506 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 507 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 508 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 509 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 510 SSUZJQ0FURS0tLS0tCg== 511 512 513 514 my-ldevid-chain 515 516 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 517 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 518 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 519 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 520 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 521 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 522 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 523 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 524 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 525 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 526 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 527 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 528 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 529 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 530 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 531 532 533 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 534 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 535 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 536 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 537 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 538 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 539 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 540 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 541 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 542 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 543 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 544 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 545 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 546 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 547 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 548 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 549 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 550 551 552 553 554 556 557 558 explicitly-trusted-client-certs 559 560 Specific client authentication certificates that are to be 561 explicitly trusted NETCONF/RESTCONF clients. These are 562 needed for client certificates not signed by our CA. 563 564 565 George Jetson 566 567 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 568 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 569 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 570 RV0JCU2t2MXI2SFNHeUFUVkpwSmYyOWtXbUU0NEo5akJrQmdOVkhTTUVY 571 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 572 UxNQWtHQTFVRUJoTUNWVk14RURBT0JnTlZCQW9UQjJWNApZVzF3YkdVeE 573 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 574 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 575 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 576 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 577 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 578 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 579 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 580 TQzcjFZSjk0M1FQLzV5eGUKN2QxMkxCV0dxUjUrbEl5N01YL21ka2M4al 581 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 582 LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 583 584 585 586 Fred Flintstone 587 588 VlEVlFRREV3Vm9ZWEJ3ZVRDQm56QU5CZ2txaGtpRzl3MEJBUUVGQUFPQm 589 pRQXdnWWtDCmdZRUE1RzRFSWZsS1p2bDlXTW44eUhyM2hObUFRaUhVUzV 590 rRUpPQy9hSFA3eGJXQW1ra054ZStUa2hrZnBsL3UKbVhsTjhSZUd1ODhG 591 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 592 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 593 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 594 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 595 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 596 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 597 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 598 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 599 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 600 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 601 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 602 QWtUOCBDRVUUZJ0RUF== 603 604 605 607 608 609 deployment-specific-ca-certs 610 611 Trust anchors used only to authenticate NETCONF/RESTCONF 612 client connections. Since our security policy only allows 613 authentication for clients having a certificate signed by 614 our CA, we only configure its certificate below. 615 616 617 ca.example.com 618 619 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 620 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 621 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 622 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 623 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 624 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 625 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 626 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 627 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 628 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 629 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 630 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 631 RJSUJQFRStS0Cg== 632 633 634 636 637 638 common-ca-certs 639 640 Trusted certificates to authenticate common HTTPS servers. 641 These certificates are similar to those that might be 642 shipped with a web browser. 643 644 645 ex-certificate-authority 646 647 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 648 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 649 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 650 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 651 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 652 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 653 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 654 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 655 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 656 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 657 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 658 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 659 660 661 663 664 665 explicitly-trusted-ssh-host-keys 666 667 Trusted SSH host keys used to authenticate SSH servers. 668 These host keys would be analogous to those stored in 669 a known_hosts file in OpenSSH. 670 671 672 corp-fw1 673 674 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 675 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 676 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 677 678 679 681 682 683 684 admin 685 686 1 687 my-ec-chain 688 my-rsa-chain 689 690 691 2 692 my-rsa-user-key 693 694 695 696 tester 697 698 1 699 testing123 700 701 702 703 ldevid 704 705 1 706 my-ldevid-chain 707 708 709 711 713 The following example illustrates a "certificate-expiration" 714 notification in XML. 716 ['\' line wrapping added for formatting only] 718 720 2016-07-08T00:01:00Z 721 723 724 /kc:keychain/kc:private-keys/kc:private-key/kc:certificate-chains\ 725 /kc:certificate-chain/kc:certificate[3] 726 727 2016-08-08T14:18:53-05:00 728 729 730 2.3. YANG Module 732 This YANG module makes extensive use of data types defined in 733 [RFC5280] and [RFC5958]. 735 file "ietf-system-keychain@2016-07-08.yang" 737 module ietf-system-keychain { 738 yang-version 1.1; 740 namespace "urn:ietf:params:xml:ns:yang:ietf-system-keychain"; 741 prefix "kc"; 743 import ietf-yang-types { 744 prefix yang; 745 reference 746 "RFC 6991: Common YANG Data Types"; 747 } 749 organization 750 "IETF NETCONF (Network Configuration) Working Group"; 752 contact 753 "WG Web: 754 WG List: 756 WG Chair: Mehmet Ersue 757 759 WG Chair: Mahesh Jethanandani 760 762 Editor: Kent Watsen 763 "; 765 description 766 "This module defines a keychain to centralize management of 767 security credentials. 769 Copyright (c) 2014 IETF Trust and the persons identified as 770 authors of the code. All rights reserved. 772 Redistribution and use in source and binary forms, with or 773 without modification, is permitted pursuant to, and subject 774 to the license terms contained in, the Simplified BSD 775 License set forth in Section 4.c of the IETF Trust's 776 Legal Provisions Relating to IETF Documents 777 (http://trustee.ietf.org/license-info). 779 This version of this YANG module is part of RFC VVVV; see 780 the RFC itself for full legal notices."; 782 revision "2016-07-08" { 783 description 784 "Initial version"; 785 reference 786 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 787 Models"; 788 } 790 identity key-algorithm { 791 description 792 "Base identity from which all key-algorithms are derived."; 793 } 795 identity rsa { 796 base key-algorithm; 797 description 798 "The RSA algorithm."; 799 reference 800 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 801 RSA Cryptography Specifications Version 2.1."; 802 } 804 identity secp192r1 { 805 base key-algorithm; 806 description 807 "The secp192r1 algorithm."; 808 reference 809 "RFC5480: 810 Elliptic Curve Cryptography Subject Public Key Information."; 811 } 813 identity secp256r1 { 814 base key-algorithm; 815 description 816 "The secp256r1 algorithm."; 817 reference 818 "RFC5480: 819 Elliptic Curve Cryptography Subject Public Key Information."; 820 } 822 identity secp384r1 { 823 base key-algorithm; 824 description 825 "The secp384r1 algorithm."; 826 reference 827 "RFC5480: 828 Elliptic Curve Cryptography Subject Public Key Information."; 829 } 831 identity secp521r1 { 832 base key-algorithm; 833 description 834 "The secp521r1 algorithm."; 835 reference 836 "RFC5480: 837 Elliptic Curve Cryptography Subject Public Key Information."; 838 } 840 container keychain { 841 description 842 "A list of private-keys and their associated certificates, as 843 well as lists of trusted certificates for client certificate 844 authentication. RPCs are provided to generate a new private 845 key and to generate a certificate signing requests."; 847 container private-keys { 848 description 849 "A list of private key maintained by the keychain."; 850 list private-key { 851 key name; 852 description 853 "A private key."; 854 leaf name { 855 type string; 856 description 857 "An arbitrary name for the private key."; 858 } 859 leaf algorithm { 860 type identityref { 861 base "key-algorithm"; 862 } 863 config false; 864 description 865 "The algorithm used by the private key."; 866 } 867 leaf key-length { 868 type uint32; 869 config false; 870 description 871 "The key-length used by the private key."; 872 } 873 leaf public-key { 874 type binary; 875 config false; 876 mandatory true; 877 description 878 "An OneAsymmetricKey 'publicKey' structure as specified 879 by RFC 5958, Section 2 encoded using the ASN.1 880 distinguished encoding rules (DER), as specified 881 in ITU-T X.690."; 882 reference 883 "RFC 5958: 884 Asymmetric Key Packages 885 ITU-T X.690: 886 Information technology - ASN.1 encoding rules: 887 Specification of Basic Encoding Rules (BER), 888 Canonical Encoding Rules (CER) and Distinguished 889 Encoding Rules (DER)."; 890 } 891 container certificate-chains { 892 description 893 "Certificate chains associated with this private key. 894 More than one chain per key is enabled to support, 895 for instance, a TPM-protected key that has associated 896 both IDevID and LDevID certificates."; 897 list certificate-chain { 898 key name; 899 description 900 "A certificate chain for this public key."; 901 leaf name { 902 type string; 903 description 904 "An arbitrary name for the certificate chain. The 905 name must be a unique across all private keys, not 906 just within this private key."; 907 } 908 leaf-list certificate { 909 type binary; 910 ordered-by user; 911 description 912 "An X.509 v3 certificate structure as specified by RFC 913 5280, Section 4 encoded using the ASN.1 distinguished 914 encoding rules (DER), as specified in ITU-T X.690. 915 The list of certificates that run from the server 916 certificate towards the trust anchor. The chain MAY 917 include the trust anchor certificate itself."; 918 reference 919 "RFC 5280: 920 Internet X.509 Public Key Infrastructure Certificate 921 and Certificate Revocation List (CRL) Profile. 922 ITU-T X.690: 923 Information technology - ASN.1 encoding rules: 924 Specification of Basic Encoding Rules (BER), 925 Canonical Encoding Rules (CER) and Distinguished 926 Encoding Rules (DER)."; 927 } 928 } 929 } 930 action generate-certificate-signing-request { 931 description 932 "Generates a certificate signing request structure for 933 the associated private key using the passed subject and 934 attribute values. Please review both the Security 935 Considerations and Design Considerations sections in 936 RFC VVVV for more information regarding this action 937 statement."; 938 input { 939 leaf subject { 940 type binary; 941 mandatory true; 942 description 943 "The 'subject' field from the CertificationRequestInfo 944 structure as specified by RFC 2986, Section 4.1 encoded 945 using the ASN.1 distinguished encoding rules (DER), as 946 specified in ITU-T X.690."; 947 reference 948 "RFC 2986: 949 PKCS #10: Certification Request Syntax Specification 950 Version 1.7. 951 ITU-T X.690: 952 Information technology - ASN.1 encoding rules: 953 Specification of Basic Encoding Rules (BER), 954 Canonical Encoding Rules (CER) and Distinguished 955 Encoding Rules (DER)."; 956 } 957 leaf attributes { 958 type binary; 959 description 960 "The 'attributes' field from the CertificationRequestInfo 961 structure as specified by RFC 2986, Section 4.1 encoded 962 using the ASN.1 distinguished encoding rules (DER), as 963 specified in ITU-T X.690."; 964 reference 965 "RFC 2986: 966 PKCS #10: Certification Request Syntax Specification 967 Version 1.7. 968 ITU-T X.690: 969 Information technology - ASN.1 encoding rules: 970 Specification of Basic Encoding Rules (BER), 971 Canonical Encoding Rules (CER) and Distinguished 972 Encoding Rules (DER)."; 973 } 974 } 975 output { 976 leaf certificate-signing-request { 977 type binary; 978 mandatory true; 979 description 980 "A CertificationRequest structure as specified by RFC 981 2986, Section 4.1 encoded using the ASN.1 distinguished 982 encoding rules (DER), as specified in ITU-T X.690."; 983 reference 984 "RFC 2986: 985 PKCS #10: Certification Request Syntax Specification 986 Version 1.7. 987 ITU-T X.690: 988 Information technology - ASN.1 encoding rules: 989 Specification of Basic Encoding Rules (BER), 990 Canonical Encoding Rules (CER) and Distinguished 991 Encoding Rules (DER)."; 993 } 994 } 995 } 996 } 998 action generate-private-key { 999 description 1000 "Requests the device to generate a private key using the 1001 specified algorithm and key length."; 1002 input { 1003 leaf name { 1004 type string; 1005 mandatory true; 1006 description 1007 "The name this private-key should have when listed 1008 in /keychain/private-keys. As such, the passed 1009 value must not match any existing 'name' value."; 1010 } 1011 leaf algorithm { 1012 type identityref { 1013 base "key-algorithm"; 1014 } 1015 mandatory true; 1016 description 1017 "The algorithm to be used when generating the key."; 1018 } 1019 leaf key-length { 1020 type uint32; 1021 description 1022 "For algorithms that need a key length specified 1023 when generating the key."; 1024 } 1025 } 1026 } 1028 action load-private-key { 1029 description 1030 "Requests the device to load a private key"; 1031 input { 1032 leaf name { 1033 type string; 1034 mandatory true; 1035 description 1036 "The name this private-key should have when listed 1037 in /keychain/private-keys. As such, the passed 1038 value must not match any existing 'name' value."; 1039 } 1040 leaf private-key { 1041 type binary; 1042 mandatory true; 1043 description 1044 "An OneAsymmetricKey structure as specified by RFC 1045 5958, Section 2 encoded using the ASN.1 distinguished 1046 encoding rules (DER), as specified in ITU-T X.690. 1047 Note that this is the raw private with no shrouding 1048 to protect it. The strength of this private key 1049 MUST NOT be greater than the strength of the secure 1050 connection over which it is communicated. Devices 1051 SHOULD fail this request if ever that happens."; 1052 reference 1053 "RFC 5958: 1054 Asymmetric Key Packages 1055 ITU-T X.690: 1056 Information technology - ASN.1 encoding rules: 1057 Specification of Basic Encoding Rules (BER), 1058 Canonical Encoding Rules (CER) and Distinguished 1059 Encoding Rules (DER)."; 1060 } 1061 } 1062 } 1064 } 1066 list trusted-certificates { 1067 key name; 1068 description 1069 "A list of trusted certificates. These certificates 1070 can be used by a server to authenticate clients, or by clients 1071 to authenticate servers. The certificates may be endpoint 1072 specific or for certificate authorities (to authenticate many 1073 clients at once. Each list of certificates SHOULD be specific 1074 to a purpose, as the list as a whole may be referenced by other 1075 modules. For instance, a NETCONF server model might point to 1076 a list of certificates to use when authenticating client 1077 certificates."; 1078 leaf name { 1079 type string; 1080 description 1081 "An arbitrary name for this list of trusted certificates."; 1082 } 1083 leaf description { 1084 type string; 1085 description 1086 "An arbitrary description for this list of trusted 1087 certificates."; 1088 } 1089 list trusted-certificate { 1090 key name; 1091 description 1092 "A trusted certificate for a specific use. Note, this 1093 'certificate' is a list in order to encode any 1094 associated intermediate certificates."; 1095 leaf name { 1096 type string; 1097 description 1098 "An arbitrary name for this trusted certificate. Must 1099 be unique across all lists of trusted certificates 1100 (not just this list) so that a leafref to it from 1101 another module can resolve to unique values."; 1102 } 1103 leaf certificate { // rename to 'data'? 1104 type binary; 1105 description 1106 "An X.509 v3 certificate structure as specified by RFC 1107 5280, Section 4 encoded using the ASN.1 distinguished 1108 encoding rules (DER), as specified in ITU-T X.690."; 1109 reference 1110 "RFC 5280: 1111 Internet X.509 Public Key Infrastructure Certificate 1112 and Certificate Revocation List (CRL) Profile. 1113 ITU-T X.690: 1114 Information technology - ASN.1 encoding rules: 1115 Specification of Basic Encoding Rules (BER), 1116 Canonical Encoding Rules (CER) and Distinguished 1117 Encoding Rules (DER)."; 1118 } 1119 } 1120 } 1122 list trusted-ssh-host-keys { 1123 key name; 1124 description 1125 "A list of trusted host-keys. These host-keys can be used 1126 by clients to authenticate SSH servers. The host-keys are 1127 endpoint specific. Each list of host-keys SHOULD be 1128 specific to a purpose, as the list as a whole may be 1129 referenced by other modules. For instance, a NETCONF 1130 client model might point to a list of host-keys to use 1131 when authenticating servers host-keys."; 1132 leaf name { 1133 type string; 1134 description 1135 "An arbitrary name for this list of trusted SSH host keys."; 1136 } 1137 leaf description { 1138 type string; 1139 description 1140 "An arbitrary description for this list of trusted SSH host 1141 keys."; 1142 } 1143 list trusted-host-key { 1144 key name; 1145 description 1146 "A trusted host key."; 1147 leaf name { 1148 type string; 1149 description 1150 "An arbitrary name for this trusted host-key. Must be 1151 unique across all lists of trusted host-keys (not just 1152 this list) so that a leafref to it from another module 1153 can resolve to unique values. 1155 Note that, for when the SSH client is able to listen 1156 for call-home connections as well, there is no reference 1157 identifier (e.g., hostname, IP address, etc.) that it 1158 can use to uniquely identify the server with. The 1159 call-home draft recommends SSH servers use X.509v3 1160 certificates (RFC6187) when calling home."; 1161 } 1162 leaf host-key { // rename to 'data'? 1163 type binary; 1164 mandatory true; 1165 description 1166 "An OneAsymmetricKey 'publicKey' structure as specified 1167 by RFC 5958, Section 2 encoded using the ASN.1 1168 distinguished encoding rules (DER), as specified 1169 in ITU-T X.690."; 1170 reference 1171 "RFC 5958: 1172 Asymmetric Key Packages 1173 ITU-T X.690: 1174 Information technology - ASN.1 encoding rules: 1175 Specification of Basic Encoding Rules (BER), 1176 Canonical Encoding Rules (CER) and Distinguished 1177 Encoding Rules (DER)."; 1178 } 1179 } 1180 } 1182 /* 1183 Are the auth credentials truly limited to SSH? 1184 Could they be used by an HTTP client to log into an HTTP server? 1185 If truly just for SSH, maybe rename? 1186 */ 1187 container user-auth-credentials { 1188 description 1189 "A list of user authentication credentials that can be used 1190 by an SSH client to log into an SSH server, using any of 1191 the supported authentication methods (e.g., password, 1192 public key, client certificate, etc.)."; 1193 list user-auth-credential { 1194 key username; 1195 description 1196 "The authentication credentials for a specific user."; 1197 leaf username { 1198 type string; 1199 description 1200 "The username of this user. This will be the username 1201 used, for instance, to log into an SSH server."; 1202 } 1203 list auth-method { 1204 key priority; 1205 description 1206 "A method of authenticating as this user."; 1207 leaf priority { 1208 type uint8; 1209 description 1210 "When multiple authentication methods in this list are 1211 supported by the server, the one with the lowest priority 1212 value will be the one that is used."; 1213 } 1214 choice auth-type { 1215 description 1216 "The authentication type."; 1217 leaf-list certificate { 1218 type leafref { 1219 path "/keychain/private-keys/private-key/" 1220 + "certificate-chains/certificate-chain/name"; 1221 } 1222 ordered-by user; 1223 description 1224 "A list of references to certificates that can be used for 1225 user authentication. When multiple certificates in this 1226 list supported by the server, the one that comes 1227 before the others in the leaf-list will be used."; 1228 } 1229 leaf-list public-key { 1230 type leafref { 1231 path "/keychain/private-keys/private-key/name"; 1232 } 1233 ordered-by user; 1234 description 1235 "A list of references to public keys that can be used for 1236 user authentication. When multiple public keys in this 1237 list supported by the server, the one that comes 1238 before the others in the leaf-list will be used."; 1239 } 1240 leaf ciphertext-password { 1241 type string; 1242 description 1243 "An ciphertext password. The method of encipherment and 1244 how that method can be determined from this string is 1245 implementation-specific."; 1246 } 1247 leaf cleartext-password { 1248 type string; 1249 description 1250 "An cleartext password."; 1251 } 1252 } 1253 } 1254 } 1255 } 1257 } 1259 notification certificate-expiration { 1260 description 1261 "A notification indicating that a configured certificate is 1262 either about to expire or has already expired. When to send 1263 notifications is an implementation specific decision, but 1264 it is RECOMMENDED that a notification be sent once a month 1265 for 3 months, then once a week for four weeks, and then once 1266 a day thereafter."; 1267 leaf certificate { 1268 type instance-identifier; 1269 mandatory true; 1270 description 1271 "Identifies which certificate is expiring or is expired."; 1272 } 1273 leaf expiration-date { 1274 type yang:date-and-time; 1275 mandatory true; 1276 description 1277 "Identifies the expiration date on the certificate."; 1278 } 1279 } 1281 } 1283 1285 3. Design Considerations 1287 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 1288 signing-request" action. The use of Certificate Request Message 1289 Format (CRMF) [RFC4211] was considered, but is was unclear if there 1290 was market demand for it, and so support for CRMF has been left out 1291 of this specification. If it is desired to support CRMF in the 1292 future, placing a "choice" statement in both the input and output 1293 statements, along with an "if-feature" statement on the CRMF option, 1294 would enable a backwards compatible solution. 1296 This document puts a limit of the number of elliptical curves 1297 supported by default. This was done to match industry trends in IETF 1298 best practice (e.g., matching work being done in TLS 1.3). If 1299 additional algorithms are needed, they MAY be augmented in by another 1300 module, or added directly in a future version of this document. 1302 Both this document and Key Chain YANG Data Model 1303 [draft-ietf-rtgwg-yang-key-chain] define keychain YANG modules. The 1304 authors looked at this and agree that they two modules server 1305 different purposes and hence not worth merging into one document. To 1306 underscore this further, this document renamed its module from "ietf- 1307 keychain" to "ietf-system-keychain" and that other document renamed 1308 its module from "ietf-key-chain" to "ietf-routing-key-chain". 1310 For the trusted-certificates list, Trust Anchor Format [RFC5914] was 1311 evaluated and deemed inappropriate due to this document's need to 1312 also support pinning. That is, pinning a client-certificate to 1313 support NETCONF over TLS client authentication. 1315 4. Security Considerations 1317 This document defines a keychain mechanism that is entrusted with the 1318 safe keeping of private keys, and the safe keeping of trusted 1319 certificates. Nowhere in this API is there an ability to access 1320 (read out) a private key once it is known to the keychain. Further, 1321 associated public keys and attributes (e.g., algorithm name, key 1322 length, etc.) are read-only. That said, this document allows for the 1323 deletion of private keys and their certificates, as well the deletion 1324 of trusted certificates. Access control mechanisms (e.g., NACM 1325 [RFC6536]) MUST be in place so as to authorize such client actions. 1326 Further, whilst the data model allows for private keys and trusted 1327 certificates in general to be deleted, implementations should be well 1328 aware that some privates keys (e.g., those in a TPM) and some trusted 1329 certificates, should never be deleted, regardless if the 1330 authorization mechanisms would generally allow for such actions. 1332 For the "generate-certificate-signing-request" action, it is 1333 RECOMMENDED that devices implement assert channel binding [RFC5056], 1334 so as to ensure that the application layer that sent the request is 1335 the same as the device authenticated in the secure transport layer 1336 was established. 1338 This document defines a data model that includes a list of private 1339 keys. These private keys MAY be deleted using standard NETCONF or 1340 RESTCONF operations (e.g., ). Implementations SHOULD 1341 automatically (without explicit request) zeroize these keys in the 1342 most secure manner available, so as to prevent the remnants of their 1343 persisted storage locations from being analyzed in any meaningful 1344 way. 1346 The keychain module define within this document defines the "load- 1347 private-key" action enabling a device to load a client-supplied 1348 private key. This is a private key with no shrouding to protect it. 1349 The strength of this private key MUST NOT be greater than the 1350 strength of the underlying secure transport connection over which it 1351 is communicated. Devices SHOULD fail this request if ever the 1352 strength of the private key is greater then the strength of the 1353 underlying transport. 1355 5. IANA Considerations 1357 5.1. The IETF XML Registry 1359 This document registers one URI in the IETF XML registry [RFC2119]. 1360 Following the format in [RFC3688], the following registration is 1361 requested: 1363 URI: urn:ietf:params:xml:ns:yang:ietf-system-keychain 1364 Registrant Contact: The NETCONF WG of the IETF. 1365 XML: N/A, the requested URI is an XML namespace. 1367 5.2. The YANG Module Names Registry 1369 This document registers one YANG module in the YANG Module Names 1370 registry [RFC6020]. Following the format in [RFC6020], the the 1371 following registration is requested: 1373 name: ietf-system-keychain 1374 namespace: urn:ietf:params:xml:ns:yang:ietf-system-keychain 1375 prefix: kc 1376 reference: RFC VVVV 1378 6. Acknowledgements 1380 The authors would like to thank for following for lively discussions 1381 on list and in the halls (ordered by last name): Andy Bierman, Martin 1382 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 1383 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder; Phil 1384 Shafer, Sean Turner, and Bert Wijnen. 1386 7. References 1388 7.1. Normative References 1390 [draft-ietf-netconf-restconf] 1391 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1392 Protocol", draft-ieft-netconf-restconf-04 (work in 1393 progress), 2014. 1395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1396 Requirement Levels", BCP 14, RFC 2119, 1397 DOI 10.17487/RFC2119, March 1997, 1398 . 1400 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1401 Request Syntax Specification Version 1.7", RFC 2986, 1402 DOI 10.17487/RFC2986, November 2000, 1403 . 1405 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1406 Housley, R., and W. Polk, "Internet X.509 Public Key 1407 Infrastructure Certificate and Certificate Revocation List 1408 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1409 . 1411 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1412 DOI 10.17487/RFC5958, August 2010, 1413 . 1415 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1416 the Network Configuration Protocol (NETCONF)", RFC 6020, 1417 DOI 10.17487/RFC6020, October 2010, 1418 . 1420 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1421 and A. Bierman, Ed., "Network Configuration Protocol 1422 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1423 . 1425 7.2. Informative References 1427 [draft-ietf-rtgwg-yang-key-chain] 1428 Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, J., and Y. 1429 Yang, "Key Chain YANG Data Model", draft-ietf-rtgwg-yang- 1430 key-chain (work in progress), 2016, 1431 . 1434 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1435 DOI 10.17487/RFC3688, January 2004, 1436 . 1438 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1439 Certificate Request Message Format (CRMF)", RFC 4211, 1440 DOI 10.17487/RFC4211, September 2005, 1441 . 1443 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1444 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1445 . 1447 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1448 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 1449 . 1451 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1452 Protocol (NETCONF) Access Control Model", RFC 6536, 1453 DOI 10.17487/RFC6536, March 2012, 1454 . 1456 [Std-802.1AR-2009] 1457 IEEE SA-Standards Board, "IEEE Standard for Local and 1458 metropolitan area networks - Secure Device Identity", 1459 December 2009, . 1462 Appendix A. Change Log 1464 A.1. server-model-09 to 00 1466 o This draft was split out from draft-ietf-netconf-server-model-09. 1468 o Removed key-usage parameter from generate-private-key action. 1470 o Now /private-keys/private-key/certificates/certificate/name must 1471 be globally unique (unique across all private keys). 1473 o Added top-level 'trusted-ssh-host-keys' and 'user-auth- 1474 credentials' to support SSH client modules. 1476 Appendix B. Open Issues 1478 Please see: https://github.com/netconf-wg/system-keychain/issues. 1480 Authors' Addresses 1482 Kent Watsen 1483 Juniper Networks 1485 EMail: kwatsen@juniper.net 1487 Gary Wu 1488 Cisco Networks 1490 EMail: garywu@cisco.com