idnits 2.17.1 draft-ietf-netconf-server-model-08.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 410 has weird spacing: '...request bin...' == Line 822 has weird spacing: '... field in th...' == Line 1443 has weird spacing: '...rw name str...' == Line 1481 has weird spacing: '...erprint x50...' == Line 1494 has weird spacing: '...address ine...' == (6 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 (October 9, 2015) is 3116 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track J. Schoenwaelder 5 Expires: April 11, 2016 Jacobs University Bremen 6 October 9, 2015 8 NETCONF Server and RESTCONF Server Configuration Models 9 draft-ietf-netconf-server-model-08 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 Artwork in this document contains shorthand references to drafts in 38 progress. Please apply the following replacements: 40 o "VVVV" --> the assigned RFC value for this draft 42 o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf 44 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home 46 Artwork in this document contains placeholder values for ports 47 pending IANA assignment from "draft-ietf-netconf-call-home". Please 48 apply the following replacements: 50 o "7777" --> the assigned port value for "netconf-ch-ssh" 52 o "8888" --> the assigned port value for "netconf-ch-tls" 54 o "9999" --> the assigned port value for "restconf-ch-tls" 56 Artwork in this document contains placeholder values for the date of 57 publication of this draft. Please apply the following replacement: 59 o "2015-10-09" --> the publication date of this draft 61 The following two Appendix sections are to be removed prior to 62 publication: 64 o Appendix B. Change Log 66 o Appendix C. Open Issues 68 Status of This Memo 70 This Internet-Draft is submitted in full conformance with the 71 provisions of BCP 78 and BCP 79. 73 Internet-Drafts are working documents of the Internet Engineering 74 Task Force (IETF). Note that other groups may also distribute 75 working documents as Internet-Drafts. The list of current Internet- 76 Drafts is at http://datatracker.ietf.org/drafts/current/. 78 Internet-Drafts are draft documents valid for a maximum of six months 79 and may be updated, replaced, or obsoleted by other documents at any 80 time. It is inappropriate to use Internet-Drafts as reference 81 material or to cite them other than as "work in progress." 83 This Internet-Draft will expire on April 11, 2016. 85 Copyright Notice 87 Copyright (c) 2015 IETF Trust and the persons identified as the 88 document authors. All rights reserved. 90 This document is subject to BCP 78 and the IETF Trust's Legal 91 Provisions Relating to IETF Documents 92 (http://trustee.ietf.org/license-info) in effect on the date of 93 publication of this document. Please review these documents 94 carefully, as they describe your rights and restrictions with respect 95 to this document. Code Components extracted from this document must 96 include Simplified BSD License text as described in Section 4.e of 97 the Trust Legal Provisions and are provided without warranty as 98 described in the Simplified BSD License. 100 Table of Contents 102 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 103 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 104 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 105 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 106 2.1. Support all NETCONF and RESTCONF transports . . . . . . . 5 107 2.2. Enable each transport to select which keys to use . . . . 5 108 2.3. Support authenticating NETCONF/RESTCONF clients 109 certificates . . . . . . . . . . . . . . . . . . . . . . 5 110 2.4. Support mapping authenticated NETCONF/RESTCONF client 111 certificates to usernames . . . . . . . . . . . . . . . . 5 112 2.5. Support both listening for connections and call home . . 6 113 2.6. For Call Home connections . . . . . . . . . . . . . . . . 6 114 2.6.1. Support more than one NETCONF/RESTCONF client . . . . 6 115 2.6.2. Support NETCONF/RESTCONF clients having more than one 116 endpoint . . . . . . . . . . . . . . . . . . . . . . 6 117 2.6.3. Support a reconnection strategy . . . . . . . . . . . 6 118 2.6.4. Support both persistent and periodic connections . . 6 119 2.6.5. Reconnection strategy for periodic connections . . . 7 120 2.6.6. Keep-alives for persistent connections . . . . . . . 7 121 2.6.7. Customizations for periodic connections . . . . . . . 7 122 3. High-Level Design . . . . . . . . . . . . . . . . . . . . . . 7 123 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 8 124 4.1. The Keychain Model . . . . . . . . . . . . . . . . . . . 8 125 4.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 9 126 4.1.2. Example Usage . . . . . . . . . . . . . . . . . . . . 9 127 4.1.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 15 128 4.2. The SSH Server Model . . . . . . . . . . . . . . . . . . 20 129 4.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 21 130 4.2.2. Example Usage . . . . . . . . . . . . . . . . . . . . 21 131 4.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 22 132 4.3. The TLS Server Model . . . . . . . . . . . . . . . . . . 26 133 4.3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 26 134 4.3.2. Example Usage . . . . . . . . . . . . . . . . . . . . 27 135 4.3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 27 136 4.4. The NETCONF Server Model . . . . . . . . . . . . . . . . 31 137 4.4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 31 138 4.4.2. Example Usage . . . . . . . . . . . . . . . . . . . . 33 139 4.4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 37 140 4.5. The RESTCONF Server Model . . . . . . . . . . . . . . . . 47 141 4.5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 47 142 4.5.2. Example Usage . . . . . . . . . . . . . . . . . . . . 49 143 4.5.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 51 144 5. Security Considerations . . . . . . . . . . . . . . . . . . . 59 145 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 146 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 60 147 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 148 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 149 9.1. Normative References . . . . . . . . . . . . . . . . . . 61 150 9.2. Informative References . . . . . . . . . . . . . . . . . 61 151 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 62 152 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 62 153 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 62 154 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 62 155 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 62 156 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 63 157 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 63 158 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 63 159 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 64 160 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 65 162 1. Introduction 164 This draft defines a NETCONF [RFC6241] server configuration data 165 model and a RESTCONF [draft-ietf-netconf-restconf] server 166 configuration data model. These data models enable configuration of 167 the NETCONF and RESTCONF services themselves, including which 168 transports are supported, what ports the servers listen on, call-home 169 parameters, client authentication, and related parameters. 171 1.1. Terminology 173 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 1.2. Tree Diagrams 179 A simplified graphical representation of the data models is used in 180 this document. The meaning of the symbols in these diagrams is as 181 follows: 183 o Brackets "[" and "]" enclose list keys. 185 o Braces "{" and "}" enclose feature names, and indicate that the 186 named feature must be present for the subtree to be present. 188 o Abbreviations before data node names: "rw" means configuration 189 (read-write) and "ro" state data (read-only). 191 o Symbols after data node names: "?" means an optional node, "!" 192 means a presence container, and "*" denotes a list and leaf-list. 194 o Parentheses enclose choice and case nodes, and case nodes are also 195 marked with a colon (":"). 197 o Ellipsis ("...") stands for contents of subtrees that are not 198 shown. 200 2. Objectives 202 The primary purpose of the YANG modules defined herein is to enable 203 the configuration of the NETCONF and RESTCONF services on a network 204 element. This scope includes the following objectives: 206 2.1. Support all NETCONF and RESTCONF transports 208 The YANG module should support all current NETCONF and RESTCONF 209 transports, namely NETCONF over SSH [RFC6242], NETCONF over TLS 210 [RFC7589], and RESTCONF over TLS [draft-ietf-netconf-restconf], and 211 to be extensible to support future transports as necessary. 213 Because implementations may not support all transports, the module 214 should use YANG "feature" statements so that implementations can 215 accurately advertise which transports are supported. 217 2.2. Enable each transport to select which keys to use 219 Servers may have a multiplicity of host-keys or server-certificates 220 from which subsets may be selected for specific uses. For instance, 221 a NETCONF server may want to use one set of SSH host-keys when 222 listening on port 830, and a different set of SSH host-keys when 223 calling home. The data models provided herein should enable 224 configuration of which keys to use on a per-use basis. 226 2.3. Support authenticating NETCONF/RESTCONF clients certificates 228 When a certificate is used to authenticate a NETCONF or RESTCONF 229 client, there is a need to configure the server to know how to 230 authenticate the certificates. The server should be able to 231 authenticate the client's certificate either by using path-validation 232 to a configured trust anchor or by matching the client-certificate to 233 one previously configured. 235 2.4. Support mapping authenticated NETCONF/RESTCONF client certificates 236 to usernames 238 When a client certificate is used for TLS client authentication, the 239 NETCONF/RESTCONF server must be able to derive a username from the 240 authenticated certificate. Thus the modules defined herein should 241 enable this mapping to be configured. 243 2.5. Support both listening for connections and call home 245 The NETCONF and RESTCONF protocols were originally defined as having 246 the server opening a port to listen for client connections. More 247 recently the NETCONF working group defined support for call-home 248 ([draft-ietf-netconf-call-home]), enabling the server to initiate the 249 connection to the client, for both the NETCONF and RESTCONF 250 protocols. Thus the modules defined herein should enable 251 configuration for both listening for connections and calling home. 252 Because implementations may not support both listening for 253 connections and calling home, YANG "feature" statements should be 254 used so that implementation can accurately advertise the connection 255 types it supports. 257 2.6. For Call Home connections 259 The following objectives only pertain to call home connections. 261 2.6.1. Support more than one NETCONF/RESTCONF client 263 A NETCONF/RESTCONF server may be managed by more than one NETCONF/ 264 RESTCONF client. For instance, a deployment may have one client for 265 provisioning and another for fault monitoring. Therefore, when it is 266 desired for a server to initiate call home connections, it should be 267 able to do so to more than one client. 269 2.6.2. Support NETCONF/RESTCONF clients having more than one endpoint 271 An NETCONF/RESTCONF client managing a NETCONF/RESTCONF server may 272 implement a high-availability strategy employing a multiplicity of 273 active and/or passive endpoint. Therefore, when it is desired for a 274 server to initiate call home connections, it should be able to 275 connect to any of the client's endpoints. 277 2.6.3. Support a reconnection strategy 279 Assuming a NETCONF/RESTCONF client has more than one endpoint, then 280 it becomes necessary to configure how a NETCONF/RESTCONF server 281 should reconnect to the client should it lose its connection to one 282 the client's endpoints. For instance, the NETCONF/RESTCONF server 283 may start with first endpoint defined in a user-ordered list of 284 endpoints or with the last endpoints it was connected to. 286 2.6.4. Support both persistent and periodic connections 288 NETCONF/RESTCONF clients may vary greatly on how frequently they need 289 to interact with a NETCONF/RESTCONF server, how responsive 290 interactions need to be, and how many simultaneous connections they 291 can support. Some clients may need a persistent connection to 292 servers to optimize real-time interactions, while others prefer 293 periodic interactions in order to minimize resource requirements. 294 Therefore, when it is necessary for server to initiate connections, 295 it should be configurable if the connection is persistent or 296 periodic. 298 2.6.5. Reconnection strategy for periodic connections 300 The reconnection strategy should apply to both persistent and 301 periodic connections. How it applies to periodic connections becomes 302 clear when considering that a periodic "connection" is a logical 303 connection to a single server. That is, the periods of 304 unconnectedness are intentional as opposed to due to external 305 reasons. A periodic "connection" should always reconnect to the same 306 server until it is no longer able to, at which time the reconnection 307 strategy guides how to connect to another server. 309 2.6.6. Keep-alives for persistent connections 311 If a persistent connection is desired, it is the responsibility of 312 the connection initiator to actively test the "aliveness" of the 313 connection. The connection initiator must immediately work to 314 reestablish a persistent connection as soon as the connection is 315 lost. How often the connection should be tested is driven by 316 NETCONF/RESTCONF client requirements, and therefore keep-alive 317 settings should be configurable on a per-client basis. 319 2.6.7. Customizations for periodic connections 321 If a periodic connection is desired, it is necessary for the NETCONF/ 322 RESTCONF server to know how often it should connect. This frequency 323 determines the maximum amount of time a NETCONF/RESTCONF client may 324 have to wait to send data to a server. A server may connect to a 325 client before this interval expires if desired (e.g., to send data to 326 a client). 328 3. High-Level Design 330 The solution presented in this document defines a configurable 331 keychain object, reusable groupings for SSH and TLS based servers, 332 and, finally, the configurable NETCONF and RESTCONF server objects, 333 which are the primary purpose for this draft. Each of these are 334 defined in a distinct YANG module, thus a total of five YANG modules 335 are defined in this document. The relationship between these five 336 YANG modules is illustrated by the tree diagram below. 338 +-------------+ 339 |ietf-keychain| 340 +-------------+ 341 ^ ^ 342 | | 343 | | 344 +------------+ +------------+ 345 | | 346 +---------------+ +------------------+ 347 |ietf-ssh-server| | ietf-tls-server | 348 +---------------+ +------------------+ 349 ^ ^ ^ 350 | | | 351 | | | 352 | +--------------------+ | 353 | | | 354 +-------------------+ +--------------------+ 355 |ietf-netconf-server| |ietf-restconf-server| 356 +-------------------+ +--------------------+ 358 4. Solution 360 Each of the following five sections relate to one of the YANG modules 361 depicted by the figure above. 363 4.1. The Keychain Model 365 The keychain model depicted in this section provides a configurable 366 object having the following characteristics: 368 o A semi-configurable list of private keys, each with one or more 369 associated certificates. Though private keys can only be created 370 via an RPC (see bullet #3 below), the entries of the list may be 371 renamed and have certificates associated with them after creation. 373 o A configurable list of lists of trust anchor certificates. This 374 enables the server to have use-specific trust anchors. For 375 instance, one list of trust anchors might be used to authenticate 376 management connections (e.g., client certificate-based 377 authentication for NETCONF or RESTCONF connections), and a 378 different list of trust anchors might be used for when connecting 379 to a specific Internet-based service (e.g., a zero touch bootstrap 380 server). 382 o An RPC to request the server to generate a new private key using 383 the specified algorithm and key length. 385 o An RPC to generate a certificate signing request for an existing 386 private key, a passed subject, and an optional attributes. The 387 signed certificate returned from an external certificate authority 388 (CA) can be set using a standard configuration change request 389 (e.g., ). 391 4.1.1. Tree Diagram 393 module: ietf-keychain 394 +--rw keychain 395 +--rw private-keys 396 | +--rw private-key* [name] 397 | | +--rw name string 398 | | +--ro algorithm? enumeration 399 | | +--ro key-length? uint32 400 | | +--ro public-key? string 401 | | +--rw certificates 402 | | | +--rw certificate* [name] 403 | | | +--rw name string 404 | | | +--rw chain? binary 405 | | +---x generate-certificate-signing-request 406 | | +---w input 407 | | | +---w subject binary 408 | | | +---w attributes? binary 409 | | +--ro output 410 | | +--ro certificate-signing-request binary 411 | +---x generate-private-key 412 | +---w input 413 | +---w name string 414 | +---w algorithm enumeration 415 | +---w key-length? uint32 416 +--rw trusted-certificates* [name] 417 +--rw name string 418 +--rw description? string 419 +--rw trusted-certificate* [name] 420 +--rw name string 421 +--rw certificate? binary 423 4.1.2. Example Usage 425 The following example illustrates the "generate-private-key" RPC in 426 use with the RESTCONF protocol and JSON encoding. 428 REQUEST 429 ------- 431 ['\' line wrapping added for formatting only] 433 POST https://example.com/restconf/data/ietf-keychain:keychain/\ 434 private-keys/generate-private-key HTTP/1.1 435 HOST: example.com 436 Content-Type: application/yang.operation+json 438 { 439 "ietf-keychain:input" : { 440 "name" : "ex-key-sect571r1", 441 "algorithm" : "sect571r1" 442 } 443 } 445 RESPONSE 446 -------- 448 HTTP/1.1 204 No Content 449 Date: Mon, 31 Oct 2015 11:01:00 GMT 450 Server: example-server 452 The following example illustrates the action statement "generate- 453 certificate-signing-request" action in use with the NETCONF protocol. 455 REQUEST 456 ------- 458 460 461 462 463 464 ex-key-sect571r1 465 466 467 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2R 468 manZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNlmO 469 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmR6Zgo= 470 471 472 bwtakWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvut4 473 arnZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYm 474 Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmC6Rhp= 475 476 477 478 479 480 481 483 RESPONSE 484 -------- 486 488 490 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 491 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 492 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 493 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 494 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 495 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 496 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 497 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 498 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 499 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 500 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 501 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 502 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 503 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 504 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 505 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 506 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 507 508 510 The following example illustrates what a fully configured keychain 511 object might look like. The private-key shown below is consistent 512 with the generate-private-key and generate-certificate-signing- 513 request examples above. This example also assumes that the resulting 514 CA-signed certificate has been configured back onto the server. 515 Lastly, this example shows that three lists of trusted certificates 516 having been configured. 518 519 520 521 522 ex-key-sect571r1 523 sect571r1 524 525 cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ 526 mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm 527 JvO3NkZ25iO29pLmR6Zgo= 528 529 530 531 ex-key-sect571r1-cert 532 533 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z 534 0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU 535 FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd 536 GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE 537 diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl 538 KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3 539 El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1 540 FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV 541 bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W 542 URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU 543 ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d 544 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 545 RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx 546 rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx 547 TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d 548 c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV 549 SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 550 551 552 553 554 556 557 558 explicitly-trusted-client-certs 559 560 Specific client authentication certificates that are to be 561 explicitly trusted NETCONF/RESTCONF clients. These are 562 needed for client certificates not signed by our CA. 563 564 565 George Jetson 566 567 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 568 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 569 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 570 RV0JCU2t2MXI2SFNHeUFUVkpwSmYyOWtXbUU0NEo5akJrQmdOVkhTTUVY 571 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 572 UxNQWtHQTFVRUJoTUNWVk14RURBT0JnTlZCQW9UQjJWNApZVzF3YkdVeE 573 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 574 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 575 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 576 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 577 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 578 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 579 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 580 TQzcjFZSjk0M1FQLzV5eGUKN2QxMkxCV0dxUjUrbEl5N01YL21ka2M4al 581 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 582 LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== 583 584 585 586 Fred Flinstone 587 588 VlEVlFRREV3Vm9ZWEJ3ZVRDQm56QU5CZ2txaGtpRzl3MEJBUUVGQUFPQm 589 pRQXdnWWtDCmdZRUE1RzRFSWZsS1p2bDlXTW44eUhyM2hObUFRaUhVUzV 590 rRUpPQy9hSFA3eGJXQW1ra054ZStUa2hrZnBsL3UKbVhsTjhSZUd1ODhG 591 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 592 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 593 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 594 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 595 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 596 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 597 xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B 598 EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK 599 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 600 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 601 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 602 QWtUOCBDRVUUZJ0RUF== 603 604 605 607 608 609 deployment-specific-ca-certs 610 611 Trust anchors used only to authenticate NETCONF/RESTCONF 612 client connections. Since our security policy only allows 613 authentication for clients having a certificate signed by 614 our CA, we only configure its certificate below. 616 617 618 ca.example.com 619 620 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 621 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 622 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 623 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 624 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 625 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 626 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 627 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 628 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 629 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 630 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 631 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 632 RJSUJQFRStS0Cg== 633 634 635 637 638 639 common-ca-certs 640 641 Trusted certificates to authenticate common HTTPS servers. 642 These certificates are similar to those that might be 643 shipped with a web browser. 644 645 646 ex-certificate-authority 647 648 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 649 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 650 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 651 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 652 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 653 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 654 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 655 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 656 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 657 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 658 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 659 WpiMjB2WlhoaGJYQnNaUzVqY215aU9L= 660 661 662 664 666 4.1.3. YANG Model 668 file "ietf-keychain@2015-10-09.yang" 670 module ietf-keychain { 671 yang-version 1.1; 673 namespace "urn:ietf:params:xml:ns:yang:ietf-keychain"; 674 prefix "kc"; 676 organization 677 "IETF NETCONF (Network Configuration) Working Group"; 679 contact 680 "WG Web: 681 WG List: 683 WG Chair: Mehmet Ersue 684 686 WG Chair: Mahesh Jethanandani 687 689 Editor: Kent Watsen 690 "; 692 description 693 "This module defines a keychain to centralize management of 694 security credentials. 696 Copyright (c) 2014 IETF Trust and the persons identified as 697 authors of the code. All rights reserved. 699 Redistribution and use in source and binary forms, with or 700 without modification, is permitted pursuant to, and subject 701 to the license terms contained in, the Simplified BSD 702 License set forth in Section 4.c of the IETF Trust's 703 Legal Provisions Relating to IETF Documents 704 (http://trustee.ietf.org/license-info). 706 This version of this YANG module is part of RFC VVVV; see 707 the RFC itself for full legal notices."; 709 revision "2015-10-09" { 710 description 711 "Initial version"; 712 reference 713 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 714 Models"; 715 } 717 container keychain { 718 description 719 "A list of private-keys and their associated certificates, as 720 well as lists of trusted certificates for client certificate 721 authentication. RPCs are provided to generate a new private 722 key and to generate a certificate signing requests."; 724 container private-keys { 725 description 726 "A list of private key maintained by the keychain."; 727 list private-key { 728 key name; 729 description 730 "A private key."; 731 leaf name { 732 type string; 733 description 734 "An arbitrary name for the private key."; 735 } 736 leaf algorithm { 737 type enumeration { 738 enum rsa { description "TBD"; } 739 enum dsa { description "TBD"; } 740 enum secp192r1 { description "TBD"; } 741 enum sect163k1 { description "TBD"; } 742 enum sect163r2 { description "TBD"; } 743 enum secp224r1 { description "TBD"; } 744 enum sect233k1 { description "TBD"; } 745 enum sect233r1 { description "TBD"; } 746 enum secp256r1 { description "TBD"; } 747 enum sect283k1 { description "TBD"; } 748 enum sect283r1 { description "TBD"; } 749 enum secp384r1 { description "TBD"; } 750 enum sect409k1 { description "TBD"; } 751 enum sect409r1 { description "TBD"; } 752 enum secp521r1 { description "TBD"; } 753 enum sect571k1 { description "TBD"; } 754 enum sect571r1 { description "TBD"; } 755 } 756 config false; 757 description 758 "The algorithm used by the private key."; 759 } 760 leaf key-length { 761 type uint32; 762 config false; 763 description 764 "The key-length used by the private key."; 765 } 766 leaf public-key { 767 type string; 768 config false; 769 description 770 "The public-key matching the private key."; 771 } 772 container certificates { 773 list certificate { 774 key name; 775 description 776 "A certificate for this public key."; 777 leaf name { 778 type string; 779 description 780 "An arbitrary name for the certificate."; 781 } 782 leaf chain { 783 type binary; 784 description 785 "The certificate itself, as well as an ordered 786 sequence of intermediate certificates leading 787 to a trust anchor, as specified by RFC 5246, 788 Section 7.4.2."; 789 reference 790 "RFC 5246: The Transport Layer Security (TLS) 791 Protocol Version 1.2"; 792 } 793 } 794 description 795 "A list of certificates for this public key."; 796 } 797 action generate-certificate-signing-request { 798 description 799 "Generates a certificate signing request structure for 800 the associated private key using the passed subject 801 and attribute values."; 802 input { 803 leaf subject { 804 type binary; 805 mandatory true; 806 description 807 "The distinguished name of the certificate subject 808 (the entity whose public key is to be certified). 809 This field is encoded the same as the 'subject' 810 field in the CertificationRequestInfo type defined 811 in RFC 2986, Section 4.1."; 812 reference 813 "RFC 2986: PKCS #10: Certification Request Syntax 814 Specification Version 1.7"; 815 } 816 leaf attributes { 817 type binary; 818 description 819 "A collection of attributes providing additional 820 information about the subject of the certificate. 821 This field is encoded the same as the 'attributes' 822 field in the CertificationRequestInfo type defined 823 in RFC 2986, Section 4.1."; 824 reference 825 "RFC 2986: PKCS #10: Certification Request Syntax 826 Specification Version 1.7"; 827 } 828 } 829 output { 830 leaf certificate-signing-request { 831 type binary; 832 mandatory true; 833 description 834 "The certificate signing request to be signed by 835 a certificate authority. This field is encoded 836 as the CertificationRequest type defined in 837 RFC 2986, Section 4.2."; 838 reference 839 "RFC 2986: PKCS #10: Certification Request Syntax 840 Specification Version 1.7"; 841 } 842 } 843 } 844 } 845 action generate-private-key { 846 description 847 "Generates a private key using the specified algorithm and 848 key length."; 849 input { 850 leaf name { 851 type string; 852 mandatory true; 853 description 854 "The name this private-key should have when listed 855 in /keychain/private-keys. As such, the passed 856 value must not match any existing 'name' value."; 857 } 858 leaf algorithm { 859 type enumeration { 860 enum rsa { description "TBD"; } 861 enum dsa { description "TBD"; } 862 enum secp192r1 { description "TBD"; } 863 enum sect163k1 { description "TBD"; } 864 enum sect163r2 { description "TBD"; } 865 enum secp224r1 { description "TBD"; } 866 enum sect233k1 { description "TBD"; } 867 enum sect233r1 { description "TBD"; } 868 enum secp256r1 { description "TBD"; } 869 enum sect283k1 { description "TBD"; } 870 enum sect283r1 { description "TBD"; } 871 enum secp384r1 { description "TBD"; } 872 enum sect409k1 { description "TBD"; } 873 enum sect409r1 { description "TBD"; } 874 enum secp521r1 { description "TBD"; } 875 enum sect571k1 { description "TBD"; } 876 enum sect571r1 { description "TBD"; } 877 } 878 mandatory true; 879 description 880 "The algorithm to be used."; 881 } 882 leaf key-length { 883 type uint32; 884 description 885 "For algorithms that need a key length specified 886 when generating the key."; 887 } 888 } 889 } 890 } 892 list trusted-certificates { 893 key name; 894 description 895 "A list of lists of trusted certificates."; 896 leaf name { 897 type string; 898 description 899 "An arbitrary name for this list of trusted 900 certificates."; 901 } 902 leaf description { 903 type string; 904 description 905 "An arbitrary description for this list of trusted 906 certificates."; 907 } 908 list trusted-certificate { 909 key name; 910 description 911 "A list of trusted certificates for a specific use."; 912 leaf name { 913 type string; 914 description 915 "An arbitrary name for this trusted certificate."; 916 } 917 leaf certificate { 918 type binary; 919 description 920 "The binary certificate structure as specified by RFC 921 5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>; 922 "; 923 reference 924 "RFC 5246: The Transport Layer Security (TLS) 925 Protocol Version 1.2"; 926 } 927 } 928 } 929 } 930 } 932 934 4.2. The SSH Server Model 936 The SSH Server model presented in this section presents two YANG 937 groupings, one for a server that opens a socket to accept TCP 938 connections on, and another for a server that has had the TCP 939 connection opened for it already (e.g., inetd). 941 The SSH Server model (like the TLS Server model presented below) is 942 provided as a grouping so that it can be used in different contexts. 943 For instance, the NETCONF Server model presented in Section 4.4 uses 944 one grouping to configure a NETCONF server listening for connections 945 and the other grouping to configure NETCONF call home. 947 A shared characteristic between both groupings is the ability to 948 configure which host key is presented to clients, the private key for 949 which is held in the keychain configuration presented before. 950 Another shared characteristic is the ability to configure which 951 trusted CA or client certificates the server should be used to 952 authenticate clients when using X.509 based client certificates 953 [RFC6187]. 955 4.2.1. Tree Diagram 957 The following tree diagram represents the data model for the grouping 958 used to configure an SSH server to listen for TCP connections. The 959 tree diagram for the other grouping is not provided, but it is the 960 same except without the "address" and "port" fields. 962 NOTE: the diagram below shows "listening-ssh-server" as a YANG 963 container (not a grouping). This temporary container was created 964 only to enable the `pyang` tool to output the tree diagram, as 965 groupings by themselves have no protocol accessible nodes, and hence 966 `pyang` would output an empty tree diagram. 968 module: ietf-ssh-server 969 +--rw listening-ssh-server 970 +--rw address? inet:ip-address 971 +--rw port inet:port-number 972 +--rw host-keys 973 | +--rw host-key* [name] 974 | +--rw name string 975 | +--rw (type)? 976 | +--:(public-key) 977 | | +--rw public-key? -> /kc:keychain/private-keys/pri 978 vate-key/name 979 | +--:(certificate) 980 | +--rw certificate? -> /kc:keychain/private-keys/pri 981 vate-key/certificates/certificate/name {ssh-x509-certs}? 982 +--rw client-cert-auth {ssh-x509-certs}? 983 +--rw trusted-ca-certs? -> /kc:keychain/trusted-certific 984 ates/name 985 +--rw trusted-client-certs? -> /kc:keychain/trusted-certific 986 ates/name 988 4.2.2. Example Usage 990 This section shows how it would appear if the temporary listening- 991 ssh-server container just mentioned above were populated with some 992 data. This example is consistent with the examples presented earlier 993 in this document. 995 997 830 998 999 1000 deployment-specific-certificate 1001 ex-key-sect571r1-cert 1002 1003 1004 1005 1006 1007 deployment-specific-ca-certs 1008 1009 1010 explicitly-trusted-client-certs 1011 1012 1013 1015 4.2.3. YANG Model 1017 file "ietf-ssh-server@2015-10-09.yang" 1019 module ietf-ssh-server { 1020 yang-version 1.1; 1022 namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-server"; 1023 prefix "ts"; 1025 import ietf-inet-types { // RFC 6991 1026 prefix inet; 1027 } 1028 import ietf-keychain { 1029 prefix kc; // RFC VVVV 1030 revision-date 2015-10-09; 1031 } 1033 organization 1034 "IETF NETCONF (Network Configuration) Working Group"; 1036 contact 1037 "WG Web: 1038 WG List: 1040 WG Chair: Mehmet Ersue 1041 1043 WG Chair: Mahesh Jethanandani 1044 1046 Editor: Kent Watsen 1047 "; 1049 description 1050 "This module defines a reusable grouping for a SSH server that 1051 can be used as a basis for specific SSH server instances. 1053 Copyright (c) 2014 IETF Trust and the persons identified as 1054 authors of the code. All rights reserved. 1056 Redistribution and use in source and binary forms, with or 1057 without modification, is permitted pursuant to, and subject 1058 to the license terms contained in, the Simplified BSD 1059 License set forth in Section 4.c of the IETF Trust's 1060 Legal Provisions Relating to IETF Documents 1061 (http://trustee.ietf.org/license-info). 1063 This version of this YANG module is part of RFC VVVV; see 1064 the RFC itself for full legal notices."; 1066 revision "2015-10-09" { 1067 description 1068 "Initial version"; 1069 reference 1070 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 1071 Models"; 1072 } 1074 // features 1075 feature ssh-x509-certs { 1076 description 1077 "The ssh-x509-certs feature indicates that the NETCONF 1078 server supports RFC 6187"; 1079 reference 1080 "RFC 6187: X.509v3 Certificates for Secure Shell 1081 Authentication"; 1082 } 1084 // grouping 1085 grouping non-listening-ssh-server-grouping { 1086 description 1087 "A reusable grouping for a SSH server that can be used as a 1088 basis for specific SSH server instances."; 1090 container host-keys { 1091 description 1092 "The list of host-keys the SSH server will present when 1093 establishing a SSH connection."; 1094 list host-key { 1095 key name; 1096 min-elements 1; 1097 ordered-by user; 1098 description 1099 "An ordered list of host keys the SSH server advertises 1100 when sending its ??? message."; 1101 reference 1102 "RFC ????: ..."; 1103 leaf name { 1104 type string; 1105 mandatory true; 1106 description 1107 "An arbitrary name for this host-key"; 1108 } 1109 choice type { 1110 description 1111 "The type of host key being specified"; 1112 leaf public-key { 1113 type leafref { 1114 path "/kc:keychain/kc:private-keys/kc:private-key/" 1115 + "kc:name"; 1116 } 1117 description 1118 "The name of a private-key in the keychain."; 1119 } 1120 leaf certificate { 1121 if-feature ssh-x509-certs; 1122 type leafref { 1123 path "/kc:keychain/kc:private-keys/kc:private-key/" 1124 + "kc:certificates/kc:certificate/kc:name"; 1125 } 1126 description 1127 "The name of a certificate in the keychain."; 1128 } 1129 } 1130 } 1131 } 1133 container client-cert-auth { 1134 if-feature ssh-x509-certs; 1135 description 1136 "A reference to a list of trusted certificate authority (CA) 1137 certificates and a reference to a list of trusted client 1138 certificates."; 1139 leaf trusted-ca-certs { 1140 type leafref { 1141 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1142 } 1143 description 1144 "A reference to a list of certificate authority (CA) 1145 certificates used by the SSH server to authenticate 1146 SSH client certificates."; 1147 } 1149 leaf trusted-client-certs { 1150 type leafref { 1151 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1152 } 1153 description 1154 "A reference to a list of client certificates used by 1155 the SSH server to authenticate SSH client certificates. 1156 A clients certificate is authenticated if it is an 1157 exact match to a configured trusted client certificate."; 1158 } 1159 } 1160 } 1162 grouping listening-ssh-server-grouping { 1163 description 1164 "A reusable grouping for a SSH server that can be used as a 1165 basis for specific SSH server instances."; 1166 leaf address { 1167 type inet:ip-address; 1168 description 1169 "The IP address of the interface to listen on. The SSH 1170 server will listen on all interfaces if no value is 1171 specified."; 1172 } 1173 leaf port { 1174 type inet:port-number; 1175 mandatory true; // will a default augmented in work? 1176 description 1177 "The local port number on this interface the SSH server 1178 listens on."; 1179 } 1180 uses non-listening-ssh-server-grouping; 1181 } 1183 // RFC Editor: please remove the following container block 1184 // when publishing this document as an RFC. 1186 container listening-ssh-server { 1187 description 1188 "This container is only present to enable `pyang` 1189 tree diagram output, as a grouping by itself has 1190 no protocol accessible nodes to output."; 1192 uses listening-ssh-server-grouping; 1193 } 1195 } 1197 1199 4.3. The TLS Server Model 1201 The TLS Server model presented in this section presents two YANG 1202 groupings, one for a server that opens a socket to accept TCP 1203 connections on, and another for a server that has had the TCP 1204 connection opened for it already (e.g., inetd). 1206 The TLS Server model (like the SSH Server model presented above) is 1207 provided as a grouping so that it can be used in different contexts. 1208 For instance, the NETCONF Server model presented in Section 4.4 uses 1209 one grouping to configure a NETCONF server listening for connections 1210 and the other grouping to configure NETCONF call home. 1212 A shared characteristic between both groupings is the ability to 1213 configure which server certificate is presented to clients, the 1214 private key for which is held in the keychain model presented in 1215 Section 4.1. Another shared characteristic is the ability to 1216 configure which trusted CA or client certificates the server should 1217 be used to authenticate clients. 1219 4.3.1. Tree Diagram 1221 The following tree diagram represents the data model for the grouping 1222 used to configure an TLS server to listen for TCP connections. The 1223 tree diagram for the other grouping is not provided, but it is the 1224 same except without the "address" and "port" fields. 1226 NOTE: the diagram below shows "listening-ssh-server" as a YANG 1227 container (not a grouping). This temporary container was created 1228 only to enable the `pyang` tool to output the tree diagram, as 1229 groupings by themselves have no protocol accessible nodes, and hence 1230 `pyang` would output an empty tree diagram. 1232 module: ietf-tls-server 1233 +--rw listening-tls-server 1234 +--rw address? inet:ip-address 1235 +--rw port inet:port-number 1236 +--rw certificates 1237 | +--rw certificate* [name] 1238 | +--rw name -> /kc:keychain/private-keys/private-key/cert 1239 ificates/certificate/name 1240 +--rw client-auth 1241 +--rw trusted-ca-certs? -> /kc:keychain/trusted-certific 1242 ates/name 1243 +--rw trusted-client-certs? -> /kc:keychain/trusted-certific 1244 ates/name 1246 4.3.2. Example Usage 1248 1250 6513 1251 1252 1253 ex-key-sect571r1-cert 1254 1255 1256 1257 1258 deployment-specific-ca-certs 1259 1260 1261 explicitly-trusted-client-certs 1262 1263 1264 1266 4.3.3. YANG Model 1268 file "ietf-tls-server@2015-10-09.yang" 1270 module ietf-tls-server { 1271 yang-version 1.1; 1273 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 1274 prefix "ts"; 1276 import ietf-inet-types { // RFC 6991 1277 prefix inet; 1278 } 1279 import ietf-keychain { 1280 prefix kc; // RFC VVVV 1281 revision-date 2015-10-09; 1282 } 1284 organization 1285 "IETF NETCONF (Network Configuration) Working Group"; 1287 contact 1288 "WG Web: 1289 WG List: 1291 WG Chair: Mehmet Ersue 1292 1294 WG Chair: Mahesh Jethanandani 1295 1297 Editor: Kent Watsen 1298 "; 1300 description 1301 "This module defines a reusable grouping for a TLS server that 1302 can be used as a basis for specific TLS server instances. 1304 Copyright (c) 2014 IETF Trust and the persons identified as 1305 authors of the code. All rights reserved. 1307 Redistribution and use in source and binary forms, with or 1308 without modification, is permitted pursuant to, and subject 1309 to the license terms contained in, the Simplified BSD 1310 License set forth in Section 4.c of the IETF Trust's 1311 Legal Provisions Relating to IETF Documents 1312 (http://trustee.ietf.org/license-info). 1314 This version of this YANG module is part of RFC VVVV; see 1315 the RFC itself for full legal notices."; 1317 revision "2015-10-09" { 1318 description 1319 "Initial version"; 1320 reference 1321 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 1322 Models"; 1323 } 1324 // grouping 1325 grouping non-listening-tls-server-grouping { 1326 description 1327 "A reusable grouping for a TLS server that can be used as a 1328 basis for specific TLS server instances."; 1329 container certificates { 1330 description 1331 "The list of certificates the TLS server will present when 1332 establishing a TLS connection."; 1333 list certificate { 1334 key name; 1335 min-elements 1; 1336 description 1337 "An unordered list of certificates the TLS server can pick 1338 from when sending its Server Certificate message."; 1339 reference 1340 "RFC 5246: The TLS Protocol, Section 7.4.2"; 1341 leaf name { 1342 type leafref { 1343 path "/kc:keychain/kc:private-keys/kc:private-key/" 1344 + "kc:certificates/kc:certificate/kc:name"; 1345 } 1346 description 1347 "The name of the certificate in the keychain."; 1348 } 1349 } 1350 } 1352 container client-auth { 1353 description 1354 "A reference to a list of trusted certificate authority (CA) 1355 certificates and a reference to a list of trusted client 1356 certificates."; 1357 leaf trusted-ca-certs { 1358 type leafref { 1359 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1360 } 1361 description 1362 "A reference to a list of certificate authority (CA) 1363 certificates used by the TLS server to authenticate 1364 TLS client certificates."; 1365 } 1367 leaf trusted-client-certs { 1368 type leafref { 1369 path "/kc:keychain/kc:trusted-certificates/kc:name"; 1370 } 1371 description 1372 "A reference to a list of client certificates used by 1373 the TLS server to authenticate TLS client certificates. 1374 A clients certificate is authenticated if it is an 1375 exact match to a configured trusted client certificate."; 1376 } 1377 } 1378 } 1380 grouping listening-tls-server-grouping { 1381 description 1382 "A reusable grouping for a TLS server that can be used as a 1383 basis for specific TLS server instances."; 1384 leaf address { 1385 type inet:ip-address; 1386 description 1387 "The IP address of the interface to listen on. The TLS 1388 server will listen on all interfaces if no value is 1389 specified."; 1390 } 1391 leaf port { 1392 type inet:port-number; 1393 mandatory true; // will a default augmented in work? 1394 description 1395 "The local port number on this interface the TLTLS server 1396 listens on."; 1397 } 1398 uses non-listening-tls-server-grouping; 1399 } 1401 // RFC Editor: please remove the following container block 1402 // when publishing this document as an RFC. 1403 container listening-tls-server { 1404 description 1405 "This container is only present to enable `pyang` 1406 tree diagram output, as a grouping by itself has 1407 no protocol accessible nodes to output."; 1409 uses listening-tls-server-grouping; 1410 } 1412 } 1413 1415 4.4. The NETCONF Server Model 1417 The NETCONF Server model presented in this section supports servers 1418 both listening for connections to accept as well as initiating call- 1419 home connections. This model also supports both the SSH and TLS 1420 transport protocols, using the SSH Server and TLS Server groupings 1421 presented in Section 4.2 and Section 4.3 respectively. All private 1422 keys and trusted certificates are held in the keychain model 1423 presented in Section 4.1. YANG feature statements are used to enable 1424 implementations to advertise which parts of the model the NETCONF 1425 server supports. 1427 4.4.1. Tree Diagram 1429 The following tree diagram uses line-wrapping in order to comply with 1430 xml2rfc validation. This is annoying as I find that drafts (even txt 1431 drafts) look just fine with long lines - maybe xml2rfc should remove 1432 this warning? - or pyang could have an option to suppress printing 1433 leafref paths? 1435 module: ietf-netconf-server 1436 +--rw netconf-server 1437 +--rw session-options 1438 | +--rw hello-timeout? uint16 1439 +--rw listen {(ssh-listen or tls-listen)}? 1440 | +--rw max-sessions? uint16 1441 | +--rw idle-timeout? uint16 1442 | +--rw endpoint* [name] 1443 | +--rw name string 1444 | +--rw (transport) 1445 | +--:(ssh) {ssh-listen}? 1446 | | +--rw ssh 1447 | | +--rw address? inet:ip-address 1448 | | +--rw port inet:port-number 1449 | | +--rw host-keys 1450 | | | +--rw host-key* [name] 1451 | | | +--rw name string 1452 | | | +--rw (type)? 1453 | | | +--:(public-key) 1454 | | | | +--rw public-key? -> /kc:keychain/p 1455 rivate-keys/private-key/name 1456 | | | +--:(certificate) 1457 | | | +--rw certificate? -> /kc:keychain/p 1458 rivate-keys/private-key/certificates/certificate/name {ssh-x509-certs}? 1459 | | +--rw client-cert-auth {ssh-x509-certs}? 1460 | | +--rw trusted-ca-certs? -> /kc:keychain/t 1462 rusted-certificates/name 1463 | | +--rw trusted-client-certs? -> /kc:keychain/t 1464 rusted-certificates/name 1465 | +--:(tls) {tls-listen}? 1466 | +--rw tls 1467 | +--rw address? inet:ip-address 1468 | +--rw port inet:port-number 1469 | +--rw certificates 1470 | | +--rw certificate* [name] 1471 | | +--rw name -> /kc:keychain/private-keys/p 1472 rivate-key/certificates/certificate/name 1473 | +--rw client-auth 1474 | +--rw trusted-ca-certs? -> /kc:keychain/t 1475 rusted-certificates/name 1476 | +--rw trusted-client-certs? -> /kc:keychain/t 1477 rusted-certificates/name 1478 | +--rw cert-maps 1479 | +--rw cert-to-name* [id] 1480 | +--rw id uint32 1481 | +--rw fingerprint x509c2n:tls-fingerpr 1482 int 1483 | +--rw map-type identityref 1484 | +--rw name string 1485 +--rw call-home {(ssh-call-home or tls-call-home)}? 1486 +--rw netconf-client* [name] 1487 +--rw name string 1488 +--rw (transport) 1489 | +--:(ssh) {ssh-call-home}? 1490 | | +--rw ssh 1491 | | +--rw endpoints 1492 | | | +--rw endpoint* [name] 1493 | | | +--rw name string 1494 | | | +--rw address inet:host 1495 | | | +--rw port? inet:port-number 1496 | | +--rw host-keys 1497 | | | +--rw host-key* [name] 1498 | | | +--rw name string 1499 | | | +--rw (type)? 1500 | | | +--:(public-key) 1501 | | | | +--rw public-key? -> /kc:keychain/p 1502 rivate-keys/private-key/name 1503 | | | +--:(certificate) 1504 | | | +--rw certificate? -> /kc:keychain/p 1505 rivate-keys/private-key/certificates/certificate/name {ssh-x509-certs}? 1506 | | +--rw client-cert-auth {ssh-x509-certs}? 1507 | | +--rw trusted-ca-certs? -> /kc:keychain/t 1508 rusted-certificates/name 1509 | | +--rw trusted-client-certs? -> /kc:keychain/t 1511 rusted-certificates/name 1512 | +--:(tls) {tls-call-home}? 1513 | +--rw tls 1514 | +--rw endpoints 1515 | | +--rw endpoint* [name] 1516 | | +--rw name string 1517 | | +--rw address inet:host 1518 | | +--rw port? inet:port-number 1519 | +--rw certificates 1520 | | +--rw certificate* [name] 1521 | | +--rw name -> /kc:keychain/private-keys/p 1522 rivate-key/certificates/certificate/name 1523 | +--rw client-auth 1524 | +--rw trusted-ca-certs? -> /kc:keychain/t 1525 rusted-certificates/name 1526 | +--rw trusted-client-certs? -> /kc:keychain/t 1527 rusted-certificates/name 1528 | +--rw cert-maps 1529 | +--rw cert-to-name* [id] 1530 | +--rw id uint32 1531 | +--rw fingerprint x509c2n:tls-fingerpr 1532 int 1533 | +--rw map-type identityref 1534 | +--rw name string 1535 +--rw connection-type 1536 | +--rw (connection-type)? 1537 | +--:(persistent-connection) 1538 | | +--rw persistent! 1539 | | +--rw idle-timeout? uint32 1540 | | +--rw keep-alives 1541 | | +--rw max-wait? uint16 1542 | | +--rw max-attempts? uint8 1543 | +--:(periodic-connection) 1544 | +--rw periodic! 1545 | +--rw idle-timeout? uint16 1546 | +--rw reconnect_timeout? uint16 1547 +--rw reconnect-strategy 1548 +--rw start-with? enumeration 1549 +--rw max-attempts? uint8 1551 4.4.2. Example Usage 1553 Configuring a NETCONF Server to listen for NETCONF client connections 1554 using both the SSH and TLS transport protocols, as well as 1555 configuring call-home to two NETCONF clients, one using SSH and the 1556 other using TLS. 1558 This example is consistent with other examples presented in this 1559 document. 1561 1563 1565 1566 1567 netconf/ssh 1568 1569
11.22.33.44
1570 1571 1572 my-rsa-key 1573 1574 1575 TPM key 1576 1577 1578 1579 1580 deployment-specific-ca-certs 1581 1582 1583 explicitly-trusted-client-certs 1584 1585 1586 1587 1589 1590 1591 netconf/tls 1592 1593
11.22.33.44
1594 1595 ex-key-sect571r1-cert 1596 1597 1598 1599 deployment-specific-ca-certs 1600 1601 1602 explicitly-trusted-client-certs 1603 1604 1605 1606 1 1607 11:0A:05:11:00 1608 x509c2n:san-any 1609 1610 1611 2 1612 B3:4F:A1:8C:54 1613 x509c2n:specified 1614 scooby-doo 1615 1616 1617 1618 1619 1621 1622 1624 1625 1626 config-mgr 1627 1628 1629 1630 east-data-center 1631
11.22.33.44
1632 1633 1634 west-data-center 1635
55.66.77.88
1636 1637 1638 1639 1640 TPM key 1641 1642 1643 1644 1645 deployment-specific-ca-certs 1646 1647 1648 explicitly-trusted-client-certs 1649 1650 1651 1652 1653 1654 300 1655 60 1656 1657 1658 1659 last-connected 1660 3 1661 1662 1664 1665 1666 event-correlator 1667 1668 1669 1670 east-data-center 1671
22.33.44.55
1672 1673 1674 west-data-center 1675
33.44.55.66
1676 1677 1678 1679 ex-key-sect571r1-cert 1680 1681 1682 1683 deployment-specific-ca-certs 1684 1685 1686 explicitly-trusted-client-certs 1687 1688 1689 1690 1 1691 11:0A:05:11:00 1692 x509c2n:san-any 1693 1694 1695 2 1696 B3:4F:A1:8C:54 1697 x509c2n:specified 1698 scooby-doo 1699 1700 1701 1703 1704 1705 1706 300 1707 1708 30 1709 3 1710 1711 1712 1713 1714 first-listed 1715 3 1716 1717 1719 1720 1722 4.4.3. YANG Model 1724 This YANG module imports YANG types from [RFC6991] and [RFC7407]. 1726 file "ietf-netconf-server@2015-10-09.yang" 1728 module ietf-netconf-server { 1729 yang-version 1.1; 1731 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; 1732 prefix "ncserver"; 1734 import ietf-inet-types { // RFC 6991 1735 prefix inet; 1736 } 1737 import ietf-x509-cert-to-name { // RFC 7407 1738 prefix x509c2n; 1739 } 1740 import ietf-ssh-server { // RFC VVVV 1741 prefix ss; 1742 revision-date 2015-10-09; 1743 } 1744 import ietf-tls-server { // RFC VVVV 1745 prefix ts; 1746 revision-date 2015-10-09; 1747 } 1748 organization 1749 "IETF NETCONF (Network Configuration) Working Group"; 1751 contact 1752 "WG Web: 1753 WG List: 1755 WG Chair: Mehmet Ersue 1756 1758 WG Chair: Mahesh Jethanandani 1759 1761 Editor: Kent Watsen 1762 "; 1764 description 1765 "This module contains a collection of YANG definitions for 1766 configuring NETCONF servers. 1768 Copyright (c) 2014 IETF Trust and the persons identified as 1769 authors of the code. All rights reserved. 1771 Redistribution and use in source and binary forms, with or 1772 without modification, is permitted pursuant to, and subject 1773 to the license terms contained in, the Simplified BSD 1774 License set forth in Section 4.c of the IETF Trust's 1775 Legal Provisions Relating to IETF Documents 1776 (http://trustee.ietf.org/license-info). 1778 This version of this YANG module is part of RFC VVVV; see 1779 the RFC itself for full legal notices."; 1781 revision "2015-10-09" { 1782 description 1783 "Initial version"; 1784 reference 1785 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 1786 Models"; 1787 } 1789 // Features 1791 feature ssh-listen { 1792 description 1793 "The ssh-listen feature indicates that the NETCONF server 1794 supports opening a port to accept NETCONF over SSH 1795 client connections."; 1796 reference 1797 "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; 1798 } 1800 feature ssh-call-home { 1801 description 1802 "The ssh-call-home feature indicates that the NETCONF 1803 server supports initiating a NETCONF over SSH call 1804 home connection to NETCONF clients."; 1805 reference 1806 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 1807 } 1809 feature tls-listen { 1810 description 1811 "The tls-listen feature indicates that the NETCONF server 1812 supports opening a port to accept NETCONF over TLS 1813 client connections."; 1814 reference 1815 "RFC 5539: Using the NETCONF Protocol over Transport 1816 Layer Security (TLS) with Mutual X.509 1817 Authentication"; 1818 } 1820 feature tls-call-home { 1821 description 1822 "The tls-call-home feature indicates that the NETCONF 1823 server supports initiating a NETCONF over TLS call 1824 home connection to NETCONF clients."; 1825 reference 1826 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 1827 } 1829 feature ssh-x509-certs { 1830 description 1831 "The ssh-x509-certs feature indicates that the NETCONF 1832 server supports RFC 6187"; 1833 reference 1834 "RFC 6187: X.509v3 Certificates for Secure Shell 1835 Authentication"; 1836 } 1838 // top-level container (groupings below) 1839 container netconf-server { 1840 description 1841 "Top-level container for NETCONF server configuration."; 1843 container session-options { // SHOULD WE REMOVE THIS ALTOGETHER? 1844 description 1845 "NETCONF session options, independent of transport 1846 or connection strategy."; 1847 leaf hello-timeout { 1848 type uint16; 1849 units "seconds"; 1850 default 600; 1851 description 1852 "Specifies the maximum number of seconds that a SSH/TLS 1853 connection may wait for a hello message to be received. 1854 A connection will be dropped if no hello message is 1855 received before this number of seconds elapses. If set 1856 to zero, then the server will wait forever for a hello 1857 message."; 1858 } 1859 } 1861 container listen { 1862 if-feature "(ssh-listen or tls-listen)"; 1863 description 1864 "Configures listen behavior"; 1865 leaf max-sessions { 1866 type uint16; 1867 default 0; 1868 description 1869 "Specifies the maximum number of concurrent sessions 1870 that can be active at one time. The value 0 indicates 1871 that no artificial session limit should be used."; 1872 } 1873 leaf idle-timeout { 1874 type uint16; 1875 units "seconds"; 1876 default 3600; // one hour 1877 description 1878 "Specifies the maximum number of seconds that a NETCONF 1879 session may remain idle. A NETCONF session will be dropped 1880 if it is idle for an interval longer than this number of 1881 seconds. If set to zero, then the server will never drop 1882 a session because it is idle. Sessions that have a 1883 notification subscription active are never dropped."; 1884 } 1885 list endpoint { 1886 key name; 1887 description 1888 "List of endpoints to listen for NETCONF connections on."; 1890 leaf name { 1891 type string; 1892 description 1893 "An arbitrary name for the NETCONF listen endpoint."; 1894 } 1895 choice transport { 1896 mandatory true; 1897 description 1898 "Selects between available transports."; 1899 case ssh { 1900 if-feature ssh-listen; 1901 container ssh { 1902 description 1903 "SSH-specific listening configuration for inbound 1904 connections."; 1905 uses ss:listening-ssh-server-grouping { 1906 refine port { 1907 default 830; 1908 } 1909 } 1910 } 1911 } 1912 case tls { 1913 if-feature tls-listen; 1914 container tls { 1915 description 1916 "TLS-specific listening configuration for inbound 1917 connections."; 1918 uses ts:listening-tls-server-grouping { 1919 refine port { 1920 default 6513; 1921 } 1922 augment "client-auth" { 1923 description 1924 "Augments in the cert-to-name structure."; 1925 uses cert-maps-grouping; 1926 } 1927 } 1928 } 1929 } 1930 } 1931 } 1932 } 1934 container call-home { 1935 if-feature "(ssh-call-home or tls-call-home)"; 1936 description 1937 "Configures call-home behavior"; 1939 list netconf-client { 1940 key name; 1941 description 1942 "List of NETCONF clients the NETCONF server is to initiate 1943 call-home connections to."; 1944 leaf name { 1945 type string; 1946 description 1947 "An arbitrary name for the remote NETCONF client."; 1948 } 1949 choice transport { 1950 mandatory true; 1951 description 1952 "Selects between available transports."; 1953 case ssh { 1954 if-feature ssh-call-home; 1955 container ssh { 1956 description 1957 "Specifies SSH-specific call-home transport 1958 configuration."; 1959 uses endpoints-container { 1960 refine endpoints/endpoint/port { 1961 default 7777; 1962 } 1963 } 1964 uses ss:non-listening-ssh-server-grouping; 1965 } 1966 } 1967 case tls { 1968 if-feature tls-call-home; 1969 container tls { 1970 description 1971 "Specifies TLS-specific call-home transport 1972 configuration."; 1973 uses endpoints-container { 1974 refine endpoints/endpoint/port { 1975 default 8888; 1976 } 1977 } 1978 uses ts:non-listening-tls-server-grouping { 1979 augment "client-auth" { 1980 description 1981 "Augments in the cert-to-name structure."; 1982 uses cert-maps-grouping; 1983 } 1984 } 1985 } 1986 } 1988 } 1989 container connection-type { 1990 description 1991 "Indicates the kind of connection to use."; 1992 choice connection-type { 1993 description 1994 "Selects between available connection types."; 1995 case persistent-connection { 1996 container persistent { 1997 presence true; 1998 description 1999 "Maintain a persistent connection to the NETCONF 2000 client. If the connection goes down, immediately 2001 start trying to reconnect to it, using the 2002 reconnection strategy. 2004 This connection type minimizes any NETCONF client 2005 to NETCONF server data-transfer delay, albeit at 2006 the expense of holding resources longer."; 2007 leaf idle-timeout { 2008 type uint32; 2009 units "seconds"; 2010 default 86400; // one day; 2011 description 2012 "Specifies the maximum number of seconds that a 2013 a NETCONF session may remain idle. A NETCONF 2014 session will be dropped if it is idle for an 2015 interval longer than this number of seconds. 2016 If set to zero, then the server will never drop 2017 a session because it is idle. Sessions that 2018 have a notification subscription active are 2019 never dropped."; 2020 } 2021 container keep-alives { 2022 description 2023 "Configures the keep-alive policy, to proactively 2024 test the aliveness of the SSH/TLS client. An 2025 unresponsive SSH/TLS client will be dropped after 2026 approximately max-attempts * max-wait seconds."; 2027 reference 2028 "RFC YYYY: NETCONF Call Home and RESTCONF Call 2029 Home, Section 3.1, item S6"; 2030 leaf max-wait { 2031 type uint16 { 2032 range "1..max"; 2033 } 2034 units seconds; 2035 default 30; 2036 description 2037 "Sets the amount of time in seconds after which 2038 if no data has been received from the SSH/TLS 2039 client, a SSH/TLS-level message will be sent 2040 to test the aliveness of the SSH/TLS client."; 2041 } 2042 leaf max-attempts { 2043 type uint8; 2044 default 3; 2045 description 2046 "Sets the number of maximum number of sequential 2047 keep-alive messages that can fail to obtain a 2048 response from the SSH/TLS client before assuming 2049 the SSH/TLS client is no longer alive."; 2050 } 2051 } 2052 } 2053 } 2054 case periodic-connection { 2055 container periodic { 2056 presence true; 2057 description 2058 "Periodically connect to the NETCONF client, so that 2059 the NETCONF client may deliver messages pending for 2060 the NETCONF server. The NETCONF client is expected 2061 to close the connection when it is ready to release 2062 it, thus starting the NETCONF server's timer until 2063 next connection."; 2064 leaf idle-timeout { 2065 type uint16; 2066 units "seconds"; 2067 default 300; // five minutes 2068 description 2069 "Specifies the maximum number of seconds that a 2070 a NETCONF session may remain idle. A NETCONF 2071 session will be dropped if it is idle for an 2072 interval longer than this number of seconds. 2073 If set to zero, then the server will never drop 2074 a session because it is idle. Sessions that 2075 have a notification subscription active are 2076 never dropped."; 2077 } 2078 leaf reconnect_timeout { 2079 type uint16 { 2080 range "1..max"; 2081 } 2082 units minutes; 2083 default 60; 2084 description 2085 "Sets the maximum amount of unconnected time the 2086 NETCONF server will wait before re-establishing 2087 a connection to the NETCONF client. The NETCONF 2088 server may initiate a connection before this 2089 time if desired (e.g., to deliver an event 2090 notification message)."; 2091 } 2092 } 2093 } 2094 } 2095 } 2096 container reconnect-strategy { 2097 description 2098 "The reconnection strategy guides how a NETCONF server 2099 reconnects to a NETCONF client, after discovering its 2100 connection to the client has dropped. The NETCONF 2101 server starts with the specified endpoint and tries 2102 to connect to it max-attempts times before trying the 2103 next endpoint in the list (round robin)."; 2104 leaf start-with { 2105 type enumeration { 2106 enum first-listed { 2107 description 2108 "Indicates that reconnections should start with 2109 the first endpoint listed."; 2110 } 2111 enum last-connected { 2112 description 2113 "Indicates that reconnections should start with 2114 the endpoint last connected to. If no previous 2115 connection has ever been established, then the 2116 first endpoint configured is used. NETCONF 2117 servers SHOULD be able to remember the last 2118 endpoint connected to across reboots."; 2119 } 2120 } 2121 default first-listed; 2122 description 2123 "Specifies which of the NETCONF client's endpoints the 2124 NETCONF server should start with when trying to connect 2125 to the NETCONF client."; 2126 } 2127 leaf max-attempts { 2128 type uint8 { 2129 range "1..max"; 2130 } 2131 default 3; 2132 description 2133 "Specifies the number times the NETCONF server tries to 2134 connect to a specific endpoint before moving on to the 2135 next endpoint in the list (round robin)."; 2136 } 2137 } 2138 } 2139 } 2140 } 2142 grouping cert-maps-grouping { 2143 description 2144 "A grouping that defines a container around the 2145 cert-to-name structure defined in RFC 7407."; 2146 container cert-maps { 2147 uses x509c2n:cert-to-name; 2148 description 2149 "The cert-maps container is used by a TLS-based NETCONF 2150 server to map the NETCONF client's presented X.509 2151 certificate to a NETCONF username. If no matching and 2152 valid cert-to-name list entry can be found, then the 2153 NETCONF server MUST close the connection, and MUST NOT 2154 accept NETCONF messages over it."; 2155 reference 2156 "RFC WWWW: NETCONF over TLS, Section 7"; 2157 } 2158 } 2160 grouping endpoints-container { 2161 description 2162 "This grouping is used by both the ssh and tls containers 2163 for call-home configurations."; 2164 container endpoints { 2165 description 2166 "Container for the list of endpoints."; 2167 list endpoint { 2168 key name; 2169 min-elements 1; 2170 ordered-by user; 2171 description 2172 "User-ordered list of endpoints for this NETCONF client. 2173 Defining more than one enables high-availability."; 2174 leaf name { 2175 type string; 2176 description 2177 "An arbitrary name for this endpoint."; 2179 } 2180 leaf address { 2181 type inet:host; 2182 mandatory true; 2183 description 2184 "The IP address or hostname of the endpoint. If a 2185 hostname is configured and the DNS resolution results 2186 in more than one IP address, the NETCONF server 2187 will process the IP addresses as if they had been 2188 explicitly configured in place of the hostname."; 2189 } 2190 leaf port { 2191 type inet:port-number; 2192 description 2193 "The IP port for this endpoint. The NETCONF server will 2194 use the IANA-assigned well-known port if no value is 2195 specified."; 2196 } 2197 } 2198 } 2199 } 2201 } 2203 2205 4.5. The RESTCONF Server Model 2207 The RESTCONF Server model presented in this section supports servers 2208 both listening for connections to accept as well as initiating call- 2209 home connections. This model supports the TLS transport only, as 2210 RESTCONF only supports HTTPS, using the TLS Server groupings 2211 presented in Section 4.3. All private keys and trusted certificates 2212 are held in the keychain model presented in Section 4.1. YANG 2213 feature statements are used to enable implementations to advertise 2214 which parts of the model the RESTCONF server supports. 2216 4.5.1. Tree Diagram 2218 The following tree diagram uses line-wrapping in order to comply with 2219 xml2rfc validation. This is annoying as I find that drafts (even txt 2220 drafts) look just fine with long lines - maybe xml2rfc should remove 2221 this warning? - or pyang could have an option to suppress printing 2222 leafref paths? 2224 module: ietf-restconf-server 2225 +--rw restconf-server 2226 +--rw listen {tls-listen}? 2227 | +--rw max-sessions? uint16 2228 | +--rw endpoint* [name] 2229 | +--rw name string 2230 | +--rw (transport) 2231 | +--:(tls) {tls-listen}? 2232 | +--rw tls 2233 | +--rw address? inet:ip-address 2234 | +--rw port inet:port-number 2235 | +--rw certificates 2236 | | +--rw certificate* [name] 2237 | | +--rw name -> /kc:keychain/private-keys/p 2238 rivate-key/certificates/certificate/name 2239 | +--rw client-auth 2240 | +--rw trusted-ca-certs? -> /kc:keychain/t 2241 rusted-certificates/name 2242 | +--rw trusted-client-certs? -> /kc:keychain/t 2243 rusted-certificates/name 2244 | +--rw cert-maps 2245 | +--rw cert-to-name* [id] 2246 | +--rw id uint32 2247 | +--rw fingerprint x509c2n:tls-fingerpr 2248 int 2249 | +--rw map-type identityref 2250 | +--rw name string 2251 +--rw call-home {tls-call-home}? 2252 +--rw restconf-client* [name] 2253 +--rw name string 2254 +--rw (transport) 2255 | +--:(tls) {tls-call-home}? 2256 | +--rw tls 2257 | +--rw endpoints 2258 | | +--rw endpoint* [name] 2259 | | +--rw name string 2260 | | +--rw address inet:host 2261 | | +--rw port? inet:port-number 2262 | +--rw certificates 2263 | | +--rw certificate* [name] 2264 | | +--rw name -> /kc:keychain/private-keys/p 2265 rivate-key/certificates/certificate/name 2266 | +--rw client-auth 2267 | +--rw trusted-ca-certs? -> /kc:keychain/t 2268 rusted-certificates/name 2269 | +--rw trusted-client-certs? -> /kc:keychain/t 2270 rusted-certificates/name 2271 | +--rw cert-maps 2272 | +--rw cert-to-name* [id] 2273 | +--rw id uint32 2274 | +--rw fingerprint x509c2n:tls-fingerpr 2275 int 2276 | +--rw map-type identityref 2277 | +--rw name string 2278 +--rw connection-type 2279 | +--rw (connection-type)? 2280 | +--:(persistent-connection) 2281 | | +--rw persistent! 2282 | | +--rw keep-alives 2283 | | +--rw max-wait? uint16 2284 | | +--rw max-attempts? uint8 2285 | +--:(periodic-connection) 2286 | +--rw periodic! 2287 | +--rw reconnect-timeout? uint16 2288 +--rw reconnect-strategy 2289 +--rw start-with? enumeration 2290 +--rw max-attempts? uint8 2292 4.5.2. Example Usage 2294 Configuring a RESTCONF Server to listen for RESTCONF client 2295 connections, as well as configuring call-home to one RESTCONF client. 2297 This example is consistent with other examples presented in this 2298 document. 2300 2303 2304 2305 2306 netconf/tls 2307 2308
11.22.33.44
2309 2310 ex-key-sect571r1-cert 2311 2312 2313 2314 deployment-specific-ca-certs 2315 2316 2317 explicitly-trusted-client-certs 2318 2319 2320 2321 1 2322 11:0A:05:11:00 2323 x509c2n:san-any 2324 2325 2326 2 2327 B3:4F:A1:8C:54 2328 x509c2n:specified 2329 scooby-doo 2330 2331 2332 2333 2335 2336 2338 2339 2340 2341 config-manager 2342 2343 2344 2345 east-data-center 2346
22.33.44.55
2347 2348 2349 west-data-center 2350
33.44.55.66
2351 2352 2353 2354 ex-key-sect571r1-cert 2355 2356 2357 2358 deployment-specific-ca-certs 2359 2360 2361 explicitly-trusted-client-certs 2362 2363 2364 2365 1 2366 11:0A:05:11:00 2367 x509c2n:san-any 2368 2369 2370 2 2371 B3:4F:A1:8C:54 2372 x509c2n:specified 2373 scooby-doo 2374 2375 2376 2377 2378 2379 2380 300 2381 60 2382 2383 2384 2385 last-connected 2386 3 2387 2388 2389 2391 2393 4.5.3. YANG Model 2395 This YANG module imports YANG types from [RFC6991] and [RFC7407]. 2397 file "ietf-restconf-server@2015-10-09.yang" 2399 module ietf-restconf-server { 2400 yang-version 1.1; 2402 namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server"; 2403 prefix "rcserver"; 2405 //import ietf-netconf-acm { 2406 // prefix nacm; // RFC 6536 2407 //} 2408 import ietf-inet-types { // RFC 6991 2409 prefix inet; 2410 } 2411 import ietf-x509-cert-to-name { // RFC 7407 2412 prefix x509c2n; 2413 } 2414 import ietf-tls-server { // RFC VVVV 2415 prefix ts; 2416 revision-date 2015-10-09; 2418 } 2420 organization 2421 "IETF NETCONF (Network Configuration) Working Group"; 2423 contact 2424 "WG Web: 2425 WG List: 2427 WG Chair: Mehmet Ersue 2428 2430 WG Chair: Mahesh Jethanandani 2431 2433 Editor: Kent Watsen 2434 "; 2436 description 2437 "This module contains a collection of YANG definitions for 2438 configuring RESTCONF servers. 2440 Copyright (c) 2014 IETF Trust and the persons identified as 2441 authors of the code. All rights reserved. 2443 Redistribution and use in source and binary forms, with or 2444 without modification, is permitted pursuant to, and subject 2445 to the license terms contained in, the Simplified BSD 2446 License set forth in Section 4.c of the IETF Trust's 2447 Legal Provisions Relating to IETF Documents 2448 (http://trustee.ietf.org/license-info). 2450 This version of this YANG module is part of RFC VVVV; see 2451 the RFC itself for full legal notices."; 2453 revision "2015-10-09" { 2454 description 2455 "Initial version"; 2456 reference 2457 "RFC VVVV: NETCONF Server and RESTCONF Server Configuration 2458 Models"; 2459 } 2461 // Features 2463 feature tls-listen { 2464 description 2465 "The listen feature indicates that the RESTCONF server 2466 supports opening a port to listen for incoming RESTCONF 2467 client connections."; 2468 reference 2469 "RFC XXXX: RESTCONF Protocol"; 2470 } 2472 feature tls-call-home { 2473 description 2474 "The call-home feature indicates that the RESTCONF server 2475 supports initiating connections to RESTCONF clients."; 2476 reference 2477 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 2478 } 2480 feature client-cert-auth { 2481 description 2482 "The client-cert-auth feature indicates that the RESTCONF 2483 server supports the ClientCertificate authentication scheme."; 2484 reference 2485 "RFC ZZZZ: Client Authentication over New TLS Connection"; 2486 } 2488 // top-level container 2489 container restconf-server { 2490 description 2491 "Top-level container for RESTCONF server configuration."; 2493 container listen { 2494 if-feature tls-listen; 2495 description 2496 "Configures listen behavior"; 2497 leaf max-sessions { 2498 type uint16; 2499 default 0; // should this be 'max'? 2500 description 2501 "Specifies the maximum number of concurrent sessions 2502 that can be active at one time. The value 0 indicates 2503 that no artificial session limit should be used."; 2504 } 2505 list endpoint { 2506 key name; 2507 description 2508 "List of endpoints to listen for RESTCONF connections on."; 2509 leaf name { 2510 type string; 2511 description 2512 "An arbitrary name for the RESTCONF listen endpoint."; 2513 } 2514 choice transport { 2515 mandatory true; 2516 description 2517 "Selects between available transports."; 2518 case tls { 2519 if-feature tls-listen; 2520 container tls { 2521 description 2522 "TLS-specific listening configuration for inbound 2523 connections."; 2524 uses ts:listening-tls-server-grouping { 2525 refine port { 2526 default 443; 2527 } 2528 augment "client-auth" { 2529 description 2530 "Augments in the cert-to-name structure."; 2531 uses cert-maps-grouping; 2532 } 2533 } 2534 } 2535 } 2536 } 2537 } 2538 } 2540 container call-home { 2541 if-feature tls-call-home; 2542 description 2543 "Configures call-home behavior"; 2544 list restconf-client { 2545 key name; 2546 description 2547 "List of RESTCONF clients the RESTCONF server is to 2548 initiate call-home connections to."; 2549 leaf name { 2550 type string; 2551 description 2552 "An arbitrary name for the remote RESTCONF client."; 2553 } 2554 choice transport { 2555 mandatory true; 2556 description 2557 "Selects between TLS and any transports augmented in."; 2558 case tls { 2559 if-feature tls-call-home; 2560 container tls { 2561 description 2562 "Specifies TLS-specific call-home transport 2563 configuration."; 2564 uses endpoints-container { 2565 refine endpoints/endpoint/port { 2566 default 9999; 2567 } 2568 } 2569 uses ts:non-listening-tls-server-grouping { 2570 augment "client-auth" { 2571 description 2572 "Augments in the cert-to-name structure."; 2573 uses cert-maps-grouping; 2574 } 2575 } 2576 } 2577 } 2578 } 2579 container connection-type { 2580 description 2581 "Indicates the RESTCONF client's preference for how the 2582 RESTCONF server's connection is maintained."; 2583 choice connection-type { 2584 description 2585 "Selects between available connection types."; 2586 case persistent-connection { 2587 container persistent { 2588 presence true; 2589 description 2590 "Maintain a persistent connection to the RESTCONF 2591 client. If the connection goes down, immediately 2592 start trying to reconnect to it, using the 2593 reconnection strategy. 2595 This connection type minimizes any RESTCONF client 2596 to RESTCONF server data-transfer delay, albeit at 2597 the expense of holding resources longer."; 2599 container keep-alives { 2600 description 2601 "Configures the keep-alive policy, to proactively 2602 test the aliveness of the TLS client. An 2603 unresponsive TLS client will be dropped after 2604 approximately (max-attempts * max-wait) seconds."; 2605 reference 2606 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home, 2607 Section 3.1, item S6"; 2608 leaf max-wait { 2609 type uint16 { 2610 range "1..max"; 2611 } 2612 units seconds; 2613 default 30; 2614 description 2615 "Sets the amount of time in seconds after which 2616 if no data has been received from the TLS 2617 client, a TLS-level message will be sent to 2618 test the aliveness of the TLS client."; 2619 } 2620 leaf max-attempts { 2621 type uint8; 2622 default 3; 2623 description 2624 "Sets the number of sequential keep-alive messages 2625 that can fail to obtain a response from the TLS 2626 client before assuming the TLS client is no 2627 longer alive."; 2628 } 2629 } 2630 } 2631 } 2632 case periodic-connection { 2633 container periodic { 2634 presence true; 2635 description 2636 "Periodically connect to the RESTCONF client, so that 2637 the RESTCONF client may deliver messages pending for 2638 the RESTCONF server. The RESTCONF client is expected 2639 to close the connection when it is ready to release 2640 it, thus starting the RESTCONF server's timer until 2641 next connection."; 2642 leaf reconnect-timeout { 2643 type uint16 { 2644 range "1..max"; 2645 } 2646 units minutes; 2647 default 60; 2648 description 2649 "The maximum amount of unconnected time the RESTCONF 2650 server will wait before re-establishing a connection 2651 to the RESTCONF client. The RESTCONF server may 2652 initiate a connection before this time if desired 2653 (e.g., to deliver a notification)."; 2654 } 2656 } 2657 } 2658 } 2659 } 2660 container reconnect-strategy { 2661 description 2662 "The reconnection strategy guides how a RESTCONF server 2663 reconnects to an RESTCONF client, after losing a connection 2664 to it, even if due to a reboot. The RESTCONF server starts 2665 with the specified endpoint and tries to connect to it 2666 max-attempts times before trying the next endpoint in the 2667 list (round robin)."; 2668 leaf start-with { 2669 type enumeration { 2670 enum first-listed { 2671 description 2672 "Indicates that reconnections should start with 2673 the first endpoint listed."; 2674 } 2675 enum last-connected { 2676 description 2677 "Indicates that reconnections should start with 2678 the endpoint last connected to. If no previous 2679 connection has ever been established, then the 2680 first endpoint configured is used. RESTCONF 2681 servers SHOULD be able to remember the last 2682 endpoint connected to across reboots."; 2683 } 2684 } 2685 default first-listed; 2686 description 2687 "Specifies which of the RESTCONF client's endpoints the 2688 RESTCONF server should start with when trying to connect 2689 to the RESTCONF client."; 2690 } 2691 leaf max-attempts { 2692 type uint8 { 2693 range "1..max"; 2694 } 2695 default 3; 2696 description 2697 "Specifies the number times the RESTCONF server tries to 2698 connect to a specific endpoint before moving on to the 2699 next endpoint in the list (round robin)."; 2700 } 2701 } 2702 } 2703 } 2705 } 2707 grouping cert-maps-grouping { 2708 description 2709 "A grouping that defines a container around the 2710 cert-to-name structure defined in RFC 7407."; 2711 container cert-maps { 2712 uses x509c2n:cert-to-name; 2713 description 2714 "The cert-maps container is used by a TLS-based RESTCONF 2715 server to map the RESTCONF client's presented X.509 2716 certificate to a RESTCONF username. If no matching and 2717 valid cert-to-name list entry can be found, then the 2718 RESTCONF server MUST close the connection, and MUST NOT 2719 accept RESTCONF messages over it."; 2720 reference 2721 "RFC XXXX: The RESTCONF Protocol"; 2722 } 2723 } 2725 grouping endpoints-container { 2726 description 2727 "This grouping is used by tls container for call-home 2728 configurations."; 2729 container endpoints { 2730 description 2731 "Container for the list of endpoints."; 2732 list endpoint { 2733 key name; 2734 min-elements 1; 2735 ordered-by user; 2736 description 2737 "User-ordered list of endpoints for this RESTCONF client. 2738 Defining more than one enables high-availability."; 2739 leaf name { 2740 type string; 2741 description 2742 "An arbitrary name for this endpoint."; 2743 } 2744 leaf address { 2745 type inet:host; 2746 mandatory true; 2747 description 2748 "The IP address or hostname of the endpoint. If a 2749 hostname is configured and the DNS resolution results 2750 in more than one IP address, the RESTCONF server 2751 will process the IP addresses as if they had been 2752 explicitly configured in place of the hostname."; 2753 } 2754 leaf port { 2755 type inet:port-number; 2756 description 2757 "The IP port for this endpoint. The RESTCONF server will 2758 use the IANA-assigned well-known port if no value is 2759 specified."; 2760 } 2761 } 2762 } 2763 } 2765 } 2767 2769 5. Security Considerations 2771 This section needs to be filled in... 2773 6. IANA Considerations 2775 This document registers two URIs in the IETF XML registry [RFC2119]. 2776 Following the format in [RFC3688], the following registrations are 2777 requested: 2779 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server 2780 Registrant Contact: The NETCONF WG of the IETF. 2781 XML: N/A, the requested URI is an XML namespace. 2783 URI: urn:ietf:params:xml:ns:yang:ietf-restconf-server 2784 Registrant Contact: The NETCONF WG of the IETF. 2785 XML: N/A, the requested URI is an XML namespace. 2787 This document registers two YANG modules in the YANG Module Names 2788 registry [RFC6020]. Following the format in [RFC6020], the the 2789 following registrations are requested: 2791 name: ietf-keychain 2792 namespace: urn:ietf:params:xml:ns:yang:ietf-keychain 2793 prefix: kc 2794 reference: RFC VVVV 2796 name: ietf-ssh-server 2797 namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-server 2798 prefix: ssvr 2799 reference: RFC VVVV 2801 name: ietf-tls-server 2802 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 2803 prefix: tsvr 2804 reference: RFC VVVV 2806 name: ietf-netconf-server 2807 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server 2808 prefix: ncsvr 2809 reference: RFC VVVV 2811 name: ietf-restconf-server 2812 namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server 2813 prefix: rcsvr 2814 reference: RFC VVVV 2816 7. Other Considerations 2818 The YANG modules define herein do not themselves support virtual 2819 routing and forwarding (VRF). It is expected that external modules 2820 will augment in VRF designations when needed. 2822 8. Acknowledgements 2824 The authors would like to thank for following for lively discussions 2825 on list and in the halls (ordered by last name): Andy Bierman, Martin 2826 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 2827 Ladislav Lhotka, Radek Krejci, Tom Petch, Phil Shafer, and Bert 2828 Wijnen. 2830 Juergen Schoenwaelder and was partly funded by Flamingo, a Network of 2831 Excellence project (ICT-318488) supported by the European Commission 2832 under its Seventh Framework Programme. 2834 9. References 2835 9.1. Normative References 2837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2838 Requirement Levels", BCP 14, RFC 2119, March 1997. 2840 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2841 Network Configuration Protocol (NETCONF)", RFC 6020, 2842 October 2010. 2844 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 2845 Shell Authentication", RFC 6187, March 2011. 2847 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2848 Bierman, "Network Configuration Protocol (NETCONF)", RFC 2849 6241, June 2011. 2851 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2852 Shell (SSH)", RFC 6242, June 2011. 2854 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 2855 July 2013. 2857 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 2858 SNMP Configuration", RFC 7407, December 2014. 2860 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 2861 NETCONF Protocol over Transport Layer Security (TLS) with 2862 Mutual X.509 Authentication", RFC 7589, June 2015. 2864 [draft-ietf-netconf-call-home] 2865 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 2866 draft-ieft-netconf-call-home-02 (work in progress), 2014. 2868 [draft-ietf-netconf-restconf] 2869 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2870 Protocol", draft-ieft-netconf-restconf-04 (work in 2871 progress), 2014. 2873 9.2. Informative References 2875 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2876 January 2004. 2878 Appendix A. Change Log 2880 A.1. 00 to 01 2882 o Restructured document so it flows better 2884 o Added trusted-ca-certs and trusted-client-certs objects into the 2885 ietf-system-tls-auth module 2887 A.2. 01 to 02 2889 o removed the "one-to-many" construct 2891 o removed "address" as a key field 2893 o removed "network-manager" terminology 2895 o moved open issues to github issues 2897 o brought TLS client auth back into model 2899 A.3. 02 to 03 2901 o fixed tree diagrams and surrounding text 2903 A.4. 03 to 04 2905 o reduced the number of grouping statements 2907 o removed psk-maps and associated feature statements 2909 o added ability for listen/call-home instances to specify which 2910 host-keys/certificates (of all listed) to use 2912 o clarified that last-connected should span reboots 2914 o added missing "objectives" for selecting which keys to use, 2915 authenticating client-certificates, and mapping authenticated 2916 client-certificates to usernames 2918 o clarified indirect client certificate authentication 2920 o added keep-alive configuration for listen connections 2922 o added global-level NETCONF session parameters 2924 A.5. 04 to 05 2926 o Removed all refs to the old ietf-system-tls-auth module 2928 o Removed YANG 1.1 style if-feature statements (loss some 2929 expressiveness) 2931 o Removed the read-only (config false) lists of SSH host-keys and 2932 TLS certs 2934 o Added an if-feature around session-options container 2936 o Added ability to configure trust-anchors for SSH X.509 client 2937 certs 2939 o Now imports by revision, per best practice 2941 o Added support for RESTCONF server 2943 o Added RFC Editor instructions 2945 A.6. 05 to 06 2947 o Removed feature statement on the session-options container (issue 2948 #21). 2950 o Added NACM statements to YANG modules for sensitive nodes (issue 2951 #24). 2953 o Fixed default RESTCONF server port value to be 443 (issue #26). 2955 o Added client-cert-auth subtree to ietf-restconf-server module 2956 (issue #27). 2958 o Updated draft-ietf-netmod-snmp-cfg reference to RFC 7407 (issue 2959 #28). 2961 o Added description statements for groupings (issue #29). 2963 o Added description for braces to tree diagram section (issue #30). 2965 o Renamed feature from "rfc6187" to "ssh-x509-certs" (issue #31). 2967 A.7. 06 to 07 2969 o Replaced "application" with "NETCONF/RESTCONF client" (issue #32). 2971 o Reverted back to YANG 1.1 if-feature statements (issue #34). 2973 o Removed import by revisions (issue #36). 2975 o Removed groupings only used once (issue #37). 2977 o Removed upper-bound on hello-timeout, idle-timeout, and max- 2978 sessions (issue #38). 2980 o Clarified that when no listen address is configured, the NETCONF/ 2981 RESTCONF server will listen on all addresses (issue #41). 2983 o Update keep-alive reference to new section in Call Home draft 2984 (issue #42). 2986 o Modified connection-type/persistent/keep-alives/interval-secs 2987 default value, removed the connection-type/periodic/linger-secs 2988 node, and also removed the reconnect-strategy/interval-secs node 2989 (issue #43). 2991 o Clarified how last-connected reconnection type should work across 2992 reboots (issue #44). 2994 o Clarified how DNS-expanded hostnames should be processed (issue 2995 #45). 2997 o Removed text on how to implement keep-alives (now in the call-home 2998 draft) and removed the keep-alive configuration for listen 2999 connections (issue #46). 3001 o Clarified text for .../periodic-connection/timeout-mins (issue 3002 #47). 3004 o Fixed description on the "trusted-ca-certs" leaf-list (issue #48). 3006 o Added optional keychain-based solution in appendix A (issue #49). 3008 o Fixed description text for the interval-secs leaf (issue #50). 3010 o moved idle-time into the listen, persistent, and periodic subtrees 3011 (issue #51). 3013 o put presence statements on containers where it makes sense (issue 3014 #53). 3016 A.8. 07 to 08 3018 o Per WG consensus, replaced body with the keychain-based approach 3019 described in -07's Appendix. 3021 o Added a lot of introductory text, improved examples, and what not. 3023 Appendix B. Open Issues 3025 Please see: https://github.com/netconf-wg/server-model/issues. 3027 Authors' Addresses 3029 Kent Watsen 3030 Juniper Networks 3032 EMail: kwatsen@juniper.net 3034 Juergen Schoenwaelder 3035 Jacobs University Bremen 3037 EMail: j.schoenwaelder@jacobs-university.de