idnits 2.17.1 draft-ietf-netconf-tls-client-server-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-02 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-08 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-03 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track G. Wu 5 Expires: September 10, 2019 Cisco Systems 6 L. Xia 7 Huawei 8 March 9, 2019 10 YANG Groupings for TLS Clients and TLS Servers 11 draft-ietf-netconf-tls-client-server-09 13 Abstract 15 This document defines three YANG modules: the first defines groupings 16 for a generic TLS client, the second defines groupings for a generic 17 TLS server, and the third defines common identities and groupings 18 used by both the client and the server. It is intended that these 19 groupings will be used by applications using the TLS protocol. 21 Editorial Note (To be removed by RFC Editor) 23 This draft contains many placeholder values that need to be replaced 24 with finalized values at the time of publication. This note 25 summarizes all of the substitutions that are needed. No other RFC 26 Editor instructions are specified elsewhere in this document. 28 This document contains references to other drafts in progress, both 29 in the Normative References section, as well as in body text 30 throughout. Please update the following references to reflect their 31 final RFC assignments: 33 o I-D.ietf-netconf-trust-anchors 35 o I-D.ietf-netconf-keystore 37 Artwork in this document contains shorthand references to drafts in 38 progress. Please apply the following replacements: 40 o "XXXX" --> the assigned RFC value for this draft 42 o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust- 43 anchors 45 o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore 47 Artwork in this document contains placeholder values for the date of 48 publication of this draft. Please apply the following replacement: 50 o "2019-03-09" --> the publication date of this draft 52 The following Appendix section is to be removed prior to publication: 54 o Appendix A. Change Log 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at https://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on September 10, 2019. 73 Copyright Notice 75 Copyright (c) 2019 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (https://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 95 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 96 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10 97 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 98 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 99 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 100 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 17 101 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25 102 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 25 103 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 106 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 35 107 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 35 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 36 110 8.2. Informative References . . . . . . . . . . . . . . . . . 37 111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 39 112 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 39 113 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 39 114 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 39 115 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 39 116 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 40 117 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 40 118 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 40 119 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 40 120 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 40 121 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 124 1. Introduction 126 This document defines three YANG 1.1 [RFC7950] modules: the first 127 defines a grouping for a generic TLS client, the second defines a 128 grouping for a generic TLS server, and the third defines identities 129 and groupings common to both the client and the server (TLS is 130 defined in [RFC5246]). It is intended that these groupings will be 131 used by applications using the TLS protocol. For instance, these 132 groupings could be used to help define the data model for an HTTPS 133 [RFC2818] server or a NETCONF over TLS [RFC7589] based server. 135 The client and server YANG modules in this document each define one 136 grouping, which is focused on just TLS-specific configuration, and 137 specifically avoids any transport-level configuration, such as what 138 ports to listen-on or connect-to. This affords applications the 139 opportunity to define their own strategy for how the underlying TCP 140 connection is established. For instance, applications supporting 141 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping" 142 grouping for the TLS parts it provides, while adding data nodes for 143 the TCP-level call-home configuration. 145 The modules defined in this document use groupings defined in 146 [I-D.ietf-netconf-keystore] enabling keys to be either locally 147 defined or a reference to globally configured values. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. The TLS Client Model 159 3.1. Tree Diagram 161 This section provides a tree diagram [RFC8340] for the "ietf-tls- 162 client" module that does not have groupings expanded. 164 module: ietf-tls-client 166 grouping tls-client-grouping 167 +---u client-identity-grouping 168 +---u server-auth-grouping 169 +---u hello-params-grouping 170 +---u keepalives-grouping 171 grouping client-identity-grouping 172 +-- tls-client-identity 173 +-- (auth-type)? 174 +--:(certificate) 175 +-- certificate 176 +---u client-identity-grouping 177 grouping server-auth-grouping 178 +-- tls-server-auth 179 +-- pinned-ca-certs? ta:pinned-certificates-ref 180 | {ta:x509-certificates}? 181 +-- pinned-server-certs? ta:pinned-certificates-ref 182 {ta:x509-certificates}? 183 grouping hello-params-grouping 184 +-- tls-hello-params {tls-client-hello-params-config}? 185 +---u hello-params-grouping 186 grouping keepalives-grouping 187 +-- tls-keepalives {tls-client-keepalives}? 188 +-- max-wait? uint16 189 +-- max-attempts? uint8 191 3.2. Example Usage 193 This section presents two examples showing the tls-client-grouping 194 populated with some data. These examples are effectively the same 195 except the first configures the client identity using a local key 196 while the second uses a key configured in a keystore. Both examples 197 are consistent with the examples presented in Section 3 of 198 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 199 [I-D.ietf-netconf-keystore]. 201 The following example configures the client identity using a local 202 key: 204 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 206 208 209 210 211 212 ct:rsa2048 214 base64encodedvalue== 215 base64encodedvalue== 216 base64encodedvalue== 217 218 219 221 222 223 explicitly-trusted-server-ca-certs 225 explicitly-trusted-server-certs 227 229 230 30 231 3 232 234 236 The following example configures the client identity using a key from 237 the keystore: 239 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 241 243 244 245 246 ex-rsa-cert 247 248 250 251 252 explicitly-trusted-server-ca-certs 254 explicitly-trusted-server-certs 256 258 259 30 260 3 261 263 265 3.3. YANG Module 267 This YANG module has normative references to 268 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. 270 file "ietf-tls-client@2019-03-09.yang" 271 module ietf-tls-client { 272 yang-version 1.1; 273 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 274 prefix "tlsc"; 276 import ietf-tls-common { 277 prefix tlscmn; 278 revision-date 2019-03-09; // stable grouping definitions 279 reference 280 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 281 } 283 import ietf-trust-anchors { 284 prefix ta; 285 reference 286 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 288 } 290 import ietf-keystore { 291 prefix ks; 292 reference 293 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; 294 } 296 organization 297 "IETF NETCONF (Network Configuration) Working Group"; 299 contact 300 "WG Web: 301 WG List: 302 Author: Kent Watsen 303 Author: Gary Wu "; 305 description 306 "This module defines reusable groupings for TLS clients that 307 can be used as a basis for specific TLS client instances. 309 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 310 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 311 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 312 are to be interpreted as described in BCP 14 [RFC2119] 313 [RFC8174] when, and only when, they appear in all 314 capitals, as shown here. 316 Copyright (c) 2019 IETF Trust and the persons identified as 317 authors of the code. All rights reserved. 319 Redistribution and use in source and binary forms, with or 320 without modification, is permitted pursuant to, and subject 321 to the license terms contained in, the Simplified BSD 322 License set forth in Section 4.c of the IETF Trust's 323 Legal Provisions Relating to IETF Documents 324 (http://trustee.ietf.org/license-info). 326 This version of this YANG module is part of RFC XXXX; see 327 the RFC itself for full legal notices."; 329 revision "2019-03-09" { 330 description 331 "Initial version"; 332 reference 333 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 334 } 335 // Features 337 feature tls-client-hello-params-config { 338 description 339 "TLS hello message parameters are configurable on a TLS 340 client."; 341 } 343 feature tls-client-keepalives { 344 description 345 "Per socket TLS keepalive parameters are configurable for 346 TLS clients on the server implementing this feature."; 347 } 349 // Groupings 351 grouping tls-client-grouping { 352 description 353 "A reusable grouping for configuring a TLS client without 354 any consideration for how an underlying TCP session is 355 established."; 356 uses client-identity-grouping; 357 uses server-auth-grouping; 358 uses hello-params-grouping; 359 uses keepalives-grouping; 360 } 362 grouping client-identity-grouping { 363 description 364 "A reusable grouping for configuring a TLS client identity."; 365 container tls-client-identity { 366 description 367 "The credentials used by the client to authenticate to 368 the TLS server."; 370 choice auth-type { 371 description 372 "The authentication type."; 373 container certificate { 374 uses 375 ks:local-or-keystore-end-entity-cert-with-key-grouping; 376 description 377 "A locally-defined or referenced certificate 378 to be used for client authentication."; 379 reference 380 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; 381 } 382 } 384 } 385 } 387 grouping server-auth-grouping { 388 description 389 "A reusable grouping for configuring TLS server 390 authentication."; 391 container tls-server-auth { 392 must 'pinned-ca-certs or pinned-server-certs'; 393 description 394 "Trusted server identities."; 395 leaf pinned-ca-certs { 396 if-feature "ta:x509-certificates"; 397 type ta:pinned-certificates-ref; 398 description 399 "A reference to a list of certificate authority (CA) 400 certificates used by the TLS client to authenticate 401 TLS server certificates. A server certificate is 402 authenticated if it has a valid chain of trust to 403 a configured pinned CA certificate."; 404 } 405 leaf pinned-server-certs { 406 if-feature "ta:x509-certificates"; 407 type ta:pinned-certificates-ref; 408 description 409 "A reference to a list of server certificates used by 410 the TLS client to authenticate TLS server certificates. 411 A server certificate is authenticated if it is an 412 exact match to a configured pinned server certificate."; 413 } 414 } 415 } 417 grouping hello-params-grouping { 418 description 419 "A reusable grouping for configuring a TLS transport 420 parameters."; 421 container tls-hello-params { 422 if-feature tls-client-hello-params-config; 423 uses tlscmn:hello-params-grouping; 424 description 425 "Configurable parameters for the TLS hello message."; 426 } 427 } 429 grouping keepalives-grouping { 430 description 431 "A reusable grouping for configuring TLS client keepalive 432 parameters."; 433 container tls-keepalives { 434 if-feature "tls-client-keepalives"; 435 description 436 "Configures the keep-alive policy, to proactively test 437 the aliveness of the TLS server. An unresponsive 438 TLS server is dropped after approximately max-wait 439 * max-attempts seconds."; 440 leaf max-wait { 441 type uint16 { 442 range "1..max"; 443 } 444 units seconds; 445 default 30; 446 description 447 "Sets the amount of time in seconds after which if no data 448 has been received from the TLS server, a TLS-level message 449 will be sent to test the aliveness of the TLS server."; 450 } 451 leaf max-attempts { 452 type uint8; 453 default 3; 454 description 455 "Sets the maximum number of sequential keep-alive messages 456 that can fail to obtain a response from the TLS server 457 before assuming the TLS server is no longer alive."; 458 } 459 } 460 } 461 } 462 464 4. The TLS Server Model 466 4.1. Tree Diagram 468 This section provides a tree diagram [RFC8340] for the "ietf-tls- 469 server" module that does not have groupings expanded. 471 module: ietf-tls-server 473 grouping tls-server-grouping 474 +---u server-identity-grouping 475 +---u client-auth-grouping 476 +---u hello-params-grouping 477 +---u keepalives-grouping 478 grouping server-identity-grouping 479 +-- tls-server-identity 480 +---u server-identity-grouping 481 grouping client-auth-grouping 482 +-- tls-client-auth 483 +-- pinned-ca-certs? ta:pinned-certificates-ref 484 | {ta:x509-certificates}? 485 +-- pinned-client-certs? ta:pinned-certificates-ref 486 {ta:x509-certificates}? 487 grouping hello-params-grouping 488 +-- tls-hello-params {tls-server-hello-params-config}? 489 +---u hello-params-grouping 490 grouping keepalives-grouping 491 +-- tls-keepalives {tls-server-keepalives}? 492 +-- max-wait? uint16 493 +-- max-attempts? uint8 495 4.2. Example Usage 497 This section presents two examples showing the tls-server-grouping 498 populated with some data. These examples are effectively the same 499 except the first configures the server identity using a local key 500 while the second uses a key configured in a keystore. Both examples 501 are consistent with the examples presented in Section 3 of 502 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 503 [I-D.ietf-netconf-keystore]. 505 The following example configures the server identity using a local 506 key: 508 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 510 512 513 514 515 ct:rsa2048 517 base64encodedvalue== 518 base64encodedvalue== 519 base64encodedvalue== 520 521 523 524 525 explicitly-trusted-client-ca-certs 527 explicitly-trusted-client-certs 529 531 533 The following example configures the server identity using a key from 534 the keystore: 536 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 538 540 541 542 ex-rsa-cert 543 545 546 547 explicitly-trusted-client-ca-certs 549 explicitly-trusted-client-certs 551 553 555 4.3. YANG Module 557 This YANG module has a normative references to [RFC5246], 558 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. 560 file "ietf-tls-server@2019-03-09.yang" 561 module ietf-tls-server { 562 yang-version 1.1; 563 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 564 prefix "tlss"; 566 import ietf-tls-common { 567 prefix tlscmn; 568 revision-date 2019-03-09; // stable grouping definitions 569 reference 570 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 571 } 573 import ietf-trust-anchors { 574 prefix ta; 575 reference 576 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 577 } 579 import ietf-keystore { 580 prefix ks; 581 reference 582 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; 583 } 585 organization 586 "IETF NETCONF (Network Configuration) Working Group"; 588 contact 589 "WG Web: 590 WG List: 591 Author: Kent Watsen 592 Author: Gary Wu "; 594 description 595 "This module defines reusable groupings for TLS servers that 596 can be used as a basis for specific TLS server instances. 598 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 599 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 600 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 601 are to be interpreted as described in BCP 14 [RFC2119] 602 [RFC8174] when, and only when, they appear in all 603 capitals, as shown here. 605 Copyright (c) 2019 IETF Trust and the persons identified as 606 authors of the code. All rights reserved. 608 Redistribution and use in source and binary forms, with or 609 without modification, is permitted pursuant to, and subject 610 to the license terms contained in, the Simplified BSD 611 License set forth in Section 4.c of the IETF Trust's 612 Legal Provisions Relating to IETF Documents 613 (http://trustee.ietf.org/license-info). 615 This version of this YANG module is part of RFC XXXX; see 616 the RFC itself for full legal notices."; 618 revision "2019-03-09" { 619 description 620 "Initial version"; 621 reference 622 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 623 } 625 // Features 627 feature tls-server-hello-params-config { 628 description 629 "TLS hello message parameters are configurable on a TLS 630 server."; 631 } 633 feature tls-server-keepalives { 634 description 635 "Per socket TLS keepalive parameters are configurable for 636 TLS servers on the server implementing this feature."; 637 } 639 // Groupings 641 grouping tls-server-grouping { 642 description 643 "A reusable grouping for configuring a TLS server without 644 any consideration for how underlying TCP sessions are 645 established."; 646 uses server-identity-grouping; 647 uses client-auth-grouping; 648 uses hello-params-grouping; 649 uses keepalives-grouping; 651 } 653 grouping server-identity-grouping { 654 description 655 "A reusable grouping for configuring a TLS server identity."; 656 container tls-server-identity { 657 description 658 "A locally-defined or referenced end-entity certificate, 659 including any configured intermediate certificates, the 660 TLS server will present when establishing a TLS connection 661 in its Certificate message, as defined in Section 7.4.2 662 in RFC 5246."; 663 reference 664 "RFC 5246: 665 The Transport Layer Security (TLS) Protocol Version 1.2 666 RFC ZZZZ: 667 YANG Data Model for a 'Keystore' Mechanism"; 668 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 669 } 670 } 672 grouping client-auth-grouping { 673 description 674 "A reusable grouping for configuring a TLS client 675 authentication."; 676 container tls-client-auth { 677 description 678 "A reference to a list of pinned certificate authority (CA) 679 certificates and a reference to a list of pinned client 680 certificates."; 681 leaf pinned-ca-certs { 682 if-feature "ta:x509-certificates"; 683 type ta:pinned-certificates-ref; 684 description 685 "A reference to a list of certificate authority (CA) 686 certificates used by the TLS server to authenticate 687 TLS client certificates. A client certificate is 688 authenticated if it has a valid chain of trust to 689 a configured pinned CA certificate."; 690 reference 691 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 692 } 693 leaf pinned-client-certs { 694 if-feature "ta:x509-certificates"; 695 type ta:pinned-certificates-ref; 696 description 697 "A reference to a list of client certificates used by 698 the TLS server to authenticate TLS client certificates. 700 A clients certificate is authenticated if it is an 701 exact match to a configured pinned client certificate."; 702 reference 703 "RFC YYYY: YANG Data Model for Global Trust Anchors"; 704 } 705 } 706 } 708 grouping hello-params-grouping { 709 description 710 "A reusable grouping for configuring a TLS transport 711 parameters."; 712 container tls-hello-params { 713 if-feature tls-server-hello-params-config; 714 uses tlscmn:hello-params-grouping; 715 description 716 "Configurable parameters for the TLS hello message."; 717 } 718 } 720 grouping keepalives-grouping { 721 description 722 "A reusable grouping for configuring TLS server keepalive 723 parameters."; 724 container tls-keepalives { 725 if-feature "tls-server-keepalives"; 726 description 727 "Configures the keep-alive policy, to proactively test 728 the aliveness of the TLS client. An unresponsive 729 TLS client is dropped after approximately max-wait 730 * max-attempts seconds."; 731 leaf max-wait { 732 type uint16 { 733 range "1..max"; 734 } 735 units seconds; 736 default 30; 737 description 738 "Sets the amount of time in seconds after which if no data 739 has been received from the TLS client, a TLS-level message 740 will be sent to test the aliveness of the TLS client."; 741 } 742 leaf max-attempts { 743 type uint8; 744 default 3; 745 description 746 "Sets the maximum number of sequential keep-alive messages 747 that can fail to obtain a response from the TLS client 748 before assuming the TLS client is no longer alive."; 749 } 750 } 751 } 752 } 753 755 5. The TLS Common Model 757 The TLS common model presented in this section contains identities 758 and groupings common to both TLS clients and TLS servers. The hello- 759 params-grouping can be used to configure the list of TLS algorithms 760 permitted by the TLS client or TLS server. The lists of algorithms 761 are ordered such that, if multiple algorithms are permitted by the 762 client, the algorithm that appears first in its list that is also 763 permitted by the server is used for the TLS transport layer 764 connection. The ability to restrict the algorithms allowed is 765 provided in this grouping for TLS clients and TLS servers that are 766 capable of doing so and may serve to make TLS clients and TLS servers 767 compliant with local security policies. This model supports both 768 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446]. 770 TLS 1.2 and TLS 1.3 have different ways defining their own supported 771 cryptographic algorithms, see TLS and DTLS IANA registries page 772 (https://www.iana.org/assignments/tls-parameters/tls- 773 parameters.xhtml): 775 o TLS 1.2 defines four categories of registries for cryptographic 776 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS 777 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the 778 role of combining all of them into one set, as each value of the 779 set represents a unique and feasible combination of all the 780 cryptographic algorithms, and thus the other three registry 781 categories do not need to be considered here. In this document, 782 the TLS common model only chooses those TLS1.2 algorithms in TLS 783 Cipher Suites which are marked as recommended: 784 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 785 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, 786 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, 787 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen 788 algorithms are enumerated in Table 1-1 below; 790 o TLS 1.3 defines its supported algorithms differently. Firstly, it 791 defines three categories of registries for cryptographic 792 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported 793 Groups. Secondly, all three of these categories are useful, since 794 they represent different parts of all the supported algorithms 795 respectively. Thus, all of these registries categories are 796 considered here. In this draft, the TLS common model chooses only 797 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of 798 [RFC8446]. 800 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites 801 part of the hello-params-grouping should include three parameters for 802 configuring its permitted TLS algorithms, which are: TLS Cipher 803 Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2 804 only uses TLS Cipher Suites. 806 [I-D.ietf-netconf-crypto-types] defines six categories of 807 cryptographic algorithms (hash-algorithm, symmetric-key-encryption- 808 algorithm, mac-algorithm, asymmetric-key-encryption-algorithm, 809 signature-algorithm, key-negotiation-algorithm) and lists several 810 widely accepted algorithms for each of them. The TLS client and 811 server models use one or more of these algorithms. The following 812 tables are provided, in part to define the subset of algorithms 813 defined in the crypto-types model used by TLS, and in part to ensure 814 compatibility of configured TLS cryptographic parameters for 815 configuring its permitted TLS algorithms: 817 +-----------------------------------------------+---------+ 818 | ciper-suites in hello-params-grouping | HASH | 819 +-----------------------------------------------+---------+ 820 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | 821 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | 822 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | 823 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | 824 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 | 825 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 | 826 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | 827 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | 828 | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 | 829 | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 | 830 | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 | 831 | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 | 832 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 833 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 834 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 835 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 836 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | 837 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | 838 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | 839 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 | 840 +-----------------------------------------------+---------+ 842 Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping 843 to hash-algorithm 845 +--------------------------------------------- +---------------------+ 846 | ciper-suites in hello-params-grouping | symmetric | 847 | | | 848 +--------------------------------------------- +---------------------+ 849 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 850 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 851 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 852 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 853 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 854 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 855 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 856 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 857 | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm | 858 | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm | 859 | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm | 860 | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm | 861 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 862 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305| 863 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 864 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 865 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| 866 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | 867 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | 868 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm | 869 +--------------------------------------------- +---------------------+ 871 Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping 872 to symmetric-key-encryption-algorithm 874 +--------------------------------------------- +---------------------+ 875 | ciper-suites in hello-params-grouping | MAC | 876 | | | 877 +--------------------------------------------- +---------------------+ 878 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 879 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 880 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 881 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 882 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 883 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 884 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 885 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 886 | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm | 887 | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm | 888 | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm | 889 | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm | 890 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 891 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305| 892 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 893 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 894 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| 895 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | 896 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | 897 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm | 898 +--------------------------------------------- +---------------------+ 900 Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping 901 to MAC-algorithm 903 +----------------------------------------------+----------------------+ 904 |ciper-suites in hello-params-grouping | signature | 905 +--------------------------------------------- +----------------------+ 906 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | 907 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | 908 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | 909 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | 910 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256| 911 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384| 912 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | 913 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | 914 | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 | 915 | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 | 916 | TLS_DHE_PSK_WITH_AES_128_CCM | N/A | 917 | TLS_DHE_PSK_WITH_AES_256_CCM | N/A | 918 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | 919 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256| 920 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | 921 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | 922 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | 923 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | 924 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | 925 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A | 926 +----------------------------------------------+----------------------+ 928 Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping 929 to signature-algorithm 931 +----------------------------------------------+-----------------------+ 932 |ciper-suites in hello-params-grouping | key-negotiation | 933 +----------------------------------------------+-----------------------+ 934 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... | 935 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... | 936 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...| 937 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...| 938 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | 939 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | 940 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | 941 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | 942 | TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... | 943 | TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... | 944 | TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...| 945 | TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...| 946 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... | 947 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... | 948 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... | 949 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...| 950 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...| 951 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...| 952 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...| 953 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...| 954 +----------------------------------------------+-----------------------+ 956 Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping 957 to key-negotiation-algorithm 959 +------------------------------+---------+ 960 | ciper-suites in hello | HASH | 961 | -params-grouping | | 962 +------------------------------+---------+ 963 | TLS_AES_128_GCM_SHA256 | sha-256 | 964 | TLS_AES_256_GCM_SHA384 | sha-384 | 965 | TLS_CHACHA20_POLY1305_SHA256 | sha-256 | 966 | TLS_AES_128_CCM_SHA256 | sha-256 | 967 +------------------------------+---------+ 969 Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping 970 to hash-algorithm 972 +------------------------------+-----------------------+ 973 | ciper-suites in hello | symmetric | 974 | -params-grouping | | 975 +------------------------------+-----------------------+ 976 | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm | 977 | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm | 978 | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 | 979 | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm | 980 +------------------------------+-----------------------+ 982 Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping 983 to symmetric-key--encryption-algorithm 985 +------------------------------+-----------------------+ 986 | ciper-suites in hello | symmetric | 987 | -params-grouping | | 988 +------------------------------+-----------------------+ 989 | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm | 990 | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm | 991 | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 | 992 | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm | 993 +------------------------------+-----------------------+ 995 Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping 996 to MAC-algorithm 998 +----------------------------+-------------------------+ 999 |signatureScheme in hello | signature | 1000 | -params-grouping | | 1001 +----------------------------+-------------------------+ 1002 | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 | 1003 | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 | 1004 | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 | 1005 | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 | 1006 | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 | 1007 | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 | 1008 | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 | 1009 | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 | 1010 | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 | 1011 | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 | 1012 | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 | 1013 | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 | 1014 | ed25519 | ed25519 | 1015 | ed448 | ed448 | 1016 +----------------------------+-------------------------+ 1018 Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme 1019 mapping to signature-algorithm 1021 +----------------------------+-------------------------+ 1022 |supported Groups in hello | key-negotiation | 1023 | -params-grouping | | 1024 +----------------------------+-------------------------+ 1025 | dhe-ffdhe2048 | dhe-ffdhe2048 | 1026 | dhe-ffdhe3072 | dhe-ffdhe3072 | 1027 | dhe-ffdhe4096 | dhe-ffdhe4096 | 1028 | dhe-ffdhe6144 | dhe-ffdhe6144 | 1029 | dhe-ffdhe8192 | dhe-ffdhe8192 | 1030 | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 | 1031 | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 | 1032 | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 | 1033 | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 | 1034 | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 | 1035 | ecdhe-secp256r1 | ecdhe-secp256r1 | 1036 | ecdhe-secp384r1 | ecdhe-secp384r1 | 1037 | ecdhe-secp521r1 | ecdhe-secp521r1 | 1038 | ecdhe-x25519 | ecdhe-x25519 | 1039 | ecdhe-x448 | ecdhe-x448 | 1040 | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 | 1041 | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 | 1042 | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 | 1043 | psk-ecdhe-x25519 | psk-ecdhe-x25519 | 1044 | psk-ecdhe-x448 | psk-ecdhe-x448 | 1045 +----------------------------+-------------------------+ 1047 Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups 1048 mapping to key-negotiation-algorithm 1050 Note that in Table 1-5: 1052 o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe- 1053 ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192; 1055 o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048, 1056 psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe- 1057 ffdhe8192; 1059 o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1, 1060 ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448; 1062 o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe- 1063 secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe- 1064 x25519, psk-ecdhe-x448. 1066 Features are defined for algorithms that are OPTIONAL or are not 1067 widely supported by popular implementations. Note that the list of 1068 algorithms is not exhaustive. 1070 5.1. Tree Diagram 1072 The following tree diagram [RFC8340] provides an overview of the data 1073 model for the "ietf-tls-common" module. 1075 module: ietf-tls-common 1077 grouping hello-params-grouping 1078 +-- tls-versions 1079 | +-- tls-version* identityref 1080 +-- cipher-suites 1081 +-- cipher-suite* identityref 1083 5.2. Example Usage 1085 This section shows how it would appear if the transport-params- 1086 grouping were populated with some data. 1088 1091 1092 tlscmn:tls-1.1 1093 tlscmn:tls-1.2 1094 1095 1096 tlscmn:dhe-rsa-with-aes-128-cbc-sha 1097 tlscmn:rsa-with-aes-128-cbc-sha 1098 tlscmn:rsa-with-3des-ede-cbc-sha 1099 1100 1102 5.3. YANG Module 1104 This YANG module has a normative references to [RFC4346], [RFC5246], 1105 [RFC5288], [RFC5289], and [RFC8422]. 1107 This YANG module has a informative references to [RFC2246], 1108 [RFC4346], [RFC5246], and [RFC8446]. 1110 file "ietf-tls-common@2019-03-09.yang" 1111 module ietf-tls-common { 1112 yang-version 1.1; 1113 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; 1114 prefix "tlscmn"; 1116 organization 1117 "IETF NETCONF (Network Configuration) Working Group"; 1119 contact 1120 "WG Web: 1121 WG List: 1122 Author: Kent Watsen 1123 Author: Gary Wu "; 1125 description 1126 "This module defines a common features, identities, and 1127 groupings for Transport Layer Security (TLS). 1129 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1130 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1131 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1132 are to be interpreted as described in BCP 14 [RFC2119] 1133 [RFC8174] when, and only when, they appear in all 1134 capitals, as shown here. 1136 Copyright (c) 2019 IETF Trust and the persons identified as 1137 authors of the code. All rights reserved. 1139 Redistribution and use in source and binary forms, with or 1140 without modification, is permitted pursuant to, and subject 1141 to the license terms contained in, the Simplified BSD 1142 License set forth in Section 4.c of the IETF Trust's 1143 Legal Provisions Relating to IETF Documents 1144 (http://trustee.ietf.org/license-info). 1146 This version of this YANG module is part of RFC XXXX; see 1147 the RFC itself for full legal notices."; 1149 revision "2019-03-09" { 1150 description 1151 "Initial version"; 1152 reference 1153 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 1154 } 1156 // Features 1158 feature tls-1_0 { 1159 description 1160 "TLS Protocol Version 1.0 is supported."; 1161 reference 1162 "RFC 2246: The TLS Protocol Version 1.0"; 1163 } 1165 feature tls-1_1 { 1166 description 1167 "TLS Protocol Version 1.1 is supported."; 1168 reference 1169 "RFC 4346: The Transport Layer Security (TLS) Protocol 1170 Version 1.1"; 1171 } 1173 feature tls-1_2 { 1174 description 1175 "TLS Protocol Version 1.2 is supported."; 1176 reference 1177 "RFC 5246: The Transport Layer Security (TLS) Protocol 1178 Version 1.2"; 1179 } 1181 feature tls-1_3 { 1182 description 1183 "TLS Protocol Version 1.2 is supported."; 1184 reference 1185 "RFC 8446: The Transport Layer Security (TLS) Protocol 1186 Version 1.3"; 1187 } 1189 feature tls-ecc { 1190 description 1191 "Elliptic Curve Cryptography (ECC) is supported for TLS."; 1192 reference 1193 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1194 for Transport Layer Security (TLS)"; 1195 } 1197 feature tls-dhe { 1198 description 1199 "Ephemeral Diffie-Hellman key exchange is supported for TLS."; 1200 reference 1201 "RFC 5246: The Transport Layer Security (TLS) Protocol 1202 Version 1.2"; 1203 } 1205 feature tls-3des { 1206 description 1207 "The Triple-DES block cipher is supported for TLS."; 1208 reference 1209 "RFC 5246: The Transport Layer Security (TLS) Protocol 1210 Version 1.2"; 1211 } 1213 feature tls-gcm { 1214 description 1215 "The Galois/Counter Mode authenticated encryption mode is 1216 supported for TLS."; 1217 reference 1218 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for 1219 TLS"; 1220 } 1222 feature tls-sha2 { 1223 description 1224 "The SHA2 family of cryptographic hash functions is supported 1225 for TLS."; 1226 reference 1227 "FIPS PUB 180-4: Secure Hash Standard (SHS)"; 1228 } 1230 // Identities 1232 identity tls-version-base { 1233 description 1234 "Base identity used to identify TLS protocol versions."; 1235 } 1237 identity tls-1.0 { 1238 base tls-version-base; 1239 if-feature tls-1_0; 1240 description 1241 "TLS Protocol Version 1.0."; 1242 reference 1243 "RFC 2246: The TLS Protocol Version 1.0"; 1244 } 1246 identity tls-1.1 { 1247 base tls-version-base; 1248 if-feature tls-1_1; 1249 description 1250 "TLS Protocol Version 1.1."; 1251 reference 1252 "RFC 4346: The Transport Layer Security (TLS) Protocol 1253 Version 1.1"; 1254 } 1256 identity tls-1.2 { 1257 base tls-version-base; 1258 if-feature tls-1_2; 1259 description 1260 "TLS Protocol Version 1.2."; 1261 reference 1262 "RFC 5246: The Transport Layer Security (TLS) Protocol 1263 Version 1.2"; 1264 } 1266 identity cipher-suite-base { 1267 description 1268 "Base identity used to identify TLS cipher suites."; 1269 } 1271 identity rsa-with-aes-128-cbc-sha { 1272 base cipher-suite-base; 1273 description 1274 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA."; 1275 reference 1276 "RFC 5246: The Transport Layer Security (TLS) Protocol 1277 Version 1.2"; 1278 } 1280 identity rsa-with-aes-256-cbc-sha { 1281 base cipher-suite-base; 1282 description 1283 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; 1284 reference 1285 "RFC 5246: The Transport Layer Security (TLS) Protocol 1286 Version 1.2"; 1287 } 1289 identity rsa-with-aes-128-cbc-sha256 { 1290 base cipher-suite-base; 1291 if-feature tls-sha2; 1292 description 1293 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; 1294 reference 1295 "RFC 5246: The Transport Layer Security (TLS) Protocol 1296 Version 1.2"; 1297 } 1299 identity rsa-with-aes-256-cbc-sha256 { 1300 base cipher-suite-base; 1301 if-feature tls-sha2; 1302 description 1303 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256."; 1304 reference 1305 "RFC 5246: The Transport Layer Security (TLS) Protocol 1306 Version 1.2"; 1307 } 1309 identity dhe-rsa-with-aes-128-cbc-sha { 1310 base cipher-suite-base; 1311 if-feature tls-dhe; 1312 description 1313 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA."; 1314 reference 1315 "RFC 5246: The Transport Layer Security (TLS) Protocol 1316 Version 1.2"; 1317 } 1319 identity dhe-rsa-with-aes-256-cbc-sha { 1320 base cipher-suite-base; 1321 if-feature tls-dhe; 1322 description 1323 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA."; 1324 reference 1325 "RFC 5246: The Transport Layer Security (TLS) Protocol 1326 Version 1.2"; 1327 } 1329 identity dhe-rsa-with-aes-128-cbc-sha256 { 1330 base cipher-suite-base; 1331 if-feature "tls-dhe and tls-sha2"; 1332 description 1333 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; 1334 reference 1335 "RFC 5246: The Transport Layer Security (TLS) Protocol 1336 Version 1.2"; 1337 } 1339 identity dhe-rsa-with-aes-256-cbc-sha256 { 1340 base cipher-suite-base; 1341 if-feature "tls-dhe and tls-sha2"; 1342 description 1343 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; 1344 reference 1345 "RFC 5246: The Transport Layer Security (TLS) Protocol 1346 Version 1.2"; 1347 } 1349 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 { 1350 base cipher-suite-base; 1351 if-feature "tls-ecc and tls-sha2"; 1352 description 1353 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256."; 1354 reference 1355 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1356 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1357 } 1358 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 { 1359 base cipher-suite-base; 1360 if-feature "tls-ecc and tls-sha2"; 1361 description 1362 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384."; 1363 reference 1364 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1365 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1366 } 1368 identity ecdhe-rsa-with-aes-128-cbc-sha256 { 1369 base cipher-suite-base; 1370 if-feature "tls-ecc and tls-sha2"; 1371 description 1372 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256."; 1373 reference 1374 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1375 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1376 } 1378 identity ecdhe-rsa-with-aes-256-cbc-sha384 { 1379 base cipher-suite-base; 1380 if-feature "tls-ecc and tls-sha2"; 1381 description 1382 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; 1383 reference 1384 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1385 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1386 } 1388 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { 1389 base cipher-suite-base; 1390 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1391 description 1392 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; 1393 reference 1394 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1395 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1396 } 1398 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 { 1399 base cipher-suite-base; 1400 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1401 description 1402 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."; 1403 reference 1404 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1405 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1407 } 1409 identity ecdhe-rsa-with-aes-128-gcm-sha256 { 1410 base cipher-suite-base; 1411 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1412 description 1413 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256."; 1414 reference 1415 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1416 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1417 } 1419 identity ecdhe-rsa-with-aes-256-gcm-sha384 { 1420 base cipher-suite-base; 1421 if-feature "tls-ecc and tls-gcm and tls-sha2"; 1422 description 1423 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384."; 1424 reference 1425 "RFC 5289: TLS Elliptic Curve Cipher Suites with 1426 SHA-256/384 and AES Galois Counter Mode (GCM)"; 1427 } 1429 identity rsa-with-3des-ede-cbc-sha { 1430 base cipher-suite-base; 1431 if-feature tls-3des; 1432 description 1433 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; 1434 reference 1435 "RFC 5246: The Transport Layer Security (TLS) Protocol 1436 Version 1.2"; 1437 } 1439 identity ecdhe-rsa-with-3des-ede-cbc-sha { 1440 base cipher-suite-base; 1441 if-feature "tls-ecc and tls-3des"; 1442 description 1443 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; 1444 reference 1445 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1446 for Transport Layer Security (TLS)"; 1447 } 1449 identity ecdhe-rsa-with-aes-128-cbc-sha { 1450 base cipher-suite-base; 1451 if-feature "tls-ecc"; 1452 description 1453 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA."; 1454 reference 1455 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1456 for Transport Layer Security (TLS)"; 1457 } 1459 identity ecdhe-rsa-with-aes-256-cbc-sha { 1460 base cipher-suite-base; 1461 if-feature "tls-ecc"; 1462 description 1463 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA."; 1464 reference 1465 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites 1466 for Transport Layer Security (TLS)"; 1467 } 1469 // Groupings 1471 grouping hello-params-grouping { 1472 description 1473 "A reusable grouping for TLS hello message parameters."; 1474 reference 1475 "RFC 5246: The Transport Layer Security (TLS) Protocol 1476 Version 1.2"; 1478 container tls-versions { 1479 description 1480 "Parameters regarding TLS versions."; 1481 leaf-list tls-version { 1482 type identityref { 1483 base tls-version-base; 1484 } 1485 description 1486 "Acceptable TLS protocol versions. 1488 If this leaf-list is not configured (has zero elements) 1489 the acceptable TLS protocol versions are implementation- 1490 defined."; 1491 } 1492 } 1493 container cipher-suites { 1494 description 1495 "Parameters regarding cipher suites."; 1496 leaf-list cipher-suite { 1497 type identityref { 1498 base cipher-suite-base; 1499 } 1500 ordered-by user; 1501 description 1502 "Acceptable cipher suites in order of descending 1503 preference. The configured host key algorithms should 1504 be compatible with the algorithm used by the configured 1505 private key. Please see Section 5 of RFC XXXX for 1506 valid combinations. 1508 If this leaf-list is not configured (has zero elements) 1509 the acceptable cipher suites are implementation- 1510 defined."; 1511 reference 1512 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; 1513 } 1514 } 1516 } 1517 } 1518 1520 6. Security Considerations 1522 The YANG modules defined in this document are designed to be accessed 1523 via YANG based management protocols, such as NETCONF [RFC6241] and 1524 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1525 implement secure transport layers (e.g., SSH, TLS) with mutual 1526 authentication. 1528 The NETCONF access control model (NACM) [RFC8341] provides the means 1529 to restrict access for particular users to a pre-configured subset of 1530 all available protocol operations and content. 1532 Since the modules defined in this document only define groupings, 1533 these considerations are primarily for the designers of other modules 1534 that use these groupings. 1536 There are a number of data nodes defined in the YANG modules that are 1537 writable/creatable/deletable (i.e., config true, which is the 1538 default). These data nodes may be considered sensitive or vulnerable 1539 in some network environments. Write operations (e.g., edit-config) 1540 to these data nodes without proper protection can have a negative 1541 effect on network operations. These are the subtrees and data nodes 1542 and their sensitivity/vulnerability: 1544 /: The entire data tree of all the groupings defined in this draft 1545 is sensitive to write operations. For instance, the addition 1546 or removal of references to keys, certificates, trusted 1547 anchors, etc., can dramatically alter the implemented security 1548 policy. However, no NACM annotations are applied as the data 1549 SHOULD be editable by users other than a designated 'recovery 1550 session'. 1552 Some of the readable data nodes in the YANG modules may be considered 1553 sensitive or vulnerable in some network environments. It is thus 1554 important to control read access (e.g., via get, get-config, or 1555 notification) to these data nodes. These are the subtrees and data 1556 nodes and their sensitivity/vulnerability: 1558 NONE 1560 Some of the RPC operations in this YANG module may be considered 1561 sensitive or vulnerable in some network environments. It is thus 1562 important to control access to these operations. These are the 1563 operations and their sensitivity/vulnerability: 1565 NONE 1567 7. IANA Considerations 1569 7.1. The IETF XML Registry 1571 This document registers three URIs in the "ns" subregistry of the 1572 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the 1573 following registrations are requested: 1575 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 1576 Registrant Contact: The NETCONF WG of the IETF. 1577 XML: N/A, the requested URI is an XML namespace. 1579 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 1580 Registrant Contact: The NETCONF WG of the IETF. 1581 XML: N/A, the requested URI is an XML namespace. 1583 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common 1584 Registrant Contact: The NETCONF WG of the IETF. 1585 XML: N/A, the requested URI is an XML namespace. 1587 7.2. The YANG Module Names Registry 1589 This document registers three YANG modules in the YANG Module Names 1590 registry [RFC6020]. Following the format in [RFC6020], the following 1591 registrations are requested: 1593 name: ietf-tls-client 1594 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 1595 prefix: tlsc 1596 reference: RFC XXXX 1598 name: ietf-tls-server 1599 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 1600 prefix: tlss 1601 reference: RFC XXXX 1603 name: ietf-tls-common 1604 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common 1605 prefix: tlscmn 1606 reference: RFC XXXX 1608 8. References 1610 8.1. Normative References 1612 [I-D.ietf-netconf-crypto-types] 1613 Watsen, K. and H. Wang, "Common YANG Data Types for 1614 Cryptography", draft-ietf-netconf-crypto-types-02 (work in 1615 progress), October 2018. 1617 [I-D.ietf-netconf-keystore] 1618 Watsen, K., "YANG Data Model for a Centralized Keystore 1619 Mechanism", draft-ietf-netconf-keystore-08 (work in 1620 progress), March 2019. 1622 [I-D.ietf-netconf-trust-anchors] 1623 Watsen, K., "YANG Data Model for Global Trust Anchors", 1624 draft-ietf-netconf-trust-anchors-03 (work in progress), 1625 March 2019. 1627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1628 Requirement Levels", BCP 14, RFC 2119, 1629 DOI 10.17487/RFC2119, March 1997, 1630 . 1632 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1633 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1634 DOI 10.17487/RFC5288, August 2008, 1635 . 1637 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 1638 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 1639 DOI 10.17487/RFC5289, August 2008, 1640 . 1642 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1643 the Network Configuration Protocol (NETCONF)", RFC 6020, 1644 DOI 10.17487/RFC6020, October 2010, 1645 . 1647 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1648 NETCONF Protocol over Transport Layer Security (TLS) with 1649 Mutual X.509 Authentication", RFC 7589, 1650 DOI 10.17487/RFC7589, June 2015, 1651 . 1653 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1654 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1655 . 1657 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1658 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1659 May 2017, . 1661 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1662 Access Control Model", STD 91, RFC 8341, 1663 DOI 10.17487/RFC8341, March 2018, 1664 . 1666 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1667 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1668 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1669 DOI 10.17487/RFC8422, August 2018, 1670 . 1672 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1673 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1674 . 1676 8.2. Informative References 1678 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1679 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1680 . 1682 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1683 DOI 10.17487/RFC2818, May 2000, 1684 . 1686 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1687 DOI 10.17487/RFC3688, January 2004, 1688 . 1690 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1691 (TLS) Protocol Version 1.1", RFC 4346, 1692 DOI 10.17487/RFC4346, April 2006, 1693 . 1695 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1696 (TLS) Protocol Version 1.2", RFC 5246, 1697 DOI 10.17487/RFC5246, August 2008, 1698 . 1700 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1701 and A. Bierman, Ed., "Network Configuration Protocol 1702 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1703 . 1705 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1706 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1707 . 1709 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1710 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1711 . 1713 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1714 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1715 . 1717 Appendix A. Change Log 1719 A.1. 00 to 01 1721 o Noted that '0.0.0.0' and '::' might have special meanings. 1723 o Renamed "keychain" to "keystore". 1725 A.2. 01 to 02 1727 o Removed the groupings containing transport-level configuration. 1728 Now modules contain only the transport-independent groupings. 1730 o Filled in previously incomplete 'ietf-tls-client' module. 1732 o Added cipher suites for various algorithms into new 'ietf-tls- 1733 common' module. 1735 A.3. 02 to 03 1737 o Added a 'must' statement to container 'server-auth' asserting that 1738 at least one of the various auth mechanisms must be specified. 1740 o Fixed description statement for leaf 'trusted-ca-certs'. 1742 A.4. 03 to 04 1744 o Updated title to "YANG Groupings for TLS Clients and TLS Servers" 1746 o Updated leafref paths to point to new keystore path 1748 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to 1749 'tlscmn'. 1751 o Added TLS protocol verions 1.0 and 1.1. 1753 o Made author lists consistent 1755 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1757 o Updated YANG to use typedefs around leafrefs to common keystore 1758 paths 1760 o Now inlines key and certificates (no longer a leafref to keystore) 1762 A.5. 04 to 05 1764 o Merged changes from co-author. 1766 A.6. 05 to 06 1768 o Updated to use trust anchors from trust-anchors draft (was 1769 keystore draft) 1771 o Now Uses new keystore grouping enabling asymmetric key to be 1772 either locally defined or a reference to the keystore. 1774 A.7. 06 to 07 1776 o factored the tls-[client|server]-groupings into more reusable 1777 groupings. 1779 o added if-feature statements for the new "x509-certificates" 1780 feature defined in draft-ietf-netconf-trust-anchors. 1782 A.8. 07 to 08 1784 o Added a number of compatibility matrices to Section 5 (thanks 1785 Frank!) 1787 o Clarified that any configured "cipher-suite" values need to be 1788 compatible with the configured private key. 1790 A.9. 08 to 09 1792 o Updated examples to reflect update to groupings defined in the 1793 keystore draft. 1795 o Add TLS keepalives features and groupings. 1797 o Prefixed top-level TLS grouping nodes with 'tls-' and support 1798 mashups. 1800 o Updated copyright date, boilerplate template, affiliation, and 1801 folding algorithm. 1803 Acknowledgements 1805 The authors would like to thank for following for lively discussions 1806 on list and in the halls (ordered by last name): Andy Bierman, Martin 1807 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 1808 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, 1809 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. 1811 Authors' Addresses 1813 Kent Watsen 1814 Watsen Networks 1816 EMail: kent+ietf@watsen.net 1818 Gary Wu 1819 Cisco Systems 1821 EMail: garywu@cisco.com 1823 Liang Xia 1824 Huawei 1826 EMail: frank.xialiang@huawei.com