idnits 2.17.1 draft-ietf-netconf-tls-client-server-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2017) is 2376 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 (-35) exists of draft-ietf-netconf-keystore-02 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track G. Wu 5 Expires: April 21, 2018 Cisco Systems 6 October 18, 2017 8 YANG Groupings for TLS Clients and TLS Servers 9 draft-ietf-netconf-tls-client-server-04 11 Abstract 13 This document defines three YANG modules: the first defines groupings 14 for a generic TLS client, the second defines groupings for a generic 15 TLS server, and the third defines common identities and groupings 16 used by both the client and the server. It is intended that these 17 groupings will be used by applications using the TLS protocol. 19 Editorial Note (To be removed by RFC Editor) 21 This draft contains many placeholder values that need to be replaced 22 with finalized values at the time of publication. This note 23 summarizes all of the substitutions that are needed. No other RFC 24 Editor instructions are specified elsewhere in this document. 26 This document contains references to other drafts in progress, both 27 in the Normative References section, as well as in body text 28 throughout. Please update the following references to reflect their 29 final RFC assignments: 31 o I-D.ietf-netconf-keystore 33 Artwork in this document contains shorthand references to drafts in 34 progress. Please apply the following replacements: 36 o "XXXX" --> the assigned RFC value for this draft 38 o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-keystore 40 Artwork in this document contains placeholder values for the date of 41 publication of this draft. Please apply the following replacement: 43 o "2017-10-19" --> the publication date of this draft 45 The following Appendix section is to be removed prior to publication: 47 o Appendix A. Change Log 49 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at https://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on April 21, 2018. 68 Copyright Notice 70 Copyright (c) 2017 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (https://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 87 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 88 2. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 89 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 90 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 91 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 5 92 3. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 8 93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8 94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9 95 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 9 96 4. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 12 97 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13 98 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13 100 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 102 4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13 103 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 105 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 23 106 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 23 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 110 8.2. Informative References . . . . . . . . . . . . . . . . . 25 111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 112 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 27 113 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 27 114 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 27 115 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 27 116 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 27 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 119 1. Introduction 121 This document defines three YANG [RFC7950] modules: the first defines 122 a grouping for a generic TLS client, the second defines a grouping 123 for a generic TLS server, and the third defines identities and 124 groupings common to both the client and the server (TLS is defined in 125 [RFC5246]). It is intended that these groupings will be used by 126 applications using the TLS protocol. For instance, these groupings 127 could be used to help define the data model for an HTTPS [RFC2818] 128 server or a NETCONF over TLS [RFC7589] based server. 130 The client and server YANG modules in this document each define one 131 grouping, which is focused on just TLS-specific configuration, and 132 specifically avoids any transport-level configuration, such as what 133 ports to listen-on or connect-to. This enables applications the 134 opportunity to define their own strategy for how the underlying TCP 135 connection is established. For instance, applications supporting 136 NETCONF Call Home [RFC8071] could use the grouping for the TLS parts 137 it provides, while adding data nodes for the TCP-level call-home 138 configuration. 140 1.1. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 150 1.2. Tree Diagrams 152 A simplified graphical representation of the data models is used in 153 this document. The meaning of the symbols in these diagrams is as 154 follows: 156 o Brackets "[" and "]" enclose list keys. 158 o Braces "{" and "}" enclose feature names, and indicate that the 159 named feature must be present for the subtree to be present. 161 o Abbreviations before data node names: "rw" means configuration 162 (read-write) and "ro" state data (read-only). 164 o Symbols after data node names: "?" means an optional node, "!" 165 means a presence container, and "*" denotes a list and leaf-list. 167 o Parentheses enclose choice and case nodes, and case nodes are also 168 marked with a colon (":"). 170 o Ellipsis ("...") stands for contents of subtrees that are not 171 shown. 173 2. The TLS Client Model 175 The TLS client model presented in this section contains one YANG 176 grouping, to just configure the TLS client, omitting, for instance, 177 any configuration for which IP address or port the client should 178 connect to. 180 This grouping references data nodes defined by the keystore model 181 [I-D.ietf-netconf-keystore]. For instance, a reference to the 182 keystore model is made to indicate which trusted CA certificate a 183 client should use to authenticate the server's certificate. 185 2.1. Tree Diagram 187 The following tree diagram presents the data model for the grouping 188 defined in the ietf-tls-client module. Please see Section 1.2 for 189 tree diagram notation. 191 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 193 module: ietf-tls-client 195 grouping tls-client-grouping 196 +---- client-auth 197 | +---- (auth-type)? 198 | +--:(certificate) 199 | +---- certificate? leafref 200 +---- server-auth 201 | +---- pinned-ca-certs? 202 | | -> /ks:keystore/pinned-certificates/name 203 | +---- pinned-server-certs? 204 | -> /ks:keystore/pinned-certificates/name 205 +---- hello-params {tls-client-hello-params-config}? 206 +---- tls-versions 207 | +---- tls-version* identityref 208 +---- cipher-suites 209 +---- cipher-suite* identityref 211 2.2. Example Usage 213 This section shows how it would appear if the tls-client-grouping 214 were populated with some data. This example is consistent with the 215 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. 217 218 220 221 222 builtin-idevid-cert 223 225 226 227 deployment-specific-ca-certs 228 explicitly-trusted-client-certs 229 231 233 2.3. YANG Model 235 This YANG module has a normative references to [RFC6991] and 236 [I-D.ietf-netconf-keystore]. 238 file "ietf-tls-client@2017-10-19.yang" 239 module ietf-tls-client { 240 yang-version 1.1; 242 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 244 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 245 prefix "tlsc"; 247 import ietf-tls-common { 248 prefix tlscmn; 249 revision-date 2017-10-19; // stable grouping definitions 250 reference 251 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 252 } 254 import ietf-keystore { 255 prefix ks; 256 reference 257 "RFC YYYY: Keystore Model"; 258 } 260 organization 261 "IETF NETCONF (Network Configuration) Working Group"; 263 contact 264 "WG Web: 265 WG List: 267 Author: Kent Watsen 268 270 Author: Gary Wu 271 "; 273 description 274 "This module defines a reusable grouping for a TLS client that 275 can be used as a basis for specific TLS client instances. 277 Copyright (c) 2017 IETF Trust and the persons identified as 278 authors of the code. All rights reserved. 280 Redistribution and use in source and binary forms, with or 281 without modification, is permitted pursuant to, and subject 282 to the license terms contained in, the Simplified BSD 283 License set forth in Section 4.c of the IETF Trust's 284 Legal Provisions Relating to IETF Documents 285 (http://trustee.ietf.org/license-info). 287 This version of this YANG module is part of RFC XXXX; see 288 the RFC itself for full legal notices."; 290 revision "2017-10-19" { 292 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 294 description 295 "Initial version"; 296 reference 297 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 298 } 300 feature tls-client-hello-params-config { 301 description 302 "TLS hello message parameters are configurable on a TLS 303 client."; 304 } 306 grouping tls-client-grouping { 307 description 308 "A reusable grouping for configuring a TLS client without 309 any consideration for how an underlying TCP session is 310 established."; 312 container client-auth { 313 description 314 "The credentials used by the client to authenticate to 315 the TLS server."; 317 choice auth-type { 318 description 319 "The authentication type."; 320 leaf certificate { 321 type leafref { 322 path "/ks:keystore/ks:keys/ks:key/ks:certificates" 323 + "/ks:certificate/ks:name"; 324 } 325 description 326 "A certificates to be used for user authentication."; 327 } 328 } 329 } 331 container server-auth { 332 must 'pinned-ca-certs or pinned-server-certs'; 333 description 334 "Trusted server identities."; 335 leaf pinned-ca-certs { 336 type leafref { 337 path "/ks:keystore/ks:pinned-certificates/ks:name"; 338 } 339 description 340 "A reference to a list of certificate authority (CA) 341 certificates used by the TLS client to authenticate 343 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 345 TLS server certificates. A server certificate is 346 authenticated if it has a valid chain of trust to 347 a configured pinned CA certificate."; 348 } 350 leaf pinned-server-certs { 351 type leafref { 352 path "/ks:keystore/ks:pinned-certificates/ks:name"; 353 } 354 description 355 "A reference to a list of server certificates used by 356 the TLS client to authenticate TLS server certificates. 357 A server certificate is authenticated if it is an 358 exact match to a configured pinned server certificate."; 359 } 360 } 362 container hello-params { 363 if-feature tls-client-hello-params-config; 364 uses tlscmn:hello-params-grouping; 365 description 366 "Configurable parameters for the TLS hello message."; 367 } 369 } // end tls-client-grouping 371 } 372 374 3. The TLS Server Model 376 The TLS server model presented in this section contains one YANG 377 grouping, for just the TLS-level configuration, omitting, for 378 instance, configuration for which ports to open to listen for 379 connections on. 381 This grouping references data nodes defined by the keystore model 382 [I-D.ietf-netconf-keystore]. For instance, a reference to the 383 keystore model is made to indicate which certificate a server should 384 present. 386 3.1. Tree Diagram 388 The following tree diagram presents the data model for the grouping 389 defined in the ietf-tls-server module. Please see Section 1.2 for 390 tree diagram notation. 392 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 394 module: ietf-tls-server 396 grouping tls-server-grouping 397 +---- certificates 398 | +---- certificate* [name] 399 | +---- name? leafref 400 +---- client-auth 401 | +---- pinned-ca-certs? 402 | | -> /ks:keystore/pinned-certificates/name 403 | +---- pinned-client-certs? 404 | -> /ks:keystore/pinned-certificates/name 405 +---- hello-params {tls-server-hello-params-config}? 406 +---- tls-versions 407 | +---- tls-version* identityref 408 +---- cipher-suites 409 +---- cipher-suite* identityref 411 3.2. Example Usage 413 This section shows how it would appear if the tls-server-grouping 414 were populated with some data. This example is consistent with the 415 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. 417 419 420 421 422 tls-ec-cert 423 424 426 427 428 deployment-specific-ca-certs 429 explicitly-trusted-client-certs 430 432 434 3.3. YANG Model 436 This YANG module has a normative references to [RFC6991], and 437 [I-D.ietf-netconf-keystore]. 439 file "ietf-tls-server@2017-10-19.yang" 440 module ietf-tls-server { 441 yang-version 1.1; 443 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 445 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 446 prefix "tlss"; 448 import ietf-tls-common { 449 prefix tlscmn; 450 revision-date 2017-10-19; // stable grouping definitions 451 reference 452 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 453 } 455 import ietf-keystore { 456 prefix ks; 457 reference 458 "RFC YYYY: Keystore Model"; 459 } 461 organization 462 "IETF NETCONF (Network Configuration) Working Group"; 464 contact 465 "WG Web: 466 WG List: 468 Author: Kent Watsen 469 471 Author: Gary Wu 472 "; 474 description 475 "This module defines a reusable grouping for a TLS server that 476 can be used as a basis for specific TLS server instances. 478 Copyright (c) 2017 IETF Trust and the persons identified as 479 authors of the code. All rights reserved. 481 Redistribution and use in source and binary forms, with or 482 without modification, is permitted pursuant to, and subject 483 to the license terms contained in, the Simplified BSD 484 License set forth in Section 4.c of the IETF Trust's 485 Legal Provisions Relating to IETF Documents 486 (http://trustee.ietf.org/license-info). 488 This version of this YANG module is part of RFC XXXX; see 489 the RFC itself for full legal notices."; 491 revision "2017-10-19" { 493 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 495 description 496 "Initial version"; 497 reference 498 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 499 } 501 feature tls-server-hello-params-config { 502 description 503 "TLS hello message parameters are configurable on a TLS 504 server."; 505 } 507 // groupings 509 grouping tls-server-grouping { 510 description 511 "A reusable grouping for configuring a TLS server without 512 any consideration for how underlying TCP sessions are 513 established."; 515 container certificates { 516 description 517 "The list of certificates the TLS server will present when 518 establishing a TLS connection in its Certificate message, 519 as defined in Section 7.4.2 in RFC 5246."; 520 reference 521 "RFC 5246: 522 The Transport Layer Security (TLS) Protocol Version 1.2"; 523 list certificate { 524 key name; 525 min-elements 1; 526 description 527 "An unordered list of certificates the TLS server can pick 528 from when sending its Server Certificate message."; 529 reference 530 "RFC 5246: The TLS Protocol, Section 7.4.2"; 531 leaf name { 532 type leafref { 533 path "/ks:keystore/ks:keys/ks:key/ks:certificates/" 534 + "ks:certificate/ks:name"; 535 } 536 description 537 "The name of the certificate in the keystore."; 538 } 539 } 540 } 542 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 544 container client-auth { 545 description 546 "A reference to a list of pinned certificate authority (CA) 547 certificates and a reference to a list of pinned client 548 certificates."; 549 leaf pinned-ca-certs { 550 type leafref { 551 path "/ks:keystore/ks:pinned-certificates/ks:name"; 552 } 553 description 554 "A reference to a list of certificate authority (CA) 555 certificates used by the TLS server to authenticate 556 TLS client certificates. A client certificate is 557 authenticated if it has a valid chain of trust to 558 a configured pinned CA certificate."; 559 } 560 leaf pinned-client-certs { 561 type leafref { 562 path "/ks:keystore/ks:pinned-certificates/ks:name"; 563 } 564 description 565 "A reference to a list of client certificates used by 566 the TLS server to authenticate TLS client certificates. 567 A clients certificate is authenticated if it is an 568 exact match to a configured pinned client certificate."; 569 } 570 } 572 container hello-params { 573 if-feature tls-server-hello-params-config; 574 uses tlscmn:hello-params-grouping; 575 description 576 "Configurable parameters for the TLS hello message."; 577 } 579 } // end tls-server-grouping 581 } 582 584 4. The TLS Common Model 586 The TLS common model presented in this section contains identities 587 and groupings common to both TLS clients and TLS servers. The hello- 588 params-grouping can be used to configure the list of TLS algorithms 589 permitted by the TLS client or TLS server. The lists of algorithms 590 are ordered such that, if multiple algorithms are permitted by the 591 client, the algorithm that appears first in its list that is also 593 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 595 permitted by the server is used for the TLS transport layer 596 connection. The ability to restrict the the algorithms allowed is 597 provided in this grouping for TLS clients and TLS servers that are 598 capable of doing so and may serve to make TLS clients and TLS servers 599 compliant with security policies. 601 Features are defined for algorithms that are OPTIONAL or are not 602 widely supported by popular implementations. Note that the list of 603 algorithms is not exhaustive. 605 4.1. Tree Diagram 607 The following tree diagram presents the data model for the grouping 608 defined in the ietf-tls-common module. Please see Section 1.2 for 609 tree diagram notation. 611 module: ietf-tls-common 613 grouping hello-params-grouping 614 +---- tls-versions 615 | +---- tls-version* identityref 616 +---- cipher-suites 617 +---- cipher-suite* identityref 619 4.2. Example Usage 621 This section shows how it would appear if the transport-params- 622 grouping were populated with some data. 624 625 627 628 tlscmn:tls-1.1 629 tlscmn:tls-1.2 630 631 632 tlscmn:dhe-rsa-with-aes-128-cbc-sha 633 tlscmn:rsa-with-aes-128-cbc-sha 634 tlscmn:rsa-with-3des-ede-cbc-sha 635 636 638 4.3. YANG Model 640 This YANG module has a normative references to [RFC2246], [RFC4346], 641 [RFC4492], [RFC5246], [RFC5288], and [RFC5289]. 643 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 645 file "ietf-tls-common@2017-10-19.yang" 646 module ietf-tls-common { 647 yang-version 1.1; 649 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; 650 prefix "tlscmn"; 652 organization 653 "IETF NETCONF (Network Configuration) Working Group"; 655 contact 656 "WG Web: 657 WG List: 659 Author: Kent Watsen 660 662 Author: Gary Wu 663 "; 665 description 666 "This module defines a common features, identities, and groupings 667 for Transport Layer Security (TLS). 669 Copyright (c) 2017 IETF Trust and the persons identified as 670 authors of the code. All rights reserved. 672 Redistribution and use in source and binary forms, with or 673 without modification, is permitted pursuant to, and subject 674 to the license terms contained in, the Simplified BSD 675 License set forth in Section 4.c of the IETF Trust's 676 Legal Provisions Relating to IETF Documents 677 (http://trustee.ietf.org/license-info). 679 This version of this YANG module is part of RFC XXXX; see 680 the RFC itself for full legal notices."; 682 revision "2017-10-19" { 683 description 684 "Initial version"; 685 reference 686 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 687 } 689 // features 690 feature tls-1_0 { 691 description 693 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 695 "TLS Protocol Version 1.0 is supported."; 696 reference 697 "RFC 2246: The TLS Protocol Version 1.0"; 698 } 700 feature tls-1_1 { 701 description 702 "TLS Protocol Version 1.1 is supported."; 703 reference 704 "RFC 4346: The Transport Layer Security (TLS) Protocol 705 Version 1.1"; 706 } 708 feature tls-1_2 { 709 description 710 "TLS Protocol Version 1.2 is supported."; 711 reference 712 "RFC 5246: The Transport Layer Security (TLS) Protocol 713 Version 1.2"; 714 } 716 feature tls-ecc { 717 description 718 "Elliptic Curve Cryptography (ECC) is supported for TLS."; 719 reference 720 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 721 for Transport Layer Security (TLS)"; 722 } 724 feature tls-dhe { 725 description 726 "Ephemeral Diffie-Hellman key exchange is supported for TLS."; 727 reference 728 "RFC 5246: The Transport Layer Security (TLS) Protocol 729 Version 1.2"; 730 } 732 feature tls-3des { 733 description 734 "The Triple-DES block cipher is supported for TLS."; 735 reference 736 "RFC 5246: The Transport Layer Security (TLS) Protocol 737 Version 1.2"; 738 } 740 feature tls-gcm { 741 description 742 "The Galois/Counter Mode authenticated encryption mode is 744 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 746 supported for TLS."; 747 reference 748 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for 749 TLS"; 750 } 752 feature tls-sha2 { 753 description 754 "The SHA2 family of cryptographic hash functions is supported 755 for TLS."; 756 reference 757 "FIPS PUB 180-4: Secure Hash Standard (SHS)"; 758 } 760 // identities 761 identity tls-version-base { 762 description 763 "Base identity used to identify TLS protocol versions."; 764 } 766 identity tls-1.0 { 767 base tls-version-base; 768 if-feature tls-1_0; 769 description 770 "TLS Protocol Version 1.0."; 771 reference 772 "RFC 2246: The TLS Protocol Version 1.0"; 773 } 775 identity tls-1.1 { 776 base tls-version-base; 777 if-feature tls-1_1; 778 description 779 "TLS Protocol Version 1.1."; 780 reference 781 "RFC 4346: The Transport Layer Security (TLS) Protocol 782 Version 1.1"; 783 } 785 identity tls-1.2 { 786 base tls-version-base; 787 if-feature tls-1_2; 788 description 789 "TLS Protocol Version 1.2."; 790 reference 791 "RFC 5246: The Transport Layer Security (TLS) Protocol 792 Version 1.2"; 793 } 795 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 797 identity cipher-suite-base { 798 description 799 "Base identity used to identify TLS cipher suites."; 800 } 802 identity rsa-with-aes-128-cbc-sha { 803 base cipher-suite-base; 804 description 805 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA."; 806 reference 807 "RFC 5246: The Transport Layer Security (TLS) Protocol 808 Version 1.2"; 809 } 811 identity rsa-with-aes-256-cbc-sha { 812 base cipher-suite-base; 813 description 814 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; 815 reference 816 "RFC 5246: The Transport Layer Security (TLS) Protocol 817 Version 1.2"; 818 } 820 identity rsa-with-aes-128-cbc-sha256 { 821 base cipher-suite-base; 822 if-feature tls-sha2; 823 description 824 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; 825 reference 826 "RFC 5246: The Transport Layer Security (TLS) Protocol 827 Version 1.2"; 828 } 830 identity rsa-with-aes-256-cbc-sha256 { 831 base cipher-suite-base; 832 if-feature tls-sha2; 833 description 834 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256."; 835 reference 836 "RFC 5246: The Transport Layer Security (TLS) Protocol 837 Version 1.2"; 838 } 840 identity dhe-rsa-with-aes-128-cbc-sha { 841 base cipher-suite-base; 842 if-feature tls-dhe; 843 description 844 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA."; 846 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 848 reference 849 "RFC 5246: The Transport Layer Security (TLS) Protocol 850 Version 1.2"; 851 } 853 identity dhe-rsa-with-aes-256-cbc-sha { 854 base cipher-suite-base; 855 if-feature tls-dhe; 856 description 857 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA."; 858 reference 859 "RFC 5246: The Transport Layer Security (TLS) Protocol 860 Version 1.2"; 861 } 863 identity dhe-rsa-with-aes-128-cbc-sha256 { 864 base cipher-suite-base; 865 if-feature "tls-dhe and tls-sha2"; 866 description 867 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; 868 reference 869 "RFC 5246: The Transport Layer Security (TLS) Protocol 870 Version 1.2"; 871 } 873 identity dhe-rsa-with-aes-256-cbc-sha256 { 874 base cipher-suite-base; 875 if-feature "tls-dhe and tls-sha2"; 876 description 877 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; 878 reference 879 "RFC 5246: The Transport Layer Security (TLS) Protocol 880 Version 1.2"; 881 } 883 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 { 884 base cipher-suite-base; 885 if-feature "tls-ecc and tls-sha2"; 886 description 887 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256."; 888 reference 889 "RFC 5289: TLS Elliptic Curve Cipher Suites with 890 SHA-256/384 and AES Galois Counter Mode (GCM)"; 891 } 893 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 { 894 base cipher-suite-base; 895 if-feature "tls-ecc and tls-sha2"; 897 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 899 description 900 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384."; 901 reference 902 "RFC 5289: TLS Elliptic Curve Cipher Suites with 903 SHA-256/384 and AES Galois Counter Mode (GCM)"; 904 } 906 identity ecdhe-rsa-with-aes-128-cbc-sha256 { 907 base cipher-suite-base; 908 if-feature "tls-ecc and tls-sha2"; 909 description 910 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256."; 911 reference 912 "RFC 5289: TLS Elliptic Curve Cipher Suites with 913 SHA-256/384 and AES Galois Counter Mode (GCM)"; 914 } 916 identity ecdhe-rsa-with-aes-256-cbc-sha384 { 917 base cipher-suite-base; 918 if-feature "tls-ecc and tls-sha2"; 919 description 920 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; 921 reference 922 "RFC 5289: TLS Elliptic Curve Cipher Suites with 923 SHA-256/384 and AES Galois Counter Mode (GCM)"; 924 } 926 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { 927 base cipher-suite-base; 928 if-feature "tls-ecc and tls-gcm and tls-sha2"; 929 description 930 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; 931 reference 932 "RFC 5289: TLS Elliptic Curve Cipher Suites with 933 SHA-256/384 and AES Galois Counter Mode (GCM)"; 934 } 936 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 { 937 base cipher-suite-base; 938 if-feature "tls-ecc and tls-gcm and tls-sha2"; 939 description 940 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."; 941 reference 942 "RFC 5289: TLS Elliptic Curve Cipher Suites with 943 SHA-256/384 and AES Galois Counter Mode (GCM)"; 944 } 946 identity ecdhe-rsa-with-aes-128-gcm-sha256 { 948 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 950 base cipher-suite-base; 951 if-feature "tls-ecc and tls-gcm and tls-sha2"; 952 description 953 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256."; 954 reference 955 "RFC 5289: TLS Elliptic Curve Cipher Suites with 956 SHA-256/384 and AES Galois Counter Mode (GCM)"; 957 } 959 identity ecdhe-rsa-with-aes-256-gcm-sha384 { 960 base cipher-suite-base; 961 if-feature "tls-ecc and tls-gcm and tls-sha2"; 962 description 963 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384."; 964 reference 965 "RFC 5289: TLS Elliptic Curve Cipher Suites with 966 SHA-256/384 and AES Galois Counter Mode (GCM)"; 967 } 969 identity rsa-with-3des-ede-cbc-sha { 970 base cipher-suite-base; 971 if-feature tls-3des; 972 description 973 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; 974 reference 975 "RFC 5246: The Transport Layer Security (TLS) Protocol 976 Version 1.2"; 977 } 979 identity ecdhe-rsa-with-3des-ede-cbc-sha { 980 base cipher-suite-base; 981 if-feature "tls-ecc and tls-3des"; 982 description 983 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; 984 reference 985 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 986 for Transport Layer Security (TLS)"; 987 } 989 identity ecdhe-rsa-with-aes-128-cbc-sha { 990 base cipher-suite-base; 991 if-feature "tls-ecc"; 992 description 993 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA."; 994 reference 995 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 996 for Transport Layer Security (TLS)"; 997 } 999 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1001 identity ecdhe-rsa-with-aes-256-cbc-sha { 1002 base cipher-suite-base; 1003 if-feature "tls-ecc"; 1004 description 1005 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA."; 1006 reference 1007 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 1008 for Transport Layer Security (TLS)"; 1009 } 1011 // groupings 1013 grouping hello-params-grouping { 1014 description 1015 "A reusable grouping for TLS hello message parameters."; 1016 reference 1017 "RFC 5246: The Transport Layer Security (TLS) Protocol 1018 Version 1.2"; 1020 container tls-versions { 1021 description 1022 "Parameters regarding TLS versions."; 1023 leaf-list tls-version { 1024 type identityref { 1025 base tls-version-base; 1026 } 1027 description 1028 "Acceptable TLS protocol versions. 1030 If this leaf-list is not configured (has zero elements) 1031 the acceptable TLS protocol versions are implementation- 1032 defined."; 1033 } 1034 } 1035 container cipher-suites { 1036 description 1037 "Parameters regarding cipher suites."; 1038 leaf-list cipher-suite { 1039 type identityref { 1040 base cipher-suite-base; 1041 } 1042 ordered-by user; 1043 description 1044 "Acceptable cipher suites in order of descending 1045 preference. 1047 If this leaf-list is not configured (has zero elements) 1048 the acceptable cipher suites are implementation- 1050 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1052 defined."; 1053 } 1054 } 1056 } // end hello-params-grouping 1058 } 1059 1061 5. Security Considerations 1063 The YANG modules defined in this document are designed to be accessed 1064 via YANG based management protocols, such as NETCONF [RFC6241] and 1065 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1066 implement secure transport layers (e.g., SSH, TLS) with mutual 1067 authentication. 1069 The NETCONF access control model (NACM) [RFC6536] provides the means 1070 to restrict access for particular users to a pre-configured subset of 1071 all available protocol operations and content. 1073 Since the modules defined in this document only define groupings, 1074 these considerations are primarily for the designers of other modules 1075 that use these groupings. 1077 There are a number of data nodes defined in the YANG modules that are 1078 writable/creatable/deletable (i.e., config true, which is the 1079 default). These data nodes may be considered sensitive or vulnerable 1080 in some network environments. Write operations (e.g., edit-config) 1081 to these data nodes without proper protection can have a negative 1082 effect on network operations. These are the subtrees and data nodes 1083 and their sensitivity/vulnerability: 1085 /: The entire data tree of all the groupings defined in this draft 1086 is sensitive to write operations. For instance, the addition 1087 or removal of references to keys, certificates, trusted 1088 anchors, etc., can dramatically alter the implemented security 1089 policy. However, no NACM annotations are applied as the data 1090 SHOULD be editable by users other than a designated 'recovery 1091 session'. 1093 Some of the readable data nodes in the YANG modules may be considered 1094 sensitive or vulnerable in some network environments. It is thus 1095 important to control read access (e.g., via get, get-config, or 1096 notification) to these data nodes. These are the subtrees and data 1097 nodes and their sensitivity/vulnerability: 1099 NONE 1101 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1103 Some of the RPC operations in this YANG module may be considered 1104 sensitive or vulnerable in some network environments. It is thus 1105 important to control access to these operations. These are the 1106 operations and their sensitivity/vulnerability: 1108 NONE 1110 6. IANA Considerations 1112 6.1. The IETF XML Registry 1114 This document registers three URIs in the IETF XML registry 1115 [RFC3688]. Following the format in [RFC3688], the following 1116 registrations are requested: 1118 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 1119 Registrant Contact: The NETCONF WG of the IETF. 1120 XML: N/A, the requested URI is an XML namespace. 1122 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 1123 Registrant Contact: The NETCONF WG of the IETF. 1124 XML: N/A, the requested URI is an XML namespace. 1126 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common 1127 Registrant Contact: The NETCONF WG of the IETF. 1128 XML: N/A, the requested URI is an XML namespace. 1130 6.2. The YANG Module Names Registry 1132 This document registers three YANG modules in the YANG Module Names 1133 registry [RFC7950]. Following the format in [RFC7950], the the 1134 following registrations are requested: 1136 name: ietf-tls-client 1137 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 1138 prefix: tlsc 1139 reference: RFC XXXX 1141 name: ietf-tls-server 1142 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 1143 prefix: tlss 1144 reference: RFC XXXX 1146 name: ietf-tls-common 1147 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common 1148 prefix: tlscmn 1149 reference: RFC XXXX 1151 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1153 7. Acknowledgements 1155 The authors would like to thank for following for lively discussions 1156 on list and in the halls (ordered by last name): Andy Bierman, Martin 1157 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 1158 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, 1159 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. 1161 8. References 1163 8.1. Normative References 1165 [I-D.ietf-netconf-keystore] 1166 Watsen, K., "Keystore Model", draft-ietf-netconf- 1167 keystore-02 (work in progress), June 2017. 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, 1171 DOI 10.17487/RFC2119, March 1997, 1172 . 1174 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1175 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1176 . 1178 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1179 (TLS) Protocol Version 1.1", RFC 4346, 1180 DOI 10.17487/RFC4346, April 2006, 1181 . 1183 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1184 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1185 for Transport Layer Security (TLS)", RFC 4492, 1186 DOI 10.17487/RFC4492, May 2006, 1187 . 1189 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1190 (TLS) Protocol Version 1.2", RFC 5246, 1191 DOI 10.17487/RFC5246, August 2008, 1192 . 1194 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1195 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1196 DOI 10.17487/RFC5288, August 2008, 1197 . 1199 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1201 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 1202 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 1203 DOI 10.17487/RFC5289, August 2008, 1204 . 1206 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1207 Protocol (NETCONF) Access Control Model", RFC 6536, 1208 DOI 10.17487/RFC6536, March 2012, 1209 . 1211 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1212 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1213 . 1215 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1216 NETCONF Protocol over Transport Layer Security (TLS) with 1217 Mutual X.509 Authentication", RFC 7589, 1218 DOI 10.17487/RFC7589, June 2015, 1219 . 1221 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1222 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1223 . 1225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1227 May 2017, . 1229 8.2. Informative References 1231 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1232 DOI 10.17487/RFC2818, May 2000, 1233 . 1235 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1236 DOI 10.17487/RFC3688, January 2004, 1237 . 1239 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1240 and A. Bierman, Ed., "Network Configuration Protocol 1241 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1242 . 1244 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1245 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1246 . 1248 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1250 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1251 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1252 . 1254 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1256 Appendix A. Change Log 1258 A.1. server-model-09 to 00 1260 o This draft was split out from draft-ietf-netconf-server-model-09. 1262 o Noted that '0.0.0.0' and '::' might have special meanings. 1264 A.2. 00 to 01 1266 o Renamed "keychain" to "keystore". 1268 A.3. 01 to 02 1270 o Removed the groupings containing transport-level configuration. 1271 Now modules contain only the transport-independent groupings. 1273 o Filled in previously incomplete 'ietf-tls-client' module. 1275 o Added cipher suites for various algorithms into new 'ietf-tls- 1276 common' module. 1278 A.4. 02 to 03 1280 o Added a 'must' statement to container 'server-auth' asserting that 1281 at least one of the various auth mechanisms must be specified. 1283 o Fixed description statement for leaf 'trusted-ca-certs'. 1285 A.5. 03 to 04 1287 o Updated title to "YANG Groupings for TLS Clients and TLS Servers" 1289 o Updated leafref paths to point to new keystore path 1291 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to 1292 'tlscmn'. 1294 o Added TLS protocol verions 1.0 and 1.1. 1296 o Made author lists consistent 1298 Authors' Addresses 1300 Kent Watsen 1301 Juniper Networks 1303 EMail: kwatsen@juniper.net 1305 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1307 Gary Wu 1308 Cisco Systems 1310 EMail: garywu@cisco.com