idnits 2.17.1 draft-ietf-netconf-tls-client-server-12.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 (April 29, 2019) is 1795 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-05 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-08 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-03 -- 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: October 31, 2019 Cisco Systems 6 L. Xia 7 Huawei 8 April 29, 2019 10 YANG Groupings for TLS Clients and TLS Servers 11 draft-ietf-netconf-tls-client-server-12 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-04-29" --> 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 October 31, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 13 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 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 127 1. Introduction 129 This document defines three YANG 1.1 [RFC7950] modules: the first 130 defines a grouping for a generic TLS client, the second defines a 131 grouping for a generic TLS server, and the third defines identities 132 and groupings common to both the client and the server (TLS is 133 defined in [RFC5246]). It is intended that these groupings will be 134 used by applications using the TLS protocol. For instance, these 135 groupings could be used to help define the data model for an HTTPS 136 [RFC2818] server or a NETCONF over TLS [RFC7589] based server. 138 The client and server YANG modules in this document each define one 139 grouping, which is focused on just TLS-specific configuration, and 140 specifically avoids any transport-level configuration, such as what 141 ports to listen-on or connect-to. This affords applications the 142 opportunity to define their own strategy for how the underlying TCP 143 connection is established. For instance, applications supporting 144 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping" 145 grouping for the TLS parts it provides, while adding data nodes for 146 the TCP-level call-home configuration. 148 The modules defined in this document use groupings defined in 149 [I-D.ietf-netconf-keystore] enabling keys to be either locally 150 defined or a reference to globally configured values. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. The TLS Client Model 162 3.1. Tree Diagram 164 This section provides a tree diagram [RFC8340] for the "ietf-tls- 165 client" module that does not have groupings expanded. 167 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 169 module: ietf-tls-client 171 grouping tls-client-grouping 172 +-- client-identity 173 | +-- (auth-type)? 174 | +--:(certificate) 175 | +-- certificate 176 | +---u ks:local-or-keystore-end-entity-cert-with-key-\ 177 grouping 178 +-- server-authentication 179 | +-- pinned-ca-certs? ta:pinned-certificates-ref 180 | | {ta:x509-certificates}? 181 | +-- pinned-server-certs? ta:pinned-certificates-ref 182 | {ta:x509-certificates}? 183 +-- hello-params {tls-client-hello-params-config}? 184 | +---u tlscmn:hello-params-grouping 185 +-- keepalives! {tls-client-keepalives}? 186 +-- max-wait? uint16 187 +-- max-attempts? uint8 189 3.2. Example Usage 191 This section presents two examples showing the tls-client-grouping 192 populated with some data. These examples are effectively the same 193 except the first configures the client identity using a local key 194 while the second uses a key configured in a keystore. Both examples 195 are consistent with the examples presented in Section 2 of 196 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 197 [I-D.ietf-netconf-keystore]. 199 The following example configures the client identity using a local 200 key: 202 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 204 206 207 208 209 210 ct:rsa2048 212 base64encodedvalue== 213 base64encodedvalue== 214 base64encodedvalue== 215 216 217 219 220 221 explicitly-trusted-server-ca-certs 223 explicitly-trusted-server-certs 225 227 228 30 229 3 230 232 234 The following example configures the client identity using a key from 235 the keystore: 237 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 239 241 242 243 244 ex-rsa-cert 245 246 248 249 250 explicitly-trusted-server-ca-certs 252 explicitly-trusted-server-certs 254 256 257 30 258 3 259 261 263 3.3. YANG Module 265 This YANG module has normative references to 266 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. 268 file "ietf-tls-client@2019-04-29.yang" 269 module ietf-tls-client { 270 yang-version 1.1; 271 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 272 prefix tlsc; 274 import ietf-tls-common { 275 prefix tlscmn; 276 revision-date 2019-04-29; // stable grouping definitions 277 reference 278 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 279 } 281 import ietf-trust-anchors { 282 prefix ta; 283 reference 284 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 286 } 288 import ietf-keystore { 289 prefix ks; 290 reference 291 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; 292 } 294 import ietf-netconf-acm { 295 prefix nacm; 296 reference 297 "RFC 8341: Network Configuration Access Control Model"; 298 } 300 organization 301 "IETF NETCONF (Network Configuration) Working Group"; 303 contact 304 "WG Web: 305 WG List: 306 Author: Kent Watsen 307 Author: Gary Wu "; 309 description 310 "This module defines reusable groupings for TLS clients that 311 can be used as a basis for specific TLS client instances. 313 Copyright (c) 2019 IETF Trust and the persons identified 314 as authors of the code. All rights reserved. 316 Redistribution and use in source and binary forms, with 317 or without modification, is permitted pursuant to, and 318 subject to the license terms contained in, the Simplified 319 BSD License set forth in Section 4.c of the IETF Trust's 320 Legal Provisions Relating to IETF Documents 321 (https://trustee.ietf.org/license-info). 323 This version of this YANG module is part of RFC XXXX 324 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 325 itself for full legal notices.; 327 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 328 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 329 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 330 are to be interpreted as described in BCP 14 (RFC 2119) 331 (RFC 8174) when, and only when, they appear in all 332 capitals, as shown here."; 334 revision 2019-04-29 { 335 description 336 "Initial version"; 337 reference 338 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 339 } 341 // Features 343 feature tls-client-hello-params-config { 344 description 345 "TLS hello message parameters are configurable on a TLS 346 client."; 347 } 349 feature tls-client-keepalives { 350 description 351 "Per socket TLS keepalive parameters are configurable for 352 TLS clients on the server implementing this feature."; 353 } 355 // Groupings 357 grouping tls-client-grouping { 358 description 359 "A reusable grouping for configuring a TLS client without 360 any consideration for how an underlying TCP session is 361 established. 363 Note that this grouping uses fairly typical descendent 364 node names such that a stack of 'uses' statements will 365 have name conflicts. It is intended that the consuming 366 data model will resolve the issue (e.g., by wrapping 367 the 'uses' statement in a container called 368 'tls-client-parameters'). This model purposely does 369 not do this itself so as to provide maximum flexibility 370 to consuming models."; 372 container client-identity { 373 nacm:default-deny-write; 374 description 375 "The credentials used by the client to authenticate to 376 the TLS server."; 377 choice auth-type { 378 description 379 "The authentication type."; 380 container certificate { 381 uses 382 ks:local-or-keystore-end-entity-cert-with-key-grouping; 383 description 384 "A locally-defined or referenced certificate 385 to be used for client authentication."; 386 reference 387 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; 388 } 389 } 390 } // container client-identity 392 container server-authentication { 393 nacm:default-deny-write; 394 must 'pinned-ca-certs or pinned-server-certs'; 395 description 396 "Trusted server identities."; 397 leaf pinned-ca-certs { 398 if-feature "ta:x509-certificates"; 399 type ta:pinned-certificates-ref; 400 description 401 "A reference to a list of certificate authority (CA) 402 certificates used by the TLS client to authenticate 403 TLS server certificates. A server certificate is 404 authenticated if it has a valid chain of trust to 405 a configured pinned CA certificate."; 406 } 407 leaf pinned-server-certs { 408 if-feature "ta:x509-certificates"; 409 type ta:pinned-certificates-ref; 410 description 411 "A reference to a list of server certificates used by 412 the TLS client to authenticate TLS server certificates. 413 A server certificate is authenticated if it is an 414 exact match to a configured pinned server certificate."; 415 } 416 } // container server-authentication 418 container hello-params { 419 nacm:default-deny-write; 420 if-feature "tls-client-hello-params-config"; 421 uses tlscmn:hello-params-grouping; 422 description 423 "Configurable parameters for the TLS hello message."; 424 } // container hello-params 426 container keepalives { 427 nacm:default-deny-write; 428 if-feature "tls-client-keepalives"; 429 presence "Indicates that keepalives are enabled."; 430 description 431 "Configures the keep-alive policy, to proactively test 432 the aliveness of the TLS server. An unresponsive 433 TLS server is dropped after approximately max-wait 434 * max-attempts seconds."; 435 leaf max-wait { 436 type uint16 { 437 range "1..max"; 438 } 439 units "seconds"; 440 default "30"; 441 description 442 "Sets the amount of time in seconds after which if 443 no data has been received from the TLS server, a 444 TLS-level message will be sent to test the 445 aliveness of the TLS server."; 446 } 447 leaf max-attempts { 448 type uint8; 449 default "3"; 450 description 451 "Sets the maximum number of sequential keep-alive 452 messages that can fail to obtain a response from 453 the TLS server before assuming the TLS server is 454 no longer alive."; 455 } 456 } // container keepalives 457 } // grouping tls-client-grouping 458 } 459 461 4. The TLS Server Model 463 4.1. Tree Diagram 465 This section provides a tree diagram [RFC8340] for the "ietf-tls- 466 server" module that does not have groupings expanded. 468 module: ietf-tls-server 470 grouping tls-server-grouping 471 +-- server-identity 472 | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping 473 +-- client-authentication! 474 | +-- (required-or-optional) 475 | | +--:(required) 476 | | | +-- required? empty 477 | | +--:(optional) 478 | | +-- optional? empty 479 | +-- (local-or-external) 480 | +--:(local) {local-client-auth-supported}? 481 | | +-- pinned-ca-certs? 482 | | | ta:pinned-certificates-ref 483 | | | {ta:x509-certificates}? 484 | | +-- pinned-client-certs? 485 | | ta:pinned-certificates-ref 486 | | {ta:x509-certificates}? 487 | +--:(external) {external-client-auth-supported}? 488 | +-- client-auth-defined-elsewhere? empty 489 +-- hello-params {tls-server-hello-params-config}? 490 | +---u tlscmn:hello-params-grouping 491 +-- keepalives! {tls-server-keepalives}? 492 +-- max-wait? uint16 493 +-- max-attempts? uint8 495 4.2. Example Usage 497 This section presents two examples showing the tls-server-grouping 498 populated with some data. These examples are effectively the same 499 except the first configures the server identity using a local key 500 while the second uses a key configured in a keystore. Both examples 501 are consistent with the examples presented in Section 2 of 502 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 503 [I-D.ietf-netconf-keystore]. 505 The following example configures the server identity using a local 506 key: 508 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 510 512 513 514 515 ct:rsa2048 517 base64encodedvalue== 518 base64encodedvalue== 519 base64encodedvalue== 520 521 523 524 525 526 explicitly-trusted-client-ca-certs 528 explicitly-trusted-client-certs 530 532 534 The following example configures the server identity using a key from 535 the keystore: 537 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 539 541 542 543 ex-rsa-cert 544 546 547 548 549 explicitly-trusted-client-ca-certs 551 explicitly-trusted-client-certs 553 555 557 4.3. YANG Module 559 This YANG module has a normative references to [RFC5246], 560 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. 562 file "ietf-tls-server@2019-04-29.yang" 563 module ietf-tls-server { 564 yang-version 1.1; 565 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 566 prefix tlss; 568 import ietf-tls-common { 569 prefix tlscmn; 570 revision-date 2019-04-29; // stable grouping definitions 571 reference 572 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 573 } 575 import ietf-trust-anchors { 576 prefix ta; 577 reference 578 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 579 } 581 import ietf-keystore { 582 prefix ks; 583 reference 584 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; 585 } 587 import ietf-netconf-acm { 588 prefix nacm; 589 reference 590 "RFC 8341: Network Configuration Access Control Model"; 591 } 593 organization 594 "IETF NETCONF (Network Configuration) Working Group"; 596 contact 597 "WG Web: 598 WG List: 599 Author: Kent Watsen 600 Author: Gary Wu "; 602 description 603 "This module defines reusable groupings for TLS servers that 604 can be used as a basis for specific TLS server instances. 606 Copyright (c) 2019 IETF Trust and the persons identified 607 as authors of the code. All rights reserved. 609 Redistribution and use in source and binary forms, with 610 or without modification, is permitted pursuant to, and 611 subject to the license terms contained in, the Simplified 612 BSD License set forth in Section 4.c of the IETF Trust's 613 Legal Provisions Relating to IETF Documents 614 (https://trustee.ietf.org/license-info). 616 This version of this YANG module is part of RFC XXXX 617 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 618 itself for full legal notices.; 620 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 621 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 622 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 623 are to be interpreted as described in BCP 14 (RFC 2119) 624 (RFC 8174) when, and only when, they appear in all 625 capitals, as shown here."; 627 revision 2019-04-29 { 628 description 629 "Initial version"; 630 reference 631 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 632 } 634 // Features 636 feature tls-server-hello-params-config { 637 description 638 "TLS hello message parameters are configurable on a TLS 639 server."; 640 } 642 feature tls-server-keepalives { 643 description 644 "Per socket TLS keepalive parameters are configurable for 645 TLS servers on the server implementing this feature."; 646 } 648 feature local-client-auth-supported { 649 description 650 "Indicates that the TLS server supports local 651 configuration of client credentials."; 652 } 653 feature external-client-auth-supported { 654 description 655 "Indicates that the TLS server supports external 656 configuration of client credentials."; 657 } 659 // Groupings 661 grouping tls-server-grouping { 662 description 663 "A reusable grouping for configuring a TLS server without 664 any consideration for how underlying TCP sessions are 665 established. 667 Note that this grouping uses fairly typical descendent 668 node names such that a stack of 'uses' statements will 669 have name conflicts. It is intended that the consuming 670 data model will resolve the issue (e.g., by wrapping 671 the 'uses' statement in a container called 672 'tls-server-parameters'). This model purposely does 673 not do this itself so as to provide maximum flexibility 674 to consuming models."; 676 container server-identity { // FIXME: what about PSKs? 677 nacm:default-deny-write; 678 description 679 "A locally-defined or referenced end-entity certificate, 680 including any configured intermediate certificates, the 681 TLS server will present when establishing a TLS connection 682 in its Certificate message, as defined in Section 7.4.2 683 in RFC 5246."; 684 reference 685 "RFC 5246: 686 The Transport Layer Security (TLS) Protocol Version 1.2 687 RFC ZZZZ: 688 YANG Data Model for a 'Keystore' Mechanism"; 689 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 690 } // container server-identity 692 container client-authentication { // FIXME: what about PSKs? 693 nacm:default-deny-write; 694 presence 695 "Indicates that certificate based client authentication 696 is supported (i.e., the server will request that the 697 client send a certificate)."; 699 description 700 "Specifies if TLS client authentication is required or 701 optional, and specifies if the certificates needed to 702 authenticate the TLS client are configured locally or 703 externally. If configured locally, the data model 704 enables both trust anchors and end-entity certificate 705 to be set."; 706 choice required-or-optional { 707 mandatory true; // or default to 'required' ? 708 description 709 "Indicates if TLS-level client authentication is required 710 or optional. This is necessary for some protocols (e.g., 711 RESTCONF) the may optionally authenticate a client via 712 TLS-level authentication, HTTP-level authentication, or 713 both simultaneously)."; 714 leaf required { 715 type empty; 716 description 717 "Indicates that TLS-level client authentication is 718 required."; 719 } 720 leaf optional { 721 type empty; 722 description 723 "Indicates that TLS-level client authentication is 724 optional."; 725 } 726 } 727 choice local-or-external { 728 mandatory true; 729 description 730 "Indicates if the certificates needed to authenticate 731 the client are configured locally or externally. The 732 need to support external configuration for client 733 authentication stems from the desire to support 734 consuming data models that prefer to place client 735 authentication with client definitions, rather then 736 in a data model principally concerned with configuring 737 the transport."; 738 case local { 739 if-feature "local-client-auth-supported"; 740 description 741 "The certificates needed to authenticate the clients 742 are configured locally."; 743 leaf pinned-ca-certs { 744 if-feature "ta:x509-certificates"; 745 type ta:pinned-certificates-ref;//FIXME: local-or-remote? 746 description 747 "A reference to a list of certificate authority (CA) 748 certificates used by the TLS server to authenticate 749 TLS client certificates. A client certificate is 750 authenticated if it has a valid chain of trust to 751 a configured pinned CA certificate."; 752 reference 753 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 754 } 755 leaf pinned-client-certs { 756 if-feature "ta:x509-certificates"; 757 type ta:pinned-certificates-ref;//FIXME: local-or-remote? 758 description 759 "A reference to a list of client certificates 760 used by the TLS server to authenticate TLS 761 client certificates. A clients certificate 762 is authenticated if it is an exact match to 763 a configured pinned client certificate."; 764 reference 765 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 766 } 767 } 768 case external { 769 if-feature "external-client-auth-supported"; 770 description 771 "The certificates needed to authenticate the clients 772 are configured externally."; 773 leaf client-auth-defined-elsewhere { 774 type empty; 775 description 776 "Indicates that certificates needed to authenticate 777 clients are configured elsewhere."; 778 } 779 } 780 } // choice local-or-external 781 } // container client-authentication 783 container hello-params { 784 nacm:default-deny-write; 785 if-feature "tls-server-hello-params-config"; 786 uses tlscmn:hello-params-grouping; 787 description 788 "Configurable parameters for the TLS hello message."; 789 } // container hello-params 791 container keepalives { 792 nacm:default-deny-write; 793 if-feature "tls-server-keepalives"; 794 presence "Indicates that keepalives are enabled."; 795 description 796 "Configures the keep-alive policy, to proactively test 797 the aliveness of the TLS client. An unresponsive 798 TLS client is dropped after approximately max-wait 799 * max-attempts seconds."; 800 leaf max-wait { 801 type uint16 { 802 range "1..max"; 803 } 804 units "seconds"; 805 default "30"; 806 description 807 "Sets the amount of time in seconds after which if 808 no data has been received from the TLS client, a 809 TLS-level message will be sent to test the 810 aliveness of the TLS client."; 811 } 812 leaf max-attempts { 813 type uint8; 814 default "3"; 815 description 816 "Sets the maximum number of sequential keep-alive 817 messages that can fail to obtain a response from 818 the TLS client before assuming the TLS client is 819 no longer alive."; 820 } 821 } // container keepalives 822 } // grouping tls-server-grouping 823 } 824 826 5. The TLS Common Model 828 The TLS common model presented in this section contains identities 829 and groupings common to both TLS clients and TLS servers. The hello- 830 params-grouping can be used to configure the list of TLS algorithms 831 permitted by the TLS client or TLS server. The lists of algorithms 832 are ordered such that, if multiple algorithms are permitted by the 833 client, the algorithm that appears first in its list that is also 834 permitted by the server is used for the TLS transport layer 835 connection. The ability to restrict the algorithms allowed is 836 provided in this grouping for TLS clients and TLS servers that are 837 capable of doing so and may serve to make TLS clients and TLS servers 838 compliant with local security policies. This model supports both 839 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446]. 841 TLS 1.2 and TLS 1.3 have different ways defining their own supported 842 cryptographic algorithms, see TLS and DTLS IANA registries page 843 (https://www.iana.org/assignments/tls-parameters/tls- 844 parameters.xhtml): 846 o TLS 1.2 defines four categories of registries for cryptographic 847 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS 848 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the 849 role of combining all of them into one set, as each value of the 850 set represents a unique and feasible combination of all the 851 cryptographic algorithms, and thus the other three registry 852 categories do not need to be considered here. In this document, 853 the TLS common model only chooses those TLS1.2 algorithms in TLS 854 Cipher Suites which are marked as recommended: 855 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 856 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, 857 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, 858 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen 859 algorithms are enumerated in Table 1-1 below; 861 o TLS 1.3 defines its supported algorithms differently. Firstly, it 862 defines three categories of registries for cryptographic 863 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported 864 Groups. Secondly, all three of these categories are useful, since 865 they represent different parts of all the supported algorithms 866 respectively. Thus, all of these registries categories are 867 considered here. In this draft, the TLS common model chooses only 868 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of 869 [RFC8446]. 871 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites 872 part of the hello-params-grouping should include three parameters for 873 configuring its permitted TLS algorithms, which are: TLS Cipher 874 Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2 875 only uses TLS Cipher Suites. 877 [I-D.ietf-netconf-crypto-types] defines six categories of 878 cryptographic algorithms (hash-algorithm, symmetric-key-encryption- 879 algorithm, mac-algorithm, asymmetric-key-encryption-algorithm, 880 signature-algorithm, key-negotiation-algorithm) and lists several 881 widely accepted algorithms for each of them. The TLS client and 882 server models use one or more of these algorithms. The following 883 tables are provided, in part to define the subset of algorithms 884 defined in the crypto-types model used by TLS, and in part to ensure 885 compatibility of configured TLS cryptographic parameters for 886 configuring its permitted TLS algorithms: 888 +-----------------------------------------------+---------+ 889 | ciper-suites in hello-params-grouping | HASH | 890 +-----------------------------------------------+---------+ 891 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | 892 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | 893 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | 894 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | 895 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 | 896 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 | 897 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | 898 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | 899 | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 | 900 | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 | 901 | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 | 902 | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 | 903 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 904 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 905 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 906 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 907 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 908 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | 909 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | 910 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 | 911 +-----------------------------------------------+---------+ 913 Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping 914 to hash-algorithm 916 +--------------------------------------------- +---------------------+ 917 | ciper-suites in hello-params-grouping | symmetric | 918 | | | 919 +--------------------------------------------- +---------------------+ 920 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 921 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 922 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 923 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 924 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 925 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 926 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 927 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 928 | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm | 929 | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm | 930 | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm | 931 | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm | 932 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 933 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305| 934 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 935 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 936 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 937 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 938 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 939 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm | 940 +--------------------------------------------- +---------------------+ 942 Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping 943 to symmetric-key-encryption-algorithm 945 +--------------------------------------------- +---------------------+ 946 | ciper-suites in hello-params-grouping | MAC | 947 | | | 948 +--------------------------------------------- +---------------------+ 949 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 950 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 951 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 952 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 953 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 954 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 955 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 956 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 957 | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm | 958 | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm | 959 | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm | 960 | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm | 961 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 962 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305| 963 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 964 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 965 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 966 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 967 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 968 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm | 969 +--------------------------------------------- +---------------------+ 971 Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping 972 to MAC-algorithm 974 +----------------------------------------------+----------------------+ 975 |ciper-suites in hello-params-grouping | signature | 976 +--------------------------------------------- +----------------------+ 977 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | 978 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | 979 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | 980 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | 981 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256| 982 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384| 983 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | 984 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | 985 | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 | 986 | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 | 987 | TLS_DHE_PSK_WITH_AES_128_CCM | N/A | 988 | TLS_DHE_PSK_WITH_AES_256_CCM | N/A | 989 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | 990 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256| 991 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | 992 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | 993 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | 994 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | 995 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | 996 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A | 997 +----------------------------------------------+----------------------+ 999 Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping 1000 to signature-algorithm 1002 +----------------------------------------------+-----------------------+ 1003 |ciper-suites in hello-params-grouping | key-negotiation | 1004 +----------------------------------------------+-----------------------+ 1005 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... | 1006 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... | 1007 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...| 1008 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...| 1009 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | 1010 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | 1011 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | 1012 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | 1013 | TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... | 1014 | TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... | 1015 | TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...| 1016 | TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...| 1017 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... | 1018 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... | 1019 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... | 1020 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...| 1021 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...| 1022 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...| 1023 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...| 1024 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...| 1025 +----------------------------------------------+-----------------------+ 1027 Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping 1028 to key-negotiation-algorithm 1030 +------------------------------+---------+ 1031 | ciper-suites in hello | HASH | 1032 | -params-grouping | | 1033 +------------------------------+---------+ 1034 | TLS_AES_128_GCM_SHA256 | sha-256 | 1035 | TLS_AES_256_GCM_SHA384 | sha-384 | 1036 | TLS_CHACHA20_POLY1305_SHA256 | sha-256 | 1037 | TLS_AES_128_CCM_SHA256 | sha-256 | 1038 +------------------------------+---------+ 1040 Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping 1041 to hash-algorithm 1043 +------------------------------+-----------------------+ 1044 | ciper-suites in hello | symmetric | 1045 | -params-grouping | | 1046 +------------------------------+-----------------------+ 1047 | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm | 1048 | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm | 1049 | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 | 1050 | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm | 1051 +------------------------------+-----------------------+ 1053 Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping 1054 to symmetric-key--encryption-algorithm 1056 +------------------------------+-----------------------+ 1057 | ciper-suites in hello | symmetric | 1058 | -params-grouping | | 1059 +------------------------------+-----------------------+ 1060 | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm | 1061 | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm | 1062 | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 | 1063 | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm | 1064 +------------------------------+-----------------------+ 1066 Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping 1067 to MAC-algorithm 1069 +----------------------------+-------------------------+ 1070 |signatureScheme in hello | signature | 1071 | -params-grouping | | 1072 +----------------------------+-------------------------+ 1073 | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 | 1074 | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 | 1075 | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 | 1076 | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 | 1077 | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 | 1078 | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 | 1079 | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 | 1080 | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 | 1081 | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 | 1082 | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 | 1083 | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 | 1084 | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 | 1085 | ed25519 | ed25519 | 1086 | ed448 | ed448 | 1087 +----------------------------+-------------------------+ 1089 Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme 1090 mapping to signature-algorithm 1092 +----------------------------+-------------------------+ 1093 |supported Groups in hello | key-negotiation | 1094 | -params-grouping | | 1095 +----------------------------+-------------------------+ 1096 | dhe-ffdhe2048 | dhe-ffdhe2048 | 1097 | dhe-ffdhe3072 | dhe-ffdhe3072 | 1098 | dhe-ffdhe4096 | dhe-ffdhe4096 | 1099 | dhe-ffdhe6144 | dhe-ffdhe6144 | 1100 | dhe-ffdhe8192 | dhe-ffdhe8192 | 1101 | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 | 1102 | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 | 1103 | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 | 1104 | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 | 1105 | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 | 1106 | ecdhe-secp256r1 | ecdhe-secp256r1 | 1107 | ecdhe-secp384r1 | ecdhe-secp384r1 | 1108 | ecdhe-secp521r1 | ecdhe-secp521r1 | 1109 | ecdhe-x25519 | ecdhe-x25519 | 1110 | ecdhe-x448 | ecdhe-x448 | 1111 | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 | 1112 | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 | 1113 | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 | 1114 | psk-ecdhe-x25519 | psk-ecdhe-x25519 | 1115 | psk-ecdhe-x448 | psk-ecdhe-x448 | 1116 +----------------------------+-------------------------+ 1118 Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups 1119 mapping to key-negotiation-algorithm 1121 Note that in Table 1-5: 1123 o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe- 1124 ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192; 1126 o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048, 1127 psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe- 1128 ffdhe8192; 1130 o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1, 1131 ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448; 1133 o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe- 1134 secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe- 1135 x25519, psk-ecdhe-x448. 1137 Features are defined for algorithms that are OPTIONAL or are not 1138 widely supported by popular implementations. Note that the list of 1139 algorithms is not exhaustive. 1141 5.1. Tree Diagram 1143 The following tree diagram [RFC8340] provides an overview of the data 1144 model for the "ietf-tls-common" module. 1146 module: ietf-tls-common 1148 grouping hello-params-grouping 1149 +-- tls-versions 1150 | +-- tls-version* identityref 1151 +-- cipher-suites 1152 +-- cipher-suite* identityref 1154 5.2. Example Usage 1156 This section shows how it would appear if the transport-params- 1157 grouping were populated with some data. 1159 1162 1163 tlscmn:tls-1.1 1164 tlscmn:tls-1.2 1165 1166 1167 tlscmn:dhe-rsa-with-aes-128-cbc-sha 1168 tlscmn:rsa-with-aes-128-cbc-sha 1169 tlscmn:rsa-with-3des-ede-cbc-sha 1170 1171 1173 5.3. YANG Module 1175 This YANG module has a normative references to [RFC4346], [RFC5246], 1176 [RFC5288], [RFC5289], and [RFC8422]. 1178 This YANG module has a informative references to [RFC2246], 1179 [RFC4346], [RFC5246], and [RFC8446]. 1181 file "ietf-tls-common@2019-04-29.yang" 1182 module ietf-tls-common { 1183 yang-version 1.1; 1184 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; 1185 prefix tlscmn; 1187 organization 1188 "IETF NETCONF (Network Configuration) Working Group"; 1190 contact 1191 "WG Web: 1192 WG List: 1193 Author: Kent Watsen 1194 Author: Gary Wu "; 1196 description 1197 "This module defines a common features, identities, and 1198 groupings for Transport Layer Security (TLS). 1200 Copyright (c) 2019 IETF Trust and the persons identified 1201 as authors of the code. All rights reserved. 1203 Redistribution and use in source and binary forms, with 1204 or without modification, is permitted pursuant to, and 1205 subject to the license terms contained in, the Simplified 1206 BSD License set forth in Section 4.c of the IETF Trust's 1207 Legal Provisions Relating to IETF Documents 1208 (https://trustee.ietf.org/license-info). 1210 This version of this YANG module is part of RFC XXXX 1211 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1212 itself for full legal notices.; 1214 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1215 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1216 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1217 are to be interpreted as described in BCP 14 (RFC 2119) 1218 (RFC 8174) when, and only when, they appear in all 1219 capitals, as shown here."; 1221 revision 2019-04-29 { 1222 description 1223 "Initial version"; 1224 reference 1225 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 1226 } 1228 // Features 1230 feature tls-1_0 { 1231 description 1232 "TLS Protocol Version 1.0 is supported."; 1233 reference 1234 "RFC 2246: The TLS Protocol Version 1.0"; 1235 } 1237 feature tls-1_1 { 1238 description 1239 "TLS Protocol Version 1.1 is supported."; 1240 reference 1241 "RFC 4346: The Transport Layer Security (TLS) Protocol 1242 Version 1.1"; 1243 } 1245 feature tls-1_2 { 1246 description 1247 "TLS Protocol Version 1.2 is supported."; 1248 reference 1249 "RFC 5246: The Transport Layer Security (TLS) Protocol 1250 Version 1.2"; 1251 } 1253 feature tls-1_3 { 1254 description 1255 "TLS Protocol Version 1.2 is supported."; 1256 reference 1257 "RFC 8446: The Transport Layer Security (TLS) Protocol 1258 Version 1.3"; 1259 } 1261 feature tls-ecc { 1262 description 1263 "Elliptic Curve Cryptography (ECC) is supported for TLS."; 1264 reference 1265 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1266 for Transport Layer Security (TLS)"; 1267 } 1269 feature tls-dhe { 1270 description 1271 "Ephemeral Diffie-Hellman key exchange is supported for TLS."; 1272 reference 1273 "RFC 5246: The Transport Layer Security (TLS) Protocol 1274 Version 1.2"; 1275 } 1277 feature tls-3des { 1278 description 1279 "The Triple-DES block cipher is supported for TLS."; 1280 reference 1281 "RFC 5246: The Transport Layer Security (TLS) Protocol 1282 Version 1.2"; 1283 } 1285 feature tls-gcm { 1286 description 1287 "The Galois/Counter Mode authenticated encryption mode is 1288 supported for TLS."; 1289 reference 1290 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for 1291 TLS"; 1292 } 1294 feature tls-sha2 { 1295 description 1296 "The SHA2 family of cryptographic hash functions is supported 1297 for TLS."; 1298 reference 1299 "FIPS PUB 180-4: Secure Hash Standard (SHS)"; 1300 } 1302 // Identities 1304 identity tls-version-base { 1305 description 1306 "Base identity used to identify TLS protocol versions."; 1307 } 1309 identity tls-1.0 { 1310 base tls-version-base; 1311 if-feature "tls-1_0"; 1312 description 1313 "TLS Protocol Version 1.0."; 1314 reference 1315 "RFC 2246: The TLS Protocol Version 1.0"; 1316 } 1318 identity tls-1.1 { 1319 base tls-version-base; 1320 if-feature "tls-1_1"; 1321 description 1322 "TLS Protocol Version 1.1."; 1323 reference 1324 "RFC 4346: The Transport Layer Security (TLS) Protocol 1325 Version 1.1"; 1326 } 1328 identity tls-1.2 { 1329 base tls-version-base; 1330 if-feature "tls-1_2"; 1331 description 1332 "TLS Protocol Version 1.2."; 1333 reference 1334 "RFC 5246: The Transport Layer Security (TLS) Protocol 1335 Version 1.2"; 1336 } 1338 identity cipher-suite-base { 1339 description 1340 "Base identity used to identify TLS cipher suites."; 1341 } 1343 identity rsa-with-aes-128-cbc-sha { 1344 base cipher-suite-base; 1345 description 1346 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA."; 1347 reference 1348 "RFC 5246: The Transport Layer Security (TLS) Protocol 1349 Version 1.2"; 1350 } 1352 identity rsa-with-aes-256-cbc-sha { 1353 base cipher-suite-base; 1354 description 1355 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; 1356 reference 1357 "RFC 5246: The Transport Layer Security (TLS) Protocol 1358 Version 1.2"; 1359 } 1361 identity rsa-with-aes-128-cbc-sha256 { 1362 base cipher-suite-base; 1363 if-feature "tls-sha2"; 1364 description 1365 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; 1366 reference 1367 "RFC 5246: The Transport Layer Security (TLS) Protocol 1368 Version 1.2"; 1369 } 1371 identity rsa-with-aes-256-cbc-sha256 { 1372 base cipher-suite-base; 1373 if-feature "tls-sha2"; 1374 description 1375 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256."; 1376 reference 1377 "RFC 5246: The Transport Layer Security (TLS) Protocol 1378 Version 1.2"; 1379 } 1381 identity dhe-rsa-with-aes-128-cbc-sha { 1382 base cipher-suite-base; 1383 if-feature "tls-dhe"; 1384 description 1385 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA."; 1386 reference 1387 "RFC 5246: The Transport Layer Security (TLS) Protocol 1388 Version 1.2"; 1389 } 1391 identity dhe-rsa-with-aes-256-cbc-sha { 1392 base cipher-suite-base; 1393 if-feature "tls-dhe"; 1394 description 1395 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA."; 1396 reference 1397 "RFC 5246: The Transport Layer Security (TLS) Protocol 1398 Version 1.2"; 1399 } 1401 identity dhe-rsa-with-aes-128-cbc-sha256 { 1402 base cipher-suite-base; 1403 if-feature "tls-dhe and tls-sha2"; 1404 description 1405 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; 1406 reference 1407 "RFC 5246: The Transport Layer Security (TLS) Protocol 1408 Version 1.2"; 1409 } 1411 identity dhe-rsa-with-aes-256-cbc-sha256 { 1412 base cipher-suite-base; 1413 if-feature "tls-dhe and tls-sha2"; 1414 description 1415 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; 1416 reference 1417 "RFC 5246: The Transport Layer Security (TLS) Protocol 1418 Version 1.2"; 1419 } 1421 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 { 1422 base cipher-suite-base; 1423 if-feature "tls-ecc and tls-sha2"; 1424 description 1425 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256."; 1426 reference 1427 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1428 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1429 } 1430 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 { 1431 base cipher-suite-base; 1432 if-feature "tls-ecc and tls-sha2"; 1433 description 1434 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384."; 1435 reference 1436 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1437 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1438 } 1440 identity ecdhe-rsa-with-aes-128-cbc-sha256 { 1441 base cipher-suite-base; 1442 if-feature "tls-ecc and tls-sha2"; 1443 description 1444 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256."; 1445 reference 1446 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1447 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1448 } 1450 identity ecdhe-rsa-with-aes-256-cbc-sha384 { 1451 base cipher-suite-base; 1452 if-feature "tls-ecc and tls-sha2"; 1453 description 1454 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; 1455 reference 1456 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1457 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1458 } 1460 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { 1461 base cipher-suite-base; 1462 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1463 description 1464 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; 1465 reference 1466 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1467 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1468 } 1470 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 { 1471 base cipher-suite-base; 1472 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1473 description 1474 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."; 1475 reference 1476 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1477 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1479 } 1481 identity ecdhe-rsa-with-aes-128-gcm-sha256 { 1482 base cipher-suite-base; 1483 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1484 description 1485 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256."; 1486 reference 1487 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1488 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1489 } 1491 identity ecdhe-rsa-with-aes-256-gcm-sha384 { 1492 base cipher-suite-base; 1493 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1494 description 1495 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384."; 1496 reference 1497 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1498 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1499 } 1501 identity rsa-with-3des-ede-cbc-sha { 1502 base cipher-suite-base; 1503 if-feature "tls-3des"; 1504 description 1505 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; 1506 reference 1507 "RFC 5246: The Transport Layer Security (TLS) Protocol 1508 Version 1.2"; 1509 } 1511 identity ecdhe-rsa-with-3des-ede-cbc-sha { 1512 base cipher-suite-base; 1513 if-feature "tls-ecc and tls-3des"; 1514 description 1515 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; 1516 reference 1517 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1518 for Transport Layer Security (TLS)"; 1519 } 1521 identity ecdhe-rsa-with-aes-128-cbc-sha { 1522 base cipher-suite-base; 1523 if-feature "tls-ecc"; 1524 description 1525 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA."; 1526 reference 1527 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1528 for Transport Layer Security (TLS)"; 1529 } 1531 identity ecdhe-rsa-with-aes-256-cbc-sha { 1532 base cipher-suite-base; 1533 if-feature "tls-ecc"; 1534 description 1535 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA."; 1536 reference 1537 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1538 for Transport Layer Security (TLS)"; 1539 } 1541 // Groupings 1543 grouping hello-params-grouping { 1544 description 1545 "A reusable grouping for TLS hello message parameters."; 1546 reference 1547 "RFC 5246: The Transport Layer Security (TLS) Protocol 1548 Version 1.2"; 1549 container tls-versions { 1550 description 1551 "Parameters regarding TLS versions."; 1552 leaf-list tls-version { 1553 type identityref { 1554 base tls-version-base; 1555 } 1556 description 1557 "Acceptable TLS protocol versions. 1559 If this leaf-list is not configured (has zero elements) 1560 the acceptable TLS protocol versions are implementation- 1561 defined."; 1562 } 1563 } 1564 container cipher-suites { 1565 description 1566 "Parameters regarding cipher suites."; 1567 leaf-list cipher-suite { 1568 type identityref { 1569 base cipher-suite-base; 1570 } 1571 ordered-by user; 1572 description 1573 "Acceptable cipher suites in order of descending 1574 preference. The configured host key algorithms should 1575 be compatible with the algorithm used by the configured 1576 private key. Please see Section 5 of RFC XXXX for 1577 valid combinations. 1579 If this leaf-list is not configured (has zero elements) 1580 the acceptable cipher suites are implementation- 1581 defined."; 1582 reference 1583 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 1584 } 1585 } 1586 } 1587 } 1588 1590 6. Security Considerations 1592 The YANG modules defined in this document are designed to be accessed 1593 via YANG based management protocols, such as NETCONF [RFC6241] and 1594 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1595 implement secure transport layers (e.g., SSH, TLS) with mutual 1596 authentication. 1598 The NETCONF access control model (NACM) [RFC8341] provides the means 1599 to restrict access for particular users to a pre-configured subset of 1600 all available protocol operations and content. 1602 Since the modules in this document only define groupings, these 1603 considerations are primarily for the designers of other modules that 1604 use these groupings. 1606 There are a number of data nodes defined in the YANG modules that are 1607 writable/creatable/deletable (i.e., config true, which is the 1608 default). These data nodes may be considered sensitive or vulnerable 1609 in some network environments. Write operations (e.g., edit-config) 1610 to these data nodes without proper protection can have a negative 1611 effect on network operations. These are the subtrees and data nodes 1612 and their sensitivity/vulnerability: 1614 *: The entire subtree defined by the grouping statement in both 1615 the "ietf-ssh-client" and "ietf-ssh-server" modules is 1616 sensitive to write operations. For instance, the addition or 1617 removal of references to keys, certificates, trusted anchors, 1618 etc., or even the modification of transport or keepalive 1619 parameters can dramatically alter the implemented security 1620 policy. For this reason, this node is protected the NACM 1621 extension "default-deny-write". 1623 Some of the readable data nodes in the YANG modules may be considered 1624 sensitive or vulnerable in some network environments. It is thus 1625 important to control read access (e.g., via get, get-config, or 1626 notification) to these data nodes. These are the subtrees and data 1627 nodes and their sensitivity/vulnerability: 1629 /tls-client-parameters/client-identity/: This subtree in the 1630 "ietf-tls-client" module contains nodes that are additionally 1631 sensitive to read operations such that, in normal use cases, 1632 they should never be returned to a client. Some of these nodes 1633 (i.e., public-key/local-definition/private-key and certificate/ 1634 local-definition/private-key) are already protected by the NACM 1635 extension "default-deny-all" set in the "grouping" statements 1636 defined in [I-D.ietf-netconf-crypto-types]. 1638 /tls-server-parameters/server-identity/: This subtree in the 1639 "ietf-tls-server" module contains nodes that are additionally 1640 sensitive to read operations such that, in normal use cases, 1641 they should never be returned to a client. All of these nodes 1642 (i.e., host-key/public-key/local-definition/private-key and 1643 host-key/certificate/local-definition/private-key) are already 1644 protected by the NACM extension "default-deny-all" set in the 1645 "grouping" statements defined in 1646 [I-D.ietf-netconf-crypto-types]. 1648 Some of the operations in this YANG module may be considered 1649 sensitive or vulnerable in some network environments. It is thus 1650 important to control access to these operations. These are the 1651 operations and their sensitivity/vulnerability: 1653 *: The groupings defined in this document include "action" 1654 statements that come from groupings defined in 1655 [I-D.ietf-netconf-crypto-types]. Please consult that document 1656 for the security considerations of the "action" statements 1657 defined by the "grouping" statements defined in this document. 1659 7. IANA Considerations 1661 7.1. The IETF XML Registry 1663 This document registers three URIs in the "ns" subregistry of the 1664 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the 1665 following registrations are requested: 1667 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 1668 Registrant Contact: The NETCONF WG of the IETF. 1669 XML: N/A, the requested URI is an XML namespace. 1671 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 1672 Registrant Contact: The NETCONF WG of the IETF. 1673 XML: N/A, the requested URI is an XML namespace. 1675 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common 1676 Registrant Contact: The NETCONF WG of the IETF. 1677 XML: N/A, the requested URI is an XML namespace. 1679 7.2. The YANG Module Names Registry 1681 This document registers three YANG modules in the YANG Module Names 1682 registry [RFC6020]. Following the format in [RFC6020], the following 1683 registrations are requested: 1685 name: ietf-tls-client 1686 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 1687 prefix: tlsc 1688 reference: RFC XXXX 1690 name: ietf-tls-server 1691 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 1692 prefix: tlss 1693 reference: RFC XXXX 1695 name: ietf-tls-common 1696 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common 1697 prefix: tlscmn 1698 reference: RFC XXXX 1700 8. References 1702 8.1. Normative References 1704 [I-D.ietf-netconf-crypto-types] 1705 Watsen, K. and H. Wang, "Common YANG Data Types for 1706 Cryptography", draft-ietf-netconf-crypto-types-05 (work in 1707 progress), March 2019. 1709 [I-D.ietf-netconf-keystore] 1710 Watsen, K., "YANG Data Model for a Centralized Keystore 1711 Mechanism", draft-ietf-netconf-keystore-08 (work in 1712 progress), March 2019. 1714 [I-D.ietf-netconf-trust-anchors] 1715 Watsen, K., "YANG Data Model for Global Trust Anchors", 1716 draft-ietf-netconf-trust-anchors-03 (work in progress), 1717 March 2019. 1719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1720 Requirement Levels", BCP 14, RFC 2119, 1721 DOI 10.17487/RFC2119, March 1997, 1722 . 1724 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1725 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1726 DOI 10.17487/RFC5288, August 2008, 1727 . 1729 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 1730 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 1731 DOI 10.17487/RFC5289, August 2008, 1732 . 1734 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1735 the Network Configuration Protocol (NETCONF)", RFC 6020, 1736 DOI 10.17487/RFC6020, October 2010, 1737 . 1739 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1740 NETCONF Protocol over Transport Layer Security (TLS) with 1741 Mutual X.509 Authentication", RFC 7589, 1742 DOI 10.17487/RFC7589, June 2015, 1743 . 1745 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1746 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1747 . 1749 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1750 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1751 May 2017, . 1753 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1754 Access Control Model", STD 91, RFC 8341, 1755 DOI 10.17487/RFC8341, March 2018, 1756 . 1758 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1759 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1760 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1761 DOI 10.17487/RFC8422, August 2018, 1762 . 1764 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1765 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1766 . 1768 8.2. Informative References 1770 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1771 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1772 . 1774 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1775 DOI 10.17487/RFC2818, May 2000, 1776 . 1778 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1779 DOI 10.17487/RFC3688, January 2004, 1780 . 1782 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1783 (TLS) Protocol Version 1.1", RFC 4346, 1784 DOI 10.17487/RFC4346, April 2006, 1785 . 1787 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1788 (TLS) Protocol Version 1.2", RFC 5246, 1789 DOI 10.17487/RFC5246, August 2008, 1790 . 1792 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1793 and A. Bierman, Ed., "Network Configuration Protocol 1794 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1795 . 1797 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1798 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1799 . 1801 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1802 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1803 . 1805 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1806 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1807 . 1809 Appendix A. Change Log 1811 A.1. 00 to 01 1813 o Noted that '0.0.0.0' and '::' might have special meanings. 1815 o Renamed "keychain" to "keystore". 1817 A.2. 01 to 02 1819 o Removed the groupings containing transport-level configuration. 1820 Now modules contain only the transport-independent groupings. 1822 o Filled in previously incomplete 'ietf-tls-client' module. 1824 o Added cipher suites for various algorithms into new 'ietf-tls- 1825 common' module. 1827 A.3. 02 to 03 1829 o Added a 'must' statement to container 'server-auth' asserting that 1830 at least one of the various auth mechanisms must be specified. 1832 o Fixed description statement for leaf 'trusted-ca-certs'. 1834 A.4. 03 to 04 1836 o Updated title to "YANG Groupings for TLS Clients and TLS Servers" 1838 o Updated leafref paths to point to new keystore path 1840 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to 1841 'tlscmn'. 1843 o Added TLS protocol verions 1.0 and 1.1. 1845 o Made author lists consistent 1847 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1849 o Updated YANG to use typedefs around leafrefs to common keystore 1850 paths 1852 o Now inlines key and certificates (no longer a leafref to keystore) 1854 A.5. 04 to 05 1856 o Merged changes from co-author. 1858 A.6. 05 to 06 1860 o Updated to use trust anchors from trust-anchors draft (was 1861 keystore draft) 1863 o Now Uses new keystore grouping enabling asymmetric key to be 1864 either locally defined or a reference to the keystore. 1866 A.7. 06 to 07 1868 o factored the tls-[client|server]-groupings into more reusable 1869 groupings. 1871 o added if-feature statements for the new "x509-certificates" 1872 feature defined in draft-ietf-netconf-trust-anchors. 1874 A.8. 07 to 08 1876 o Added a number of compatibility matrices to Section 5 (thanks 1877 Frank!) 1879 o Clarified that any configured "cipher-suite" values need to be 1880 compatible with the configured private key. 1882 A.9. 08 to 09 1884 o Updated examples to reflect update to groupings defined in the 1885 keystore draft. 1887 o Add TLS keepalives features and groupings. 1889 o Prefixed top-level TLS grouping nodes with 'tls-' and support 1890 mashups. 1892 o Updated copyright date, boilerplate template, affiliation, and 1893 folding algorithm. 1895 A.10. 09 to 10 1897 o Reformatted the YANG modules. 1899 A.11. 10 to 11 1901 o Collapsed all the inner groupings into the top-level grouping. 1903 o Added a top-level "demux container" inside the top-level grouping. 1905 o Added NACM statements and updated the Security Considerations 1906 section. 1908 o Added "presence" statements on the "keepalive" containers, as was 1909 needed to address a validation error that appeared after adding 1910 the "must" statements into the NETCONF/RESTCONF client/server 1911 modules. 1913 o Updated the boilerplate text in module-level "description" 1914 statement to match copyeditor convention. 1916 A.12. 11 to 12 1918 o In server model, made 'client-authentication' a 'presence' node 1919 indicating that the server supports client authentication. 1921 o In the server model, added a 'required-or-optional' choice to 1922 'client-authentication' to better support protocols such as 1923 RESTCONF. 1925 o In the server model, added a 'local-or-external' choice to 1926 'client-authentication' to better support consuming data models 1927 that prefer to keep client auth with client definitions than in a 1928 model principally concerned with the "transport". 1930 o In both models, removed the "demux containers", floating the 1931 nacm:default-deny-write to each descendent node, and adding a note 1932 to model designers regarding the potential need to add their own 1933 demux containers. 1935 o Fixed a couple references (section 2 --> section 3) 1937 Acknowledgements 1939 The authors would like to thank for following for lively discussions 1940 on list and in the halls (ordered by last name): Andy Bierman, Martin 1941 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 1942 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, 1943 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. 1945 Authors' Addresses 1947 Kent Watsen 1948 Watsen Networks 1950 EMail: kent+ietf@watsen.net 1952 Gary Wu 1953 Cisco Systems 1955 EMail: garywu@cisco.com 1957 Liang Xia 1958 Huawei 1960 EMail: frank.xialiang@huawei.com