One document matched: draft-ietf-netconf-zerotouch-01.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6187 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6187.xml">
<!ENTITY rfc7317 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-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 day="27" month="October" year="2014"/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>zerotouch</keyword>
<abstract>
<t>This draft presents a technique for establishing a
secure NETCONF connection between a newly deployed
IP-based device, configured with just its factory
default settings, and the new owner's Network Management
System (NMS).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="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="Objectives">
<t>A fundamental business requirement is to reduce
operational costs where possible. Deploying new
IP-based devices is many times one of the largest
costs in running a network, as sending trained
specialists to each site to do an installation is
both cost prohibitive and does not 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 solely
on DHCP for NMS discovery, but this can only work in
environments where the DHCP server is locally administered,
which is not 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, ZeroTouch, enables
a device to securely obtain an initial configuration
from the network without any operator intervention.
The discovered configuration initiates the device to
"call home" using either SSH or TLS, as described in
<xref target="NETCONF-CALL-HOME"/>.</t>
<t><vspace blankLines="3"/></t>
</section>
<section title="Use Cases" anchor="use-cases">
<t>
<list style="symbols">
<t>Connecting to a remotely administered network
<list style="empty">
<t>This use-case involves scenarios, such as a remote
branch office or convenience store, whereby the device
connects to an ISP's network. In this case, the device
receives only generic networking settings (address, netmask,
gateway, DNS servers, etc.) provided by the ISP,
with no site-specific customizations, such that the
device has no recourse but to reach out to the
presumably insecure network for its initial
configuration.</t>
</list>
</t>
<t>Connecting to a locally administered network
<list style="empty">
<t>This use-case covers all other scenarios and
differs only in that the device may additionally
receive some site-specific information to guide
its call home process, which could then direct
it to a local server for its initial configuration.
If no site-specific information is provided, or the
device is unable to use the information provided,
it can then reach out to network just as it would
for a remotely administered network.</t>
</list>
</t>
</list>
</t>
<t><vspace blankLines="30"/></t>
</section>
<section title="Actors and Roles">
<t>
<figure>
<artwork><![CDATA[
fetches Configlet and
+----------+ boot-image, if needed
+------------| Device |---------------------+
| +----------+ |
| ^ |
| | V
| call home | manufactures +----------+
| | with necessary | Config |
| | default state | Server |<----+
| | for ZeroTouch +----------+ |
| | |
| | |
| +----------+ delegates trust |
| | Vendor |-------------------+ |
| +----------+ | |
| ^ ^ | |
| | | V |
| | | +----------+ |
| imports | | validate owner | Config | |
| trust | +-----------------| Signer | |
| anchor | +----------+ |
| | ^ |
| | | |
| +---------+ requests signing | |
+----------->| NMS |--------------------+ |
+---------+ |
| |
+----------------------------------------+
signed Configlet and boot-image file
]]></artwork>
<postamble>Though not represented as a box in the diagram,
the Configlet is also a first-class object in the solution.</postamble>
</figure>
</t>
<t>
<list style="symbols">
<t>Configlet
<list style="empty">
<t>A Configlet is an XML document that, when
loaded onto a device, configures the device
to initiate a call home connection to a deployment
specific NMS, as well as set a local administrator
account for the NMS to log into. The Configlet
is signed and optionally encrypted. More information
about Configlets is in <xref target="configlet"/>.</t>
</list>
</t>
<t>Configuration Server
<list style="empty">
<t>A Configuration Server hosts Configlets and
boot-images to be downloaded over a network via
HTTP/S. Configuration Servers can be deployed
either on the locally
administered network or on some external network
(e.g., the Internet). Configuration Servers are
known to devices in the form of a URI, which can
be either preconfigured or dynamically discovered.
More information about Configuration Servers is
in <xref target="config-server"/>.</t>
</list>
</t>
<t>Configuration Signer
<list style="empty">
<t>A Configuration Signer is an entity that the
device's vendor has delegated the Configlet-signing
function to. A Configuration Signer only needs to
ensure that the requestor is the rightful owner of
the device to which a configuration is destined. A
Configuration Signer may be site-specific or an
external entity. More information about
Configuration Signers is in
<xref target="config-signer"/>.</t>
</list>
</t>
<t>Device
<list style="empty">
<t>The device is the networking entity that initiates
ZeroTouch, whenever booting with its factory default
settings. The device is preconfigured with a secure
device identity, Configuration Servers URIs, and
certificates for both Configuration Signers and
Configuration Servers it trusts by default. A
device may dynamically discover additional URIs and
certificates from a locally-administered network.
More information about Devices
is in <xref target="device"/>.</t>
</list>
</t>
<t>Network Management System
<list style="empty">
<t>The NMS is the deployment-specific system that
devices initiate their call home connections to.
The NMS must be configured with vendor-specific
trust anchors and unique device identifiers.
The administrators of the NMS system interact with
Configuration Signer and Configuration Server
systems to stage the the device configurations.
More information about Network Management Systems
is in <xref target="nms"/>.</t>
</list>
</t>
<t>Vendor
<list style="empty">
<t>Vendors manufacture the devices with secure
device identities and preconfigured Configuration
URIs, and Configuration Signer certificates.
Vendors are the de facto Configuration Signer
for the devices it manufactures, but may
delegate that role to external Configuration
Signers. More information about Vendors is in
<xref target="vendor"/>.</t>
</list>
</t>
</list>
</t>
<t><vspace blankLines="3"/></t>
</section>
</section>
<section title="Configuration Server" anchor="config-server">
<t>A Configuration Server is the entity hosting configurations
that can be downloaded over a network. This section describes
the service interface a Configuration Server MUST implement
as well as what's needed for transport security.</t>
<section title="Service Interface" anchor="service-interface">
<t>Configuration Servers are known to devices in the form
of a URI. Configuration Servers MUST support the URI schemes
"https" and "http". Other URI schemes are not supported.</t>
<t>When accessing a Configuration Server, the device
appends its unique device identifier (UID) to the URI. The
unique identifier MUST be the same as the identifier stored
within the device's IDevID certificate, which is described
in <xref target="device-precondition"/>.</t>
<t>
For instance, if the URI were:
<figure>
<artwork><![CDATA[
http://example.com/zerotouch/devices/
https://example.com/zerotouch?id=
]]></artwork>
</figure>
then the device would try to access:
<figure>
<artwork><![CDATA[
http://example.com/zerotouch/devices/<uid>
https://example.com/zerotouch?id=<uid>
]]></artwork>
</figure>
</t>
<t>When accessing the Configuration Server, the HTTP
Accept-Type MUST be set to either "application/zerotouch-configlet"
or "application/zerotouch-bootimage". Please see
<xref target="zerotouch-media-types"/>. A wildcard Accept-Type
(e.g., */*) SHOULD default to "application/zerotouch-configlet".</t>
</section>
<section title="Interactive Interface">
<t>The Configuration server SHOULD provide a
user-facing interface to enable the end-user to
provide a Configlet and, optionally, a bootimage file.
How the Configlet and bootimage file are provided to the
Configuration Server is outside the scope of this
document.</t>
<t><vspace blankLines="3"/></t>
</section>
<section title="Transport Security">
<t>As described in <xref target="config-signer"/>, configurations
MUST be signed and MAY be encrypted. As such, transport-level
security is not needed to assure authenticity or confidentiality
of the configuration itself. However, transport-level security
enables devices to authenticate the Configuration Server and
also extends confidentiality to the application-level protocol.
Therefore, it is RECOMMENDED that only secure URL schemes are
used (see <xref target="service-interface"/>).</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 (see
<xref target="device-precondition"/>. More specifically, the
Configuration Server MUST possess all the intermediate
certificates leading to the trust anchor.</t>
<t>When a Configuration Server negotiates encryption with the
device, it provides the chain of certificates, from its server
specific certificate to, but not including, its trust anchor.
Including the trust anchor's certificate is unnecessary since
the device MUST be pre-provisioned with it. Devices need the
chain of certificates to be passed so they can validate the server
using only a simple list of Configuration Server trust anchors.</t>
</section>
<section title="Expiration Policy">
<t>An expiration policy is needed to limit how long a
Configuration Server needs to retain a configuration and,
in turn, how many configurations it might need to retain
at a given time.</t>
<t>It is expected that Configuration Servers will enable
retention information to be given at the same time as
when the configuration is provided to it. Options should
be temporal in nature, not based on access counts, so as
to thwart a DoS attack whereby the configuration is accessed
by an entity other than the device. Configuration Servers
SHOULD put a limit on the maximum amount of time it will
hold onto a configuration before purging it, even if the
configuration had never been accessed.</t>
</section>
<section title="Troubleshooting and Auditing">
<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>
<t><vspace blankLines="3"/></t>
</section>
</section>
<section title="Configuration Signer" anchor="config-signer">
<section title="Overview" anchor="signer-overview">
<t>A Configuration Signer MUST be able to sign configurations.
This function requires the Configuration Signer be able to
authenticate that the requestor is the true owner of the
device, as identified within the contents of the configuration
being signed.</t>
<t>The user interface a Configuration Signer provides to perform
its role is outside the scope of this document. However, in
order to meet operational expectations, the time it takes to
respond to a request should be as expeditious as possible.</t>
<t>A Configuration Signer does not need to retain a configuration
after signing it. The Configuration Signer SHOULD retain an
audit log for indemnification purposes.</t>
</section>
<section title="Signing Configurations">
<t>A Configuration 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 Configuration Signer MUST
possess all intermediate certificates leading to its
trust anchor.</t>
<t>When a Configuration 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 Configuration Signer trust anchors known to it.</t>
</section>
<section title="Optional Encryption">
<t>A Configuration Signer MAY optionally encrypt configurations
prior to signing them. This function requires the Configuration
Signer know the device's unique public key, as encoded within
its secure device identity certificate.</t>
<!-- KENT: what KeyUsage bits need to be set?
- are they in IDEVID? -->
</section>
<section title="Delegation of Trust" anchor="delegate-trust">
<t>A device's vendor is the root of trust for all of its
devices. That is, the vendor's devices implicitly trust
the vendor for such things as software images, subscription
updates, and licenses. As such, the vendor is the ultimate
Configuration Signer for its devices.</t>
<t>However, both vendors and its customers may prefer that
this role be performed by another entity. For instance,
a vendor may not want this role due to it being outside
its primary business function, and customers may not want
the vendor to have this role for privacy reasons.</t>
<t>It is therefore provided that a vendor MAY delegate
the Configuration Signer role to other entities. Using
X.509 certificates, the Vendor need only sign the
delegate's certificate signing request (CSR), providing
back to the delegate a signed X.509 certificate
authenticating its ability to perform the signing
function.</t>
<t>In order enable a delegate to fulfill its operational
role, as described in <xref target="signer-overview"/>,
the vendor MUST provide a mechanism that can be used to
authenticate if a given requestor is the true owner of a
specific device. Additionally, to support Configuration
Signers that want to encrypt configurations, the vendor
MUST also provide a means for the Configuration Signer
to know the public key for a given device. How the vendor
provides this information to Configuration Signers is
outside the scope of this document.</t>
</section>
<section title="Delegation to a Specific Customer">
<t>The general expectation is that the Configuration
Signer is an impartial 3rd-party. However, certain
deployments may want to be able to perform the function for
themselves. Yet without constraints, that deployment
could sign configurations for devices that do not
belong to it.</t>
<t>Resolving this concern is possible when 1) the
deployment specific Configuration Signer's certificate
is annotated with a customer identifier and 2) the
devices sold to that customer have that same identifier
encoded into their secure device identifier.</t>
<t>This entails the vendor augmenting its manufacturing
process for these special devices, which would likely
be sold directly to the customer, as opposed to through
a sales channel. This takes extraordinary effort and
likely only implemented for the most important customers,
if at all.</t>
</section>
</section>
<section title="Device" anchor="device">
<section title="Overview">
<t>While the wholistic solution, ZeroTouch, involves a
number of entities, a device being powered-on is the
essential event that sets things in motion.</t>
<t>Whenever a device boots with its factory
default settings, it initiates ZeroTouch with the goal
of finding a configuration to initialize itself with.
Once a configuration is found, the device initializes
its running datastore with it and then enters normal
operation. Since the configuration initializes the
device to call home upon entering its normal operating
mode, the device immediately begins trying to establish
a secure connection with the deployment specific NMS.</t>
</section>
<section title="Factory Default State" anchor="device-precondition">
<t>
<figure>
<artwork><![CDATA[
+------------------------------------------------------------------+
| <device> |
| |
| +------------------------------------------------------+ |
| | <immutable storage> | |
| | | |
| | list of Configuration Signer trust anchor certs | |
| | list of Configuration Server trust anchor certs | |
| +------------------------------------------------------+ |
| |
| +----------------------------------------------------------+ |
| | <other storage> | |
| | | |
| | two sets of Configuration Server URIs | |
| | IDevID entity & associated intermediate certificate(s) | |
| +----------------------------------------------------------+ |
| |
| +----------------------+ |
| | <secure storage> | |
| | | |
| | IDevID private key | |
| +----------------------+ |
| |
+------------------------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>Devices supporting ZeroTouch MUST have a
manufacturer-provisioned secure device identifier, as
defined in <xref target="Std-802.1AR-2009"/>. This identifier
is known by the IEEE standard as the Initial Device
Identifier (IDevID). The IDevID includes both an X.509
certificate, encoding a globally unique per-device
identifier, and a chain of X.509 certificates leading to the
manufacturer's well-known trust anchor. The IDevID is needed
in order for the NMS to positively authenticate a device.
The IDevID certificate MUST be used by the NETCONF server
as its SSH host-key (see <xref target="RFC6187"/>) or its TLS
server certificate, depending on which protocol is used.</t>
<t>Devices supporting ZeroTouch MUST be pre-provisioned with
one or more URIs for Internet-based Configuration Servers.
These URIs SHOULD be partitioned into one set that contains
secure schemes (e.g. https://) and another set that
contains insecure schemes (e.g., http://). The
reason for partitioning the URIs is so all the secure schemes
can attempted before any of the insecure schemes (see
<xref target="dev-boot-seq"/>). When using a secure scheme,
the Configuration Server MUST be authenticated using a
trust anchor the device possesses. As each Configuration
Server may use a different trust anchor, this generalizes
to a list of Configuration Server trust anchor certificates.</t>
<t>In order to verify the signature on retrieved
configurations, devices supporting ZeroTouch MUST also
possess the trust anchor for the Configuration Signer
that signed the configuration. Generally, only the
manufacturer's trust anchor is needed, as it can then
delegate trust for 3rd-party Configuration Signers
(see <xref target="delegate-trust"/>). However, for
various reasons, there may be a need for more than one
root anchor and therefore this generalizes to a list
of Configuration Signer trust anchor certificates.</t>
<t>Devices SHOULD ensure that the certificates for its
trust anchors are protected from external modification.
It is for this reason that the diagram shows the
Configuration Signer and Configuration Server certificates
in immutable storage. Similarly, per <xref target="Std-802.1AR-2009"/>,
the IDevID private key shall be stored confidentially and
not available outside the IDevID module, hence the diagram
shows it is held within secure storage.</t>
</section>
<section title="Boot Sequence" anchor="dev-boot-seq">
<t>
<figure>
<artwork><![CDATA[
DEVICE DHCP CONFIGURATION NMS
| SERVER/RELAY SERVERS |
| | | |
+-->| | | |
| | | | |
| |--[if running config != factory default, boot normally]--+ |
| | | | | |
<---------------------------------------------------------------+ |
| | | | |
| | | | |
| | | | |
| |--(discovery)-->| [if no dhcp server found, boot normally] |
| | | | |
| | +---(offer)---| | |
| | | | | |
| | +--[add any listed config servers to built-in list]--+ |
| | | | | |
| |<------------------------------------------------------+ |
| | | | |
| | | | |
| | | | |
| | (iterate until match, else boot normally) | |
| |------------------------------------------------>| |
| | | | |
| |<------------------------------(zerotouch info)--| |
| | | | |
| | | | |
| | | | |
| |--[if current image != expected, get image]----->| |
| | | | |
| | +-------------------------------------(image)--| |
| | | | | |
| | +--[if image valid, install & reboot]--+ | |
| | | | | |
+---------------------------------------------+ | |
| | | |
| | | |
| | | |
|--[get config]---------------------------------->| |
| | | |
| +------------------------------------(config)--| |
| | | | |
| +--[if config valid, merge into running]--+ | |
| | | | |
| +--------------------------------------+ | |
| | | | |
| +--[per new configuration, call home]----------------->|
| | | |
| | | |
]]></artwork>
</figure>
</t>
<t>Whenever a device boots with its factory default
settings, it initiates ZeroTouch with the goal of
finding a configuration that will enable it to call home
to its deployment-specific NMS.</t>
<t>The process begins with the device using the DHCP
protocol to obtain a dynamic assignment for its networking
stack. When broadcasting the DISCOVERY request, the device
may provide any DHCP options to identify itself or the type
of device it is (e.g. IPV4 options 60 or 61).</t>
<t>If the DHCP servers reside on a locally administered network
(see <xref target="use-cases"/>), then their OFFER responses
MAY include the ZeroTouch Information DHCP option defined in
<xref target="zerotouch-info-option"/>, as well as the legacy
DHCP options for TFTP server name, bootfile name, and/or
vendor specific information (e.g. IPv4 options 43, 66, 67).</t>
<t>If a DHCP server provides both the ZeroTouch Information
and the vendor specific information DHCP options, then the
ZeroTouch Information option MUST be processed first. After
exhausting all ZeroTouch options without being able to call
home, a device MAY then process the information provided by
the legacy DHCP options.</t>
<t>The ZeroTouch Information option <xref target="zerotouch-info-option"/>
provides a set of Configuration Server URIs. If returned by
the DHCP server, the device MUST append each URI to the end
of one of its 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 next.</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>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 match is found and successfully loaded,
the device attempts to initialize itself 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 usable match,
it SHOULD 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 its UID to the URI string and using the
Accept-Type "application/zerotouch-configlet", as described in
<xref target="config-server"/>. For URIs discovered
via the ZeroTouch Information option, the device
MAY also try the raw URI after trying the permutation
using its UID.</t>
<t>If the Configuration Server returns a configuration,
the device MUST first verify it before use. Configuration
verification entails both verifying the configuration's
signature using the device's list of Configuration Signer
trust anchors, and also verifying that the unique identifier
within the Configlet matches the device's unique identifier.</t>
<t>Once the configuration is authenticated, the device MUST
compare its software image version with the expected
version specified within the configuration. If there is a
mismatch, the device MUST download the correct image
version from the Configuration Server, by appending
its UID to the Configuration Server's URI string
and using the Accept-Type "application/zerotouch-bootimage", as described in
<xref target="config-server"/>. For URIs discovered
via the ZeroTouch Information option, the device
MAY also try the raw URI after first trying the permutation
using its UID. Once the image has been downloaded, the
device MUST install it and reboot, still with the
factory default settings configured, so that ZeroTouch
restarts when the device comes back up.</t>
<t>If the device is running the correct software image
version, it merges the Configlet's contents into its running
configuration. This step effectively modifies the device
so that it is no longer having its factory default setting.
Thus, at this point, a reboot is no longer expected to
start the ZeroTouch process.</t>
<t>Though not technically required, the Configlet is presumed
to have configured the device to "call home". As soon as
this configuration is merged into the running configuration,
the device SHOULD immediately begin trying to establish the
call home connection, as specified by the Configlet.</t>
<t>If configured to establish a SSH connection,
the the device MUST use its IDevID and associated
intermediate X.509 certificates as its host key per
RFC 6187 <xref target="RFC6187"/>. If configured to
establish a TLS connection, the device MUST use its
IDevID 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>
</section>
</section>
<section title="Network Management System (NMS)" anchor="nms">
<section title="Overview">
<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 initiate a call home
connection to the NMS, using either SSH or TLS, as
configured by the Configlet loaded.</t>
<t><vspace blankLines="30"/></t>
</section>
<section title="Precondition">
<t>
<figure>
<artwork><![CDATA[
+------------------------------------------------------------------+
| <nsm> |
| |
| +------------------------------------------------------+ |
| | <immutable storage> | |
| | | |
| | list of IDevID trust anchor certificates | |
| | list of expected device unique identifiers | |
| +------------------------------------------------------+ |
| |
| +--------------------------------------------------+ |
| | <secure storage> | |
| | | |
| | map of device identifiers to login credentials | |
| +--------------------------------------------------+ |
| |
+------------------------------------------------------------------+
]]></artwork>
</figure>
</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.
Because an NMS may interoperate with multiple vendors, and
a vendor may have more than one trust anchor for signing
its devices IDevID certificates, this generalizes into
the NMS needing a list of trust anchor certificates.
This certificates SHOULD be stored in a way that prevents
tampering, which is why they are shown in immutable
storage in the diagram.</t>
<t>In order for the NMS to validate that the specific
device connecting to it is expected, it MUST have
a list of unique device identifiers that it can use
to validate the device's IDevID certificate with.
The list SHOULD be protected from external modification,
which is why it is shown in immutable storage in the
diagram. In order for the NMS to know the unique
identifiers, device manufacturers will need to provide
a mechanism to convey this information to its customers.
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 deployment specific, but generalizes to the NMS needing
to have login credentials for each device. These credentials
will entail knowing a secret (e.g., password, private key).
For this reason the diagram shows the NMS storing a map of
device credentials in secure storage.</t>
</section>
<section title="Connection Handling">
<t>When receiving a NETCONF call home connection from a
device, the NSM completes the connection as specified
NETCONF Call Home <xref target="NETCONF-CALL-HOME"/>.</t>
</section>
</section>
<section title="Vendor" anchor="vendor">
<section title="Order Information" anchor="order-information">
<t>In order for a Vendor's customers to configure their
NMSs with what devices are expected, as well as to know how to
set the "unique-identifier" field within a Configlet
when requesting a signing, Vendors need to provide a
mechanism for customers to obtain the unique
identifier value for the devices they have
ordered. For instance, customers could receive emails
containing shipping information for their devices.</t>
<t>Additionally, to facilitate workflows where the
devices are initially received by a customer-specific
warehouse, or moved after having been unboxed, it is
ideal for the unique identifier to be 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,
so long as it is directly related to its IDevID identity.</t>
</section>
<section title="Ownership Validation">
<t>In order for Configuration Signers to validate that a
requestor is the true owner of a device (i.e. its IDevID
identity), Vendors need to provide a mechanism enabling
a near real-time lookup. The interface used to implement
this lookup is outside the scope of this document.</t>
</section>
</section>
<section title="Configlet" anchor="configlet">
<section title="Overview" anchor="configlet-overview">
<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 XSD schema in
<xref target="configlet-xsd-schema"/>, contains information for
the device to ensure that it's safe for it to load the configlet
(i.e. target-requirements) along with a payload, the configuration
the device is to merge into its running datastore.</t>
<t>In order for the device to call home, the configuration
contained within the Configlet MUST at least configure a local user
account and configure the connection information for the NMS the
device is to call home to. This configuration MAY use IETF-defined
modules "ietf-system" <xref target="RFC7317"/> and
"ietf-netconf-server" <xref target="NETCONF-SERVER-MODEL"/>.</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 Configuration 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="Data Model" anchor="configlet-data-model">
<t>
<figure>
<artwork><![CDATA[
module: ietf-netconf-zerotouch
+--rw configlet
+--rw target-requirements
| +--rw unique-identifier string
| +--rw software-version string
+--rw configuration
]]></artwork>
</figure>
</t>
<t>The Configlet's data model is no more than a wrapper
around a header (i.e. <target-requirements>) and a
payload (i.e. <configuration>).</t>
<t>The <target-requirements> element contains
information that MUST be validated by the device
prior to processing the <configuration> element.
Specifically, it contains:
<list style="symbols">
<t>unique-identifier
<list style="empty">
<t>The unique-identifier field is used to ensure that
the Configlet is loaded onto the targeted device
and no other. This field is also used by the
Configuration Signer, when ensuring the requestor
is the true owner of the device. The value MUST
be the same as the 'subject' field in the device's
IDevID credential, as specified by section 7.2.8 in
IEEE Std 802.1AR-2009.</t>
</list>
</t>
<t>software-version
<list style="empty">
<t>The software-version field is used to ensure
the device is running the right software version
prior to loading the configuration (e.g., 14.1R2.5).
If the device finds that it is not running the
correct version of software, it MUST pull the
correct version from the Configuration Server.</t>
</list>
</t>
</list>
</t>
<t>The <configuration> element contains the configuration
that is to be committed to the device's running datastore. This
element uses the "anyxml" type, enabling it to contain either
vendor-specific or standards-based data models. When using
standard models, in order to complete a call home connection,
only the following is needed:
<list style="symbols">
<t>The "authentication" subtree from "ietf-system", defined in <xref target="RFC7317"/>.</t>
<t>The "call-home" subtree from "ietf-netconf-server", defined in <xref target="NETCONF-SERVER-MODEL"/>.</t>
</list>
</t>
</section>
<section title="Signature">
<t>All Configlets MUST be signed by a Configuration Signer
in order to be authentic. Devices MUST reject any Configlet
that is either unsigned or having an invalid signature.
Configlets are 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 Configuration Signer's
certificate and any intermediate certificates leading to
a Configuration Signer trust anchor. A signed Configlet
example is in section <xref target="signed-configlet"/>.</t>
</section>
<section title="Encryption (optional)">
<t>Configlets MAY optionally be encrypted prior to being
signed. Encrypting the Configlet provides confidentiality
for the Configlet's contents without relying on transport-level
security. Configlets are encrypted using the W3C standard
"XML Encryption Syntax and Processing" <xref target="XMLENC"/>.
The entire contents of the Configlet MUST be encrypted.
An encrypted Configlet example is in section
<xref target="signed-encrypted-configlet"/>.</t>
</section>
<section title="XSD Schema" anchor="configlet-xsd-schema">
<t>
<figure>
<preamble>Following is the XSD for the Configlet:</preamble>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch"
targetNamespace="urn:ietf:params:xml:ns:ietf-netconf-zerotouch"
elementFormDefault="qualified">
<xs:element name="configlet">
<xs:complexType>
<xs:sequence>
<xs:element name="target-requirements">
<xs:complexType>
<xs:sequence>
<xs:element name="unique-identifier" type="xs:string">
<xs:annotation>
<xs:documentation>
Specifies the unique identifier of the device that
is to process this Configlet. The value MUST be
the same as the 'subject' field in the device's
DevID credential, as specified by section 7.2.8
in IEEE Std 802.1AR-2009.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="software-version" type="xs:string">
<xs:annotation>
<xs:documentation>
In order to process this Configlet, the device
MUST must be running this version of software.
The value is device-specific, but it MUST be
an exact match (e.g., 14.1R2.5)
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="configuration">
<xs:annotation>
<xs:documentation>
The configuration to be committed to the device's
running datastore. The configuration MUST be valid
for the target device.
Devices supporting ZeroTouch SHOULD support the
following standard data-models:
ietf-system // RFC 7317
ietf-netconf-server // RFC YYYY
These two data models contain everything needed to
support NETCONF call home using either SSH or TLS.
References:
RFC 7317: A YANG Data Model for System Management
RFC YYYY: NETCONF Server Configuration Model
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:any processContents="skip"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations" anchor="sec-con">
<section title="Immutable storage for trust anchors">
<t>Devices SHOULD ensure that all its trust anchor
certificates, including those for the Configuration
Signer and Configuration Server, are protected from
external modification. It is for this reason that
the diagram in <xref target="device-precondition"/>
shows them in immutable storage.</t>
<t>However, it may be necessary to update these
certificates over time (e.g., the vendor wants to
delegate trust to a new CA). It is therefore expected
that devices MAY update these trust anchors when
needed through a verifiable process, such as a
software upgrade using signed software images.</t>
</section>
<section title="Substitutions">
<t>It is generally 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>However, 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 Configuration 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 Configuration
Signers to not sign a Configlet when another Configlet
is still active.</t>
</section>
<section title="Confidentiality">
<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, since
it MUST be signed, only confidentiality is lost.</t>
<t>Confidentiality of a Configlet's contents is assured
when either the Configlet is encrypted or when the a
secure scheme is used when accessing the Configuration Server.</t>
<t>Some confidentiality is lost when an insecure scheme is
used to access a Configuration Server, as then the device's
unique identifier is in the clear.</t>
<t>Given the fairly regular format for unique identifiers,
it is possible that an adversary to guess unique identifiers
and access a device's Configlet. Configlets that have been
encrypted do not disclose any confidential information.</t>
</section>
<section title="Entropy loss over time">
<t>Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says
that IDevID certificate should never expire (i.e. having a
notAfter 99991231235959Z). Given the long-lived
nature of these certificates, it is paramount to use a
strong key length (e.g., 512-bit ECC). Vendors SHOULD
deploy Online Certificate State Protocol (OCSP) responders
or CRL Distribution Points (CDP) to revoke certificates in
case necessary.</t>
</section>
<section title="Serial Numbers">
<t>This draft mentions using the device's serial number as
its unique identifier in its IDevID 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>
</section>
</section>
<section title="IANA Considerations">
<section title="ZeroTouch Information DHCP Option" anchor="zerotouch-info-option">
<t>The following registration is in accordance to RFC 2939 for
"BOOTP Vendor Extensions and DHCP Options" registry maintained at
http://www.iana.org/assignments/bootp-dhcp-parameters.</t>
<section title="DHCP v4 Option">
<figure>
<artwork>
Tag: XXX
Name: Zero Touch Information
Description: Returns a list of null-terminated Configuration
Server URIs
Code Len
+-----+-----+------+------+----
| XXX | n | url1 | url2 | ...
+-----+-----+------+------+----
Reference: RFC XXXX
</artwork>
</figure>
</section>
<section title="DHCP v6 Option">
<figure>
<artwork>
Tag: YYY
Name: Zero Touch Information
Description: Returns a list of null-terminated Configuration
Server URIs
Code Len
+-----+-----+------+------+----
| YYY | n | url1 | url2 | ...
+-----+-----+------+------+----
Reference: RFC XXXX
</artwork>
</figure>
</section>
</section>
<section title="Media Types for Boot Images and Configurations" anchor="zerotouch-media-types">
<t>The following registrations are in accordance to RFC 6838.</t>
<section title="application/zerotouch-configlet">
<figure>
<artwork>
Type name: application
Subtype name: zerotouch-configlet
Required parameters: None
Optional parameters: None
Encoding considerations: 8-bit
Security considerations: See Security Considerations in RFC XXXX
Interoperability considerations: None
Published specification: RFC XXXX
Applications that use this media type:
Configuration servers and NETCONF servers.
Fragment identifier considerations: None
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): None
File extension(s): xml
Macintosh file type code(s): 'TEXT'
Person & email address to contact for further information:
Kent Watsen <kwatsen@juniper.net>
Intended usage: COMMON
Restrictions on usage: None
Author:
This specification is a work item of the IETF NETCONF working
group, with mailing list address <netconf@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
Provisional registration? (standards tree only): No
</artwork>
</figure>
</section>
<section title="application/zerotouch-bootimage">
<figure>
<artwork>
Type name: application
Subtype name: zerotouch-bootimage
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: See Security Considerations in RFC XXXX
Interoperability considerations: None
Published specification: RFC XXXX
Applications that use this media type:
Configuration servers and NETCONF servers.
Fragment identifier considerations: None
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): None
File extension(s): None
Macintosh file type code(s): N/A
Person & email address to contact for further information:
Kent Watsen <kwatsen@juniper.net>
Intended usage: COMMON
Restrictions on usage: None
Author:
This specification is a work item of the IETF NETCONF working
group, with mailing list address <netconf@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
Provisional registration? (standards tree only): No
</artwork>
</figure>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank for following for
lively discussions on list and in the halls (ordered
by last name):
David Harrington,
Dean Bogdanovic,
Martin Bjorklund,
Wes Hardaker,
Russ Mundy,
Reinaldo Penno,
Randy Presuhn,
Juergen Schoenwaelder.</t>
<t>Special thanks goes to Russ Mundy and Wes Hardaker
for brainstorming the original I-D's solution during
the IETF 87 meeting in Berlin.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6187;
<!-- &rfc7317; - why isn't this working! below is the same as fetched by the URL! -->
<reference anchor="RFC7317">
<front>
<title>A YANG Data Model for System Management</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<date year="2014" month="August"/>
<abstract>
<t>
This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7317"/>
<format type="TXT" octets="60119" target="http://www.rfc-editor.org/rfc/rfc7317.txt"/>
</reference>
<reference anchor="Std-802.1AR-2009" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Secure Device Identity</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="December" year="2009"/>
</front>
</reference>
<reference anchor="XMLSIG" target="http://www.w3.org/TR/xmldsig-core1">
<front>
<title>XML Signature Syntax and Processing</title>
<author fullname="World Wide Web Consortium"></author>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="XMLENC" target="http://www.w3.org/TR/xmlenc-core1">
<front>
<title>XML Encryption Syntax and Processing</title>
<author fullname="World Wide Web Consortium"></author>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="NETCONF-CALL-HOME" target="https://tools.ietf.org/html/draft-ietf-netconf-call-home-01">
<front>
<title>NETCONF Call Home (work in progress)</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<date month="October" year="2014"/>
</front>
</reference>
<reference anchor="NETCONF-SERVER-MODEL" target="http://tools.ietf.org/html/draft-ietf-netconf-server-model-03">
<front>
<title>NETCONF Server Model (work in progress)</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<date month="September" year="2014"/>
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="TR069" target="http://www.broadband-forum.org/technical/download/TR-069_Amendment-3.pdf">
<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>
</reference>
</references>
<section title="Examples" anchor="examples">
<section title="Unsigned Configlet" anchor="unsigned-configlet">
<t>
<figure>
<preamble>
This example illustrates a Configlet
configuring both a local user account and
call home using SSH.
Note, this is not a valid Configlet because it isn't signed.
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
<target-requirements>
<unique-identifier>0123456789</unique-identifier>
<software-version>14.1R3.5</software-version>
</target-requirements>
<configuration>
<!-- from ietf-system.yang -->
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-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 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<call-home>
<application>
<name>config-mgr</name>
<ssh>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>11.22.33.44</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>55.66.77.88</address>
</endpoint>
</endpoints>
<host-keys>
<host-key>my-call-home-x509-key</host-key>
</host-keys>
</ssh>
</application>
</call-home>
</netconf-server>
</configuration>
</configlet>
]]></artwork>
</figure>
</t>
</section>
<section title="Signed Configlet" anchor="signed-configlet">
<t>
<figure>
<preamble>
This example illustrates the above unsigned Configlet
signed as if by a Configuration Signer. Note
that in addition to the signature itself, the
signed Configlet embeds two certificates, the
chain of certificates from the signer's certificate
up to but not including the trust anchor certificate.
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
<target-requirements>
<unique-identifier>0123456789</unique-identifier>
<software-version>14.1R3.5</software-version>
</target-requirements>
<configuration>
<!-- from ietf-system.yang -->
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-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 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<call-home>
<application>
<name>config-mgr</name>
<ssh>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>11.22.33.44</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>55.66.77.88</address>
</endpoint>
</endpoints>
<host-keys>
<host-key>my-call-home-x509-key</host-key>
</host-keys>
</ssh>
</application>
</call-home>
</netconf-server>
</configuration>
<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>t9OdNsxPsjyzrKu7kO0ydcFK6xU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
AS/dlRNk/DDy2baDfQXspstvQzOxZo/goZ+Z9iiW5dbOZ+wiZwxMlJuMYlxuNrfL
o38JzJ+KnY1XexfRkFmSaaShyMJ0N9kianxaYWJgvF7+/lx5U6isFxpfIwvo9YkQ
27w/i9xb5e/tl+PzVr+FMKyUuyitdy5yjVGpa3y8Gqlk7YSo4df4LWzmR4hAYWTN
P7cuV516tHakKpyTi9FweBrqEUNT7W7BNb6Js0Q1twrEIR4lFwpQn/iWUM5KqxAu
QzP7YG/d58oWzdILeCXZ2CX3RHhhtm/Brwa9UFN9TFS3D9WLIx1pO+L0HNt5gIiu
eOMq1vN6sazkMtm6Z1NMqg==
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f
VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTE0MDIyNzE0MTM1
M1oXDTE1MDIyNzE0MTM1M1owKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE
AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
x0WiRICc5g+w0ILzTueLxlV+TIZhqeOe1hLHcBpJQd/OmX31rl8l+rgL1juu5BDF
wkwl4EA4dZhjfuiiVChNkD4lks+464PreyjuWh+V+vgytdM84TRrXB1I+yTLrXuH
/gZSKje67/5kWICAYAdRCkD8FnSdfXFtHE7blG6gYmAOHt1/g3N/UsjxOGPiUBFW
PUvH4WYWVCgSup16ehb2SOBJGjE3FBjAOQLMlL4FiFSDB4nzNnsaRxZsHgftW87d
x2d6lprLNIlmGDFRgELM/ItGsZFOpKyv3ftqdyC3rYaOz40I5i4NzP04vwfjcWxX
glRvCjwY+T9MjOwGYpirAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV
HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6
Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF
BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50
MIHXBgNVHSMEgc8wgcyAFHppoyXFyh/JaftWYf7m3KBzOdg2oYGwpIGtMIGqMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2
YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp
Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG
SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0
cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw
EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG
A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p
emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG
SIb3DQEBCwUAA4IBAQCCKQLSng8OkgniJ4EpLnzUUGmFc8BDerVuaWv+kj1Zkk0h
8leTPuNepWMiqAzdTjYVZYw4pzzSF/wYAKCVi1ng9ULlZS6wZAOL9exCF4bllvjz
rBwDUX6gxKTq0o6jKf3qEUZLCJzwaX1LD4MW8yrWf6KR56gfUerQY2M6xmklA70d
rY4u5+2F2sE6Vuh8N2aAo7HSaFMEVd5b399kC7nLMA8UJQ6S8OO+uPe9gYkqNgUJ
HwsblCuekEeL1Gs/sZ25zGzD6Ofo097MsSYBGdPVbZbKUj9XUfIsUggY+1iAFyQI
AuSxmTIAOISUbuxupPQPAU4nHOzEZediAoiNIGd5
</X509Certificate>
<X509Certificate>
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii
ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4
KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v
MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B
AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB
2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K
z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo
Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir
96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ==
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</configlet>
]]></artwork>
</figure>
</t>
</section>
<section title="Encrypted Configlet" anchor="encrypted-configlet">
<t>
<figure>
<preamble>
This example illustrates the above unsigned Configlet
that has been encrypted using the device's public key.
Note, this is not a valid Configlet because it isn't signed.
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<CipherData>
<CipherValue>
+H4vvrsgkv/qy22JudCE0quMORGamQmnQCaEhLJ7zY1UgP+zS5MbBdrREpocgHPs
W/d9eyDOwdDsREvz2j7V0Vg6NkKuzPJTz2cJVvSoGskWAV0ZwoiwBJqabzxcYErO
yV0DQmyxFruwmR5oalFBxkQzoL7zALfa2pBCpvdGuaoSRKTInQ/24iPOc/u+FNAU
5l0CPKrTNMqPeRx8cGq44nVgcprNi0Fvbg72gAVl8aiYLNA9Vo62Tn5kvvmp/qK2
WieLmBrJHQrvG6n3fg1RSM3cpR0KfsH3uaMEIaVUyzH0aYriwrhpaUPqdWCkel/u
fTpKUZ3VtVzMtiFaDhgYOtbxeLXD8kj4TCG37G1Sro9iY46yxHkqPHiVUB9lvACG
a5275yu0Z+zNfuCOUlvJtkI1CuSwOde+EOE+fzwyG9uPlacrhY3Xd7cIF9oDKFOf
vKhYp/grnnpzR4MLU1tMz0HHyBm6xI2IU7sKDWztAF0JmYH//kPs3H4boFLXmzmp
xr1eu5npsYpkhNpdflDLetMQZnqydzsmLSX8nfpkWZdkkXkmkKmuk6j1vkRiyw2k
484K71J7096UfMP0t8VhH1ObM8gZLDKXboohnCQEzUAKLKXTm3OWw+QllfJj3cvr
6GSWuKH+80CIUA10WAPNFMKO8VYFcSE68DMr+oXLk8zkXymWJR4ukWuMYa1Y14w6
tx84NuueAYHQUcqzlN0dJaTmbPiFbBRmwRFI5dcLT6t8FK2LybmXvpziFv7StHvY
C1Pr2S0W8lLwLoneaMRZsTNTd8bLzN2MlSuFdO8U6NMRvESH0WmNhF7JhGCzAegc
cYwXNgs9Ae3CK+uihxqImY2evRpk1U915n+JMfaf/TRnpK0fIR3MNFbU0WZemMvj
UYstRVCpAebJHq8L7IMbGjJesyT7vhd6CJIJCQL/4ZeWVp1W8ZPX6iKCpEhG+BhE
2CIvkNu9F8ubpvpdOdvhSs2KABGGK3DF58wJR7CsS516UuqVz+Rl0WlvVjHL9yqc
OvS1AP+NyQGfSLsGQ49tjxPSyE9uRV+dFbY7oCQlzPPdLRQ5H3htS/2CA6gCz0Cu
Ez5uweFPIe8b1k7U0ai3IWTQzxe+LQlcL+MHSgXAKz6yKk3idfpK3JViDtqz8xa5
urIYQDzOGntdjDfTdwG1+o4w/ysFI8zaCVUehL+L0T1pS0FuGwJpoyopg+6dA7rf
GVhcy3OOroAfkAXvZfqZAKTuLCFrN5+vU09iGt7kp1GqeneiaAS75JgG8oAt4SAP
KEIUquo5vxGe8WOXVpV8eByXWSpym/6wfYjwGIgzkIKz44LiqEUvL+Twz5qm3VaF
QHsJVHid/GvcUnk1mfhGtDqHWSv6KhTL2tk1mJ4cJxDzy7ijy75FXoKsDlP7H387
HnEQ/oFR9Xi52NYjylBvq/yuwhY16oGNFqqbq6uv90rdvSv5AJs7a0DxluqH/yd3
BLan1HoRCD8/iuWB2bE74TzhbO30PxuQHWCQPa7zTxJ92/Yn402z1ODUjvhKta4d
M2RTNOgIQwqcTi5qyUqhw+tKuXfQloQ1tIFI2VFwpLz9cEEImxDw+WGdb2bKfz5B
lPJIEbswHr341JqLtejMKm8dvAqkzrmuhJb+tYx5BPHDp1EUjJmzydKs9Up9QcK+
i6pkmK/42jLws5jDAvBiJp6zyaeaSABrRdY06ON7wJ0RLlaAuqecMmW4ZX/rE4oo
MIARa6SQ5JhV8Y7Z7/XWlids/GHfn9cYDIXIIadhz63a2s18qk3Ql8NAJ+CgkyiE
02h4cCjlJ/e+tpyW83XdeqvGy9tdhRir/iZh6i7iRsAQTltq/yGiR7lWQqwzMtUD
G994qckZ5PAZiKWHrB7/aWXTCDoHW1J546A5TsMcYGkIJR2UPOhFYWyOL1zCg6fG
Ehv8pO+r3CfO4vldMY4Z6Uw7mCs9c/5nrgOz7wLPPILjRoUIJ7SzknJHzqPFjG+R
Wqou6kQY6fy96Kax/iPGarfVbPJPhTJWWnxLD8NZWm8b12LViKJK6dAAl5REn3rK
om+EQVfxo/uuiLP/YAwcLwq/apURH89dDtHMiA4fh4cEY0POqwTiLm3xD0+AIaj7
lU7zbEIsKpz6HK5ex5dWsUADecIGBOyuQf//OO4E8vMO73NrSNiKA0mDPizzXCwk
UhNK2DjEZalduWlv273wFSebHM1wIiisatQIxzhwsWFuTgQJRb7/JPZGsXEg6npp
ePRShAqzrUAVOc7/flAvlNRLmOrdssqTZvmh2nFvyMeTHFoJ3BXbahxC+cNlvaWf
v0ebL2Hk7m3cntAOjuIE0ejGkqbb/6APHgYqRGRVdTmPnYq/lwohnSHcrhGmYvkL
5gk2DiSiffIpB/IJuTBQZQ==
</CipherValue>
</CipherData>
</EncryptedData>
</configlet>
]]></artwork>
</figure>
</t>
</section>
<section title="Signed Encrypted Configlet" anchor="signed-encrypted-configlet">
<t>
<figure>
<preamble>
This example illstrates the above encrypted Configlet
that has been signed by a Configuration Signer's
private key.
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<CipherData>
<CipherValue>
+H4vvrsgkv/qy22JudCE0quMORGamQmnQCaEhLJ7zY1UgP+zS5MbBdrREpocgHPs
W/d9eyDOwdDsREvz2j7V0Vg6NkKuzPJTz2cJVvSoGskWAV0ZwoiwBJqabzxcYErO
yV0DQmyxFruwmR5oalFBxkQzoL7zALfa2pBCpvdGuaoSRKTInQ/24iPOc/u+FNAU
5l0CPKrTNMqPeRx8cGq44nVgcprNi0Fvbg72gAVl8aiYLNA9Vo62Tn5kvvmp/qK2
WieLmBrJHQrvG6n3fg1RSM3cpR0KfsH3uaMEIaVUyzH0aYriwrhpaUPqdWCkel/u
fTpKUZ3VtVzMtiFaDhgYOtbxeLXD8kj4TCG37G1Sro9iY46yxHkqPHiVUB9lvACG
a5275yu0Z+zNfuCOUlvJtkI1CuSwOde+EOE+fzwyG9uPlacrhY3Xd7cIF9oDKFOf
vKhYp/grnnpzR4MLU1tMz0HHyBm6xI2IU7sKDWztAF0JmYH//kPs3H4boFLXmzmp
xr1eu5npsYpkhNpdflDLetMQZnqydzsmLSX8nfpkWZdkkXkmkKmuk6j1vkRiyw2k
484K71J7096UfMP0t8VhH1ObM8gZLDKXboohnCQEzUAKLKXTm3OWw+QllfJj3cvr
6GSWuKH+80CIUA10WAPNFMKO8VYFcSE68DMr+oXLk8zkXymWJR4ukWuMYa1Y14w6
tx84NuueAYHQUcqzlN0dJaTmbPiFbBRmwRFI5dcLT6t8FK2LybmXvpziFv7StHvY
C1Pr2S0W8lLwLoneaMRZsTNTd8bLzN2MlSuFdO8U6NMRvESH0WmNhF7JhGCzAegc
cYwXNgs9Ae3CK+uihxqImY2evRpk1U915n+JMfaf/TRnpK0fIR3MNFbU0WZemMvj
UYstRVCpAebJHq8L7IMbGjJesyT7vhd6CJIJCQL/4ZeWVp1W8ZPX6iKCpEhG+BhE
2CIvkNu9F8ubpvpdOdvhSs2KABGGK3DF58wJR7CsS516UuqVz+Rl0WlvVjHL9yqc
OvS1AP+NyQGfSLsGQ49tjxPSyE9uRV+dFbY7oCQlzPPdLRQ5H3htS/2CA6gCz0Cu
Ez5uweFPIe8b1k7U0ai3IWTQzxe+LQlcL+MHSgXAKz6yKk3idfpK3JViDtqz8xa5
urIYQDzOGntdjDfTdwG1+o4w/ysFI8zaCVUehL+L0T1pS0FuGwJpoyopg+6dA7rf
GVhcy3OOroAfkAXvZfqZAKTuLCFrN5+vU09iGt7kp1GqeneiaAS75JgG8oAt4SAP
KEIUquo5vxGe8WOXVpV8eByXWSpym/6wfYjwGIgzkIKz44LiqEUvL+Twz5qm3VaF
QHsJVHid/GvcUnk1mfhGtDqHWSv6KhTL2tk1mJ4cJxDzy7ijy75FXoKsDlP7H387
HnEQ/oFR9Xi52NYjylBvq/yuwhY16oGNFqqbq6uv90rdvSv5AJs7a0DxluqH/yd3
BLan1HoRCD8/iuWB2bE74TzhbO30PxuQHWCQPa7zTxJ92/Yn402z1ODUjvhKta4d
M2RTNOgIQwqcTi5qyUqhw+tKuXfQloQ1tIFI2VFwpLz9cEEImxDw+WGdb2bKfz5B
lPJIEbswHr341JqLtejMKm8dvAqkzrmuhJb+tYx5BPHDp1EUjJmzydKs9Up9QcK+
i6pkmK/42jLws5jDAvBiJp6zyaeaSABrRdY06ON7wJ0RLlaAuqecMmW4ZX/rE4oo
MIARa6SQ5JhV8Y7Z7/XWlids/GHfn9cYDIXIIadhz63a2s18qk3Ql8NAJ+CgkyiE
02h4cCjlJ/e+tpyW83XdeqvGy9tdhRir/iZh6i7iRsAQTltq/yGiR7lWQqwzMtUD
G994qckZ5PAZiKWHrB7/aWXTCDoHW1J546A5TsMcYGkIJR2UPOhFYWyOL1zCg6fG
Ehv8pO+r3CfO4vldMY4Z6Uw7mCs9c/5nrgOz7wLPPILjRoUIJ7SzknJHzqPFjG+R
Wqou6kQY6fy96Kax/iPGarfVbPJPhTJWWnxLD8NZWm8b12LViKJK6dAAl5REn3rK
om+EQVfxo/uuiLP/YAwcLwq/apURH89dDtHMiA4fh4cEY0POqwTiLm3xD0+AIaj7
lU7zbEIsKpz6HK5ex5dWsUADecIGBOyuQf//OO4E8vMO73NrSNiKA0mDPizzXCwk
UhNK2DjEZalduWlv273wFSebHM1wIiisatQIxzhwsWFuTgQJRb7/JPZGsXEg6npp
ePRShAqzrUAVOc7/flAvlNRLmOrdssqTZvmh2nFvyMeTHFoJ3BXbahxC+cNlvaWf
v0ebL2Hk7m3cntAOjuIE0ejGkqbb/6APHgYqRGRVdTmPnYq/lwohnSHcrhGmYvkL
5gk2DiSiffIpB/IJuTBQZQ==
</CipherValue>
</CipherData>
</EncryptedData>
<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>c7b+PFEoC9cVoQKKuLUQMhuHZik=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
G0vUKL9FZYu7YIk88+wvHRRAFoKjdU7Mqp8CZvTSrKHTErjPGuJCMOUpvE9uCdpq
5U8Y6LmpZxz7gUIFhWdSk0rpGpEsG7sRrrl64ZuSb4y0Z3lVVg/4CuaYpoLDGrNn
JpupwKI4DlfexXt/a9TyIWvb3gjBuN+4wPc87nQRqkX6uwOP8Qh7sKpB8lGDrbTT
AORhuzitJA9I3DI89he8IrLn6AF7YXYrE97RuP51eZ0/lIVn1M2fDQJtNqOs1poW
mPf9+TDjgELOMKhW2GF/UNXvM+QP5lInFU8mHxV62qx4NVvmoABzj11P7WM/BEqm
Lwlk1Qow470JH1xOyDeAuQ==
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f
VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTE0MDIyNzE0MTM1
M1oXDTE1MDIyNzE0MTM1M1owKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE
AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
x0WiRICc5g+w0ILzTueLxlV+TIZhqeOe1hLHcBpJQd/OmX31rl8l+rgL1juu5BDF
wkwl4EA4dZhjfuiiVChNkD4lks+464PreyjuWh+V+vgytdM84TRrXB1I+yTLrXuH
/gZSKje67/5kWICAYAdRCkD8FnSdfXFtHE7blG6gYmAOHt1/g3N/UsjxOGPiUBFW
PUvH4WYWVCgSup16ehb2SOBJGjE3FBjAOQLMlL4FiFSDB4nzNnsaRxZsHgftW87d
x2d6lprLNIlmGDFRgELM/ItGsZFOpKyv3ftqdyC3rYaOz40I5i4NzP04vwfjcWxX
glRvCjwY+T9MjOwGYpirAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV
HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6
Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF
BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50
MIHXBgNVHSMEgc8wgcyAFHppoyXFyh/JaftWYf7m3KBzOdg2oYGwpIGtMIGqMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2
YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp
Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG
SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0
cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw
EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG
A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p
emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG
SIb3DQEBCwUAA4IBAQCCKQLSng8OkgniJ4EpLnzUUGmFc8BDerVuaWv+kj1Zkk0h
8leTPuNepWMiqAzdTjYVZYw4pzzSF/wYAKCVi1ng9ULlZS6wZAOL9exCF4bllvjz
rBwDUX6gxKTq0o6jKf3qEUZLCJzwaX1LD4MW8yrWf6KR56gfUerQY2M6xmklA70d
rY4u5+2F2sE6Vuh8N2aAo7HSaFMEVd5b399kC7nLMA8UJQ6S8OO+uPe9gYkqNgUJ
HwsblCuekEeL1Gs/sZ25zGzD6Ofo097MsSYBGdPVbZbKUj9XUfIsUggY+1iAFyQI
AuSxmTIAOISUbuxupPQPAU4nHOzEZediAoiNIGd5
</X509Certificate>
<X509Certificate>
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii
ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4
KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v
MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B
AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB
2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K
z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo
Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir
96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ==
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</configlet>
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Change Log">
<section title="ID to 00">
<t>
<list style="symbols">
<t>Major structural update; the essence is the same.
Most every section was rewritten to some degree.</t>
<t>Added a Use Cases section</t>
<t>Added diagrams for "Actors and Roles" and
"NMS Precondition" sections, and greatly improved
the "Device Boot Sequence" diagram</t>
<t>Removed support for physical presence or any
ability for Configlets to not be signed.</t>
<t>Defined the ZeroTouch Information DHCP option</t>
<t>Added an ability for devices to also download
images from Configuration Servers</t>
<t>Added an ability for Configlets to be encrypted</t>
<t>Now Configuration Servers only have to support
HTTP/S - no other schemes possible</t>
</list>
</t>
</section>
<section title="00 to 01">
<t>
<list style="symbols">
<t>Added boot-image and validate-owner annotations
to the "Actors and Roles" diagram.</t>
<t>Fixed 2nd paragrph in section 7.1 to reflect
current use of anyxml.</t>
<t>Added encrypted and signed-encrypted examples</t>
<t>Replaced YANG module with XSD schema</t>
<t>Added IANA request for the ZeroTouch Information DHCP Option</t>
<t>Added IANA request for media types for boot-image and configuration</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-25 01:08:35 |