idnits 2.17.1 draft-ietf-netconf-server-model-09.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 431 has weird spacing: '...request bin...' == Line 441 has weird spacing: '...ate-key bin...' == Line 451 has weird spacing: '...on-date yan...' == Line 1704 has weird spacing: '...rw name str...' == Line 1743 has weird spacing: '...erprint x50...' == (7 more instances...) == 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 (March 16, 2016) is 2962 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 799 ** 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 (~~), 8 warnings (==), 4 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 J. Schoenwaelder 5 Expires: September 17, 2016 Jacobs University Bremen 6 March 16, 2016 8 NETCONF Server and RESTCONF Server Configuration Models 9 draft-ietf-netconf-server-model-09 11 Abstract 13 This draft defines a NETCONF server configuration data model and a 14 RESTCONF server configuration data model. These data models enable 15 configuration of the NETCONF and RESTCONF services themselves, 16 including which transports are supported, what ports the servers 17 listen on, call-home parameters, client authentication, and related 18 parameters. 20 Editorial Note (To be removed by RFC Editor) 22 This draft contains many placeholder values that need to be replaced 23 with finalized values at the time of publication. This note 24 summarizes all of the substitutions that are needed. Please note 25 that no other RFC Editor instructions are specified anywhere else in 26 this document. 28 This document contains references to other drafts in progress, both 29 in the Normative References section, as well as in body text 30 throughout. Please update the following references to reflect their 31 final RFC assignments: 33 o draft-ietf-netconf-restconf 35 o draft-ietf-netconf-call-home 37 o draft-ietf-rtgwg-yang-key-chain 39 Artwork in this document contains shorthand references to drafts in 40 progress. Please apply the following replacements: 42 o "VVVV" --> the assigned RFC value for this draft 44 o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf 46 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home 47 Artwork in this document contains placeholder values for ports 48 pending IANA assignment from "draft-ietf-netconf-call-home". Please 49 apply the following replacements: 51 o "7777" --> the assigned port value for "netconf-ch-ssh" 53 o "8888" --> the assigned port value for "netconf-ch-tls" 55 o "9999" --> the assigned port value for "restconf-ch-tls" 57 Artwork in this document contains placeholder values for the date of 58 publication of this draft. Please apply the following replacement: 60 o "2016-03-16" --> the publication date of this draft 62 The following two Appendix sections are to be removed prior to 63 publication: 65 o Appendix A. Change Log 67 o Appendix B. Open Issues 69 Artwork in the document contains a temporary YANG containers that 70 need to be removed. 72 o The "listening-ssh-server" container listed at the end of the 73 artwork in Section 4.2.3 needs to be removed. Please remove the 74 ten lines starting with "container listening-ssh-server {" and 75 ending with "}". 77 o The "listening-tls-server" container listed at the end of the 78 artwork in Section 4.3.3 needs to be removed. Please remove the 79 ten lines starting with "container listening-tls-server {" and 80 ending with "}". 82 Status of This Memo 84 This Internet-Draft is submitted in full conformance with the 85 provisions of BCP 78 and BCP 79. 87 Internet-Drafts are working documents of the Internet Engineering 88 Task Force (IETF). Note that other groups may also distribute 89 working documents as Internet-Drafts. The list of current Internet- 90 Drafts is at http://datatracker.ietf.org/drafts/current/. 92 Internet-Drafts are draft documents valid for a maximum of six months 93 and may be updated, replaced, or obsoleted by other documents at any 94 time. It is inappropriate to use Internet-Drafts as reference 95 material or to cite them other than as "work in progress." 97 This Internet-Draft will expire on September 17, 2016. 99 Copyright Notice 101 Copyright (c) 2016 IETF Trust and the persons identified as the 102 document authors. All rights reserved. 104 This document is subject to BCP 78 and the IETF Trust's Legal 105 Provisions Relating to IETF Documents 106 (http://trustee.ietf.org/license-info) in effect on the date of 107 publication of this document. Please review these documents 108 carefully, as they describe your rights and restrictions with respect 109 to this document. Code Components extracted from this document must 110 include Simplified BSD License text as described in Section 4.e of 111 the Trust Legal Provisions and are provided without warranty as 112 described in the Simplified BSD License. 114 Table of Contents 116 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 117 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 118 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 119 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 120 2.1. Support all NETCONF and RESTCONF transports . . . . . . . 5 121 2.2. Enable each transport to select which keys to use . . . . 6 122 2.3. Support authenticating NETCONF/RESTCONF clients 123 certificates . . . . . . . . . . . . . . . . . . . . . . 6 124 2.4. Support mapping authenticated NETCONF/RESTCONF client 125 certificates to usernames . . . . . . . . . . . . . . . . 6 126 2.5. Support both listening for connections and call home . . 6 127 2.6. For Call Home connections . . . . . . . . . . . . . . . . 6 128 2.6.1. Support more than one NETCONF/RESTCONF client . . . . 7 129 2.6.2. Support NETCONF/RESTCONF clients having more than one 130 endpoint . . . . . . . . . . . . . . . . . . . . . . 7 131 2.6.3. Support a reconnection strategy . . . . . . . . . . . 7 132 2.6.4. Support both persistent and periodic connections . . 7 133 2.6.5. Reconnection strategy for periodic connections . . . 7 134 2.6.6. Keep-alives for persistent connections . . . . . . . 8 135 2.6.7. Customizations for periodic connections . . . . . . . 8 136 3. High-Level Design . . . . . . . . . . . . . . . . . . . . . . 8 137 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 9 138 4.1. The System Keychain Model . . . . . . . . . . . . . . . . 9 139 4.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 9 140 4.1.2. Example Usage . . . . . . . . . . . . . . . . . . . . 10 141 4.1.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 18 143 4.2. The SSH Server Model . . . . . . . . . . . . . . . . . . 26 144 4.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 27 145 4.2.2. Example Usage . . . . . . . . . . . . . . . . . . . . 27 146 4.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 28 147 4.3. The TLS Server Model . . . . . . . . . . . . . . . . . . 32 148 4.3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32 149 4.3.2. Example Usage . . . . . . . . . . . . . . . . . . . . 33 150 4.3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 33 151 4.4. The NETCONF Server Model . . . . . . . . . . . . . . . . 37 152 4.4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 37 153 4.4.2. Example Usage . . . . . . . . . . . . . . . . . . . . 40 154 4.4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 43 155 4.5. The RESTCONF Server Model . . . . . . . . . . . . . . . . 53 156 4.5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 53 157 4.5.2. Example Usage . . . . . . . . . . . . . . . . . . . . 55 158 4.5.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 57 159 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 65 160 6. Security Considerations . . . . . . . . . . . . . . . . . . . 66 161 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 162 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 67 163 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 67 164 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 165 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 166 9.1. Normative References . . . . . . . . . . . . . . . . . . 68 167 9.2. Informative References . . . . . . . . . . . . . . . . . 70 168 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 71 169 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 71 170 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 71 171 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 71 172 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 71 173 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 72 174 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 72 175 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 72 176 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 73 177 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 74 178 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 74 179 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 181 1. Introduction 183 This draft defines a NETCONF [RFC6241] server configuration data 184 model and a RESTCONF [draft-ietf-netconf-restconf] server 185 configuration data model. These data models enable configuration of 186 the NETCONF and RESTCONF services themselves, including which 187 transports are supported, what ports the servers listen on, call-home 188 parameters, client authentication, and related parameters. 190 1.1. Terminology 192 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 1.2. Tree Diagrams 198 A simplified graphical representation of the data models is used in 199 this document. The meaning of the symbols in these diagrams is as 200 follows: 202 o Brackets "[" and "]" enclose list keys. 204 o Braces "{" and "}" enclose feature names, and indicate that the 205 named feature must be present for the subtree to be present. 207 o Abbreviations before data node names: "rw" means configuration 208 (read-write) and "ro" state data (read-only). 210 o Symbols after data node names: "?" means an optional node, "!" 211 means a presence container, and "*" denotes a list and leaf-list. 213 o Parentheses enclose choice and case nodes, and case nodes are also 214 marked with a colon (":"). 216 o Ellipsis ("...") stands for contents of subtrees that are not 217 shown. 219 2. Objectives 221 The primary purpose of the YANG modules defined herein is to enable 222 the configuration of the NETCONF and RESTCONF services on a network 223 element. This scope includes the following objectives: 225 2.1. Support all NETCONF and RESTCONF transports 227 The YANG module should support all current NETCONF and RESTCONF 228 transports, namely NETCONF over SSH [RFC6242], NETCONF over TLS 229 [RFC7589], and RESTCONF over TLS [draft-ietf-netconf-restconf], and 230 to be extensible to support future transports as necessary. 232 Because implementations may not support all transports, the module 233 should use YANG "feature" statements so that implementations can 234 accurately advertise which transports are supported. 236 2.2. Enable each transport to select which keys to use 238 Servers may have a multiplicity of host-keys or server-certificates 239 from which subsets may be selected for specific uses. For instance, 240 a NETCONF server may want to use one set of SSH host-keys when 241 listening on port 830, and a different set of SSH host-keys when 242 calling home. The data models provided herein should enable 243 configuration of which keys to use on a per-use basis. 245 2.3. Support authenticating NETCONF/RESTCONF clients certificates 247 When a certificate is used to authenticate a NETCONF or RESTCONF 248 client, there is a need to configure the server to know how to 249 authenticate the certificates. The server should be able to 250 authenticate the client's certificate either by using path-validation 251 to a configured trust anchor or by matching the client-certificate to 252 one previously configured. 254 2.4. Support mapping authenticated NETCONF/RESTCONF client certificates 255 to usernames 257 When a client certificate is used for TLS client authentication, the 258 NETCONF/RESTCONF server must be able to derive a username from the 259 authenticated certificate. Thus the modules defined herein should 260 enable this mapping to be configured. 262 2.5. Support both listening for connections and call home 264 The NETCONF and RESTCONF protocols were originally defined as having 265 the server opening a port to listen for client connections. More 266 recently the NETCONF working group defined support for call-home 267 ([draft-ietf-netconf-call-home]), enabling the server to initiate the 268 connection to the client, for both the NETCONF and RESTCONF 269 protocols. Thus the modules defined herein should enable 270 configuration for both listening for connections and calling home. 271 Because implementations may not support both listening for 272 connections and calling home, YANG "feature" statements should be 273 used so that implementation can accurately advertise the connection 274 types it supports. 276 2.6. For Call Home connections 278 The following objectives only pertain to call home connections. 280 2.6.1. Support more than one NETCONF/RESTCONF client 282 A NETCONF/RESTCONF server may be managed by more than one NETCONF/ 283 RESTCONF client. For instance, a deployment may have one client for 284 provisioning and another for fault monitoring. Therefore, when it is 285 desired for a server to initiate call home connections, it should be 286 able to do so to more than one client. 288 2.6.2. Support NETCONF/RESTCONF clients having more than one endpoint 290 An NETCONF/RESTCONF client managing a NETCONF/RESTCONF server may 291 implement a high-availability strategy employing a multiplicity of 292 active and/or passive endpoint. Therefore, when it is desired for a 293 server to initiate call home connections, it should be able to 294 connect to any of the client's endpoints. 296 2.6.3. Support a reconnection strategy 298 Assuming a NETCONF/RESTCONF client has more than one endpoint, then 299 it becomes necessary to configure how a NETCONF/RESTCONF server 300 should reconnect to the client should it lose its connection to one 301 the client's endpoints. For instance, the NETCONF/RESTCONF server 302 may start with first endpoint defined in a user-ordered list of 303 endpoints or with the last endpoints it was connected to. 305 2.6.4. Support both persistent and periodic connections 307 NETCONF/RESTCONF clients may vary greatly on how frequently they need 308 to interact with a NETCONF/RESTCONF server, how responsive 309 interactions need to be, and how many simultaneous connections they 310 can support. Some clients may need a persistent connection to 311 servers to optimize real-time interactions, while others prefer 312 periodic interactions in order to minimize resource requirements. 313 Therefore, when it is necessary for server to initiate connections, 314 it should be configurable if the connection is persistent or 315 periodic. 317 2.6.5. Reconnection strategy for periodic connections 319 The reconnection strategy should apply to both persistent and 320 periodic connections. How it applies to periodic connections becomes 321 clear when considering that a periodic "connection" is a logical 322 connection to a single server. That is, the periods of 323 unconnectedness are intentional as opposed to due to external 324 reasons. A periodic "connection" should always reconnect to the same 325 server until it is no longer able to, at which time the reconnection 326 strategy guides how to connect to another server. 328 2.6.6. Keep-alives for persistent connections 330 If a persistent connection is desired, it is the responsibility of 331 the connection initiator to actively test the "aliveness" of the 332 connection. The connection initiator must immediately work to 333 reestablish a persistent connection as soon as the connection is 334 lost. How often the connection should be tested is driven by 335 NETCONF/RESTCONF client requirements, and therefore keep-alive 336 settings should be configurable on a per-client basis. 338 2.6.7. Customizations for periodic connections 340 If a periodic connection is desired, it is necessary for the NETCONF/ 341 RESTCONF server to know how often it should connect. This frequency 342 determines the maximum amount of time a NETCONF/RESTCONF client may 343 have to wait to send data to a server. A server may connect to a 344 client before this interval expires if desired (e.g., to send data to 345 a client). 347 3. High-Level Design 349 The solution presented in this document defines a configurable 350 keychain object, reusable groupings for SSH and TLS based servers, 351 and, finally, the configurable NETCONF and RESTCONF server objects, 352 which are the primary purpose for this draft. Each of these are 353 defined in a distinct YANG module, thus a total of five YANG modules 354 are defined in this document. The relationship between these five 355 YANG modules is illustrated by the tree diagram below. 357 +--------------------+ 358 |ietf-system-keychain| 359 +--------------------+ 360 ^ ^ 361 | | 362 | | 363 +------------+ +------------+ 364 | | 365 +---------------+ +------------------+ 366 |ietf-ssh-server| | ietf-tls-server | 367 +---------------+ +------------------+ 368 ^ ^ ^ 369 | | | 370 | | | 371 | +--------------------+ | 372 | | | 373 +-------------------+ +--------------------+ 374 |ietf-netconf-server| |ietf-restconf-server| 375 +-------------------+ +--------------------+ 377 4. Solution 379 Each of the following five sections relate to one of the YANG modules 380 depicted by the figure above. 382 4.1. The System Keychain Model 384 The system keychain model defined in this section provides a 385 configurable object having the following characteristics: 387 o A semi-configurable list of private keys, each with one or more 388 associated certificates. Private keys MUST be either preinstalled 389 (e.g., an IDevID key), be generated by request, or be loaded by 390 request. Each private key is MAY have associated certificates, 391 either preinstalled or configured after creation. 393 o A configurable list of lists of trust anchor certificates. This 394 enables the server to have use-specific trust anchors. For 395 instance, one list of trust anchors might be used to authenticate 396 management connections (e.g., client certificate-based 397 authentication for NETCONF or RESTCONF connections), and a 398 different list of trust anchors might be used for when connecting 399 to a specific Internet-based service (e.g., a zero touch bootstrap 400 server). 402 o An RPC to generate a certificate signing request for an existing 403 private key, a passed subject, and an optional attributes. The 404 signed certificate returned from an external certificate authority 405 (CA) can be later set using a standard configuration change 406 request (e.g., ). 408 o An RPC to request the server to generate a new private key using 409 the specified algorithm and key length. 411 o An RPC to request the server to load a new private key. 413 4.1.1. Tree Diagram 414 module: ietf-system-keychain 415 +--rw keychain 416 +--rw private-keys 417 | +--rw private-key* [name] 418 | | +--rw name string 419 | | +--ro algorithm? kc:algorithms 420 | | +--ro key-length? uint32 421 | | +--ro public-key binary 422 | | +--rw certificate-chains 423 | | | +--rw certificate-chain* [name] 424 | | | +--rw name string 425 | | | +--rw certificate* binary 426 | | +---x generate-certificate-signing-request 427 | | +---w input 428 | | | +---w subject binary 429 | | | +---w attributes? binary 430 | | +--ro output 431 | | +--ro certificate-signing-request binary 432 | +---x generate-private-key 433 | | +---w input 434 | | +---w name string 435 | | +---w key-usage? enumeration 436 | | +---w algorithm kc:algorithms 437 | | +---w key-length? uint32 438 | +---x load-private-key 439 | +---w input 440 | +---w name string 441 | +---w private-key binary 442 +--rw trusted-certificates* [name] 443 +--rw name string 444 +--rw description? string 445 +--rw trusted-certificate* [name] 446 +--rw name string 447 +--rw certificate? binary 448 notifications: 449 +---n certificate-expiration 450 +--ro certificate instance-identifier 451 +--ro expiration-date yang:date-and-time 453 4.1.2. Example Usage 455 The following example illustrates the "generate-private-key" action 456 in use with the RESTCONF protocol and JSON encoding. 458 REQUEST 459 ------- 461 ['\' line wrapping added for formatting only] 463 POST https://example.com/restconf/data/ietf-system-keychain:keychain/\ 464 private-keys/generate-private-key HTTP/1.1 465 HOST: example.com 466 Content-Type: application/yang.operation+json 468 { 469 "ietf-system-keychain:input" : { 470 "name" : "ex-key-sect571r1", 471 "algorithm" : "sect571r1" 472 } 473 } 475 RESPONSE 476 -------- 478 HTTP/1.1 204 No Content 479 Date: Mon, 31 Oct 2015 11:01:00 GMT 480 Server: example-server 482 The following example illustrates the "load-private-key" action in 483 use with the RESTCONF protocol and JSON encoding. 485 REQUEST 486 ------- 488 ['\' line wrapping added for formatting only] 490 POST https://example.com/restconf/data/ietf-system-keychain:keychain/\ 491 private-keys/generate-private-key HTTP/1.1 492 HOST: example.com 493 Content-Type: application/yang.operation+xml 495 496 ex-key-sect571r1 497 498 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 499 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 500 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 501 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 502 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 503 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 504 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 505 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 506 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 507 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 508 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 509 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 510 511 513 RESPONSE 514 -------- 516 HTTP/1.1 204 No Content 517 Date: Mon, 31 Oct 2015 11:01:00 GMT 518 Server: example-server 520 The following example illustrates the "generate-certificate-signing- 521 request" action in use with the NETCONF protocol. 523 REQUEST 524 ------- 526 528 529 531 532 533 ex-key-sect571r1 534 535 536 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2R 537 manZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNlmO 538 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmR6Zgo= 539 540 541 bwtakWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvut4 542 arnZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYm 543 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmC6Rhp= 544 545 546 547 548 549 550 552 RESPONSE 553 -------- 555 557 559 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 560 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 561 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 562 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 563 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 564 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 565 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 566 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 567 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 568 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 569 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 570 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 571 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 572 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 573 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 574 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 575 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 576 577 579 The following example illustrates what a fully configured keychain 580 object might look like. The private-key shown below is consistent 581 with the generate-private-key and generate-certificate-signing- 582 request examples above. This example also assumes that the resulting 583 CA-signed certificate has been configured back onto the server. 584 Lastly, this example shows that three lists of trusted certificates 585 having been configured. 587 589 590 591 592 tpm-protected-key 593 sect571r1 594 595 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 596 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 597 JvO3NkZ25iO29pLmR6Zgo= 598 599 600 601 default-idevid-chain 602 603 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 604 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 605 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 606 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 607 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 608 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 609 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 610 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 611 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 612 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 613 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 614 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 615 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 616 617 618 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 619 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 620 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 621 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 622 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 623 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 624 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 625 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 626 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 627 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 628 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 629 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 630 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 631 SSUZJQ0FURS0tLS0tCg== 632 633 634 635 my-ldevid-chain 636 637 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 638 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 639 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 640 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 641 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 642 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 643 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 644 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 645 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 646 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 647 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 648 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 649 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 650 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 651 SWM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 652 653 654 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 655 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 656 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 657 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 658 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 659 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 660 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 661 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 662 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 663 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 664 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 665 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 666 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 667 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 668 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 669 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 670 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 671 672 673 674 676 678 679 680 explicitly-trusted-client-certs 681 682 Specific client authentication certificates that are to be 683 explicitly trusted NETCONF/RESTCONF clients. These are 684 needed for client certificates not signed by our CA. 685 686 687 George Jetson 688 689 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 690 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 691 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 692 RV0JCU2t2MXI2SFNHeUFUVkpwSmYyOWtXbUU0NEo5akJrQmdOVkhTTUVY 693 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 694 UxNQWtHQTFVRUJoTUNWVk14RURBT0JnTlZCQW9UQjJWNApZVzF3YkdVeE 695 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 696 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 697 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 698 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 699 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 700 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 701 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 702 TQzcjFZSjk0M1FQLzV5eGUKN2QxMkxCV0dxUjUrbEl5N01YL21ka2M4al 703 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 704 LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 705 706 707 708 Fred Flintstone 709 710 VlEVlFRREV3Vm9ZWEJ3ZVRDQm56QU5CZ2txaGtpRzl3MEJBUUVGQUFPQm 711 pRQXdnWWtDCmdZRUE1RzRFSWZsS1p2bDlXTW44eUhyM2hObUFRaUhVUzV 712 rRUpPQy9hSFA3eGJXQW1ra054ZStUa2hrZnBsL3UKbVhsTjhSZUd1ODhG 713 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 714 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 715 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 716 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 717 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 718 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 719 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 720 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 721 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 722 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 723 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 724 QWtUOCBDRVUUZJ0RUF== 725 726 727 729 730 731 deployment-specific-ca-certs 732 733 Trust anchors used only to authenticate NETCONF/RESTCONF 734 client connections. Since our security policy only allows 735 authentication for clients having a certificate signed by 736 our CA, we only configure its certificate below. 737 738 739 ca.example.com 740 741 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 742 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 743 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 744 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 745 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 746 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 747 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 748 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 749 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 750 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 751 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 752 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 753 RJSUJQFRStS0Cg== 754 755 756 758 759 760 common-ca-certs 761 762 Trusted certificates to authenticate common HTTPS servers. 763 These certificates are similar to those that might be 764 shipped with a web browser. 765 766 767 ex-certificate-authority 768 769 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 770 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 771 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 772 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 773 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 774 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 775 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 776 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 777 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 778 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 779 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 780 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 781 782 783 785 787 The following example illustrates a "certificate-expiration" 788 notification in XML. 790 ['\' line wrapping added for formatting only] 792 794 2016-07-08T00:01:00Z 795 797 798 /kc:keychain/kc:private-keys/kc:private-key/kc:certificate-chains\ 799 /kc:certificate-chain/kc:certificate[3] 800 801 2016-08-08T14:18:53-05:00 802 803 805 4.1.3. YANG Model 807 This YANG module makes extensive use of data types defined in 808 [RFC5280] and [RFC5958]. 810 file "ietf-system-keychain@2016-03-16.yang" 812 module ietf-system-keychain { 813 yang-version 1.1; 815 namespace "urn:ietf:params:xml:ns:yang:ietf-system-keychain"; 816 prefix "kc"; 818 import ietf-yang-types { // RFC 6991 819 prefix yang; 820 } 822 organization 823 "IETF NETCONF (Network Configuration) Working Group"; 825 contact 826 "WG Web: 827 WG List: 829 WG Chair: Mehmet Ersue 830 832 WG Chair: Mahesh Jethanandani 833 835 Editor: Kent Watsen 836 "; 838 description 839 "This module defines a keychain to centralize management of 840 security credentials. 842 Copyright (c) 2014 IETF Trust and the persons identified as 843 authors of the code. All rights reserved. 845 Redistribution and use in source and binary forms, with or 846 without modification, is permitted pursuant to, and subject 847 to the license terms contained in, the Simplified BSD 848 License set forth in Section 4.c of the IETF Trust's 849 Legal Provisions Relating to IETF Documents 850 (http://trustee.ietf.org/license-info). 852 This version of this YANG module is part of RFC VVVV; see 853 the RFC itself for full legal notices."; 855 revision "2016-03-16" { 856 description 857 "Initial version"; 858 reference 859 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 860 Models"; 861 } 863 typedef algorithms { 864 type enumeration { 865 enum rsa { description "The RSA algorithm."; } 866 enum secp192r1 { description "The secp192r1 algorithm."; } 867 enum secp256r1 { description "The secp256r1 algorithm."; } 868 enum secp384r1 { description "The secp384r1 algorithm."; } 869 enum secp521r1 { description "The secp521r1 algorithm."; } 870 // what about ecdh_x25519 and ecdh_x448 in TLS 1.3? 871 } 872 description 873 "Asymmetric key algorithms. This list has been trimmed down 874 to the minimal subset of algorithms recommended by the IETF. 875 Please see the Design Consideration section in RFC VVVV for 876 more information about this."; 877 } 879 container keychain { 880 description 881 "A list of private-keys and their associated certificates, as 882 well as lists of trusted certificates for client certificate 883 authentication. RPCs are provided to generate a new private 884 key and to generate a certificate signing requests."; 886 container private-keys { 887 description 888 "A list of private key maintained by the keychain."; 889 list private-key { 890 key name; 891 description 892 "A private key."; 893 leaf name { 894 type string; 895 description 896 "An arbitrary name for the private key."; 897 } 898 leaf algorithm { 899 type kc:algorithms; 900 config false; 901 description 902 "The algorithm used by the private key."; 903 } 904 leaf key-length { 905 type uint32; 906 config false; 907 description 908 "The key-length used by the private key."; 909 } 910 leaf public-key { 911 type binary; 912 config false; 913 mandatory true; 914 description 915 "An OneAsymmetricKey 'publicKey' structure as specified 916 by RFC 5958, Section 2 encoded using the ASN.1 917 distinguished encoding rules (DER), as specified 918 in ITU-T X.690."; 919 reference 920 "RFC 5958: 921 Asymmetric Key Packages 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 container certificate-chains { 929 description 930 "Certificate chains associated with this private key. 931 More than one chain per key is enabled to support, 932 for instance, a TPM-protected key that has associated 933 both IDevID and LDevID certificates."; 934 list certificate-chain { 935 key name; 936 description 937 "A certificate chain for this public key."; 938 leaf name { 939 type string; 940 description 941 "An arbitrary name for the certificate chain."; 942 } 943 leaf-list certificate { 944 type binary; 945 ordered-by user; 946 description 947 "An X.509 v3 certificate structure as specified by RFC 948 5280, Section 4 encoded using the ASN.1 distinguished 949 encoding rules (DER), as specified in ITU-T X.690. 950 The list of certificates that run from the server 951 certificate towards the trust anchor. The chain MAY 952 include the trust anchor certificate itself."; 953 reference 954 "RFC 5280: 955 Internet X.509 Public Key Infrastructure Certificate 956 and Certificate Revocation List (CRL) Profile. 957 ITU-T X.690: 958 Information technology - ASN.1 encoding rules: 959 Specification of Basic Encoding Rules (BER), 960 Canonical Encoding Rules (CER) and Distinguished 961 Encoding Rules (DER)."; 963 } 964 } 965 } 966 action generate-certificate-signing-request { 967 description 968 "Generates a certificate signing request structure for 969 the associated private key using the passed subject and 970 attribute values. Please review both the Security 971 Considerations and Design Considerations sections in 972 RFC VVVV for more information regarding this action 973 statement."; 974 input { 975 leaf subject { 976 type binary; 977 mandatory true; 978 description 979 "The 'subject' field from the CertificationRequestInfo 980 structure as specified by RFC 2986, Section 4.1 encoded 981 using the ASN.1 distinguished encoding rules (DER), as 982 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)."; 992 } 993 leaf attributes { 994 type binary; 995 description 996 "The 'attributes' field from the CertificationRequestInfo 997 structure as specified by RFC 2986, Section 4.1 encoded 998 using the ASN.1 distinguished encoding rules (DER), as 999 specified in ITU-T X.690."; 1000 reference 1001 "RFC 2986: 1002 PKCS #10: Certification Request Syntax Specification 1003 Version 1.7. 1004 ITU-T X.690: 1005 Information technology - ASN.1 encoding rules: 1006 Specification of Basic Encoding Rules (BER), 1007 Canonical Encoding Rules (CER) and Distinguished 1008 Encoding Rules (DER)."; 1009 } 1010 } 1011 output { 1012 leaf certificate-signing-request { 1013 type binary; 1014 mandatory true; 1015 description 1016 "A CertificationRequest structure as specified by RFC 1017 2986, Section 4.1 encoded using the ASN.1 distinguished 1018 encoding rules (DER), as specified in ITU-T X.690."; 1019 reference 1020 "RFC 2986: 1021 PKCS #10: Certification Request Syntax Specification 1022 Version 1.7. 1023 ITU-T X.690: 1024 Information technology - ASN.1 encoding rules: 1025 Specification of Basic Encoding Rules (BER), 1026 Canonical Encoding Rules (CER) and Distinguished 1027 Encoding Rules (DER)."; 1029 } 1030 } 1031 } 1032 } 1034 action generate-private-key { 1035 description 1036 "Requests the device to generate a private key using the 1037 specified algorithm and key length."; 1038 input { 1039 leaf name { 1040 type string; 1041 mandatory true; 1042 description 1043 "The name this private-key should have when listed 1044 in /keychain/private-keys. As such, the passed 1045 value must not match any existing 'name' value."; 1046 } 1047 leaf key-usage { 1048 type enumeration { 1049 enum signing { description "signing"; } 1050 enum encryption { description "encryption"; } 1051 // unclear if these should be somehow more 1052 // specific or varied. 1053 } 1054 description 1055 "An optional parameter further restricting the use of 1056 this key. Some algorithms inherently restrict use 1057 (DH for signing) whereas others can support more than 1058 one use (RSA). This flag forces the device to only 1059 allow the key to be used for the indicated purposes."; 1060 } 1061 leaf algorithm { 1062 type kc:algorithms; 1063 mandatory true; 1064 description 1065 "The algorithm to be used when generating the key."; 1066 } 1067 leaf key-length { 1068 type uint32; 1069 description 1070 "For algorithms that need a key length specified 1071 when generating the key."; 1072 } 1073 } 1074 } 1076 action load-private-key { 1077 description 1078 "Requests the device to load a private key"; 1079 input { 1080 leaf name { 1081 type string; 1082 mandatory true; 1083 description 1084 "The name this private-key should have when listed 1085 in /keychain/private-keys. As such, the passed 1086 value must not match any existing 'name' value."; 1087 } 1088 leaf private-key { 1089 type binary; 1090 mandatory true; 1091 description 1092 "An OneAsymmetricKey structure as specified by RFC 1093 5958, Section 2 encoded using the ASN.1 distinguished 1094 encoding rules (DER), as specified in ITU-T X.690. 1095 Note that this is the raw private with no shrouding 1096 to protect it. The strength of this private key 1097 MUST NOT be greater than the strength of the secure 1098 connection over which it is communicated. Devices 1099 SHOULD fail this request if ever that happens."; 1100 reference 1101 "RFC 5958: 1102 Asymmetric Key Packages 1103 ITU-T X.690: 1104 Information technology - ASN.1 encoding rules: 1105 Specification of Basic Encoding Rules (BER), 1106 Canonical Encoding Rules (CER) and Distinguished 1107 Encoding Rules (DER)."; 1108 } 1109 } 1110 } 1111 } 1113 list trusted-certificates { 1114 key name; 1115 description 1116 "A list of trusted certificates. Each list SHOULD be specific 1117 to a purpose. For instance, there could be one list for 1118 authenticating NETCONF/RESTCONF client certificates, and 1119 another list for authenticating manufacturer-signed data, 1120 and yet another list for authenticated web servers."; 1121 leaf name { 1122 type string; 1123 description 1124 "An arbitrary name for this list of trusted certificates."; 1125 } 1126 leaf description { 1127 type string; 1128 description 1129 "An arbitrary description for this list of trusted 1130 certificates."; 1131 } 1132 list trusted-certificate { 1133 key name; 1134 description 1135 "A trusted certificate for a specific use."; 1136 leaf name { 1137 type string; 1138 description 1139 "An arbitrary name for this trusted certificate."; 1140 } 1141 leaf certificate { 1142 type binary; 1143 description 1144 "An X.509 v3 certificate structure as specified by RFC 1145 5280, Section 4 encoded using the ASN.1 distinguished 1146 encoding rules (DER), as specified in ITU-T X.690."; 1147 reference 1148 "RFC 5280: 1149 Internet X.509 Public Key Infrastructure Certificate 1150 and Certificate Revocation List (CRL) Profile. 1151 ITU-T X.690: 1152 Information technology - ASN.1 encoding rules: 1153 Specification of Basic Encoding Rules (BER), 1154 Canonical Encoding Rules (CER) and Distinguished 1155 Encoding Rules (DER)."; 1156 } 1157 } 1158 } 1159 } 1160 notification certificate-expiration { 1161 description 1162 "A notification indicating that a configured certificate is 1163 either about to expire or has already expired. When to send 1164 notifications is an implementation specific decision, but 1165 it is RECOMMENDED that a notification be sent once a month 1166 for 3 months, then once a week for four weeks, and then once 1167 a day thereafter."; 1168 leaf certificate { 1169 type instance-identifier; 1170 mandatory true; 1171 description 1172 "Identifies which certificate is expiring or is expired."; 1173 } 1174 leaf expiration-date { 1175 type yang:date-and-time; 1176 mandatory true; 1177 description 1178 "Identifies the expiration date on the certificate."; 1179 } 1180 } 1181 } 1183 1185 4.2. The SSH Server Model 1187 The SSH Server model presented in this section presents two YANG 1188 groupings, one for a server that opens a socket to accept TCP 1189 connections on, and another for a server that has had the TCP 1190 connection opened for it already (e.g., inetd). 1192 The SSH Server model (like the TLS Server model presented below) is 1193 provided as a grouping so that it can be used in different contexts. 1194 For instance, the NETCONF Server model presented in Section 4.4 uses 1195 one grouping to configure a NETCONF server listening for connections 1196 and the other grouping to configure NETCONF call home. 1198 A shared characteristic between both groupings is the ability to 1199 configure which host key is presented to clients, the private key for 1200 which is held in the keychain configuration presented before. 1201 Another shared characteristic is the ability to configure which 1202 trusted CA or client certificates the server should be used to 1203 authenticate clients when using X.509 based client certificates 1204 [RFC6187]. 1206 4.2.1. Tree Diagram 1208 The following tree diagram represents the data model for the grouping 1209 used to configure an SSH server to listen for TCP connections. The 1210 tree diagram for the other grouping is not provided, but it is the 1211 same except without the "address" and "port" fields. 1213 NOTE: the diagram below shows "listening-ssh-server" as a YANG 1214 container (not a grouping). This temporary container was created 1215 only to enable the `pyang` tool to output the tree diagram, as 1216 groupings by themselves have no protocol accessible nodes, and hence 1217 `pyang` would output an empty tree diagram. 1219 module: ietf-ssh-server 1220 +--rw listening-ssh-server 1221 +--rw address? inet:ip-address 1222 +--rw port inet:port-number 1223 +--rw host-keys 1224 | +--rw host-key* [name] 1225 | +--rw name string 1226 | +--rw (type)? 1227 | +--:(public-key) 1228 | | +--rw public-key? -> /kc:keychain/private-keys/pri 1229 vate-key/name 1230 | +--:(certificate) 1231 | +--rw certificate? -> /kc:keychain/private-keys/pri 1232 vate-key/certificate-chains/certificate-chain/certificate {ssh-x509-cer 1233 ts}? 1234 +--rw client-cert-auth {ssh-x509-certs}? 1235 +--rw trusted-ca-certs? -> /kc:keychain/trusted-certific 1236 ates/name 1237 +--rw trusted-client-certs? -> /kc:keychain/trusted-certific 1238 ates/name 1240 4.2.2. Example Usage 1242 This section shows how it would appear if the temporary listening- 1243 ssh-server container just mentioned above were populated with some 1244 data. This example is consistent with the examples presented earlier 1245 in this document. 1247 1249 830 1250 1251 1252 deployment-specific-certificate 1253 ex-key-sect571r1-cert 1254 1255 1256 1257 1258 1259 deployment-specific-ca-certs 1260 1261 1262 explicitly-trusted-client-certs 1263 1264 1265 1267 4.2.3. YANG Model 1269 This YANG module has a normative reference to [RFC4253]. 1271 file "ietf-ssh-server@2016-03-16.yang" 1273 module ietf-ssh-server { 1274 yang-version 1.1; 1276 namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-server"; 1277 prefix "ts"; 1279 import ietf-inet-types { // RFC 6991 1280 prefix inet; 1281 } 1282 import ietf-system-keychain { 1283 prefix kc; // RFC VVVV 1284 revision-date 2016-03-16; 1285 } 1287 organization 1288 "IETF NETCONF (Network Configuration) Working Group"; 1290 contact 1291 "WG Web: 1292 WG List: 1293 WG Chair: Mehmet Ersue 1294 1296 WG Chair: Mahesh Jethanandani 1297 1299 Editor: Kent Watsen 1300 "; 1302 description 1303 "This module defines a reusable grouping for a SSH server that 1304 can be used as a basis for specific SSH server instances. 1306 Copyright (c) 2014 IETF Trust and the persons identified as 1307 authors of the code. All rights reserved. 1309 Redistribution and use in source and binary forms, with or 1310 without modification, is permitted pursuant to, and subject 1311 to the license terms contained in, the Simplified BSD 1312 License set forth in Section 4.c of the IETF Trust's 1313 Legal Provisions Relating to IETF Documents 1314 (http://trustee.ietf.org/license-info). 1316 This version of this YANG module is part of RFC VVVV; see 1317 the RFC itself for full legal notices."; 1319 revision "2016-03-16" { 1320 description 1321 "Initial version"; 1322 reference 1323 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 1324 Models"; 1325 } 1327 // features 1328 feature ssh-x509-certs { 1329 description 1330 "The ssh-x509-certs feature indicates that the NETCONF 1331 server supports RFC 6187"; 1332 reference 1333 "RFC 6187: X.509v3 Certificates for Secure Shell 1334 Authentication"; 1335 } 1337 // grouping 1338 grouping non-listening-ssh-server-grouping { 1339 description 1340 "A reusable grouping for a SSH server that can be used as a 1341 basis for specific SSH server instances."; 1343 container host-keys { 1344 description 1345 "The list of host-keys the SSH server will present when 1346 establishing a SSH connection."; 1347 list host-key { 1348 key name; 1349 min-elements 1; 1350 ordered-by user; 1351 description 1352 "An ordered list of host keys the SSH server will use to 1353 construct its ordered list of algorithms, when sending 1354 its SSH_MSG_KEXINIT message, as defined in Section 7.1 1355 of RFC 4253."; 1356 reference 1357 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 1358 leaf name { 1359 type string; 1360 mandatory true; 1361 description 1362 "An arbitrary name for this host-key"; 1363 } 1364 choice type { 1365 description 1366 "The type of host key being specified"; 1367 leaf public-key { 1368 type leafref { 1369 path "/kc:keychain/kc:private-keys/kc:private-key/" 1370 + "kc:name"; 1371 } 1372 description 1373 "The public key is actually identified by the name of 1374 its cooresponding private-key in the keychain."; 1375 } 1376 leaf certificate { 1377 if-feature ssh-x509-certs; 1378 type leafref { 1379 path "/kc:keychain/kc:private-keys/kc:private-key/" 1380 + "kc:certificate-chains/kc:certificate-chain/" 1381 + "kc:certificate"; 1382 } 1383 description 1384 "The name of a certificate in the keychain."; 1385 } 1386 } 1387 } 1389 } 1391 container client-cert-auth { 1392 if-feature ssh-x509-certs; 1393 description 1394 "A reference to a list of trusted certificate authority (CA) 1395 certificates and a reference to a list of trusted client 1396 certificates."; 1397 leaf trusted-ca-certs { 1398 type leafref { 1399 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1400 } 1401 description 1402 "A reference to a list of certificate authority (CA) 1403 certificates used by the SSH server to authenticate 1404 SSH client certificates."; 1405 } 1407 leaf trusted-client-certs { 1408 type leafref { 1409 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1410 } 1411 description 1412 "A reference to a list of client certificates used by 1413 the SSH server to authenticate SSH client certificates. 1414 A clients certificate is authenticated if it is an 1415 exact match to a configured trusted client certificate."; 1416 } 1417 } 1418 } 1420 grouping listening-ssh-server-grouping { 1421 description 1422 "A reusable grouping for a SSH server that can be used as a 1423 basis for specific SSH server instances."; 1424 leaf address { 1425 type inet:ip-address; 1426 description 1427 "The IP address of the interface to listen on. The SSH 1428 server will listen on all interfaces if no value is 1429 specified."; 1430 } 1431 leaf port { 1432 type inet:port-number; 1433 mandatory true; // will a default augmented in work? 1434 description 1435 "The local port number on this interface the SSH server 1436 listens on."; 1437 } 1438 uses non-listening-ssh-server-grouping; 1439 } 1441 container listening-ssh-server { 1442 description 1443 "This container will be removed by the RFC Editor. This 1444 container is currently only present in order to enable 1445 the `pyang` tool to generate tree diagram output of this 1446 module (used in the draft) as it otherwise would not 1447 contain any protocol accessible nodes to output."; 1449 uses listening-ssh-server-grouping; 1450 } 1451 } 1453 1455 4.3. The TLS Server Model 1457 The TLS Server model presented in this section presents two YANG 1458 groupings, one for a server that opens a socket to accept TCP 1459 connections on, and another for a server that has had the TCP 1460 connection opened for it already (e.g., inetd). 1462 The TLS Server model (like the SSH Server model presented above) is 1463 provided as a grouping so that it can be used in different contexts. 1464 For instance, the NETCONF Server model presented in Section 4.4 uses 1465 one grouping to configure a NETCONF server listening for connections 1466 and the other grouping to configure NETCONF call home. 1468 A shared characteristic between both groupings is the ability to 1469 configure which server certificate is presented to clients, the 1470 private key for which is held in the keychain model presented in 1471 Section 4.1. Another shared characteristic is the ability to 1472 configure which trusted CA or client certificates the server should 1473 be used to authenticate clients. 1475 4.3.1. Tree Diagram 1477 The following tree diagram represents the data model for the grouping 1478 used to configure an TLS server to listen for TCP connections. The 1479 tree diagram for the other grouping is not provided, but it is the 1480 same except without the "address" and "port" fields. 1482 NOTE: the diagram below shows "listening-ssh-server" as a YANG 1483 container (not a grouping). This temporary container was created 1484 only to enable the `pyang` tool to output the tree diagram, as 1485 groupings by themselves have no protocol accessible nodes, and hence 1486 `pyang` would output an empty tree diagram. 1488 module: ietf-tls-server 1489 +--rw listening-tls-server 1490 +--rw address? inet:ip-address 1491 +--rw port inet:port-number 1492 +--rw certificates 1493 | +--rw certificate* [name] 1494 | +--rw name -> /kc:keychain/private-keys/private-key/cert 1495 ificate-chains/certificate-chain/certificate 1496 +--rw client-auth 1497 +--rw trusted-ca-certs? -> /kc:keychain/trusted-certific 1498 ates/name 1499 +--rw trusted-client-certs? -> /kc:keychain/trusted-certific 1500 ates/name 1502 4.3.2. Example Usage 1504 1506 6513 1507 1508 1509 ex-key-sect571r1-cert 1510 1511 1512 1513 1514 deployment-specific-ca-certs 1515 1516 1517 explicitly-trusted-client-certs 1518 1519 1520 1522 4.3.3. YANG Model 1524 file "ietf-tls-server@2016-03-16.yang" 1526 module ietf-tls-server { 1527 yang-version 1.1; 1528 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 1529 prefix "ts"; 1531 import ietf-inet-types { // RFC 6991 1532 prefix inet; 1533 } 1534 import ietf-system-keychain { 1535 prefix kc; // RFC VVVV 1536 revision-date 2016-03-16; 1537 } 1539 organization 1540 "IETF NETCONF (Network Configuration) Working Group"; 1542 contact 1543 "WG Web: 1544 WG List: 1546 WG Chair: Mehmet Ersue 1547 1549 WG Chair: Mahesh Jethanandani 1550 1552 Editor: Kent Watsen 1553 "; 1555 description 1556 "This module defines a reusable grouping for a TLS server that 1557 can be used as a basis for specific TLS server instances. 1559 Copyright (c) 2014 IETF Trust and the persons identified as 1560 authors of the code. All rights reserved. 1562 Redistribution and use in source and binary forms, with or 1563 without modification, is permitted pursuant to, and subject 1564 to the license terms contained in, the Simplified BSD 1565 License set forth in Section 4.c of the IETF Trust's 1566 Legal Provisions Relating to IETF Documents 1567 (http://trustee.ietf.org/license-info). 1569 This version of this YANG module is part of RFC VVVV; see 1570 the RFC itself for full legal notices."; 1572 revision "2016-03-16" { 1573 description 1574 "Initial version"; 1576 reference 1577 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 1578 Models"; 1579 } 1581 // grouping 1582 grouping non-listening-tls-server-grouping { 1583 description 1584 "A reusable grouping for a TLS server that can be used as a 1585 basis for specific TLS server instances."; 1586 container certificates { 1587 description 1588 "The list of certificates the TLS server will present when 1589 establishing a TLS connection in its Certificate message, 1590 as defined in Section 7.4.2 in RRC 5246."; 1591 reference 1592 "RFC 5246: 1593 The Transport Layer Security (TLS) Protocol Version 1.2"; 1594 list certificate { 1595 key name; 1596 min-elements 1; 1597 description 1598 "An unordered list of certificates the TLS server can pick 1599 from when sending its Server Certificate message."; 1600 reference 1601 "RFC 5246: The TLS Protocol, Section 7.4.2"; 1602 leaf name { 1603 type leafref { 1604 path "/kc:keychain/kc:private-keys/kc:private-key/" 1605 + "kc:certificate-chains/kc:certificate-chain/" 1606 + "kc:certificate"; 1607 } 1608 description 1609 "The name of the certificate in the keychain."; 1610 } 1611 } 1612 } 1614 container client-auth { 1615 description 1616 "A reference to a list of trusted certificate authority (CA) 1617 certificates and a reference to a list of trusted client 1618 certificates."; 1619 leaf trusted-ca-certs { 1620 type leafref { 1621 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1622 } 1623 description 1624 "A reference to a list of certificate authority (CA) 1625 certificates used by the TLS server to authenticate 1626 TLS client certificates."; 1627 } 1629 leaf trusted-client-certs { 1630 type leafref { 1631 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1632 } 1633 description 1634 "A reference to a list of client certificates used by 1635 the TLS server to authenticate TLS client certificates. 1636 A clients certificate is authenticated if it is an 1637 exact match to a configured trusted client certificate."; 1638 } 1639 } 1640 } 1642 grouping listening-tls-server-grouping { 1643 description 1644 "A reusable grouping for a TLS server that can be used as a 1645 basis for specific TLS server instances."; 1646 leaf address { 1647 type inet:ip-address; 1648 description 1649 "The IP address of the interface to listen on. The TLS 1650 server will listen on all interfaces if no value is 1651 specified."; 1652 } 1653 leaf port { 1654 type inet:port-number; 1655 mandatory true; // will a default augmented in work? 1656 description 1657 "The local port number on this interface the TLTLS server 1658 listens on."; 1659 } 1660 uses non-listening-tls-server-grouping; 1661 } 1663 container listening-tls-server { 1664 description 1665 "This container will be removed by the RFC Editor. This 1666 container is currently only present in order to enable 1667 the `pyang` tool to generate tree diagram output of this 1668 module (used in the draft) as it otherwise would not 1669 contain any protocol accessible nodes to output."; 1670 uses listening-tls-server-grouping; 1671 } 1672 } 1674 1676 4.4. The NETCONF Server Model 1678 The NETCONF Server model presented in this section supports servers 1679 both listening for connections to accept as well as initiating call- 1680 home connections. This model also supports both the SSH and TLS 1681 transport protocols, using the SSH Server and TLS Server groupings 1682 presented in Section 4.2 and Section 4.3 respectively. All private 1683 keys and trusted certificates are held in the keychain model 1684 presented in Section 4.1. YANG feature statements are used to enable 1685 implementations to advertise which parts of the model the NETCONF 1686 server supports. 1688 4.4.1. Tree Diagram 1690 The following tree diagram uses line-wrapping in order to comply with 1691 xml2rfc validation. This is annoying as I find that drafts (even txt 1692 drafts) look just fine with long lines - maybe xml2rfc should remove 1693 this warning? - or pyang could have an option to suppress printing 1694 leafref paths? 1696 module: ietf-netconf-server 1697 +--rw netconf-server 1698 +--rw session-options 1699 | +--rw hello-timeout? uint16 1700 +--rw listen {(ssh-listen or tls-listen)}? 1701 | +--rw max-sessions? uint16 1702 | +--rw idle-timeout? uint16 1703 | +--rw endpoint* [name] 1704 | +--rw name string 1705 | +--rw (transport) 1706 | +--:(ssh) {ssh-listen}? 1707 | | +--rw ssh 1708 | | +--rw address? inet:ip-address 1709 | | +--rw port inet:port-number 1710 | | +--rw host-keys 1711 | | | +--rw host-key* [name] 1712 | | | +--rw name string 1713 | | | +--rw (type)? 1714 | | | +--:(public-key) 1715 | | | | +--rw public-key? -> /kc:keychain/p 1717 rivate-keys/private-key/name 1718 | | | +--:(certificate) 1719 | | | +--rw certificate? -> /kc:keychain/p 1720 rivate-keys/private-key/certificate-chains/certificate-chain/certificat 1721 e {ssh-x509-certs}? 1722 | | +--rw client-cert-auth {ssh-x509-certs}? 1723 | | +--rw trusted-ca-certs? -> /kc:keychain/t 1724 rusted-certificates/name 1725 | | +--rw trusted-client-certs? -> /kc:keychain/t 1726 rusted-certificates/name 1727 | +--:(tls) {tls-listen}? 1728 | +--rw tls 1729 | +--rw address? inet:ip-address 1730 | +--rw port inet:port-number 1731 | +--rw certificates 1732 | | +--rw certificate* [name] 1733 | | +--rw name -> /kc:keychain/private-keys/p 1734 rivate-key/certificate-chains/certificate-chain/certificate 1735 | +--rw client-auth 1736 | +--rw trusted-ca-certs? -> /kc:keychain/t 1737 rusted-certificates/name 1738 | +--rw trusted-client-certs? -> /kc:keychain/t 1739 rusted-certificates/name 1740 | +--rw cert-maps 1741 | +--rw cert-to-name* [id] 1742 | +--rw id uint32 1743 | +--rw fingerprint x509c2n:tls-fingerpr 1744 int 1745 | +--rw map-type identityref 1746 | +--rw name string 1747 +--rw call-home {(ssh-call-home or tls-call-home)}? 1748 +--rw netconf-client* [name] 1749 +--rw name string 1750 +--rw (transport) 1751 | +--:(ssh) {ssh-call-home}? 1752 | | +--rw ssh 1753 | | +--rw endpoints 1754 | | | +--rw endpoint* [name] 1755 | | | +--rw name string 1756 | | | +--rw address inet:host 1757 | | | +--rw port? inet:port-number 1758 | | +--rw host-keys 1759 | | | +--rw host-key* [name] 1760 | | | +--rw name string 1761 | | | +--rw (type)? 1762 | | | +--:(public-key) 1763 | | | | +--rw public-key? -> /kc:keychain/p 1764 rivate-keys/private-key/name 1765 | | | +--:(certificate) 1766 | | | +--rw certificate? -> /kc:keychain/p 1767 rivate-keys/private-key/certificate-chains/certificate-chain/certificat 1768 e {ssh-x509-certs}? 1769 | | +--rw client-cert-auth {ssh-x509-certs}? 1770 | | +--rw trusted-ca-certs? -> /kc:keychain/t 1771 rusted-certificates/name 1772 | | +--rw trusted-client-certs? -> /kc:keychain/t 1773 rusted-certificates/name 1774 | +--:(tls) {tls-call-home}? 1775 | +--rw tls 1776 | +--rw endpoints 1777 | | +--rw endpoint* [name] 1778 | | +--rw name string 1779 | | +--rw address inet:host 1780 | | +--rw port? inet:port-number 1781 | +--rw certificates 1782 | | +--rw certificate* [name] 1783 | | +--rw name -> /kc:keychain/private-keys/p 1784 rivate-key/certificate-chains/certificate-chain/certificate 1785 | +--rw client-auth 1786 | +--rw trusted-ca-certs? -> /kc:keychain/t 1787 rusted-certificates/name 1788 | +--rw trusted-client-certs? -> /kc:keychain/t 1789 rusted-certificates/name 1790 | +--rw cert-maps 1791 | +--rw cert-to-name* [id] 1792 | +--rw id uint32 1793 | +--rw fingerprint x509c2n:tls-fingerpr 1794 int 1795 | +--rw map-type identityref 1796 | +--rw name string 1797 +--rw connection-type 1798 | +--rw (connection-type)? 1799 | +--:(persistent-connection) 1800 | | +--rw persistent! 1801 | | +--rw idle-timeout? uint32 1802 | | +--rw keep-alives 1803 | | +--rw max-wait? uint16 1804 | | +--rw max-attempts? uint8 1805 | +--:(periodic-connection) 1806 | +--rw periodic! 1807 | +--rw idle-timeout? uint16 1808 | +--rw reconnect_timeout? uint16 1809 +--rw reconnect-strategy 1810 +--rw start-with? enumeration 1811 +--rw max-attempts? uint8 1813 4.4.2. Example Usage 1815 Configuring a NETCONF Server to listen for NETCONF client connections 1816 using both the SSH and TLS transport protocols, as well as 1817 configuring call-home to two NETCONF clients, one using SSH and the 1818 other using TLS. 1820 This example is consistent with other examples presented in this 1821 document. 1823 1825 1827 1828 1829 netconf/ssh 1830 1831
11.22.33.44
1832 1833 1834 my-rsa-key 1835 1836 1837 TPM key 1838 1839 1840 1841 1842 deployment-specific-ca-certs 1843 1844 1845 explicitly-trusted-client-certs 1846 1847 1848 1849 1851 1852 1853 netconf/tls 1854 1855
11.22.33.44
1856 1857 ex-key-sect571r1-cert 1858 1859 1860 1861 deployment-specific-ca-certs 1862 1863 1864 explicitly-trusted-client-certs 1865 1866 1867 1868 1 1869 11:0A:05:11:00 1870 x509c2n:san-any 1871 1872 1873 2 1874 B3:4F:A1:8C:54 1875 x509c2n:specified 1876 scooby-doo 1877 1878 1879 1880 1881 1883 1884 1886 1887 1888 config-mgr 1889 1890 1891 1892 east-data-center 1893
11.22.33.44
1894 1895 1896 west-data-center 1897
55.66.77.88
1898 1899 1900 1901 1902 TPM key 1903 1904 1905 1906 1907 deployment-specific-ca-certs 1908 1909 1910 explicitly-trusted-client-certs 1911 1912 1913 1914 1915 1916 300 1917 60 1918 1919 1920 1921 last-connected 1922 3 1923 1924 1926 1927 1928 event-correlator 1929 1930 1931 1932 east-data-center 1933
22.33.44.55
1934 1935 1936 west-data-center 1937
33.44.55.66
1938 1939 1940 1941 ex-key-sect571r1-cert 1942 1943 1944 1945 deployment-specific-ca-certs 1946 1947 1948 explicitly-trusted-client-certs 1949 1950 1951 1952 1 1953 11:0A:05:11:00 1954 x509c2n:san-any 1955 1956 1957 2 1958 B3:4F:A1:8C:54 1959 x509c2n:specified 1960 scooby-doo 1961 1962 1963 1964 1965 1966 1967 300 1968 1969 30 1970 3 1971 1972 1973 1974 1975 first-listed 1976 3 1977 1978 1980 1981 1983 4.4.3. YANG Model 1985 This YANG module imports YANG types from [RFC6991] and [RFC7407]. 1987 file "ietf-netconf-server@2016-03-16.yang" 1989 module ietf-netconf-server { 1990 yang-version 1.1; 1992 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; 1993 prefix "ncserver"; 1995 import ietf-inet-types { // RFC 6991 1996 prefix inet; 1997 } 1998 import ietf-x509-cert-to-name { // RFC 7407 1999 prefix x509c2n; 2000 } 2001 import ietf-ssh-server { // RFC VVVV 2002 prefix ss; 2003 revision-date 2016-03-16; 2005 } 2006 import ietf-tls-server { // RFC VVVV 2007 prefix ts; 2008 revision-date 2016-03-16; 2009 } 2011 organization 2012 "IETF NETCONF (Network Configuration) Working Group"; 2014 contact 2015 "WG Web: 2016 WG List: 2018 WG Chair: Mehmet Ersue 2019 2021 WG Chair: Mahesh Jethanandani 2022 2024 Editor: Kent Watsen 2025 "; 2027 description 2028 "This module contains a collection of YANG definitions for 2029 configuring NETCONF servers. 2031 Copyright (c) 2014 IETF Trust and the persons identified as 2032 authors of the code. All rights reserved. 2034 Redistribution and use in source and binary forms, with or 2035 without modification, is permitted pursuant to, and subject 2036 to the license terms contained in, the Simplified BSD 2037 License set forth in Section 4.c of the IETF Trust's 2038 Legal Provisions Relating to IETF Documents 2039 (http://trustee.ietf.org/license-info). 2041 This version of this YANG module is part of RFC VVVV; see 2042 the RFC itself for full legal notices."; 2044 revision "2016-03-16" { 2045 description 2046 "Initial version"; 2047 reference 2048 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 2049 Models"; 2050 } 2051 // Features 2053 feature ssh-listen { 2054 description 2055 "The ssh-listen feature indicates that the NETCONF server 2056 supports opening a port to accept NETCONF over SSH 2057 client connections."; 2058 reference 2059 "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; 2060 } 2062 feature ssh-call-home { 2063 description 2064 "The ssh-call-home feature indicates that the NETCONF 2065 server supports initiating a NETCONF over SSH call 2066 home connection to NETCONF clients."; 2067 reference 2068 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 2069 } 2071 feature tls-listen { 2072 description 2073 "The tls-listen feature indicates that the NETCONF server 2074 supports opening a port to accept NETCONF over TLS 2075 client connections."; 2076 reference 2077 "RFC 7589: Using the NETCONF Protocol over Transport 2078 Layer Security (TLS) with Mutual X.509 2079 Authentication"; 2080 } 2082 feature tls-call-home { 2083 description 2084 "The tls-call-home feature indicates that the NETCONF 2085 server supports initiating a NETCONF over TLS call 2086 home connection to NETCONF clients."; 2087 reference 2088 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 2089 } 2091 feature ssh-x509-certs { 2092 description 2093 "The ssh-x509-certs feature indicates that the NETCONF 2094 server supports RFC 6187"; 2095 reference 2096 "RFC 6187: X.509v3 Certificates for Secure Shell 2097 Authentication"; 2098 } 2099 // top-level container (groupings below) 2100 container netconf-server { 2101 description 2102 "Top-level container for NETCONF server configuration."; 2104 container session-options { // SHOULD WE REMOVE THIS ALTOGETHER? 2105 description 2106 "NETCONF session options, independent of transport 2107 or connection strategy."; 2108 leaf hello-timeout { 2109 type uint16; 2110 units "seconds"; 2111 default 600; 2112 description 2113 "Specifies the maximum number of seconds that a SSH/TLS 2114 connection may wait for a hello message to be received. 2115 A connection will be dropped if no hello message is 2116 received before this number of seconds elapses. If set 2117 to zero, then the server will wait forever for a hello 2118 message."; 2119 } 2120 } 2122 container listen { 2123 if-feature "(ssh-listen or tls-listen)"; 2124 description 2125 "Configures listen behavior"; 2126 leaf max-sessions { 2127 type uint16; 2128 default 0; 2129 description 2130 "Specifies the maximum number of concurrent sessions 2131 that can be active at one time. The value 0 indicates 2132 that no artificial session limit should be used."; 2133 } 2134 leaf idle-timeout { 2135 type uint16; 2136 units "seconds"; 2137 default 3600; // one hour 2138 description 2139 "Specifies the maximum number of seconds that a NETCONF 2140 session may remain idle. A NETCONF session will be dropped 2141 if it is idle for an interval longer than this number of 2142 seconds. If set to zero, then the server will never drop 2143 a session because it is idle. Sessions that have a 2144 notification subscription active are never dropped."; 2145 } 2146 list endpoint { 2147 key name; 2148 description 2149 "List of endpoints to listen for NETCONF connections on."; 2150 leaf name { 2151 type string; 2152 description 2153 "An arbitrary name for the NETCONF listen endpoint."; 2154 } 2155 choice transport { 2156 mandatory true; 2157 description 2158 "Selects between available transports."; 2159 case ssh { 2160 if-feature ssh-listen; 2161 container ssh { 2162 description 2163 "SSH-specific listening configuration for inbound 2164 connections."; 2165 uses ss:listening-ssh-server-grouping { 2166 refine port { 2167 default 830; 2168 } 2169 } 2170 } 2171 } 2172 case tls { 2173 if-feature tls-listen; 2174 container tls { 2175 description 2176 "TLS-specific listening configuration for inbound 2177 connections."; 2178 uses ts:listening-tls-server-grouping { 2179 refine port { 2180 default 6513; 2181 } 2182 augment "client-auth" { 2183 description 2184 "Augments in the cert-to-name structure."; 2185 uses cert-maps-grouping; 2186 } 2187 } 2188 } 2189 } 2190 } 2191 } 2192 } 2194 container call-home { 2195 if-feature "(ssh-call-home or tls-call-home)"; 2196 description 2197 "Configures call-home behavior"; 2198 list netconf-client { 2199 key name; 2200 description 2201 "List of NETCONF clients the NETCONF server is to initiate 2202 call-home connections to."; 2203 leaf name { 2204 type string; 2205 description 2206 "An arbitrary name for the remote NETCONF client."; 2207 } 2208 choice transport { 2209 mandatory true; 2210 description 2211 "Selects between available transports."; 2212 case ssh { 2213 if-feature ssh-call-home; 2214 container ssh { 2215 description 2216 "Specifies SSH-specific call-home transport 2217 configuration."; 2218 uses endpoints-container { 2219 refine endpoints/endpoint/port { 2220 default 7777; 2221 } 2222 } 2223 uses ss:non-listening-ssh-server-grouping; 2224 } 2225 } 2226 case tls { 2227 if-feature tls-call-home; 2228 container tls { 2229 description 2230 "Specifies TLS-specific call-home transport 2231 configuration."; 2232 uses endpoints-container { 2233 refine endpoints/endpoint/port { 2234 default 8888; 2235 } 2236 } 2237 uses ts:non-listening-tls-server-grouping { 2238 augment "client-auth" { 2239 description 2240 "Augments in the cert-to-name structure."; 2241 uses cert-maps-grouping; 2242 } 2244 } 2245 } 2246 } 2247 } 2248 container connection-type { 2249 description 2250 "Indicates the kind of connection to use."; 2251 choice connection-type { 2252 description 2253 "Selects between available connection types."; 2254 case persistent-connection { 2255 container persistent { 2256 presence true; 2257 description 2258 "Maintain a persistent connection to the NETCONF 2259 client. If the connection goes down, immediately 2260 start trying to reconnect to it, using the 2261 reconnection strategy. 2263 This connection type minimizes any NETCONF client 2264 to NETCONF server data-transfer delay, albeit at 2265 the expense of holding resources longer."; 2266 leaf idle-timeout { 2267 type uint32; 2268 units "seconds"; 2269 default 86400; // one day; 2270 description 2271 "Specifies the maximum number of seconds that a 2272 a NETCONF session may remain idle. A NETCONF 2273 session will be dropped if it is idle for an 2274 interval longer than this number of seconds. 2275 If set to zero, then the server will never drop 2276 a session because it is idle. Sessions that 2277 have a notification subscription active are 2278 never dropped."; 2279 } 2280 container keep-alives { 2281 description 2282 "Configures the keep-alive policy, to proactively 2283 test the aliveness of the SSH/TLS client. An 2284 unresponsive SSH/TLS client will be dropped after 2285 approximately max-attempts * max-wait seconds."; 2286 reference 2287 "RFC YYYY: NETCONF Call Home and RESTCONF Call 2288 Home, Section 3.1, item S6"; 2289 leaf max-wait { 2290 type uint16 { 2291 range "1..max"; 2293 } 2294 units seconds; 2295 default 30; 2296 description 2297 "Sets the amount of time in seconds after which 2298 if no data has been received from the SSH/TLS 2299 client, a SSH/TLS-level message will be sent 2300 to test the aliveness of the SSH/TLS client."; 2301 } 2302 leaf max-attempts { 2303 type uint8; 2304 default 3; 2305 description 2306 "Sets the number of maximum number of sequential 2307 keep-alive messages that can fail to obtain a 2308 response from the SSH/TLS client before assuming 2309 the SSH/TLS client is no longer alive."; 2310 } 2311 } 2312 } 2313 } 2314 case periodic-connection { 2315 container periodic { 2316 presence true; 2317 description 2318 "Periodically connect to the NETCONF client, so that 2319 the NETCONF client may deliver messages pending for 2320 the NETCONF server. The NETCONF client is expected 2321 to close the connection when it is ready to release 2322 it, thus starting the NETCONF server's timer until 2323 next connection."; 2324 leaf idle-timeout { 2325 type uint16; 2326 units "seconds"; 2327 default 300; // five minutes 2328 description 2329 "Specifies the maximum number of seconds that a 2330 a NETCONF session may remain idle. A NETCONF 2331 session will be dropped if it is idle for an 2332 interval longer than this number of seconds. 2333 If set to zero, then the server will never drop 2334 a session because it is idle. Sessions that 2335 have a notification subscription active are 2336 never dropped."; 2337 } 2338 leaf reconnect_timeout { 2339 type uint16 { 2340 range "1..max"; 2342 } 2343 units minutes; 2344 default 60; 2345 description 2346 "Sets the maximum amount of unconnected time the 2347 NETCONF server will wait before re-establishing 2348 a connection to the NETCONF client. The NETCONF 2349 server may initiate a connection before this 2350 time if desired (e.g., to deliver an event 2351 notification message)."; 2352 } 2353 } 2354 } 2355 } 2356 } 2357 container reconnect-strategy { 2358 description 2359 "The reconnection strategy guides how a NETCONF server 2360 reconnects to a NETCONF client, after discovering its 2361 connection to the client has dropped. The NETCONF 2362 server starts with the specified endpoint and tries 2363 to connect to it max-attempts times before trying the 2364 next endpoint in the list (round robin)."; 2365 leaf start-with { 2366 type enumeration { 2367 enum first-listed { 2368 description 2369 "Indicates that reconnections should start with 2370 the first endpoint listed."; 2371 } 2372 enum last-connected { 2373 description 2374 "Indicates that reconnections should start with 2375 the endpoint last connected to. If no previous 2376 connection has ever been established, then the 2377 first endpoint configured is used. NETCONF 2378 servers SHOULD be able to remember the last 2379 endpoint connected to across reboots."; 2380 } 2381 } 2382 default first-listed; 2383 description 2384 "Specifies which of the NETCONF client's endpoints the 2385 NETCONF server should start with when trying to connect 2386 to the NETCONF client."; 2387 } 2388 leaf max-attempts { 2389 type uint8 { 2390 range "1..max"; 2391 } 2392 default 3; 2393 description 2394 "Specifies the number times the NETCONF server tries to 2395 connect to a specific endpoint before moving on to the 2396 next endpoint in the list (round robin)."; 2397 } 2398 } 2399 } 2400 } 2401 } 2403 grouping cert-maps-grouping { 2404 description 2405 "A grouping that defines a container around the 2406 cert-to-name structure defined in RFC 7407."; 2407 container cert-maps { 2408 uses x509c2n:cert-to-name; 2409 description 2410 "The cert-maps container is used by a TLS-based NETCONF 2411 server to map the NETCONF client's presented X.509 2412 certificate to a NETCONF username. If no matching and 2413 valid cert-to-name list entry can be found, then the 2414 NETCONF server MUST close the connection, and MUST NOT 2415 accept NETCONF messages over it."; 2416 reference 2417 "RFC WWWW: NETCONF over TLS, Section 7"; 2418 } 2419 } 2421 grouping endpoints-container { 2422 description 2423 "This grouping is used by both the ssh and tls containers 2424 for call-home configurations."; 2425 container endpoints { 2426 description 2427 "Container for the list of endpoints."; 2428 list endpoint { 2429 key name; 2430 min-elements 1; 2431 ordered-by user; 2432 description 2433 "User-ordered list of endpoints for this NETCONF client. 2434 Defining more than one enables high-availability."; 2435 leaf name { 2436 type string; 2437 description 2438 "An arbitrary name for this endpoint."; 2439 } 2440 leaf address { 2441 type inet:host; 2442 mandatory true; 2443 description 2444 "The IP address or hostname of the endpoint. If a 2445 hostname is configured and the DNS resolution results 2446 in more than one IP address, the NETCONF server 2447 will process the IP addresses as if they had been 2448 explicitly configured in place of the hostname."; 2449 } 2450 leaf port { 2451 type inet:port-number; 2452 description 2453 "The IP port for this endpoint. The NETCONF server will 2454 use the IANA-assigned well-known port if no value is 2455 specified."; 2456 } 2457 } 2458 } 2459 } 2461 } 2463 2465 4.5. The RESTCONF Server Model 2467 The RESTCONF Server model presented in this section supports servers 2468 both listening for connections to accept as well as initiating call- 2469 home connections. This model supports the TLS transport only, as 2470 RESTCONF only supports HTTPS, using the TLS Server groupings 2471 presented in Section 4.3. All private keys and trusted certificates 2472 are held in the keychain model presented in Section 4.1. YANG 2473 feature statements are used to enable implementations to advertise 2474 which parts of the model the RESTCONF server supports. 2476 4.5.1. Tree Diagram 2478 The following tree diagram uses line-wrapping in order to comply with 2479 xml2rfc validation. This is annoying as I find that drafts (even txt 2480 drafts) look just fine with long lines - maybe xml2rfc should remove 2481 this warning? - or pyang could have an option to suppress printing 2482 leafref paths? 2484 module: ietf-restconf-server 2485 +--rw restconf-server 2486 +--rw listen {tls-listen}? 2487 | +--rw max-sessions? uint16 2488 | +--rw endpoint* [name] 2489 | +--rw name string 2490 | +--rw (transport) 2491 | +--:(tls) {tls-listen}? 2492 | +--rw tls 2493 | +--rw address? inet:ip-address 2494 | +--rw port inet:port-number 2495 | +--rw certificates 2496 | | +--rw certificate* [name] 2497 | | +--rw name -> /kc:keychain/private-keys/p 2498 rivate-key/certificate-chains/certificate-chain/certificate 2499 | +--rw client-auth 2500 | +--rw trusted-ca-certs? -> /kc:keychain/t 2501 rusted-certificates/name 2502 | +--rw trusted-client-certs? -> /kc:keychain/t 2503 rusted-certificates/name 2504 | +--rw cert-maps 2505 | +--rw cert-to-name* [id] 2506 | +--rw id uint32 2507 | +--rw fingerprint x509c2n:tls-fingerpr 2508 int 2509 | +--rw map-type identityref 2510 | +--rw name string 2511 +--rw call-home {tls-call-home}? 2512 +--rw restconf-client* [name] 2513 +--rw name string 2514 +--rw (transport) 2515 | +--:(tls) {tls-call-home}? 2516 | +--rw tls 2517 | +--rw endpoints 2518 | | +--rw endpoint* [name] 2519 | | +--rw name string 2520 | | +--rw address inet:host 2521 | | +--rw port? inet:port-number 2522 | +--rw certificates 2523 | | +--rw certificate* [name] 2524 | | +--rw name -> /kc:keychain/private-keys/p 2525 rivate-key/certificate-chains/certificate-chain/certificate 2526 | +--rw client-auth 2527 | +--rw trusted-ca-certs? -> /kc:keychain/t 2528 rusted-certificates/name 2529 | +--rw trusted-client-certs? -> /kc:keychain/t 2530 rusted-certificates/name 2531 | +--rw cert-maps 2532 | +--rw cert-to-name* [id] 2533 | +--rw id uint32 2534 | +--rw fingerprint x509c2n:tls-fingerpr 2535 int 2536 | +--rw map-type identityref 2537 | +--rw name string 2538 +--rw connection-type 2539 | +--rw (connection-type)? 2540 | +--:(persistent-connection) 2541 | | +--rw persistent! 2542 | | +--rw keep-alives 2543 | | +--rw max-wait? uint16 2544 | | +--rw max-attempts? uint8 2545 | +--:(periodic-connection) 2546 | +--rw periodic! 2547 | +--rw reconnect-timeout? uint16 2548 +--rw reconnect-strategy 2549 +--rw start-with? enumeration 2550 +--rw max-attempts? uint8 2552 4.5.2. Example Usage 2554 Configuring a RESTCONF Server to listen for RESTCONF client 2555 connections, as well as configuring call-home to one RESTCONF client. 2557 This example is consistent with other examples presented in this 2558 document. 2560 2563 2564 2565 2566 netconf/tls 2567 2568
11.22.33.44
2569 2570 ex-key-sect571r1-cert 2571 2572 2573 2574 deployment-specific-ca-certs 2575 2576 2577 explicitly-trusted-client-certs 2578 2579 2580 2581 1 2582 11:0A:05:11:00 2583 x509c2n:san-any 2584 2585 2586 2 2587 B3:4F:A1:8C:54 2588 x509c2n:specified 2589 scooby-doo 2590 2591 2592 2593 2595 2596 2598 2599 2600 2601 config-manager 2602 2603 2604 2605 east-data-center 2606
22.33.44.55
2607 2608 2609 west-data-center 2610
33.44.55.66
2611 2612 2613 2614 ex-key-sect571r1-cert 2615 2616 2617 2618 deployment-specific-ca-certs 2619 2620 2621 explicitly-trusted-client-certs 2622 2623 2624 2625 1 2626 11:0A:05:11:00 2627 x509c2n:san-any 2629 2630 2631 2 2632 B3:4F:A1:8C:54 2633 x509c2n:specified 2634 scooby-doo 2635 2636 2637 2638 2639 2640 2641 300 2642 60 2643 2644 2645 2646 last-connected 2647 3 2648 2649 2650 2652 2654 4.5.3. YANG Model 2656 This YANG module imports YANG types from [RFC6991] and [RFC7407]. 2658 file "ietf-restconf-server@2016-03-16.yang" 2660 module ietf-restconf-server { 2661 yang-version 1.1; 2663 namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server"; 2664 prefix "rcserver"; 2666 //import ietf-netconf-acm { 2667 // prefix nacm; // RFC 6536 2668 //} 2669 import ietf-inet-types { // RFC 6991 2670 prefix inet; 2671 } 2672 import ietf-x509-cert-to-name { // RFC 7407 2673 prefix x509c2n; 2674 } 2675 import ietf-tls-server { // RFC VVVV 2676 prefix ts; 2677 revision-date 2016-03-16; 2678 } 2680 organization 2681 "IETF NETCONF (Network Configuration) Working Group"; 2683 contact 2684 "WG Web: 2685 WG List: 2687 WG Chair: Mehmet Ersue 2688 2690 WG Chair: Mahesh Jethanandani 2691 2693 Editor: Kent Watsen 2694 "; 2696 description 2697 "This module contains a collection of YANG definitions for 2698 configuring RESTCONF servers. 2700 Copyright (c) 2014 IETF Trust and the persons identified as 2701 authors of the code. All rights reserved. 2703 Redistribution and use in source and binary forms, with or 2704 without modification, is permitted pursuant to, and subject 2705 to the license terms contained in, the Simplified BSD 2706 License set forth in Section 4.c of the IETF Trust's 2707 Legal Provisions Relating to IETF Documents 2708 (http://trustee.ietf.org/license-info). 2710 This version of this YANG module is part of RFC VVVV; see 2711 the RFC itself for full legal notices."; 2713 revision "2016-03-16" { 2714 description 2715 "Initial version"; 2716 reference 2717 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 2718 Models"; 2719 } 2721 // Features 2722 feature tls-listen { 2723 description 2724 "The listen feature indicates that the RESTCONF server 2725 supports opening a port to listen for incoming RESTCONF 2726 client connections."; 2727 reference 2728 "RFC XXXX: RESTCONF Protocol"; 2729 } 2731 feature tls-call-home { 2732 description 2733 "The call-home feature indicates that the RESTCONF server 2734 supports initiating connections to RESTCONF clients."; 2735 reference 2736 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 2737 } 2739 feature client-cert-auth { 2740 description 2741 "The client-cert-auth feature indicates that the RESTCONF 2742 server supports the ClientCertificate authentication scheme."; 2743 reference 2744 "RFC ZZZZ: Client Authentication over New TLS Connection"; 2745 } 2747 // top-level container 2748 container restconf-server { 2749 description 2750 "Top-level container for RESTCONF server configuration."; 2752 container listen { 2753 if-feature tls-listen; 2754 description 2755 "Configures listen behavior"; 2756 leaf max-sessions { 2757 type uint16; 2758 default 0; // should this be 'max'? 2759 description 2760 "Specifies the maximum number of concurrent sessions 2761 that can be active at one time. The value 0 indicates 2762 that no artificial session limit should be used."; 2763 } 2764 list endpoint { 2765 key name; 2766 description 2767 "List of endpoints to listen for RESTCONF connections on."; 2768 leaf name { 2769 type string; 2770 description 2771 "An arbitrary name for the RESTCONF listen endpoint."; 2772 } 2773 choice transport { 2774 mandatory true; 2775 description 2776 "Selects between available transports."; 2777 case tls { 2778 if-feature tls-listen; 2779 container tls { 2780 description 2781 "TLS-specific listening configuration for inbound 2782 connections."; 2783 uses ts:listening-tls-server-grouping { 2784 refine port { 2785 default 443; 2786 } 2787 augment "client-auth" { 2788 description 2789 "Augments in the cert-to-name structure."; 2790 uses cert-maps-grouping; 2791 } 2792 } 2793 } 2794 } 2795 } 2796 } 2797 } 2799 container call-home { 2800 if-feature tls-call-home; 2801 description 2802 "Configures call-home behavior"; 2803 list restconf-client { 2804 key name; 2805 description 2806 "List of RESTCONF clients the RESTCONF server is to 2807 initiate call-home connections to."; 2808 leaf name { 2809 type string; 2810 description 2811 "An arbitrary name for the remote RESTCONF client."; 2812 } 2813 choice transport { 2814 mandatory true; 2815 description 2816 "Selects between TLS and any transports augmented in."; 2818 case tls { 2819 if-feature tls-call-home; 2820 container tls { 2821 description 2822 "Specifies TLS-specific call-home transport 2823 configuration."; 2824 uses endpoints-container { 2825 refine endpoints/endpoint/port { 2826 default 9999; 2827 } 2828 } 2829 uses ts:non-listening-tls-server-grouping { 2830 augment "client-auth" { 2831 description 2832 "Augments in the cert-to-name structure."; 2833 uses cert-maps-grouping; 2834 } 2835 } 2836 } 2837 } 2838 } 2839 container connection-type { 2840 description 2841 "Indicates the RESTCONF client's preference for how the 2842 RESTCONF server's connection is maintained."; 2843 choice connection-type { 2844 description 2845 "Selects between available connection types."; 2846 case persistent-connection { 2847 container persistent { 2848 presence true; 2849 description 2850 "Maintain a persistent connection to the RESTCONF 2851 client. If the connection goes down, immediately 2852 start trying to reconnect to it, using the 2853 reconnection strategy. 2855 This connection type minimizes any RESTCONF client 2856 to RESTCONF server data-transfer delay, albeit at 2857 the expense of holding resources longer."; 2859 container keep-alives { 2860 description 2861 "Configures the keep-alive policy, to proactively 2862 test the aliveness of the TLS client. An 2863 unresponsive TLS client will be dropped after 2864 approximately (max-attempts * max-wait) seconds."; 2865 reference 2866 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home, 2867 Section 3.1, item S6"; 2868 leaf max-wait { 2869 type uint16 { 2870 range "1..max"; 2871 } 2872 units seconds; 2873 default 30; 2874 description 2875 "Sets the amount of time in seconds after which 2876 if no data has been received from the TLS 2877 client, a TLS-level message will be sent to 2878 test the aliveness of the TLS client."; 2879 } 2880 leaf max-attempts { 2881 type uint8; 2882 default 3; 2883 description 2884 "Sets the number of sequential keep-alive messages 2885 that can fail to obtain a response from the TLS 2886 client before assuming the TLS client is no 2887 longer alive."; 2888 } 2889 } 2890 } 2891 } 2892 case periodic-connection { 2893 container periodic { 2894 presence true; 2895 description 2896 "Periodically connect to the RESTCONF client, so that 2897 the RESTCONF client may deliver messages pending for 2898 the RESTCONF server. The RESTCONF client is expected 2899 to close the connection when it is ready to release 2900 it, thus starting the RESTCONF server's timer until 2901 next connection."; 2902 leaf reconnect-timeout { 2903 type uint16 { 2904 range "1..max"; 2905 } 2906 units minutes; 2907 default 60; 2908 description 2909 "The maximum amount of unconnected time the RESTCONF 2910 server will wait before re-establishing a connection 2911 to the RESTCONF client. The RESTCONF server may 2912 initiate a connection before this time if desired 2913 (e.g., to deliver a notification)."; 2915 } 2916 } 2917 } 2918 } 2919 } 2920 container reconnect-strategy { 2921 description 2922 "The reconnection strategy guides how a RESTCONF server 2923 reconnects to an RESTCONF client, after losing a connection 2924 to it, even if due to a reboot. The RESTCONF server starts 2925 with the specified endpoint and tries to connect to it 2926 max-attempts times before trying the next endpoint in the 2927 list (round robin)."; 2928 leaf start-with { 2929 type enumeration { 2930 enum first-listed { 2931 description 2932 "Indicates that reconnections should start with 2933 the first endpoint listed."; 2934 } 2935 enum last-connected { 2936 description 2937 "Indicates that reconnections should start with 2938 the endpoint last connected to. If no previous 2939 connection has ever been established, then the 2940 first endpoint configured is used. RESTCONF 2941 servers SHOULD be able to remember the last 2942 endpoint connected to across reboots."; 2943 } 2944 } 2945 default first-listed; 2946 description 2947 "Specifies which of the RESTCONF client's endpoints the 2948 RESTCONF server should start with when trying to connect 2949 to the RESTCONF client."; 2950 } 2951 leaf max-attempts { 2952 type uint8 { 2953 range "1..max"; 2954 } 2955 default 3; 2956 description 2957 "Specifies the number times the RESTCONF server tries to 2958 connect to a specific endpoint before moving on to the 2959 next endpoint in the list (round robin)."; 2960 } 2961 } 2962 } 2964 } 2965 } 2967 grouping cert-maps-grouping { 2968 description 2969 "A grouping that defines a container around the 2970 cert-to-name structure defined in RFC 7407."; 2971 container cert-maps { 2972 uses x509c2n:cert-to-name; 2973 description 2974 "The cert-maps container is used by a TLS-based RESTCONF 2975 server to map the RESTCONF client's presented X.509 2976 certificate to a RESTCONF username. If no matching and 2977 valid cert-to-name list entry can be found, then the 2978 RESTCONF server MUST close the connection, and MUST NOT 2979 accept RESTCONF messages over it."; 2980 reference 2981 "RFC XXXX: The RESTCONF Protocol"; 2982 } 2983 } 2985 grouping endpoints-container { 2986 description 2987 "This grouping is used by tls container for call-home 2988 configurations."; 2989 container endpoints { 2990 description 2991 "Container for the list of endpoints."; 2992 list endpoint { 2993 key name; 2994 min-elements 1; 2995 ordered-by user; 2996 description 2997 "User-ordered list of endpoints for this RESTCONF client. 2998 Defining more than one enables high-availability."; 2999 leaf name { 3000 type string; 3001 description 3002 "An arbitrary name for this endpoint."; 3003 } 3004 leaf address { 3005 type inet:host; 3006 mandatory true; 3007 description 3008 "The IP address or hostname of the endpoint. If a 3009 hostname is configured and the DNS resolution results 3010 in more than one IP address, the RESTCONF server 3011 will process the IP addresses as if they had been 3012 explicitly configured in place of the hostname."; 3013 } 3014 leaf port { 3015 type inet:port-number; 3016 description 3017 "The IP port for this endpoint. The RESTCONF server will 3018 use the IANA-assigned well-known port if no value is 3019 specified."; 3020 } 3021 } 3022 } 3023 } 3025 } 3027 3029 5. Design Considerations 3031 The manner that the both local and remote endpoints have been 3032 specified in the ietf-netconf-server and ietf-rest-server modules 3033 does not directly support virtual routing and forwarding (VRF), 3034 though they have been specified in such a way to enable external 3035 modules will augment in VRF designations when needed. 3037 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 3038 signing-request" action. The use of Certificate Request Message 3039 Format (CRMF) [RFC4211] was considered, but is was unclear if there 3040 was market demand for it, and so support for CRMF has been left out 3041 of this specification. If it is desired to support CRMF in the 3042 future, placing a "choice" statement in both the input and output 3043 statements, along with an "if-feature" statement on the CRMF option, 3044 would enable a backwards compatible solution. 3046 This document puts a limit of the number of elliptical curves 3047 supported. This was done to match industry trends in IETF best 3048 practice (e.g., matching work being done in TLS 1.3). In additional 3049 algorithms are needed, they MAY be augmented in by another module, or 3050 added directly in a future version of this document. 3052 Both this document and Key Chain YANG Data Model 3053 [draft-ietf-rtgwg-yang-key-chain] define keychain YANG modules. The 3054 authors looked at this and agree that they two modules server 3055 different purposes and hence not worth merging into one document. To 3056 underscore this further, this document renamed its module from "ietf- 3057 keychain" to "ietf-system-keychain" and that other document renamed 3058 its module from "ietf-key-chain" to "ietf-routing-key-chain". 3060 For the trusted-certificates list, Trust Anchor Format [RFC5914] was 3061 evaluated and deemed inappropriate due to this document's need to 3062 also support pinning. That is, pinning a client-certificate to 3063 support NETCONF over TLS client authentication. 3065 6. Security Considerations 3067 This document defines a keychain mechanism that is entrusted with the 3068 safe keeping of private keys, and the safe keeping of trusted 3069 certificates. Nowhere in this API is there an ability to access 3070 (read out) a private key once it is known to the keychain. Further, 3071 associated public keys and attributes (e.g., algorithm name, key 3072 length, etc.) are read-only. That said, this document allows for the 3073 deletion of private keys and their certificates, as well the deletion 3074 of trusted certificates. Access control mechanisms (e.g., NACM 3075 [RFC6536]) MUST be in place so as to authorize such client actions. 3076 Further, whilst the data model allows for private keys and trusted 3077 certificates in general to be deleted, implementations should be well 3078 aware that some privates keys (e.g., those in a TPM) and some trusted 3079 certificates, should never be deleted, regardless if the 3080 authorization mechanisms would generally allow for such actions. 3082 For the "generate-certificate-signing-request" action, it is 3083 RECOMMENDED that devices implement assert channel binding [RFC5056], 3084 so as to ensure that the application layer that sent the request is 3085 the same as the device authenticated in the secure transport layer 3086 was established. 3088 This document defines a data model that includes a list of private 3089 keys. These private keys MAY be deleted using standard NETCONF or 3090 RESTCONF operations (e.g., ). Implementations SHOULD 3091 automatically (without explicit request) zeroize these keys in the 3092 most secure manner available, so as to prevent the remnants of their 3093 persisted storage locations from being analyzed in any meaningful 3094 way. 3096 The keychain module define within this document defines the "load- 3097 private-key" action enabling a device to load a client-supplied 3098 private key. This is a private key with no shrouding to protect it. 3099 The strength of this private key MUST NOT be greater than the 3100 strength of the underlying secure transport connection over which it 3101 is communicated. Devices SHOULD fail this request if ever the 3102 strength of the private key is greater then the strength of the 3103 underlying transport. 3105 A denial of service (DoS) attack MAY occur if the NETCONF server 3106 limits the maximum number of NETCONF sessions it will accept (i.e. 3107 the 'max-sessions' field in the ietf-netconf-server module is not 3108 zero) and either the "hello-timeout" or "idle-timeout" fields in 3109 ietf-netconf-server module have been set to indicate the NETCONF 3110 server should wait forever (i.e. set to zero). 3112 7. IANA Considerations 3114 7.1. The IETF XML Registry 3116 This document registers two URIs in the IETF XML registry [RFC2119]. 3117 Following the format in [RFC3688], the following registrations are 3118 requested: 3120 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server 3121 Registrant Contact: The NETCONF WG of the IETF. 3122 XML: N/A, the requested URI is an XML namespace. 3124 URI: urn:ietf:params:xml:ns:yang:ietf-restconf-server 3125 Registrant Contact: The NETCONF WG of the IETF. 3126 XML: N/A, the requested URI is an XML namespace. 3128 7.2. The YANG Module Names Registry 3130 This document registers five YANG modules in the YANG Module Names 3131 registry [RFC6020]. Following the format in [RFC6020], the the 3132 following registrations are requested: 3134 name: ietf-system-keychain 3135 namespace: urn:ietf:params:xml:ns:yang:ietf-system-keychain 3136 prefix: kc 3137 reference: RFC VVVV 3139 name: ietf-ssh-server 3140 namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-server 3141 prefix: ssvr 3142 reference: RFC VVVV 3144 name: ietf-tls-server 3145 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 3146 prefix: tsvr 3147 reference: RFC VVVV 3149 name: ietf-netconf-server 3150 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server 3151 prefix: ncsvr 3152 reference: RFC VVVV 3154 name: ietf-restconf-server 3155 namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server 3156 prefix: rcsvr 3157 reference: RFC VVVV 3159 8. Acknowledgements 3161 The authors would like to thank for following for lively discussions 3162 on list and in the halls (ordered by last name): Andy Bierman, Martin 3163 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 3164 Ladislav Lhotka, Radek Krejci, Tom Petch, Phil Shafer, Sean Turner, 3165 and Bert Wijnen. 3167 Juergen Schoenwaelder and was partly funded by Flamingo, a Network of 3168 Excellence project (ICT-318488) supported by the European Commission 3169 under its Seventh Framework Programme. 3171 9. References 3173 9.1. Normative References 3175 [draft-ietf-netconf-call-home] 3176 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 3177 draft-ieft-netconf-call-home-02 (work in progress), 2014. 3179 [draft-ietf-netconf-restconf] 3180 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3181 Protocol", draft-ieft-netconf-restconf-04 (work in 3182 progress), 2014. 3184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3185 Requirement Levels", BCP 14, RFC 2119, 3186 DOI 10.17487/RFC2119, March 1997, 3187 . 3189 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3190 Request Syntax Specification Version 1.7", RFC 2986, 3191 DOI 10.17487/RFC2986, November 2000, 3192 . 3194 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 3195 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 3196 January 2006, . 3198 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3199 Housley, R., and W. Polk, "Internet X.509 Public Key 3200 Infrastructure Certificate and Certificate Revocation List 3201 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3202 . 3204 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3205 DOI 10.17487/RFC5958, August 2010, 3206 . 3208 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3209 the Network Configuration Protocol (NETCONF)", RFC 6020, 3210 DOI 10.17487/RFC6020, October 2010, 3211 . 3213 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 3214 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 3215 March 2011, . 3217 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3218 and A. Bierman, Ed., "Network Configuration Protocol 3219 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3220 . 3222 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3223 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3224 . 3226 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3227 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3228 . 3230 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 3231 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 3232 December 2014, . 3234 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 3235 NETCONF Protocol over Transport Layer Security (TLS) with 3236 Mutual X.509 Authentication", RFC 7589, 3237 DOI 10.17487/RFC7589, June 2015, 3238 . 3240 9.2. Informative References 3242 [draft-ietf-rtgwg-yang-key-chain] 3243 Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, J., and Y. 3244 Yang, "Key Chain YANG Data Model", draft-ietf-rtgwg-yang- 3245 key-chain (work in progress), 2016, 3246 . 3249 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3250 DOI 10.17487/RFC3688, January 2004, 3251 . 3253 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3254 Certificate Request Message Format (CRMF)", RFC 4211, 3255 DOI 10.17487/RFC4211, September 2005, 3256 . 3258 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 3259 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 3260 . 3262 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 3263 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 3264 . 3266 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 3267 Protocol (NETCONF) Access Control Model", RFC 6536, 3268 DOI 10.17487/RFC6536, March 2012, 3269 . 3271 Appendix A. Change Log 3273 A.1. 00 to 01 3275 o Restructured document so it flows better 3277 o Added trusted-ca-certs and trusted-client-certs objects into the 3278 ietf-system-tls-auth module 3280 A.2. 01 to 02 3282 o removed the "one-to-many" construct 3284 o removed "address" as a key field 3286 o removed "network-manager" terminology 3288 o moved open issues to github issues 3290 o brought TLS client auth back into model 3292 A.3. 02 to 03 3294 o fixed tree diagrams and surrounding text 3296 A.4. 03 to 04 3298 o reduced the number of grouping statements 3300 o removed psk-maps and associated feature statements 3302 o added ability for listen/call-home instances to specify which 3303 host-keys/certificates (of all listed) to use 3305 o clarified that last-connected should span reboots 3307 o added missing "objectives" for selecting which keys to use, 3308 authenticating client-certificates, and mapping authenticated 3309 client-certificates to usernames 3311 o clarified indirect client certificate authentication 3313 o added keep-alive configuration for listen connections 3315 o added global-level NETCONF session parameters 3317 A.5. 04 to 05 3319 o Removed all refs to the old ietf-system-tls-auth module 3321 o Removed YANG 1.1 style if-feature statements (loss some 3322 expressiveness) 3324 o Removed the read-only (config false) lists of SSH host-keys and 3325 TLS certs 3327 o Added an if-feature around session-options container 3329 o Added ability to configure trust-anchors for SSH X.509 client 3330 certs 3332 o Now imports by revision, per best practice 3334 o Added support for RESTCONF server 3336 o Added RFC Editor instructions 3338 A.6. 05 to 06 3340 o Removed feature statement on the session-options container (issue 3341 #21). 3343 o Added NACM statements to YANG modules for sensitive nodes (issue 3344 #24). 3346 o Fixed default RESTCONF server port value to be 443 (issue #26). 3348 o Added client-cert-auth subtree to ietf-restconf-server module 3349 (issue #27). 3351 o Updated draft-ietf-netmod-snmp-cfg reference to RFC 7407 (issue 3352 #28). 3354 o Added description statements for groupings (issue #29). 3356 o Added description for braces to tree diagram section (issue #30). 3358 o Renamed feature from "rfc6187" to "ssh-x509-certs" (issue #31). 3360 A.7. 06 to 07 3362 o Replaced "application" with "NETCONF/RESTCONF client" (issue #32). 3364 o Reverted back to YANG 1.1 if-feature statements (issue #34). 3366 o Removed import by revisions (issue #36). 3368 o Removed groupings only used once (issue #37). 3370 o Removed upper-bound on hello-timeout, idle-timeout, and max- 3371 sessions (issue #38). 3373 o Clarified that when no listen address is configured, the NETCONF/ 3374 RESTCONF server will listen on all addresses (issue #41). 3376 o Update keep-alive reference to new section in Call Home draft 3377 (issue #42). 3379 o Modified connection-type/persistent/keep-alives/interval-secs 3380 default value, removed the connection-type/periodic/linger-secs 3381 node, and also removed the reconnect-strategy/interval-secs node 3382 (issue #43). 3384 o Clarified how last-connected reconnection type should work across 3385 reboots (issue #44). 3387 o Clarified how DNS-expanded hostnames should be processed (issue 3388 #45). 3390 o Removed text on how to implement keep-alives (now in the call-home 3391 draft) and removed the keep-alive configuration for listen 3392 connections (issue #46). 3394 o Clarified text for .../periodic-connection/timeout-mins (issue 3395 #47). 3397 o Fixed description on the "trusted-ca-certs" leaf-list (issue #48). 3399 o Added optional keychain-based solution in appendix A (issue #49). 3401 o Fixed description text for the interval-secs leaf (issue #50). 3403 o moved idle-time into the listen, persistent, and periodic subtrees 3404 (issue #51). 3406 o put presence statements on containers where it makes sense (issue 3407 #53). 3409 A.8. 07 to 08 3411 o Per WG consensus, replaced body with the keychain-based approach 3412 described in -07's Appendix. 3414 o Added a lot of introductory text, improved examples, and what not. 3416 A.9. 08 to 09 3418 o Renamed ietf-keychain to ietf-system-keychain to disambiguate from 3419 the routing area working group's keychain model (they similarly 3420 renamed their model from ietf-key-chain to ietf-routing-key- 3421 chain). 3423 o Added an action statement to ietf-system-keychain to load a 3424 private key. 3426 o Added a notification statement to ietf-system-keychain to notify 3427 when a certificate is nearing expiration and beyond. 3429 o Converted all binary types to use ASN.1 DER encoding. 3431 o Added a Design Considerations section. 3433 o Filled in the Security Considerations section. 3435 o Removed the Other Considerations section. 3437 o Extended the Editorial Note section. 3439 o Added many Normative and Informative references. 3441 Appendix B. Open Issues 3443 Please see: https://github.com/netconf-wg/server-model/issues. 3445 Authors' Addresses 3447 Kent Watsen 3448 Juniper Networks 3450 EMail: kwatsen@juniper.net 3452 Juergen Schoenwaelder 3453 Jacobs University Bremen 3455 EMail: j.schoenwaelder@jacobs-university.de