rfc8886xml2.original.xml   rfc8886.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<!-- WK: Set category, IPR, docName -->
<rfc category="info" docName="draft-ietf-opsawg-sdi-13" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-opsawg-sdi-13" number="8886" ipr="trust200902"
obsoletes="" updates="" submissionType="IETF" category="info"
consensus="true" xml:lang="en" tocInclude="true" symRefs="true"
sortRefs="true" version="3">
<front> <front>
<!-- WK: Set long title. -->
<title abbrev="Secure Device Install">Secure Device Install</title> <title abbrev="Secure Device Install">Secure Device Install</title>
<seriesInfo name="RFC" value="8886"/>
<author fullname="Warren Kumari" initials="W." surname="Kumari"> <author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<city>Mountain View, CA</city> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<author fullname="Colin Doyle" initials="C." surname="Doyle"> <author fullname="Colin Doyle" initials="C." surname="Doyle">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<city>Sunnyvale, CA</city> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>cdoyle@juniper.net</email> <email>cdoyle@juniper.net</email>
</address> </address>
</author> </author>
<date month="September" year="2020"/>
<date day="24" month="June" year="2020"/> <keyword>autoboot</keyword>
<keyword>auto-boot</keyword>
<keyword>autoinstall</keyword>
<keyword>tftp</keyword>
<keyword>install</keyword>
<keyword>bunny</keyword>
<abstract> <abstract>
<t>Deploying a new network device in a location
where the operator has no staff of its own often requires that an employee
physically travel to the location to perform the initial install and
configuration, even in shared facilities with "remote-hands" type
support. In many cases, this could be avoided if there were an
easy way to transfer the initial configuration to a new device,
while still maintaining confidentiality of the configuration.</t>
<t>This document extends existing vendor proprietary auto-install <t>Deploying a new network device in a location where the operator has
no staff of its own often requires that an employee physically travel to
the location to perform the initial install and configuration, even in
shared facilities with "remote-hands" (or similar) support. In many
cases, this could be avoided if there were an easy way to transfer the
initial configuration to a new device while still maintaining
confidentiality of the configuration.</t>
<t>This document extends existing vendor proprietary auto-install
to provide limited confidentiality to initial configuration during to provide limited confidentiality to initial configuration during
bootstrapping of the device.</t> bootstrapping of the device.</t>
<t>[ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc. They will be removed before publication. This document is being
collaborated on in Github at:
https://github.com/wkumari/draft-wkumari-opsawg-sdi. The most recent
version of the document, open issues, etc should all be available here.
The authors (gratefully) accept pull requests. ]</t>
<t>[ Ed note: This document introduces concepts and serves as the basic
for discussion. Because of this, it is conversational, and would need
to be firmed up before being published ]</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>In a growing, global network, significant amounts of time and money <t>In a growing, global network, significant amounts of time and money
are spent deploying new devices and "forklift" upgrading are spent deploying new devices and "forklift" upgrading
existing devices. In many cases, these devices are in shared existing devices. In many cases, these devices are in shared
facilities (for example, Internet Exchange Points (IXP) or facilities (for example, Internet Exchange Points (IXP) or
"carrier-neutral datacenters"), which have staff on hand that can be "carrier-neutral data centers"), which have staff on hand that can be
contracted to perform tasks including physical installs, device contracted to perform tasks including physical installs, device
reboots, loading initial configurations, etc. There are also a reboots, loading initial configurations, etc. There are also a
number of (often proprietary) protocols to perform initial number of (often proprietary) protocols to perform initial
device installs and configurations. For example, many network device installs and configurations. For example, many network
devices will attempt to use DHCP <xref target="RFC2131"></xref> or devices will attempt to use DHCP <xref target="RFC2131" format="default"/>
DHCPv6 <xref target="RFC8415"></xref> to get or
an IP address and configuration server, and then fetch and install DHCPv6 <xref target="RFC8415" format="default"/> to get
an IP address and configuration server and then fetch and install
a configuration when they are first powered on.</t> a configuration when they are first powered on.</t>
<t>The configurations of network devices contain a significant amount of <t>The configurations of network devices contain a significant amount of
security-related and proprietary information (for example, RADIUS security-related and proprietary information (for example, RADIUS
<xref target="RFC2865"></xref> or TACACS+ <xref target="I-D.ietf-opsawg-ta cacs"/> <xref target="RFC2865" format="default"/> or TACACS+ <xref target="I-D.iet f-opsawg-tacacs" format="default"/>
secrets). Exposing these to a third party to load onto a new device (or us ing secrets). Exposing these to a third party to load onto a new device (or us ing
an auto-install technique which fetches an unencrypted configuration file an auto-install technique that fetches an unencrypted configuration file v
via ia
TFTP <xref target="RFC1350"/>) or something similar is an unacceptable TFTP <xref target="RFC1350" format="default"/>) or something similar is an
unacceptable
security risk for many operators, and so they send employees to remote loc ations to security risk for many operators, and so they send employees to remote loc ations to
perform the initial configuration work; this costs time and money.</t> perform the initial configuration work; this costs time and money.</t>
<t>There are some workarounds to this, such as asking the vendor to
<t>There are some workarounds to this, such as asking the vendor to pre- preconfigure the device before shipping it; asking the remote support to
configure the device before shipping it; asking the remote support to
install a terminal server; providing a minimal, unsecured install a terminal server; providing a minimal, unsecured
configuration and using that to bootstrap to a complete configuration and using that to bootstrap to a complete
configuration, etc. However, these are often clumsy and have security configuration; etc. However, these are often clumsy and have security
issues. As an example, in the terminal server case, the console port issues. As an example, in the terminal server case, the console port
connection could be easily snooped.</t> connection could be easily snooped.</t>
<t>An ideal solution in this space would protect both the
confidentiality of device configuration in transit and the authenticity
(and authorization status) of configuration to be used by the
device. The mechanism described in this document only addresses the
former and makes no effort to do the latter, with the device accepting
any configuration file that comes its way and is encrypted to the
device's key (or not encrypted, as the case may be). Other solutions
(such as <xref target="RFC8572" format="default">Secure Zero Touch
Provisioning (SZTP)</xref>, <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"
format="default">Bootstrapping Remote Secure Key Infrastructures (BRSKI)</
xref>, and
other voucher-based methods) are more fully featured but also require
more complicated machinery.
<t>An ideal solution in this space would protect both the confidentiality This document describes something much
of device configuration in transit and the authenticity (and authorizatio
n
status) of configuration to be used by the device. The mechanism describe
d
in this document only addresses the former, and makes no effort to do
the latter, with the device accepting any configuration file that comes i
ts
way and is encrypted to the device's key (or not encrypted, as the case m
ay be).
Other solutions (such as <xref
target="RFC8572">"Secure Zero Touch Provisioning (SZTP)"</xref>,
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> and other
voucher-based methods) are more fully featured, but also require
more complicated machinery. This document describes something much
simpler, at the cost of only providing limited protection.</t> simpler, at the cost of only providing limited protection.</t>
<t>This document layers security onto existing auto-install solutions <t>This document layers security onto existing auto-install solutions
(one example of which is <xref target="Cisco_AutoInstall"/>) (one example of which is <xref target="Cisco_AutoInstall"
to provide a method to initially configure new devices while maintaining format="default"/>) to provide a method to initially configure new
(limited) confidentiality of the initial configuration. It is devices while maintaining (limited) confidentiality of the initial
optimized for simplicity, for both the implementor and the operator; configuration. It is optimized for simplicity, for both the implementor
it is explicitly not intended to be a and the operator. It is explicitly not intended to be a fully featured
fully featured system for managing installed devices, nor system for managing installed devices nor is it intended to solve all
is it intended to solve all use cases: rather it is a simple use cases; rather, it is a simple targeted solution to solve a common
targeted solution to solve a common operational issue where the operational issue where the network device has been delivered, fiber has
network device has been delivered, fibre laid (as appropriate) been laid (as appropriate), and there is no trusted member of the
and there is no trusted member of the operator's staff to perform operator's staff to perform the initial configuration. This solution is
the initial configuration. This solution is only intended to increase only intended to increase confidentiality of the information in the
confidentiality of the information in the configuration file, and configuration file and does not protect the device itself from loading a
does not protect the device itself from loading a malicious malicious configuration.</t>
configuration.</t> <t>This document describes a concept and some example ways of implementing
this concept. As devices have different capabilities and use different
<t>This document describes a concept, and some example ways of implementin
g
this concept. As devices have different capabilities, and use different
configuration paradigms, one method will not suit all, and so it is configuration paradigms, one method will not suit all, and so it is
expected that vendors will differ in exactly how they implement this.</t> expected that vendors will differ in exactly how they implement this.</t>
<t>This solution is specifically designed to be a simple method on top <t>This solution is specifically designed to be a simple method on top
of exiting device functionality. If devices do not support this new of exiting device functionality. If devices do not support this new
method, they can continue to use the existing functionality. In method, they can continue to use the existing functionality. In
addition, operators can choose to use this to protect their addition, operators can choose to use this to protect their
configuration information, or can continue to use the existing configuration information or can continue to use the existing
functionality.</t> functionality.</t>
<t>The issue of securely installing devices is in no way a new issue
<t>The issue of securely installing devices is in no way a new issue,
nor is it limited to network devices; it occurs when deploying nor is it limited to network devices; it occurs when deploying
servers, PCs, IoT devices, and in many other situations. While the servers, PCs, Internet of Things (IoT) devices, and in many other situatio ns. While the
solution described in this document is obvious (encrypt the config, solution described in this document is obvious (encrypt the config,
then decrypt it with a device key), this document only discusses the then decrypt it with a device key), this document only discusses the
use for network devices, such as routers and switches.</t> use for network devices, such as routers and switches.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Overview"> <name>Overview</name>
<t>Most network devices already include some sort of initial bootstrapping <t>Most network devices already include some sort of initial
logic (sometimes called 'autoboot', or 'autoinstall'). This generally work bootstrapping logic (sometimes called 'autoboot' or 'autoinstall'). This
s generally works by having a newly installed, unconfigured device obtain
by having a newly installed, unconfigured device obtain an IP address for an IP address for itself and discover the address of a configuration
itself server (often called 'next-server', 'siaddr', or 'tftp-server-name')
and discover the address of a configuration server using DHCP or DHCPv6 (see <xref target="RFC2131" format="default"/> and
(often called 'next-server', 'siaddr' or <xref target="RFC8415" format="default"/>). The device then contacts
'tftp-server-name') using DHCP or DHCPv6 (see <xref target="RFC2131"></xre this configuration server to download its initial configuration, which
f>, is often identified using the device's serial number, Media Access
<xref target="RFC8415"></xref>). The device Control (MAC) address, or similar. This document extends this
then contacts this configuration server to download its initial configurat (vendor-specific) paradigm by allowing the configuration file to be
ion, encrypted.</t>
which is often identified using the device's serial number, MAC address or
similar. This document extends this (vendor-specific) paradigm by allowing
the configuration file to be encrypted.</t>
<t>This document uses the serial number of the device as a unique device <t>This document uses the serial number of the device as a unique device
identifier for simplicity; some vendors may not want to implement the identifier for simplicity; some vendors may not want to implement the
system using the serial number as the identifier for business reasons (a system using the serial number as the identifier for business reasons (a
competitor or similar could enumerate the serial numbers and determine competitor or similar could enumerate the serial numbers and determine
how many devices have been manufactured). Implementors are free to how many devices have been manufactured). Implementors are free to
choose some other way of generating identifiers (e.g., UUID <xref choose some other way of generating identifiers (e.g., a Universally
target="RFC4122"/>), but this will likely make it somewhat harder for Unique Identifier (UUID) <xref target="RFC4122" format="default"/>), but
this will likely make it somewhat harder for
operators to use (the serial number is usually easy to find on a device).< /t> operators to use (the serial number is usually easy to find on a device).< /t>
<section numbered="true" toc="default">
<t>[ Ed note: This example also uses TFTP because that is what many vendor <name>Example Scenario</name>
s <t>Operator_A needs another peering router, and so they
use in their auto-install feature. It could easily instead be order another router from Vendor_B to be drop-shipped to
HTTP, FTP, etc. ]</t>
<section title="Example Scenario">
<t>Operator_A needs another peering router, and so they
order another router from Vendor_B, to be drop-shipped to
the facility. Vendor_B begins assembling the new the facility. Vendor_B begins assembling the new
device, and tells Operator_A what the new device's serial number will be device and tells Operator_A what the new device's serial number will be
(SN:17894321). When Vendor_B first installs the firmware on the device and (SN:17894321). When Vendor_B first installs the firmware on the device and
boots it, the device generates a public-private key pair, and Vendor_B boots it, the device generates a public-private key pair, and Vendor_B
publishes the public key on their keyserver (in a public key certificate, for publishes the public key on its key server (in a public key certificate, f or
ease of use).</t> ease of use).</t>
<t>While the device is being shipped, Operator_A generates the initial
<t>While the device is being shipped, Operator_A generates the initial device configuration and fetches the certificate from Vendor_B key servers
device configuration and fetches the certificate from Vendor_B keyservers by
by
providing the serial number of the new device. Operator_A then encrypts th e providing the serial number of the new device. Operator_A then encrypts th e
device configuration and puts this encrypted configuration on a (local) TF TP device configuration and puts this encrypted configuration on a (local) TF TP
server.</t> server.</t>
<t>When the device arrives at the Point of Presence (POP), it gets
<t>When the device arrives at the POP, it gets installed in Operator_A's installed in Operator_A's rack and cabled as instructed. The new
rack, and cabled as instructed. The new device powers up and discovers device powers up and discovers that it has not yet been configured. It
that it has not yet been configured. It enters its autoboot state, and enters its autoboot state and begins the DHCP process. Operator_A's
begins the DHCP process. Operator_A's DHCP server provides it with an IP DHCP server provides it with an IP address and the address of the
address and the address of the configuration server. The router uses configuration server. The router uses TFTP to fetch its configuration
TFTP to fetch its configuration file. Note that all of this is existing file. Note that all of this is existing functionality. The device
functionality. The device attempts to load the configuration file. As an attempts to load the configuration file. As an added step, if the
added step, if the configuration file cannot be parsed, the device tries configuration file cannot be parsed, the device tries to use its
to use its private key to decrypt the file and, assuming it validates, private key to decrypt the file and, assuming it validates, proceeds
proceeds to install the new, decrypted, configuration.</t> to install the new, decrypted configuration.</t>
<t>Only the "correct" device will have the required private key and be
<t>Only the "correct" device will have the required private key and be able to decrypt and use the configuration file (see
able to decrypt and use the configuration file (See
<xref target="security">Security Considerations</xref>). <xref target="security">Security Considerations</xref>).
An attacker would be able to connect to the network and get an IP An attacker would be able to connect to the network and get an IP
address. They would also be able to retrieve (encrypted) configuration fil es by address. They would also be able to retrieve (encrypted) configuration fil es by
guessing serial numbers (or perhaps the server would allow directory guessing serial numbers (or perhaps the server would allow directory
listing), but without the private keys an attacker will not be able to listing), but without the private keys, an attacker will not be able to
decrypt the files.</t> decrypt the files.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Vendor Role"> <name>Vendor Role</name>
<t>This section describes the vendor's roles and <t>This section describes the vendor's roles and
provides an overview of what the device needs to do.</t> provides an overview of what the device needs to do.</t>
<section numbered="true" toc="default">
<section title="Device key generation"> <name>Device Key Generation</name>
<t>Each device requires a public-private key pair, and for the <t>Each device requires a public-private key pair and for the
public part to be published and retrievable by the operator. The public part to be published and retrievable by the operator. The
cryptographic algorithm and key lengths to be used are out of the scope cryptographic algorithm and key lengths to be used are out of the scope
of this document. This section illustrates one method, but, as with of this document. This section illustrates one method, but, as with
much of this document the exact mechanism may vary by vendor. much of this document, the exact mechanism may vary by vendor.
Enrollment over Secure Transport (<xref target="RFC7030"/>)
or possibly <xref target="I-D.gutmann-scep"/> are
methods which vendors may want to consider.</t>
Enrollment over Secure Transport <xref target="RFC7030"
format="default"/> and possibly the Simple Certificate Enrollment
Protocol <xref target="RFC8894" format="default"/> are
methods that vendors may want to consider.</t>
<t>During the manufacturing stage, when the device is initially powered <t>During the manufacturing stage, when the device is initially powered
on, it will generate a public-private key pair. It will send its unique device on, it will generate a public-private key pair. It will send its unique device
identifier and the public key to the vendor's directory server identifier and the public key to the vendor's directory server
(<xref target="RFC5280"/>) to be published. The vendor's directory serve <xref target="RFC5280" format="default"/> to be published. The vendor's
r directory server
should only accept certificates from the manufacturing facility, should only accept certificates that are from the manufacturing
and which match vendor defined policies (for example, extended key usage facility and that match vendor-defined policies (for example, extended
, key usage and extensions).
and extensions) Note that some devices may be constrained, and so may se
nd Note that some devices may be constrained and so may send
the raw public key and unique device identifier to the certificate the raw public key and unique device identifier to the certificate
publication server, while more capable devices may generate and send publication server, while more capable devices may generate and send
self-signed certificates. This communication with the directory server self-signed certificates.
should be integrity protected, and in a controlled environment.</t>
This communication with the directory server should be integrity protected and
should occur in a controlled environment.</t>
<t>This reference architecture needs a serialization format for the <t>This reference architecture needs a serialization format for the
key material. Due to the prevalence of tooling support for it on key material. Due to the prevalence of tooling support for it on
network devices, X.509 certificates are a convenient format to network devices, X.509 certificates are a convenient format to
exchange public keys. However, most of the meta-data that would exchange public keys.
use for revocation and aging will not be used and should be
ignored by both the client and server. In such cases the
signature on the certificate conveys no value and the consumer
of the certificate is expected to pin the end-entity key
fingerprint (versus using a PKI and signature chain).</t>
</section>
<section title="Directory Server"> However, most of the metadata that would be used for revocation and aging will
not be used and should be ignored by both the client and server. In such
cases, the signature on the certificate conveys no value, and the consumer of
the certificate is expected to pin the end-entity key fingerprint (versus
using a PKI and signature chain).</t>
</section>
<section numbered="true" toc="default">
<name>Directory Server</name>
<t>The directory server contains a database of <t>The directory server contains a database of
certificates. If newly manufactured devices upload certificates the certificates. If newly manufactured devices upload certificates, the
directory server can simply publish these; if the directory server can simply publish these; if the
devices provide the raw public keys and unique device identifier, devices provide the raw public keys and unique device identifier,
the directory server will need to wrap these in a the directory server will need to wrap these in a
certificate.</t> certificate.</t>
<t>The customers (e.g., Operator_A) query this server with <t>The customers (e.g., Operator_A) query this server with
the serial number (or other provided unique identifier) of a device, the serial number (or other provided unique identifier) of a device
and retrieve the associated certificate. It is expected that operators and retrieve the associated certificate. It is expected that operators
will receive the unique device identifier (serial number) of devices whe n will receive the unique device identifier (serial number) of devices whe n
they purchase them, and will download and store the they purchase them and will download and store the
certificate. This means that there is not a hard requirement on the certificate. This means that there is not a hard requirement on the
reachability of the directory server.</t> reachability of the directory server.</t>
<figure>
<figure> <name>Initial Certificate Generation and Publication</name>
<artwork><![CDATA[ +------------+ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------+
+------+ | | +------+ | |
|Device| | Directory | |Device| | Directory |
+------+ | Server | +------+ | Server |
+------------+ +------------+
+----------------+ +--------------+ +----------------+ +--------------+
| +---------+ | | | | +---------+ | | |
| | Initial | | | | | | Initial | | | |
| | boot? | | | | | | boot? | | | |
| +----+----+ | | | | +----+----+ | | |
| | | | | | | | | |
skipping to change at line 316 skipping to change at line 284
| |Certificate | | | | | |Certificate | | | |
| +------------+ | | | | +------------+ | | |
| | | | +-------+ | | | | | +-------+ |
| +-------|---|-->|Receive| | | +-------|---|-->|Receive| |
| | | +---+---+ | | | | +---+---+ |
| | | | | | | | | |
| | | +---v---+ | | | | +---v---+ |
| | | |Publish| | | | | |Publish| |
| | | +-------+ | | | | +-------+ |
| | | | | | | |
+----------------+ +--------------+]]></artwork> +----------------+ +--------------+
]]></artwork>
<postamble>Initial certificate generation and </figure>
publication.</postamble>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Operator Role"> <name>Operator Role</name>
<section title="Administrative "> <section numbered="true" toc="default">
<name>Administrative</name>
<t>When purchasing a new device, the accounting department will need <t>When purchasing a new device, the accounting department will need
to get the unique device identifier (e.g., serial number) of the new to get the unique device identifier (e.g., serial number) of the new
device and communicate it to the operations group.</t> device and communicate it to the operations group.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Technical"> <name>Technical</name>
<t>The operator will contact the vendor's publication server, and <t>The operator will contact the vendor's publication server and
download the certificate (by providing the unique device identifier of download the certificate (by providing the unique device identifier of
the device). The operator fetches the certificate using a secure the device). The operator fetches the certificate using a secure
transport that authenticates the source of the certificate, transport that authenticates the source of the certificate,
such as HTTPS (confidentiality protection can provide some privacy such as HTTPS (confidentiality protection can provide some privacy
and metadata-leakage benefit, but is not key to the primary and metadata-leakage benefit but is not key to the primary
mechanism of this document). The operator will then encrypt the initial mechanism of this document). The operator will then encrypt the initial
configuration (for example, using SMIME <xref target="RFC5751"/>) configuration (for example, using S/MIME <xref target="RFC8551" format="
using the key in the certificate, and place it on their default"/>)
using the key in the certificate and place it on their
configuration server.</t> configuration server.</t>
<t>See Appendix B for examples.</t>
<figure> <t>See <xref target="proof"/> for examples.</t>
<artwork><![CDATA[ +------------+ <figure>
+--------+ | | <name>Fetching the Certificate, Encrypting the Configuration, and Publishing
|Operator| | Directory | the Encrypted Configuration</name>
+--------+ | Server | <artwork name="" type="" align="left" alt=""><![CDATA[
+------------+
+--------+ | |
|Operator| | Directory |
+--------+ | Server |
+------------+ +------------+
+----------------+ +----------------+ +----------------+ +----------------+
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | Fetch | | | | | | | | Fetch | | | | | |
| | Device |<------>|Certificate| | | | Device |<------>|Certificate| |
| |Certificate| | | | | | | |Certificate| | | | | |
| +-----+-----+ | | +-----------+ | | +-----+-----+ | | +-----------+ |
| | | | | | | | | |
| +-----v------+ | | | | +-----v------+ | | |
| | Encrypt | | | | | | Encrypt | | | |
| | Device | | | | | | Device | | | |
| | Config | | | | | | Config | | | |
| +-----+------+ | | | | +-----+------+ | | |
| | | | | | | | | |
| +-----v------+ | | | | +-----v------+ | | |
| | Publish | | | | | | Publish | | | |
| | TFTP | | | | | | TFTP | | | |
| | Server | | | | | | Server | | | |
| +------------+ | | | | +------------+ | | |
| | | | | | | |
+----------------+ +----------------+]]></artwork> +----------------+ +----------------+
]]></artwork>
<postamble>Fetching the certificate, encrypting the configuration, </figure>
publishing the encrypted configuration.</postamble>
</figure>
</section> </section>
<section anchor="initial_cust_boot" numbered="true" toc="default">
<section anchor="initial_cust_boot" title="Example Initial Customer Boot"> <name>Example Initial Customer Boot</name>
<t>When the device is first booted by the customer (and on subsequent <t>When the device is first booted by the customer (and on subsequent
boots), if the device does not have a valid configuration, it will use boots), if the device does not have a valid configuration, it will use
existing auto-install functionality. As an example, it performs DHCP existing auto-install functionality. As an example, it performs DHCP
Discovery until it gets a DHCP offer including DHCP option 66 Discovery until it gets a DHCP offer including DHCP option 66
(Server-Name) or 150 (TFTP server address), contacts the server (Server-Name) or 150 (TFTP server address), contacts the server
listed in these DHCP options and downloads its configuration file. Note that this listed in these DHCP options, and downloads its configuration file. Note that this
is existing functionality (for example, Cisco devices fetch the config is existing functionality (for example, Cisco devices fetch the config
file named by the Bootfile-Name DHCP option (67)).</t> file named by the Bootfile-Name DHCP option (67)).</t>
<t>After retrieving the configuration file, the device needs to determin e if it is <t>After retrieving the configuration file, the device needs to determin e if it is
encrypted or not. If it is not encrypted, the existing behavior is used. encrypted or not. If it is not encrypted, the existing behavior is used.
If the configuration is encrypted, the process continues as described in this If the configuration is encrypted, the process continues as described in this
document. If the device has been configured to only support encrypted co nfiguration document. If the device has been configured to only support encrypted co nfiguration
and determines that the configuration file is not encrypted, it should a bort. and determines that the configuration file is not encrypted, it should a bort.
The method used to determine if the configuration is encrypted or not is The method used to determine if the configuration is encrypted or not is
implementation dependent; there are a number of (obvious) options, inclu ding implementation dependent; there are a number of (obvious) options, inclu ding
having a magic string in the file header, using a file name extension having a magic string in the file header, using a file name extension
(e.g., config.enc), or using specific DHCP options.</t> (e.g., config.enc), or using specific DHCP options.</t>
<t>If the file is encrypted, the device will attempt to <t>If the file is encrypted, the device will attempt to
decrypt and parse the file. If able, it will install the configuration, decrypt and parse the file. If able, it will install the configuration a
and nd
start using it. If it cannot decrypt the file, or if parsing the configu start using it. If it cannot decrypt the file or if parsing the configur
ration fails, ation fails,
the device will either abort the auto-install process, or repeat this the device will either abort the auto-install process or repeat this
process until it succeeds. When retrying, care should be taken to not process until it succeeds. When retrying, care should be taken to not
overwhelm the server hosting the encrypted configuration files. It is su ggested overwhelm the server hosting the encrypted configuration files. It is su ggested
that the device retry every 5 minutes for the first hour, and then every hour after that the device retry every 5 minutes for the first hour and then every hour after
that. As it is expected that devices may be installed well before the that. As it is expected that devices may be installed well before the
configuration file is ready, a maximum number of retries is not specifie d.</t> configuration file is ready, a maximum number of retries is not specifie d.</t>
<t>Note that the device only needs to be able to download the <t>Note that the device only needs to be able to download the
configuration file; after the initial power-on in the factory it never n configuration file; after the initial power on in the factory, it never
eeds needs
to access the Internet or vendor or directory server. The device to access the Internet, vendor, or directory server. The device
(and only the device) has the private key and so has the ability to decr ypt (and only the device) has the private key and so has the ability to decr ypt
the configuration file.</t> the configuration file.</t>
<figure>
<figure> <name>Device Boot, Fetch, and Install Configuration File</name>
<artwork><![CDATA[ +--------+ +--------------+ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------------+
| Device | |Config server | | Device | |Config server |
+--------+ | (e.g. TFTP) | +--------+ |(e.g., TFTP) |
+--------------+ +--------------+
+---------------------------+ +------------------+ +---------------------------+ +------------------+
| +-----------+ | | | | +-----------+ | | |
| | | | | | | | | | | |
| | DHCP | | | | | | DHCP | | | |
| | | | | | | | | | | |
| +-----+-----+ | | | | +-----+-----+ | | |
| | | | | | | | | |
| +-----v------+ | | +-----------+ | | +-----v------+ | | +-----------+ |
| | | | | | Encrypted | | | | | | | | Encrypted | |
skipping to change at line 458 skipping to change at line 424
| \ / | Boot | | | | | \ / | Boot | | | |
| \ / +--------+ | | | | \ / +--------+ | | |
| V | | | | V | | |
| |N | | | | |N | | |
| | | | | | | | | |
| +----v---+ | | | | +----v---+ | | |
| |Retry or| | | | | |Retry or| | | |
| | abort | | | | | | abort | | | |
| +--------+ | | | | +--------+ | | |
| | | | | | | |
+---------------------------+ +------------------+]]></artwork> +---------------------------+ +------------------+
]]></artwork>
<postamble>Device boot, fetch and install configuration file</postambl </figure>
e>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Additional Considerations"> <name>Additional Considerations</name>
<section title="Key storage"> <section numbered="true" toc="default">
<name>Key Storage</name>
<t>Ideally, the key pair would be stored in a Trusted Platform Module <t>Ideally, the key pair would be stored in a Trusted Platform Module
(TPM) on something which is identified as the &ldquo;router&rdquo; (TPM) on something that is identified as the "router"
- for example, the chassis / backplane. This is so that a key pair -- for example, the chassis/backplane. This is so that a key pair
is bound to what humans think of as the &ldquo;device&rdquo;, and is bound to what humans think of as the "device" and
not, for example (redundant) routing engines. Devices which not, for example, (redundant) routing engines. Devices that
implement IEEE 802.1AR <xref target="IEEE802-1AR"/> implement IEEE 802.1AR <xref target="IEEE802-1AR" format="default"/>
could choose to use the IDevID for this could choose to use the Initial Device Identifier (IDevID) for this
purpose.</t> purpose.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Key replacement "> <name>Key Replacement</name>
<t>It is anticipated that some operator may want to replace the <t>It is anticipated that some operator may want to replace the
(vendor provided) keys after installing the device. There are two (vendor-provided) keys after installing the device. There are two
options when implementing this: a vendor could allow the operator's options when implementing this: a vendor could allow the operator's
key to completely replace the initial device-generated key (which key to completely replace the initial device-generated key (which
means that, if the device is ever sold, the new owner couldn't use means that, if the device is ever sold, the new owner couldn't use
this technique to install the device), or the device could prefer the this technique to install the device), or the device could prefer the
operator's installed key. This is an implementation decision left to operator's installed key. This is an implementation decision left to
the vendor.</t> the vendor.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Device reinstall"> <name>Device Reinstall</name>
<t>Increasingly, operations is moving towards an automated model of <t>Increasingly, operations are moving towards an automated model of
device management, whereby portions of (or the entire) configuration is device management, whereby portions of the configuration (or the entire
configuration) are
programmatically generated. This means that operators may want to programmatically generated. This means that operators may want to
generate an entire configuration after the device has been initially generate an entire configuration after the device has been initially
installed and ask the device to load and use this new configuration. installed and ask the device to load and use this new configuration.
It is expected (but not defined in this document, as it is vendor It is expected (but not defined in this document, as it is vendor
specific) that vendors will allow the operator to copy a new, specific) that vendors will allow the operator to copy a new,
encrypted configuration (or part of a configuration) onto a device and t encrypted configuration (or part of a configuration) onto a device and
hen request then request that the device decrypt and install it (e.g., 'load
that the device decrypt and install it (e.g.: &lsquo;load replace replace &lt;filename&gt; encrypted'). The operator could also choose to
&lt;filename&gt; encrypted). The operator could also choose to reset reset the device to factory defaults and allow the device to act as
the device to factory defaults, and allow the device to act as though though it were the initial boot (see <xref target="initial_cust_boot"
it were the initial boot (see <xref target="initial_cust_boot"/>).</t> format="default"/>).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document makes no requests of the IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>This reference architecture is intended to incrementally improve <t>This reference architecture is intended to incrementally improve
upon commonly accepted "auto-install" practices used today that may upon commonly accepted "auto-install" practices used today that may
transmit configurations unencrypted (e.g., unencrypted configuration files transmit configurations unencrypted (e.g., unencrypted configuration files
which can be downloaded connecting to unprotected ports in datacenters, that can be downloaded connecting to unprotected ports in data centers,
mailing initial configuration files on flash drives, or emailing configura tion files mailing initial configuration files on flash drives, or emailing configura tion files
and asking a third-party to copy and paste them over a serial terminal) and asking a third party to copy and paste them over a serial terminal)
or allow unrestricted access to these configurations.</t> or allow unrestricted access to these configurations.</t>
<t>> This document describes an object level security design to provide <t>This document describes an object-level security design to provide
confidentiality assurances for the configuration stored at rest on the confidentiality assurances for the configuration stored at rest on the
configuration server; and for configuration while it is in transit between configuration server and for configuration while it is in transit
the configuration server and the unprovisioned device even if the underly between the configuration server and the unprovisioned device, even if
transport does not provide this security service.</t> the underlying transport does not provide this security service.</t>
<t>The architecture provides no assurances about the source of <t>The architecture provides no assurances about the source of
the encrypted configuration or protect against theft and the encrypted configuration or protect against theft and
reuse of devices.</t> reuse of devices.</t>
<t>An attacker (e.g., a malicious data center employee, person in the
<t>An attacker (e.g., a malicious datacenter employee, person in the
supply chain, etc.) who has physical supply chain, etc.) who has physical
access to the device before it is connected to the network, or who access to the device before it is connected to the network or who
manages to exploit it once installed, manages to exploit it once installed
may be able to extract the device private key (especially if it is not may be able to extract the device private key (especially if it is not
stored in a TPM), pretend to be the device when connecting to the stored in a TPM), pretend to be the device when connecting to the
network, and download and extract the (encrypted) configuration file.</t> network, and download and extract the (encrypted) configuration file.</t>
<t>An attacker with access to the configuration server (or the <t>An attacker with access to the configuration server (or the
ability to route traffic to configuration server under their control) ability to route traffic to configuration server under their control)
and the device's public key could return a configuration of the and the device's public key could return a configuration of the
attacker's choosing to the unprovisioned device.</t> attacker's choosing to the unprovisioned device.</t>
<t>This mechanism does not protect against a malicious vendor. While <t>This mechanism does not protect against a malicious vendor. While
the key pair should be generated on the device, and the private key the key pair should be generated on the device and the private key
should be securely stored, the mechanism cannot detect or protect should be securely stored, the mechanism cannot detect or protect
against a vendor who claims to do this, but instead generates the against a vendor who claims to do this but instead generates the
key pair off device and keeps a copy of the private key. It is largely key pair off device and keeps a copy of the private key. It is largely
understood in the operator community that a malicious vendor or attacker understood in the operator community that a malicious vendor or attacker
with physical access to the device is largely a "Game Over" with physical access to the device is largely a "Game Over"
situation.</t> situation.</t>
<t>Even when using a secure bootstrap mechanism, security-conscious <t>Even when using a secure bootstrap mechanism, security-conscious
operators may wish to bootstrap devices with a minimal or less-sensitive operators may wish to bootstrap devices with a minimal or less-sensitive
configuration, and then replace this with a more complete one after configuration and then replace this with a more complete one after
install.</t> install.</t>
</section> </section>
<section title="Acknowledgments">
<t>The authors wish to thank everyone who contributed, including Benoit
Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael Richardson,
Sean Turner and Kent Watsen. Joe Clarke also provided significant
comments and review, and Tom Petch provided significant editorial
contributions to better describe the use cases, and clarify the scope.</t>
<t>Roman Danyliw and Benjamin Kaduk also provided helpful text,
especially around the certificate usage and security considerations.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Informative References">
<?rfc include='reference.RFC.8572'?>
<?rfc include='reference.RFC.4122'?> <displayreference target="I-D.ietf-anima-bootstrapping-keyinfra" to="BRSKI"/>
<?rfc include='reference.RFC.2131'?>
<?rfc include='reference.RFC.8415'?>
<?rfc include='reference.RFC.2865'?>
<?rfc include='reference.RFC.1350'?>
<?rfc include='reference.RFC.5751'?>
<?rfc include='reference.RFC.7030'?>
<?rfc include='reference.RFC.5280'?>
<?rfc include="reference.I-D.ietf-opsawg-tacacs.xml"?>
<?rfc include="reference.I-D.ietf-anima-bootstrapping-keyinfra.xml"?>
<?rfc include="reference.I-D.gutmann-scep.xml"?>
<reference anchor="IEEE802-1AR"
target="https://standards.ieee.org/standard/802_1AR-2018.html">
<front>
<title>IEEE Standard for Local and Metropolitan Area Net
works - Secure Device Identity</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" year="2018"/>
</front>
<format type="TXT" target="https://standards.ieee.org/standard/8
02_1AR-2018.html"/>
</reference>
<reference anchor="Cisco_AutoInstall"
target="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundam
entals/configuration/15mt/fundamentals-15-mt-book/cf-autoinstall.html">
<front>
<title>Using AutoInstall to Remotely Configure Cisco Net
working Devices</title>
<author>
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="Jan" year="2018"/>
</front>
<format type="TXT" target="https://standards.ieee.org/standard/8
02_1AR-2018.html"/>
</reference>
</references>
<section title="Changes / Author Notes.">
<t>[RFC Editor: Please remove this section before publication ]</t>
<t>From -09 to -10</t>
<t><list style="symbols">
<t>Typos - "lenghts" => "lengths", missed a reference to Acme.</t>
</list></t>
<t>From -08 to -09</t>
<t><list style="symbols">
<t>Addressed Mirja's IETF LC comments.</t>
</list></t>
<t>From -04 to -08</t>
<t><list style="symbols">
<t>Please see GitHub commit log (I forgot to put them in here :-P )</t
>
</list></t>
<t>From -03 to -04</t> <displayreference target="I-D.ietf-opsawg-tacacs" to="TACACS"/>
<t><list style="symbols">
<t>Addressed Joe's WGLC comments. This involved changing the "just try
decrypt and pray" to vendor specific, like a file extension, magic header sting
, etc.</t>
<t>Addressed tom's comments.</t>
</list></t>
<t>From individual WG-01 to -03:</t> <references>
<t><list style="symbols"> <name>Informative References</name>
<t>Addressed Joe Clarke's comments - https://mailarchive.ietf.org/arch <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
/msg/opsawg/JTzsdVXw-XtWXZIIFhH7aW_-0YY</t> ce.RFC.8572.xml"/>
<t>Many typos / nits</t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<t>Broke Overview and Example Scenario into 2 sections.</t> ce.RFC.4122.xml"/>
<t>Reordered text for above.</t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
</list></t> ce.RFC.2131.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8415.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2865.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1350.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8551.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7030.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5280.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8894.xml"/>
<t>From individual -04 to WG-01:</t> <reference anchor='I-D.ietf-opsawg-tacacs'>
<front>
<title>The TACACS+ Protocol</title>
<t><list style="symbols"> <author initials='T' surname='Dahm' fullname='Thorsten Dahm'>
<t>Renamed from draft-wkumari-opsawg-sdi-04 -&gt; <organization />
draft-ietf-opsawg-sdi-00</t> </author>
</list></t>
<t>From -00 to -01</t> <author initials='A' surname='Ota' fullname='Andrej Ota'>
<organization />
</author>
<t><list style="symbols"> <author initials='D.' surname='Medway Gash' fullname='Douglas C. Medway Gash'>
<t>Nothing changed in the template!</t> <organization />
</list>From -01 to -03:<list style="symbols"> </author>
<t>See github commit log (AKA, we forgot to update this!)</t>
<t>Added Colin Doyle.</t> <author initials='D' surname='Carrel' fullname='David Carrel'>
</list></t> <organization />
</author>
<t>From -03 to -04:</t> <author initials='L' surname='Grant' fullname='Lol Grant'>
<organization />
</author>
<t>Addressed a number of comments received before / at IETF104 (Prague). <date month='March' day='20' year='2020' />
These include:<list style="symbols">
<t>Pointer to
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch --
included reference to (now) RFC8572 (KW)</t>
<t>Suggested that 802.1AR IDevID (or similar) could be used. Stress </front>
that this is designed for simplicity (MR)</t> <seriesInfo name='Internet-Draft' value='draft-ietf-opsawg-tacacs-18' />
<t>Added text to explain that any unique device identifier can be </reference>
used, not just serial number - serial number is simple and easy, but
anything which is unique (and can be communicated to the customer)
will work (BF).</t>
<t>Lots of clarifications from Joe Clarke.</t> <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-a
nima-bootstrapping-keyinfra.xml"/>
<t>Make it clear it should first try use the config, and if it <reference anchor="IEEE802-1AR" target="https://standards.ieee.org/standar
doesn't work, then try decrypt and use it.</t> d/802_1AR-2018.html">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secure
Device Identity</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="802-1AR"/>
</reference>
<t>The CA part was confusing people - the certificate is simply a <reference anchor="Cisco_AutoInstall" target="https://www.cisco.com/c/en/u
wrapper for the key, and the Subject just an index, and so removed s/td/docs/ios-xml/ios/fundamentals/configuration/15mt/fundamentals-15-mt-book/cf
that.</t> -autoinstall.html">
<front>
<title>Using AutoInstall to Remotely Configure Cisco Networking Device
s</title>
<author>
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="January" year="2018"/>
</front>
<refcontent>Configuration Fundamentals Configuration Guide, Cisco IOS
Release 15M&amp;T</refcontent>
</reference>
</references>
<t>Added a bunch of ASCII diagrams</t> <section anchor="proof" numbered="true" toc="default">
</list></t> <name>Proof of Concept</name>
</section>
<section title="Proof of Concept">
<t>This section contains a proof of concept of the system. <t>This section contains a proof of concept of the system.
It is only intended for illustration, and is not intended to be used It is only intended for illustration and is not intended to be used
in production.</t> in production.</t>
<t>It uses OpenSSL from the command line. In production, something more
<t>It uses OpenSSL from the command line. In production something more
automated would be used. In this example, the unique device identifier is the automated would be used. In this example, the unique device identifier is the
serial number of the router, SN19842256.</t> serial number of the router, SN19842256.</t>
<section numbered="true" toc="default">
<section title="Step 1: Generating the certificate. "> <name>Step 1: Generating the Certificate</name>
<t>This step is performed by the router. It generates a key, then a <t>This step is performed by the router. It generates a key, then a
Certificate Signing Request (CSR), and then a self signed certificate.</ Certificate Signing Request (CSR), and then a self-signed certificate.</
t> t>
<section numbered="true" toc="default">
<section title="Step 1.1: Generate the private key. "> <name>Step 1.1: Generate the Private Key</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork><![CDATA[ $ openssl ecparam -out privatekey.key -name prime256v1 -genkey
$ openssl ecparam -out privatekey.key -name prime256v1 -genkey $
$ ]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 1.2: Generate the certificate signing request."> <name>Step 1.2: Generate the Certificate Signing Request</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork><![CDATA[$ openssl req -new -key key.pem -out SN19842256.cs $ openssl req -new -key key.pem -out SN19842256.csr
r Common Name (e.g., server FQDN or YOUR name) []:SN19842256
Common Name (e.g. server FQDN or YOUR name) []:SN19842256 ]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 1.3: Generate the (self signed) certificate itself. <name>Step 1.3: Generate the (Self-Signed) Certificate Itself</name>
"> <sourcecode name="" type=""><![CDATA[
<t>$ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr
-out SN19842256.crt</t> -out SN19842256.crt
]]></sourcecode>
<t>The router then sends the key to the vendor&rsquo;s keyserver for <t>The router then sends the key to the vendor's key server for
publication (not shown).</t> publication (not shown).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 2: Generating the encrypted configuration. "> <name>Step 2: Generating the Encrypted Configuration</name>
<t>The operator now wants to deploy the new router.</t> <t>The operator now wants to deploy the new router.</t>
<t>They generate the initial configuration (using whatever magic tool <t>They generate the initial configuration (using whatever magic tool
generates router configs!), fetch the router&rsquo;s certificate and generates router configs!), fetch the router's certificate, and
encrypt the configuration file to that key. This is done by the operator .</t> encrypt the configuration file to that key. This is done by the operator .</t>
<section numbered="true" toc="default">
<section title="Step 2.1: Fetch the certificate."> <name>Step 2.1: Fetch the Certificate</name>
<t>$ wget http://keyserv.example.net/certificates/SN19842256.crt</t> <sourcecode name="" type=""><![CDATA[
$ wget http://keyserv.example.net/certificates/SN19842256.crt
]]></sourcecode>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 2.2: Encrypt the configuration file. "> <name>Step 2.2: Encrypt the Configuration File</name>
<t>S/MIME is used here because it is simple to demonstrate. This is <t>S/MIME is used here because it is simple to demonstrate. This is
almost definitely not the best way to do this.</t> almost definitely not the best way to do this.</t>
<sourcecode name="" type=""><![CDATA[
<figure> $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\
<artwork><![CDATA[$ openssl smime -encrypt -aes-256-cbc -in SN198422
56.cfg\
-out SN19842256.enc -outform PEM SN19842256.crt -out SN19842256.enc -outform PEM SN19842256.crt
$ more SN19842256.enc $ more SN19842256.enc
-----BEGIN PKCS7----- -----BEGIN PKCS7-----
MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV
BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3 BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3
... ...
LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt
-----END PKCS7----- -----END PKCS7-----
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 2.3: Copy configuration to the configuration server <name>Step 2.3: Copy Configuration to the Configuration Server</name>
."> <sourcecode name="" type=""><![CDATA[
<figure> $ scp SN19842256.enc config.example.com:/tftpboot
<artwork><![CDATA[$ scp SN19842256.enc config.example.com:/tftpboot ]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 3: Decrypting and using the configuration. "> <name>Step 3: Decrypting and Using the Configuration</name>
<t>When the router connects to the operator's network it will detect <t>When the router connects to the operator's network, it will detect
that does not have a valid configuration file, and will start the that it does not have a valid configuration file and will start the
&ldquo;autoboot&rdquo; process. This is a well documented process, but "autoboot" process. This is a well-documented process, but
the high level overview is that it will use DHCP to obtain an IP the high-level overview is that it will use DHCP to obtain an IP
address and configuration server. It will then use TFTP to download a address and configuration server. It will then use TFTP to download a
configuration file, based upon its serial number (this document configuration file, based upon its serial number (this document
modifies the solution to fetch an encrypted configuration file (ending i n modifies the solution to fetch an encrypted configuration file (ending i n
.enc)). It will then decrypt the configuration file, and install it.</t> .enc)). It will then decrypt the configuration file and install it.</t>
<section numbered="true" toc="default">
<t/> <name>Step 3.1: Fetch Encrypted Configuration File from Configuration
Server</name>
<section title="Step 3.1: Fetch encrypted configuration file from config <sourcecode name="" type=""><![CDATA[
uration server."> $ tftp 2001:0db8::23 -c get SN19842256.enc
<figure> ]]></sourcecode>
<artwork><![CDATA[$ tftp 2001:0db8::23 -c get SN19842256.enc
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Step 3.2: Decrypt and use the configuration. "> <name>Step 3.2: Decrypt and Use the Configuration</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork><![CDATA[$ openssl smime -decrypt -in SN19842256.enc -infor $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
m pkcs7\
-out config.cfg -inkey key.pem -out config.cfg -inkey key.pem
]]></artwork> ]]></sourcecode>
</figure>
<t>If an attacker does not have the correct key, they will not be <t>If an attacker does not have the correct key, they will not be
able to decrypt the configuration file:</t> able to decrypt the configuration file:</t>
<sourcecode name="" type=""><![CDATA[
<figure> $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
<artwork><![CDATA[$ openssl smime -decrypt -in SN19842256.enc -infor
m pkcs7\
-out config.cfg -inkey wrongkey.pem -out config.cfg -inkey wrongkey.pem
Error decrypting PKCS#7 structure Error decrypting PKCS#7 structure
140352450692760:error:06065064:digital envelope 140352450692760:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592: routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592:
$ echo $? $ echo $?
4]]></artwork> 4]]></sourcecode>
</figure>
</section> </section>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors wish to thank everyone who contributed, including
<contact fullname="Benoit Claise"/>, <contact fullname="Francis
Dupont"/>, <contact fullname="Mirja Kuehlewind"/>, <contact
fullname="Sam Ribeiro"/>, <contact fullname="Michael Richardson"/>,
<contact fullname="Sean Turner"/>, and <contact fullname="Kent
Watsen"/>. <contact fullname="Joe Clarke"/> also provided significant
comments and review, and <contact fullname="Tom Petch"/> provided
significant editorial contributions to better describe the use cases
and clarify the scope.</t>
<t><contact fullname="Roman Danyliw"/> and <contact fullname="Benjamin
Kaduk"/> also provided helpful text, especially around the certificate
usage and security considerations.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 140 change blocks. 
502 lines changed or deleted 399 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/