idnits 2.17.1 draft-ietf-netconf-tls-client-server-02.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 8 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 2601 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-00 ** 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: 4 errors (**), 0 flaws (~~), 3 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: September 14, 2017 Cisco Systems 6 March 13, 2017 8 TLS Client and Server Models 9 draft-ietf-netconf-tls-client-server-02 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-03-13" --> the publication date of this draft 45 The following two Appendix sections are to be removed prior to 46 publication: 48 o Appendix A. Change Log 49 o Appendix B. Open Issues 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 http://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 September 14, 2017. 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 (http://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 99 4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 22 103 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 22 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 107 8.2. Informative References . . . . . . . . . . . . . . . . . 24 108 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 109 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 25 110 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 25 111 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 25 112 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 25 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 115 1. Introduction 117 This document defines three YANG [RFC7950] modules: the first defines 118 a grouping for a generic TLS client, the second defines a grouping 119 for a generic TLS server, and the third defines identities and 120 groupings common to both the client and the server (TLS is defined in 121 [RFC5246]). It is intended that these groupings will be used by 122 applications using the TLS protocol. For instance, these groupings 123 could be used to help define the data model for an HTTPS [RFC2818] 124 server or a NETCONF over TLS [RFC7589] based server. 126 The client and server YANG modules in this document each define one 127 grouping, which is focused on just TLS-specific configuration, and 128 specifically avoids any transport-level configuration, such as what 129 ports to listen-on or connect-to. This enables applications the 130 opportunity to define their own strategy for how the underlying TCP 131 connection is established. For instance, applications supporting 132 NETCONF Call Home [RFC8071] could use the grouping for the TLS parts 133 it provides, while adding data nodes for the TCP-level call-home 134 configuration. 136 1.1. Terminology 138 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 1.2. Tree Diagrams 144 A simplified graphical representation of the data models is used in 145 this document. The meaning of the symbols in these diagrams is as 146 follows: 148 o Brackets "[" and "]" enclose list keys. 150 o Braces "{" and "}" enclose feature names, and indicate that the 151 named feature must be present for the subtree to be present. 153 o Abbreviations before data node names: "rw" means configuration 154 (read-write) and "ro" state data (read-only). 156 o Symbols after data node names: "?" means an optional node, "!" 157 means a presence container, and "*" denotes a list and leaf-list. 159 o Parentheses enclose choice and case nodes, and case nodes are also 160 marked with a colon (":"). 162 o Ellipsis ("...") stands for contents of subtrees that are not 163 shown. 165 2. The TLS Client Model 167 The TLS client model presented in this section contains one YANG 168 grouping, to just configure the TLS client omitting, for instance, 169 any configuration for which IP address or port the client should 170 connect to. 172 This grouping references data nodes defined by the keystore model 173 [I-D.ietf-netconf-keystore]. For instance, a reference to the 174 keystore model is made to indicate which trusted CA certificate a 175 client should use to authenticate the server's certificate. 177 2.1. Tree Diagram 179 The following tree diagram presents the data model for the grouping 180 defined in the ietf-tls-client module. Please see Section 1.2 for 181 tree diagram notation. 183 module: ietf-tls-client 184 groupings: 185 tls-client-grouping 186 +---- server-auth 187 | +---- trusted-ca-certs? 188 | | -> /ks:keystore/trusted-certificates/name 189 | +---- trusted-server-certs? 190 | -> /ks:keystore/trusted-certificates/name 191 +---- client-auth 192 | +---- (auth-type)? 193 | +--:(certificate) 194 | +---- certificate? leafref 195 +---- hello-params {tls-client-hello-params-config}? 196 +---- tls-versions 197 | +---- tls-version* identityref 198 +---- cipher-suites 199 +---- cipher-suite* identityref 201 2.2. Example Usage 203 This section shows how it would appear if the tls-client-grouping 204 were populated with some data. This example is consistent with the 205 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. 207 208 210 211 212 deployment-specific-ca-certs 213 explicitly-trusted-client-certs 214 216 217 218 builtin-idevid-cert 219 221 223 2.3. YANG Model 225 This YANG module has a normative references to [RFC6991] and 226 [I-D.ietf-netconf-keystore]. 228 file "ietf-tls-client@2017-03-13.yang" 229 module ietf-tls-client { 230 yang-version 1.1; 232 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 233 prefix "tlsc"; 235 import ietf-tls-common { 236 prefix tlscom; 237 revision-date 2017-03-13; // stable grouping definitions 238 reference 239 "RFC XXXX: TLS Client and Server Models"; 240 } 242 import ietf-keystore { 243 prefix ks; 244 reference 245 "RFC YYYY: Keystore Model"; 246 } 248 organization 249 "IETF NETCONF (Network Configuration) Working Group"; 251 contact 252 "WG Web: 253 WG List: 255 Author: Kent Watsen 256 "; 258 description 259 "This module defines a reusable grouping for a TLS client that 260 can be used as a basis for specific TLS client instances. 262 Copyright (c) 2014 IETF Trust and the persons identified as 263 authors of the code. All rights reserved. 265 Redistribution and use in source and binary forms, with or 266 without modification, is permitted pursuant to, and subject 267 to the license terms contained in, the Simplified BSD 268 License set forth in Section 4.c of the IETF Trust's 269 Legal Provisions Relating to IETF Documents 270 (http://trustee.ietf.org/license-info). 272 This version of this YANG module is part of RFC XXXX; see 273 the RFC itself for full legal notices."; 275 revision "2017-03-13" { 276 description 277 "Initial version"; 278 reference 279 "RFC XXXX: TLS Client and Server Models"; 280 } 282 feature tls-client-hello-params-config { 283 description 284 "TLS hello message parameters are configurable on a TLS 285 client."; 286 } 288 grouping tls-client-grouping { 289 description 290 "A reusable grouping for configuring a TLS client without 291 any consideration for how an underlying TCP session is 292 established."; 294 container server-auth { 295 description 296 "Trusted server identities."; 298 leaf trusted-ca-certs { 299 type leafref { 300 path "/ks:keystore/ks:trusted-certificates/ks:name"; 301 } 302 description 303 "A reference to a list of certificate authority (CA) 304 certificates used by the TLS client to authenticate 305 TLS server certificates."; 306 } 308 leaf trusted-server-certs { 309 type leafref { 310 path "/ks:keystore/ks:trusted-certificates/ks:name"; 311 } 312 description 313 "A reference to a list of server certificates used by 314 the TLS client to authenticate TLS server certificates. 315 A server certificate is authenticated if it is an 316 exact match to a configured trusted server certificate."; 317 } 318 } 320 container client-auth { 321 description 322 "The credentials used by the client to authenticate to 323 the TLS server."; 325 choice auth-type { 326 description 327 "The authentication type."; 328 leaf certificate { 329 type leafref { 330 path "/ks:keystore/ks:keys/ks:key/ks:certificates" 331 + "/ks:certificate/ks:name"; 332 } 333 description 334 "A certificates to be used for user authentication."; 335 } 336 } 337 } 339 container hello-params { 340 if-feature tls-client-hello-params-config; 341 uses tlscom:hello-params-grouping; 342 description 343 "Configurable parameters for the TLS hello message."; 344 } 346 } // end tls-client-grouping 348 } 350 352 3. The TLS Server Model 354 The TLS server model presented in this section contains one YANG 355 grouping, for just the TLS-level configuration omitting, for 356 instance, configuration for which ports to open to listen for 357 connections on. 359 This grouping references data nodes defined by the keystore model 360 [I-D.ietf-netconf-keystore]. For instance, a reference to the 361 keystore model is made to indicate which certificate a server should 362 present. 364 3.1. Tree Diagram 366 The following tree diagram presents the data model for the grouping 367 defined in the ietf-tls-server module. Please see Section 1.2 for 368 tree diagram notation. 370 module: ietf-tls-server 371 groupings: 372 tls-server-grouping 373 +---- certificates 374 | +---- certificate* [name] 375 | +---- name? leafref 376 +---- client-auth 377 | +---- trusted-ca-certs? 378 | | -> /ks:keystore/trusted-certificates/name 379 | +---- trusted-client-certs? 380 | -> /ks:keystore/trusted-certificates/name 381 +---- hello-params {tls-server-hello-params-config}? 382 +---- tls-versions 383 | +---- tls-version* identityref 384 +---- cipher-suites 385 +---- cipher-suite* identityref 387 3.2. Example Usage 389 This section shows how it would appear if the tls-server-grouping 390 were populated with some data. This example is consistent with the 391 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. 393 395 397 398 399 tls-ec-cert 400 401 402 403 deployment-specific-ca-certs 404 explicitly-trusted-client-certs 405 406 408 3.3. YANG Model 410 This YANG module has a normative references to [RFC6991], and 411 [I-D.ietf-netconf-keystore]. 413 file "ietf-tls-server@2017-03-13.yang" 415 module ietf-tls-server { 416 yang-version 1.1; 418 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 419 prefix "tlss"; 421 import ietf-tls-common { 422 prefix tlscom; 423 revision-date 2017-03-13; // stable grouping definitions 424 reference 425 "RFC XXXX: TLS Client and Server Models"; 426 } 428 import ietf-keystore { 429 prefix ks; 430 reference 431 "RFC YYYY: Keystore Model"; 432 } 434 organization 435 "IETF NETCONF (Network Configuration) Working Group"; 437 contact 438 "WG Web: 439 WG List: 441 Author: Kent Watsen 442 "; 444 description 445 "This module defines a reusable grouping for a TLS server that 446 can be used as a basis for specific TLS server instances. 448 Copyright (c) 2014 IETF Trust and the persons identified as 449 authors of the code. All rights reserved. 451 Redistribution and use in source and binary forms, with or 452 without modification, is permitted pursuant to, and subject 453 to the license terms contained in, the Simplified BSD 454 License set forth in Section 4.c of the IETF Trust's 455 Legal Provisions Relating to IETF Documents 456 (http://trustee.ietf.org/license-info). 458 This version of this YANG module is part of RFC XXXX; see 459 the RFC itself for full legal notices."; 461 revision "2017-03-13" { 462 description 463 "Initial version"; 464 reference 465 "RFC XXXX: TLS Client and Server Models"; 466 } 468 feature tls-server-hello-params-config { 469 description 470 "TLS hello message parameters are configurable on a TLS 471 server."; 472 } 474 // grouping 475 grouping tls-server-grouping { 476 description 477 "A reusable grouping for configuring a TLS server without 478 any consideration for how underlying TCP sessions are 479 established."; 480 container certificates { 481 description 482 "The list of certificates the TLS server will present when 483 establishing a TLS connection in its Certificate message, 484 as defined in Section 7.4.2 in RRC 5246."; 485 reference 486 "RFC 5246: 487 The Transport Layer Security (TLS) Protocol Version 1.2"; 488 list certificate { 489 key name; 490 min-elements 1; 491 description 492 "An unordered list of certificates the TLS server can pick 493 from when sending its Server Certificate message."; 494 reference 495 "RFC 5246: The TLS Protocol, Section 7.4.2"; 496 leaf name { 497 type leafref { 498 path "/ks:keystore/ks:keys/ks:key/ks:certificates/" 499 + "ks:certificate/ks:name"; 500 } 501 description 502 "The name of the certificate in the keystore."; 503 } 504 } 505 } 507 container client-auth { 508 description 509 "A reference to a list of trusted certificate authority (CA) 510 certificates and a reference to a list of trusted client 511 certificates."; 512 leaf trusted-ca-certs { 513 type leafref { 514 path "/ks:keystore/ks:trusted-certificates/ks:name"; 515 } 516 description 517 "A reference to a list of certificate authority (CA) 518 certificates used by the TLS server to authenticate 519 TLS client certificates."; 520 } 522 leaf trusted-client-certs { 523 type leafref { 524 path "/ks:keystore/ks:trusted-certificates/ks:name"; 525 } 526 description 527 "A reference to a list of client certificates used by 528 the TLS server to authenticate TLS client certificates. 529 A clients certificate is authenticated if it is an 530 exact match to a configured trusted client certificate."; 531 } 532 } 534 container hello-params { 535 if-feature tls-server-hello-params-config; 536 uses tlscom:hello-params-grouping; 537 description 538 "Configurable parameters for the TLS hello message."; 539 } 541 } // end tls-server-grouping 543 } 545 547 4. The TLS Common Model 549 The TLS common model presented in this section contains identities 550 and groupings common to both TLS clients and TLS servers. The hello- 551 params-grouping can be used to configure the list of TLS algorithms 552 permitted by the TLS client or TLS server. The lists of algorithms 553 are ordered such that, if multiple algorithms are permitted by the 554 client, the algorithm that appears first in its list that is also 555 permitted by the server is used for the TLS transport layer 556 connection. The ability to restrict the the algorithms allowed is 557 provided in this grouping for TLS clients and TLS servers that are 558 capable of doing so and may serve to make TLS clients and TLS servers 559 compliant with security policies. 561 Features are defined for algorithms that are OPTIONAL or are not 562 widely supported by popular implementations. Note that the list of 563 algorithms is not exhaustive. 565 4.1. Tree Diagram 567 The following tree diagram presents the data model for the grouping 568 defined in the ietf-tls-common module. Please see Section 1.2 for 569 tree diagram notation. 571 module: ietf-tls-common 572 groupings: 573 hello-params-grouping 574 +---- tls-versions 575 | +---- tls-version* identityref 576 +---- cipher-suites 577 +---- cipher-suite* identityref 579 4.2. Example Usage 581 This section shows how it would appear if the transport-params- 582 grouping were populated with some data. 584 585 587 588 tls-1.2 589 590 591 ecdhe-rsa-with-3des-ede-cbc-sha 592 dhe-rsa-with-aes-128-cbc-sha 593 rsa-with-aes-128-cbc-sha 594 rsa-with-3des-ede-cbc-sha 595 597 599 4.3. YANG Model 601 This YANG module has a normative references to [RFC4492], [RFC5246], 602 [RFC5288], and [RFC5289]. 604 file "ietf-tls-common@2017-03-13.yang" 606 module ietf-tls-common { 607 yang-version 1.1; 609 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; 610 prefix "tlscom"; 612 organization 613 "IETF NETCONF (Network Configuration) Working Group"; 615 contact 616 "WG Web: 617 WG List: 619 Author: Kent Watsen 620 622 Author: Gary Wu 623 "; 625 description 626 "This module defines a common features, identities, and groupings 627 for Transport Layer Security (TLS). 629 Copyright (c) 2017 IETF Trust and the persons identified as 630 authors of the code. All rights reserved. 632 Redistribution and use in source and binary forms, with or 633 without modification, is permitted pursuant to, and subject 634 to the license terms contained in, the Simplified BSD 635 License set forth in Section 4.c of the IETF Trust's 636 Legal Provisions Relating to IETF Documents 637 (http://trustee.ietf.org/license-info). 639 This version of this YANG module is part of RFC XXXX; see 640 the RFC itself for full legal notices."; 642 revision "2017-03-13" { 643 description 644 "Initial version"; 645 reference 646 "RFC XXXX: TLS Client and Server Models"; 647 } 649 // features 650 feature tls-ecc { 651 description 652 "Elliptic Curve Cryptography (ECC) is supported for TLS."; 653 reference 654 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 655 for Transport Layer Security (TLS)"; 656 } 658 feature tls-dhe { 659 description 660 "Ephemeral Diffie-Hellman key exchange is supported for TLS."; 661 reference 662 "RFC 5246: The Transport Layer Security (TLS) Protocol 663 Version 1.2"; 664 } 666 feature tls-3des { 667 description 668 "The Triple-DES block cipher is supported for TLS."; 669 reference 670 "RFC 5246: The Transport Layer Security (TLS) Protocol 671 Version 1.2"; 672 } 674 feature tls-gcm { 675 description 676 "The Galois/Counter Mode authenticated encryption mode is 677 supported for TLS."; 678 reference 679 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS"; 680 } 682 feature tls-sha2 { 683 description 684 "The SHA2 family of cryptographic hash functions is supported 685 for TLS."; 686 reference 687 "FIPS PUB 180-4: Secure Hash Standard (SHS)"; 688 } 690 // identities 691 identity tls-version-base { 692 description 693 "Base identity used to identify TLS protocol versions."; 694 } 696 identity tls-1.2 { 697 base tls-version-base; 698 description 699 "TLS protocol version 1.2."; 700 reference 701 "RFC 5246: The Transport Layer Security (TLS) Protocol 702 Version 1.2"; 703 } 705 identity cipher-suite-base { 706 description 707 "Base identity used to identify TLS cipher suites."; 708 } 710 identity rsa-with-aes-128-cbc-sha { 711 base cipher-suite-base; 712 description 713 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA."; 714 reference 715 "RFC 5246: The Transport Layer Security (TLS) Protocol 716 Version 1.2"; 717 } 719 identity rsa-with-aes-256-cbc-sha { 720 base cipher-suite-base; 721 description 722 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; 723 reference 724 "RFC 5246: The Transport Layer Security (TLS) Protocol 725 Version 1.2"; 726 } 728 identity rsa-with-aes-128-cbc-sha256 { 729 base cipher-suite-base; 730 if-feature tls-sha2; 731 description 732 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; 733 reference 734 "RFC 5246: The Transport Layer Security (TLS) Protocol 735 Version 1.2"; 736 } 738 identity rsa-with-aes-256-cbc-sha256 { 739 base cipher-suite-base; 740 if-feature tls-sha2; 741 description 742 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256."; 743 reference 744 "RFC 5246: The Transport Layer Security (TLS) Protocol 745 Version 1.2"; 746 } 747 identity dhe-rsa-with-aes-128-cbc-sha { 748 base cipher-suite-base; 749 if-feature tls-dhe; 750 description 751 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA."; 752 reference 753 "RFC 5246: The Transport Layer Security (TLS) Protocol 754 Version 1.2"; 755 } 757 identity dhe-rsa-with-aes-256-cbc-sha { 758 base cipher-suite-base; 759 if-feature tls-dhe; 760 description 761 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA."; 762 reference 763 "RFC 5246: The Transport Layer Security (TLS) Protocol 764 Version 1.2"; 765 } 767 identity dhe-rsa-with-aes-128-cbc-sha256 { 768 base cipher-suite-base; 769 if-feature "tls-dhe and tls-sha2"; 770 description 771 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; 772 reference 773 "RFC 5246: The Transport Layer Security (TLS) Protocol 774 Version 1.2"; 775 } 777 identity dhe-rsa-with-aes-256-cbc-sha256 { 778 base cipher-suite-base; 779 if-feature "tls-dhe and tls-sha2"; 780 description 781 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; 782 reference 783 "RFC 5246: The Transport Layer Security (TLS) Protocol 784 Version 1.2"; 785 } 787 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 { 788 base cipher-suite-base; 789 if-feature "tls-ecc and tls-sha2"; 790 description 791 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256."; 792 reference 793 "RFC 5289: TLS Elliptic Curve Cipher Suites with 794 SHA-256/384 and AES Galois Counter Mode (GCM)"; 796 } 798 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 { 799 base cipher-suite-base; 800 if-feature "tls-ecc and tls-sha2"; 801 description 802 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384."; 803 reference 804 "RFC 5289: TLS Elliptic Curve Cipher Suites with 805 SHA-256/384 and AES Galois Counter Mode (GCM)"; 806 } 808 identity ecdhe-rsa-with-aes-128-cbc-sha256 { 809 base cipher-suite-base; 810 if-feature "tls-ecc and tls-sha2"; 811 description 812 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256."; 813 reference 814 "RFC 5289: TLS Elliptic Curve Cipher Suites with 815 SHA-256/384 and AES Galois Counter Mode (GCM)"; 816 } 818 identity ecdhe-rsa-with-aes-256-cbc-sha384 { 819 base cipher-suite-base; 820 if-feature "tls-ecc and tls-sha2"; 821 description 822 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; 823 reference 824 "RFC 5289: TLS Elliptic Curve Cipher Suites with 825 SHA-256/384 and AES Galois Counter Mode (GCM)"; 826 } 828 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { 829 base cipher-suite-base; 830 if-feature "tls-ecc and tls-gcm and tls-sha2"; 831 description 832 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; 833 reference 834 "RFC 5289: TLS Elliptic Curve Cipher Suites with 835 SHA-256/384 and AES Galois Counter Mode (GCM)"; 836 } 838 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 { 839 base cipher-suite-base; 840 if-feature "tls-ecc and tls-gcm and tls-sha2"; 841 description 842 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."; 843 reference 844 "RFC 5289: TLS Elliptic Curve Cipher Suites with 845 SHA-256/384 and AES Galois Counter Mode (GCM)"; 846 } 848 identity ecdhe-rsa-with-aes-128-gcm-sha256 { 849 base cipher-suite-base; 850 if-feature "tls-ecc and tls-gcm and tls-sha2"; 851 description 852 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256."; 853 reference 854 "RFC 5289: TLS Elliptic Curve Cipher Suites with 855 SHA-256/384 and AES Galois Counter Mode (GCM)"; 856 } 858 identity ecdhe-rsa-with-aes-256-gcm-sha384 { 859 base cipher-suite-base; 860 if-feature "tls-ecc and tls-gcm and tls-sha2"; 861 description 862 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384."; 863 reference 864 "RFC 5289: TLS Elliptic Curve Cipher Suites with 865 SHA-256/384 and AES Galois Counter Mode (GCM)"; 866 } 868 identity rsa-with-3des-ede-cbc-sha { 869 base cipher-suite-base; 870 if-feature tls-3des; 871 description 872 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; 873 reference 874 "RFC 5246: The Transport Layer Security (TLS) Protocol 875 Version 1.2"; 876 } 878 identity ecdhe-rsa-with-3des-ede-cbc-sha { 879 base cipher-suite-base; 880 if-feature "tls-ecc and tls-3des"; 881 description 882 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; 883 reference 884 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 885 for Transport Layer Security (TLS)"; 886 } 888 identity ecdhe-rsa-with-aes-128-cbc-sha { 889 base cipher-suite-base; 890 if-feature "tls-ecc"; 891 description 892 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA."; 893 reference 894 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 895 for Transport Layer Security (TLS)"; 896 } 898 identity ecdhe-rsa-with-aes-256-cbc-sha { 899 base cipher-suite-base; 900 if-feature "tls-ecc"; 901 description 902 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA."; 903 reference 904 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 905 for Transport Layer Security (TLS)"; 906 } 908 // groupings 909 grouping hello-params-grouping { 910 description 911 "A reusable grouping for TLS hello message parameters. For 912 configurable parameters, a zero-element leaf-list indicates the 913 system default configuration for that parameter."; 914 reference 915 "RFC 5246: The Transport Layer Security (TLS) Protocol 916 Version 1.2"; 917 container tls-versions { 918 description 919 "Parameters regarding TLS versions."; 920 leaf-list tls-version { 921 type identityref { 922 base tls-version-base; 923 } 924 description 925 "Allowed TLS protocol versions."; 926 } 927 } 928 container cipher-suites { 929 description 930 "Parameters regarding cipher suites."; 931 leaf-list cipher-suite { 932 type identityref { 933 base cipher-suite-base; 934 } 935 ordered-by user; 936 description 937 "Cipher suites in order of descending preference."; 938 } 939 } 941 } 942 } 944 946 5. Security Considerations 948 The YANG module defined in this document is designed to be accessed 949 via YANG based management protocols, such as NETCONF [RFC6241] and 950 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 951 implement secure transport layers (e.g., SSH, TLS) with mutual 952 authentication. 954 The NETCONF access control model (NACM) [RFC6536] provides the means 955 to restrict access for particular users to a pre-configured subset of 956 all available protocol operations and content. 958 There are a number of data nodes defined in this YANG module that are 959 writable/creatable/deletable (i.e., config true, which is the 960 default). These data nodes may be considered sensitive or vulnerable 961 in some network environments. Write operations (e.g., edit-config) 962 to these data nodes without proper protection can have a negative 963 effect on network operations. These are the subtrees and data nodes 964 and their sensitivity/vulnerability: 966 /: The entire data tree defined by this module is sensitive to 967 write operations. For instance, the addition or removal of 968 references to keys, certificates, trusted anchors, etc., can 969 dramatically alter the implemented security policy. However, 970 no NACM annotations are applied as the data SHOULD be editable 971 by users other than a designated 'recovery session'. 973 Some of the readable data nodes in this YANG module may be considered 974 sensitive or vulnerable in some network environments. It is thus 975 important to control read access (e.g., via get, get-config, or 976 notification) to these data nodes. These are the subtrees and data 977 nodes and their sensitivity/vulnerability: 979 NONE 981 Some of the RPC operations in this YANG module may be considered 982 sensitive or vulnerable in some network environments. It is thus 983 important to control access to these operations. These are the 984 operations and their sensitivity/vulnerability: 986 NONE 988 6. IANA Considerations 990 6.1. The IETF XML Registry 992 This document registers three URIs in the IETF XML registry 993 [RFC3688]. Following the format in [RFC3688], the following 994 registrations are requested: 996 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 997 Registrant Contact: The NETCONF WG of the IETF. 998 XML: N/A, the requested URI is an XML namespace. 1000 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 1001 Registrant Contact: The NETCONF WG of the IETF. 1002 XML: N/A, the requested URI is an XML namespace. 1004 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common 1005 Registrant Contact: The NETCONF WG of the IETF. 1006 XML: N/A, the requested URI is an XML namespace. 1008 6.2. The YANG Module Names Registry 1010 This document registers three YANG modules in the YANG Module Names 1011 registry [RFC7950]. Following the format in [RFC7950], the the 1012 following registrations are requested: 1014 name: ietf-tls-client 1015 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 1016 prefix: tlsc 1017 reference: RFC XXXX 1019 name: ietf-tls-server 1020 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 1021 prefix: tlss 1022 reference: RFC XXXX 1024 name: ietf-tls-common 1025 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common 1026 prefix: tlss 1027 reference: RFC XXXX 1029 7. Acknowledgements 1031 The authors would like to thank for following for lively discussions 1032 on list and in the halls (ordered by last name): Andy Bierman, Martin 1033 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 1034 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil 1035 Shafer, Sean Turner, and Bert Wijnen. 1037 8. References 1039 8.1. Normative References 1041 [I-D.ietf-netconf-keystore] 1042 Watsen, K. and G. Wu, "Keystore Model", draft-ietf- 1043 netconf-keystore-00 (work in progress), October 2016. 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, 1047 DOI 10.17487/RFC2119, March 1997, 1048 . 1050 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1051 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1052 for Transport Layer Security (TLS)", RFC 4492, 1053 DOI 10.17487/RFC4492, May 2006, 1054 . 1056 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1057 (TLS) Protocol Version 1.2", RFC 5246, 1058 DOI 10.17487/RFC5246, August 2008, 1059 . 1061 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1062 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1063 DOI 10.17487/RFC5288, August 2008, 1064 . 1066 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 1067 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 1068 DOI 10.17487/RFC5289, August 2008, 1069 . 1071 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1072 Protocol (NETCONF) Access Control Model", RFC 6536, 1073 DOI 10.17487/RFC6536, March 2012, 1074 . 1076 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1077 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1078 . 1080 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1081 NETCONF Protocol over Transport Layer Security (TLS) with 1082 Mutual X.509 Authentication", RFC 7589, 1083 DOI 10.17487/RFC7589, June 2015, 1084 . 1086 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1087 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1088 . 1090 8.2. Informative References 1092 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1093 DOI 10.17487/RFC2818, May 2000, 1094 . 1096 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1097 DOI 10.17487/RFC3688, January 2004, 1098 . 1100 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1101 and A. Bierman, Ed., "Network Configuration Protocol 1102 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1103 . 1105 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1106 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1107 . 1109 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1110 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1111 . 1113 Appendix A. Change Log 1115 A.1. server-model-09 to 00 1117 o This draft was split out from draft-ietf-netconf-server-model-09. 1119 o Noted that '0.0.0.0' and '::' might have special meanings. 1121 A.2. 00 to 01 1123 o Renamed "keychain" to "keystore". 1125 A.3. 01 to 02 1127 o Removed the groupings containing transport-level configuration. 1128 Now modules contain only the transport-independent groupings. 1130 o Filled in previously incomplete 'ietf-tls-client' module. 1132 o Added cipher suites for various algorithms into new 'ietf-tls- 1133 common' module. 1135 Appendix B. Open Issues 1137 Please see: https://github.com/netconf-wg/tls-client-server/issues. 1139 Authors' Addresses 1141 Kent Watsen 1142 Juniper Networks 1144 EMail: kwatsen@juniper.net 1146 Gary Wu 1147 Cisco Systems 1149 EMail: garywu@cisco.com