One document matched: draft-kwatsen-netconf-zerotouch-01.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std"
ipr="trust200902"
docName="draft-kwatsen-netconf-zerotouch-01">
<front>
<title abbrev="ZeroTouch">Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>kwatsen@juniper.net</email>
</address>
</author>
<author initials="S.H." surname="Hanna" fullname="Stephen Hanna">
<organization>Juniper Networks</organization>
<address>
<email>shanna@juniper.net</email>
</address>
</author>
<author initials="J.M.C." surname="Clarke" fullname="Joe Marcus Clarke">
<organization>Cisco Systems</organization>
<address>
<email>jclarke@cisco.com</email>
</address>
</author>
<author initials="M.A." surname="Abrahamsson" fullname="Mikael Abrahamsson">
<organization>T-Systems</organization>
<address>
<email>"mikael.abrahamsson@t-systems.se</email>
</address>
</author>
<date month="February" year="2014"/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>zerotouch</keyword>
<abstract>
<t>This draft presents a technique for how to establish a
secure NETCONF connection between a newly deployed
networking device, configured with just its factory
default settings, and the new owner's Network Management
System (NMS).</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>The solution presented herein is designed to support
the NETCONF configuration protocol <xref target="RFC6241"/>.
This is achieved by leveraging the recently standardized call home
mechanisms for SSH <xref target="REVERSE-SSH"/> and TLS
<xref target="RFC5539bis"/>.</t>
<t>A fundamental business requirement is to reduce
operational costs where possible. Deploying new devices
is typically one of the largest costs in running
the network, as sending trained specialists to each
site is both cost prohibitive and doesn't scale.</t>
<t>Both networking vendors and standard bodies have
tried to address this issue, with varying levels of
success. For instance, the Broadband Forum TR-069 specification
<xref target="TR069"/> relies on DHCP for NMS discovery,
but this only works in environments where the DHCP
server can be configured, which isn't the case when
the device is connected to an ISP's network. In another
example, some network vendors have enabled their devices
to load an initial configuration from removable storage
media (e.g., a USB flash drive), but not all devices have
such ports.</t>
<t>The solution presented herein attempts to
addresses the evaluation criteria outlined by the draft
"Configuring Security Parameters in Small Devices"
<xref target="draft-hanna-zeroconf-seccfg-00"/>:
security, flexibility, ease of use, and device cost.
More specifically:
<list style="symbols">
<t>Security
<list style="empty">
<t>Security is fundamental to any automated discovery
solution, especially one that bootstraps the
parameters used to secure a device's connection
to its NMS. Consistent with <xref target="RFC3365"/>,
security is a required aspect of ZeroTouch.
Every ZeroTouch implementation is sure to be secure.</t>
</list>
</t>
<t>Flexibility
<list style="empty">
<t>ZeroTouch is designed to support a wide variety of
deployments, including cases where the device is
connected to a network without administrative control
of the local DHCP and DNS servers, where the device
is connected to an untrusted network, or deployed
behind a gateway that dynamically translates its
network address (e.g., NAT). Special consideration
is also provided for devices that are on a network with
no public Internet access.</t>
</list>
</t>
<t>Ease of Use
<list style="empty">
<t>Ultimately, the success of the solution depends on
the ability for presumably non-technical personnel to
be able to complete the installation by themselves. To
this end, it is envisioned that installers only need to
connect the device to a wired or wireless network and a
power source and wait for the device to indicate success.
ZeroTouch also attempts to not be overly complicated for
NMS administrators.</t>
</list>
</t>
<t>Device Cost
<list style="empty">
<t>For vendors of devices with already slim margins,
such as consumer-oriented devices, a significant
concern is the cost of goods. Fortunately, the
solution presented in this draft requires minimal
additional components. Additionally, the development
effort doesn't seem exorbitant, though that may vary
by vendor and their circumstances.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Actors and Roles">
<section title="Device">
<t>The device is the networking entity that initiates
Zero Touch. Whenever a device boots with its factory
default settings, it initiates ZeroTouch with the goal
of finding a Configlet with which it can use to
configure itself. Once a Configlet is found, the
device initializes its configuration using that Configlet
and then exits ZeroTouch. Since the Configlet
configures the device to "call home" upon entering
its normal operating mode, the device immediately
begins trying to establish a reverse-SSH or
reverse-TLS connection, as specified by the
Configlet.</t>
</section>
<section title="Configlet" anchor="configlet">
<t>A Configlet is an XML file, containing specific
YANG-defined configuration, that has been signed by
a trusted signer known to the device (e.g., the
device's manufacturer).</t>
<t>The Configlet data-model, defined by the YANG
module in this document (see <xref target="configlet"/>),
is just enough to configure a local user account and
either reverse-SSH or reverse-TLS. More specifically,
this data-model is a subset of what's defined in
ietf-system and ietf-netconf-server YANG models. This
focused data-model is consistent with the common
use-case of having the NMS push a full configuration
to a device when it calls home.</t>
<t>The signature on the Configlet is enveloped,
meaning that the signature is contained inside the
XML file itself. The signature block also contains
the X.509 certificate of the Configlet Signer
and its chain of trust.</t>
<t>Once a device authenticates the signature on a
Configlet and matches the unique identifier
(e.g., serial number) within the Configlet, it merges
the configuration contained in the Configlet into
its running datastore.</t>
</section>
<section title="Configlet Signer" anchor="configlet-signer">
<t>A Configlet Signer is the entity authorized by the
device manufacturer to sign Configlets for its devices (note:
this may be the device vendor itself).</t>
<t>A Configlet Signer MUST provide a user-facing service
enabling the creation of a Configlet with user-specific
deployment values, using the YANG schema defined in
<xref target="configlet"/>. This document does not
specify what form this interface must take, so it is
the Configlet Signer's discretion if it is a web page,
a REST API, or something else.</t>
<t>A Configlet Signer MUST ensure that the end-user is
the rightful owner of the device containing the unique
identifier value to be put into the Configlet. How
a Configlet Signer ensures this is outside the scope of
this document, but it is envisioned that the vendor
would provide a secured interface for its trusted
Configlet Signers to use.</t>
<t>A Configlet Signer MUST have an X.509 certificate with
Key Usage capable of signing data (digitalSignature) and
be signed by a certificate authority having a chain of
trust leading to a trust anchor known to the devices
loading its Configlets. The Configlet Signer MUST
possess all intermediate certificates leading to its
trust anchor.</t>
<t>When a Configlet Signer signs a Configlet, it attaches
both the signature and the chain of X.509 certificates,
including its own, but not necessarily including the
trust anchor's certificate. This chain of certificates
is needed so a device can validate a Configlet using
only the Configlet Signer trust anchors known to it.</t>
<t>A Configlet Signer does not need to retain the Configlet
after signing it; it is expected that either the end-user
or the Configlet Signer will convey the signer Configlet
to a Configuration Server where it will be hosted.</t>
</section>
<section title="Configuration Server" anchor="configlet-server">
<t>A Configuration Server is the entity hosting configurations
that can be downloaded over a network. Configuration Servers are
known to devices in the form of a URI, to which a device
appends the fingerprint of its entity certificate
(see <xref target="precondition"/> for details). For
instance, if the URI were:
<figure>
<artwork><![CDATA[
https://example.com?id=
scp://user@zerotouch.example.com/configlets/
ftp://example.com/zerotouch/configlets/
]]></artwork>
</figure>
then the device would try to access:
<figure>
<artwork><![CDATA[
https://example.com?id=<fingerprint>
scp://user@zerotouch.example.com/configlets/<fingerprint>
ftp://example.com/zerotouch/configlets/<fingerprint>
]]></artwork>
</figure>
where the fingerprint is generated using the SHA-256
algorithm over the device's entity certificate. For
instance, using OpenSSL's command line tool: `openssl dgst
-sha256 <entity certificate>` (see <xref
target="precondition"/>).</t>
<t>The Configuration Server is expected to be able to map
the fingerprint to a device-specific unique identifier
(e.g., serial number), which is the value contained in the
Configlet it is hosting. How the Configuration Server does
this mapping is outside the scope of this document, but
it is envisioned that the vendor would provide a secured
interface for its trusted Configuration Servers to use.</t>
<t>Configuration Servers do not need to use encryption, since the
Configlets themselves are immutable to tampering, due to
being signed. However, for confidentiality reasons, it
is RECOMMENDED to use encryption, so adversaries cannot
see the Configlet's otherwise clear-text content,
from which they can learn some details about the device's
internal deployment.</t>
<t>If a Configuration Server uses X.509-based encryption,
then its X.509 certificate MUST have a chain of trust
to a trust anchor known to devices. The Configuration
Server MUST possess all the intermediate certificates leading
to a trust anchor.</t>
<t>When a Configuration Server negotiates encryption with the
device, it provides the chain of X.509 certificates, including
its own, but not necessarily including the trust anchor's
certificate. Devices need the chain of certificates to be
passed so they can validate the server using only a minimal
list of Configuration Server trust anchors.</t>
<t>Configuration Server's SHOULD automatically expire
Configlets after some user-specified amount of time.</t>
<t>In order to facilitate troubleshooting and auditing, the
Configuration Server SHOULD record into a log a record of
the various Configlet download requests. This draft does
not define what information should be kept or for how
long.</t>
</section>
<section title="Network Management System (NMS)">
<t>The NMS is the ultimate destination of ZeroTouch for
a device. It is the NMS's network address configured
in the Configlet. The device will connect to the NMS
using either a reverse-SSH or reverse-TLS, as configured
by the Configlet loaded.</t>
<t>In order to authenticate the device, the NMS
MUST possess the X.509 certificate for the trust anchor
leading to the device's entity certificate. The NMS
uses this certificate to validate the server-certificate
the device presents during SSH or TLS transport negotiation.</t>
<t>The NMS SHOULD also validate that the unique identifier
(e.g., serial number), within the "Common Name" field of
the device's X.509 certificate, is an identity that the NMS
is expecting, and not another device having the same
device type. In order for the NMS to know the unique
identifiers for devices shipped directly to their destinations,
it may be necessary for the device manufacturer to provide the
unique identifiers along with other shipping or billing information.
This draft not specify a format for this information
exchange.</t>
<t>In addition to authenticating the device, the NMS must
also authenticate itself to the device. How
this is done is protocol specific. For reverse-SSH, the
NMS needs to know the information configured
on the device by the Configlet it loaded, specifically the
name of a local user account and the necessary credentials
configured for the account (i.e., password or the private-half
of a SSH host key). For reverse-TLS, the NMS must present
a client certificate. Presumably the NMS has been configured
with the information used when the Configlet was created.</t>
</section>
</section>
<section title="Device Boot Sequence">
<section title="Precondition" anchor="precondition">
<t>Devices supporting ZeroTouch MUST support either
reverse-SSH or reverse-TLS, and MAY support both. In
either case, the device MUST present an X.509-based
certificate encoding a unique device identifier
(e.g. serial number) and a public key, both signed
by a trusted certificate authority. This certificate
is the "entity certificate" in the diagram below.
This certificate is needed in order for the NMS to
positively authenticate a device. For reverse-SSH,
this certificate requirement constrains the SSH host
key algorithms the device is allowed to to use to
those defined in <xref target="RFC6187"/>.</t>
<t>The unique identifier MUST be something that is
both known to the device and easily tracked through
labels affixed to the device as well as the box it is
packaged in. A device's serial number is commonly
treated this way and would be suitable for this
purpose.</t>
<t>The device MUST possess the private key matching
the public key encoded in the entity certificate.
Ideally, the private key SHOULD be generated and
protected by a tamper-resistant cryptographic processor,
as this provides the greatest assurance that the private
key is known to no one, including the device's
manufacturer.</t>
<t>The entity certificate MUST be signed by a certificate
authority having a chain of trust to a well-known trust
anchor. The device MUST also possess the X.509
certificates for any intermediate CAs leading to the
trust anchor. During SSH or TLS transport setup, the
device will send both its entity and any intermediate
certificates so the NMS can verify the certificate
path using only the well-known trust anchor.</t>
<t>Since the entity certificate is to be used for SSH
and TLS connections, its Key Usage, if set, SHOULD have
the digitalSignature, keyEncipherment, and keyAgreement
bits set.</t>
<t>In order for a device to know where it can obtain a
Configlet, it MUST have two sets of URIs, identifying
resources where it can obtain Configlets. One set contains
secure schemes (e.g. https://, scp://) and the other contains
insecure schemes (e.g., http://, ftp://). These URIs
point to the "Configuration Servers" in the diagram below.</t>
<t>In order for a device to use a URI with a secure
scheme, devices MUST possess a trust anchor certificate
that it can use to authenticate the Configuration Server with.
As each Configuration Server may use a different trust
anchor, this generalizes to a list of Configuration
Server trust anchor certificates. These trust anchors
MAY include broadly recognized certificate authorities,
such as the certificates packaged with web browsers.</t>
<t>In order for a device to authenticate Configlets, it
MUST have a trust anchor for the CA that signed the
Configlet. The CA used to sign Configlets is called a
"Configlet Signer" in the diagram below. In order to
enable Configlets to be signed by different CAs, the
device MAY have either a list of trust anchors, or a
single trust anchor that delegates Configlet signing
trust to other CAs. The diagram below shows a list of
Configlet Signer trust anchors only because it is
the more flexible option.</t>
<t>Devices SHOULD ensure that all its trust anchor
certificates, including those for the Configlet
Signer and Configuration Server, are protected from
external modification. It is for this reason that
the diagram below shows them in immutable storage.
However, it may be necessary to update these
certificates over time (e.g., the vendor wants to
delegate trust to a new CA). Therefore, devices
MAY update these trust anchors when needed through
a verifiable process, such as a software upgrade
using signed software images.</t>
<t>Devices SHOULD ensure that the certificates
for its trust anchors are protected from external modification,
specifically the Configlet Signer and Configuration Server
X.509 certificates. It is for this reason that the
diagram below shows them in immutable storage. The
certificates for the device's trust anchors MAY be
updated along with a standard software image upgrade.</t>
<t>
<figure>
<preamble>Device State Precondition</preamble>
<artwork><![CDATA[
+------------------------------------------------------------------+
| <device> |
| |
| +------------------------------------------------------+ |
| | <immutable storage> | |
| | | |
| | list of Configlet Signer trust anchor certificates | |
| | list of Configuration Server trust anchor certs | |
| +------------------------------------------------------+ |
| |
| +----------------------------------------------------------+ |
| | <other storage> | |
| | | |
| | two sets of Configuration Server URIs | |
| | device entity & associated intermediate certificate(s) | |
| +----------------------------------------------------------+ |
| |
| +----------------------+ |
| | <crypto processor> | |
| | | |
| | device private key | |
| +----------------------+ |
| |
+------------------------------------------------------------------+
]]></artwork>
</figure>
</t>
</section>
<section title="Runtime Operation" anchor="runtime-operation">
<t>Whenever a device boots with its factory default
settings, it initiates ZeroTouch with the goal of
finding a configuration with which it can use to configure
itself.</t>
<t>The device MUST first initialize its networking as
per its default factory configuration. This SHOULD
result in the dynamic assignment of an IP address,
subnet or prefix, gateway, and a DNS server.</t>
<t>While initializing its networking, the device
MAY receive some additional URIs for where a software
image or configuration can be downloaded. This draft
does not define how such URIs MAY be exchanged, for
instance, using DHCP options.</t>
<t>If, while initializing its networking, the device
receives software image URIs, it MAY download and
install the software image only if the image is protected
from modification (e.g., the image is signed) and the
device is able to verify its integrity. The device
SHOULD try URIs with secure schemes before URIs with
insecure schemes (e.g., scp:// before ftp://). If the
device needs to reboot to activate the new software image,
it MUST do so with its default factory configuration set
so that ZeroTouch will run again when the device comes
back up.</t>
<t>If, while initializing its networking, the device
receives configuration URIs, each URI SHOULD be appended
to one of the device's two sets of Configuration Server
URIs, depending on if the URI's scheme is secure or not.
URIs added this way MUST remain distinguishable from those
URIs the device was shipped with, for reasons discussed
in <xref target="runtime-operation"/>.</t>
<t>Before trying any of the Configuration Server URIs,
the device SHOULD first try to load a configuration
through local means that assert physical presence.
For instance, a removable USB flash drive or
near-field communication mechanism. Configurations
obtained through an assertion of physical presence
do not have to be signed or contain the device's
unique identifier (e.g., serial number). If a
Configlet is found, the device MUST use it without
trying any of the Configuration Server URIs.</t>
<t>If a configuration was not found via physical presence,
the device then iterates over its two sets of Configuration
Server URIs. The device MUST first try all the URIs
from the set having secure schemes before trying any
of the URIs from the set having insecure schemes. For
each URI, until a usable configuration is found and
successfully loaded, the device attempts to download
a configuration from the URI. If the URI uses a
secure scheme (e.g., https), the device MUST validate
the Configuration Server's certificate using one of
its Configuration Server trust anchors. If the device
is unable to verify the server's certificate, the
device MUST skip that URI. If the device reaches the
end of all its URIs without finding a configuration,
it MAY continue its normal boot sequence using its
factory default configuration.</t>
<t>When the device is accessing a Configuration Server
URI that it was shipped with (i.e., not discovered
while initializing its networking, it MUST do so by
appending the fingerprint of its entity certificate to
the URI's string, as described in the <xref
target="configlet-server"/>. For URIs discovered
while initializing its networking, the device MAY try
both the raw URI as well as the permutation of it
using its fingerprint.</t>
<t>The Configuration Server's response MAY be anything
allowed by the given URI's scheme. For instance, if
the scheme is HTTP-based, the Configuration Server MAY
return an HTTP redirect. In this way, a vendor's
Configuration Server service may allow the device
owner to redirect the device to a Configuration Server
running in their network.</t>
<t>If the Configuration Server returns a Configlet,
the device MUST first verify it before use. Configlet
verification entails both verifying the Configlet's
signature using the device's list of Configlet Signer
trust anchors, and also verifying that the unique identifier
(e.g., serial number) within the Configlet matches the
device's unique identifier.</t>
<t>Once a Configlet is authenticated, the device
merges the Configlet's contents into its running
configuration and then exits ZeroTouch. Since the
Configlet configures the device to "call home,"
upon entering its normal operating mode, the device
immediately begins trying to establish a reverse-SSH or
reverse-TLS connection, as specified by the Configlet.</t>
<t>If configured to establish a reverse-SSH connection,
the the device MUST use its entity and associated
intermediate X.509 certificates as its host key per
RFC 6187 <xref target="RFC6187"/>. If configured to
use reverse-TLS, the device MUST use its entity and
associated intermediate X.509 certificates as its
server-side certificate for the TLS connection.</t>
<t>In order to facilitate troubleshooting, the device
SHOULD record into a log information relating
to its stepping through the ZeroTouch sequence of
steps. This draft does not define any specific
log messages, for instance, for Syslog or SNMP.</t>
<t>
<figure>
<preamble>ZeroTouch Sequence Diagram</preamble>
<artwork><![CDATA[
DEVICE LOCAL DHCP CONFIGLET NMS
| SERVER SERVERS |
| | | |
|------------>| | |
| Lease IP | | |
| | | |
|------------------------------->| |
| Iterate until Configlet found | |
| | | |
| | | |
|---------------------+ | |
| Validate Configlet | | |
|<--------------------+ | |
| | | |
| | | |
|---------------------------------------------->|
| reverse-SSH or reverse-TLS | |
| | | |
| | | |
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Configlets">
<section title="Data Model">
<t>The Configlet's data is modeled after the data models
provided by draft-ietf-netmod-system-mgmt and
draft-kwatsen-netconf-server. These data models are
used to configure a local user account and either
reverse-SSH or reverse-TLS. Networking is not included
in the Configlet data model as it is expected that the
device will by assigned a dynamic address by the
network and that it will use this address both when
connecting to a Configuration Server and later the NMS.</t>
<t>
<figure>
<preamble>From draft-ietf-netmod-system-mgmt, the
data model for user authentication has the following
structure:</preamble>
<artwork><![CDATA[
+--rw system
+--rw authentication
+--rw user-authentication-order* identityref
+--rw user* [name]
+--rw name string
+--rw password? crypt-hash
+--rw ssh-key* [name]
+--rw name string
+--rw algorithm string
+--rw key-data binary
]]></artwork>
</figure>
</t>
<t><vspace blankLines='30'/></t>
<t>
<figure>
<preamble>From draft-kwatsen-netconf-server, the
data model for reverse-SSH has the following
structure:</preamble>
<artwork><![CDATA[
+--rw netconf
+--rw ssh {ssh}?
+--rw listen {inbound-ssh}?
| +--rw (one-or-many)?
| +--:(one-port)
| | +--rw port? inet:port-number
| +--:(many-ports)
| +--rw interface* [address]
| +--rw address inet:ip-address
| +--rw port? inet:port-number
+--rw call-home {outbound-ssh}?
+--rw applications
+--rw application* [name]
+--rw name string
+--rw description? string
+--rw servers
| +--rw server* [address]
| +--rw address inet:host
| +--rw port? inet:port-number
+--rw connection-type
| +--rw (connection-type)?
| +--:(persistent-connection)
| | +--rw persistent
| | +--rw keep-alives
| | +--rw interval-secs? uint8
| | +--rw count-max? uint8
| +--:(periodic-connection)
| +--rw periodic
| +--rw timeout-mins? uint8
| +--rw linger-secs? uint8
+--rw reconnect-strategy
| +--rw start-with? enumeration
| +--rw interval-secs? uint8
| +--rw count-max? uint8
+--rw host-keys
+--rw host-key* [name]
+--rw name string
]]></artwork>
</figure>
</t>
<t>
<figure>
<preamble>Also from draft-kwatsen-netconf-server,
the data model for reverse-TLS has the following
structure:</preamble>
<artwork><![CDATA[
+--rw netconf
+--rw tls {tls}?
+--rw listen {inbound-tls}?
| +--rw (one-or-many)?
| +--:(one-port)
| | +--rw port? inet:port-number
| +--:(many-ports)
| +--rw interface* [address]
| +--rw address inet:ip-address
| +--rw port? inet:port-number
+--rw call-home {outbound-tls}?
| +--rw applications
| +--rw application* [name]
| +--rw name string
| +--rw description? string
| +--rw servers
| | +--rw server* [address]
| | +--rw address inet:host
| | +--rw port? inet:port-number
| +--rw connection-type
| | +--rw (connection-type)?
| | +--:(persistent-connection)
| | | +--rw persistent
| | | +--rw keep-alives
| | | +--rw interval-secs? uint8
| | | +--rw count-max? uint8
| | +--:(periodic-connection)
| | +--rw periodic
| | +--rw timeout-mins? uint8
| | +--rw linger-secs? uint8
| +--rw reconnect-strategy
| +--rw start-with? enumeration
| +--rw interval-secs? uint8
| +--rw count-max? uint8
+--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
]]></artwork>
</figure>
</t>
</section>
<section title="Signature">
<t>Configlets obtained over the network MUST be
signed using the W3C standard "XML Signature Syntax
and Processing" <xref target="XMLSIG"/>.
The entire contents of the Configlet MUST be signed.
The signature block must also include the Configlet
Signer's certificate and any intermediate certificates
leading to a Configlet Signer trust anchor.</t>
<t>A signed Configlet example is in the Appendix.</t>
</section>
<section title="YANG Module">
<t>
<figure>
<preamble>Following is the YANG module for the
Configlet:</preamble>
<artwork><![CDATA[
module ietf-netconf-zerotouch {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-zerotouch";
prefix "nczerotouch";
//import ietf-system {
// prefix ncsystem;
//}
import ietf-netconf-server {
prefix ncserver;
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module contains a collection of YANG definitions for
configuring NETCONF zerotouch.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note
// RFC Ed.: please update the date to the date of publication
revision "2014-01-24" {
description
"Initial version";
reference
"RFC XXXX: A YANG Data Model for NETCONF ZeroTouch Configlet";
}
typedef crypt-hash {
type string {
pattern
'$0$.*'
+ '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
+ '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
+ '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
}
description
"The crypt-hash type is used to store passwords using
a hash function. The algorithms for applying the hash
function and encoding the result are implemented in
various UNIX systems as the function crypt(3).
A value of this type matches one of the forms:
$0$<clear text password>
$<id>$<salt>$<password hash>
$<id>$<parameter>$<salt>$<password hash>
The '$0$' prefix signals that the value is clear text. When
such a value is received by the server, a hash value is
calculated, and the string '$<id>$<salt>$' or
$<id>$<parameter>$<salt>$ is prepended to the result. This
value is stored in the configuration data store.
If a value starting with '$<id>$', where <id> is not '0', is
received, the server knows that the value already represents a
hashed value, and stores it as is in the data store.
When a server needs to verify a password given by a user, it
finds the stored password hash string for that user, extracts
the salt, and calculates the hash with the salt and given
password as input. If the calculated hash value is the same
as the stored value, the password given by the client is
accepted.
This type defines the following hash functions:
id | hash function | feature
---+---------------+-------------------
1 | MD5 | crypt-hash-md5
5 | SHA-256 | crypt-hash-sha-256
6 | SHA-512 | crypt-hash-sha-512
The server indicates support for the different hash functions
by advertising the corresponding feature.";
reference
"IEEE Std 1003.1-2008 - crypt() function
Wikipedia: http://en.wikipedia.org/wiki/Crypt_(C)
RFC 1321: The MD5 Message-Digest Algorithm
FIPS.180-3.2008: Secure Hash Standard";
}
container configlet {
description
"Top-level container for ZeroTouch configuration objects.";
container system {
// no way to use top-level "netconf" container?
container authentication {
list user {
key name;
description
"The list of local users configured on this device.";
leaf name {
type string;
description
"The user name string identifying this entry.";
}
leaf password {
type crypt-hash;
description
"The password for this entry.";
}
list ssh-key {
key name;
description
"A list of public SSH keys for this user.";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
leaf name {
type string;
description
"An arbitrary name for the ssh key.";
}
leaf algorithm {
type string;
mandatory true;
description
"The public key algorithm name for this ssh key.
Valid values are the values in the IANA Secure Shell
(SSH) Protocol Parameters registry, Public Key
Algorithm Names";
reference
"IANA Secure Shell (SSH) Protocol Parameters
registry, Public Key Algorithm Names";
}
leaf key-data {
type binary;
mandatory true;
description
"The binary key data for this ssh key.";
}
}
}
}
}
container netconf-server {
// no way to use top-level "netconf" container?
container ssh {
uses ncserver:ssh-config;
// no way to disable "listen" container?
}
container tls {
uses ncserver:tls-config;
// no way to disable "listen" container?
}
}
}
}
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations">
<t>It is not possible to substitute a Configlet created
for a different device, since devices assert that the
Configlet contains their unique identifier (e.g., serial number).</t>
<t>It is possible to substitute a Configlet created for
a device with a different Configlet created for the same
device. Generally, unless imposed by the Configlet Signers,
there is no limit to the number of Configlets that may be
generated for a given device. This could be resolved, in
part, by placing a timestamp into the Configlet and
ensuring devices do not load Configlets older than some
amount, but this requires the devices have an accurate
clock when validating a Configlet and for Configlet
Signers to not sign a Configlet when another Configlet
is still active.</t>
<t>Confidentiality of Configlets loaded over a network
is only assured when the device uses a secure networking
scheme and validates the Configuration Server's certificate.</t>
<t>Confidentiality is further provided by using the fingerprint
of the device's entity certificate when doing a Configuration
Server lookup, as it is not guessable and thus makes it
nearly impossible for an adversary to lookup.</t>
<t>This draft allows devices to try alternate means to load
a Configlet before trying the network, so long as they assert
physical presence. For instance, a removable USB drive or
a near-field communication mechanism. Further, this draft
does not require Configlets to be signed, if loaded via a
mechanism that asserts physical presence. or require those
Configlets to have the device's unique identifier value set.
All of these relaxations in Security are deemed acceptable because
physical presence should only be accessible to trusted
parties.</t>
<t>This draft allows devices to use insecure schemes when
doing a Configuration Server lookup. This is deemed acceptable because
the Configlet is tamper-proof, due to being signed, only
confidentiality is lost.</t>
<t>This draft entails the device having an X.509 certificate
that is used by the NMS to authenticate the device. This
certificate and every certificate in the chain leading to the
well known trust anchor, should have a expiration date greater
than the device's useful life expectancy. Given the long-lived
nature of these device certificates, it is paramount to use a
strong key length (e.g., 512-bit ECC). Configlet Signers should
deploy Online Certificate State Protocol (OCSP) responders
or CRL Distribution Points (CDP) to revoke certificates in
case necessary.</t>
<t>This draft mentions using the device's serial number as
its unique identifier in its entity certificate. This is
because serial numbers are ubiquitous and prominently
contained in invoices and on labels affixed to devices and
their packaging. That said, serial numbers many times encode
revealing information, such as the device's model number,
manufacture date, and/or sequence number. Knowledge of this
information may provide an adversary with details needed
to launch an attack. To address this concern, the
certificate could contain the hash of the serial number
instead, which the NMS could also compute, but doing so
is much less intuitive and raises questions if it is just
security through obscurity.</t>
<t>It is paramount the device manufacturer ensures the
integrity of the device's list of trust anchors. It
should not be possible for anyone other than the
manufacturer be able to modify the list of trust anchors.
One way to achieve this to sign the list of trust anchors
with a private key known only to the manufacturer, and
for the matching public key to be stored on tamper-resistant
read-only media.</t>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Russ Mundy and Wes
Hardaker for brainstorming the solution presented in this
draft with us during the IETF 87 meeting in Berlin.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S.B." surname="Bradner"
fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC3365">
<front>
<title>
Strong Security Requirements for Internet
Engineering Task Force Standard Protocols
</title>
<author initials="J.S." surname="Schiller"
fullname="Jeffrey Schiller">
<organization>
Massachusetts Institute of Technology
</organization>
</author>
<date month="August" year="2002" />
</front>
<seriesInfo name="RFC" value="3365" />
</reference>
<reference anchor="RFC4252">
<front>
<title>
The Secure Shell (SSH) Authentication Protocol
</title>
<author initials="T.Y." surname="Ylonen"
fullname="Tatu Ylonen">
<organization>
SSH Communications Security Corp
</organization>
</author>
<author initials="C.L." surname="Lonvick"
fullname="Chris Lonvick" role="editor">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="January" year="2006" />
</front>
<seriesInfo name="RFC" value="4252" />
</reference>
<reference anchor="RFC5539bis">
<front>
<title>
Using the NETCONF Protocol over Transport Layer Security (TLS)
</title>
<author initials="M.B." surname="Badra"
fullname="Mohamad Badra">
<organization>LIMOS Laboratory</organization>
</author>
<author initials="A.L." surname="Luchuk"
fullname="Alan Luchuk">
<organization>
SNMP Research, Inc.
</organization>
</author>
<date month="March" year="2011" />
</front>
<seriesInfo name="RFC" value="5539" />
</reference>
<reference anchor="RFC6187">
<front>
<title>
X.509v3 Certificates for Secure Shell Authentication
</title>
<author initials="K.I." surname="Igoe"
fullname="Kevin Igoe">
<organization>National Security Agency</organization>
</author>
<author initials="D.S." surname="Stebila"
fullname="Douglas Stebila">
<organization>
Queensland University of Technology
</organization>
</author>
<date month="March" year="2011" />
</front>
<seriesInfo name="RFC" value="6187" />
</reference>
<reference anchor="RFC6241">
<front>
<title>NETCONF Configuration Protocol</title>
<author initials="R.E." surname="Enns"
fullname="Rob Enns" role="editor">
<organization>Juniper Networks</organization>
</author>
<author initials="M.B." surname="Bjorklund"
fullname="Martin Bjorklund" role="editor">
<organization>Tail-f Systems</organization>
</author>
<author initials="J.S." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder" role="editor">
<organization>Jacobs University</organization>
</author>
<author initials="A.B." surname="Bierman"
fullname="Andy Bierman" role="editor">
<organization>Brocade</organization>
</author>
<date month="June" year="2011" />
</front>
<seriesInfo name="RFC" value="6241" />
</reference>
<reference anchor="REVERSE-SSH">
<front>
<title>Reverse SSH</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<date month="June" year="2013" />
</front>
</reference>
<reference anchor="XMLSIG">
<front>
<title>XML Signature Syntax and Processing</title>
<author fullname="World Wide Web Consortium"></author>
<date month="June" year="2008" />
</front>
<format type="HTML" target="http://www.w3.org/TR/xmldsig-core/"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="TR069">
<front>
<title>
TR-069 Amendment 3, CPE WAN Management Protocol
</title>
<author surname="The Broadband Forum"
fullname="The Broadband Forum"/>
<date month="November" year="2010" />
</front>
<format type="PDF" target="http://www.broadband-forum.org/technical/download/TR-069_Amendment-3.pdf"/>
</reference>
<reference anchor="draft-hanna-zeroconf-seccfg-00">
<front>
<title>
Configuring Security Parameters in Small Devices
</title>
<author surname="Hanna" fullname="Stephen Hanna"/>
<date month="January" year="2002"/>
</front>
<format type="HTML" target="http://tools.ietf.org/html/draft-hanna-zeroconf-seccfg-00"/>
</reference>
</references>
<section title="Examples" anchor="examples">
<section title="Signed Configlet">
<t>
<figure>
<preamble>This example illustrates a Configlet
configuring both a local user account and
reverse-SSH. This Configlet includes both
the Configlet Signer's certificate as well as
an Intermediate certificate. Note that '\'
characters have been added for formatting
reasons.</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-zerotouch">
<!-- from ietf-system.yang -->
<system>
<authentication>
<user>
<name>admin</name>
<ssh-key>
<name>admin's rsa ssh host-key</name>
<algorithm>ssh-rsa</algorithm>
<key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC
jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj
E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC
WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5
vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq
EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6
gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
</ssh-key>
</user>
</authentication>
</system>
<!-- from ietf-netconf-server.yang -->
<netconf-server>
<ssh>
<call-home>
<applications>
<application>
<name>config-mgr</name>
<description>
This entry requests the device to periodically
connect to the Configuration Manager application
</description>
<servers>
<server>
<address>config-mgr1.example.com</address>
</server>
<server>
<address>config-mgr2.example.com</address>
</server>
</servers>
<connection-type>
<periodic>
<timeout-mins>5</timeout-mins>
<linger-secs>10</linger-secs>
</periodic>
</connection-type>
<reconnect-strategy>
<start-with>last-connected</start-with>
<interval-secs>10</interval-secs>
<count-max>3</count-max>
</reconnect-strategy>
<host-keys>
<host-key>
<name>ssh_host_key_cert</name>
</host-key>
<host-key>
<name>ssh_host_key_cert2</name>
</host-key>
</host-keys>
</application>
</applications>
</call-home>
</ssh>
</netconf-server>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference>
<Transforms>
<Transform
Algorithm=\
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>2xlFdlVifb1snGBLJuEZYrLjSUQ=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>\
HUx3S7TZXGJGUhazWGRSB9CBMZ0T+tTrB1fOnTcKi9wU4UOnSw5KMWDvOVwc6ldM
UIOJIuJigWhSkn+VvWSWz6qy7LTYIywNcxDyghMvmMXfoRXETpL+qCDxribMi4VW
mVhEw1oe83kJt7W/0DJUE7FFKRUhPjy9EgxpQX/7WdKSK+4f2uYkSpq2UumW3DIU
LeK9vNRVQBbhmcF3zZWANmwKH5V4WeQimwWE497AeSYWgSImSetADI0NvvXfBZjx
JqzFEaYLNz8IB0ZVY+w14s1RZbN7YmxhN1R3q52wWvHjR2SylR/Z5BpIhYoDeKoD
HMQMf3HZL06Hm5S8r8rgGg==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>\
MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f
VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTEzMTAyMDE2MjIx
MFoXDTE0MTAyMDE2MjIxMFowKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE
AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDf
4hyWqFsf801sZYJQBJ0PB4cHmlnPNOs9pv3QCCB1PzlYhfcDOygVmqhzZjPY+t7q
ZTjPs/E8n5X4dd0DkR80uc4MWmzc40Pz2HAW6GQ2mo+eUYzXUqQFbi3EkqrzddZk
gRi6vuadMkAcJH8ugYR+cbw/LlpXhIy2A5fUh4JP7Y9l1wABTbK8eGhF9cvGxBYR
+KqZJycoV6aaIvD/0NO1CNSaGeAJXXxXWoRF5E6HVKsolTHPPdi+40BmYrCuuWy6
1ybCIP5uZZ7Oza4j0n/fPb6SEqEa0I1zUEWlFQMZYsBClNY5TzWHNgQ5dPJO2qgx
PONwnLIsx46DlAzlpFpXAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV
HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6
Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF
BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50
MIHXBgNVHSMEgc8wgcyAFCHd7bYICEQX3QxR30ixhppG7bjmoYGwpIGtMIGqMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2
YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp
Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG
SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0
cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw
EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG
A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p
emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG
SIb3DQEBCwUAA4IBAQCsVFVA90O8E4p/8ohBYQRezVaWidTHCTM1sdAoeljlrsFX
xqwcQEGVT3BpzwN8w2r+iKOKLQkWv64os0KKL0RIIjmCmJ2RukqH/R0M8Air4+Im
iWI3xV+HzVRsJIrCRT2tzxbchU/i/LQiwhteUEZ9sZbHKyLQe9x9HgByM05ifOGh
z2dcb7AWNlo7nJtRBmx0v9iim2kktqGMuXgBzlnMMabqHMb4L+vjww2Wn5nNYbr/
oXq4fa01MGQyvRPAEOwL3ZxcaqKHvmTn9coBLhpP3nQIEV+V+PngQjtBmwdkjIj5
feDp86jGN6348H+z9CzXUSbyOn6utIxN0SvVESxx</X509Certificate>
<X509Certificate>\
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
QGp1bmlwZXIuY29tMB4XDTEzMTAyMDE2MjIwOVoXDTE0MTAyMDE2MjIwOVowMDET
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK+D34JQ/tsWv5SZ5L2TF7u7
xo7eZEpz/BmnXhxa6keBx5gmjkBXgfSMov7ZJaZfzXkCL01YDDCDQyXBLkh/n2bL
3K0AkEUJPTJgSTTQbPtLkVJgWWAwYASu3/L88c9JH33tvPNQusL0qW683Pd3iVV5
VFOe7c2ZZ0aUtw/FBexjOwPmkQdivb78mfNwyJYkgy0dq0z5GaIIZNna2de1N/Jk
mStZEB6+QJfn0qRsaJbA3TS5JQ13ZBSOqcvtjOIDingjHCXGWEULTeF1UVExNXEG
fsHY2CtQaP/r8hT/8TjPB4mJpbuG1P/BpIAXtBC+hqggwAnNpVfcAxReozzoFCcC
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFCHd7bYI
CEQX3QxR30ixhppG7bjmMIHfBgNVHSMEgdcwgdSAFH+nvIT5PZV62rnjGbqzwT2R
K1FOoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQCVivZlfsyT
TzAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B
AQsFAAOCAQEAXw4/3c9yC4TiYTxHmEXoqYgw2+xyEtJIEs3Kv7MSbF/cJwXz4lci
8Fy3ZiKgq9gj9vloWLT5V9ri1HCgalD8D56iKtQCOvY7TJ64qChAA8q7/WNC3dbJ
s9Op6+nSpolfG8YNHfBroCSfNOVCteJ+pU26p3cC1150Pr+/yZZHnsMhNLYuLCvq
29uvnPDBC4MMVfcMbasPpsxL7Ue4PJsjnLquGLZ33MgNGP1TdefvYCFLF2ZEIbvi
KEGLOTXMrXsbUbQLZAdlq6kLCm7A3u6gwTMg+NydCziVsARq+ZKJS0n3vDoAIJxl
BfXhJE4VOjAEQ8w+Sftu1lu6rJZr3ctSLg==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</configlet>
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Change Log">
<section title="00 to 01">
<t>
<list>
<t>Complete re-write. Switched from using signed DNS
records using DNSSEC to using signed YANG-defined
XML files using XML Signature. This update took
into a lot a feedback from both operators and
vendors.</t>
</list>
</t>
</section>
</section>
<section title="Open Issues" anchor="OPENISSUES">
<section title="How to best structure the Configlet YANG module?">
<t>The current YANG module must redefine parts of the
"ietf-system" and "ietf-netconf-server" modules. Also,
when referencing parts that it can, the YANG module
unnecessarily includes parts it doesn't need, such as
configuring the device to listen for inbound connections.
Ideally "deviation" statements could be used to delete
the unwanted sub-trees.</t>
</section>
<section title="Should Configlets always be signed?">
<t>This drafts states that Configlets don't have to be signed
when loaded through a mechanism that asserts physical presence.
However, some have voiced concern, saying that no possible
backdoor should be allowed.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:58:13 |