draft-ietf-netconf-tls-client-server-10.txt   draft-ietf-netconf-tls-client-server-11.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 10, 2019 Cisco Systems Expires: October 9, 2019 Cisco Systems
L. Xia L. Xia
Huawei Huawei
March 9, 2019 April 7, 2019
YANG Groupings for TLS Clients and TLS Servers YANG Groupings for TLS Clients and TLS Servers
draft-ietf-netconf-tls-client-server-10 draft-ietf-netconf-tls-client-server-11
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-03-09" --> the publication date of this draft o "2019-04-07" --> 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 September 10, 2019. This Internet-Draft will expire on October 9, 2019.
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 2, line 49 skipping to change at page 2, line 49
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 17 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 17
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 26
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 35 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 36
7.2. The YANG Module Names Registry . . . . . . . . . . . . . 35 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 39 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 41
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 39 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 41
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 39 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 41
A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 40 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 42
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 40 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 42
A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 40 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 42
A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 40 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 42
A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 40 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 42
A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 40 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 24 skipping to change at page 4, line 24
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. The TLS Client Model 3. The TLS Client Model
3.1. Tree Diagram 3.1. Tree Diagram
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.
=========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
module: ietf-tls-client module: ietf-tls-client
grouping tls-client-grouping grouping tls-client-grouping
+---u client-identity-grouping +-- tls-client-parameters
+---u server-auth-grouping +-- client-identity
+---u hello-params-grouping | +-- (auth-type)?
+---u keepalives-grouping | +--:(certificate)
grouping client-identity-grouping | +-- certificate
+-- tls-client-identity | +---u ks:local-or-keystore-end-entity-cert-with-k\
+-- (auth-type)? ey-grouping
+--:(certificate) +-- server-authentication
+-- certificate | +-- pinned-ca-certs? ta:pinned-certificates-ref
+---u client-identity-grouping | | {ta:x509-certificates}?
grouping server-auth-grouping | +-- pinned-server-certs? ta:pinned-certificates-ref
+-- tls-server-auth | {ta:x509-certificates}?
+-- pinned-ca-certs? ta:pinned-certificates-ref +-- hello-params {tls-client-hello-params-config}?
| {ta:x509-certificates}? | +---u tlscmn:hello-params-grouping
+-- pinned-server-certs? ta:pinned-certificates-ref +-- keepalives! {tls-client-keepalives}?
{ta:x509-certificates}? +-- max-wait? uint16
grouping hello-params-grouping +-- max-attempts? uint8
+-- tls-hello-params {tls-client-hello-params-config}?
+---u hello-params-grouping
grouping keepalives-grouping
+-- tls-keepalives {tls-client-keepalives}?
+-- 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 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 3 of are consistent with the examples presented in Section 3 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 XX (RFC XXXX) =========== =========== NOTE: '\' line wrapping per BCP XX (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">
<tls-client-parameters>
<!-- how this client will authenticate itself to the server --> <!-- how this client will authenticate itself to the server -->
<tls-client-identity> <client-identity>
<certificate> <certificate>
<local-definition> <local-definition>
<algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto\ <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-cryp\
\-types">ct:rsa2048</algorithm> to-types">ct: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>
</certificate> </certificate>
</tls-client-identity> </client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<tls-server-auth> <server-authentication>
<pinned-ca-certs>explicitly-trusted-server-ca-certs</pinned-ca-c\ <pinned-ca-certs>explicitly-trusted-server-ca-certs</pinned-ca\
\erts> -certs>
<pinned-server-certs>explicitly-trusted-server-certs</pinned-ser\ <pinned-server-certs>explicitly-trusted-server-certs</pinned-s\
\ver-certs> erver-certs>
</tls-server-auth> </server-authentication>
<tls-keepalives> <keepalives>
<max-wait>30</max-wait> <max-wait>30</max-wait>
<max-attempts>3</max-attempts> <max-attempts>3</max-attempts>
</tls-keepalives> </keepalives>
</tls-client-parameters>
</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 XX (RFC XXXX) =========== =========== NOTE: '\' line wrapping per BCP XX (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">
<tls-client-parameters>
<!-- how this client will authenticate itself to the server --> <!-- how this client will authenticate itself to the server -->
<tls-client-identity> <client-identity>
<certificate> <certificate>
<keystore-reference>ex-rsa-cert</keystore-reference> <keystore-reference>ex-rsa-cert</keystore-reference>
</certificate> </certificate>
</tls-client-identity> </client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<tls-server-auth> <server-authentication>
<pinned-ca-certs>explicitly-trusted-server-ca-certs</pinned-ca-c\ <pinned-ca-certs>explicitly-trusted-server-ca-certs</pinned-ca\
\erts> -certs>
<pinned-server-certs>explicitly-trusted-server-certs</pinned-ser\ <pinned-server-certs>explicitly-trusted-server-certs</pinned-s\
\ver-certs> erver-certs>
</tls-server-auth> </server-authentication>
<tls-keepalives> <keepalives>
<max-wait>30</max-wait> <max-wait>30</max-wait>
<max-attempts>3</max-attempts> <max-attempts>3</max-attempts>
</tls-keepalives> </keepalives>
</tls-client-parameters>
</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-03-09.yang" <CODE BEGINS> file "ietf-tls-client@2019-04-07.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-03-09; // stable grouping definitions revision-date 2019-04-07; // 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-trust-anchors { import ietf-trust-anchors {
prefix ta; prefix ta;
reference reference
"RFC YYYY: YANG Data Model for Global Trust Anchors"; "RFC YYYY: YANG Data Model for Global Trust Anchors";
} }
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
reference reference
"RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
} }
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
}
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.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Copyright (c) 2019 IETF Trust and the persons identified
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', as authors of the code. All rights reserved.
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with
without modification, is permitted pursuant to, and subject or without modification, is permitted pursuant to, and
to the license terms contained in, the Simplified BSD subject to the license terms contained in, the Simplified
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
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX
the RFC itself for full legal notices."; (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.;
revision 2019-03-09 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2019-04-07 {
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.";
} }
feature tls-client-keepalives { feature tls-client-keepalives {
description description
skipping to change at page 8, line 25 skipping to change at page 8, line 34
TLS clients on the server implementing this feature."; TLS clients on the server implementing this feature.";
} }
// Groupings // Groupings
grouping tls-client-grouping { grouping tls-client-grouping {
description description
"A reusable grouping for configuring a TLS client without "A reusable grouping for configuring a TLS client without
any consideration for how an underlying TCP session is any consideration for how an underlying TCP session is
established."; established.";
uses client-identity-grouping;
uses server-auth-grouping;
uses hello-params-grouping;
uses keepalives-grouping;
}
grouping client-identity-grouping { container tls-client-parameters {
description nacm:default-deny-write;
"A reusable grouping for configuring a TLS client identity.";
container tls-client-identity {
description description
"The credentials used by the client to authenticate to "A container to hold TLS client configuration.";
the TLS server.";
choice auth-type { container client-identity {
description description
"The authentication type."; "The credentials used by the client to authenticate to
container certificate { the TLS server.";
uses choice auth-type {
ks:local-or-keystore-end-entity-cert-with-key-grouping;
description description
"A locally-defined or referenced certificate "The authentication type.";
to be used for client authentication."; container certificate {
reference uses
"RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; ks:local-or-keystore-end-entity-cert-with-key-grouping;
description
"A locally-defined or referenced certificate
to be used for client authentication.";
reference
"RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
}
} }
} } // container client-identity
}
}
grouping server-auth-grouping { container server-authentication {
description must 'pinned-ca-certs or pinned-server-certs';
"A reusable grouping for configuring TLS server
authentication.";
container tls-server-auth {
must 'pinned-ca-certs or pinned-server-certs';
description
"Trusted server identities.";
leaf pinned-ca-certs {
if-feature "ta:x509-certificates";
type ta:pinned-certificates-ref;
description
"A reference to a list of certificate authority (CA)
certificates used by the TLS client to authenticate
TLS server certificates. A server certificate is
authenticated if it has a valid chain of trust to
a configured pinned CA certificate.";
}
leaf pinned-server-certs {
if-feature "ta:x509-certificates";
type ta:pinned-certificates-ref;
description description
"A reference to a list of server certificates used by "Trusted server identities.";
the TLS client to authenticate TLS server certificates. leaf pinned-ca-certs {
A server certificate is authenticated if it is an if-feature "ta:x509-certificates";
exact match to a configured pinned server certificate."; type ta:pinned-certificates-ref;
} description
} "A reference to a list of certificate authority (CA)
} certificates used by the TLS client to authenticate
TLS server certificates. A server certificate is
authenticated if it has a valid chain of trust to
a configured pinned CA certificate.";
}
leaf pinned-server-certs {
if-feature "ta:x509-certificates";
type ta:pinned-certificates-ref;
description
"A reference to a list of server certificates used by
the TLS client to authenticate TLS server certificates.
A server certificate is authenticated if it is an
exact match to a configured pinned server certificate.";
}
} // container server-authentication
grouping hello-params-grouping { container hello-params {
description if-feature "tls-client-hello-params-config";
"A reusable grouping for configuring a TLS transport uses tlscmn:hello-params-grouping;
parameters."; description
container tls-hello-params { "Configurable parameters for the TLS hello message.";
if-feature "tls-client-hello-params-config"; } // container hello-params
uses tlscmn:hello-params-grouping;
description
"Configurable parameters for the TLS hello message.";
}
}
grouping keepalives-grouping { container keepalives {
description if-feature "tls-client-keepalives";
"A reusable grouping for configuring TLS client keepalive presence "Indicates that keepalives are enabled.";
parameters."; description
"Configures the keep-alive policy, to proactively test
the aliveness of the TLS server. An unresponsive
TLS server is dropped after approximately max-wait
* max-attempts seconds.";
container tls-keepalives { leaf max-wait {
if-feature "tls-client-keepalives"; type uint16 {
description range "1..max";
"Configures the keep-alive policy, to proactively test }
the aliveness of the TLS server. An unresponsive units "seconds";
TLS server is dropped after approximately max-wait default "30";
* max-attempts seconds."; description
leaf max-wait { "Sets the amount of time in seconds after which if
type uint16 { no data has been received from the TLS server, a
range "1..max"; TLS-level message will be sent to test the
aliveness of the TLS server.";
} }
units "seconds"; leaf max-attempts {
default "30"; type uint8;
description default "3";
"Sets the amount of time in seconds after which if no data description
has been received from the TLS server, a TLS-level message "Sets the maximum number of sequential keep-alive
will be sent to test the aliveness of the TLS server."; messages that can fail to obtain a response from
} the TLS server before assuming the TLS server is
leaf max-attempts { no longer alive.";
type uint8; }
default "3"; } // container keepalives
description } // container tls-client-parameters
"Sets the maximum number of sequential keep-alive messages } // grouping tls-client-grouping
that can fail to obtain a response from the TLS server
before assuming the TLS server is no longer alive.";
}
}
}
} }
<CODE ENDS> <CODE ENDS>
4. The TLS Server Model 4. The TLS Server Model
4.1. Tree Diagram 4.1. Tree Diagram
This section provides a tree diagram [RFC8340] for the "ietf-tls- This section provides a tree diagram [RFC8340] for the "ietf-tls-
server" module that does not have groupings expanded. server" module that does not have groupings expanded.
=========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
module: ietf-tls-server module: ietf-tls-server
grouping tls-server-grouping grouping tls-server-grouping
+---u server-identity-grouping +-- tls-server-parameters
+---u client-auth-grouping +-- server-identity
+---u hello-params-grouping | +---u ks:local-or-keystore-end-entity-cert-with-key-groupi\
+---u keepalives-grouping ng
grouping server-identity-grouping +-- client-authentication
+-- tls-server-identity | +-- pinned-ca-certs? ta:pinned-certificates-ref
+---u server-identity-grouping | | {ta:x509-certificates}?
grouping client-auth-grouping | +-- pinned-client-certs? ta:pinned-certificates-ref
+-- tls-client-auth | {ta:x509-certificates}?
+-- pinned-ca-certs? ta:pinned-certificates-ref +-- hello-params {tls-server-hello-params-config}?
| {ta:x509-certificates}? | +---u tlscmn:hello-params-grouping
+-- pinned-client-certs? ta:pinned-certificates-ref +-- keepalives! {tls-server-keepalives}?
{ta:x509-certificates}? +-- max-wait? uint16
grouping hello-params-grouping +-- max-attempts? uint8
+-- tls-hello-params {tls-server-hello-params-config}?
+---u hello-params-grouping
grouping keepalives-grouping
+-- tls-keepalives {tls-server-keepalives}?
+-- 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 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 3 of are consistent with the examples presented in Section 3 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 XX (RFC XXXX) =========== =========== NOTE: '\' line wrapping per BCP XX (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">
<tls-server-parameters>
<!-- how this server will authenticate itself to the client --> <!-- how this server will authenticate itself to the client -->
<tls-server-identity> <server-identity>
<local-definition> <local-definition>
<algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-t\ <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto\
\ypes">ct:rsa2048</algorithm> -types">ct: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>
</tls-server-identity> </server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<tls-client-auth> <client-authentication>
<pinned-ca-certs>explicitly-trusted-client-ca-certs</pinned-ca-c\ <pinned-ca-certs>explicitly-trusted-client-ca-certs</pinned-ca\
\erts> -certs>
<pinned-client-certs>explicitly-trusted-client-certs</pinned-cli\ <pinned-client-certs>explicitly-trusted-client-certs</pinned-c\
\ent-certs> lient-certs>
</tls-client-auth> </client-authentication>
</tls-server-parameters>
</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 XX (RFC XXXX) =========== =========== NOTE: '\' line wrapping per BCP XX (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">
<tls-server-parameters>
<!-- how this server will authenticate itself to the client --> <!-- how this server will authenticate itself to the client -->
<tls-server-identity> <server-identity>
<keystore-reference>ex-rsa-cert</keystore-reference> <keystore-reference>ex-rsa-cert</keystore-reference>
</tls-server-identity> </server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<tls-client-auth> <client-authentication>
<pinned-ca-certs>explicitly-trusted-client-ca-certs</pinned-ca-c\ <pinned-ca-certs>explicitly-trusted-client-ca-certs</pinned-ca\
\erts> -certs>
<pinned-client-certs>explicitly-trusted-client-certs</pinned-cli\ <pinned-client-certs>explicitly-trusted-client-certs</pinned-c\
\ent-certs> lient-certs>
</tls-client-auth> </client-authentication>
</tls-server-parameters>
</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-03-09.yang" <CODE BEGINS> file "ietf-tls-server@2019-04-07.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-03-09; // stable grouping definitions revision-date 2019-04-07; // 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-trust-anchors { import ietf-trust-anchors {
prefix ta; prefix ta;
reference reference
"RFC YYYY: YANG Data Model for Global Trust Anchors"; "RFC YYYY: YANG Data Model for Global Trust Anchors";
} }
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
reference reference
"RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism"; "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
} }
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
}
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.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Copyright (c) 2019 IETF Trust and the persons identified
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', as authors of the code. All rights reserved.
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with
without modification, is permitted pursuant to, and subject or without modification, is permitted pursuant to, and
to the license terms contained in, the Simplified BSD subject to the license terms contained in, the Simplified
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
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX
the RFC itself for full legal notices."; (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.;
revision 2019-03-09 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2019-04-07 {
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
"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 14, line 47 skipping to change at page 15, line 28
TLS servers on the server implementing this feature."; TLS servers on the server implementing this feature.";
} }
// Groupings // Groupings
grouping tls-server-grouping { grouping tls-server-grouping {
description description
"A reusable grouping for configuring a TLS server without "A reusable grouping for configuring a TLS server without
any consideration for how underlying TCP sessions are any consideration for how underlying TCP sessions are
established."; established.";
uses server-identity-grouping;
uses client-auth-grouping;
uses hello-params-grouping;
uses keepalives-grouping;
}
grouping server-identity-grouping {
description
"A reusable grouping for configuring a TLS server identity.";
container tls-server-identity {
description
"A locally-defined or referenced end-entity certificate,
including any configured intermediate certificates, the
TLS server will present when establishing a TLS connection
in its Certificate message, as defined in Section 7.4.2
in RFC 5246.";
reference
"RFC 5246:
The Transport Layer Security (TLS) Protocol Version 1.2
RFC ZZZZ:
YANG Data Model for a 'Keystore' Mechanism";
uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
}
}
grouping client-auth-grouping { container tls-server-parameters {
description nacm:default-deny-write;
"A reusable grouping for configuring a TLS client
authentication.";
container tls-client-auth {
description description
"A reference to a list of pinned certificate authority (CA) "A container to hold TLS server configuration.";
certificates and a reference to a list of pinned client
certificates.";
leaf pinned-ca-certs {
if-feature "ta:x509-certificates";
type ta:pinned-certificates-ref;
description
"A reference to a list of certificate authority (CA)
certificates used by the TLS server to authenticate
TLS client certificates. A client certificate is
authenticated if it has a valid chain of trust to
a configured pinned CA certificate.";
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
}
leaf pinned-client-certs {
if-feature "ta:x509-certificates";
type ta:pinned-certificates-ref;
description
"A reference to a list of client certificates used by
the TLS server to authenticate TLS client certificates.
A clients certificate is authenticated if it is an
exact match to a configured pinned client certificate.";
container server-identity {
description
"A locally-defined or referenced end-entity certificate,
including any configured intermediate certificates, the
TLS server will present when establishing a TLS connection
in its Certificate message, as defined in Section 7.4.2
in RFC 5246.";
reference reference
"RFC YYYY: YANG Data Model for Global Trust Anchors"; "RFC 5246:
} The Transport Layer Security (TLS) Protocol Version 1.2
} RFC ZZZZ:
} YANG Data Model for a 'Keystore' Mechanism";
uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
grouping hello-params-grouping { } // container server-identity
description
"A reusable grouping for configuring a TLS transport
parameters.";
container tls-hello-params {
if-feature "tls-server-hello-params-config";
uses tlscmn:hello-params-grouping;
description
"Configurable parameters for the TLS hello message.";
}
}
grouping keepalives-grouping { container client-authentication {
description
"A reusable grouping for configuring TLS server keepalive
parameters.";
container tls-keepalives {
if-feature "tls-server-keepalives";
description
"Configures the keep-alive policy, to proactively test
the aliveness of the TLS client. An unresponsive
TLS client is dropped after approximately max-wait
* max-attempts seconds.";
leaf max-wait {
type uint16 {
range "1..max";
}
units "seconds";
default "30";
description description
"Sets the amount of time in seconds after which if no data "A reference to a list of pinned certificate authority (CA)
has been received from the TLS client, a TLS-level message certificates and a reference to a list of pinned client
will be sent to test the aliveness of the TLS client."; certificates.";
} leaf pinned-ca-certs {
leaf max-attempts { if-feature "ta:x509-certificates";
type uint8; type ta:pinned-certificates-ref;
default "3"; description
"A reference to a list of certificate authority (CA)
certificates used by the TLS server to authenticate
TLS client certificates. A client certificate is
authenticated if it has a valid chain of trust to
a configured pinned CA certificate.";
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
}
leaf pinned-client-certs {
if-feature "ta:x509-certificates";
type ta:pinned-certificates-ref;
description
"A reference to a list of client certificates used by
the TLS server to authenticate TLS client certificates.
A clients certificate is authenticated if it is an
exact match to a configured pinned client certificate.";
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
}
} // container client-authentication
container hello-params {
if-feature "tls-server-hello-params-config";
uses tlscmn:hello-params-grouping;
description description
"Sets the maximum number of sequential keep-alive messages "Configurable parameters for the TLS hello message.";
that can fail to obtain a response from the TLS client } // container hello-params
before assuming the TLS client is no longer alive.";
}
} container keepalives {
} if-feature "tls-server-keepalives";
presence "Indicates that keepalives are enabled.";
description
"Configures the keep-alive policy, to proactively test
the aliveness of the TLS client. An unresponsive
TLS client is dropped after approximately max-wait
* max-attempts seconds.";
leaf max-wait {
type uint16 {
range "1..max";
}
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 tls-server-parameters
} // grouping tls-server-grouping
} }
<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 hello-
params-grouping can be used to configure the list of TLS algorithms params-grouping can be used to configure the list of TLS algorithms
permitted by the TLS client or TLS server. The lists of algorithms permitted by the TLS client or TLS server. The lists of algorithms
are ordered such that, if multiple algorithms are permitted by the are ordered such that, if multiple algorithms are permitted by the
skipping to change at page 25, line 45 skipping to change at page 26, 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-03-09.yang" <CODE BEGINS> file "ietf-tls-common@2019-04-07.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).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Copyright (c) 2019 IETF Trust and the persons identified
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', as authors of the code. All rights reserved.
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with
without modification, is permitted pursuant to, and subject or without modification, is permitted pursuant to, and
to the license terms contained in, the Simplified BSD subject to the license terms contained in, the Simplified
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
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX
the RFC itself for full legal notices."; (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.;
revision 2019-03-09 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2019-04-07 {
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 34, line 31 skipping to change at page 35, line 31
The YANG modules defined in this document are designed to be accessed The YANG modules defined in this document are designed to be accessed
via YANG based management protocols, such as NETCONF [RFC6241] and via YANG based management protocols, such as NETCONF [RFC6241] and
RESTCONF [RFC8040]. Both of these protocols have mandatory-to- RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
implement secure transport layers (e.g., SSH, TLS) with mutual implement secure transport layers (e.g., SSH, TLS) with mutual
authentication. authentication.
The NETCONF access control model (NACM) [RFC8341] provides the means The NETCONF access control model (NACM) [RFC8341] provides the means
to restrict access for particular users to a pre-configured subset of to restrict access for particular users to a pre-configured subset of
all available protocol operations and content. all available protocol operations and content.
Since the modules defined in this document only define groupings, Since the modules in this document only define groupings, these
these considerations are primarily for the designers of other modules considerations are primarily for the designers of other modules that
that use these groupings. use these groupings.
There are a number of data nodes defined in the YANG modules that are There are a number of data nodes defined in the YANG modules that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/: The entire data tree of all the groupings defined in this draft *: The entire subtree defined by the grouping statement in both
is sensitive to write operations. For instance, the addition the "ietf-ssh-client" and "ietf-ssh-server" modules is
or removal of references to keys, certificates, trusted sensitive to write operations. For instance, the addition or
anchors, etc., can dramatically alter the implemented security removal of references to keys, certificates, trusted anchors,
policy. However, no NACM annotations are applied as the data etc., or even the modification of transport or keepalive
SHOULD be editable by users other than a designated 'recovery parameters can dramatically alter the implemented security
session'. policy. For this reason, this node is protected the NACM
extension "default-deny-write".
Some of the readable data nodes in the YANG modules may be considered Some of the readable data nodes in the YANG modules may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
NONE /tls-client-parameters/client-identity/: This subtree in the
"ietf-tls-client" module contains nodes that are additionally
sensitive to read operations such that, in normal use cases,
they should never be returned to a client. Some of these nodes
(i.e., public-key/local-definition/private-key and certificate/
local-definition/private-key) are already protected by the NACM
extension "default-deny-all" set in the "grouping" statements
defined in [I-D.ietf-netconf-crypto-types].
Some of the RPC operations in this YANG module may be considered /tls-server-parameters/server-identity/: This subtree in the
"ietf-tls-server" module contains nodes that are additionally
sensitive to read operations such that, in normal use cases,
they should never be returned to a client. All of these nodes
(i.e., host-key/public-key/local-definition/private-key and
host-key/certificate/local-definition/private-key) are already
protected by the NACM extension "default-deny-all" set in the
"grouping" statements defined in
[I-D.ietf-netconf-crypto-types].
Some of the operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
NONE *: The groupings defined in this document include "action"
statements that come from groupings defined in
[I-D.ietf-netconf-crypto-types]. Please consult that document
for the security considerations of the "action" statements
defined by the "grouping" statements defined in this document.
7. IANA Considerations 7. IANA Considerations
7.1. The IETF XML Registry 7.1. The IETF XML Registry
This document registers three URIs in the "ns" subregistry of the This document registers three URIs in the "ns" subregistry of the
IETF XML Registry [RFC3688]. Following the format in [RFC3688], the IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
following registrations are requested: following registrations are requested:
URI: urn:ietf:params:xml:ns:yang:ietf-tls-client URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
skipping to change at page 36, line 26 skipping to change at page 37, 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-02 (work in Cryptography", draft-ietf-netconf-crypto-types-05 (work in
progress), October 2018. progress), March 2019.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "YANG Data Model for a Centralized Keystore Watsen, K., "YANG Data Model for a Centralized Keystore
Mechanism", draft-ietf-netconf-keystore-08 (work in Mechanism", draft-ietf-netconf-keystore-08 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-netconf-trust-anchors] [I-D.ietf-netconf-trust-anchors]
Watsen, K., "YANG Data Model for Global Trust Anchors", Watsen, K., "YANG Data Model for Global Trust Anchors",
draft-ietf-netconf-trust-anchors-03 (work in progress), draft-ietf-netconf-trust-anchors-03 (work in progress),
March 2019. March 2019.
skipping to change at page 41, line 5 skipping to change at page 43, line 5
o Prefixed top-level TLS grouping nodes with 'tls-' and support o Prefixed top-level TLS grouping nodes with 'tls-' and support
mashups. mashups.
o Updated copyright date, boilerplate template, affiliation, and o Updated copyright date, boilerplate template, affiliation, and
folding algorithm. folding algorithm.
A.10. 09 to 10 A.10. 09 to 10
o Reformatted the YANG modules. o Reformatted the YANG modules.
A.11. 10 to 11
o Collapsed all the inner groupings into the top-level grouping.
o Added a top-level "demux container" inside the top-level grouping.
o Added NACM statements and updated the Security Considerations
section.
o Added "presence" statements on the "keepalive" containers, as was
needed to address a validation error that appeared after adding
the "must" statements into the NETCONF/RESTCONF client/server
modules.
o Updated the boilerplate text in module-level "description"
statement to match copyeditor convention.
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. 86 change blocks. 
407 lines changed or deleted 435 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/