draft-ietf-netconf-server-model-00.txt		draft-ietf-netconf-server-model-01.txt
	NETCONF Working Group K. Watsen		NETCONF Working Group K. Watsen
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Standards Track J. Schoenwaelder		Intended status: Standards Track J. Schoenwaelder
	Expires: November 02, 2014 Jacobs University Bremen		Expires: December 03, 2014 Jacobs University Bremen
	May 2014		June 2014
	NETCONF Server Configuration Model		NETCONF Server Configuration Model
	draft-ietf-netconf-server-model-00		draft-ietf-netconf-server-model-01
	Abstract		Abstract
	This draft defines a NETCONF server configuration data model. This		This draft defines a NETCONF server configuration data model. This
	data model enables configuration of the NETCONF service itself,		data model enables configuration of the NETCONF service itself,
	including which transports it supports, what ports they listen on,		including which transports it supports, what ports they listen on,
	whether they support device-initiated connections, and associated		whether they support device-initiated connections, and associated
	parameters.		parameters.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 November 02, 2014.		This Internet-Draft will expire on December 03, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 32		skipping to change at page 2, line 32
	2.2. Align Transport-Specific Configurations . . . . . . . . . 4		2.2. Align Transport-Specific Configurations . . . . . . . . . 4
	2.3. Support both Listening for Connections and Call Home . . 4		2.3. Support both Listening for Connections and Call Home . . 4
	2.4. For Call Home Connections . . . . . . . . . . . . . . . . 4		2.4. For Call Home Connections . . . . . . . . . . . . . . . . 4
	2.4.1. Support More than One Application . . . . . . . . . . 4		2.4.1. Support More than One Application . . . . . . . . . . 4
	2.4.2. Support Applications Having More than One Server . . 4		2.4.2. Support Applications Having More than One Server . . 4
	2.4.3. Support a Reconnection Strategy . . . . . . . . . . . 4		2.4.3. Support a Reconnection Strategy . . . . . . . . . . . 4
	2.4.4. Support both Persistent and Periodic Connections . . 5		2.4.4. Support both Persistent and Periodic Connections . . 5
	2.4.5. Reconnection Strategy for Periodic Connections . . . 5		2.4.5. Reconnection Strategy for Periodic Connections . . . 5
	2.4.6. Keep-Alives for Persistent Connections . . . . . . . 5		2.4.6. Keep-Alives for Persistent Connections . . . . . . . 5
	2.4.7. Customizations for Periodic Connections . . . . . . . 5		2.4.7. Customizations for Periodic Connections . . . . . . . 5
	3. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 6		3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Support for Virtual Routing and Forwarding . . . . . . . . . 7		4. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 16
	5. The "ietf-netconf-server" Data Model . . . . . . . . . . . . 7		4.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. The "listen" Grouping . . . . . . . . . . . . . . . . . . 7		4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.2. The "call-home" Grouping . . . . . . . . . . . . . . . . 8		5. User Authentication for TLS . . . . . . . . . . . . . . . . . 17
	6. The "ietf-system-tls-auth" Data Model . . . . . . . . . . . . 9		5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 17
	7. The "ietf-netconf-server" YANG Module . . . . . . . . . . . . 9		5.2. Data Model Overview . . . . . . . . . . . . . . . . . . . 17
	8. The "ietf-system-tls-auth" YANG Module . . . . . . . . . . . 18		5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 22		6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		8. Other Considerations . . . . . . . . . . . . . . . . . . . . 24
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	12.1. Normative References . . . . . . . . . . . . . . . . . . 24		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	12.2. Informative References . . . . . . . . . . . . . . . . . 25		10.1. Normative References . . . . . . . . . . . . . . . . . . 24
	Appendix A. Example: SSH Transport Configuration . . . . . . . . 25		10.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix B. Example: TLS Transport Configuration . . . . . . . . 26		Appendix A. Example: SSH Transport Configuration . . . . . . . . 26
	Appendix C. Example: TLS Authentication Configuration . . . . . 27		Appendix B. Example: TLS Transport Configuration . . . . . . . . 27
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 28		Appendix C. Example: TLS Authentication Configuration . . . . . 28
	D.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 28		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 29
			D.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 29
	Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . 28		D.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 29
			Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	This draft defines a NETCONF [RFC6241] server configuration data		This draft defines a NETCONF [RFC6241] server configuration data
	model. This data model enables configuration of the NETCONF service		model. This data model enables configuration of the NETCONF service
	itself, including which transports are supported, what ports does the		itself, including which transports are supported, what ports does the
	server listen on, whether call-home is supported, and associated		server listen on, whether call-home is supported, and associated
	parameters.		parameters.
	1.1. Terminology		1.1. Terminology
	skipping to change at page 6, line 13		skipping to change at page 6, line 13
	to it.		to it.
	A common communication pattern is that one data transmission is many		A common communication pattern is that one data transmission is many
	times closely followed by another. For instance, if the device needs		times closely followed by another. For instance, if the device needs
	to send a notification message, there's a high probability that it		to send a notification message, there's a high probability that it
	will send another shortly thereafter. Likewise, the application may		will send another shortly thereafter. Likewise, the application may
	have a sequence of pending messages to send. Thus, it should be		have a sequence of pending messages to send. Thus, it should be
	possible for a device to hold a connection open until some amount of		possible for a device to hold a connection open until some amount of
	time of no data being transmitted as transpired.		time of no data being transmitted as transpired.
	3. Keep-Alives for SSH and TLS		3. Data Model
	One the objectives listed above, Keep-Alives for Persistent
	Connections (Section 2.4.6) indicates a need for a "keep-alive"
	mechanism. This section specifies how the NETCONF keep-alive
	mechanism is to be implemented.
	Both SSH and TLS have the ability to support keep-alives. Using
	these mechanisms, the keep-alive messages are sent inside the
	encrypted tunnel, thus thwarting spoof attacks.
	3.1. SSH
	The SSH keep-alive solution that is expected to be used when
	configured using the data model defined in this document is
	ubiquitous in practice, though never being explicitly defined in an
	RFC. The strategy used is to purposely send a malformed request
	message with a flag set to ensure a response. More specifically, per
	section 4 of [RFC4253], either SSH peer can send a
	SSH_MSG_GLOBAL_REQUEST message with "want reply" set to '1' and that,
	if there is an error, will get back a SSH_MSG_REQUEST_FAILURE
	response. Similarly, section 5 of [RFC4253] says that either SSH
	peer can send a SSH_MSG_CHANNEL_REQUEST message with "want reply" set
	to '1' and that, if there is an error, will get back a
	SSH_MSG_CHANNEL_FAILURE response.
	To ensure that the request will fail, current implementations send an
	invalid "request name" or "request type", respectively. Abiding to
	the extensibility guidelines specified in Section 6 of [RFC4251],
	these implementations use the "name@domain". For instance, when
	configured to send keep-alives, OpenSSH sends the string
	"keepalive@openssh.com". In order to remain compatible with existing
	implementations, this draft does not require a specific "request
	name" or "request type" string be used.
	3.2. TLS
	The TLS keep-alive solution is defined in [RFC6520]. This solution
	allows both peers to advertise if they can receive heartbeat request
	messages from its peer. For standard NETCONF over TLS connections,
	devices SHOULD advertise "peer_allowed_to_send", as per [RFC6520].
	This advertisement is not a "MUST" in order to grandfather existing
	NETCONF over TLS implementations. For NETCONF over TLS Call Home,
	the network management system MUST advertise "peer_allowed_to_send"
	per [RFC6520]. This is a "MUST" so as to ensure devices can depend
	in it always being there for call home connections, which is
	conveniently when keep-alives are needed the most.
	4. Support for Virtual Routing and Forwarding
	The YANG module define herein does not itself support virtual routing
	and forwarding (VRF). It is expected that other modules with augment
	in a VRF designation when needed.
	5. The "ietf-netconf-server" Data Model
	5.1. The "listen" Grouping		3.1. Overview
	To enable transports to configure listening on one or more ports in a		To enable transports to configure listening on one or more ports in a
	common way, this grouping is defined. This grouping defines SSH and		common way, this grouping is defined. This grouping defines SSH and
	TLS specific containers, each of which refines the default listening		TLS specific containers, each of which refines the default listening
	port appropriately. Further, each of these transport specific		port appropriately. Further, each of these transport specific
	containers use a feature statement, enabling NETCONF servers to		containers use a feature statement, enabling NETCONF servers to
	accurately advertise what they support.		accurately advertise what they support.
	module: ietf-netconf-server		module: ietf-netconf-server
	+--rw netconf-server		+--rw netconf-server
	skipping to change at page 8, line 25		skipping to change at page 6, line 44
	| +--rw port? inet:port-number		| +--rw port? inet:port-number
	+--rw tls {tls-listen}?		+--rw tls {tls-listen}?
	+--rw (one-or-many)?		+--rw (one-or-many)?
	+--:(one-port)		+--:(one-port)
	| +--rw port? inet:port-number		| +--rw port? inet:port-number
	+--:(many-ports)		+--:(many-ports)
	+--rw interface* [address]		+--rw interface* [address]
	+--rw address inet:host		+--rw address inet:host
	+--rw port? inet:port-number		+--rw port? inet:port-number
	5.2. The "call-home" Grouping
	To enable transports to configure initiating connections to remote		To enable transports to configure initiating connections to remote
	applications in a common way, this grouping is defined. This		applications in a common way, this grouping is defined. This
	grouping configures a list of network-managers, each with some		grouping configures a list of network-managers, each with some
	transport-specific configuration augmented in. Each of the transport		transport-specific configuration augmented in. Each of the transport
	specific containers use a feature statement, enabling NETCONF servers		specific containers use a feature statement, enabling NETCONF servers
	to accurately advertise what they support.		to accurately advertise what they support.
	module: ietf-netconf-server		module: ietf-netconf-server
	+--rw netconf-server		+--rw netconf-server
	+--rw call-home		+--rw call-home
	skipping to change at page 9, line 18		skipping to change at page 7, line 35
	| | +--rw count-max? uint8		| | +--rw count-max? uint8
	| +--:(periodic-connection)		| +--:(periodic-connection)
	| +--rw periodic		| +--rw periodic
	| +--rw timeout-mins? uint8		| +--rw timeout-mins? uint8
	| +--rw linger-secs? uint8		| +--rw linger-secs? uint8
	+--rw reconnect-strategy		+--rw reconnect-strategy
	+--rw start-with? enumeration		+--rw start-with? enumeration
	+--rw interval-secs? uint8		+--rw interval-secs? uint8
	+--rw count-max? uint8		+--rw count-max? uint8
	6. The "ietf-system-tls-auth" Data Model		3.2. YANG Module
	This data model augments the "ietf-system" module defined in
	[draft-ietf-netmod-system-mgmt] by adding some configuration nodes
	under its "/system/authentication" subtree.
	module: ietf-system-tls-auth
	augment /sys:system/sys:authentication:
	+--rw tls
	+--rw cert-maps {tls-map-certificates}?
	| +--rw cert-to-name* [id]
	| +--rw id uint32
	| +--rw fingerprint x509c2n:tls-fingerprint
	| +--rw map-type identityref
	| +--rw name string
	+--rw psk-maps {tls-map-pre-shared-keys}?
	+--rw psk-map* [psk-identity]
	+--rw psk-identity string
	+--rw user-name nacm:user-name-type
	+--rw not-valid-before? yang:date-and-time
	+--rw not-valid-after? yang:date-and-time
	+--rw key yang:hex-string
	7. The "ietf-netconf-server" YANG Module
	This YANG module imports YANG types from [RFC6991].		This YANG module imports YANG types from [RFC6991].
	RFC Ed.: update the date below with the date of RFC publication		RFC Ed.: update the date below with the date of RFC publication
	and remove this note.		and remove this note.
	<CODE BEGINS> file "ietf-system-tls-auth.@2014-05-16.yang"		<CODE BEGINS> file "ietf-netconf-server.@2014-05-16.yang"
	module ietf-netconf-server {		module ietf-netconf-server {
	namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server";		namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server";
	prefix "ncserver";		prefix "ncserver";
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet; // RFC 6991		prefix inet; // RFC 6991
	}		}
	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://tools.ietf.org/wg/netconf/>
	WG List: <mailto:netconf@ietf.org>		WG List: <mailto:netconf@ietf.org>
	WG Chair: Mehmet Ersue		WG Chair: Mehmet Ersue
	<mailto:mehmet.ersue@nsn.com>		<mailto:mehmet.ersue@nsn.com>
	skipping to change at page 18, line 33		skipping to change at page 16, line 27
	}		}
	container call-home {		container call-home {
	uses call-home-config;		uses call-home-config;
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	8. The "ietf-system-tls-auth" YANG Module		4. Keep-Alives for SSH and TLS
			One the objectives listed above, Keep-Alives for Persistent
			Connections (Section 2.4.6) indicates a need for a "keep-alive"
			mechanism. This section specifies how the NETCONF keep-alive
			mechanism is to be implemented.
			Both SSH and TLS have the ability to support keep-alives. Using
			these mechanisms, the keep-alive messages are sent inside the
			encrypted tunnel, thus thwarting spoof attacks.
			4.1. SSH
			The SSH keep-alive solution that is expected to be used when
			configured using the data model defined in this document is
			ubiquitous in practice, though never being explicitly defined in an
			RFC. The strategy used is to purposely send a malformed request
			message with a flag set to ensure a response. More specifically, per
			section 4 of [RFC4253], either SSH peer can send a
			SSH_MSG_GLOBAL_REQUEST message with "want reply" set to '1' and that,
			if there is an error, will get back a SSH_MSG_REQUEST_FAILURE
			response. Similarly, section 5 of [RFC4253] says that either SSH
			peer can send a SSH_MSG_CHANNEL_REQUEST message with "want reply" set
			to '1' and that, if there is an error, will get back a
			SSH_MSG_CHANNEL_FAILURE response.
			To ensure that the request will fail, current implementations send an
			invalid "request name" or "request type", respectively. Abiding to
			the extensibility guidelines specified in Section 6 of [RFC4251],
			these implementations use the "name@domain". For instance, when
			configured to send keep-alives, OpenSSH sends the string
			"keepalive@openssh.com". In order to remain compatible with existing
			implementations, this draft does not require a specific "request
			name" or "request type" string be used.
			4.2. TLS
			The TLS keep-alive solution is defined in [RFC6520]. This solution
			allows both peers to advertise if they can receive heartbeat request
			messages from its peer. For standard NETCONF over TLS connections,
			devices SHOULD advertise "peer_allowed_to_send", as per [RFC6520].
			This advertisement is not a "MUST" in order to grandfather existing
			NETCONF over TLS implementations. For NETCONF over TLS Call Home,
			the network management system MUST advertise "peer_allowed_to_send"
			per [RFC6520]. This is a "MUST" so as to ensure devices can depend
			in it always being there for call home connections, which is
			conveniently when keep-alives are needed the most.
			5. User Authentication for TLS
			5.1. Introduction
			The NETCONF Server Module defined in this draft focuses on the
			configuration the SSH and TLS transports. This module does not
			define a means to configure User Authentication, as that is a stated
			focus for [draft-ietf-netmod-system-mgmt], however, that draft does
			not define configuration nodes for TLS client authentication. Thus,
			this draft also includes the following YANG module to augment TLS
			client authentication into the "ietf-system" module defined in
			[draft-ietf-netmod-system-mgmt].
			5.2. Data Model Overview
			This data model augments the "ietf-system" module defined in
			[draft-ietf-netmod-system-mgmt] by adding some configuration nodes
			under its "/system/authentication" subtree.
			module: ietf-system-tls-auth
			augment /sys:system/sys:authentication:
			+--rw tls
			+--rw trusted-ca-certs
			| +--rw trusted-ca-cert* binary
			+--rw trusted-client-certs
			| +--rw trusted-client-cert* binary
			+--rw cert-maps {tls-map-certificates}?
			| +--rw cert-to-name* [id]
			| +--rw id uint32
			| +--rw fingerprint x509c2n:tls-fingerprint
			| +--rw map-type identityref
			| +--rw name string
			+--rw psk-maps {tls-map-pre-shared-keys}?
			+--rw psk-map* [psk-identity]
			+--rw psk-identity string
			+--rw user-name nacm:user-name-type
			+--rw not-valid-before? yang:date-and-time
			+--rw not-valid-after? yang:date-and-time
			+--rw key yang:hex-string
			5.3. YANG Module
	This YANG module imports YANG extensions from [RFC6536], and imports		This YANG module imports YANG extensions from [RFC6536], and imports
	YANG types from [RFC6991] and a YANG grouping from		YANG types from [RFC6991] and a YANG grouping from
	[I-D.ietf-netmod-snmp-cfg].		[I-D.ietf-netmod-snmp-cfg].
	RFC Ed.: update the date below with the date of RFC publication		RFC Ed.: update the date below with the date of RFC publication
	and remove this note.		and remove this note.
	<CODE BEGINS> file "ietf-netconf-server.@2014-05-16.yang"		<CODE BEGINS> file "ietf-system-tls-auth.@2014-05-16.yang"
	module ietf-system-tls-auth {		module ietf-system-tls-auth {
	namespace "urn:ietf:params:xml:ns:yang:ietf-system-tls-auth";		namespace "urn:ietf:params:xml:ns:yang:ietf-system-tls-auth";
	prefix "system-tls-auth";		prefix "system-tls-auth";
	import ietf-system { // draft-ietf-netmod-system-mgmt		import ietf-system { // draft-ietf-netmod-system-mgmt
	prefix "sys";		prefix "sys";
	}		}
	import ietf-netconf-acm {		import ietf-netconf-acm {
	prefix nacm; // RFC 6536		prefix nacm; // RFC 6536
	}		}
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang; // RFC 6991		prefix yang; // RFC 6991
	}		}
	import ietf-x509-cert-to-name {		import ietf-x509-cert-to-name {
	skipping to change at page 20, line 35		skipping to change at page 20, line 21
	}		}
	feature tls-map-pre-shared-keys {		feature tls-map-pre-shared-keys {
	description		description
	"The tls-map-pre-shared-keys feature indicates that the		"The tls-map-pre-shared-keys feature indicates that the
	NETCONF server implements mapping TLS pre-shared keys to NETCONF		NETCONF server implements mapping TLS pre-shared keys to NETCONF
	usernames.";		usernames.";
	}		}
	grouping tls-global-config {		grouping tls-global-config {
	// Objects for deriving NETCONF usernames from X.509
	// certificates.		container trusted-ca-certs {
	container cert-maps {		description
	if-feature tls-map-certificates;		"A list of Certificate Authority (CA) certificates that a
	uses x509c2n:cert-to-name;		NETCONF server can use to authenticate a NETCONF client's
			certificate. A client's certificate is authenticated if
			its Issuer matches one of the configured trusted CA
			certificates.";
			leaf-list trusted-ca-cert {
			type binary;
			ordered-by system;
	description		description
	"The cert-maps container is used by a NETCONF server to		"The binary certificate structure, as
	map the NETCONF client's presented X.509 certificate to		specified by RFC 5246, Section 7.4.6, i.e.,:
	a NETCONF username.
	If no matching and valid cert-to-name list entry can be		opaque ASN.1Cert<1..2^24>;
	found, then the NETCONF server MUST close the connection,
	and MUST NOT accept NETCONF messages over it.";		";
			reference
			"RFC 5246: The Transport Layer Security (TLS)
			Protocol Version 1.2";
	}		}
			}
			container trusted-client-certs {
			description
			"A list of client certificates that a NETCONF server can
			use to authenticate a NETCONF client's certificate. A
			client's certificate is authenticated if it is an exact
			match to one of the configured trusted client certificates.";
			leaf-list trusted-client-cert {
			type binary;
			ordered-by system;
			description
			"The binary certificate structure, as
			specified by RFC 5246, Section 7.4.6, i.e.,:
			opaque ASN.1Cert<1..2^24>;
			";
			reference
			"RFC 5246: The Transport Layer Security (TLS)
			Protocol Version 1.2";
			}
			}
			// Objects for deriving NETCONF usernames from X.509
			// certificates.
			container cert-maps {
			if-feature tls-map-certificates;
			uses x509c2n:cert-to-name;
			description
			"The cert-maps container is used by a NETCONF server to
			map the NETCONF client's presented X.509 certificate to
			a NETCONF username.
			If no matching and valid cert-to-name list entry can be
			found, then the NETCONF server MUST close the connection,
			and MUST NOT accept NETCONF messages over it.";
			}
	// Objects for deriving NETCONF usernames from TLS		// Objects for deriving NETCONF usernames from TLS
	// pre-shared keys.		// pre-shared keys.
	container psk-maps {		container psk-maps {
	if-feature tls-map-pre-shared-keys;		if-feature tls-map-pre-shared-keys;
	description		description
	"During the TLS Handshake, the client indicates which		"During the TLS Handshake, the client indicates which
	key to use by including a PSK identity in the TLS		key to use by including a PSK identity in the TLS
	ClientKeyExchange message. On the NETCONF server side,		ClientKeyExchange message. On the NETCONF server side,
	this PSK identity is used to look up an entry in the psk-map		this PSK identity is used to look up an entry in the psk-map
	list. If such an entry is found, and the pre-shared keys		list. If such an entry is found, and the pre-shared keys
	match, then the client is authenticated. The NETCONF		match, then the client is authenticated. The NETCONF
	server uses the value from the user-name leaf in the		server uses the value from the user-name leaf in the
	skipping to change at page 22, line 19		skipping to change at page 23, line 4
	nacm:default-deny-all;		nacm:default-deny-all;
	description		description
	"The key associated with the PSK identity";		"The key associated with the PSK identity";
	reference		reference
	"RFC 4279: Pre-Shared Key Ciphersuites for Transport		"RFC 4279: Pre-Shared Key Ciphersuites for Transport
	Layer Security (TLS)";		Layer Security (TLS)";
	}		}
	}		}
	}		}
	}		}
	augment "/sys:system/sys:authentication" {		augment "/sys:system/sys:authentication" {
	container tls {		container tls {
	uses tls-global-config;		uses tls-global-config;
	// leaf test {
	// type string;
	// }
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	9. Security Considerations		6. Security Considerations
	The YANG modules defined in this memo are designed to be accessed via		The YANG modules defined in this memo are designed to be accessed via
	the NETCONF protocol [RFC6241]. Authorization for access to specific		the NETCONF protocol [RFC6241]. Authorization for access to specific
	portions of conceptual data and operations within this module is		portions of conceptual data and operations within this module is
	provided by the NETCONF access control model (NACM) [RFC6536].		provided by the NETCONF access control model (NACM) [RFC6536].
	There are a number of data nodes defined in the "ietf-netconf-server"		There are a number of data nodes defined in the "ietf-netconf-server"
	and "ietf-system-tls-auth" YANG modules which are writable/creatable/		and "ietf-system-tls-auth" YANG modules which are writable/creatable/
	deletable (i.e., config true, which is the default). These data		deletable (i.e., config true, which is the default). These data
	nodes may be considered sensitive or vulnerable in some network		nodes may be considered sensitive or vulnerable in some network
	skipping to change at page 23, line 20		skipping to change at page 24, line 5
	o /system/authentication/tls/psk-maps/psk-map/user-name: This leaf		o /system/authentication/tls/psk-maps/psk-map/user-name: This leaf
	node contains a user name that some deployments may consider		node contains a user name that some deployments may consider
	sensitive information.		sensitive information.
	o /system/authentication/tls/psk-maps/psk-map/key: This leaf node		o /system/authentication/tls/psk-maps/psk-map/key: This leaf node
	contains a shared key that remote clients use to authenticate		contains a shared key that remote clients use to authenticate
	themselves to the system. This value should not be readable or		themselves to the system. This value should not be readable or
	writable by anyone by default.		writable by anyone by default.
	10. IANA Considerations		7. IANA Considerations
	This document registers two URIs in the IETF XML registry [RFC2119].		This document registers two URIs in the IETF XML registry [RFC2119].
	Following the format in [RFC3688], the following registrations are		Following the format in [RFC3688], the following registrations are
	requested:		requested:
	URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server		URI: urn:ietf:params:xml:ns:yang:ietf-netconf-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-system-tle-auth		URI: urn:ietf:params:xml:ns:yang:ietf-system-tle-auth
	skipping to change at page 23, line 47		skipping to change at page 24, line 32
	name: ietf-netconf-server		name: ietf-netconf-server
	namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server		namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server
	prefix: ncserver		prefix: ncserver
	reference: RFC XXXX		reference: RFC XXXX
	name: ietf-system-tls-auth		name: ietf-system-tls-auth
	namespace: urn:ietf:params:xml:ns:yang:ietf-system-tls-auth		namespace: urn:ietf:params:xml:ns:yang:ietf-system-tls-auth
	prefix: sys-tls-auth		prefix: sys-tls-auth
	reference: RFC XXXX		reference: RFC XXXX
	11. Acknowledgements		8. Other Considerations
			The YANG module define herein does not itself support virtual routing
			and forwarding (VRF). It is expected that external modules will
			augment in VRF designations when needed.
			9. Acknowledgements
	The authors would like to thank for following for lively discussions		The authors would like to thank for following for lively discussions
	on list and in the halls (ordered by last name): Andy Bierman, Martin		on list and in the halls (ordered by last name): Andy Bierman, Martin
	Bjorklund, Benoit Claise, David Lamparter, Alan Luchuk, Ladislav		Bjorklund, Benoit Claise, David Lamparter, Alan Luchuk, Ladislav
	Lhotka, Radek Krejci, Tom Petch, and Phil Shafer.		Lhotka, Radek Krejci, Tom Petch, and Phil Shafer.
	Juergen Schoenwaelder and was partly funded by Flamingo, a Network of		Juergen Schoenwaelder and was partly funded by Flamingo, a Network of
	Excellence project (ICT-318488) supported by the European Commission		Excellence project (ICT-318488) supported by the European Commission
	under its Seventh Framework Programme.		under its Seventh Framework Programme.
	12. References		10. References
	12.1. Normative References		10.1. Normative References
	[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, March 1997.		Requirement Levels ", BCP 14, RFC 2119, March 1997.
	[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Protocol Architecture ", RFC 4251, January 2006.		Protocol Architecture ", RFC 4251, January 2006.
	[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Transport Layer Protocol ", RFC 4253, January 2006.		Transport Layer Protocol ", RFC 4253, January 2006.
	skipping to change at page 25, line 17		skipping to change at page 26, line 8
	[draft-ieft-netconf-reverse-ssh]		[draft-ieft-netconf-reverse-ssh]
	Watsen, K., "NETCONF over SSH Call Home ", draft-ieft-		Watsen, K., "NETCONF over SSH Call Home ", draft-ieft-
	netconf-reverse-ssh-00 (work in progress), May 2014.		netconf-reverse-ssh-00 (work in progress), May 2014.
	[draft-ietf-netmod-system-mgmt]		[draft-ietf-netmod-system-mgmt]
	Bierman, A., "A YANG Data Model for System Management ",		Bierman, A., "A YANG Data Model for System Management ",
	draft-ieft-netmod-system-mgmt-16 (work in progress), May		draft-ieft-netmod-system-mgmt-16 (work in progress), May
	2014.		2014.
	12.2. Informative References		10.2. Informative References
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	Appendix A. Example: SSH Transport Configuration		Appendix A. Example: SSH Transport Configuration
	<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">		<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
	<listen>		<listen>
	<ssh>		<ssh>
	<port>831</port>		<port>831</port>
	skipping to change at page 27, line 33		skipping to change at page 28, line 24
	</network-managers>		</network-managers>
	</call-home>		</call-home>
	</netconf-server>		</netconf-server>
	Appendix C. Example: TLS Authentication Configuration		Appendix C. Example: TLS Authentication Configuration
	<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">		<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
	<authentication>		<authentication>
	<tls xmlns="urn:ietf:params:xml:ns:yang:ietf-system-tls-auth">		<tls xmlns="urn:ietf:params:xml:ns:yang:ietf-system-tls-auth">
	<cert-maps>		<trusted-ca-certs>
	<cert-to-name>		<trusted-ca-cert>
	<id>1</id>		QW4gRWFzdGVyIGVnZywgZm9yIHRob3NlIHdobyBtaWdodCBsb29rICA6KQo=
	<fingerprint>11:0A:05:11:00</fingerprint>		</trusted-ca-cert>
	<map-type>x509c2n:san-any</map-type>		</trusted-ca-certs>
	</cert-to-name>
	<cert-to-name>
	<id>2</id>
	<fingerprint>11:0A:05:11:00</fingerprint>
	<map-type>x509c2n:specified</map-type>
	<name>Joe Cool</name>
	</cert-to-name>
	</cert-maps>
	<psk-maps>		<trusted-client-certs>
	<psk-map>		<trusted-client-cert>
	<psk-identity>a8gc8]klh59</psk-identity>		SSBhbSB0aGUgZWdnIG1hbiwgdGhleSBhcmUgdGhlIGVnZyBtZW4uCg==
	<user-name>admin</user-name>		</trusted-client-cert>
	<not-valid-before>2013-01-01T00:00:00Z</not-valid-before>		<trusted-client-cert>
	<not-valid-after>2014-01-01T00:00:00Z</not-valid-after>		SSBhbSB0aGUgd2FscnVzLCBnb28gZ29vIGcnam9vYi4K
			</trusted-client-cert>
			</trusted-client-certs>
	</psk-map>		<cert-maps>
	</psk-maps>		<cert-to-name>
			<id>1</id>
			<fingerprint>11:0A:05:11:00</fingerprint>
			<map-type>x509c2n:san-any</map-type>
			</cert-to-name>
			<cert-to-name>
			<id>2</id>
			<fingerprint>11:0A:05:11:00</fingerprint>
			<map-type>x509c2n:specified</map-type>
			<name>Joe Cool</name>
			</cert-to-name>
			</cert-maps>
			<psk-maps>
			<psk-map>
			<psk-identity>a8gc8]klh59</psk-identity>
			<user-name>admin</user-name>
			<not-valid-before>2013-01-01T00:00:00Z</not-valid-before>
			<not-valid-after>2014-01-01T00:00:00Z</not-valid-after>
			</psk-map>
			</psk-maps>
	</tls>		</tls>
	</authentication>		</authentication>
	</system>		</system>
	Appendix D. Change Log		Appendix D. Change Log
	D.1. I-D to 00		D.1. I-D to 00
	o Changed title to "NETCONF Server Configuration Model"		o Changed title to "NETCONF Server Configuration Model"
	skipping to change at page 28, line 32		skipping to change at page 29, line 37
	o Added section "Keep-Alives for SSH and TLS"		o Added section "Keep-Alives for SSH and TLS"
	o Updated the Security Considerations section		o Updated the Security Considerations section
	o Added text for supporting VRFs via augments		o Added text for supporting VRFs via augments
	o Factored the TLS-AUTH config into another module augmenting the		o Factored the TLS-AUTH config into another module augmenting the
	"ietf-system" module		"ietf-system" module
			D.2. 00 to 01
			o Restructured document so it flows better
			o Added trusted-ca-certs and trusted-client-certs objects into the
			ietf-system-tls-auth module
	Appendix E. Open Issues		Appendix E. Open Issues
	o NETCONF implementations typically have config parameters such as		o NETCONF implementations typically have config parameters such as
	session timeouts or hello timeouts. Shall they be included in		session timeouts or hello timeouts. Shall they be included in
	this model?		this model?
	o Do we need knobs to enable/disable call-home without the need to		o Do we need knobs to enable/disable call-home without the need to
	remove all the call-home client configuration?		remove all the call-home client configuration?
	Authors' Addresses		Authors' Addresses
End of changes. 33 change blocks.
	159 lines changed or deleted		237 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/