idnits 2.17.1 draft-ietf-netconf-tls-client-server-14.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 -- The document date (July 2, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-09 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-11 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-05 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track G. Wu 5 Expires: January 3, 2020 Cisco Systems 6 L. Xia 7 Huawei 8 July 2, 2019 10 YANG Groupings for TLS Clients and TLS Servers 11 draft-ietf-netconf-tls-client-server-14 13 Abstract 15 This document defines three YANG modules: the first defines groupings 16 for a generic TLS client, the second defines groupings for a generic 17 TLS server, and the third defines common identities and groupings 18 used by both the client and the server. It is intended that these 19 groupings will be used by applications using the TLS protocol. 21 Editorial Note (To be removed by RFC Editor) 23 This draft contains many placeholder values that need to be replaced 24 with finalized values at the time of publication. This note 25 summarizes all of the substitutions that are needed. No other RFC 26 Editor instructions are specified elsewhere in 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 I-D.ietf-netconf-trust-anchors 35 o I-D.ietf-netconf-keystore 37 Artwork in this document contains shorthand references to drafts in 38 progress. Please apply the following replacements: 40 o "XXXX" --> the assigned RFC value for this draft 42 o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust- 43 anchors 45 o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore 47 Artwork in this document contains placeholder values for the date of 48 publication of this draft. Please apply the following replacement: 50 o "2019-07-02" --> the publication date of this draft 52 The following Appendix section is to be removed prior to publication: 54 o Appendix A. Change Log 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at https://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on January 3, 2020. 73 Copyright Notice 75 Copyright (c) 2019 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (https://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4 95 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 96 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10 97 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 98 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 99 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 100 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 18 101 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 102 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 27 103 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 106 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 37 107 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 38 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 110 8.2. Informative References . . . . . . . . . . . . . . . . . 40 111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 112 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 42 113 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 42 114 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 42 115 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 42 116 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 43 117 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 43 118 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 43 119 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 43 120 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 43 121 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 43 122 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 44 123 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 44 124 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 44 125 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 44 126 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 45 127 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 130 1. Introduction 132 This document defines three YANG 1.1 [RFC7950] modules: the first 133 defines a grouping for a generic TLS client, the second defines a 134 grouping for a generic TLS server, and the third defines identities 135 and groupings common to both the client and the server (TLS is 136 defined in [RFC5246]). It is intended that these groupings will be 137 used by applications using the TLS protocol. For instance, these 138 groupings could be used to help define the data model for an HTTPS 139 [RFC2818] server or a NETCONF over TLS [RFC7589] based server. 141 The client and server YANG modules in this document each define one 142 grouping, which is focused on just TLS-specific configuration, and 143 specifically avoids any transport-level configuration, such as what 144 ports to listen-on or connect-to. This affords applications the 145 opportunity to define their own strategy for how the underlying TCP 146 connection is established. For instance, applications supporting 147 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping" 148 grouping for the TLS parts it provides, while adding data nodes for 149 the TCP-level call-home configuration. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. The TLS Client Model 161 3.1. Tree Diagram 163 This section provides a tree diagram [RFC8340] for the "ietf-tls- 164 client" module that does not have groupings expanded. 166 module: ietf-tls-client 168 grouping tls-client-grouping 169 +-- client-identity 170 | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping 171 +-- server-authentication 172 | +-- ca-certs? ts:certificates-ref 173 | | {ts:x509-certificates}? 174 | +-- server-certs? ts:certificates-ref 175 | {ts:x509-certificates}? 176 +-- hello-params {tls-client-hello-params-config}? 177 | +---u tlscmn:hello-params-grouping 178 +-- keepalives! {tls-client-keepalives}? 179 +-- max-wait? uint16 180 +-- max-attempts? uint8 182 3.2. Example Usage 184 This section presents two examples showing the tls-client-grouping 185 populated with some data. These examples are effectively the same 186 except the first configures the client identity using a local key 187 while the second uses a key configured in a keystore. Both examples 188 are consistent with the examples presented in Section 2 of 189 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 190 [I-D.ietf-netconf-keystore]. 192 The following example configures the client identity using a local 193 key: 195 197 198 199 200 rsa2048 201 base64encodedvalue== 202 base64encodedvalue== 203 base64encodedvalue== 204 205 207 208 209 explicitly-trusted-server-ca-certs 210 explicitly-trusted-server-certs 211 213 214 30 215 3 216 218 220 The following example configures the client identity using a key from 221 the keystore: 223 225 226 227 228 ex-rsa-key 229 ex-rsa-cert 230 231 233 234 235 explicitly-trusted-server-ca-certs 236 explicitly-trusted-server-certs 237 239 240 30 241 3 242 244 246 3.3. YANG Module 248 This YANG module has normative references to 249 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. 251 file "ietf-tls-client@2019-07-02.yang" 252 module ietf-tls-client { 253 yang-version 1.1; 254 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 255 prefix tlsc; 257 import ietf-tls-common { 258 prefix tlscmn; 259 revision-date 2019-07-02; // stable grouping definitions 260 reference 261 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 262 } 264 import ietf-truststore { 265 prefix ts; 266 reference 267 "RFC YYYY: A YANG Data Model for a Truststore"; 268 } 270 import ietf-keystore { 271 prefix ks; 272 reference 273 "RFC ZZZZ: A YANG Data Model for a Keystore"; 274 } 276 import ietf-netconf-acm { 277 prefix nacm; 278 reference 279 "RFC 8341: Network Configuration Access Control Model"; 280 } 282 organization 283 "IETF NETCONF (Network Configuration) Working Group"; 285 contact 286 "WG Web: 287 WG List: 288 Author: Kent Watsen 289 Author: Gary Wu "; 291 description 292 "This module defines reusable groupings for TLS clients that 293 can be used as a basis for specific TLS client instances. 295 Copyright (c) 2019 IETF Trust and the persons identified 296 as authors of the code. All rights reserved. 298 Redistribution and use in source and binary forms, with 299 or without modification, is permitted pursuant to, and 300 subject to the license terms contained in, the Simplified 301 BSD License set forth in Section 4.c of the IETF Trust's 302 Legal Provisions Relating to IETF Documents 303 (https://trustee.ietf.org/license-info). 305 This version of this YANG module is part of RFC XXXX 306 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 307 itself for full legal notices.; 309 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 310 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 311 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 312 are to be interpreted as described in BCP 14 (RFC 2119) 313 (RFC 8174) when, and only when, they appear in all 314 capitals, as shown here."; 316 revision 2019-07-02 { 317 description 318 "Initial version"; 320 reference 321 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 322 } 324 // Features 326 feature tls-client-hello-params-config { 327 description 328 "TLS hello message parameters are configurable on a TLS 329 client."; 330 } 332 feature tls-client-keepalives { 333 description 334 "Per socket TLS keepalive parameters are configurable for 335 TLS clients on the server implementing this feature."; 336 } 338 // Groupings 340 grouping tls-client-grouping { 341 description 342 "A reusable grouping for configuring a TLS client without 343 any consideration for how an underlying TCP session is 344 established. 346 Note that this grouping uses fairly typical descendent 347 node names such that a stack of 'uses' statements will 348 have name conflicts. It is intended that the consuming 349 data model will resolve the issue (e.g., by wrapping 350 the 'uses' statement in a container called 351 'tls-client-parameters'). This model purposely does 352 not do this itself so as to provide maximum flexibility 353 to consuming models."; 355 container client-identity { // FIXME: what about PSKs? 356 nacm:default-deny-write; 357 description 358 "A locally-defined or referenced end-entity certificate, 359 including any configured intermediate certificates, the 360 TLS client will present when establishing a TLS connection 361 in its Certificate message, as defined in Section 7.4.2 362 in RFC 5246."; 363 reference 364 "RFC 5246: 365 The Transport Layer Security (TLS) Protocol Version 1.2 366 RFC ZZZZ: 367 YANG Data Model for a 'Keystore' Mechanism"; 369 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 370 } // container client-identity 372 container server-authentication { // FIXME: what about PSKs? 373 nacm:default-deny-write; 374 must 'ca-certs or server-certs'; 375 description 376 "Trusted server identities."; 377 leaf ca-certs { 378 if-feature "ts:x509-certificates"; 379 type ts:certificates-ref; 380 description 381 "A reference to a list of certificate authority (CA) 382 certificates used by the TLS client to authenticate 383 TLS server certificates. A server certificate is 384 authenticated if it has a valid chain of trust to 385 a configured CA certificate."; 386 } 387 leaf server-certs { 388 if-feature "ts:x509-certificates"; 389 type ts:certificates-ref; 390 description 391 "A reference to a list of server certificates used by 392 the TLS client to authenticate TLS server certificates. 393 A server certificate is authenticated if it is an 394 exact match to a configured server certificate."; 395 } 396 } // container server-authentication 398 container hello-params { 399 nacm:default-deny-write; 400 if-feature "tls-client-hello-params-config"; 401 uses tlscmn:hello-params-grouping; 402 description 403 "Configurable parameters for the TLS hello message."; 404 } // container hello-params 406 container keepalives { 407 nacm:default-deny-write; 408 if-feature "tls-client-keepalives"; 409 presence "Indicates that keepalives are enabled."; 410 description 411 "Configures the keep-alive policy, to proactively test 412 the aliveness of the TLS server. An unresponsive 413 TLS server is dropped after approximately max-wait 414 * max-attempts seconds."; 415 leaf max-wait { 416 type uint16 { 417 range "1..max"; 418 } 419 units "seconds"; 420 default "30"; 421 description 422 "Sets the amount of time in seconds after which if 423 no data has been received from the TLS server, a 424 TLS-level message will be sent to test the 425 aliveness of the TLS server."; 426 } 427 leaf max-attempts { 428 type uint8; 429 default "3"; 430 description 431 "Sets the maximum number of sequential keep-alive 432 messages that can fail to obtain a response from 433 the TLS server before assuming the TLS server is 434 no longer alive."; 435 } 436 } // container keepalives 437 } // grouping tls-client-grouping 438 } 439 441 4. The TLS Server Model 443 4.1. Tree Diagram 445 This section provides a tree diagram [RFC8340] for the "ietf-tls- 446 server" module that does not have groupings expanded. 448 module: ietf-tls-server 450 grouping tls-server-grouping 451 +-- server-identity 452 | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping 453 +-- client-authentication! 454 | +-- (required-or-optional) 455 | | +--:(required) 456 | | | +-- required? empty 457 | | +--:(optional) 458 | | +-- optional? empty 459 | +-- (local-or-external) 460 | +--:(local) {local-client-auth-supported}? 461 | | +-- ca-certs? ts:certificates-ref 462 | | | {ts:x509-certificates}? 463 | | +-- client-certs? ts:certificates-ref 464 | | {ts:x509-certificates}? 465 | +--:(external) {external-client-auth-supported}? 466 | +-- client-auth-defined-elsewhere? empty 467 +-- hello-params {tls-server-hello-params-config}? 468 | +---u tlscmn:hello-params-grouping 469 +-- keepalives! {tls-server-keepalives}? 470 +-- max-wait? uint16 471 +-- max-attempts? uint8 473 4.2. Example Usage 475 This section presents two examples showing the tls-server-grouping 476 populated with some data. These examples are effectively the same 477 except the first configures the server identity using a local key 478 while the second uses a key configured in a keystore. Both examples 479 are consistent with the examples presented in Section 2 of 480 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 481 [I-D.ietf-netconf-keystore]. 483 The following example configures the server identity using a local 484 key: 486 488 489 490 491 rsa2048 492 base64encodedvalue== 493 base64encodedvalue== 494 base64encodedvalue== 495 496 498 499 500 501 explicitly-trusted-client-ca-certs 502 explicitly-trusted-client-certs 503 505 507 The following example configures the server identity using a key from 508 the keystore: 510 512 513 514 515 ex-rsa-key 516 ex-rsa-cert 517 518 520 521 522 523 explicitly-trusted-client-ca-certs 524 explicitly-trusted-client-certs 525 527 529 4.3. YANG Module 531 This YANG module has a normative references to [RFC5246], 532 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. 534 file "ietf-tls-server@2019-07-02.yang" 535 module ietf-tls-server { 536 yang-version 1.1; 537 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 538 prefix tlss; 540 import ietf-tls-common { 541 prefix tlscmn; 542 revision-date 2019-07-02; // stable grouping definitions 543 reference 544 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 545 } 547 import ietf-truststore { 548 prefix ts; 549 reference 550 "RFC YYYY: A YANG Data Model for a Truststore"; 551 } 553 import ietf-keystore { 554 prefix ks; 555 reference 556 "RFC ZZZZ: A YANG Data Model for a Keystore"; 557 } 559 import ietf-netconf-acm { 560 prefix nacm; 561 reference 562 "RFC 8341: Network Configuration Access Control Model"; 563 } 565 organization 566 "IETF NETCONF (Network Configuration) Working Group"; 568 contact 569 "WG Web: 570 WG List: 571 Author: Kent Watsen 572 Author: Gary Wu "; 574 description 575 "This module defines reusable groupings for TLS servers that 576 can be used as a basis for specific TLS server instances. 578 Copyright (c) 2019 IETF Trust and the persons identified 579 as authors of the code. All rights reserved. 581 Redistribution and use in source and binary forms, with 582 or without modification, is permitted pursuant to, and 583 subject to the license terms contained in, the Simplified 584 BSD License set forth in Section 4.c of the IETF Trust's 585 Legal Provisions Relating to IETF Documents 586 (https://trustee.ietf.org/license-info). 588 This version of this YANG module is part of RFC XXXX 589 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 590 itself for full legal notices.; 592 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 593 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 594 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 595 are to be interpreted as described in BCP 14 (RFC 2119) 596 (RFC 8174) when, and only when, they appear in all 597 capitals, as shown here."; 599 revision 2019-07-02 { 600 description 601 "Initial version"; 602 reference 603 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 604 } 606 // Features 608 feature tls-server-hello-params-config { 609 description 610 "TLS hello message parameters are configurable on a TLS 611 server."; 612 } 614 feature tls-server-keepalives { 615 description 616 "Per socket TLS keepalive parameters are configurable for 617 TLS servers on the server implementing this feature."; 618 } 620 feature local-client-auth-supported { 621 description 622 "Indicates that the TLS server supports local 623 configuration of client credentials."; 624 } 626 feature external-client-auth-supported { 627 description 628 "Indicates that the TLS server supports external 629 configuration of client credentials."; 630 } 632 // Groupings 634 grouping tls-server-grouping { 635 description 636 "A reusable grouping for configuring a TLS server without 637 any consideration for how underlying TCP sessions are 638 established. 640 Note that this grouping uses fairly typical descendent 641 node names such that a stack of 'uses' statements will 642 have name conflicts. It is intended that the consuming 643 data model will resolve the issue (e.g., by wrapping 644 the 'uses' statement in a container called 645 'tls-server-parameters'). This model purposely does 646 not do this itself so as to provide maximum flexibility 647 to consuming models."; 649 container server-identity { // FIXME: what about PSKs? 650 nacm:default-deny-write; 651 description 652 "A locally-defined or referenced end-entity certificate, 653 including any configured intermediate certificates, the 654 TLS server will present when establishing a TLS connection 655 in its Certificate message, as defined in Section 7.4.2 656 in RFC 5246."; 657 reference 658 "RFC 5246: 659 The Transport Layer Security (TLS) Protocol Version 1.2 660 RFC ZZZZ: 661 YANG Data Model for a 'Keystore' Mechanism"; 662 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 663 } // container server-identity 665 container client-authentication { // FIXME: what about PSKs? 666 nacm:default-deny-write; 667 presence 668 "Indicates that certificate based client authentication 669 is supported (i.e., the server will request that the 670 client send a certificate)."; 671 description 672 "Specifies if TLS client authentication is required or 673 optional, and specifies if the certificates needed to 674 authenticate the TLS client are configured locally or 675 externally. If configured locally, the data model 676 enables both trust anchors and end-entity certificate 677 to be set."; 678 choice required-or-optional { 679 mandatory true; // or default to 'required' ? 680 description 681 "Indicates if TLS-level client authentication is required 682 or optional. This is necessary for some protocols (e.g., 683 RESTCONF) the may optionally authenticate a client via 684 TLS-level authentication, HTTP-level authentication, or 685 both simultaneously)."; 686 leaf required { 687 type empty; 688 description 689 "Indicates that TLS-level client authentication is 690 required."; 691 } 692 leaf optional { 693 type empty; 694 description 695 "Indicates that TLS-level client authentication is 696 optional."; 697 } 698 } 699 choice local-or-external { 700 mandatory true; 701 description 702 "Indicates if the certificates needed to authenticate 703 the client are configured locally or externally. The 704 need to support external configuration for client 705 authentication stems from the desire to support 706 consuming data models that prefer to place client 707 authentication with client definitions, rather then 708 in a data model principally concerned with configuring 709 the transport."; 710 case local { 711 if-feature "local-client-auth-supported"; 712 description 713 "The certificates needed to authenticate the clients 714 are configured locally."; 715 leaf ca-certs { 716 if-feature "ts:x509-certificates"; 717 type ts:certificates-ref;//FIXME: local-or-remote? 718 description 719 "A reference to a list of certificate authority (CA) 720 certificates used by the TLS server to authenticate 721 TLS client certificates. A client certificate is 722 authenticated if it has a valid chain of trust to 723 a configured CA certificate."; 724 reference 725 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 726 } 727 leaf client-certs { 728 if-feature "ts:x509-certificates"; 729 type ts:certificates-ref;//FIXME: local-or-remote? 730 description 731 "A reference to a list of client certificates 732 used by the TLS server to authenticate TLS 733 client certificates. A clients certificate 734 is authenticated if it is an exact match to 735 a configured client certificate."; 736 reference 737 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 738 } 739 } 740 case external { 741 if-feature "external-client-auth-supported"; 742 description 743 "The certificates needed to authenticate the clients 744 are configured externally."; 745 leaf client-auth-defined-elsewhere { 746 type empty; 747 description 748 "Indicates that certificates needed to authenticate 749 clients are configured elsewhere."; 750 } 751 } 752 } // choice local-or-external 753 } // container client-authentication 755 container hello-params { 756 nacm:default-deny-write; 757 if-feature "tls-server-hello-params-config"; 758 uses tlscmn:hello-params-grouping; 759 description 760 "Configurable parameters for the TLS hello message."; 761 } // container hello-params 763 container keepalives { 764 nacm:default-deny-write; 765 if-feature "tls-server-keepalives"; 766 presence "Indicates that keepalives are enabled."; 767 description 768 "Configures the keep-alive policy, to proactively test 769 the aliveness of the TLS client. An unresponsive 770 TLS client is dropped after approximately max-wait 771 * max-attempts seconds."; 772 leaf max-wait { 773 type uint16 { 774 range "1..max"; 775 } 776 units "seconds"; 777 default "30"; 778 description 779 "Sets the amount of time in seconds after which if 780 no data has been received from the TLS client, a 781 TLS-level message will be sent to test the 782 aliveness of the TLS client."; 783 } 784 leaf max-attempts { 785 type uint8; 786 default "3"; 787 description 788 "Sets the maximum number of sequential keep-alive 789 messages that can fail to obtain a response from 790 the TLS client before assuming the TLS client is 791 no longer alive."; 792 } 793 } // container keepalives 794 } // grouping tls-server-grouping 795 } 796 798 5. The TLS Common Model 800 The TLS common model presented in this section contains identities 801 and groupings common to both TLS clients and TLS servers. The hello- 802 params-grouping can be used to configure the list of TLS algorithms 803 permitted by the TLS client or TLS server. The lists of algorithms 804 are ordered such that, if multiple algorithms are permitted by the 805 client, the algorithm that appears first in its list that is also 806 permitted by the server is used for the TLS transport layer 807 connection. The ability to restrict the algorithms allowed is 808 provided in this grouping for TLS clients and TLS servers that are 809 capable of doing so and may serve to make TLS clients and TLS servers 810 compliant with local security policies. This model supports both 811 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446]. 813 TLS 1.2 and TLS 1.3 have different ways defining their own supported 814 cryptographic algorithms, see TLS and DTLS IANA registries page 815 (https://www.iana.org/assignments/tls-parameters/tls- 816 parameters.xhtml): 818 o TLS 1.2 defines four categories of registries for cryptographic 819 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS 820 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the 821 role of combining all of them into one set, as each value of the 822 set represents a unique and feasible combination of all the 823 cryptographic algorithms, and thus the other three registry 824 categories do not need to be considered here. In this document, 825 the TLS common model only chooses those TLS1.2 algorithms in TLS 826 Cipher Suites which are marked as recommended: 827 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 828 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, 829 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, 830 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen 831 algorithms are enumerated in Table 1-1 below; 833 o TLS 1.3 defines its supported algorithms differently. Firstly, it 834 defines three categories of registries for cryptographic 835 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported 836 Groups. Secondly, all three of these categories are useful, since 837 they represent different parts of all the supported algorithms 838 respectively. Thus, all of these registries categories are 839 considered here. In this draft, the TLS common model chooses only 840 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of 841 [RFC8446]. 843 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites 844 part of the hello-params-grouping should include three parameters for 845 configuring its permitted TLS algorithms, which are: TLS Cipher 846 Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2 847 only uses TLS Cipher Suites. 849 [I-D.ietf-netconf-crypto-types] defines six categories of 850 cryptographic algorithms (hash-algorithm, symmetric-key-encryption- 851 algorithm, mac-algorithm, asymmetric-key-encryption-algorithm, 852 signature-algorithm, key-negotiation-algorithm) and lists several 853 widely accepted algorithms for each of them. The TLS client and 854 server models use one or more of these algorithms. The following 855 tables are provided, in part to define the subset of algorithms 856 defined in the crypto-types model used by TLS, and in part to ensure 857 compatibility of configured TLS cryptographic parameters for 858 configuring its permitted TLS algorithms: 860 +-----------------------------------------------+---------+ 861 | ciper-suites in hello-params-grouping | HASH | 862 +-----------------------------------------------+---------+ 863 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | 864 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | 865 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | 866 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | 867 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 | 868 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 | 869 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | 870 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | 871 | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 | 872 | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 | 873 | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 | 874 | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 | 875 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 876 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 877 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 878 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 879 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 880 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | 881 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | 882 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 | 883 +-----------------------------------------------+---------+ 885 Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping 886 to hash-algorithm 888 +--------------------------------------------- +---------------------+ 889 | ciper-suites in hello-params-grouping | symmetric | 890 | | | 891 +--------------------------------------------- +---------------------+ 892 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 893 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 894 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 895 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 896 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 897 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 898 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 899 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 900 | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm | 901 | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm | 902 | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm | 903 | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm | 904 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 905 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305| 906 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 907 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 908 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 909 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 910 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 911 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm | 912 +--------------------------------------------- +---------------------+ 914 Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping 915 to symmetric-key-encryption-algorithm 917 +--------------------------------------------- +---------------------+ 918 | ciper-suites in hello-params-grouping | MAC | 919 | | | 920 +--------------------------------------------- +---------------------+ 921 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 922 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 923 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 924 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 925 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 926 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 927 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 928 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 929 | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm | 930 | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm | 931 | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm | 932 | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm | 933 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 934 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305| 935 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 936 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 937 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 938 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 939 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 940 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm | 941 +--------------------------------------------- +---------------------+ 943 Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping 944 to MAC-algorithm 946 +----------------------------------------------+----------------------+ 947 |ciper-suites in hello-params-grouping | signature | 948 +--------------------------------------------- +----------------------+ 949 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | 950 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | 951 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | 952 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | 953 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256| 954 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384| 955 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | 956 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | 957 | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 | 958 | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 | 959 | TLS_DHE_PSK_WITH_AES_128_CCM | N/A | 960 | TLS_DHE_PSK_WITH_AES_256_CCM | N/A | 961 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | 962 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256| 963 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | 964 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | 965 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | 966 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | 967 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | 968 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A | 969 +----------------------------------------------+----------------------+ 971 Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping 972 to signature-algorithm 974 +----------------------------------------------+-----------------------+ 975 |ciper-suites in hello-params-grouping | key-negotiation | 976 +----------------------------------------------+-----------------------+ 977 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... | 978 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... | 979 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...| 980 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...| 981 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | 982 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | 983 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | 984 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | 985 | TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... | 986 | TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... | 987 | TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...| 988 | TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...| 989 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... | 990 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... | 991 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... | 992 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...| 993 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...| 994 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...| 995 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...| 996 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...| 997 +----------------------------------------------+-----------------------+ 999 Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping 1000 to key-negotiation-algorithm 1002 +------------------------------+---------+ 1003 | ciper-suites in hello | HASH | 1004 | -params-grouping | | 1005 +------------------------------+---------+ 1006 | TLS_AES_128_GCM_SHA256 | sha-256 | 1007 | TLS_AES_256_GCM_SHA384 | sha-384 | 1008 | TLS_CHACHA20_POLY1305_SHA256 | sha-256 | 1009 | TLS_AES_128_CCM_SHA256 | sha-256 | 1010 +------------------------------+---------+ 1012 Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping 1013 to hash-algorithm 1015 +------------------------------+-----------------------+ 1016 | ciper-suites in hello | symmetric | 1017 | -params-grouping | | 1018 +------------------------------+-----------------------+ 1019 | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm | 1020 | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm | 1021 | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 | 1022 | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm | 1023 +------------------------------+-----------------------+ 1025 Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping 1026 to symmetric-key--encryption-algorithm 1028 +------------------------------+-----------------------+ 1029 | ciper-suites in hello | symmetric | 1030 | -params-grouping | | 1031 +------------------------------+-----------------------+ 1032 | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm | 1033 | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm | 1034 | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 | 1035 | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm | 1036 +------------------------------+-----------------------+ 1038 Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping 1039 to MAC-algorithm 1041 +----------------------------+-------------------------+ 1042 |signatureScheme in hello | signature | 1043 | -params-grouping | | 1044 +----------------------------+-------------------------+ 1045 | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 | 1046 | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 | 1047 | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 | 1048 | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 | 1049 | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 | 1050 | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 | 1051 | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 | 1052 | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 | 1053 | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 | 1054 | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 | 1055 | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 | 1056 | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 | 1057 | ed25519 | ed25519 | 1058 | ed448 | ed448 | 1059 +----------------------------+-------------------------+ 1061 Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme 1062 mapping to signature-algorithm 1064 +----------------------------+-------------------------+ 1065 |supported Groups in hello | key-negotiation | 1066 | -params-grouping | | 1067 +----------------------------+-------------------------+ 1068 | dhe-ffdhe2048 | dhe-ffdhe2048 | 1069 | dhe-ffdhe3072 | dhe-ffdhe3072 | 1070 | dhe-ffdhe4096 | dhe-ffdhe4096 | 1071 | dhe-ffdhe6144 | dhe-ffdhe6144 | 1072 | dhe-ffdhe8192 | dhe-ffdhe8192 | 1073 | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 | 1074 | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 | 1075 | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 | 1076 | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 | 1077 | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 | 1078 | ecdhe-secp256r1 | ecdhe-secp256r1 | 1079 | ecdhe-secp384r1 | ecdhe-secp384r1 | 1080 | ecdhe-secp521r1 | ecdhe-secp521r1 | 1081 | ecdhe-x25519 | ecdhe-x25519 | 1082 | ecdhe-x448 | ecdhe-x448 | 1083 | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 | 1084 | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 | 1085 | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 | 1086 | psk-ecdhe-x25519 | psk-ecdhe-x25519 | 1087 | psk-ecdhe-x448 | psk-ecdhe-x448 | 1088 +----------------------------+-------------------------+ 1090 Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups 1091 mapping to key-negotiation-algorithm 1093 Note that in Table 1-5: 1095 o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe- 1096 ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192; 1098 o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048, 1099 psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe- 1100 ffdhe8192; 1102 o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1, 1103 ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448; 1105 o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe- 1106 secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe- 1107 x25519, psk-ecdhe-x448. 1109 Features are defined for algorithms that are OPTIONAL or are not 1110 widely supported by popular implementations. Note that the list of 1111 algorithms is not exhaustive. 1113 5.1. Tree Diagram 1115 The following tree diagram [RFC8340] provides an overview of the data 1116 model for the "ietf-tls-common" module. 1118 module: ietf-tls-common 1120 grouping hello-params-grouping 1121 +-- tls-versions 1122 | +-- tls-version* identityref 1123 +-- cipher-suites 1124 +-- cipher-suite* identityref 1126 5.2. Example Usage 1128 This section shows how it would appear if the transport-params- 1129 grouping were populated with some data. 1131 1134 1135 tlscmn:tls-1.1 1136 tlscmn:tls-1.2 1137 1138 1139 tlscmn:dhe-rsa-with-aes-128-cbc-sha 1140 tlscmn:rsa-with-aes-128-cbc-sha 1141 tlscmn:rsa-with-3des-ede-cbc-sha 1142 1143 1145 5.3. YANG Module 1147 This YANG module has a normative references to [RFC4346], [RFC5246], 1148 [RFC5288], [RFC5289], and [RFC8422]. 1150 This YANG module has a informative references to [RFC2246], 1151 [RFC4346], [RFC5246], and [RFC8446]. 1153 file "ietf-tls-common@2019-07-02.yang" 1154 module ietf-tls-common { 1155 yang-version 1.1; 1156 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; 1157 prefix tlscmn; 1159 organization 1160 "IETF NETCONF (Network Configuration) Working Group"; 1162 contact 1163 "WG Web: 1164 WG List: 1165 Author: Kent Watsen 1166 Author: Gary Wu "; 1168 description 1169 "This module defines a common features, identities, and 1170 groupings for Transport Layer Security (TLS). 1172 Copyright (c) 2019 IETF Trust and the persons identified 1173 as authors of the code. All rights reserved. 1175 Redistribution and use in source and binary forms, with 1176 or without modification, is permitted pursuant to, and 1177 subject to the license terms contained in, the Simplified 1178 BSD License set forth in Section 4.c of the IETF Trust's 1179 Legal Provisions Relating to IETF Documents 1180 (https://trustee.ietf.org/license-info). 1182 This version of this YANG module is part of RFC XXXX 1183 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1184 itself for full legal notices.; 1186 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1187 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1188 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1189 are to be interpreted as described in BCP 14 (RFC 2119) 1190 (RFC 8174) when, and only when, they appear in all 1191 capitals, as shown here."; 1193 revision 2019-07-02 { 1194 description 1195 "Initial version"; 1196 reference 1197 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 1198 } 1200 // Features 1202 feature tls-1_0 { 1203 description 1204 "TLS Protocol Version 1.0 is supported."; 1205 reference 1206 "RFC 2246: The TLS Protocol Version 1.0"; 1207 } 1209 feature tls-1_1 { 1210 description 1211 "TLS Protocol Version 1.1 is supported."; 1212 reference 1213 "RFC 4346: The Transport Layer Security (TLS) Protocol 1214 Version 1.1"; 1215 } 1217 feature tls-1_2 { 1218 description 1219 "TLS Protocol Version 1.2 is supported."; 1220 reference 1221 "RFC 5246: The Transport Layer Security (TLS) Protocol 1222 Version 1.2"; 1223 } 1225 feature tls-1_3 { 1226 description 1227 "TLS Protocol Version 1.2 is supported."; 1228 reference 1229 "RFC 8446: The Transport Layer Security (TLS) Protocol 1230 Version 1.3"; 1231 } 1233 feature tls-ecc { 1234 description 1235 "Elliptic Curve Cryptography (ECC) is supported for TLS."; 1236 reference 1237 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1238 for Transport Layer Security (TLS)"; 1239 } 1241 feature tls-dhe { 1242 description 1243 "Ephemeral Diffie-Hellman key exchange is supported for TLS."; 1244 reference 1245 "RFC 5246: The Transport Layer Security (TLS) Protocol 1246 Version 1.2"; 1247 } 1249 feature tls-3des { 1250 description 1251 "The Triple-DES block cipher is supported for TLS."; 1252 reference 1253 "RFC 5246: The Transport Layer Security (TLS) Protocol 1254 Version 1.2"; 1255 } 1257 feature tls-gcm { 1258 description 1259 "The Galois/Counter Mode authenticated encryption mode is 1260 supported for TLS."; 1261 reference 1262 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for 1263 TLS"; 1264 } 1266 feature tls-sha2 { 1267 description 1268 "The SHA2 family of cryptographic hash functions is supported 1269 for TLS."; 1270 reference 1271 "FIPS PUB 180-4: Secure Hash Standard (SHS)"; 1272 } 1274 // Identities 1276 identity tls-version-base { 1277 description 1278 "Base identity used to identify TLS protocol versions."; 1279 } 1281 identity tls-1.0 { 1282 base tls-version-base; 1283 if-feature "tls-1_0"; 1284 description 1285 "TLS Protocol Version 1.0."; 1286 reference 1287 "RFC 2246: The TLS Protocol Version 1.0"; 1288 } 1290 identity tls-1.1 { 1291 base tls-version-base; 1292 if-feature "tls-1_1"; 1293 description 1294 "TLS Protocol Version 1.1."; 1295 reference 1296 "RFC 4346: The Transport Layer Security (TLS) Protocol 1297 Version 1.1"; 1298 } 1300 identity tls-1.2 { 1301 base tls-version-base; 1302 if-feature "tls-1_2"; 1303 description 1304 "TLS Protocol Version 1.2."; 1305 reference 1306 "RFC 5246: The Transport Layer Security (TLS) Protocol 1307 Version 1.2"; 1308 } 1310 identity cipher-suite-base { 1311 description 1312 "Base identity used to identify TLS cipher suites."; 1313 } 1315 identity rsa-with-aes-128-cbc-sha { 1316 base cipher-suite-base; 1317 description 1318 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA."; 1319 reference 1320 "RFC 5246: The Transport Layer Security (TLS) Protocol 1321 Version 1.2"; 1322 } 1324 identity rsa-with-aes-256-cbc-sha { 1325 base cipher-suite-base; 1326 description 1327 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; 1328 reference 1329 "RFC 5246: The Transport Layer Security (TLS) Protocol 1330 Version 1.2"; 1331 } 1333 identity rsa-with-aes-128-cbc-sha256 { 1334 base cipher-suite-base; 1335 if-feature "tls-sha2"; 1336 description 1337 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; 1338 reference 1339 "RFC 5246: The Transport Layer Security (TLS) Protocol 1340 Version 1.2"; 1341 } 1343 identity rsa-with-aes-256-cbc-sha256 { 1344 base cipher-suite-base; 1345 if-feature "tls-sha2"; 1346 description 1347 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256."; 1348 reference 1349 "RFC 5246: The Transport Layer Security (TLS) Protocol 1350 Version 1.2"; 1351 } 1353 identity dhe-rsa-with-aes-128-cbc-sha { 1354 base cipher-suite-base; 1355 if-feature "tls-dhe"; 1356 description 1357 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA."; 1358 reference 1359 "RFC 5246: The Transport Layer Security (TLS) Protocol 1360 Version 1.2"; 1361 } 1363 identity dhe-rsa-with-aes-256-cbc-sha { 1364 base cipher-suite-base; 1365 if-feature "tls-dhe"; 1366 description 1367 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA."; 1368 reference 1369 "RFC 5246: The Transport Layer Security (TLS) Protocol 1370 Version 1.2"; 1371 } 1373 identity dhe-rsa-with-aes-128-cbc-sha256 { 1374 base cipher-suite-base; 1375 if-feature "tls-dhe and tls-sha2"; 1376 description 1377 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; 1378 reference 1379 "RFC 5246: The Transport Layer Security (TLS) Protocol 1380 Version 1.2"; 1381 } 1383 identity dhe-rsa-with-aes-256-cbc-sha256 { 1384 base cipher-suite-base; 1385 if-feature "tls-dhe and tls-sha2"; 1386 description 1387 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; 1388 reference 1389 "RFC 5246: The Transport Layer Security (TLS) Protocol 1390 Version 1.2"; 1391 } 1393 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 { 1394 base cipher-suite-base; 1395 if-feature "tls-ecc and tls-sha2"; 1396 description 1397 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256."; 1398 reference 1399 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1400 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1401 } 1402 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 { 1403 base cipher-suite-base; 1404 if-feature "tls-ecc and tls-sha2"; 1405 description 1406 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384."; 1407 reference 1408 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1409 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1410 } 1412 identity ecdhe-rsa-with-aes-128-cbc-sha256 { 1413 base cipher-suite-base; 1414 if-feature "tls-ecc and tls-sha2"; 1415 description 1416 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256."; 1417 reference 1418 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1419 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1420 } 1422 identity ecdhe-rsa-with-aes-256-cbc-sha384 { 1423 base cipher-suite-base; 1424 if-feature "tls-ecc and tls-sha2"; 1425 description 1426 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; 1427 reference 1428 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1429 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1430 } 1432 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { 1433 base cipher-suite-base; 1434 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1435 description 1436 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; 1437 reference 1438 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1439 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1440 } 1442 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 { 1443 base cipher-suite-base; 1444 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1445 description 1446 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."; 1447 reference 1448 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1449 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1451 } 1453 identity ecdhe-rsa-with-aes-128-gcm-sha256 { 1454 base cipher-suite-base; 1455 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1456 description 1457 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256."; 1458 reference 1459 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1460 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1461 } 1463 identity ecdhe-rsa-with-aes-256-gcm-sha384 { 1464 base cipher-suite-base; 1465 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1466 description 1467 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384."; 1468 reference 1469 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1470 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1471 } 1473 identity rsa-with-3des-ede-cbc-sha { 1474 base cipher-suite-base; 1475 if-feature "tls-3des"; 1476 description 1477 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; 1478 reference 1479 "RFC 5246: The Transport Layer Security (TLS) Protocol 1480 Version 1.2"; 1481 } 1483 identity ecdhe-rsa-with-3des-ede-cbc-sha { 1484 base cipher-suite-base; 1485 if-feature "tls-ecc and tls-3des"; 1486 description 1487 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; 1488 reference 1489 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1490 for Transport Layer Security (TLS)"; 1491 } 1493 identity ecdhe-rsa-with-aes-128-cbc-sha { 1494 base cipher-suite-base; 1495 if-feature "tls-ecc"; 1496 description 1497 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA."; 1498 reference 1499 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1500 for Transport Layer Security (TLS)"; 1501 } 1503 identity ecdhe-rsa-with-aes-256-cbc-sha { 1504 base cipher-suite-base; 1505 if-feature "tls-ecc"; 1506 description 1507 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA."; 1508 reference 1509 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1510 for Transport Layer Security (TLS)"; 1511 } 1513 // Groupings 1515 grouping hello-params-grouping { 1516 description 1517 "A reusable grouping for TLS hello message parameters."; 1518 reference 1519 "RFC 5246: The Transport Layer Security (TLS) Protocol 1520 Version 1.2"; 1521 container tls-versions { 1522 description 1523 "Parameters regarding TLS versions."; 1524 leaf-list tls-version { 1525 type identityref { 1526 base tls-version-base; 1527 } 1528 description 1529 "Acceptable TLS protocol versions. 1531 If this leaf-list is not configured (has zero elements) 1532 the acceptable TLS protocol versions are implementation- 1533 defined."; 1534 } 1535 } 1536 container cipher-suites { 1537 description 1538 "Parameters regarding cipher suites."; 1539 leaf-list cipher-suite { 1540 type identityref { 1541 base cipher-suite-base; 1542 } 1543 ordered-by user; 1544 description 1545 "Acceptable cipher suites in order of descending 1546 preference. The configured host key algorithms should 1547 be compatible with the algorithm used by the configured 1548 private key. Please see Section 5 of RFC XXXX for 1549 valid combinations. 1551 If this leaf-list is not configured (has zero elements) 1552 the acceptable cipher suites are implementation- 1553 defined."; 1554 reference 1555 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 1556 } 1557 } 1558 } 1559 } 1560 1562 6. Security Considerations 1564 The YANG modules defined in this document are designed to be accessed 1565 via YANG based management protocols, such as NETCONF [RFC6241] and 1566 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1567 implement secure transport layers (e.g., SSH, TLS) with mutual 1568 authentication. 1570 The NETCONF access control model (NACM) [RFC8341] provides the means 1571 to restrict access for particular users to a pre-configured subset of 1572 all available protocol operations and content. 1574 Since the modules in this document only define groupings, these 1575 considerations are primarily for the designers of other modules that 1576 use these groupings. 1578 There are a number of data nodes defined in the YANG modules that are 1579 writable/creatable/deletable (i.e., config true, which is the 1580 default). These data nodes may be considered sensitive or vulnerable 1581 in some network environments. Write operations (e.g., edit-config) 1582 to these data nodes without proper protection can have a negative 1583 effect on network operations. These are the subtrees and data nodes 1584 and their sensitivity/vulnerability: 1586 *: The entire subtree defined by the grouping statement in both 1587 the "ietf-ssh-client" and "ietf-ssh-server" modules is 1588 sensitive to write operations. For instance, the addition or 1589 removal of references to keys, certificates, trusted anchors, 1590 etc., or even the modification of transport or keepalive 1591 parameters can dramatically alter the implemented security 1592 policy. For this reason, this node is protected the NACM 1593 extension "default-deny-write". 1595 Some of the readable data nodes in the YANG modules may be considered 1596 sensitive or vulnerable in some network environments. It is thus 1597 important to control read access (e.g., via get, get-config, or 1598 notification) to these data nodes. These are the subtrees and data 1599 nodes and their sensitivity/vulnerability: 1601 /tls-client-parameters/client-identity/: This subtree in the 1602 "ietf-tls-client" module contains nodes that are additionally 1603 sensitive to read operations such that, in normal use cases, 1604 they should never be returned to a client. Some of these nodes 1605 (i.e., public-key/local-definition/private-key and certificate/ 1606 local-definition/private-key) are already protected by the NACM 1607 extension "default-deny-all" set in the "grouping" statements 1608 defined in [I-D.ietf-netconf-crypto-types]. 1610 /tls-server-parameters/server-identity/: This subtree in the 1611 "ietf-tls-server" module contains nodes that are additionally 1612 sensitive to read operations such that, in normal use cases, 1613 they should never be returned to a client. All of these nodes 1614 (i.e., host-key/public-key/local-definition/private-key and 1615 host-key/certificate/local-definition/private-key) are already 1616 protected by the NACM extension "default-deny-all" set in the 1617 "grouping" statements defined in 1618 [I-D.ietf-netconf-crypto-types]. 1620 Some of the operations in this YANG module may be considered 1621 sensitive or vulnerable in some network environments. It is thus 1622 important to control access to these operations. These are the 1623 operations and their sensitivity/vulnerability: 1625 *: The groupings defined in this document include "action" 1626 statements that come from groupings defined in 1627 [I-D.ietf-netconf-crypto-types]. Please consult that document 1628 for the security considerations of the "action" statements 1629 defined by the "grouping" statements defined in this document. 1631 7. IANA Considerations 1633 7.1. The IETF XML Registry 1635 This document registers three URIs in the "ns" subregistry of the 1636 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the 1637 following registrations are requested: 1639 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 1640 Registrant Contact: The NETCONF WG of the IETF. 1641 XML: N/A, the requested URI is an XML namespace. 1643 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 1644 Registrant Contact: The NETCONF WG of the IETF. 1645 XML: N/A, the requested URI is an XML namespace. 1647 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common 1648 Registrant Contact: The NETCONF WG of the IETF. 1649 XML: N/A, the requested URI is an XML namespace. 1651 7.2. The YANG Module Names Registry 1653 This document registers three YANG modules in the YANG Module Names 1654 registry [RFC6020]. Following the format in [RFC6020], the following 1655 registrations are requested: 1657 name: ietf-tls-client 1658 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 1659 prefix: tlsc 1660 reference: RFC XXXX 1662 name: ietf-tls-server 1663 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 1664 prefix: tlss 1665 reference: RFC XXXX 1667 name: ietf-tls-common 1668 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common 1669 prefix: tlscmn 1670 reference: RFC XXXX 1672 8. References 1674 8.1. Normative References 1676 [I-D.ietf-netconf-crypto-types] 1677 Watsen, K. and H. Wang, "Common YANG Data Types for 1678 Cryptography", draft-ietf-netconf-crypto-types-09 (work in 1679 progress), June 2019. 1681 [I-D.ietf-netconf-keystore] 1682 Watsen, K., "A YANG Data Model for a Keystore", draft- 1683 ietf-netconf-keystore-11 (work in progress), June 2019. 1685 [I-D.ietf-netconf-trust-anchors] 1686 Watsen, K., "A YANG Data Model for a Truststore", draft- 1687 ietf-netconf-trust-anchors-05 (work in progress), June 1688 2019. 1690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1691 Requirement Levels", BCP 14, RFC 2119, 1692 DOI 10.17487/RFC2119, March 1997, 1693 . 1695 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1696 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1697 DOI 10.17487/RFC5288, August 2008, 1698 . 1700 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 1701 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 1702 DOI 10.17487/RFC5289, August 2008, 1703 . 1705 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1706 the Network Configuration Protocol (NETCONF)", RFC 6020, 1707 DOI 10.17487/RFC6020, October 2010, 1708 . 1710 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1711 NETCONF Protocol over Transport Layer Security (TLS) with 1712 Mutual X.509 Authentication", RFC 7589, 1713 DOI 10.17487/RFC7589, June 2015, 1714 . 1716 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1717 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1718 . 1720 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1721 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1722 May 2017, . 1724 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1725 Access Control Model", STD 91, RFC 8341, 1726 DOI 10.17487/RFC8341, March 2018, 1727 . 1729 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1730 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1731 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1732 DOI 10.17487/RFC8422, August 2018, 1733 . 1735 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1736 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1737 . 1739 8.2. Informative References 1741 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1742 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1743 . 1745 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1746 DOI 10.17487/RFC2818, May 2000, 1747 . 1749 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1750 DOI 10.17487/RFC3688, January 2004, 1751 . 1753 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1754 (TLS) Protocol Version 1.1", RFC 4346, 1755 DOI 10.17487/RFC4346, April 2006, 1756 . 1758 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1759 (TLS) Protocol Version 1.2", RFC 5246, 1760 DOI 10.17487/RFC5246, August 2008, 1761 . 1763 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1764 and A. Bierman, Ed., "Network Configuration Protocol 1765 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1766 . 1768 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1769 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1770 . 1772 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1773 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1774 . 1776 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1777 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1778 . 1780 Appendix A. Change Log 1782 A.1. 00 to 01 1784 o Noted that '0.0.0.0' and '::' might have special meanings. 1786 o Renamed "keychain" to "keystore". 1788 A.2. 01 to 02 1790 o Removed the groupings containing transport-level configuration. 1791 Now modules contain only the transport-independent groupings. 1793 o Filled in previously incomplete 'ietf-tls-client' module. 1795 o Added cipher suites for various algorithms into new 'ietf-tls- 1796 common' module. 1798 A.3. 02 to 03 1800 o Added a 'must' statement to container 'server-auth' asserting that 1801 at least one of the various auth mechanisms must be specified. 1803 o Fixed description statement for leaf 'trusted-ca-certs'. 1805 A.4. 03 to 04 1807 o Updated title to "YANG Groupings for TLS Clients and TLS Servers" 1809 o Updated leafref paths to point to new keystore path 1811 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to 1812 'tlscmn'. 1814 o Added TLS protocol verions 1.0 and 1.1. 1816 o Made author lists consistent 1818 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1820 o Updated YANG to use typedefs around leafrefs to common keystore 1821 paths 1823 o Now inlines key and certificates (no longer a leafref to keystore) 1825 A.5. 04 to 05 1827 o Merged changes from co-author. 1829 A.6. 05 to 06 1831 o Updated to use trust anchors from trust-anchors draft (was 1832 keystore draft) 1834 o Now Uses new keystore grouping enabling asymmetric key to be 1835 either locally defined or a reference to the keystore. 1837 A.7. 06 to 07 1839 o factored the tls-[client|server]-groupings into more reusable 1840 groupings. 1842 o added if-feature statements for the new "x509-certificates" 1843 feature defined in draft-ietf-netconf-trust-anchors. 1845 A.8. 07 to 08 1847 o Added a number of compatibility matrices to Section 5 (thanks 1848 Frank!) 1850 o Clarified that any configured "cipher-suite" values need to be 1851 compatible with the configured private key. 1853 A.9. 08 to 09 1855 o Updated examples to reflect update to groupings defined in the 1856 keystore draft. 1858 o Add TLS keepalives features and groupings. 1860 o Prefixed top-level TLS grouping nodes with 'tls-' and support 1861 mashups. 1863 o Updated copyright date, boilerplate template, affiliation, and 1864 folding algorithm. 1866 A.10. 09 to 10 1868 o Reformatted the YANG modules. 1870 A.11. 10 to 11 1872 o Collapsed all the inner groupings into the top-level grouping. 1874 o Added a top-level "demux container" inside the top-level grouping. 1876 o Added NACM statements and updated the Security Considerations 1877 section. 1879 o Added "presence" statements on the "keepalive" containers, as was 1880 needed to address a validation error that appeared after adding 1881 the "must" statements into the NETCONF/RESTCONF client/server 1882 modules. 1884 o Updated the boilerplate text in module-level "description" 1885 statement to match copyeditor convention. 1887 A.12. 11 to 12 1889 o In server model, made 'client-authentication' a 'presence' node 1890 indicating that the server supports client authentication. 1892 o In the server model, added a 'required-or-optional' choice to 1893 'client-authentication' to better support protocols such as 1894 RESTCONF. 1896 o In the server model, added a 'local-or-external' choice to 1897 'client-authentication' to better support consuming data models 1898 that prefer to keep client auth with client definitions than in a 1899 model principally concerned with the "transport". 1901 o In both models, removed the "demux containers", floating the 1902 nacm:default-deny-write to each descendent node, and adding a note 1903 to model designers regarding the potential need to add their own 1904 demux containers. 1906 o Fixed a couple references (section 2 --> section 3) 1908 A.13. 12 to 13 1910 o Updated to reflect changes in trust-anchors drafts (e.g., s/trust- 1911 anchors/truststore/g + s/pinned.//) 1913 A.14. 12 to 13 1915 o Removed 'container' under 'client-identity' to match server model. 1917 o Updated examples to reflect change grouping in keystore module. 1919 A.15. 13 to 14 1921 o Removed the "certificate" container from "client-identity" in the 1922 ietf-tls-client module. 1924 o Updated examples to reflect ietf-crypto-types change (e.g., 1925 identities --> enumerations) 1927 Acknowledgements 1929 The authors would like to thank for following for lively discussions 1930 on list and in the halls (ordered by last name): Andy Bierman, Martin 1931 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 1932 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, 1933 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. 1935 Authors' Addresses 1937 Kent Watsen 1938 Watsen Networks 1940 EMail: kent+ietf@watsen.net 1942 Gary Wu 1943 Cisco Systems 1945 EMail: garywu@cisco.com 1947 Liang Xia 1948 Huawei 1950 EMail: frank.xialiang@huawei.com