idnits 2.17.1 draft-ietf-netconf-tls-client-server-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 181 has weird spacing: '...gorithm ide...' == Line 191 has weird spacing: '...request bin...' == Line 407 has weird spacing: '...gorithm ide...' == Line 417 has weird spacing: '...request bin...' -- The document date (October 30, 2017) is 2363 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) == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 7 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: May 3, 2018 Cisco Systems 6 October 30, 2017 8 YANG Groupings for TLS Clients and TLS Servers 9 draft-ietf-netconf-tls-client-server-05 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-30" --> 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 May 3, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 87 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 88 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 89 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 90 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 91 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 9 92 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9 93 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10 94 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 95 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 14 96 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 14 97 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 14 98 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15 100 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 104 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24 105 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 25 106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 109 9.2. Informative References . . . . . . . . . . . . . . . . . 27 110 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 111 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28 112 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 28 113 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 28 114 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 28 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 117 1. Introduction 119 This document defines three YANG [RFC7950] modules: the first defines 120 a grouping for a generic TLS client, the second defines a grouping 121 for a generic TLS server, and the third defines identities and 122 groupings common to both the client and the server (TLS is defined in 123 [RFC5246]). It is intended that these groupings will be used by 124 applications using the TLS protocol. For instance, these groupings 125 could be used to help define the data model for an HTTPS [RFC2818] 126 server or a NETCONF over TLS [RFC7589] based server. 128 The client and server YANG modules in this document each define one 129 grouping, which is focused on just TLS-specific configuration, and 130 specifically avoids any transport-level configuration, such as what 131 ports to listen-on or connect-to. This enables applications the 132 opportunity to define their own strategy for how the underlying TCP 133 connection is established. For instance, applications supporting 134 NETCONF Call Home [RFC8071] could use the grouping for the TLS parts 135 it provides, while adding data nodes for the TCP-level call-home 136 configuration. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 148 3. The TLS Client Model 150 The TLS client model presented in this section contains one YANG 151 grouping, to just configure the TLS client, omitting, for instance, 152 any configuration for which IP address or port the client should 153 connect to. 155 This grouping references data nodes defined by the keystore model 156 [I-D.ietf-netconf-keystore]. For instance, a reference to the 157 keystore model is made to indicate which trusted CA certificate a 158 client should use to authenticate the server's certificate. 160 3.1. Tree Diagram 162 The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] 163 provides an overview of the data model for the "ietf-tls-client" 164 module. 166 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 168 module: ietf-tls-client 170 grouping tls-client-grouping 171 +---- client-identity 172 | +---- (auth-type)? 173 | +--:(certificate) 174 | +---- certificate 175 | +---- algorithm? 176 | | identityref 177 | +---- private-key? union 178 | +---- public-key? binary 179 | +---x generate-private-key 180 | | +---w input 181 | | +---w algorithm identityref 182 | +---- certificates 183 | | +---- certificate* [name] 184 | | +---- name? string 185 | | +---- value? binary 186 | +---x generate-certificate-signing-request 187 | +---w input 188 | | +---w subject binary 189 | | +---w attributes? binary 190 | +--ro output 191 | +--ro certificate-signing-request binary 192 +---- server-auth 193 | +---- pinned-ca-certs? ks:pinned-certificates 194 | +---- pinned-server-certs? ks:pinned-certificates 195 +---- hello-params {tls-client-hello-params-config}? 196 +---- tls-versions 197 | +---- tls-version* identityref 198 +---- cipher-suites 199 +---- cipher-suite* identityref 201 3.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 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 209 [ note: '\' line wrapping for formatting only] 211 212 214 215 216 217 ks:secp521r1 219 base64encodedvalue== 220 base64encodedvalue== 221 222 223 domain certificate 224 base64encodedvalue== 225 226 227 228 230 231 232 deployment-specific-ca-certs 233 explicitly-trusted-client-certs 235 237 239 3.3. YANG Module 241 This YANG module has a normative references to [RFC6991] and 242 [I-D.ietf-netconf-keystore]. 244 file "ietf-tls-client@2017-10-30.yang" 245 module ietf-tls-client { 246 yang-version 1.1; 248 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 249 prefix "tlsc"; 251 import ietf-tls-common { 252 prefix tlscmn; 253 revision-date 2017-10-30; // stable grouping definitions 254 reference 255 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 256 } 258 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 260 import ietf-keystore { 261 prefix ks; 262 reference 263 "RFC YYYY: Keystore Model"; 264 } 266 organization 267 "IETF NETCONF (Network Configuration) Working Group"; 269 contact 270 "WG Web: 271 WG List: 273 Author: Kent Watsen 274 276 Author: Gary Wu 277 "; 279 description 280 "This module defines a reusable grouping for a TLS client that 281 can be used as a basis for specific TLS client instances. 283 Copyright (c) 2017 IETF Trust and the persons identified as 284 authors of the code. All rights reserved. 286 Redistribution and use in source and binary forms, with or 287 without modification, is permitted pursuant to, and subject 288 to the license terms contained in, the Simplified BSD 289 License set forth in Section 4.c of the IETF Trust's 290 Legal Provisions Relating to IETF Documents 291 (http://trustee.ietf.org/license-info). 293 This version of this YANG module is part of RFC XXXX; see 294 the RFC itself for full legal notices."; 296 revision "2017-10-30" { 297 description 298 "Initial version"; 299 reference 300 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 301 } 303 // features 305 feature tls-client-hello-params-config { 306 description 308 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 310 "TLS hello message parameters are configurable on a TLS 311 client."; 312 } 314 // groupings 316 grouping tls-client-grouping { 317 description 318 "A reusable grouping for configuring a TLS client without 319 any consideration for how an underlying TCP session is 320 established."; 322 container client-identity { 323 description 324 "The credentials used by the client to authenticate to 325 the TLS server."; 327 choice auth-type { 328 description 329 "The authentication type."; 330 container certificate { 331 uses ks:private-key-grouping; 332 uses ks:certificate-grouping; 333 description 334 "Choice statement for future augmentations."; 335 } 336 } 337 } 339 container server-auth { 340 must 'pinned-ca-certs or pinned-server-certs'; 341 description 342 "Trusted server identities."; 343 leaf pinned-ca-certs { 344 type ks:pinned-certificates; 345 description 346 "A reference to a list of certificate authority (CA) 347 certificates used by the TLS client to authenticate 348 TLS server certificates. A server certificate is 349 authenticated if it has a valid chain of trust to 350 a configured pinned CA certificate."; 351 } 353 leaf pinned-server-certs { 354 type ks:pinned-certificates; 355 description 356 "A reference to a list of server certificates used by 357 the TLS client to authenticate TLS server certificates. 359 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 361 A server certificate is authenticated if it is an 362 exact match to a configured pinned server certificate."; 363 } 364 } 366 container hello-params { 367 if-feature tls-client-hello-params-config; 368 uses tlscmn:hello-params-grouping; 369 description 370 "Configurable parameters for the TLS hello message."; 371 } 373 } // end tls-client-grouping 375 } 376 378 4. The TLS Server Model 380 The TLS server model presented in this section contains one YANG 381 grouping, for just the TLS-level configuration, omitting, for 382 instance, configuration for which ports to open to listen for 383 connections on. 385 This grouping references data nodes defined by the keystore model 386 [I-D.ietf-netconf-keystore]. For instance, a reference to the 387 keystore model is made to indicate which certificate a server should 388 present. 390 4.1. Tree Diagram 392 The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] 393 provides an overview of the data model for the "ietf-tls-server" 394 module. 396 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 398 module: ietf-tls-server 400 grouping tls-server-grouping 401 +---- server-identity 402 | +---- algorithm? identityref 403 | +---- private-key? union 404 | +---- public-key? binary 405 | +---x generate-private-key 406 | | +---w input 407 | | +---w algorithm identityref 408 | +---- certificates 409 | | +---- certificate* [name] 410 | | +---- name? string 411 | | +---- value? binary 412 | +---x generate-certificate-signing-request 413 | +---w input 414 | | +---w subject binary 415 | | +---w attributes? binary 416 | +--ro output 417 | +--ro certificate-signing-request binary 418 +---- client-auth 419 | +---- pinned-ca-certs? ks:pinned-certificates 420 | +---- pinned-client-certs? ks:pinned-certificates 421 +---- hello-params {tls-server-hello-params-config}? 422 +---- tls-versions 423 | +---- tls-version* identityref 424 +---- cipher-suites 425 +---- cipher-suite* identityref 427 4.2. Example Usage 429 This section shows how it would appear if the tls-server-grouping 430 were populated with some data. This example is consistent with the 431 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. 433 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 435 [ note: '\' line wrapping for formatting only] 437 439 440 441 k\ 442 s:secp521r1 443 base64encodedvalue== 444 base64encodedvalue== 445 446 447 domain certificate 448 base64encodedvalue== 449 450 451 453 454 455 deployment-specific-ca-certs 456 explicitly-trusted-client-certs 458 460 462 4.3. YANG Module 464 This YANG module has a normative references to [RFC6991], and 465 [I-D.ietf-netconf-keystore]. 467 file "ietf-tls-server@2017-10-30.yang" 468 module ietf-tls-server { 469 yang-version 1.1; 471 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 472 prefix "tlss"; 474 import ietf-tls-common { 475 prefix tlscmn; 476 revision-date 2017-10-30; // stable grouping definitions 477 reference 478 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 479 } 481 import ietf-keystore { 482 prefix ks; 484 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 486 reference 487 "RFC YYYY: Keystore Model"; 488 } 490 organization 491 "IETF NETCONF (Network Configuration) Working Group"; 493 contact 494 "WG Web: 495 WG List: 497 Author: Kent Watsen 498 500 Author: Gary Wu 501 "; 503 description 504 "This module defines a reusable grouping for a TLS server that 505 can be used as a basis for specific TLS server instances. 507 Copyright (c) 2017 IETF Trust and the persons identified as 508 authors of the code. All rights reserved. 510 Redistribution and use in source and binary forms, with or 511 without modification, is permitted pursuant to, and subject 512 to the license terms contained in, the Simplified BSD 513 License set forth in Section 4.c of the IETF Trust's 514 Legal Provisions Relating to IETF Documents 515 (http://trustee.ietf.org/license-info). 517 This version of this YANG module is part of RFC XXXX; see 518 the RFC itself for full legal notices."; 520 revision "2017-10-30" { 521 description 522 "Initial version"; 523 reference 524 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 525 } 527 // features 529 feature tls-server-hello-params-config { 530 description 531 "TLS hello message parameters are configurable on a TLS 532 server."; 534 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 536 } 538 // groupings 540 grouping tls-server-grouping { 541 description 542 "A reusable grouping for configuring a TLS server without 543 any consideration for how underlying TCP sessions are 544 established."; 546 container server-identity { 547 description 548 "The list of certificates the TLS server will present when 549 establishing a TLS connection in its Certificate message, 550 as defined in Section 7.4.2 in RFC 5246."; 551 reference 552 "RFC 5246: 553 The Transport Layer Security (TLS) Protocol Version 1.2"; 554 uses ks:private-key-grouping; 555 uses ks:certificate-grouping; 556 } 558 container client-auth { 559 description 560 "A reference to a list of pinned certificate authority (CA) 561 certificates and a reference to a list of pinned client 562 certificates."; 563 leaf pinned-ca-certs { 564 type ks:pinned-certificates; 565 description 566 "A reference to a list of certificate authority (CA) 567 certificates used by the TLS server to authenticate 568 TLS client certificates. A client certificate is 569 authenticated if it has a valid chain of trust to 570 a configured pinned CA certificate."; 571 } 572 leaf pinned-client-certs { 573 type ks:pinned-certificates; 574 description 575 "A reference to a list of client certificates used by 576 the TLS server to authenticate TLS client certificates. 577 A clients certificate is authenticated if it is an 578 exact match to a configured pinned client certificate."; 579 } 580 } 582 container hello-params { 584 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 586 if-feature tls-server-hello-params-config; 587 uses tlscmn:hello-params-grouping; 588 description 589 "Configurable parameters for the TLS hello message."; 590 } 592 } // end tls-server-grouping 594 } 595 597 5. The TLS Common Model 599 The TLS common model presented in this section contains identities 600 and groupings common to both TLS clients and TLS servers. The hello- 601 params-grouping can be used to configure the list of TLS algorithms 602 permitted by the TLS client or TLS server. The lists of algorithms 603 are ordered such that, if multiple algorithms are permitted by the 604 client, the algorithm that appears first in its list that is also 605 permitted by the server is used for the TLS transport layer 606 connection. The ability to restrict the the algorithms allowed is 607 provided in this grouping for TLS clients and TLS servers that are 608 capable of doing so and may serve to make TLS clients and TLS servers 609 compliant with security policies. 611 Features are defined for algorithms that are OPTIONAL or are not 612 widely supported by popular implementations. Note that the list of 613 algorithms is not exhaustive. 615 5.1. Tree Diagram 617 The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] 618 provides an overview of the data model for the "ietf-tls-common" 619 module. 621 module: ietf-tls-common 623 grouping hello-params-grouping 624 +---- tls-versions 625 | +---- tls-version* identityref 626 +---- cipher-suites 627 +---- cipher-suite* identityref 629 5.2. Example Usage 631 This section shows how it would appear if the transport-params- 632 grouping were populated with some data. 634 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 636 637 640 641 tlscmn:tls-1.1 642 tlscmn:tls-1.2 643 644 645 tlscmn:dhe-rsa-with-aes-128-cbc-sha 646 tlscmn:rsa-with-aes-128-cbc-sha 647 tlscmn:rsa-with-3des-ede-cbc-sha 648 649 651 5.3. YANG Module 653 This YANG module has a normative references to [RFC2246], [RFC4346], 654 [RFC4492], [RFC5246], [RFC5288], and [RFC5289]. 656 file "ietf-tls-common@2017-10-30.yang" 657 module ietf-tls-common { 658 yang-version 1.1; 660 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; 661 prefix "tlscmn"; 663 organization 664 "IETF NETCONF (Network Configuration) Working Group"; 666 contact 667 "WG Web: 668 WG List: 670 Author: Kent Watsen 671 673 Author: Gary Wu 674 "; 676 description 677 "This module defines a common features, identities, and groupings 678 for Transport Layer Security (TLS). 680 Copyright (c) 2017 IETF Trust and the persons identified as 681 authors of the code. All rights reserved. 683 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 685 Redistribution and use in source and binary forms, with or 686 without modification, is permitted pursuant to, and subject 687 to the license terms contained in, the Simplified BSD 688 License set forth in Section 4.c of the IETF Trust's 689 Legal Provisions Relating to IETF Documents 690 (http://trustee.ietf.org/license-info). 692 This version of this YANG module is part of RFC XXXX; see 693 the RFC itself for full legal notices."; 695 revision "2017-10-30" { 696 description 697 "Initial version"; 698 reference 699 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 700 } 702 // features 704 feature tls-1_0 { 705 description 706 "TLS Protocol Version 1.0 is supported."; 707 reference 708 "RFC 2246: The TLS Protocol Version 1.0"; 709 } 711 feature tls-1_1 { 712 description 713 "TLS Protocol Version 1.1 is supported."; 714 reference 715 "RFC 4346: The Transport Layer Security (TLS) Protocol 716 Version 1.1"; 717 } 719 feature tls-1_2 { 720 description 721 "TLS Protocol Version 1.2 is supported."; 722 reference 723 "RFC 5246: The Transport Layer Security (TLS) Protocol 724 Version 1.2"; 725 } 727 feature tls-ecc { 728 description 729 "Elliptic Curve Cryptography (ECC) is supported for TLS."; 730 reference 731 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 732 for Transport Layer Security (TLS)"; 734 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 736 } 738 feature tls-dhe { 739 description 740 "Ephemeral Diffie-Hellman key exchange is supported for TLS."; 741 reference 742 "RFC 5246: The Transport Layer Security (TLS) Protocol 743 Version 1.2"; 744 } 746 feature tls-3des { 747 description 748 "The Triple-DES block cipher is supported for TLS."; 749 reference 750 "RFC 5246: The Transport Layer Security (TLS) Protocol 751 Version 1.2"; 752 } 754 feature tls-gcm { 755 description 756 "The Galois/Counter Mode authenticated encryption mode is 757 supported for TLS."; 758 reference 759 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for 760 TLS"; 761 } 763 feature tls-sha2 { 764 description 765 "The SHA2 family of cryptographic hash functions is supported 766 for TLS."; 767 reference 768 "FIPS PUB 180-4: Secure Hash Standard (SHS)"; 769 } 771 // identities 773 identity tls-version-base { 774 description 775 "Base identity used to identify TLS protocol versions."; 776 } 778 identity tls-1.0 { 779 base tls-version-base; 780 if-feature tls-1_0; 781 description 782 "TLS Protocol Version 1.0."; 783 reference 785 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 787 "RFC 2246: The TLS Protocol Version 1.0"; 788 } 790 identity tls-1.1 { 791 base tls-version-base; 792 if-feature tls-1_1; 793 description 794 "TLS Protocol Version 1.1."; 795 reference 796 "RFC 4346: The Transport Layer Security (TLS) Protocol 797 Version 1.1"; 798 } 800 identity tls-1.2 { 801 base tls-version-base; 802 if-feature tls-1_2; 803 description 804 "TLS Protocol Version 1.2."; 805 reference 806 "RFC 5246: The Transport Layer Security (TLS) Protocol 807 Version 1.2"; 808 } 810 identity cipher-suite-base { 811 description 812 "Base identity used to identify TLS cipher suites."; 813 } 815 identity rsa-with-aes-128-cbc-sha { 816 base cipher-suite-base; 817 description 818 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA."; 819 reference 820 "RFC 5246: The Transport Layer Security (TLS) Protocol 821 Version 1.2"; 822 } 824 identity rsa-with-aes-256-cbc-sha { 825 base cipher-suite-base; 826 description 827 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; 828 reference 829 "RFC 5246: The Transport Layer Security (TLS) Protocol 830 Version 1.2"; 831 } 833 identity rsa-with-aes-128-cbc-sha256 { 834 base cipher-suite-base; 836 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 838 if-feature tls-sha2; 839 description 840 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; 841 reference 842 "RFC 5246: The Transport Layer Security (TLS) Protocol 843 Version 1.2"; 844 } 846 identity rsa-with-aes-256-cbc-sha256 { 847 base cipher-suite-base; 848 if-feature tls-sha2; 849 description 850 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256."; 851 reference 852 "RFC 5246: The Transport Layer Security (TLS) Protocol 853 Version 1.2"; 854 } 856 identity dhe-rsa-with-aes-128-cbc-sha { 857 base cipher-suite-base; 858 if-feature tls-dhe; 859 description 860 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA."; 861 reference 862 "RFC 5246: The Transport Layer Security (TLS) Protocol 863 Version 1.2"; 864 } 866 identity dhe-rsa-with-aes-256-cbc-sha { 867 base cipher-suite-base; 868 if-feature tls-dhe; 869 description 870 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA."; 871 reference 872 "RFC 5246: The Transport Layer Security (TLS) Protocol 873 Version 1.2"; 874 } 876 identity dhe-rsa-with-aes-128-cbc-sha256 { 877 base cipher-suite-base; 878 if-feature "tls-dhe and tls-sha2"; 879 description 880 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; 881 reference 882 "RFC 5246: The Transport Layer Security (TLS) Protocol 883 Version 1.2"; 884 } 886 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 888 identity dhe-rsa-with-aes-256-cbc-sha256 { 889 base cipher-suite-base; 890 if-feature "tls-dhe and tls-sha2"; 891 description 892 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; 893 reference 894 "RFC 5246: The Transport Layer Security (TLS) Protocol 895 Version 1.2"; 896 } 898 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 { 899 base cipher-suite-base; 900 if-feature "tls-ecc and tls-sha2"; 901 description 902 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256."; 903 reference 904 "RFC 5289: TLS Elliptic Curve Cipher Suites with 905 SHA-256/384 and AES Galois Counter Mode (GCM)"; 906 } 908 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 { 909 base cipher-suite-base; 910 if-feature "tls-ecc and tls-sha2"; 911 description 912 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384."; 913 reference 914 "RFC 5289: TLS Elliptic Curve Cipher Suites with 915 SHA-256/384 and AES Galois Counter Mode (GCM)"; 916 } 918 identity ecdhe-rsa-with-aes-128-cbc-sha256 { 919 base cipher-suite-base; 920 if-feature "tls-ecc and tls-sha2"; 921 description 922 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256."; 923 reference 924 "RFC 5289: TLS Elliptic Curve Cipher Suites with 925 SHA-256/384 and AES Galois Counter Mode (GCM)"; 926 } 928 identity ecdhe-rsa-with-aes-256-cbc-sha384 { 929 base cipher-suite-base; 930 if-feature "tls-ecc and tls-sha2"; 931 description 932 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; 933 reference 934 "RFC 5289: TLS Elliptic Curve Cipher Suites with 935 SHA-256/384 and AES Galois Counter Mode (GCM)"; 937 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 939 } 941 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { 942 base cipher-suite-base; 943 if-feature "tls-ecc and tls-gcm and tls-sha2"; 944 description 945 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; 946 reference 947 "RFC 5289: TLS Elliptic Curve Cipher Suites with 948 SHA-256/384 and AES Galois Counter Mode (GCM)"; 949 } 951 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 { 952 base cipher-suite-base; 953 if-feature "tls-ecc and tls-gcm and tls-sha2"; 954 description 955 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."; 956 reference 957 "RFC 5289: TLS Elliptic Curve Cipher Suites with 958 SHA-256/384 and AES Galois Counter Mode (GCM)"; 959 } 961 identity ecdhe-rsa-with-aes-128-gcm-sha256 { 962 base cipher-suite-base; 963 if-feature "tls-ecc and tls-gcm and tls-sha2"; 964 description 965 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256."; 966 reference 967 "RFC 5289: TLS Elliptic Curve Cipher Suites with 968 SHA-256/384 and AES Galois Counter Mode (GCM)"; 969 } 971 identity ecdhe-rsa-with-aes-256-gcm-sha384 { 972 base cipher-suite-base; 973 if-feature "tls-ecc and tls-gcm and tls-sha2"; 974 description 975 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384."; 976 reference 977 "RFC 5289: TLS Elliptic Curve Cipher Suites with 978 SHA-256/384 and AES Galois Counter Mode (GCM)"; 979 } 981 identity rsa-with-3des-ede-cbc-sha { 982 base cipher-suite-base; 983 if-feature tls-3des; 984 description 985 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; 986 reference 988 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 990 "RFC 5246: The Transport Layer Security (TLS) Protocol 991 Version 1.2"; 992 } 994 identity ecdhe-rsa-with-3des-ede-cbc-sha { 995 base cipher-suite-base; 996 if-feature "tls-ecc and tls-3des"; 997 description 998 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; 999 reference 1000 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 1001 for Transport Layer Security (TLS)"; 1002 } 1004 identity ecdhe-rsa-with-aes-128-cbc-sha { 1005 base cipher-suite-base; 1006 if-feature "tls-ecc"; 1007 description 1008 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA."; 1009 reference 1010 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 1011 for Transport Layer Security (TLS)"; 1012 } 1014 identity ecdhe-rsa-with-aes-256-cbc-sha { 1015 base cipher-suite-base; 1016 if-feature "tls-ecc"; 1017 description 1018 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA."; 1019 reference 1020 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites 1021 for Transport Layer Security (TLS)"; 1022 } 1024 // groupings 1026 grouping hello-params-grouping { 1027 description 1028 "A reusable grouping for TLS hello message parameters."; 1029 reference 1030 "RFC 5246: The Transport Layer Security (TLS) Protocol 1031 Version 1.2"; 1033 container tls-versions { 1034 description 1035 "Parameters regarding TLS versions."; 1036 leaf-list tls-version { 1037 type identityref { 1039 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1041 base tls-version-base; 1042 } 1043 description 1044 "Acceptable TLS protocol versions. 1046 If this leaf-list is not configured (has zero elements) 1047 the acceptable TLS protocol versions are implementation- 1048 defined."; 1049 } 1050 } 1051 container cipher-suites { 1052 description 1053 "Parameters regarding cipher suites."; 1054 leaf-list cipher-suite { 1055 type identityref { 1056 base cipher-suite-base; 1057 } 1058 ordered-by user; 1059 description 1060 "Acceptable cipher suites in order of descending 1061 preference. 1063 If this leaf-list is not configured (has zero elements) 1064 the acceptable cipher suites are implementation- 1065 defined."; 1066 } 1067 } 1069 } // end hello-params-grouping 1071 } 1072 1074 6. Security Considerations 1076 The YANG modules defined in this document are designed to be accessed 1077 via YANG based management protocols, such as NETCONF [RFC6241] and 1078 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1079 implement secure transport layers (e.g., SSH, TLS) with mutual 1080 authentication. 1082 The NETCONF access control model (NACM) [RFC6536] provides the means 1083 to restrict access for particular users to a pre-configured subset of 1084 all available protocol operations and content. 1086 Since the modules defined in this document only define groupings, 1087 these considerations are primarily for the designers of other modules 1088 that use these groupings. 1090 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1092 There are a number of data nodes defined in the YANG modules that are 1093 writable/creatable/deletable (i.e., config true, which is the 1094 default). These data nodes may be considered sensitive or vulnerable 1095 in some network environments. Write operations (e.g., edit-config) 1096 to these data nodes without proper protection can have a negative 1097 effect on network operations. These are the subtrees and data nodes 1098 and their sensitivity/vulnerability: 1100 /: The entire data tree of all the groupings defined in this draft 1101 is sensitive to write operations. For instance, the addition 1102 or removal of references to keys, certificates, trusted 1103 anchors, etc., can dramatically alter the implemented security 1104 policy. However, no NACM annotations are applied as the data 1105 SHOULD be editable by users other than a designated 'recovery 1106 session'. 1108 Some of the readable data nodes in the YANG modules may be considered 1109 sensitive or vulnerable in some network environments. It is thus 1110 important to control read access (e.g., via get, get-config, or 1111 notification) to these data nodes. These are the subtrees and data 1112 nodes and their sensitivity/vulnerability: 1114 NONE 1116 Some of the RPC operations in this YANG module may be considered 1117 sensitive or vulnerable in some network environments. It is thus 1118 important to control access to these operations. These are the 1119 operations and their sensitivity/vulnerability: 1121 NONE 1123 7. IANA Considerations 1125 7.1. The IETF XML Registry 1127 This document registers three URIs in the IETF XML registry 1128 [RFC3688]. Following the format in [RFC3688], the following 1129 registrations are requested: 1131 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1133 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 1134 Registrant Contact: The NETCONF WG of the IETF. 1135 XML: N/A, the requested URI is an XML namespace. 1137 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 1138 Registrant Contact: The NETCONF WG of the IETF. 1139 XML: N/A, the requested URI is an XML namespace. 1141 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common 1142 Registrant Contact: The NETCONF WG of the IETF. 1143 XML: N/A, the requested URI is an XML namespace. 1145 7.2. The YANG Module Names Registry 1147 This document registers three YANG modules in the YANG Module Names 1148 registry [RFC7950]. Following the format in [RFC7950], the the 1149 following registrations are requested: 1151 name: ietf-tls-client 1152 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 1153 prefix: tlsc 1154 reference: RFC XXXX 1156 name: ietf-tls-server 1157 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 1158 prefix: tlss 1159 reference: RFC XXXX 1161 name: ietf-tls-common 1162 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common 1163 prefix: tlscmn 1164 reference: RFC XXXX 1166 8. Acknowledgements 1168 The authors would like to thank for following for lively discussions 1169 on list and in the halls (ordered by last name): Andy Bierman, Martin 1170 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 1171 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, 1172 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. 1174 9. References 1176 9.1. Normative References 1178 [I-D.ietf-netconf-keystore] 1179 Watsen, K., "Keystore Model", draft-ietf-netconf- 1180 keystore-02 (work in progress), June 2017. 1182 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, 1186 DOI 10.17487/RFC2119, March 1997, 1187 . 1189 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1190 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1191 . 1193 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1194 (TLS) Protocol Version 1.1", RFC 4346, 1195 DOI 10.17487/RFC4346, April 2006, 1196 . 1198 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1199 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1200 for Transport Layer Security (TLS)", RFC 4492, 1201 DOI 10.17487/RFC4492, May 2006, 1202 . 1204 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1205 (TLS) Protocol Version 1.2", RFC 5246, 1206 DOI 10.17487/RFC5246, August 2008, 1207 . 1209 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1210 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1211 DOI 10.17487/RFC5288, August 2008, 1212 . 1214 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 1215 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 1216 DOI 10.17487/RFC5289, August 2008, 1217 . 1219 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1220 Protocol (NETCONF) Access Control Model", RFC 6536, 1221 DOI 10.17487/RFC6536, March 2012, 1222 . 1224 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1225 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1226 . 1228 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1230 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1231 NETCONF Protocol over Transport Layer Security (TLS) with 1232 Mutual X.509 Authentication", RFC 7589, 1233 DOI 10.17487/RFC7589, June 2015, 1234 . 1236 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1237 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1238 . 1240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1242 May 2017, . 1244 9.2. Informative References 1246 [I-D.ietf-netmod-yang-tree-diagrams] 1247 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1248 ietf-netmod-yang-tree-diagrams-02 (work in progress), 1249 October 2017. 1251 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1252 DOI 10.17487/RFC2818, May 2000, 1253 . 1255 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1256 DOI 10.17487/RFC3688, January 2004, 1257 . 1259 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1260 and A. Bierman, Ed., "Network Configuration Protocol 1261 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1262 . 1264 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1265 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1266 . 1268 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1269 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1270 . 1272 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1274 Appendix A. Change Log 1276 A.1. 00 to 01 1278 o Noted that '0.0.0.0' and '::' might have special meanings. 1280 o Renamed "keychain" to "keystore". 1282 A.2. 01 to 02 1284 o Removed the groupings containing transport-level configuration. 1285 Now modules contain only the transport-independent groupings. 1287 o Filled in previously incomplete 'ietf-tls-client' module. 1289 o Added cipher suites for various algorithms into new 'ietf-tls- 1290 common' module. 1292 A.3. 02 to 03 1294 o Added a 'must' statement to container 'server-auth' asserting that 1295 at least one of the various auth mechanisms must be specified. 1297 o Fixed description statement for leaf 'trusted-ca-certs'. 1299 A.4. 03 to 04 1301 o Updated title to "YANG Groupings for TLS Clients and TLS Servers" 1303 o Updated leafref paths to point to new keystore path 1305 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to 1306 'tlscmn'. 1308 o Added TLS protocol verions 1.0 and 1.1. 1310 o Made author lists consistent 1312 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1314 o Updated YANG to use typedefs around leafrefs to common keystore 1315 paths 1317 o Now inlines key and certificates (no longer a leafref to keystore) 1319 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 1321 Authors' Addresses 1323 Kent Watsen 1324 Juniper Networks 1326 EMail: kwatsen@juniper.net 1328 Gary Wu 1329 Cisco Systems 1331 EMail: garywu@cisco.com