draft-ietf-netconf-tls-client-server-05.txt   draft-ietf-netconf-tls-client-server-06.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track G. Wu Intended status: Standards Track G. Wu
Expires: May 3, 2018 Cisco Systems Expires: December 6, 2018 Cisco Systems
October 30, 2017 June 4, 2018
YANG Groupings for TLS Clients and TLS Servers YANG Groupings for TLS Clients and TLS Servers
draft-ietf-netconf-tls-client-server-05 draft-ietf-netconf-tls-client-server-06
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 1, line 32 skipping to change at page 1, line 32
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. No other RFC summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document. Editor instructions are specified elsewhere in this document.
This document contains references to other drafts in progress, both This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their throughout. Please update the following references to reflect their
final RFC assignments: final RFC assignments:
o I-D.ietf-netconf-trust-anchors
o I-D.ietf-netconf-keystore 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 "XXXX" --> the assigned RFC value for this draft
o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-keystore o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust-
anchors
o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore
Artwork in this document contains placeholder values for the date of 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 "2017-10-30" --> the publication date of this draft o "2018-06-04" --> 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
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
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 May 3, 2018. This Internet-Draft will expire on December 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 5
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 9 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10
4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 14
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 14
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 16
7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 17
7.2. The YANG Module Names Registry . . . . . . . . . . . . . 25 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 27 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 27
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . 27
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . 29
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 30
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 30
A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 31
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document defines three YANG [RFC7950] modules: the first defines This document defines three YANG 1.1 [RFC7950] modules: the first
a grouping for a generic TLS client, the second defines a grouping defines a grouping for a generic TLS client, the second defines a
for a generic TLS server, and the third defines identities and grouping for a generic TLS server, and the third defines identities
groupings common to both the client and the server (TLS is defined in and groupings common to both the client and the server (TLS is
[RFC5246]). It is intended that these groupings will be used by defined in [RFC5246]). It is intended that these groupings will be
applications using the TLS protocol. For instance, these groupings used by applications using the TLS protocol. For instance, these
could be used to help define the data model for an HTTPS [RFC2818] groupings could be used to help define the data model for an HTTPS
server or a NETCONF over TLS [RFC7589] based server. [RFC2818] server or a NETCONF over TLS [RFC7589] based server.
The client and server YANG modules in this document each define one The client and server YANG modules in this document each define one
grouping, which is focused on just TLS-specific configuration, and grouping, which is focused on just TLS-specific configuration, and
specifically avoids any transport-level configuration, such as what specifically avoids any transport-level configuration, such as what
ports to listen-on or connect-to. This enables applications the ports to listen-on or connect-to. This affords applications the
opportunity to define their own strategy for how the underlying TCP opportunity to define their own strategy for how the underlying TCP
connection is established. For instance, applications supporting connection is established. For instance, applications supporting
NETCONF Call Home [RFC8071] could use the grouping for the TLS parts NETCONF Call Home [RFC8071] could use the "ssh-server-grouping"
it provides, while adding data nodes for the TCP-level call-home grouping for the TLS parts it provides, while adding data nodes for
configuration. the TCP-level call-home configuration.
The modules defined in this document uses groupings defined in
[I-D.ietf-netconf-keystore] enabling keys to be either locally
defined or a reference to globally configured values.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
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.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
3. The TLS Client Model 3. The TLS Client Model
The TLS client model presented in this section contains one YANG 3.1. Tree Diagram
grouping, to just configure the TLS client, omitting, for instance,
any configuration for which IP address or port the client should
connect to.
This grouping references data nodes defined by the keystore model This section provides two tree diagrams [RFC8340] for the "ietf-tls-
[I-D.ietf-netconf-keystore]. For instance, a reference to the client" module, the first with used groupings expanded and the second
keystore model is made to indicate which trusted CA certificate a with used groupings not expanded.
client should use to authenticate the server's certificate.
3.1. Tree Diagram The following tree diagram has used groupings expanded:
The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] module: ietf-tls-client
provides an overview of the data model for the "ietf-tls-client"
module.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 grouping tls-client-grouping
+-- client-identity
| +-- (auth-type)?
| +--:(certificate)
| +-- certificate
| +-- (local-or-keystore)
| +--:(local)
| | +-- algorithm
| | | ct:key-algorithm-ref
| | +-- public-key binary
| | +-- private-key union
| | +-- cert
| | | ct:end-entity-cert-cms
| | +---n certificate-expiration
| | +-- expiration-date? yang:date-and-time
| +--:(keystore) {keystore-implemented}?
| +-- reference
| ks:asymmetric-key-certificate-ref
+-- server-auth
| +-- pinned-ca-certs? ta:pinned-certificates-ref
| +-- pinned-server-certs? ta:pinned-certificates-ref
+-- hello-params {tls-client-hello-params-config}?
+-- tls-versions
| +-- tls-version* identityref
+-- cipher-suites
+-- cipher-suite* identityref
The following tree diagram does not have the groupings expanded:
[Note: '\' line wrapping for formatting only]
module: ietf-tls-client module: ietf-tls-client
grouping tls-client-grouping grouping tls-client-grouping
+---- client-identity +-- client-identity
| +---- (auth-type)? | +-- (auth-type)?
| +--:(certificate) | +--:(certificate)
| +---- certificate | +-- certificate
| +---- algorithm? | +---u ks:local-or-keystore-end-entity-certificate-gr\
| | identityref ouping
| +---- private-key? union +-- server-auth
| +---- public-key? binary | +-- pinned-ca-certs? ta:pinned-certificates-ref
| +---x generate-private-key | +-- pinned-server-certs? ta:pinned-certificates-ref
| | +---w input +-- hello-params {tls-client-hello-params-config}?
| | +---w algorithm identityref +---u tlscmn:hello-params-grouping
| +---- certificates
| | +---- certificate* [name]
| | +---- name? string
| | +---- value? binary
| +---x generate-certificate-signing-request
| +---w input
| | +---w subject binary
| | +---w attributes? binary
| +--ro output
| +--ro certificate-signing-request binary
+---- server-auth
| +---- pinned-ca-certs? ks:pinned-certificates
| +---- pinned-server-certs? ks:pinned-certificates
+---- hello-params {tls-client-hello-params-config}?
+---- tls-versions
| +---- tls-version* identityref
+---- cipher-suites
+---- cipher-suite* identityref
3.2. Example Usage 3.2. Example Usage
This section shows how it would appear if the tls-client-grouping This section presents two examples showing the tls-client-grouping
were populated with some data. This example is consistent with the populated with some data. These examples are effectively the same
examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. except the first configures the client identity using a local key
while the second uses a key configured in a keystore. Both examples
are consistent with the examples presented in Section 3 of
[I-D.ietf-netconf-trust-anchors] and Section 3.2 of
[I-D.ietf-netconf-keystore].
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 The following example configures the client identity using a local
key:
[ note: '\' line wrapping for formatting only] [Note: '\' line wrapping for formatting only]
<!-- hypothetical example, as groupings don't have instance data --> <tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client">
<tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client">
<!-- how this client will authenticate itself to the server --> <!-- how this client will authenticate itself to the server -->
<client-identity> <client-identity>
<certificate> <certificate>
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-keystore"\ <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-t\
>ks:secp521r1</algorithm> ypes">ct:rsa1024</algorithm>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<certificates> <cert>base64encodedvalue==</cert>
<certificate> </certificate>
<name>domain certificate</name> </client-identity>
<value>base64encodedvalue==</value>
</certificate>
</certificates>
</certificate>
</client-identity>
<!-- which certificates will this client trust --> <!-- which certificates will this client trust -->
<server-auth> <server-auth>
<pinned-ca-certs>deployment-specific-ca-certs</pinned-ca-certs> <pinned-ca-certs>explicitly-trusted-server-ca-certs</pinned-ca-c\
<pinned-server-certs>explicitly-trusted-client-certs</pinned-serv\ erts>
er-certs> <pinned-server-certs>explicitly-trusted-server-certs</pinned-ser\
</server-auth> ver-certs>
</server-auth>
</tls-client> </tls-client>
The following example configures the client identity using a key from
the keystore:
[Note: '\' line wrapping for formatting only]
<tls-client xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-client">
<!-- how this client will authenticate itself to the server -->
<client-identity>
<certificate>
<reference>ex-rsa-cert</reference>
</certificate>
</client-identity>
<!-- which certificates will this client trust -->
<server-auth>
<pinned-ca-certs>explicitly-trusted-server-ca-certs</pinned-ca-c\
erts>
<pinned-server-certs>explicitly-trusted-server-certs</pinned-ser\
ver-certs>
</server-auth>
</tls-client>
3.3. YANG Module 3.3. YANG Module
This YANG module has a normative references to [RFC6991] and This YANG module has normative references to
[I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
<CODE BEGINS> file "ietf-tls-client@2017-10-30.yang" <CODE BEGINS> file "ietf-tls-client@2018-06-04.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 2017-10-30; // stable grouping definitions revision-date 2018-06-04; // 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";
} }
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 import ietf-trust-anchors {
prefix ta;
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
}
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
reference reference
"RFC YYYY: Keystore Model"; "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http://tools.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 Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Gary Wu Author: Gary Wu
<mailto:garywu@cisco.com>"; <mailto:garywu@cisco.com>";
description description
"This module defines a reusable grouping for a TLS client that "This module defines a reusable grouping for a TLS client 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) 2017 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. 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 or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's 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). (http://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; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2017-10-30" { revision "2018-06-04" {
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
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
"TLS hello message parameters are configurable on a TLS "TLS hello message parameters are configurable on a TLS
client."; client.";
} }
// 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.";
skipping to change at page 8, line 28 skipping to change at page 9, line 24
container client-identity { container client-identity {
description description
"The credentials used by the client to authenticate to "The credentials used by the client to authenticate to
the TLS server."; the TLS server.";
choice auth-type { choice auth-type {
description description
"The authentication type."; "The authentication type.";
container certificate { container certificate {
uses ks:private-key-grouping; uses ks:local-or-keystore-end-entity-certificate-grouping;
uses ks:certificate-grouping;
description description
"Choice statement for future augmentations."; "A locally-defined or referenced certificate
to be used for client authentication.";
reference
"RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
} }
} }
} } // end client-identity
container server-auth { container server-auth {
must 'pinned-ca-certs or pinned-server-certs'; must 'pinned-ca-certs or pinned-server-certs';
description description
"Trusted server identities."; "Trusted server identities.";
leaf pinned-ca-certs { leaf pinned-ca-certs {
type ks:pinned-certificates; type ta:pinned-certificates-ref;
description description
"A reference to a list of certificate authority (CA) "A reference to a list of certificate authority (CA)
certificates used by the TLS client to authenticate certificates used by the TLS client to authenticate
TLS server certificates. A server certificate is TLS server certificates. A server certificate is
authenticated if it has a valid chain of trust to authenticated if it has a valid chain of trust to
a configured pinned CA certificate."; a configured pinned CA certificate.";
} }
leaf pinned-server-certs { leaf pinned-server-certs {
type ks:pinned-certificates; type ta:pinned-certificates-ref;
description description
"A reference to a list of server certificates used by "A reference to a list of server certificates used by
the TLS client to authenticate TLS server certificates. the TLS client to authenticate TLS server certificates.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
A server certificate is authenticated if it is an A server certificate is authenticated if it is an
exact match to a configured pinned server certificate."; exact match to a configured pinned server certificate.";
} }
} }
container hello-params { container hello-params {
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.";
} }
} // end tls-client-grouping } // end tls-client-grouping
} }
<CODE ENDS> <CODE ENDS>
4. The TLS Server Model 4. The TLS Server Model
The TLS server model presented in this section contains one YANG 4.1. Tree Diagram
grouping, for just the TLS-level configuration, omitting, for
instance, configuration for which ports to open to listen for
connections on.
This grouping references data nodes defined by the keystore model This section provides two tree diagrams [RFC8340] for the "ietf-tls-
[I-D.ietf-netconf-keystore]. For instance, a reference to the server" module, the first with used groupings expanded and the second
keystore model is made to indicate which certificate a server should with used groupings not expanded.
present.
4.1. Tree Diagram The following tree diagram has used groupings expanded:
The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] module: ietf-tls-server
provides an overview of the data model for the "ietf-tls-server"
module.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 grouping tls-server-grouping
+-- server-identity
| +-- (local-or-keystore)
| +--:(local)
| | +-- algorithm ct:key-algorithm-ref
| | +-- public-key binary
| | +-- private-key union
| | +-- cert ct:end-entity-cert-cms
| | +---n certificate-expiration
| | +-- expiration-date? yang:date-and-time
| +--:(keystore) {keystore-implemented}?
| +-- reference
| ks:asymmetric-key-certificate-ref
+-- client-auth
| +-- pinned-ca-certs? ta:pinned-certificates-ref
| +-- pinned-client-certs? ta:pinned-certificates-ref
+-- hello-params {tls-server-hello-params-config}?
+-- tls-versions
| +-- tls-version* identityref
+-- cipher-suites
+-- cipher-suite* identityref
The following tree diagram does not have the used groupings expanded:
module: ietf-tls-server module: ietf-tls-server
grouping tls-server-grouping grouping tls-server-grouping
+---- server-identity +-- server-identity
| +---- algorithm? identityref | +---u ks:local-or-keystore-end-entity-certificate-grouping
| +---- private-key? union +-- client-auth
| +---- public-key? binary | +-- pinned-ca-certs? ta:pinned-certificates-ref
| +---x generate-private-key | +-- pinned-client-certs? ta:pinned-certificates-ref
| | +---w input +-- hello-params {tls-server-hello-params-config}?
| | +---w algorithm identityref +---u tlscmn:hello-params-grouping
| +---- certificates
| | +---- certificate* [name]
| | +---- name? string
| | +---- value? binary
| +---x generate-certificate-signing-request
| +---w input
| | +---w subject binary
| | +---w attributes? binary
| +--ro output
| +--ro certificate-signing-request binary
+---- client-auth
| +---- pinned-ca-certs? ks:pinned-certificates
| +---- pinned-client-certs? ks:pinned-certificates
+---- hello-params {tls-server-hello-params-config}?
+---- tls-versions
| +---- tls-version* identityref
+---- cipher-suites
+---- cipher-suite* identityref
4.2. Example Usage 4.2. Example Usage
This section shows how it would appear if the tls-server-grouping This section presents two examples showing the tls-server-grouping
were populated with some data. This example is consistent with the populated with some data. These examples are effectively the same
examples presented in Section 2.2 of [I-D.ietf-netconf-keystore]. except the first configures the server identity using a local key
while the second uses a key configured in a keystore. Both examples
are consistent with the examples presented in Section 3 of
[I-D.ietf-netconf-trust-anchors] and Section 3.2 of
[I-D.ietf-netconf-keystore].
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 The following example configures the server identity using a local
key:
[ note: '\' line wrapping for formatting only] [Note: '\' line wrapping for formatting only]
<tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server"> <tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server">
<!-- how this server will authenticate itself to the client --> <!-- how this server will authenticate itself to the client -->
<server-identity> <server-identity>
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-keystore">k\ <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-typ\
s:secp521r1</algorithm> es">ct:rsa1024</algorithm>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<certificates> <cert>base64encodedvalue==</cert>
<certificate> </server-identity>
<name>domain certificate</name>
<value>base64encodedvalue==</value>
</certificate>
</certificates>
</server-identity>
<!-- which certificates will this server trust --> <!-- which certificates will this server trust -->
<client-auth> <client-auth>
<pinned-ca-certs>deployment-specific-ca-certs</pinned-ca-certs> <pinned-ca-certs>explicitly-trusted-client-ca-certs</pinned-ca-c\
<pinned-client-certs>explicitly-trusted-client-certs</pinned-clie\ erts>
nt-certs> <pinned-client-certs>explicitly-trusted-client-certs</pinned-cli\
</client-auth> ent-certs>
</client-auth>
</tls-server> </tls-server>
The following example configures the server identity using a key from
the keystore:
[Note: '\' line wrapping for formatting only]
<tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server">
<!-- how this server will authenticate itself to the client -->
<server-identity>
<reference>ex-rsa-cert</reference>
</server-identity>
<!-- which certificates will this server trust -->
<client-auth>
<pinned-ca-certs>explicitly-trusted-client-ca-certs</pinned-ca-c\
erts>
<pinned-client-certs>explicitly-trusted-client-certs</pinned-cli\
ent-certs>
</client-auth>
</tls-server>
4.3. YANG Module 4.3. YANG Module
This YANG module has a normative references to [RFC6991], and This YANG module has a normative references to [RFC5246],
[I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
<CODE BEGINS> file "ietf-tls-server@2017-10-30.yang" <CODE BEGINS> file "ietf-tls-server@2018-06-04.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 2017-10-30; // stable grouping definitions revision-date 2018-06-04; // 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 {
prefix ta;
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
}
import ietf-keystore { import ietf-keystore {
prefix ks; prefix ks;
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
reference reference
"RFC YYYY: Keystore Model"; "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http://tools.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 Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Gary Wu Author: Gary Wu
<mailto:garywu@cisco.com>"; <mailto:garywu@cisco.com>";
description description
"This module defines a reusable grouping for a TLS server that "This module defines a reusable grouping for a TLS server 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) 2017 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. 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 or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's 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). (http://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; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2017-10-30" { revision "2018-06-04" {
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.";
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
} }
// 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.";
container server-identity { container server-identity {
description description
skipping to change at page 13, line 19 skipping to change at page 15, line 14
// 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.";
container server-identity { container server-identity {
description description
"The list of certificates the TLS server will present when "A locally-defined or referenced end-entity certificate,
establishing a TLS connection in its Certificate message, including any configured intermediate certificates, the
as defined in Section 7.4.2 in RFC 5246."; 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 5246: "RFC 5246:
The Transport Layer Security (TLS) Protocol Version 1.2"; The Transport Layer Security (TLS) Protocol Version 1.2
uses ks:private-key-grouping; RFC ZZZZ:
uses ks:certificate-grouping; YANG Data Model for a 'Keystore' Mechanism";
uses ks:local-or-keystore-end-entity-certificate-grouping;
} }
container client-auth { container client-auth {
description description
"A reference to a list of pinned certificate authority (CA) "A reference to a list of pinned certificate authority (CA)
certificates and a reference to a list of pinned client certificates and a reference to a list of pinned client
certificates."; certificates.";
leaf pinned-ca-certs { leaf pinned-ca-certs {
type ks:pinned-certificates; type ta:pinned-certificates-ref;
description description
"A reference to a list of certificate authority (CA) "A reference to a list of certificate authority (CA)
certificates used by the TLS server to authenticate certificates used by the TLS server to authenticate
TLS client certificates. A client certificate is TLS client certificates. A client certificate is
authenticated if it has a valid chain of trust to authenticated if it has a valid chain of trust to
a configured pinned CA certificate."; a configured pinned CA certificate.";
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
} }
leaf pinned-client-certs { leaf pinned-client-certs {
type ks:pinned-certificates; type ta:pinned-certificates-ref;
description description
"A reference to a list of client certificates used by "A reference to a list of client certificates used by
the TLS server to authenticate TLS client certificates. the TLS server to authenticate TLS client certificates.
A clients certificate is authenticated if it is an A clients certificate is authenticated if it is an
exact match to a configured pinned client certificate."; exact match to a configured pinned client certificate.";
reference
"RFC YYYY: YANG Data Model for Global Trust Anchors";
} }
} }
container hello-params { container hello-params {
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
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.";
} }
} // end tls-server-grouping } // end tls-server-grouping
} }
<CODE ENDS> <CODE ENDS>
skipping to change at page 14, line 38 skipping to change at page 16, line 40
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 security policies. compliant with security policies.
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 [I-D.ietf-netmod-yang-tree-diagrams] The following tree diagram [RFC8340] provides an overview of the data
provides an overview of the data model for the "ietf-tls-common" model for the "ietf-tls-common" module.
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 transport-params-
grouping were populated with some data. grouping were populated with some data.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
<!-- hypothetical example, as groupings don't have instance 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>
<cipher-suite>tlscmn:dhe-rsa-with-aes-128-cbc-sha</cipher-suite> <cipher-suite>tlscmn:dhe-rsa-with-aes-128-cbc-sha</cipher-suite>
<cipher-suite>tlscmn:rsa-with-aes-128-cbc-sha</cipher-suite> <cipher-suite>tlscmn:rsa-with-aes-128-cbc-sha</cipher-suite>
<cipher-suite>tlscmn:rsa-with-3des-ede-cbc-sha</cipher-suite> <cipher-suite>tlscmn:rsa-with-3des-ede-cbc-sha</cipher-suite>
</cipher-suites> </cipher-suites>
</hello-params> </hello-params>
5.3. YANG Module 5.3. YANG Module
This YANG module has a normative references to [RFC2246], [RFC4346], This YANG module has a normative references to [RFC2246], [RFC4346],
[RFC4492], [RFC5246], [RFC5288], and [RFC5289]. [RFC4492], [RFC5246], [RFC5288], and [RFC5289].
<CODE BEGINS> file "ietf-tls-common@2017-10-30.yang" <CODE BEGINS> file "ietf-tls-common@2018-06-04.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://tools.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 Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Gary Wu Author: Gary Wu
<mailto:garywu@cisco.com>"; <mailto:garywu@cisco.com>";
description description
"This module defines a common features, identities, and groupings "This module defines a common features, identities, and groupings
for Transport Layer Security (TLS). for Transport Layer Security (TLS).
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's 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). (http://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; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2017-10-30" { revision "2018-06-04" {
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 16, line 52 skipping to change at page 19, line 4
description description
"TLS Protocol Version 1.2 is supported."; "TLS Protocol Version 1.2 is supported.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
feature tls-ecc { feature tls-ecc {
description description
"Elliptic Curve Cryptography (ECC) is supported for TLS."; "Elliptic Curve Cryptography (ECC) is supported for TLS.";
reference reference
"RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)"; for Transport Layer Security (TLS)";
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
} }
feature tls-dhe { feature tls-dhe {
description description
"Ephemeral Diffie-Hellman key exchange is supported for TLS."; "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
skipping to change at page 18, line 4 skipping to change at page 20, line 7
description description
"Base identity used to identify TLS protocol versions."; "Base identity used to identify TLS protocol versions.";
} }
identity tls-1.0 { identity tls-1.0 {
base tls-version-base; base tls-version-base;
if-feature tls-1_0; if-feature tls-1_0;
description description
"TLS Protocol Version 1.0."; "TLS Protocol Version 1.0.";
reference reference
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
"RFC 2246: The TLS Protocol Version 1.0"; "RFC 2246: The TLS Protocol Version 1.0";
} }
identity tls-1.1 { identity tls-1.1 {
base tls-version-base; base tls-version-base;
if-feature tls-1_1; if-feature tls-1_1;
description description
"TLS Protocol Version 1.1."; "TLS Protocol Version 1.1.";
reference reference
"RFC 4346: The Transport Layer Security (TLS) Protocol "RFC 4346: The Transport Layer Security (TLS) Protocol
skipping to change at page 18, line 52 skipping to change at page 21, line 4
} }
identity rsa-with-aes-256-cbc-sha { identity rsa-with-aes-256-cbc-sha {
base cipher-suite-base; base cipher-suite-base;
description description
"Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA."; "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
identity rsa-with-aes-128-cbc-sha256 { identity rsa-with-aes-128-cbc-sha256 {
base cipher-suite-base; base cipher-suite-base;
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
if-feature tls-sha2; if-feature tls-sha2;
description description
"Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256."; "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
identity rsa-with-aes-256-cbc-sha256 { identity rsa-with-aes-256-cbc-sha256 {
base cipher-suite-base; base cipher-suite-base;
skipping to change at page 19, line 53 skipping to change at page 22, line 4
} }
identity dhe-rsa-with-aes-128-cbc-sha256 { identity dhe-rsa-with-aes-128-cbc-sha256 {
base cipher-suite-base; base cipher-suite-base;
if-feature "tls-dhe and tls-sha2"; if-feature "tls-dhe and tls-sha2";
description description
"Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256."; "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
}
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 }
identity dhe-rsa-with-aes-256-cbc-sha256 { identity dhe-rsa-with-aes-256-cbc-sha256 {
base cipher-suite-base; base cipher-suite-base;
if-feature "tls-dhe and tls-sha2"; if-feature "tls-dhe and tls-sha2";
description description
"Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256."; "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
skipping to change at page 21, line 4 skipping to change at page 23, line 6
} }
identity ecdhe-rsa-with-aes-256-cbc-sha384 { identity ecdhe-rsa-with-aes-256-cbc-sha384 {
base cipher-suite-base; base cipher-suite-base;
if-feature "tls-ecc and tls-sha2"; if-feature "tls-ecc and tls-sha2";
description description
"Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384."; "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
reference reference
"RFC 5289: TLS Elliptic Curve Cipher Suites with "RFC 5289: TLS Elliptic Curve Cipher Suites with
SHA-256/384 and AES Galois Counter Mode (GCM)"; SHA-256/384 and AES Galois Counter Mode (GCM)";
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
} }
identity ecdhe-ecdsa-with-aes-128-gcm-sha256 { identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
base cipher-suite-base; base cipher-suite-base;
if-feature "tls-ecc and tls-gcm and tls-sha2"; if-feature "tls-ecc and tls-gcm and tls-sha2";
description description
"Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256."; "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
reference reference
"RFC 5289: TLS Elliptic Curve Cipher Suites with "RFC 5289: TLS Elliptic Curve Cipher Suites with
SHA-256/384 and AES Galois Counter Mode (GCM)"; SHA-256/384 and AES Galois Counter Mode (GCM)";
skipping to change at page 22, line 4 skipping to change at page 24, line 6
"RFC 5289: TLS Elliptic Curve Cipher Suites with "RFC 5289: TLS Elliptic Curve Cipher Suites with
SHA-256/384 and AES Galois Counter Mode (GCM)"; SHA-256/384 and AES Galois Counter Mode (GCM)";
} }
identity rsa-with-3des-ede-cbc-sha { identity rsa-with-3des-ede-cbc-sha {
base cipher-suite-base; base cipher-suite-base;
if-feature tls-3des; if-feature tls-3des;
description description
"Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."; "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
reference reference
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
identity ecdhe-rsa-with-3des-ede-cbc-sha { identity ecdhe-rsa-with-3des-ede-cbc-sha {
base cipher-suite-base; base cipher-suite-base;
if-feature "tls-ecc and tls-3des"; if-feature "tls-ecc and tls-3des";
description description
"Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA."; "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
reference reference
skipping to change at page 22, line 53 skipping to change at page 25, line 4
grouping hello-params-grouping { grouping hello-params-grouping {
description description
"A reusable grouping for TLS hello message parameters."; "A reusable grouping for TLS hello message parameters.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
container tls-versions { container tls-versions {
description description
"Parameters regarding TLS versions."; "Parameters regarding TLS versions.";
leaf-list tls-version { leaf-list tls-version {
type identityref { type identityref {
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
base tls-version-base; base tls-version-base;
} }
description description
"Acceptable TLS protocol versions. "Acceptable TLS protocol versions.
If this leaf-list is not configured (has zero elements) If this leaf-list is not configured (has zero elements)
the acceptable TLS protocol versions are implementation- the acceptable TLS protocol versions are implementation-
defined."; defined.";
} }
} }
skipping to change at page 24, line 5 skipping to change at page 26, line 9
authentication. authentication.
The NETCONF access control model (NACM) [RFC6536] provides the means The NETCONF access control model (NACM) [RFC6536] 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 defined in this document only define groupings,
these considerations are primarily for the designers of other modules these considerations are primarily for the designers of other modules
that use these groupings. that use these groupings.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
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 data tree of all the groupings defined in this draft
is sensitive to write operations. For instance, the addition is sensitive to write operations. For instance, the addition
skipping to change at page 25, line 5 skipping to change at page 27, line 5
NONE NONE
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 IETF XML registry This document registers three URIs in the IETF XML registry
[RFC3688]. Following the format in [RFC3688], the following [RFC3688]. Following the format in [RFC3688], the following
registrations are requested: registrations are requested:
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
URI: urn:ietf:params:xml:ns:yang:ietf-tls-client URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-tls-server URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-tls-common URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
skipping to change at page 25, line 53 skipping to change at page 28, line 6
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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "Keystore Model", draft-ietf-netconf- Watsen, K., "YANG Data Model for a "Keystore" Mechanism",
keystore-02 (work in progress), June 2017. draft-ietf-netconf-keystore-04 (work in progress), October
2017.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 [I-D.ietf-netconf-trust-anchors]
Watsen, K., "YANG Data Model for Global Trust Anchors",
draft-ietf-netconf-trust-anchors-00 (work in progress),
June 2018.
[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>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
skipping to change at page 26, line 47 skipping to change at page 29, line 10
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
DOI 10.17487/RFC5289, August 2008, DOI 10.17487/RFC5289, August 2008,
<https://www.rfc-editor.org/info/rfc5289>. <https://www.rfc-editor.org/info/rfc5289>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015, DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>. <https://www.rfc-editor.org/info/rfc7589>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 2017.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
skipping to change at page 28, line 5 skipping to change at page 29, line 47
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<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>.
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
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 29, line 5 skipping to change at page 31, line 5
o Made author lists consistent o Made author lists consistent
o Now tree diagrams reference ietf-netmod-yang-tree-diagrams o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
o Updated YANG to use typedefs around leafrefs to common keystore o Updated YANG to use typedefs around leafrefs to common keystore
paths paths
o Now inlines key and certificates (no longer a leafref to keystore) o Now inlines key and certificates (no longer a leafref to keystore)
Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017 A.5. 04 to 05
o Merged changes from co-author.
A.6. 05 to 06
o Updated to use trust anchors from trust-anchors draft (was
keystore draft)
o Now Uses new keystore grouping enabling asymmetric key to be
either locally defined or a reference to the keystore.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
Gary Wu Gary Wu
Cisco Systems Cisco Systems
 End of changes. 103 change blocks. 
287 lines changed or deleted 325 lines changed or added

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