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/