draft-ietf-netconf-tls-client-server-18.txt   draft-ietf-netconf-tls-client-server-19.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: September 9, 2020 Cisco Systems Expires: November 21, 2020 Cisco Systems
L. Xia May 20, 2020
Huawei
March 8, 2020
YANG Groupings for TLS Clients and TLS Servers YANG Groupings for TLS Clients and TLS Servers
draft-ietf-netconf-tls-client-server-18 draft-ietf-netconf-tls-client-server-19
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)
This draft contains many placeholder values that need to be replaced This draft contains placeholder values that need to be replaced with
with finalized values at the time of publication. This note finalized values at the time of publication. This note summarizes
summarizes all of the substitutions that are needed. No other RFC all of the substitutions that are needed. No other RFC Editor
Editor instructions are specified elsewhere in this document. instructions are specified elsewhere in this document.
This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their
final RFC assignments:
o I-D.ietf-netconf-trust-anchors
o I-D.ietf-netconf-keystore
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto-
types
o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust- o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust-
anchors anchors
o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore
o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp-
client-server
o "FFFF" --> the assigned RFC value for this draft
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 "2020-03-08" --> the publication date of this draft o "2020-05-20" --> 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
Note to Reviewers (To be removed by RFC Editor)
This document presents a YANG module or modules that is/are part of a
collection of drafts that work together to produce the ultimate goal
of the NETCONF WG: to define configuration modules for NETCONF client
and servers, and RESTCONF client and servers.
The relationship between the various drafts in the collection is
presented in the below diagram.
crypto-types
^ ^
/ \
/ \
trust-anchors keystore
^ ^ ^ ^
| +---------+ | |
| | | |
| +------------+ |
tcp-client-server | / | |
^ ^ ssh-client-server | |
| | ^ tls-client-server
| | | ^ ^ http-client-server
| | | | | ^
| | | +-----+ +---------+ |
| | | | | |
| +-----------|--------|--------------+ | |
| | | | | |
+-----------+ | | | | |
| | | | | |
| | | | | |
netconf-client-server restconf-client-server
Full draft names and link to drafts:
o draft-ietf-netconf-crypto-types (html [1])
o draft-ietf-netconf-trust-anchors (html [2])
o draft-ietf-netconf-keystore (html [3])
o draft-ietf-netconf-tcp-client-server (html [4])
o draft-ietf-netconf-ssh-client-server (html [5])
o draft-ietf-netconf-tls-client-server (html [6])
o draft-ietf-netconf-http-client-server (html [7])
o draft-ietf-netconf-netconf-client-server (html [8])
o draft-ietf-netconf-restconf-client-server (html [9])
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 September 9, 2020. This Internet-Draft will expire on November 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 5
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10
4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 16
4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 16 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 17
4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 17
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 18
5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 27 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 36 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 29
5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 36 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 30
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 46 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
7.2. The YANG Module Names Registry . . . . . . . . . . . . . 47 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 42
8.1. Normative References . . . . . . . . . . . . . . . . . . 47 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 51 8.2. Informative References . . . . . . . . . . . . . . . . . 44
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 51 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 46
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 51 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 51 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 52 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 52 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 52 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 52 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 52 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 52 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 53 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 53 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 53 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 53 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 54 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 54 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 54 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 49
A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 54 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 49
A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 54 A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55 A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 49
A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 5, line 25 skipping to change at page 6, line 25
grouping grouping
| +--:(raw-public-key) {raw-public-key-auth}? | +--:(raw-public-key) {raw-public-key-auth}?
| | +-- raw-private-key | | +-- raw-private-key
| | +---u ks:local-or-keystore-asymmetric-key-grouping | | +---u ks:local-or-keystore-asymmetric-key-grouping
| +--:(psk) {psk-auth}? | +--:(psk) {psk-auth}?
| +-- psk | +-- psk
| +---u ks:local-or-keystore-symmetric-key-grouping | +---u ks:local-or-keystore-symmetric-key-grouping
+-- server-authentication +-- server-authentication
| +-- ca-certs! {x509-certificate-auth}? | +-- ca-certs! {x509-certificate-auth}?
| | +---u ts:local-or-truststore-certs-grouping | | +---u ts:local-or-truststore-certs-grouping
| +-- server-certs! {x509-certificate-auth}? | +-- ee-certs! {x509-certificate-auth}?
| | +---u ts:local-or-truststore-certs-grouping | | +---u ts:local-or-truststore-certs-grouping
| +-- raw-public-keys! {raw-public-key-auth}? | +-- raw-public-keys! {raw-public-key-auth}?
| | +---u ts:local-or-truststore-public-keys-grouping | | +---u ts:local-or-truststore-public-keys-grouping
| +-- psks! {psk-auth}? | +-- psks! {psk-auth}?
+-- 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 +-- peer-allowed-to-send? empty
+-- max-attempts? uint8 +-- test-peer-aliveness!
+-- max-wait? uint16
+-- 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 grouping populated with some data. These examples are effectively
except the first configures the client identity using a local key the same except the first configures the client identity using a
while the second uses a key configured in a keystore. Both examples local key while the second uses a key configured in a keystore. Both
are consistent with the examples presented in Section 2 of examples 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) =========== ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<tls-client <tls-client
xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client" xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<!-- how this client will authenticate itself to the server --> <!-- how this client will authenticate itself to the server -->
<client-identity> <client-identity>
<certificate> <certificate>
<local-definition> <local-definition>
<algorithm>rsa2048</algorithm>
<public-key-format>ct:subject-public-key-info-format</public\ <public-key-format>ct:subject-public-key-info-format</public\
-key-format> -key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key-format>ct:rsa-private-key-format</private-key-f\ <private-key-format>ct:rsa-private-key-format</private-key-f\
ormat> ormat>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</certificate> </certificate>
<!-- TESTED, BUT COMMENTED OUT DUE TO ONLY ONE ALLOWED AT A TIME <!-- TESTED, BUT COMMENTED OUT DUE TO ONLY ONE ALLOWED AT A TIME
<raw-private-key> <raw-private-key>
<local-definition> <local-definition>
<algorithm>rsa2048</algorithm>
<public-key-format>ct:subject-public-key-info-format</public\ <public-key-format>ct:subject-public-key-info-format</public\
-key-format> -key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key-format>ct:rsa-private-key-format</private-key-f\ <private-key-format>ct:rsa-private-key-format</private-key-f\
ormat> ormat>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
</local-definition> </local-definition>
</raw-private-key> </raw-private-key>
<psk> <psk>
<local-definition> <local-definition>
<algorithm>aes-256-cbc</algorithm>
<key-format>ct:octet-string-key-format</key-format> <key-format>ct:octet-string-key-format</key-format>
<key>base64encodedvalue==</key> <key>base64encodedvalue==</key>
</local-definition> </local-definition>
</psk> </psk>
--> -->
</client-identity> </client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<server-authentication> <server-authentication>
<ca-certs> <ca-certs>
<local-definition> <local-definition>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</ca-certs> </ca-certs>
<server-certs> <ee-certs>
<local-definition> <local-definition>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</server-certs> </ee-certs>
<raw-public-keys> <raw-public-keys>
<local-definition> <local-definition>
<public-key> <public-key>
<name>corp-fw1</name> <name>corp-fw1</name>
<algorithm>secp256r1</algorithm>
<public-key-format>ct:subject-public-key-info-format</publ\ <public-key-format>ct:subject-public-key-info-format</publ\
ic-key-format> ic-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
</public-key> </public-key>
<public-key> <public-key>
<name>corp-fw1</name> <name>corp-fw1</name>
<algorithm>secp256r1</algorithm>
<public-key-format>ct:subject-public-key-info-format</publ\ <public-key-format>ct:subject-public-key-info-format</publ\
ic-key-format> ic-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
</public-key> </public-key>
</local-definition> </local-definition>
</raw-public-keys> </raw-public-keys>
<psks/> <psks/>
</server-authentication> </server-authentication>
<keepalives> <keepalives>
<max-wait>30</max-wait> <test-peer-aliveness>
<max-attempts>3</max-attempts> <max-wait>30</max-wait>
<max-attempts>3</max-attempts>
</test-peer-aliveness>
</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) =========== ========== 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">
skipping to change at page 8, line 34 skipping to change at page 9, line 34
</psk> </psk>
--> -->
</client-identity> </client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<server-authentication> <server-authentication>
<ca-certs> <ca-certs>
<truststore-reference>trusted-server-ca-certs</truststore-refe\ <truststore-reference>trusted-server-ca-certs</truststore-refe\
rence> rence>
</ca-certs> </ca-certs>
<server-certs> <ee-certs>
<truststore-reference>trusted-server-ee-certs</truststore-refe\ <truststore-reference>trusted-server-ee-certs</truststore-refe\
rence> rence>
</server-certs> </ee-certs>
<raw-public-keys> <raw-public-keys>
<truststore-reference>Raw Public Keys for Servers</truststore-\ <truststore-reference>Raw Public Keys for TLS Servers</trustst\
reference> ore-reference>
</raw-public-keys> </raw-public-keys>
<psks/> <psks/>
</server-authentication> </server-authentication>
<keepalives> <keepalives>
<max-wait>30</max-wait> <test-peer-aliveness>
<max-attempts>3</max-attempts> <max-wait>30</max-wait>
<max-attempts>3</max-attempts>
</test-peer-aliveness>
</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@2020-03-08.yang" <CODE BEGINS> file "ietf-tls-client@2020-05-20.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-netconf-acm {
prefix tlscmn; prefix nacm;
revision-date 2020-03-08; // stable grouping definitions
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC 8341: Network Configuration Access Control Model";
} }
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"RFC AAAA: Common YANG Data Types for Cryptography"; "RFC AAAA: Common YANG Data Types for Cryptography";
} }
import ietf-truststore { import ietf-truststore {
prefix ts; prefix ts;
reference reference
"RFC BBBB: A YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
} }
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
reference reference
"RFC CCCC: A YANG Data Model for a Keystore"; "RFC CCCC: A YANG Data Model for a Keystore";
} }
import ietf-netconf-acm { import ietf-tls-common {
prefix nacm; prefix tlscmn;
revision-date 2020-05-20; // stable grouping definitions
reference reference
"RFC 8341: Network Configuration Access Control Model"; "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
} }
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/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net> Author: Kent Watsen <mailto:kent+ietf@watsen.net>
Author: Gary Wu <mailto:garywu@cisco.com>"; Author: Gary Wu <mailto:garywu@cisco.com>";
description description
"This module defines reusable groupings for TLS clients that "This module defines reusable groupings for TLS clients that
can be used as a basis for specific TLS client instances. can be used as a basis for specific TLS client instances.
Copyright (c) 2019 IETF Trust and the persons identified Copyright (c) 2020 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC FFFF
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcFFFF); 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 2020-03-08 { revision 2020-05-20 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC FFFF: 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 12, line 7 skipping to change at page 13, line 7
description description
"Identity credentials the TLS client MAY present when "Identity credentials the TLS client MAY present when
establishing a connection to a TLS server. If not establishing a connection to a TLS server. If not
configured, then client authentication is presumed to configured, then client authentication is presumed to
occur a protocol layer above TLS. When configured, occur a protocol layer above TLS. When configured,
and requested by the TLS server when establishing a and requested by the TLS server when establishing a
TLS session, these credentials are passed in the TLS session, these credentials are passed in the
Certificate message defined in Section 7.4.2 of Certificate message defined in Section 7.4.2 of
RFC 5246."; RFC 5246.";
reference reference
"RFC 5246: "RFC 5246: The Transport Layer Security (TLS) Protocol
The Transport Layer Security (TLS) Protocol Version 1.2 Version 1.2
RFC ZZZZ: RFC CCCC: A YANG Data Model for a Keystore";
YANG Data Model for a 'Keystore' Mechanism";
choice auth-type { choice auth-type {
description description
"A choice amongst available authentication types."; "A choice amongst available authentication types.";
case certificate { case certificate {
if-feature x509-certificate-auth; if-feature x509-certificate-auth;
container certificate { container certificate {
description description
"Specifies the client identity using a certificate."; "Specifies the client identity using a certificate.";
uses uses
ks:local-or-keystore-end-entity-cert-with-key-grouping{ ks:local-or-keystore-end-entity-cert-with-key-grouping{
skipping to change at page 13, line 19 skipping to change at page 14, line 18
or pairwise-symmetric key). Note that, when the PSK is or pairwise-symmetric key). Note that, when the PSK is
configured as a Keystore reference, the key's 'name' configured as a Keystore reference, the key's 'name'
node MAY be used as the PSK's ID when used by the TLS node MAY be used as the PSK's ID when used by the TLS
protocol."; protocol.";
uses ks:local-or-keystore-symmetric-key-grouping { uses ks:local-or-keystore-symmetric-key-grouping {
augment "local-or-keystore/local/local-definition" { augment "local-or-keystore/local/local-definition" {
if-feature "ks:local-definitions-supported"; if-feature "ks:local-definitions-supported";
description description
"Adds an 'id' value when the PSK is used by TLS."; "Adds an 'id' value when the PSK is used by TLS.";
leaf id { leaf id {
type string; // is this the right type? type string; // FIXME: is this the right type?
description description
"The key id used in the TLS protocol for PSKs."; "The key id used in the TLS protocol for PSKs.";
} }
} }
} }
} }
} }
} }
} // container client-identity } // container client-identity
skipping to change at page 14, line 4 skipping to change at page 14, line 51
if-feature "x509-certificate-auth"; if-feature "x509-certificate-auth";
presence presence
"Indicates that the TLS client can authenticate TLS servers "Indicates that the TLS client can authenticate TLS servers
using configured certificate authority certificates."; using configured certificate authority certificates.";
description description
"A set of certificate authority (CA) certificates used by "A set of certificate authority (CA) certificates used by
the TLS client to authenticate TLS server certificates. the TLS client to authenticate TLS server certificates.
A server certificate is authenticated if it has a valid A server certificate is authenticated if it has a valid
chain of trust to a configured CA certificate."; chain of trust to a configured CA certificate.";
reference reference
"RFC YYYY: YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
uses ts:local-or-truststore-certs-grouping; uses ts:local-or-truststore-certs-grouping;
// Note: TS certs don't have a key-format...no test needed
} }
container server-certs { container ee-certs { // FIXME: plural too much?
// FIXME: plural too much? rename to ee-certs?
if-feature "x509-certificate-auth"; if-feature "x509-certificate-auth";
presence presence
"Indicates that the TLS client can authenticate TLS "Indicates that the TLS client can authenticate TLS
servers using configured server certificates."; servers using configured server certificates.";
description description
"A set of server certificates (i.e., end entity "A set of server certificates (i.e., end entity
certificates) used by the TLS client to authenticate certificates) used by the TLS client to authenticate
certificates presented by TLS servers. A server certificates presented by TLS servers. A server
certificate is authenticated if it is an exact certificate is authenticated if it is an exact
match to a configured server certificate."; match to a configured server certificate.";
reference reference
"RFC YYYY: YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
uses ts:local-or-truststore-certs-grouping; uses ts:local-or-truststore-certs-grouping;
// Note: TS certs don't have a key-format...no test needed
} }
container raw-public-keys { container raw-public-keys {
if-feature "raw-public-key-auth"; if-feature "raw-public-key-auth";
presence presence
"Indicates that the TLS client can authenticate TLS "Indicates that the TLS client can authenticate TLS
servers using configured server certificates."; servers using configured server certificates.";
description description
"A set of raw public keys used by the TLS client to "A set of raw public keys used by the TLS client to
authenticate raw public keys presented by the TLS authenticate raw public keys presented by the TLS
server. A raw public key is authenticated if it server. A raw public key is authenticated if it
is an exact match to a configured raw public key."; is an exact match to a configured raw public key.";
reference reference
"RFC YYYY: YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
uses ts:local-or-truststore-public-keys-grouping { uses ts:local-or-truststore-public-keys-grouping {
refine "local-or-truststore/local/local-definition" refine "local-or-truststore/local/local-definition"
+ "/public-key" { + "/public-key" {
must 'public-key-format' must 'public-key-format'
+ ' = "ct:subject-public-key-info-format"'; + ' = "ct:subject-public-key-info-format"';
} }
refine "local-or-truststore/truststore" refine "local-or-truststore/truststore"
+ "/truststore-reference" { + "/truststore-reference" {
must 'deref(.)/../*/ts:public-key-format' must 'deref(.)/../*/ts:public-key-format'
+ ' = "ct:subject-public-key-info-format"'; + ' = "ct:subject-public-key-info-format"';
skipping to change at page 15, line 26 skipping to change at page 16, line 23
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
container keepalives { container keepalives {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "tls-client-keepalives"; if-feature "tls-client-keepalives";
presence "Indicates that keepalives are enabled.";
description description
"Configures the keep-alive policy, to proactively test "Configures the keepalive policy for the TLS client.";
the aliveness of the TLS server. An unresponsive leaf peer-allowed-to-send {
TLS server is dropped after approximately max-wait type empty;
* max-attempts seconds.";
leaf max-wait {
type uint16 {
range "1..max";
}
units "seconds";
default "30";
description description
"Sets the amount of time in seconds after which if "Indicates that the remote TLS server is allowed to send
no data has been received from the TLS server, a HeartbeatRequest messages, as defined by RFC 6520
TLS-level message will be sent to test the to this TLS client.";
aliveness of the TLS server."; reference
"RFC 6520: Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) Heartbeat Extension";
} }
leaf max-attempts { container test-peer-aliveness {
type uint8; presence
default "3"; "Indicates that the TLS client proactively tests the
aliveness of the remote TLS server.";
description description
"Sets the maximum number of sequential keep-alive "Configures the keep-alive policy to proactively test
messages that can fail to obtain a response from the aliveness of the TLS server. An unresponsive
the TLS server before assuming the TLS server is TLS server is dropped after approximately max-wait
no longer alive."; * max-attempts seconds. The TLS client MUST send
HeartbeatRequest messages, as defined by RFC 6520.";
reference
"RFC 6520: Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) Heartbeat Extension";
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
aliveness of the TLS server.";
}
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.";
}
} }
} }
} // grouping tls-client-grouping } // grouping tls-client-grouping
} // module ietf-tls-client } // module ietf-tls-client
<CODE ENDS> <CODE ENDS>
4. The TLS Server Model 4. The TLS Server Model
4.1. Tree Diagram 4.1. Tree Diagram
skipping to change at page 16, line 39 skipping to change at page 18, line 25
grouping grouping
| +--:(raw-private-key) {raw-public-key-auth}? | +--:(raw-private-key) {raw-public-key-auth}?
| | +-- raw-private-key | | +-- raw-private-key
| | +---u ks:local-or-keystore-asymmetric-key-grouping | | +---u ks:local-or-keystore-asymmetric-key-grouping
| +--:(psk) {psk-auth}? | +--:(psk) {psk-auth}?
| +-- psk | +-- psk
| +---u ks:local-or-keystore-symmetric-key-grouping | +---u ks:local-or-keystore-symmetric-key-grouping
+-- client-authentication! {client-auth-config-supported}? +-- client-authentication! {client-auth-config-supported}?
| +-- ca-certs! {x509-certificate-auth}? | +-- ca-certs! {x509-certificate-auth}?
| | +---u ts:local-or-truststore-certs-grouping | | +---u ts:local-or-truststore-certs-grouping
| +-- client-certs! {x509-certificate-auth}? | +-- ee-certs! {x509-certificate-auth}?
| | +---u ts:local-or-truststore-certs-grouping | | +---u ts:local-or-truststore-certs-grouping
| +-- raw-public-keys! {raw-public-key-auth}? | +-- raw-public-keys! {raw-public-key-auth}?
| | +---u ts:local-or-truststore-public-keys-grouping | | +---u ts:local-or-truststore-public-keys-grouping
| +-- psks! {psk-auth}? | +-- psks! {psk-auth}?
+-- 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 +-- peer-allowed-to-send? empty
+-- max-attempts? uint8 +-- test-peer-aliveness!
+-- max-wait? uint16
+-- max-attempts? uint8
4.2. Example Usage 4.2. Example Usage
This section presents two examples showing the tls-server-grouping This section presents two examples showing the "tls-server-grouping"
populated with some data. These examples are effectively the same grouping populated with some data. These examples are effectively
except the first configures the server identity using a local key the same except the first configures the server identity using a
while the second uses a key configured in a keystore. Both examples local key while the second uses a key configured in a keystore. Both
are consistent with the examples presented in Section 2 of examples 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) =========== ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<tls-server <tls-server
xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server" xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<!-- how this server will authenticate itself to the client --> <!-- how this server will authenticate itself to the client -->
<server-identity> <server-identity>
<certificate> <certificate>
<local-definition> <local-definition>
<algorithm>rsa2048</algorithm>
<public-key-format>ct:subject-public-key-info-format</public\ <public-key-format>ct:subject-public-key-info-format</public\
-key-format> -key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key-format>ct:rsa-private-key-format</private-key-f\ <private-key-format>ct:rsa-private-key-format</private-key-f\
ormat> ormat>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</certificate> </certificate>
<!-- TESTED, BUT COMMENTED OUT DUE TO ONLY ONE ALLOWED AT A TIME <!-- TESTED, BUT COMMENTED OUT DUE TO ONLY ONE ALLOWED AT A TIME
<raw-private-key> <raw-private-key>
<local-definition> <local-definition>
<algorithm>rsa2048</algorithm>
<public-key-format>ct:subject-public-key-info-format</public\ <public-key-format>ct:subject-public-key-info-format</public\
-key-format> -key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key-format>ct:rsa-private-key-format</private-key-f\ <private-key-format>ct:rsa-private-key-format</private-key-f\
ormat> ormat>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
</local-definition> </local-definition>
</raw-private-key> </raw-private-key>
<psk> <psk>
<local-definition> <local-definition>
<algorithm>aes-256-cbc</algorithm>
<key-format>ct:octet-string-key-format</key-format> <key-format>ct:octet-string-key-format</key-format>
<key>base64encodedvalue==</key> <key>base64encodedvalue==</key>
</local-definition> </local-definition>
</psk> </psk>
--> -->
</server-identity> </server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<client-authentication> <client-authentication>
<ca-certs> <ca-certs>
<local-definition> <local-definition>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</ca-certs> </ca-certs>
<client-certs> <ee-certs>
<local-definition> <local-definition>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</local-definition> </local-definition>
</client-certs> </ee-certs>
<raw-public-keys> <raw-public-keys>
<local-definition> <local-definition>
<public-key> <public-key>
<name>User A</name> <name>User A</name>
<algorithm>secp256r1</algorithm>
<public-key-format>ct:subject-public-key-info-format</publ\ <public-key-format>ct:subject-public-key-info-format</publ\
ic-key-format> ic-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
</public-key> </public-key>
<public-key> <public-key>
<name>User B</name> <name>User B</name>
<algorithm>secp256r1</algorithm>
<public-key-format>ct:subject-public-key-info-format</publ\ <public-key-format>ct:subject-public-key-info-format</publ\
ic-key-format> ic-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
</public-key> </public-key>
</local-definition> </local-definition>
</raw-public-keys> </raw-public-keys>
<psks/> <psks/>
</client-authentication> </client-authentication>
<keepalives>
<peer-allowed-to-send/>
</keepalives>
</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) =========== ========== 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 -->
skipping to change at page 19, line 34 skipping to change at page 21, line 34
</psk> </psk>
--> -->
</server-identity> </server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<client-authentication> <client-authentication>
<ca-certs> <ca-certs>
<truststore-reference>trusted-client-ca-certs</truststore-refe\ <truststore-reference>trusted-client-ca-certs</truststore-refe\
rence> rence>
</ca-certs> </ca-certs>
<client-certs> <ee-certs>
<truststore-reference>trusted-client-ee-certs</truststore-refe\ <truststore-reference>trusted-client-ee-certs</truststore-refe\
rence> rence>
</client-certs> </ee-certs>
<raw-public-keys> <raw-public-keys>
<truststore-reference>Raw Public Keys for Clients</truststore-\ <truststore-reference>Raw Public Keys for TLS Clients</trustst\
reference> ore-reference>
</raw-public-keys> </raw-public-keys>
<psks/> <psks/>
</client-authentication> </client-authentication>
<keepalives>
<peer-allowed-to-send/>
</keepalives>
</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@2020-03-08.yang" <CODE BEGINS> file "ietf-tls-server@2020-05-20.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-netconf-acm {
prefix tlscmn; prefix nacm;
revision-date 2020-03-08; // stable grouping definitions
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC 8341: Network Configuration Access Control Model";
} }
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"RFC AAAA: Common YANG Data Types for Cryptography"; "RFC AAAA: Common YANG Data Types for Cryptography";
} }
import ietf-truststore { import ietf-truststore {
prefix ts; prefix ts;
reference reference
"RFC BBBB: A YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
} }
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
reference reference
"RFC CCCC: A YANG Data Model for a Keystore"; "RFC CCCC: A YANG Data Model for a Keystore";
} }
import ietf-netconf-acm { import ietf-tls-common {
prefix nacm; prefix tlscmn;
revision-date 2020-05-20; // stable grouping definitions
reference reference
"RFC 8341: Network Configuration Access Control Model"; "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
} }
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/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net> Author: Kent Watsen <mailto:kent+ietf@watsen.net>
Author: Gary Wu <mailto:garywu@cisco.com>"; Author: Gary Wu <mailto:garywu@cisco.com>";
description description
"This module defines reusable groupings for TLS servers that "This module defines reusable groupings for TLS servers that
can be used as a basis for specific TLS server instances. can be used as a basis for specific TLS server instances.
Copyright (c) 2019 IETF Trust and the persons identified Copyright (c) 2020 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC FFFF
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcFFFF); 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 2020-03-08 { revision 2020-05-20 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: YANG Groupings for TLS Clients and TLS Servers"; "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
} }
// Features // Features
feature tls-server-hello-params-config { feature tls-server-hello-params-config {
description description
"TLS hello message parameters are configurable on a TLS "TLS hello message parameters are configurable on a TLS
server."; server.";
} }
skipping to change at page 23, line 8 skipping to change at page 25, line 15
container server-identity { container server-identity {
nacm:default-deny-write; nacm:default-deny-write;
description description
"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 server will present when establishing a TLS connection TLS server 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
The Transport Layer Security (TLS) Protocol Version 1.2 Version 1.2
RFC ZZZZ: RFC CCCC: A YANG Data Model for a Keystore";
YANG Data Model for a 'Keystore' Mechanism";
choice auth-type { choice auth-type {
mandatory true; mandatory true;
description description
"A choice amongst authentication types."; "A choice amongst authentication types.";
case certificate { case certificate {
if-feature x509-certificate-auth; if-feature x509-certificate-auth;
container certificate { container certificate {
description description
"Specifies the server identity using a certificate."; "Specifies the server identity using a certificate.";
uses uses
skipping to change at page 24, line 21 skipping to change at page 26, line 28
or pairwise-symmetric key). Note that, when the PSK is or pairwise-symmetric key). Note that, when the PSK is
configured as a Keystore reference, the key's 'name' configured as a Keystore reference, the key's 'name'
node MAY be used as the PSK's ID when used by the TLS node MAY be used as the PSK's ID when used by the TLS
protocol."; protocol.";
uses ks:local-or-keystore-symmetric-key-grouping { uses ks:local-or-keystore-symmetric-key-grouping {
augment "local-or-keystore/local/local-definition" { augment "local-or-keystore/local/local-definition" {
if-feature "ks:local-definitions-supported"; if-feature "ks:local-definitions-supported";
description description
"An 'id' value for when the PSK is used by TLS."; "An 'id' value for when the PSK is used by TLS.";
leaf id { leaf id {
type string; // is this the right type? type string; // FIXME: is this the right type?
description description
"The key id used in the TLS protocol for PSKs."; "The key id used in the TLS protocol for PSKs.";
} }
} }
} }
} }
} }
} }
} // container server-identity } // container server-identity
skipping to change at page 25, line 4 skipping to change at page 27, line 11
Note that no configuration is required for PSK (pre-shared Note that no configuration is required for PSK (pre-shared
or pairwise-symmetric key) based authentication as the key or pairwise-symmetric key) based authentication as the key
is necessarily the same as configured in the '../server- is necessarily the same as configured in the '../server-
identity' node."; identity' node.";
container ca-certs { container ca-certs {
if-feature "x509-certificate-auth"; if-feature "x509-certificate-auth";
presence presence
"Indicates that the TLS server can authenticate TLS clients "Indicates that the TLS server can authenticate TLS clients
using configured certificate authority certificates."; using configured certificate authority certificates.";
description description
"A set of certificate authority (CA) certificates used by "A set of certificate authority (CA) certificates used by
the TLS server to authenticate TLS client certificates. A the TLS server to authenticate TLS client certificates. A
client certificate is authenticated if it has a valid client certificate is authenticated if it has a valid
chain of trust to a configured CA certificate."; chain of trust to a configured CA certificate.";
reference reference
"RFC CCCC: YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
uses ts:local-or-truststore-certs-grouping; uses ts:local-or-truststore-certs-grouping;
// Note: TS certs don't have a key-format...no test needed
} }
container client-certs { // FIXME: plural too much? container ee-certs { // FIXME: plural too much?
if-feature "x509-certificate-auth"; if-feature "x509-certificate-auth";
presence presence
"Indicates that the TLS server can authenticate TLS "Indicates that the TLS server can authenticate TLS
clients using configured client certificates."; clients using configured client certificates.";
description description
"A set of client certificates (i.e., end entity "A set of client certificates (i.e., end entity
certificates) used by the TLS server to authenticate certificates) used by the TLS server to authenticate
certificates presented by TLS clients. A client certificates presented by TLS clients. A client
certificate is authenticated if it is an exact certificate is authenticated if it is an exact
match to a configured client certificate."; match to a configured client certificate.";
reference reference
"RFC CCCC: YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
uses ts:local-or-truststore-certs-grouping; uses ts:local-or-truststore-certs-grouping;
// Note: TS certs don't have a key-format...no test needed
} }
container raw-public-keys { container raw-public-keys {
if-feature "raw-public-key-auth"; if-feature "raw-public-key-auth";
presence presence
"Indicates that the TLS server can authenticate TLS "Indicates that the TLS server can authenticate TLS
clients using raw public keys."; clients using raw public keys.";
description description
"A set of raw public keys used by the TLS server to "A set of raw public keys used by the TLS server to
authenticate raw public keys presented by the TLS authenticate raw public keys presented by the TLS
client. A raw public key is authenticated if it client. A raw public key is authenticated if it
is an exact match to a configured raw public key."; is an exact match to a configured raw public key.";
reference reference
"RFC CCCC: YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
uses ts:local-or-truststore-public-keys-grouping { uses ts:local-or-truststore-public-keys-grouping {
refine "local-or-truststore/local/local-definition" refine "local-or-truststore/local/local-definition"
+ "/public-key" { + "/public-key" {
must 'public-key-format' must 'public-key-format'
+ ' = "ct:subject-public-key-info-format"'; + ' = "ct:subject-public-key-info-format"';
} }
refine "local-or-truststore/truststore" refine "local-or-truststore/truststore"
+ "/truststore-reference" { + "/truststore-reference" {
must 'deref(.)/../*/ts:public-key-format' must 'deref(.)/../*/ts:public-key-format'
+ ' = "ct:subject-public-key-info-format"'; + ' = "ct:subject-public-key-info-format"';
} }
} }
} }
container psks { container psks {
if-feature "psk-auth"; if-feature "psk-auth";
presence presence
"Indicates that the TLS server can authenticate the TLS "Indicates that the TLS server can authenticate the TLS
client using its PSK (pre-shared or pairwise-symmetric client using its PSK (pre-shared or pairwise-symmetric
key)."; key).";
description description
skipping to change at page 26, line 32 skipping to change at page 28, line 37
nacm:default-deny-write; nacm:default-deny-write;
if-feature "tls-server-hello-params-config"; if-feature "tls-server-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
container keepalives { container keepalives {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "tls-server-keepalives"; if-feature "tls-server-keepalives";
presence "Indicates that keepalives are enabled.";
description description
"Configures the keep-alive policy, to proactively test "Configures the keepalive policy for the TLS server.";
the aliveness of the TLS client. An unresponsive leaf peer-allowed-to-send {
TLS client is dropped after approximately max-wait type empty;
* max-attempts seconds.";
leaf max-wait {
type uint16 {
range "1..max";
}
units "seconds";
default "30";
description description
"Sets the amount of time in seconds after which if "Indicates that the remote TLS client is allowed to send
no data has been received from the TLS client, a HeartbeatRequest messages, as defined by RFC 6520
TLS-level message will be sent to test the to this TLS server.";
aliveness of the TLS client."; reference
"RFC 6520: Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) Heartbeat Extension";
} }
leaf max-attempts { container test-peer-aliveness {
type uint8; presence
default "3"; "Indicates that the TLS server proactively tests the
aliveness of the remote TLS client.";
description description
"Sets the maximum number of sequential keep-alive "Configures the keep-alive policy to proactively test
messages that can fail to obtain a response from the aliveness of the TLS client. An unresponsive
the TLS client before assuming the TLS client is TLS client is dropped after approximately max-wait
no longer alive."; * 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 client, a
TLS-level message will be sent to test the
aliveness of the TLS client.";
}
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 keepalives
} // grouping tls-server-grouping } // grouping tls-server-grouping
} // module ietf-tls-server } // module ietf-tls-server
<CODE ENDS> <CODE ENDS>
5. The TLS Common Model 5. The TLS Common Model
The TLS common model presented in this section contains identities The TLS common model presented in this section contains identities
and groupings common to both TLS clients and TLS servers. The hello- and groupings common to both TLS clients and TLS servers. The
params-grouping can be used to configure the list of TLS algorithms "hello-params-grouping" grouping can be used to configure the list of
permitted by the TLS client or TLS server. The lists of algorithms TLS algorithms permitted by the TLS client or TLS server. The lists
are ordered such that, if multiple algorithms are permitted by the of algorithms are ordered such that, if multiple algorithms are
client, the algorithm that appears first in its list that is also permitted by the client, the algorithm that appears first in its list
permitted by the server is used for the TLS transport layer that is also permitted by the server is used for the TLS transport
connection. The ability to restrict the algorithms allowed is layer connection. The ability to restrict the algorithms allowed is
provided in this grouping for TLS clients and TLS servers that are 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 capable of doing so and may serve to make TLS clients and TLS servers
compliant with local security policies. This model supports both compliant with local security policies. This model supports both
TLS1.2 [RFC5246] and TLS 1.3 [RFC8446]. TLS1.2 [RFC5246] and TLS 1.3 [RFC8446].
TLS 1.2 and TLS 1.3 have different ways defining their own supported TLS 1.2 and TLS 1.3 have different ways defining their own supported
cryptographic algorithms, see TLS and DTLS IANA registries page cryptographic algorithms, see TLS and DTLS IANA registries page
(https://www.iana.org/assignments/tls-parameters/tls- (https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml): parameters.xhtml):
skipping to change at page 28, line 16 skipping to change at page 30, line 36
defines three categories of registries for cryptographic defines three categories of registries for cryptographic
algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported
Groups. Secondly, all three of these categories are useful, since Groups. Secondly, all three of these categories are useful, since
they represent different parts of all the supported algorithms they represent different parts of all the supported algorithms
respectively. Thus, all of these registries categories are respectively. Thus, all of these registries categories are
considered here. In this draft, the TLS common model chooses only 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 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of
[RFC8446]. [RFC8446].
Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites 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 part of the "hello-params-grouping" grouping should include three
configuring its permitted TLS algorithms, which are: TLS Cipher parameters for configuring its permitted TLS algorithms, which are:
Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2 TLS Cipher Suites, TLS SignatureScheme, TLS Supported Groups. Note
only uses TLS Cipher Suites. 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 Features are defined for algorithms that are OPTIONAL or are not
widely supported by popular implementations. Note that the list of widely supported by popular implementations. Note that the list of
algorithms is not exhaustive. algorithms is not exhaustive.
5.1. Tree Diagram 5.1. Tree Diagram
The following tree diagram [RFC8340] provides an overview of the data The following tree diagram [RFC8340] provides an overview of the data
model for the "ietf-tls-common" module. model for the "ietf-tls-common" module.
module: ietf-tls-common module: ietf-tls-common
grouping hello-params-grouping grouping hello-params-grouping
+-- tls-versions +-- tls-versions
| +-- tls-version* identityref | +-- tls-version* identityref
+-- cipher-suites +-- cipher-suites
+-- cipher-suite* identityref +-- cipher-suite* identityref
5.2. Example Usage 5.2. Example Usage
This section shows how it would appear if the transport-params- This section shows how it would appear if the "hello-params-grouping"
grouping were populated with some data. grouping were populated with some data.
<hello-params <hello-params
xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-common" xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-common"
xmlns:tlscmn="urn:ietf:params:xml:ns:yang:ietf-tls-common"> xmlns:tlscmn="urn:ietf:params:xml:ns:yang:ietf-tls-common">
<tls-versions> <tls-versions>
<tls-version>tlscmn:tls-1.1</tls-version> <tls-version>tlscmn:tls-1.1</tls-version>
<tls-version>tlscmn:tls-1.2</tls-version> <tls-version>tlscmn:tls-1.2</tls-version>
</tls-versions> </tls-versions>
<cipher-suites> <cipher-suites>
skipping to change at page 36, line 45 skipping to change at page 31, line 40
</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@2020-03-08.yang" <CODE BEGINS> file "ietf-tls-common@2020-05-20.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/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net> Author: Kent Watsen <mailto:kent+ietf@watsen.net>
Author: Gary Wu <mailto:garywu@cisco.com>"; Author: Gary Wu <mailto:garywu@cisco.com>";
description description
"This module defines a common features, identities, and "This module defines a common features, identities, and
groupings for Transport Layer Security (TLS). groupings for Transport Layer Security (TLS).
Copyright (c) 2019 IETF Trust and the persons identified Copyright (c) 2020 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(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 2020-03-08 { revision 2020-05-20 {
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 47, line 26 skipping to change at page 42, line 26
7.2. The YANG Module Names Registry 7.2. The YANG Module Names Registry
This document registers three YANG modules in the YANG Module Names This document registers three YANG modules in the YANG Module Names
registry [RFC6020]. Following the format in [RFC6020], the following registry [RFC6020]. Following the format in [RFC6020], the following
registrations are requested: registrations are requested:
name: ietf-tls-client name: ietf-tls-client
namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
prefix: tlsc prefix: tlsc
reference: RFC XXXX reference: RFC FFFF
name: ietf-tls-server name: ietf-tls-server
namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
prefix: tlss prefix: tlss
reference: RFC XXXX reference: RFC FFFF
name: ietf-tls-common name: ietf-tls-common
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 FFFF
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-13 (work in Cryptography", draft-ietf-netconf-crypto-types-14 (work in
progress), November 2019. progress), March 2020.
[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-15 (work in progress), November ietf-netconf-keystore-16 (work in progress), March 2020.
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-08 (work in progress), November ietf-netconf-trust-anchors-09 (work in progress), March
2019. 2020.
[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>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
DOI 10.17487/RFC5288, August 2008, DOI 10.17487/RFC5288, August 2008,
<https://www.rfc-editor.org/info/rfc5288>. <https://www.rfc-editor.org/info/rfc5288>.
skipping to change at page 51, line 5 skipping to change at page 45, line 9
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
RFC 8071, DOI 10.17487/RFC8071, February 2017, RFC 8071, DOI 10.17487/RFC8071, February 2017,
<https://www.rfc-editor.org/info/rfc8071>. <https://www.rfc-editor.org/info/rfc8071>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
8.3. URIs
[1] https://tools.ietf.org/html/draft-ietf-netconf-crypto-types
[2] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors
[3] https://tools.ietf.org/html/draft-ietf-netconf-keystore
[4] https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server
[5] https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server
[6] https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server
[7] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server
[8] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-
server
[9] https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-
server
Appendix A. Change Log Appendix A. Change Log
A.1. 00 to 01 A.1. 00 to 01
o Noted that '0.0.0.0' and '::' might have special meanings. o Noted that '0.0.0.0' and '::' might have special meanings.
o Renamed "keychain" to "keystore". o Renamed "keychain" to "keystore".
A.2. 01 to 02 A.2. 01 to 02
skipping to change at page 55, line 22 skipping to change at page 50, line 22
o Refined truststore/keystore groupings to ensure the key formats o Refined truststore/keystore groupings to ensure the key formats
"must" be particular values. "must" be particular values.
o Switched to using truststore's new "public-key" bag (instead of o Switched to using truststore's new "public-key" bag (instead of
separate "ssh-public-key" and "raw-public-key" bags. separate "ssh-public-key" and "raw-public-key" bags.
o Updated client/server examples to cover ALL cases (local/ref x o Updated client/server examples to cover ALL cases (local/ref x
cert/raw-key/psk). cert/raw-key/psk).
A.20. 18 to 19
o Updated the "keepalives" containers in part to address Michal
Vasko's request to align with RFC 8071, and in part to better
align to RFC 6520.
o Removed algorithm-mapping tables from the "TLS Common Model"
section
o Removed the 'algorithm' node from the examples.
o Renamed both "client-certs" and "server-certs" to "ee-certs"
o Added a "Note to Reviewers" note to first page.
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, Radek Krejci,
Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, David Lamparter, Ladislav Lhotka, Alan Luchuk, Tom Petch, Juergen
Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen. Schoenwaelder, Phil Shafer, Sean Turner, Michal Vasko, Bert Wijnen,
and Liang Xia.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
EMail: kent+ietf@watsen.net EMail: kent+ietf@watsen.net
Gary Wu Gary Wu
Cisco Systems Cisco Systems
EMail: garywu@cisco.com EMail: garywu@cisco.com
Liang Xia
Huawei
EMail: frank.xialiang@huawei.com
 End of changes. 106 change blocks. 
496 lines changed or deleted 354 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/