idnits 2.17.1 draft-ietf-netconf-keystore-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 229 has weird spacing: '...request bin...' == Line 238 has weird spacing: '...ate-key bin...' == Line 250 has weird spacing: '...ost-key bin...' == Line 271 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 (October 31, 2016) is 2734 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 726 == Unused Reference: 'RFC6241' is defined on line 1439, 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: 1 error (**), 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: May 4, 2017 Cisco Networks 6 October 31, 2016 8 Keystore Model 9 draft-ietf-netconf-keystore-00 11 Abstract 13 This document defines a YANG data module for a system-level keystore 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-10-31" --> 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 May 4, 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. Requirements Language . . . . . . . . . . . . . . . . . . 4 103 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 4 104 2. The Keystore 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 . . . . . . . . . . . . . . . . . . . . . . 31 114 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 7.1. Normative References . . . . . . . . . . . . . . . . . . 31 116 7.2. Informative References . . . . . . . . . . . . . . . . . 32 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 keystore 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 keystore utility to implement this module. 146 1.1. Requirements Language 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 Diagram Notation 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 Keystore Model 177 The keystore module defined in this section provides a configurable 178 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 keystore module has the following tree diagram. Please see 210 Section 1.2 for information on how to interpret this diagram. 212 module: ietf-keystore 213 +--rw keystore 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* -> /keystore/private 259 -keys/private-key/certificate-chains/certificate-chain/name 260 +--:(public-key) 261 | +--rw public-key* -> /keystore/private 262 -keys/private-key/name 263 +--:(ciphertext-password) 264 | +--rw ciphertext-password? string 265 +--:(cleartext-password) 266 +--rw cleartext-password? string 268 notifications: 269 +---n certificate-expiration 270 +--ro certificate instance-identifier 271 +--ro expiration-date yang:date-and-time 273 2.2. Example Usage 275 The following example illustrates the "generate-private-key" action 276 in use with the RESTCONF protocol and JSON encoding. 278 REQUEST 279 ------- 281 ['\' line wrapping added for formatting only] 283 POST https://example.com/restconf/data/ietf-keystore:keystore/\ 284 private-keys/generate-private-key HTTP/1.1 285 HOST: example.com 286 Content-Type: application/yang.operation+json 288 { 289 "ietf-keystore:input" : { 290 "name" : "ex-key-sect571r1", 291 "algorithm" : "sect571r1" 292 } 293 } 295 RESPONSE 296 -------- 298 HTTP/1.1 204 No Content 299 Date: Mon, 31 Oct 2015 11:01:00 GMT 300 Server: example-server 302 The following example illustrates the "load-private-key" action in 303 use with the RESTCONF protocol and JSON encoding. 305 REQUEST 306 ------- 308 ['\' line wrapping added for formatting only] 310 POST https://example.com/restconf/data/ietf-keystore:keystore/\ 311 private-keys/load-private-key HTTP/1.1 312 HOST: example.com 313 Content-Type: application/yang.operation+xml 315 316 ex-key-sect571r1 317 318 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 319 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 320 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 321 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 322 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 323 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 324 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 325 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 326 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 327 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 328 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 329 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 330 331 333 RESPONSE 334 -------- 336 HTTP/1.1 204 No Content 337 Date: Mon, 31 Oct 2015 11:01:00 GMT 338 Server: example-server 340 The following example illustrates the "generate-certificate-signing- 341 request" action in use with the NETCONF protocol. 343 REQUEST 344 ------- 346 348 349 351 352 353 ex-key-sect571r1 354 355 356 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2R 357 manZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNlmO 358 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmR6Zgo= 359 360 361 bwtakWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvut4 362 arnZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYm 363 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmC6Rhp= 364 365 366 367 368 369 370 372 RESPONSE 373 -------- 375 377 379 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 380 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 381 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 382 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 383 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 384 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 385 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 386 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 387 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 388 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 389 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 390 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 391 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 392 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 393 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 394 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 395 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 396 397 399 The following example illustrates what a fully configured keystore 400 object might look like. The private-key shown below is consistent 401 with the generate-private-key and generate-certificate-signing- 402 request examples above. This example also assumes that the resulting 403 CA-signed certificate has been configured back onto the server. 404 Lastly, this example shows that three lists of trusted certificates 405 having been configured. 407 409 410 411 412 my-rsa-user-key 413 rsa 414 415 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 416 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 417 JvO3NkZ25iO29pLmR6Zgo= 418 419 420 421 my-rsa-chain 422 423 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 424 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 425 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 426 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 427 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 428 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 429 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 430 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 431 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 432 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 433 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 434 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 435 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 436 437 438 439 441 442 my-ec-user-key 443 secp256r1 444 445 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 446 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 447 JvO3NkZ25iO29pLmR6Zgo= 448 449 450 451 my-ec-chain 452 453 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 454 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 455 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 456 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 457 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 458 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 459 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 460 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 461 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 462 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 463 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 464 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 465 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 466 467 468 469 471 472 tpm-protected-key 473 sect571r1 474 475 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 476 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 477 JvO3NkZ25iO29pLmR6Zgo= 478 479 480 481 default-idevid-chain 482 483 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 484 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 485 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 486 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 487 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 488 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 489 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 490 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 491 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 492 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 493 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 494 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 495 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 496 497 498 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 499 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 500 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 501 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 502 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 503 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 504 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 505 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 506 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 507 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 508 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 509 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 510 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 511 SSUZJQ0FURS0tLS0tCg== 512 513 514 515 my-ldevid-chain 516 517 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 518 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 519 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 520 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 521 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 522 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 523 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 524 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 525 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 526 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 527 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 528 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 529 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 530 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 531 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 532 533 534 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 535 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 536 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 537 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 538 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 539 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 540 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 541 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 542 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 543 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 544 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 545 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 546 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 547 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 548 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 549 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 550 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 551 552 553 554 555 557 558 559 explicitly-trusted-client-certs 560 561 Specific client authentication certificates that are to be 562 explicitly trusted NETCONF/RESTCONF clients. These are 563 needed for client certificates not signed by our CA. 564 565 566 George Jetson 567 568 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 569 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 570 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 571 RV0JCU2t2MXI2SFNHeUFUVkpwSmYyOWtXbUU0NEo5akJrQmdOVkhTTUVY 572 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 573 UxNQWtHQTFVRUJoTUNWVk14RURBT0JnTlZCQW9UQjJWNApZVzF3YkdVeE 574 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 575 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 576 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 577 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 578 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 579 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 580 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 581 TQzcjFZSjk0M1FQLzV5eGUKN2QxMkxCV0dxUjUrbEl5N01YL21ka2M4al 582 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 583 LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 584 585 586 587 Fred Flintstone 588 589 VlEVlFRREV3Vm9ZWEJ3ZVRDQm56QU5CZ2txaGtpRzl3MEJBUUVGQUFPQm 590 pRQXdnWWtDCmdZRUE1RzRFSWZsS1p2bDlXTW44eUhyM2hObUFRaUhVUzV 591 rRUpPQy9hSFA3eGJXQW1ra054ZStUa2hrZnBsL3UKbVhsTjhSZUd1ODhG 592 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 593 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 594 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 595 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 596 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 597 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 598 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 599 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 600 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 601 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 602 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 603 QWtUOCBDRVUUZJ0RUF== 604 605 606 608 609 610 deployment-specific-ca-certs 611 612 Trust anchors used only to authenticate NETCONF/RESTCONF 613 client connections. Since our security policy only allows 614 authentication for clients having a certificate signed by 615 our CA, we only configure its certificate below. 616 617 618 ca.example.com 619 620 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 621 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 622 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 623 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 624 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 625 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 626 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 627 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 628 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 629 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 630 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 631 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 632 RJSUJQFRStS0Cg== 633 634 635 637 638 639 common-ca-certs 640 641 Trusted certificates to authenticate common HTTPS servers. 642 These certificates are similar to those that might be 643 shipped with a web browser. 644 645 646 ex-certificate-authority 647 648 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 649 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 650 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 651 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 652 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 653 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 654 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 655 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 656 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 657 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 658 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 659 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 660 661 662 664 665 666 explicitly-trusted-ssh-host-keys 667 668 Trusted SSH host keys used to authenticate SSH servers. 669 These host keys would be analogous to those stored in 670 a known_hosts file in OpenSSH. 671 672 673 corp-fw1 674 675 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 676 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 677 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 678 679 680 682 683 684 685 admin 686 687 1 688 my-ec-chain 689 my-rsa-chain 690 691 692 2 693 my-rsa-user-key 694 695 696 697 tester 698 699 1 700 testing123 701 702 703 704 ldevid 705 706 1 707 my-ldevid-chain 708 709 710 712 714 The following example illustrates a "certificate-expiration" 715 notification in XML. 717 ['\' line wrapping added for formatting only] 719 721 2016-07-08T00:01:00Z 722 724 725 /ks:keystore/ks:private-keys/ks:private-key/ks:certificate-chains\ 726 /ks:certificate-chain/ks:certificate[3] 727 728 2016-08-08T14:18:53-05:00 729 730 731 2.3. YANG Module 733 This YANG module makes extensive use of data types defined in 734 [RFC5280] and [RFC5958]. 736 file "ietf-keystore@2016-10-31.yang" 738 module ietf-keystore { 739 yang-version 1.1; 741 namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; 742 prefix "ks"; 744 import ietf-yang-types { 745 prefix yang; 746 reference 747 "RFC 6991: Common YANG Data Types"; 748 } 750 organization 751 "IETF NETCONF (Network Configuration) Working Group"; 753 contact 754 "WG Web: 755 WG List: 757 WG Chair: Mehmet Ersue 758 760 WG Chair: Mahesh Jethanandani 761 763 Editor: Kent Watsen 764 "; 766 description 767 "This module defines a keystore to centralize management of 768 security credentials. 770 Copyright (c) 2014 IETF Trust and the persons identified as 771 authors of the code. All rights reserved. 773 Redistribution and use in source and binary forms, with or 774 without modification, is permitted pursuant to, and subject 775 to the license terms contained in, the Simplified BSD 776 License set forth in Section 4.c of the IETF Trust's 777 Legal Provisions Relating to IETF Documents 778 (http://trustee.ietf.org/license-info). 780 This version of this YANG module is part of RFC VVVV; see 781 the RFC itself for full legal notices."; 783 revision "2016-10-31" { 784 description 785 "Initial version"; 786 reference 787 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 788 Models"; 789 } 791 identity key-algorithm { 792 description 793 "Base identity from which all key-algorithms are derived."; 794 } 796 identity rsa { 797 base key-algorithm; 798 description 799 "The RSA algorithm."; 800 reference 801 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 802 RSA Cryptography Specifications Version 2.1."; 803 } 805 identity secp192r1 { 806 base key-algorithm; 807 description 808 "The secp192r1 algorithm."; 809 reference 810 "RFC5480: 811 Elliptic Curve Cryptography Subject Public Key Information."; 812 } 814 identity secp256r1 { 815 base key-algorithm; 816 description 817 "The secp256r1 algorithm."; 818 reference 819 "RFC5480: 820 Elliptic Curve Cryptography Subject Public Key Information."; 821 } 823 identity secp384r1 { 824 base key-algorithm; 825 description 826 "The secp384r1 algorithm."; 827 reference 828 "RFC5480: 829 Elliptic Curve Cryptography Subject Public Key Information."; 830 } 832 identity secp521r1 { 833 base key-algorithm; 834 description 835 "The secp521r1 algorithm."; 836 reference 837 "RFC5480: 838 Elliptic Curve Cryptography Subject Public Key Information."; 839 } 841 container keystore { 842 description 843 "A list of private-keys and their associated certificates, as 844 well as lists of trusted certificates for client certificate 845 authentication. RPCs are provided to generate a new private 846 key and to generate a certificate signing requests."; 848 container private-keys { 849 description 850 "A list of private key maintained by the keystore."; 851 list private-key { 852 key name; 853 description 854 "A private key."; 855 leaf name { 856 type string; 857 description 858 "An arbitrary name for the private key."; 859 } 860 leaf algorithm { 861 type identityref { 862 base "key-algorithm"; 863 } 864 config false; 865 description 866 "The algorithm used by the private key."; 867 } 868 leaf key-length { 869 type uint32; 870 config false; 871 description 872 "The key-length used by the private key."; 873 } 874 leaf public-key { 875 type binary; 876 config false; 877 mandatory true; 878 description 879 "An OneAsymmetricKey 'publicKey' structure as specified 880 by RFC 5958, Section 2 encoded using the ASN.1 881 distinguished encoding rules (DER), as specified 882 in ITU-T X.690."; 883 reference 884 "RFC 5958: 885 Asymmetric Key Packages 886 ITU-T X.690: 887 Information technology - ASN.1 encoding rules: 888 Specification of Basic Encoding Rules (BER), 889 Canonical Encoding Rules (CER) and Distinguished 890 Encoding Rules (DER)."; 891 } 892 container certificate-chains { 893 description 894 "Certificate chains associated with this private key. 895 More than one chain per key is enabled to support, 896 for instance, a TPM-protected key that has associated 897 both IDevID and LDevID certificates."; 898 list certificate-chain { 899 key name; 900 description 901 "A certificate chain for this public key."; 902 leaf name { 903 type string; 904 description 905 "An arbitrary name for the certificate chain. The 906 name must be a unique across all private keys, not 907 just within this private key."; 908 } 909 leaf-list certificate { 910 type binary; 911 ordered-by user; 912 description 913 "An X.509 v3 certificate structure as specified by RFC 914 5280, Section 4 encoded using the ASN.1 distinguished 915 encoding rules (DER), as specified in ITU-T X.690. 916 The list of certificates that run from the server 917 certificate towards the trust anchor. The chain MAY 918 include the trust anchor certificate itself."; 919 reference 920 "RFC 5280: 921 Internet X.509 Public Key Infrastructure Certificate 922 and Certificate Revocation List (CRL) Profile. 923 ITU-T X.690: 924 Information technology - ASN.1 encoding rules: 925 Specification of Basic Encoding Rules (BER), 926 Canonical Encoding Rules (CER) and Distinguished 927 Encoding Rules (DER)."; 928 } 929 } 930 } 931 action generate-certificate-signing-request { 932 description 933 "Generates a certificate signing request structure for 934 the associated private key using the passed subject and 935 attribute values. Please review both the Security 936 Considerations and Design Considerations sections in 937 RFC VVVV for more information regarding this action 938 statement."; 939 input { 940 leaf subject { 941 type binary; 942 mandatory true; 943 description 944 "The 'subject' field from the CertificationRequestInfo 945 structure as specified by RFC 2986, Section 4.1 encoded 946 using the ASN.1 distinguished encoding rules (DER), as 947 specified in ITU-T X.690."; 948 reference 949 "RFC 2986: 950 PKCS #10: Certification Request Syntax Specification 951 Version 1.7. 952 ITU-T X.690: 953 Information technology - ASN.1 encoding rules: 954 Specification of Basic Encoding Rules (BER), 955 Canonical Encoding Rules (CER) and Distinguished 956 Encoding Rules (DER)."; 957 } 958 leaf attributes { 959 type binary; 960 description 961 "The 'attributes' field from the CertificationRequestInfo 962 structure as specified by RFC 2986, Section 4.1 encoded 963 using the ASN.1 distinguished encoding rules (DER), as 964 specified in ITU-T X.690."; 965 reference 966 "RFC 2986: 967 PKCS #10: Certification Request Syntax Specification 968 Version 1.7. 969 ITU-T X.690: 970 Information technology - ASN.1 encoding rules: 971 Specification of Basic Encoding Rules (BER), 972 Canonical Encoding Rules (CER) and Distinguished 973 Encoding Rules (DER)."; 974 } 975 } 976 output { 977 leaf certificate-signing-request { 978 type binary; 979 mandatory true; 980 description 981 "A CertificationRequest structure as specified by RFC 982 2986, Section 4.1 encoded using the ASN.1 distinguished 983 encoding rules (DER), as specified in ITU-T X.690."; 984 reference 985 "RFC 2986: 986 PKCS #10: Certification Request Syntax Specification 987 Version 1.7. 988 ITU-T X.690: 989 Information technology - ASN.1 encoding rules: 990 Specification of Basic Encoding Rules (BER), 991 Canonical Encoding Rules (CER) and Distinguished 992 Encoding Rules (DER)."; 994 } 995 } 996 } 997 } 999 action generate-private-key { 1000 description 1001 "Requests the device to generate a private key using the 1002 specified algorithm and key length."; 1003 input { 1004 leaf name { 1005 type string; 1006 mandatory true; 1007 description 1008 "The name this private-key should have when listed 1009 in /keystore/private-keys. As such, the passed 1010 value must not match any existing 'name' value."; 1011 } 1012 leaf algorithm { 1013 type identityref { 1014 base "key-algorithm"; 1015 } 1016 mandatory true; 1017 description 1018 "The algorithm to be used when generating the key."; 1019 } 1020 leaf key-length { 1021 type uint32; 1022 description 1023 "For algorithms that need a key length specified 1024 when generating the key."; 1025 } 1026 } 1027 } 1029 action load-private-key { 1030 description 1031 "Requests the device to load a private key"; 1032 input { 1033 leaf name { 1034 type string; 1035 mandatory true; 1036 description 1037 "The name this private-key should have when listed 1038 in /keystore/private-keys. As such, the passed 1039 value must not match any existing 'name' value."; 1040 } 1041 leaf private-key { 1042 type binary; 1043 mandatory true; 1044 description 1045 "An OneAsymmetricKey structure as specified by RFC 1046 5958, Section 2 encoded using the ASN.1 distinguished 1047 encoding rules (DER), as specified in ITU-T X.690. 1048 Note that this is the raw private with no shrouding 1049 to protect it. The strength of this private key 1050 MUST NOT be greater than the strength of the secure 1051 connection over which it is communicated. Devices 1052 SHOULD fail this request if ever that happens."; 1053 reference 1054 "RFC 5958: 1055 Asymmetric Key Packages 1056 ITU-T X.690: 1057 Information technology - ASN.1 encoding rules: 1058 Specification of Basic Encoding Rules (BER), 1059 Canonical Encoding Rules (CER) and Distinguished 1060 Encoding Rules (DER)."; 1061 } 1062 } 1063 } 1065 } 1067 list trusted-certificates { 1068 key name; 1069 description 1070 "A list of trusted certificates. These certificates 1071 can be used by a server to authenticate clients, or by clients 1072 to authenticate servers. The certificates may be endpoint 1073 specific or for certificate authorities (to authenticate many 1074 clients at once. Each list of certificates SHOULD be specific 1075 to a purpose, as the list as a whole may be referenced by other 1076 modules. For instance, a NETCONF server model might point to 1077 a list of certificates to use when authenticating client 1078 certificates."; 1079 leaf name { 1080 type string; 1081 description 1082 "An arbitrary name for this list of trusted certificates."; 1083 } 1084 leaf description { 1085 type string; 1086 description 1087 "An arbitrary description for this list of trusted 1088 certificates."; 1089 } 1090 list trusted-certificate { 1091 key name; 1092 description 1093 "A trusted certificate for a specific use. Note, this 1094 'certificate' is a list in order to encode any 1095 associated intermediate certificates."; 1096 leaf name { 1097 type string; 1098 description 1099 "An arbitrary name for this trusted certificate. Must 1100 be unique across all lists of trusted certificates 1101 (not just this list) so that a leafref to it from 1102 another module can resolve to unique values."; 1103 } 1104 leaf certificate { // rename to 'data'? 1105 type binary; 1106 description 1107 "An X.509 v3 certificate structure as specified by RFC 1108 5280, Section 4 encoded using the ASN.1 distinguished 1109 encoding rules (DER), as specified in ITU-T X.690."; 1110 reference 1111 "RFC 5280: 1112 Internet X.509 Public Key Infrastructure Certificate 1113 and Certificate Revocation List (CRL) Profile. 1114 ITU-T X.690: 1115 Information technology - ASN.1 encoding rules: 1116 Specification of Basic Encoding Rules (BER), 1117 Canonical Encoding Rules (CER) and Distinguished 1118 Encoding Rules (DER)."; 1119 } 1120 } 1121 } 1123 list trusted-ssh-host-keys { 1124 key name; 1125 description 1126 "A list of trusted host-keys. These host-keys can be used 1127 by clients to authenticate SSH servers. The host-keys are 1128 endpoint specific. Each list of host-keys SHOULD be 1129 specific to a purpose, as the list as a whole may be 1130 referenced by other modules. For instance, a NETCONF 1131 client model might point to a list of host-keys to use 1132 when authenticating servers host-keys."; 1133 leaf name { 1134 type string; 1135 description 1136 "An arbitrary name for this list of trusted SSH host keys."; 1137 } 1138 leaf description { 1139 type string; 1140 description 1141 "An arbitrary description for this list of trusted SSH host 1142 keys."; 1143 } 1144 list trusted-host-key { 1145 key name; 1146 description 1147 "A trusted host key."; 1148 leaf name { 1149 type string; 1150 description 1151 "An arbitrary name for this trusted host-key. Must be 1152 unique across all lists of trusted host-keys (not just 1153 this list) so that a leafref to it from another module 1154 can resolve to unique values. 1156 Note that, for when the SSH client is able to listen 1157 for call-home connections as well, there is no reference 1158 identifier (e.g., hostname, IP address, etc.) that it 1159 can use to uniquely identify the server with. The 1160 call-home draft recommends SSH servers use X.509v3 1161 certificates (RFC6187) when calling home."; 1162 } 1163 leaf host-key { // rename to 'data'? 1164 type binary; 1165 mandatory true; 1166 description 1167 "An OneAsymmetricKey 'publicKey' structure as specified 1168 by RFC 5958, Section 2 encoded using the ASN.1 1169 distinguished encoding rules (DER), as specified 1170 in ITU-T X.690."; 1171 reference 1172 "RFC 5958: 1173 Asymmetric Key Packages 1174 ITU-T X.690: 1175 Information technology - ASN.1 encoding rules: 1176 Specification of Basic Encoding Rules (BER), 1177 Canonical Encoding Rules (CER) and Distinguished 1178 Encoding Rules (DER)."; 1179 } 1180 } 1181 } 1183 /* 1184 Are the auth credentials truly limited to SSH? 1185 Could they be used by an HTTP client to log into an HTTP server? 1186 If truly just for SSH, maybe rename? 1187 */ 1188 container user-auth-credentials { 1189 description 1190 "A list of user authentication credentials that can be used 1191 by an SSH client to log into an SSH server, using any of 1192 the supported authentication methods (e.g., password, 1193 public key, client certificate, etc.)."; 1194 list user-auth-credential { 1195 key username; 1196 description 1197 "The authentication credentials for a specific user."; 1198 leaf username { 1199 type string; 1200 description 1201 "The username of this user. This will be the username 1202 used, for instance, to log into an SSH server."; 1203 } 1204 list auth-method { 1205 key priority; 1206 description 1207 "A method of authenticating as this user."; 1208 leaf priority { 1209 type uint8; 1210 description 1211 "When multiple authentication methods in this list are 1212 supported by the server, the one with the lowest priority 1213 value will be the one that is used."; 1214 } 1215 choice auth-type { 1216 description 1217 "The authentication type."; 1218 leaf-list certificate { 1219 type leafref { 1220 path "/keystore/private-keys/private-key/" 1221 + "certificate-chains/certificate-chain/name"; 1222 } 1223 ordered-by user; 1224 description 1225 "A list of references to certificates that can be used 1226 for user authentication. When multiple certificates 1227 in this list supported by the server, the one that 1228 comes before the others in the leaf-list will be 1229 used."; 1230 } 1231 leaf-list public-key { 1232 type leafref { 1233 path "/keystore/private-keys/private-key/name"; 1234 } 1235 ordered-by user; 1236 description 1237 "A list of references to public keys that can be used 1238 for user authentication. When multiple public keys 1239 in this list supported by the server, the one that 1240 comes before the others in the leaf-list will be 1241 used."; 1242 } 1243 leaf ciphertext-password { 1244 type string; 1245 description 1246 "An ciphertext password. The method of encipherment 1247 and how that method can be determined from this 1248 string is implementation-specific."; 1249 } 1250 leaf cleartext-password { 1251 type string; 1252 description 1253 "An cleartext password."; 1254 } 1255 } 1256 } 1258 } 1259 } 1260 } 1262 notification certificate-expiration { 1263 description 1264 "A notification indicating that a configured certificate is 1265 either about to expire or has already expired. When to send 1266 notifications is an implementation specific decision, but 1267 it is RECOMMENDED that a notification be sent once a month 1268 for 3 months, then once a week for four weeks, and then once 1269 a day thereafter."; 1270 leaf certificate { 1271 type instance-identifier; 1272 mandatory true; 1273 description 1274 "Identifies which certificate is expiring or is expired."; 1275 } 1276 leaf expiration-date { 1277 type yang:date-and-time; 1278 mandatory true; 1279 description 1280 "Identifies the expiration date on the certificate."; 1281 } 1282 } 1284 } 1286 1288 3. Design Considerations 1290 This document, along with four other drafts, was split out from the 1291 original draft "draft-ietf-netconf-server-model". The split was made 1292 so that each draft would have better focus, and also becuase there 1293 was a desire to define client modules, in addition to server modules. 1294 The complete list of drafts that resulted from the split includes: 1296 - draft-ietf-netconf-keystore 1298 - draft-ietf-netconf-ssh-client-server 1300 - draft-ietf-netconf-tls-client-server 1302 - draft-ietf-netconf-netconf-client-server 1304 - draft-ietf-netconf-restconf-client-server 1306 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 1307 signing-request" action. The use of Certificate Request Message 1308 Format (CRMF) [RFC4211] was considered, but is was unclear if there 1309 was market demand for it, and so support for CRMF has been left out 1310 of this specification. If it is desired to support CRMF in the 1311 future, placing a "choice" statement in both the input and output 1312 statements, along with an "if-feature" statement on the CRMF option, 1313 would enable a backwards compatible solution. 1315 This document puts a limit of the number of elliptical curves 1316 supported by default. This was done to match industry trends in IETF 1317 best practice (e.g., matching work being done in TLS 1.3). If 1318 additional algorithms are needed, they MAY be augmented in by another 1319 module, or added directly in a future version of this document. 1321 Both this document and Key Chain YANG Data Model 1322 [draft-ietf-rtgwg-yang-key-chain] regard a similar idea. The authors 1323 looked at this and agree that they two modules server different 1324 purposes and hence not worth merging into one document. To 1325 underscore this further, this document renamed its module from "ietf- 1326 keychain" to "ietf-keystore", to contrast it with the other 1327 document's module "ietf-key-chain". 1329 For the trusted-certificates list, Trust Anchor Format [RFC5914] was 1330 evaluated and deemed inappropriate due to this document's need to 1331 also support pinning. That is, pinning a client-certificate to 1332 support NETCONF over TLS client authentication. 1334 4. Security Considerations 1336 This document defines a keystore mechanism that is entrusted with the 1337 safe keeping of private keys, and the safe keeping of trusted 1338 certificates. Nowhere in this API is there an ability to access 1339 (read out) a private key once it is known to the keystore. Further, 1340 associated public keys and attributes (e.g., algorithm name, key 1341 length, etc.) are read-only. That said, this document allows for the 1342 deletion of private keys and their certificates, as well the deletion 1343 of trusted certificates. Access control mechanisms (e.g., NACM 1344 [RFC6536]) MUST be in place so as to authorize such client actions. 1345 Further, whilst the data model allows for private keys and trusted 1346 certificates in general to be deleted, implementations should be well 1347 aware that some privates keys (e.g., those in a TPM) and some trusted 1348 certificates, should never be deleted, regardless if the 1349 authorization mechanisms would generally allow for such actions. 1351 For the "generate-certificate-signing-request" action, it is 1352 RECOMMENDED that devices implement assert channel binding [RFC5056], 1353 so as to ensure that the application layer that sent the request is 1354 the same as the device authenticated in the secure transport layer 1355 was established. 1357 This document defines a data model that includes a list of private 1358 keys. These private keys MAY be deleted using standard NETCONF or 1359 RESTCONF operations (e.g., ). Implementations SHOULD 1360 automatically (without explicit request) zeroize these keys in the 1361 most secure manner available, so as to prevent the remnants of their 1362 persisted storage locations from being analyzed in any meaningful 1363 way. 1365 The keystore module define within this document defines the "load- 1366 private-key" action enabling a device to load a client-supplied 1367 private key. This is a private key with no shrouding to protect it. 1368 The strength of this private key MUST NOT be greater than the 1369 strength of the underlying secure transport connection over which it 1370 is communicated. Devices SHOULD fail this request if ever the 1371 strength of the private key is greater then the strength of the 1372 underlying transport. 1374 5. IANA Considerations 1376 5.1. The IETF XML Registry 1378 This document registers one URI in the IETF XML registry [RFC2119]. 1379 Following the format in [RFC3688], the following registration is 1380 requested: 1382 URI: urn:ietf:params:xml:ns:yang:ietf-keystore 1383 Registrant Contact: The NETCONF WG of the IETF. 1384 XML: N/A, the requested URI is an XML namespace. 1386 5.2. The YANG Module Names Registry 1388 This document registers one YANG module in the YANG Module Names 1389 registry [RFC6020]. Following the format in [RFC6020], the the 1390 following registration is requested: 1392 name: ietf-keystore 1393 namespace: urn:ietf:params:xml:ns:yang:ietf-keystore 1394 prefix: kc 1395 reference: RFC VVVV 1397 6. Acknowledgements 1399 The authors would like to thank for following for lively discussions 1400 on list and in the halls (ordered by last name): Andy Bierman, Martin 1401 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 1402 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder; Phil 1403 Shafer, Sean Turner, and Bert Wijnen. 1405 7. References 1407 7.1. Normative References 1409 [draft-ietf-netconf-restconf] 1410 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1411 Protocol", draft-ieft-netconf-restconf-04 (work in 1412 progress), 2014. 1414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1415 Requirement Levels", BCP 14, RFC 2119, 1416 DOI 10.17487/RFC2119, March 1997, 1417 . 1419 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1420 Request Syntax Specification Version 1.7", RFC 2986, 1421 DOI 10.17487/RFC2986, November 2000, 1422 . 1424 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1425 Housley, R., and W. Polk, "Internet X.509 Public Key 1426 Infrastructure Certificate and Certificate Revocation List 1427 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1428 . 1430 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1431 DOI 10.17487/RFC5958, August 2010, 1432 . 1434 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1435 the Network Configuration Protocol (NETCONF)", RFC 6020, 1436 DOI 10.17487/RFC6020, October 2010, 1437 . 1439 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1440 and A. Bierman, Ed., "Network Configuration Protocol 1441 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1442 . 1444 7.2. Informative References 1446 [draft-ietf-rtgwg-yang-key-chain] 1447 Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, J., and Y. 1448 Yang, "Key Chain YANG Data Model", draft-ietf-rtgwg-yang- 1449 key-chain (work in progress), 2016, 1450 . 1453 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1454 DOI 10.17487/RFC3688, January 2004, 1455 . 1457 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1458 Certificate Request Message Format (CRMF)", RFC 4211, 1459 DOI 10.17487/RFC4211, September 2005, 1460 . 1462 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1463 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1464 . 1466 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1467 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 1468 . 1470 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1471 Protocol (NETCONF) Access Control Model", RFC 6536, 1472 DOI 10.17487/RFC6536, March 2012, 1473 . 1475 [Std-802.1AR-2009] 1476 IEEE SA-Standards Board, "IEEE Standard for Local and 1477 metropolitan area networks - Secure Device Identity", 1478 December 2009, . 1481 Appendix A. Change Log 1483 A.1. server-model-09 to 00 1485 o This draft was split out from draft-ietf-netconf-server-model-09. 1487 o Removed key-usage parameter from generate-private-key action. 1489 o Now /private-keys/private-key/certificates/certificate/name must 1490 be globally unique (unique across all private keys). 1492 o Added top-level 'trusted-ssh-host-keys' and 'user-auth- 1493 credentials' to support SSH client modules. 1495 Appendix B. Open Issues 1497 Please see: https://github.com/netconf-wg/keystore/issues. 1499 Authors' Addresses 1501 Kent Watsen 1502 Juniper Networks 1504 EMail: kwatsen@juniper.net 1506 Gary Wu 1507 Cisco Networks 1509 EMail: garywu@cisco.com