--- 1/draft-ietf-netconf-tls-client-server-11.txt 2019-04-29 20:14:25.602385941 -0700 +++ 2/draft-ietf-netconf-tls-client-server-12.txt 2019-04-29 20:14:25.682387967 -0700 @@ -1,21 +1,21 @@ NETCONF Working Group K. Watsen Internet-Draft Watsen Networks Intended status: Standards Track G. Wu -Expires: October 9, 2019 Cisco Systems +Expires: October 31, 2019 Cisco Systems L. Xia Huawei - April 7, 2019 + April 29, 2019 YANG Groupings for TLS Clients and TLS Servers - draft-ietf-netconf-tls-client-server-11 + draft-ietf-netconf-tls-client-server-12 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) @@ -40,42 +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 "2019-04-07" --> the publication date of this draft + o "2019-04-29" --> 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 October 9, 2019. + This Internet-Draft will expire on October 31, 2019. Copyright Notice Copyright (c) 2019 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 @@ -84,51 +84,52 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 - 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 17 - 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 26 - 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 26 - 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 36 - 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 37 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 8.2. Informative References . . . . . . . . . . . . . . . . . 39 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41 - A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 41 - A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 41 - A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 41 - A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 41 - A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 42 - A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 42 - A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 42 - A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 42 - A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 42 - A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 42 - A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 43 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 + 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 18 + 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 + 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 27 + 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 37 + 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 38 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 8.2. Informative References . . . . . . . . . . . . . . . . . 40 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 + A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 42 + A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 42 + A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 42 + A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 42 + A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 43 + A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 43 + A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 43 + A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 43 + A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 43 + A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 43 + A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 44 + A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 44 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 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 @@ -161,138 +162,134 @@ 3.1. Tree Diagram This section provides a tree diagram [RFC8340] for the "ietf-tls- client" module that does not have groupings expanded. =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== module: ietf-tls-client grouping tls-client-grouping - +-- tls-client-parameters +-- client-identity | +-- (auth-type)? | +--:(certificate) | +-- certificate - | +---u ks:local-or-keystore-end-entity-cert-with-k\ - ey-grouping + | +---u ks:local-or-keystore-end-entity-cert-with-key-\ + grouping +-- server-authentication | +-- pinned-ca-certs? ta:pinned-certificates-ref | | {ta:x509-certificates}? | +-- pinned-server-certs? ta:pinned-certificates-ref | {ta:x509-certificates}? +-- hello-params {tls-client-hello-params-config}? | +---u tlscmn:hello-params-grouping +-- keepalives! {tls-client-keepalives}? +-- max-wait? uint16 +-- max-attempts? uint8 3.2. Example Usage This section presents two examples showing the tls-client-grouping populated with some data. These examples are effectively the same except the first configures the client identity using a local key while the second uses a key configured in a keystore. Both examples - are consistent with the examples presented in Section 3 of + are consistent with the examples presented in Section 2 of [I-D.ietf-netconf-trust-anchors] and Section 3.2 of [I-D.ietf-netconf-keystore]. The following example configures the client identity using a local key: =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== - - ct:rsa2048 + ct:rsa2048 base64encodedvalue== base64encodedvalue== base64encodedvalue== - explicitly-trusted-server-ca-certs - explicitly-trusted-server-certs + explicitly-trusted-server-ca-certs + explicitly-trusted-server-certs 30 3 - The following example configures the client identity using a key from the keystore: =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== - ex-rsa-cert - explicitly-trusted-server-ca-certs - explicitly-trusted-server-certs + explicitly-trusted-server-ca-certs + explicitly-trusted-server-certs 30 3 - 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@2019-04-07.yang" + file "ietf-tls-client@2019-04-29.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 2019-04-07; // stable grouping definitions + revision-date 2019-04-29; // 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"; + } import ietf-keystore { prefix ks; reference "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; } import ietf-netconf-acm { prefix nacm; @@ -327,21 +324,21 @@ (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices.; The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision 2019-04-07 { + revision 2019-04-29 { description "Initial version"; reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } // Features feature tls-client-hello-params-config { description @@ -354,48 +351,53 @@ "Per socket TLS keepalive parameters are configurable for TLS clients on the server implementing this feature."; } // Groupings grouping tls-client-grouping { description "A reusable grouping for configuring a TLS client without any consideration for how an underlying TCP session is - established."; - - container tls-client-parameters { - nacm:default-deny-write; + established. - description - "A container to hold TLS client configuration."; + Note that this grouping uses fairly typical descendent + node names such that a stack of 'uses' statements will + have name conflicts. It is intended that the consuming + data model will resolve the issue (e.g., by wrapping + the 'uses' statement in a container called + 'tls-client-parameters'). This model purposely does + not do this itself so as to provide maximum flexibility + to consuming models."; container client-identity { + nacm:default-deny-write; 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-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"; } } } // container client-identity container server-authentication { + nacm:default-deny-write; must 'pinned-ca-certs or pinned-server-certs'; description "Trusted server identities."; leaf pinned-ca-certs { if-feature "ta:x509-certificates"; type ta:pinned-certificates-ref; description "A reference to a list of certificate authority (CA) certificates used by the TLS client to authenticate TLS server certificates. A server certificate is @@ -407,35 +409,36 @@ type ta:pinned-certificates-ref; description "A reference to a list of server certificates used by the TLS client to authenticate TLS server certificates. A server certificate is authenticated if it is an exact match to a configured pinned server certificate."; } } // container server-authentication container hello-params { + nacm:default-deny-write; if-feature "tls-client-hello-params-config"; uses tlscmn:hello-params-grouping; description "Configurable parameters for the TLS hello message."; } // container hello-params container keepalives { + nacm:default-deny-write; if-feature "tls-client-keepalives"; presence "Indicates that keepalives are enabled."; description "Configures the keep-alive policy, to proactively test the aliveness of the TLS server. An unresponsive TLS server is dropped after approximately max-wait * max-attempts seconds."; - leaf max-wait { type uint16 { range "1..max"; } units "seconds"; default "30"; description "Sets the amount of time in seconds after which if no data has been received from the TLS server, a TLS-level message will be sent to test the @@ -444,130 +447,134 @@ leaf max-attempts { type uint8; default "3"; description "Sets the maximum number of sequential keep-alive messages that can fail to obtain a response from the TLS server before assuming the TLS server is no longer alive."; } } // container keepalives - } // container tls-client-parameters } // grouping tls-client-grouping } 4. The TLS Server Model 4.1. Tree Diagram This section provides a tree diagram [RFC8340] for the "ietf-tls- server" module that does not have groupings expanded. - =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== - module: ietf-tls-server grouping tls-server-grouping - +-- tls-server-parameters +-- server-identity - | +---u ks:local-or-keystore-end-entity-cert-with-key-groupi\ - ng - +-- client-authentication - | +-- pinned-ca-certs? ta:pinned-certificates-ref + | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping + +-- client-authentication! + | +-- (required-or-optional) + | | +--:(required) + | | | +-- required? empty + | | +--:(optional) + | | +-- optional? empty + | +-- (local-or-external) + | +--:(local) {local-client-auth-supported}? + | | +-- pinned-ca-certs? + | | | ta:pinned-certificates-ref + | | | {ta:x509-certificates}? + | | +-- pinned-client-certs? + | | ta:pinned-certificates-ref | | {ta:x509-certificates}? - | +-- pinned-client-certs? ta:pinned-certificates-ref - | {ta:x509-certificates}? + | +--:(external) {external-client-auth-supported}? + | +-- client-auth-defined-elsewhere? empty +-- hello-params {tls-server-hello-params-config}? | +---u tlscmn:hello-params-grouping +-- keepalives! {tls-server-keepalives}? +-- max-wait? uint16 +-- max-attempts? uint8 4.2. Example Usage This section presents two examples showing the tls-server-grouping populated with some data. These examples are effectively the same except the first configures the server identity using a local key while the second uses a key configured in a keystore. Both examples - are consistent with the examples presented in Section 3 of + are consistent with the examples presented in Section 2 of [I-D.ietf-netconf-trust-anchors] and Section 3.2 of [I-D.ietf-netconf-keystore]. The following example configures the server identity using a local key: =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== - - ct:rsa2048 + ct:rsa2048 base64encodedvalue== base64encodedvalue== base64encodedvalue== - explicitly-trusted-client-ca-certs - explicitly-trusted-client-certs + + explicitly-trusted-client-ca-certs + explicitly-trusted-client-certs - The following example configures the server identity using a key from the keystore: =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== - ex-rsa-cert - explicitly-trusted-client-ca-certs - explicitly-trusted-client-certs + + 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@2019-04-07.yang" + file "ietf-tls-server@2019-04-29.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 2019-04-07; // stable grouping definitions + revision-date 2019-04-29; // 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"; } @@ -610,26 +617,25 @@ (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices.; The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision 2019-04-07 { + revision 2019-04-29 { description "Initial version"; reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; - } // Features feature tls-server-hello-params-config { description "TLS hello message parameters are configurable on a TLS server."; } @@ -632,87 +638,165 @@ "TLS hello message parameters are configurable on a TLS server."; } feature tls-server-keepalives { description "Per socket TLS keepalive parameters are configurable for TLS servers on the server implementing this feature."; } + feature local-client-auth-supported { + description + "Indicates that the TLS server supports local + configuration of client credentials."; + } + feature external-client-auth-supported { + description + "Indicates that the TLS server supports external + configuration of client credentials."; + } + // Groupings grouping tls-server-grouping { description "A reusable grouping for configuring a TLS server without any consideration for how underlying TCP sessions are - established."; - - container tls-server-parameters { - nacm:default-deny-write; + established. - description - "A container to hold TLS server configuration."; + Note that this grouping uses fairly typical descendent + node names such that a stack of 'uses' statements will + have name conflicts. It is intended that the consuming + data model will resolve the issue (e.g., by wrapping + the 'uses' statement in a container called + 'tls-server-parameters'). This model purposely does + not do this itself so as to provide maximum flexibility + to consuming models."; - container server-identity { + container server-identity { // FIXME: what about PSKs? + nacm:default-deny-write; description "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-cert-with-key-grouping; } // container server-identity - container client-authentication { + container client-authentication { // FIXME: what about PSKs? + nacm:default-deny-write; + presence + "Indicates that certificate based client authentication + is supported (i.e., the server will request that the + client send a certificate)."; + description - "A reference to a list of pinned certificate authority (CA) - certificates and a reference to a list of pinned client - certificates."; + "Specifies if TLS client authentication is required or + optional, and specifies if the certificates needed to + authenticate the TLS client are configured locally or + externally. If configured locally, the data model + enables both trust anchors and end-entity certificate + to be set."; + choice required-or-optional { + mandatory true; // or default to 'required' ? + description + "Indicates if TLS-level client authentication is required + or optional. This is necessary for some protocols (e.g., + RESTCONF) the may optionally authenticate a client via + TLS-level authentication, HTTP-level authentication, or + both simultaneously)."; + leaf required { + type empty; + description + "Indicates that TLS-level client authentication is + required."; + } + leaf optional { + type empty; + description + "Indicates that TLS-level client authentication is + optional."; + } + } + choice local-or-external { + mandatory true; + description + "Indicates if the certificates needed to authenticate + the client are configured locally or externally. The + need to support external configuration for client + authentication stems from the desire to support + consuming data models that prefer to place client + authentication with client definitions, rather then + in a data model principally concerned with configuring + the transport."; + case local { + if-feature "local-client-auth-supported"; + description + "The certificates needed to authenticate the clients + are configured locally."; leaf pinned-ca-certs { if-feature "ta:x509-certificates"; - type ta:pinned-certificates-ref; + type ta:pinned-certificates-ref;//FIXME: local-or-remote? description "A reference to a list of certificate authority (CA) certificates used by the TLS server to authenticate TLS client certificates. A client certificate is authenticated if it has a valid chain of trust to a configured pinned CA certificate."; reference "RFC YYYY: YANG Data Model for Global Trust Anchors"; } leaf pinned-client-certs { if-feature "ta:x509-certificates"; - type ta:pinned-certificates-ref; + type ta:pinned-certificates-ref;//FIXME: local-or-remote? description - "A reference to a list of client certificates used by - the TLS server to authenticate TLS client certificates. - A clients certificate is authenticated if it is an - exact match to a configured pinned client certificate."; + "A reference to a list of client certificates + used by the TLS server to authenticate TLS + client certificates. A clients certificate + is authenticated if it is an exact match to + a configured pinned client certificate."; reference "RFC YYYY: YANG Data Model for Global Trust Anchors"; } + } + case external { + if-feature "external-client-auth-supported"; + description + "The certificates needed to authenticate the clients + are configured externally."; + leaf client-auth-defined-elsewhere { + type empty; + description + "Indicates that certificates needed to authenticate + clients are configured elsewhere."; + } + } + } // choice local-or-external } // container client-authentication container hello-params { + nacm:default-deny-write; if-feature "tls-server-hello-params-config"; uses tlscmn:hello-params-grouping; description "Configurable parameters for the TLS hello message."; } // container hello-params container keepalives { + nacm:default-deny-write; if-feature "tls-server-keepalives"; presence "Indicates that keepalives are enabled."; description "Configures the keep-alive policy, to proactively test the aliveness of the TLS client. An unresponsive TLS client is dropped after approximately max-wait * max-attempts seconds."; leaf max-wait { type uint16 { range "1..max"; @@ -728,21 +812,20 @@ leaf max-attempts { type uint8; default "3"; description "Sets the maximum number of sequential keep-alive messages that can fail to obtain a response from the TLS client before assuming the TLS client is no longer alive."; } } // container keepalives - } // container tls-server-parameters } // grouping tls-server-grouping } 5. The TLS Common Model 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 @@ -1088,21 +1171,21 @@ 5.3. YANG Module This YANG module has a normative references to [RFC4346], [RFC5246], [RFC5288], [RFC5289], and [RFC8422]. This YANG module has a informative references to [RFC2246], [RFC4346], [RFC5246], and [RFC8446]. - file "ietf-tls-common@2019-04-07.yang" + file "ietf-tls-common@2019-04-29.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 "WG Web: @@ -1128,21 +1211,21 @@ (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices.; The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision 2019-04-07 { + revision 2019-04-29 { description "Initial version"; reference "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; } // Features feature tls-1_0 { description @@ -1823,20 +1906,41 @@ section. o Added "presence" statements on the "keepalive" containers, as was needed to address a validation error that appeared after adding the "must" statements into the NETCONF/RESTCONF client/server modules. o Updated the boilerplate text in module-level "description" statement to match copyeditor convention. +A.12. 11 to 12 + + o In server model, made 'client-authentication' a 'presence' node + indicating that the server supports client authentication. + + o In the server model, added a 'required-or-optional' choice to + 'client-authentication' to better support protocols such as + RESTCONF. + + o In the server model, added a 'local-or-external' choice to + 'client-authentication' to better support consuming data models + that prefer to keep client auth with client definitions than in a + model principally concerned with the "transport". + + o In both models, removed the "demux containers", floating the + nacm:default-deny-write to each descendent node, and adding a note + to model designers regarding the potential need to add their own + demux containers. + + o Fixed a couple references (section 2 --> section 3) + 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