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/