--- 1/draft-ietf-netconf-tls-client-server-07.txt 2018-10-22 15:13:34.750580137 -0700 +++ 2/draft-ietf-netconf-tls-client-server-08.txt 2018-10-22 15:13:34.818581779 -0700 @@ -1,19 +1,21 @@ NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Intended status: Standards Track G. Wu -Expires: March 24, 2019 Cisco Systems - September 20, 2018 +Expires: April 25, 2019 Cisco Systems + L. Xia + Huawei + October 22, 2018 YANG Groupings for TLS Clients and TLS Servers - draft-ietf-netconf-tls-client-server-07 + draft-ietf-netconf-tls-client-server-08 Abstract This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. Editorial Note (To be removed by RFC Editor) @@ -38,41 +40,42 @@ o "XXXX" --> the assigned RFC value for this draft o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust- anchors o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: - o "2018-09-20" --> the publication date of this draft + o "2018-10-22" --> the publication date of this draft + The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 24, 2019. + This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -87,42 +90,42 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 9 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 - 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 15 - 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 16 - 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 25 - 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 26 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 - 8.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 - A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 29 - A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 29 - A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 29 - A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 29 - A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 30 - A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 30 - A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 30 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 + 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24 + 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 24 + 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 34 + 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 8.2. Informative References . . . . . . . . . . . . . . . . . 36 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 38 + A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 38 + A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 38 + A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 38 + A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 38 + A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 39 + A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 39 + A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 39 + A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 39 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document defines three YANG 1.1 [RFC7950] modules: the first defines a grouping for a generic TLS client, the second defines a grouping for a generic TLS server, and the third defines identities and groupings common to both the client and the server (TLS is defined in [RFC5246]). It is intended that these groupings will be used by applications using the TLS protocol. For instance, these groupings could be used to help define the data model for an HTTPS @@ -193,21 +197,21 @@ key: [Note: '\' line wrapping for formatting only] ct:rsa1024 + ypes">ct:rsa2048 base64encodedvalue== base64encodedvalue== base64encodedvalue== explicitly-trusted-server-ca-certs @@ -239,30 +243,30 @@ ver-certs> 3.3. YANG Module This YANG module has normative references to [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. - file "ietf-tls-client@2018-09-20.yang" + file "ietf-tls-client@2018-10-22.yang" module ietf-tls-client { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; prefix "tlsc"; import ietf-tls-common { prefix tlscmn; - revision-date 2018-09-20; // stable grouping definitions + revision-date 2018-10-22; // stable grouping definitions reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } import ietf-trust-anchors { prefix ta; reference "RFC YYYY: YANG Data Model for Global Trust Anchors"; } @@ -295,21 +299,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision "2018-09-20" { + revision "2018-10-22" { description "Initial version"; reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } // features feature tls-client-hello-params-config { description @@ -335,21 +339,21 @@ "A reusable grouping for configuring a TLS client identity."; container client-identity { description "The credentials used by the client to authenticate to the TLS server."; choice auth-type { description "The authentication type."; container certificate { - uses ks:local-or-keystore-end-entity-certificate-grouping; + uses ks:local-or-keystore-end-entity-cert-with-key-grouping; description "A locally-defined or referenced certificate to be used for client authentication."; reference "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; } } } // end client-identity } // end client-identity-grouping @@ -437,21 +441,21 @@ The following example configures the server identity using a local key: [Note: '\' line wrapping for formatting only] ct:rsa1024 + es">ct:rsa2048 base64encodedvalue== base64encodedvalue== base64encodedvalue== explicitly-trusted-client-ca-certs explicitly-trusted-client-certs 4.3. YANG Module This YANG module has a normative references to [RFC5246], [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. - file "ietf-tls-server@2018-09-20.yang" + file "ietf-tls-server@2018-10-22.yang" module ietf-tls-server { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; prefix "tlss"; import ietf-tls-common { prefix tlscmn; - revision-date 2018-09-20; // stable grouping definitions + revision-date 2018-10-22; // stable grouping definitions reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } import ietf-trust-anchors { prefix ta; reference "RFC YYYY: YANG Data Model for Global Trust Anchors"; } @@ -536,21 +540,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision "2018-09-20" { + revision "2018-10-22" { description "Initial version"; reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } // features feature tls-server-hello-params-config { description @@ -578,21 +582,21 @@ "A locally-defined or referenced end-entity certificate, including any configured intermediate certificates, the TLS server will present when establishing a TLS connection in its Certificate message, as defined in Section 7.4.2 in RFC 5246."; reference "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; - uses ks:local-or-keystore-end-entity-certificate-grouping; + uses ks:local-or-keystore-end-entity-cert-with-key-grouping; } } // end server-identity-grouping grouping client-auth-grouping { description "A reusable grouping for configuring a TLS client authentication."; container client-auth { description "A reference to a list of pinned certificate authority (CA) @@ -645,21 +649,318 @@ The TLS common model presented in this section contains identities and groupings common to both TLS clients and TLS servers. The hello- params-grouping can be used to configure the list of TLS algorithms permitted by the TLS client or TLS server. The lists of algorithms are ordered such that, if multiple algorithms are permitted by the client, the algorithm that appears first in its list that is also permitted by the server is used for the TLS transport layer connection. The ability to restrict the the algorithms allowed is provided in this grouping for TLS clients and TLS servers that are capable of doing so and may serve to make TLS clients and TLS servers - compliant with security policies. + compliant with local security policies. This model supports both + TLS1.2 [RFC5246] and TLS 1.3 [RFC8446]. + + TLS 1.2 and TLS 1.3 have different ways defining their own supported + cryptographic algorithms, see TLS and DTLS IANA registries page + (https://www.iana.org/assignments/tls-parameters/tls- + parameters.xhtml): + + o TLS 1.2 defines four categories of registries for cryptographic + algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS + HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the + role of combining all of them into one set, as each value of the + set represents a unique and feasible combination of all the + cryptographic algorithms, and thus the other three registry + categories do not need to be considered here. In this document, + the TLS common model only chooses those TLS1.2 algorithms in TLS + Cipher Suites which are marked as recommended: + TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, + TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, + TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, + TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen + algorithms are enumerated in Table 1-1 below; + + o TLS 1.3 defines its supported algorithms differently. Firstly, it + defines three categories of registries for cryptographic + algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported + Groups. Secondly, all three of these categories are useful, since + they represent different parts of all the supported algorithms + respectively. Thus, all of these registries categories are + considered here. In this draft, the TLS common model chooses only + those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of + [RFC8446]. + + Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites + part of the hello-params-grouping should include three parameters for + configuring its permitted TLS algorithms, which are: TLS Cipher + Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2 + only uses TLS Cipher Suites. + + [I-D.ietf-netconf-crypto-types] defines six categories of + cryptographic algorithms (hash-algorithm, symmetric-key-encryption- + algorithm, mac-algorithm, asymmetric-key-encryption-algorithm, + signature-algorithm, key-negotiation-algorithm) and lists several + widely accepted algorithms for each of them. The TLS client and + server models use one or more of these algorithms. The following + tables are provided, in part to define the subset of algorithms + defined in the crypto-types model used by TLS, and in part to ensure + compatibility of configured TLS cryptographic parameters for + configuring its permitted TLS algorithms: + + +-----------------------------------------------+---------+ + | ciper-suites in hello-params-grouping | HASH | + +-----------------------------------------------+---------+ + | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | + | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | + | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | + | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | + | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 | + | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 | + | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 | + | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 | + | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 | + | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 | + | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 | + | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 | + | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | + | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | + | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | + | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | + | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 | + | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 | + | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 | + | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 | + +-----------------------------------------------+---------+ + + Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping + to hash-algorithm + + +--------------------------------------------- +---------------------+ + | ciper-suites in hello-params-grouping | symmetric | + | | | + +--------------------------------------------- +---------------------+ + | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | + | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | + | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | + | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | + | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | + | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | + | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | + | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | + | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm | + | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm | + | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm | + | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm | + | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| + | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305| + | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| + | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| + | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305| + | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm | + | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm | + | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm | + +--------------------------------------------- +---------------------+ + + Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping + to symmetric-key-encryption-algorithm + + +--------------------------------------------- +---------------------+ + | ciper-suites in hello-params-grouping | MAC | + | | | + +--------------------------------------------- +---------------------+ + | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | + | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | + | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | + | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | + | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | + | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | + | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | + | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | + | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm | + | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm | + | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm | + | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm | + | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| + | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305| + | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| + | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| + | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305| + | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm | + | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm | + | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm | + +--------------------------------------------- +---------------------+ + + Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping + to MAC-algorithm + + +----------------------------------------------+----------------------+ + |ciper-suites in hello-params-grouping | signature | + +--------------------------------------------- +----------------------+ + | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | + | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | + | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | + | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | + | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256| + | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384| + | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 | + | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 | + | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 | + | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 | + | TLS_DHE_PSK_WITH_AES_128_CCM | N/A | + | TLS_DHE_PSK_WITH_AES_256_CCM | N/A | + | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | + | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256| + | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 | + | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | + | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A | + | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A | + | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A | + | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A | + +----------------------------------------------+----------------------+ + + Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping + to signature-algorithm + ++----------------------------------------------+-----------------------+ +|ciper-suites in hello-params-grouping | key-negotiation | ++----------------------------------------------+-----------------------+ +| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... | +| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... | +| TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...| +| TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...| +| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | +| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | +| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... | +| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... | +| TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... | +| TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... | +| TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...| +| TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...| +| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... | +| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... | +| TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... | +| TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...| +| TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...| +| TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...| +| TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...| +| TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...| ++----------------------------------------------+-----------------------+ + + Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping + to key-negotiation-algorithm + + +------------------------------+---------+ + | ciper-suites in hello | HASH | + | -params-grouping | | + +------------------------------+---------+ + | TLS_AES_128_GCM_SHA256 | sha-256 | + | TLS_AES_256_GCM_SHA384 | sha-384 | + | TLS_CHACHA20_POLY1305_SHA256 | sha-256 | + | TLS_AES_128_CCM_SHA256 | sha-256 | + +------------------------------+---------+ + + Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping + to hash-algorithm + + +------------------------------+-----------------------+ + | ciper-suites in hello | symmetric | + | -params-grouping | | + +------------------------------+-----------------------+ + | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm | + | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm | + | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 | + | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm | + +------------------------------+-----------------------+ + + Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping + to symmetric-key--encryption-algorithm + + +------------------------------+-----------------------+ + | ciper-suites in hello | symmetric | + | -params-grouping | | + +------------------------------+-----------------------+ + | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm | + | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm | + | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 | + | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm | + +------------------------------+-----------------------+ + + Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping + to MAC-algorithm + + +----------------------------+-------------------------+ + |signatureScheme in hello | signature | + | -params-grouping | | + +----------------------------+-------------------------+ + | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 | + | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 | + | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 | + | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 | + | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 | + | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 | + | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 | + | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 | + | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 | + | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 | + | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 | + | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 | + | ed25519 | ed25519 | + | ed448 | ed448 | + +----------------------------+-------------------------+ + + Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme + mapping to signature-algorithm + + +----------------------------+-------------------------+ + |supported Groups in hello | key-negotiation | + | -params-grouping | | + +----------------------------+-------------------------+ + | dhe-ffdhe2048 | dhe-ffdhe2048 | + | dhe-ffdhe3072 | dhe-ffdhe3072 | + | dhe-ffdhe4096 | dhe-ffdhe4096 | + | dhe-ffdhe6144 | dhe-ffdhe6144 | + | dhe-ffdhe8192 | dhe-ffdhe8192 | + | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 | + | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 | + | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 | + | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 | + | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 | + | ecdhe-secp256r1 | ecdhe-secp256r1 | + | ecdhe-secp384r1 | ecdhe-secp384r1 | + | ecdhe-secp521r1 | ecdhe-secp521r1 | + | ecdhe-x25519 | ecdhe-x25519 | + | ecdhe-x448 | ecdhe-x448 | + | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 | + | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 | + | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 | + | psk-ecdhe-x25519 | psk-ecdhe-x25519 | + | psk-ecdhe-x448 | psk-ecdhe-x448 | + +----------------------------+-------------------------+ + + Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups + mapping to key-negotiation-algorithm + + Note that in Table 1-5: + + o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe- + ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192; + + o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048, + psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe- + ffdhe8192; + + o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1, + ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448; + + o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe- + secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe- + x25519, psk-ecdhe-x448. Features are defined for algorithms that are OPTIONAL or are not widely supported by popular implementations. Note that the list of algorithms is not exhaustive. 5.1. Tree Diagram The following tree diagram [RFC8340] provides an overview of the data model for the "ietf-tls-common" module. @@ -691,21 +992,21 @@ 5.3. YANG Module This YANG module has a normative references to [RFC2246], [RFC4346], [RFC5246], [RFC5288], [RFC5289], and [RFC8422]. This YANG module has a informative references to [RFC2246], [RFC4346], and [RFC5246]. - file "ietf-tls-common@2018-09-20.yang" + file "ietf-tls-common@2018-10-22.yang" module ietf-tls-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; prefix "tlscmn"; organization "IETF NETCONF (Network Configuration) Working Group"; contact @@ -728,21 +1029,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision "2018-09-20" { + revision "2018-10-22" { description "Initial version"; reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } // features feature tls-1_0 { description @@ -1071,25 +1374,31 @@ container cipher-suites { description "Parameters regarding cipher suites."; leaf-list cipher-suite { type identityref { base cipher-suite-base; } ordered-by user; description "Acceptable cipher suites in order of descending - preference. + preference. The configured host key algorithms should + be compatible with the algorithm used by the configured + private key. Please see Section 5 of RFC XXXX for + valid combinations. If this leaf-list is not configured (has zero elements) the acceptable cipher suites are implementation- defined."; + + reference + "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } } } // end hello-params-grouping } 6. Security Considerations @@ -1176,20 +1485,25 @@ name: ietf-tls-common namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common prefix: tlscmn reference: RFC XXXX 8. References 8.1. Normative References + [I-D.ietf-netconf-crypto-types] + Watsen, K., "Common YANG Data Types for Cryptography", + draft-ietf-netconf-crypto-types-01 (work in progress), + September 2018. + [I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a Centralized Keystore Mechanism", draft-ietf-netconf-keystore-06 (work in progress), September 2018. [I-D.ietf-netconf-trust-anchors] Watsen, K., "YANG Data Model for Global Trust Anchors", draft-ietf-netconf-trust-anchors-01 (work in progress), September 2018. @@ -1231,20 +1545,24 @@ Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + 8.2. Informative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . @@ -1337,29 +1655,41 @@ either locally defined or a reference to the keystore. A.7. 06 to 07 o factored the tls-[client|server]-groupings into more reusable groupings. o added if-feature statements for the new "x509-certificates" feature defined in draft-ietf-netconf-trust-anchors. +A.8. 07 to 08 + + o Added a number of compatibility matricies to Section 5 (thanks + Frank!) + + o Claified that any configured "cipher-suite" values need to be + compatible with the configured private key. + Acknowledgements The authors would like to thank for following for lively discussions on list and in the halls (ordered by last name): Andy Bierman, Martin Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. Authors' Addresses Kent Watsen Juniper Networks EMail: kwatsen@juniper.net Gary Wu Cisco Systems EMail: garywu@cisco.com + Liang Xia + Huawei + + EMail: frank.xialiang@huawei.com