draft-ietf-netconf-tls-client-server-14.txt   draft-ietf-netconf-tls-client-server-15.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Watsen Networks Internet-Draft Watsen Networks
Intended status: Standards Track G. Wu Intended status: Standards Track G. Wu
Expires: January 3, 2020 Cisco Systems Expires: April 20, 2020 Cisco Systems
L. Xia L. Xia
Huawei Huawei
July 2, 2019 October 18, 2019
YANG Groupings for TLS Clients and TLS Servers YANG Groupings for TLS Clients and TLS Servers
draft-ietf-netconf-tls-client-server-14 draft-ietf-netconf-tls-client-server-15
Abstract Abstract
This document defines three YANG modules: the first defines groupings This document defines three YANG modules: the first defines groupings
for a generic TLS client, the second defines groupings for a generic for a generic TLS client, the second defines groupings for a generic
TLS server, and the third defines common identities and groupings TLS server, and the third defines common identities and groupings
used by both the client and the server. It is intended that these used by both the client and the server. It is intended that these
groupings will be used by applications using the TLS protocol. groupings will be used by applications using the TLS protocol.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 2, line 5 skipping to change at page 2, line 5
o "XXXX" --> the assigned RFC value for this draft o "XXXX" --> the assigned RFC value for this draft
o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust- o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust-
anchors anchors
o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
o "2019-07-02" --> the publication date of this draft o "2019-10-18" --> the publication date of this draft
The following Appendix section is to be removed prior to publication: The following Appendix section is to be removed prior to publication:
o Appendix A. Change Log o Appendix A. Change Log
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2020. This Internet-Draft will expire on April 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 3, line 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10
4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 18 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 19
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 27 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 28
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 37 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 38
7.2. The YANG Module Names Registry . . . . . . . . . . . . . 38 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 39
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 39
8.2. Informative References . . . . . . . . . . . . . . . . . 40 8.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 43
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 43
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 43
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 43
A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 46
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document defines three YANG 1.1 [RFC7950] modules: the first This document defines three YANG 1.1 [RFC7950] modules: the first
defines a grouping for a generic TLS client, the second defines a defines a grouping for a generic TLS client, the second defines a
grouping for a generic TLS server, and the third defines identities grouping for a generic TLS server, and the third defines identities
and groupings common to both the client and the server (TLS is and groupings common to both the client and the server (TLS is
defined in [RFC5246]). It is intended that these groupings will be defined in [RFC5246]). It is intended that these groupings will be
used by applications using the TLS protocol. For instance, these used by applications using the TLS protocol. For instance, these
groupings could be used to help define the data model for an HTTPS groupings could be used to help define the data model for an HTTPS
skipping to change at page 4, line 30 skipping to change at page 4, line 31
This section provides a tree diagram [RFC8340] for the "ietf-tls- This section provides a tree diagram [RFC8340] for the "ietf-tls-
client" module that does not have groupings expanded. client" module that does not have groupings expanded.
module: ietf-tls-client module: ietf-tls-client
grouping tls-client-grouping grouping tls-client-grouping
+-- client-identity +-- client-identity
| +---u ks:local-or-keystore-end-entity-cert-with-key-grouping | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping
+-- server-authentication +-- server-authentication
| +-- ca-certs? ts:certificates-ref | +-- ca-certs! {ts:x509-certificates}?
| | {ts:x509-certificates}? | | +---u ts:local-or-truststore-certs-grouping
| +-- server-certs? ts:certificates-ref | +-- server-certs! {ts:x509-certificates}?
| {ts:x509-certificates}? | +---u ts:local-or-truststore-certs-grouping
+-- hello-params {tls-client-hello-params-config}? +-- hello-params {tls-client-hello-params-config}?
| +---u tlscmn:hello-params-grouping | +---u tlscmn:hello-params-grouping
+-- keepalives! {tls-client-keepalives}? +-- keepalives! {tls-client-keepalives}?
+-- max-wait? uint16 +-- max-wait? uint16
+-- max-attempts? uint8 +-- max-attempts? uint8
3.2. Example Usage 3.2. Example Usage
This section presents two examples showing the tls-client-grouping This section presents two examples showing the tls-client-grouping
populated with some data. These examples are effectively the same populated with some data. These examples are effectively the same
except the first configures the client identity using a local key except the first configures the client identity using a local key
while the second uses a key configured in a keystore. Both examples while the second uses a key configured in a keystore. Both examples
are consistent with the examples presented in Section 2 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-trust-anchors] and Section 3.2 of
[I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-keystore].
The following example configures the client identity using a local The following example configures the client identity using a local
key: key:
========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client"> <tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client">
<!-- how this client will authenticate itself to the server --> <!-- how this client will authenticate itself to the server -->
<client-identity> <client-identity>
<local-definition> <local-definition>
<algorithm>rsa2048</algorithm> <algorithm>rsa2048</algorithm>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</client-identity> </client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<server-authentication> <server-authentication>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs> <ca-certs>
<server-certs>explicitly-trusted-server-certs</server-certs> <truststore-reference>explicitly-trusted-server-ca-certs</trus\
tstore-reference>
</ca-certs>
<server-certs>
<truststore-reference>explicitly-trusted-server-certs</trustst\
ore-reference>
</server-certs>
</server-authentication> </server-authentication>
<keepalives> <keepalives>
<max-wait>30</max-wait> <max-wait>30</max-wait>
<max-attempts>3</max-attempts> <max-attempts>3</max-attempts>
</keepalives> </keepalives>
</tls-client> </tls-client>
The following example configures the client identity using a key from The following example configures the client identity using a key from
the keystore: the keystore:
========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client"> <tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client">
<!-- how this client will authenticate itself to the server --> <!-- how this client will authenticate itself to the server -->
<client-identity> <client-identity>
<keystore-reference> <keystore-reference>
<asymmetric-key>ex-rsa-key</asymmetric-key> <asymmetric-key>rsa-asymmetric-key</asymmetric-key>
<certificate>ex-rsa-cert</certificate> <certificate>ex-rsa-cert</certificate>
</keystore-reference> </keystore-reference>
</client-identity> </client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<server-authentication> <server-authentication>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs> <ca-certs>
<server-certs>explicitly-trusted-server-certs</server-certs> <truststore-reference>explicitly-trusted-server-ca-certs</trus\
tstore-reference>
</ca-certs>
<server-certs>
<truststore-reference>explicitly-trusted-server-certs</trustst\
ore-reference>
</server-certs>
</server-authentication> </server-authentication>
<keepalives> <keepalives>
<max-wait>30</max-wait> <max-wait>30</max-wait>
<max-attempts>3</max-attempts> <max-attempts>3</max-attempts>
</keepalives> </keepalives>
</tls-client> </tls-client>
3.3. YANG Module 3.3. YANG Module
This YANG module has normative references to This YANG module has normative references to
[I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
<CODE BEGINS> file "ietf-tls-client@2019-07-02.yang" <CODE BEGINS> file "ietf-tls-client@2019-10-18.yang"
module ietf-tls-client { module ietf-tls-client {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
prefix tlsc; prefix tlsc;
import ietf-tls-common { import ietf-tls-common {
prefix tlscmn; prefix tlscmn;
revision-date 2019-07-02; // stable grouping definitions revision-date 2019-10-18; // stable grouping definitions
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
} }
import ietf-truststore { import ietf-truststore {
prefix ts; prefix ts;
reference reference
"RFC YYYY: A YANG Data Model for a Truststore"; "RFC YYYY: A YANG Data Model for a Truststore";
} }
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
skipping to change at page 7, line 49 skipping to change at page 8, line 10
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.; itself for full legal notices.;
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here."; capitals, as shown here.";
revision 2019-07-02 { revision 2019-10-18 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
} }
// Features // Features
feature tls-client-hello-params-config { feature tls-client-hello-params-config {
description description
"TLS hello message parameters are configurable on a TLS "TLS hello message parameters are configurable on a TLS
client."; client.";
skipping to change at page 9, line 4 skipping to change at page 9, line 13
"A locally-defined or referenced end-entity certificate, "A locally-defined or referenced end-entity certificate,
including any configured intermediate certificates, the including any configured intermediate certificates, the
TLS client will present when establishing a TLS connection TLS client will present when establishing a TLS connection
in its Certificate message, as defined in Section 7.4.2 in its Certificate message, as defined in Section 7.4.2
in RFC 5246."; in RFC 5246.";
reference reference
"RFC 5246: "RFC 5246:
The Transport Layer Security (TLS) Protocol Version 1.2 The Transport Layer Security (TLS) Protocol Version 1.2
RFC ZZZZ: RFC ZZZZ:
YANG Data Model for a 'Keystore' Mechanism"; YANG Data Model for a 'Keystore' Mechanism";
uses ks:local-or-keystore-end-entity-cert-with-key-grouping; uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
} // container client-identity } // container client-identity
container server-authentication { // FIXME: what about PSKs? container server-authentication { // FIXME: what about PSKs?
nacm:default-deny-write; nacm:default-deny-write;
must 'ca-certs or server-certs'; must 'ca-certs or server-certs';
description description
"Trusted server identities."; "Trusted server identities.";
leaf ca-certs { container ca-certs {
if-feature "ts:x509-certificates"; if-feature "ts:x509-certificates";
type ts:certificates-ref; presence
"Indicates that the client can authenticate servers
using the configured trust anchor certificates.";
description description
"A reference to a list of certificate authority (CA) "A list of certificate authority (CA) certificates used by
certificates used by the TLS client to authenticate the TLS client to authenticate TLS server certificates.
TLS server certificates. A server certificate is A server certificate is authenticated if it has a valid
authenticated if it has a valid chain of trust to chain of trust to a configured CA certificate.";
a configured CA certificate."; uses ts:local-or-truststore-certs-grouping;
} }
leaf server-certs { container server-certs {
if-feature "ts:x509-certificates"; if-feature "ts:x509-certificates";
type ts:certificates-ref; presence
"Indicates that the client can authenticate servers
using the configured server certificates.";
description description
"A reference to a list of server certificates used by "A list of server certificates used by the TLS client
the TLS client to authenticate TLS server certificates. to authenticate TLS server certificates. A server
A server certificate is authenticated if it is an certificate is authenticated if it is an exact match
exact match to a configured server certificate."; to a configured server certificate.";
uses ts:local-or-truststore-certs-grouping;
} }
} // container server-authentication } // container server-authentication
container hello-params { container hello-params {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "tls-client-hello-params-config"; if-feature "tls-client-hello-params-config";
uses tlscmn:hello-params-grouping; uses tlscmn:hello-params-grouping;
description description
"Configurable parameters for the TLS hello message."; "Configurable parameters for the TLS hello message.";
} // container hello-params } // container hello-params
skipping to change at page 11, line 18 skipping to change at page 11, line 18
+-- server-identity +-- server-identity
| +---u ks:local-or-keystore-end-entity-cert-with-key-grouping | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping
+-- client-authentication! +-- client-authentication!
| +-- (required-or-optional) | +-- (required-or-optional)
| | +--:(required) | | +--:(required)
| | | +-- required? empty | | | +-- required? empty
| | +--:(optional) | | +--:(optional)
| | +-- optional? empty | | +-- optional? empty
| +-- (local-or-external) | +-- (local-or-external)
| +--:(local) {local-client-auth-supported}? | +--:(local) {local-client-auth-supported}?
| | +-- ca-certs? ts:certificates-ref | | +-- ca-certs! {ts:x509-certificates}?
| | | {ts:x509-certificates}? | | | +---u ts:local-or-truststore-certs-grouping
| | +-- client-certs? ts:certificates-ref | | +-- client-certs! {ts:x509-certificates}?
| | {ts:x509-certificates}? | | +---u ts:local-or-truststore-certs-grouping
| +--:(external) {external-client-auth-supported}? | +--:(external) {external-client-auth-supported}?
| +-- client-auth-defined-elsewhere? empty | +-- client-auth-defined-elsewhere? empty
+-- hello-params {tls-server-hello-params-config}? +-- hello-params {tls-server-hello-params-config}?
| +---u tlscmn:hello-params-grouping | +---u tlscmn:hello-params-grouping
+-- keepalives! {tls-server-keepalives}? +-- keepalives! {tls-server-keepalives}?
+-- max-wait? uint16 +-- max-wait? uint16
+-- max-attempts? uint8 +-- max-attempts? uint8
4.2. Example Usage 4.2. Example Usage
skipping to change at page 12, line 5 skipping to change at page 12, line 5
populated with some data. These examples are effectively the same populated with some data. These examples are effectively the same
except the first configures the server identity using a local key except the first configures the server identity using a local key
while the second uses a key configured in a keystore. Both examples while the second uses a key configured in a keystore. Both examples
are consistent with the examples presented in Section 2 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-trust-anchors] and Section 3.2 of
[I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-keystore].
The following example configures the server identity using a local The following example configures the server identity using a local
key: key:
========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server"> <tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server">
<!-- how this server will authenticate itself to the client --> <!-- how this server will authenticate itself to the client -->
<server-identity> <server-identity>
<local-definition> <local-definition>
<algorithm>rsa2048</algorithm> <algorithm>rsa2048</algorithm>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</server-identity> </server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<client-authentication> <client-authentication>
<required/> <required/>
<ca-certs>explicitly-trusted-client-ca-certs</ca-certs> <ca-certs>
<client-certs>explicitly-trusted-client-certs</client-certs> <truststore-reference>explicitly-trusted-client-ca-certs</trus\
tstore-reference>
</ca-certs>
<client-certs>
<truststore-reference>explicitly-trusted-client-certs</trustst\
ore-reference>
</client-certs>
</client-authentication> </client-authentication>
</tls-server> </tls-server>
The following example configures the server identity using a key from The following example configures the server identity using a key from
the keystore: the keystore:
========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server"> <tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server">
<!-- how this server will authenticate itself to the client --> <!-- how this server will authenticate itself to the client -->
<server-identity> <server-identity>
<keystore-reference> <keystore-reference>
<asymmetric-key>ex-rsa-key</asymmetric-key> <asymmetric-key>rsa-asymmetric-key</asymmetric-key>
<certificate>ex-rsa-cert</certificate> <certificate>ex-rsa-cert</certificate>
</keystore-reference> </keystore-reference>
</server-identity> </server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<client-authentication> <client-authentication>
<required/> <required/>
<ca-certs>explicitly-trusted-client-ca-certs</ca-certs> <ca-certs>
<client-certs>explicitly-trusted-client-certs</client-certs> <truststore-reference>explicitly-trusted-client-ca-certs</trus\
tstore-reference>
</ca-certs>
<client-certs>
<truststore-reference>explicitly-trusted-client-certs</trustst\
ore-reference>
</client-certs>
</client-authentication> </client-authentication>
</tls-server> </tls-server>
4.3. YANG Module 4.3. YANG Module
This YANG module has a normative references to [RFC5246], This YANG module has a normative references to [RFC5246],
[I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
<CODE BEGINS> file "ietf-tls-server@2019-07-02.yang" <CODE BEGINS> file "ietf-tls-server@2019-10-18.yang"
module ietf-tls-server { module ietf-tls-server {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
prefix tlss; prefix tlss;
import ietf-tls-common { import ietf-tls-common {
prefix tlscmn; prefix tlscmn;
revision-date 2019-07-02; // stable grouping definitions revision-date 2019-10-18; // stable grouping definitions
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
} }
import ietf-truststore { import ietf-truststore {
prefix ts; prefix ts;
reference reference
"RFC YYYY: A YANG Data Model for a Truststore"; "RFC YYYY: A YANG Data Model for a Truststore";
} }
skipping to change at page 14, line 21 skipping to change at page 15, line 6
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.; itself for full legal notices.;
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here."; capitals, as shown here.";
revision 2019-07-02 { revision 2019-10-18 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
} }
// Features // Features
feature tls-server-hello-params-config { feature tls-server-hello-params-config {
description description
skipping to change at page 16, line 32 skipping to change at page 17, line 17
leaf optional { leaf optional {
type empty; type empty;
description description
"Indicates that TLS-level client authentication is "Indicates that TLS-level client authentication is
optional."; optional.";
} }
} }
choice local-or-external { choice local-or-external {
mandatory true; mandatory true;
description description
"Indicates if the certificates needed to authenticate "Indicates if the certificates needed to authenticate the
the client are configured locally or externally. The client are configured locally or externally.
need to support external configuration for client
authentication stems from the desire to support Configuring certificates externally enables applications
consuming data models that prefer to place client to place client authentication with client definitions,
authentication with client definitions, rather then rather then in a data model principally concerned with
in a data model principally concerned with configuring configuring the transport.";
the transport.";
case local { case local {
if-feature "local-client-auth-supported"; if-feature "local-client-auth-supported";
// must 'ca-certs or server-certs'; (case/must, YANG-Next)
description description
"The certificates needed to authenticate the clients "The certificates needed to authenticate the clients
are configured locally."; are configured withing the TLS configuration.
leaf ca-certs {
How to extract an application-level user name from the
certificate is outside the scope of this data model.";
container ca-certs {
if-feature "ts:x509-certificates"; if-feature "ts:x509-certificates";
type ts:certificates-ref;//FIXME: local-or-remote? presence
"Indicates that the server can authenticate clients
using the configured trust anchor certificates.";
description description
"A reference to a list of certificate authority (CA) "A list of certificate authority (CA) certificates
certificates used by the TLS server to authenticate used by the TLS server to authenticate TLS client
TLS client certificates. A client certificate is certificates. A client certificate is authenticated
authenticated if it has a valid chain of trust to if it has a valid chain of trust to a configured CA
a configured CA certificate."; certificate.";
reference reference
"RFC YYYY: YANG Data Model for Global Trust Anchors"; "RFC YYYY: YANG Data Model for Global Trust Anchors";
uses ts:local-or-truststore-certs-grouping;
} }
leaf client-certs { container client-certs {
if-feature "ts:x509-certificates"; if-feature "ts:x509-certificates";
type ts:certificates-ref;//FIXME: local-or-remote? presence
"Indicates that the server can authenticate clients
using the configured client certificates.";
description description
"A reference to a list of client certificates "A list of client certificates used by the TLS server
used by the TLS server to authenticate TLS to authenticate TLS client certificates. A clients
client certificates. A clients certificate certificate is authenticated if it is an exact match
is authenticated if it is an exact match to to a configured client certificate.";
a configured client certificate.";
reference reference
"RFC YYYY: YANG Data Model for Global Trust Anchors"; "RFC YYYY: YANG Data Model for Global Trust Anchors";
uses ts:local-or-truststore-certs-grouping;
} }
} }
case external { case external {
if-feature "external-client-auth-supported"; if-feature "external-client-auth-supported";
description description
"The certificates needed to authenticate the clients "The certificates needed to authenticate the clients
are configured externally."; are configured externally.";
leaf client-auth-defined-elsewhere { leaf client-auth-defined-elsewhere {
type empty; type empty;
description description
skipping to change at page 27, line 45 skipping to change at page 28, line 45
</hello-params> </hello-params>
5.3. YANG Module 5.3. YANG Module
This YANG module has a normative references to [RFC4346], [RFC5246], This YANG module has a normative references to [RFC4346], [RFC5246],
[RFC5288], [RFC5289], and [RFC8422]. [RFC5288], [RFC5289], and [RFC8422].
This YANG module has a informative references to [RFC2246], This YANG module has a informative references to [RFC2246],
[RFC4346], [RFC5246], and [RFC8446]. [RFC4346], [RFC5246], and [RFC8446].
<CODE BEGINS> file "ietf-tls-common@2019-07-02.yang" <CODE BEGINS> file "ietf-tls-common@2019-10-18.yang"
module ietf-tls-common { module ietf-tls-common {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
prefix tlscmn; prefix tlscmn;
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http://datatracker.ietf.org/wg/netconf/> "WG Web: <http://datatracker.ietf.org/wg/netconf/>
skipping to change at page 28, line 36 skipping to change at page 29, line 37
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.; itself for full legal notices.;
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here."; capitals, as shown here.";
revision 2019-07-02 { revision 2019-10-18 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
} }
// Features // Features
feature tls-1_0 { feature tls-1_0 {
description description
skipping to change at page 38, line 44 skipping to change at page 39, line 44
namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
prefix: tlscmn prefix: tlscmn
reference: RFC XXXX reference: RFC XXXX
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-netconf-crypto-types] [I-D.ietf-netconf-crypto-types]
Watsen, K. and H. Wang, "Common YANG Data Types for Watsen, K. and H. Wang, "Common YANG Data Types for
Cryptography", draft-ietf-netconf-crypto-types-09 (work in Cryptography", draft-ietf-netconf-crypto-types-10 (work in
progress), June 2019. progress), July 2019.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", draft- Watsen, K., "A YANG Data Model for a Keystore", draft-
ietf-netconf-keystore-11 (work in progress), June 2019. ietf-netconf-keystore-12 (work in progress), July 2019.
[I-D.ietf-netconf-trust-anchors] [I-D.ietf-netconf-trust-anchors]
Watsen, K., "A YANG Data Model for a Truststore", draft- Watsen, K., "A YANG Data Model for a Truststore", draft-
ietf-netconf-trust-anchors-05 (work in progress), June ietf-netconf-trust-anchors-05 (work in progress), June
2019. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 45, line 13 skipping to change at page 46, line 13
o Updated examples to reflect change grouping in keystore module. o Updated examples to reflect change grouping in keystore module.
A.15. 13 to 14 A.15. 13 to 14
o Removed the "certificate" container from "client-identity" in the o Removed the "certificate" container from "client-identity" in the
ietf-tls-client module. ietf-tls-client module.
o Updated examples to reflect ietf-crypto-types change (e.g., o Updated examples to reflect ietf-crypto-types change (e.g.,
identities --> enumerations) identities --> enumerations)
A.16. 14 to 15
o Updated "server-authentication" and "client-authentication" nodes
from being a leaf of type "ts:certificates-ref" to a container
that uses "ts:local-or-truststore-certs-grouping".
Acknowledgements Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Andy Bierman, Martin on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
Authors' Addresses Authors' Addresses
 End of changes. 48 change blocks. 
102 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/