< draft-ietf-opsawg-sdi-11.txt   draft-ietf-opsawg-sdi-12.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational C. Doyle Intended status: Informational C. Doyle
Expires: November 21, 2020 Juniper Networks Expires: December 10, 2020 Juniper Networks
May 20, 2020 June 08, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-11 draft-ietf-opsawg-sdi-12
Abstract Abstract
Deploying a new network device in a location where the operator has Deploying a new network device in a location where the operator has
no staff of its own often requires that an employee physically travel no staff of its own often requires that an employee physically travel
to the location to perform the initial install and configuration, to the location to perform the initial install and configuration,
even in shared facilities with "remote-hands" type support. In many even in shared facilities with "remote-hands" type support. In many
cases, this could be avoided if there were a secure way to initially cases, this could be avoided if there were an easy way to transfer
provision the device. the initial configuration to a new device, while still maintaining
confidentiality of the configuration.
This document extends existing vendor proprietary auto-install to This document extends existing vendor proprietary auto-install to
make the process more secure. provide confidentiality to initial configuration during bootstrapping
of the device.
[ Ed note: Text inside square brackets ([]) is additional background [ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings, information, answers to frequently asked questions, general musings,
etc. They will be removed before publication. This document is etc. They will be removed before publication. This document is
being collaborated on in Github at: https://github.com/wkumari/draft- being collaborated on in Github at: https://github.com/wkumari/draft-
wkumari-opsawg-sdi. The most recent version of the document, open wkumari-opsawg-sdi. The most recent version of the document, open
issues, etc should all be available here. The authors (gratefully) issues, etc should all be available here. The authors (gratefully)
accept pull requests. ] accept pull requests. ]
[ Ed note: This document introduces concepts and serves as the basic [ Ed note: This document introduces concepts and serves as the basic
skipping to change at page 2, line 4 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2020.
This Internet-Draft will expire on December 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 31
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5 2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5
3. Vendor Role . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Vendor Role . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Device key generation . . . . . . . . . . . . . . . . . . 6 3.1. Device key generation . . . . . . . . . . . . . . . . . . 6
3.2. Certificate Publication Server . . . . . . . . . . . . . 6 3.2. Directory Server . . . . . . . . . . . . . . . . . . . . 7
4. Operator Role . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Operator Role . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 8
4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Example Initial Customer Boot . . . . . . . . . . . . . . 8 4.3. Example Initial Customer Boot . . . . . . . . . . . . . . 9
5. Additional Considerations . . . . . . . . . . . . . . . . . . 11 5. Additional Considerations . . . . . . . . . . . . . . . . . . 12
5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 12
5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 15
Appendix B. Proof of Concept . . . . . . . . . . . . . . . . . . 16 Appendix B. Proof of Concept . . . . . . . . . . . . . . . . . . 17
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 17
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 17
B.1.2. Step 1.2: Generate the certificate signing request. . 16 B.1.2. Step 1.2: Generate the certificate signing request. . 17
B.1.3. Step 1.3: Generate the (self signed) certificate B.1.3. Step 1.3: Generate the (self signed) certificate
itself. . . . . . . . . . . . . . . . . . . . . . . . 17 itself. . . . . . . . . . . . . . . . . . . . . . . . 17
B.2. Step 2: Generating the encrypted configuration. . . . . . 17 B.2. Step 2: Generating the encrypted configuration. . . . . . 18
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 18
B.2.2. Step 2.2: Encrypt the configuration file. . . . . . . 17 B.2.2. Step 2.2: Encrypt the configuration file. . . . . . . 18
B.2.3. Step 2.3: Copy configuration to the configuration B.2.3. Step 2.3: Copy configuration to the configuration
server. . . . . . . . . . . . . . . . . . . . . . . . 17 server. . . . . . . . . . . . . . . . . . . . . . . . 18
B.3. Step 3: Decrypting and using the configuration. . . . . . 17 B.3. Step 3: Decrypting and using the configuration. . . . . . 18
B.3.1. Step 3.1: Fetch encrypted configuration file from B.3.1. Step 3.1: Fetch encrypted configuration file from
configuration server. . . . . . . . . . . . . . . . . 18 configuration server. . . . . . . . . . . . . . . . . 19
B.3.2. Step 3.2: Decrypt and use the configuration. . . . . 18 B.3.2. Step 3.2: Decrypt and use the configuration. . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
In a growing, global network, significant amounts of time and money In a growing, global network, significant amounts of time and money
are spent deploying new devices and "forklift" upgrading existing are spent deploying new devices and "forklift" upgrading existing
devices. In many cases, these devices are in shared facilities (for devices. In many cases, these devices are in shared facilities (for
example, Internet Exchange Points (IXP) or "carrier-neutral example, Internet Exchange Points (IXP) or "carrier-neutral
datacenters"), which have staff on hand that can be contracted to datacenters"), which have staff on hand that can be contracted to
perform tasks including physical installs, device reboots, loading perform tasks including physical installs, device reboots, loading
initial configurations, etc. There are also a number of (often initial configurations, etc. There are also a number of (often
proprietary) protocols to perform initial device installs and proprietary) protocols to perform initial device installs and
configurations. For example, many network devices will attempt to configurations. For example, many network devices will attempt to
use DHCP [RFC2131] to get an IP address and configuration server, and use DHCP [RFC2131] or DHCPv6 [RFC8415] to get an IP address and
then fetch and install a configuration when they are first powered configuration server, and then fetch and install a configuration when
on. they are first powered on.
The configurations of network devices contain a significant amount of 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
[RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing
these to a third party to load onto a new device (or using an auto- these to a third party to load onto a new device (or using an auto-
install technique which fetches an unencrypted configuration file via install technique which fetches an unencrypted configuration file via
TFTP [RFC1350]) or something similar is an unacceptable security risk TFTP [RFC1350]) or something similar is an unacceptable security risk
for many operators, and so they send employees to remote locations to for many operators, and so they send employees to remote locations to
perform the initial configuration work; this costs time and money. perform the initial configuration work; this costs time and money.
There are some workarounds to this, such as asking the vendor to pre- There are some workarounds to this, such as asking the vendor to pre-
configure 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 configuration, etc. However, these are often clumsy and have
security issues. As an example, in the terminal server case, the security issues. As an example, in the terminal server case, the
console port connection could be easily snooped. console port connection could be easily snooped.
This document layers security onto existing auto-install solutions An ideal solution in this space would protect both the
(one example of which is [Cisco_AutoInstall]) to provide a secure confidentiality of device configuration in transit and the
method to initially configure new devices. It is optimized for authenticity (and authorization status) of configuration to be used
simplicity, for both the implementor and the operator; it is by the device. The mechanism described in this document only
explicitly not intended to be a fully featured system for managing addresses the former, and makes no effort to do the latter, with the
installed devices, nor is it intended to solve all use cases: rather device accepting any configuration file that comes its way and is
it is a simple targeted solution to solve a common operational issue encrypted to the device's key (or not encrypted, as the case may be).
where the network device has been delivered, fibre laid (as Other solutions (such as "Secure Zero Touch Provisioning (SZTP)"
appropriate) but there is no trusted member of the operator's staff [RFC8572], [I-D.ietf-anima-bootstrapping-keyinfra] and other voucher-
to perform the initial configuration. This solution is only intended based methods) are more fully featured, but also require more
to increase confidentiality of the information in the configuration complicated machinery. This document describes something much
file, not to protect the device itself. simpler, at the cost of only providing limited protection.
Solutions such as "Secure Zero Touch Provisioning (SZTP)" [RFC8572], This document layers security onto existing auto-install solutions
[I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more (one example of which is [Cisco_AutoInstall]) to provide a method to
fully featured, but also more complex to implement and are not widely initially configure new devices while maintaining confidentiality of
deployed yet. In addition, work in the IETF "Software Updates for the initial configuration. It is optimized for simplicity, for both
Internet of Things (suit)" WG is expected to provide mechanisms for the implementor and the operator; it is explicitly not intended to be
firmware updates, and are out of scope for this document. a fully featured system for managing installed devices, nor is it
intended to solve all use cases: rather it is a simple targeted
solution to solve a common operational issue where the network device
has been delivered, fibre laid (as appropriate) and there is no
trusted member of the operator's staff to perform the initial
configuration. This solution is only intended to increase
confidentiality of the information in the configuration file, and
does not protect the device itself from loading a malicious
configuration.
This document describes a concept, and some example ways of This document describes a concept, and some example ways of
implementing this concept. As devices have different capabilities, implementing this concept. As devices have different capabilities,
and use different configuration paradigms, one method will not suit and use different configuration paradigms, one method will not suit
all, and so it is expected that vendors will differ in exactly how all, and so it is expected that vendors will differ in exactly how
they implement this. they implement this.
This solution is specifically designed to be a simple method on top 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
skipping to change at page 4, line 42 skipping to change at page 5, line 5
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. use for network devices, such as routers and switches.
2. Overview 2. Overview
Most network devices already include some sort of initial Most network devices already include some sort of initial
bootstrapping logic (sometimes called 'autoboot', or 'autoinstall'). bootstrapping logic (sometimes called 'autoboot', or 'autoinstall').
This generally works by having a newly installed, unconfigured device This generally works by having a newly installed, unconfigured device
obtain an IP address for itself and discover the address of a obtain an IP address for itself and discover the address of a
configuration server (often called 'next-server', 'siaddr' or 'tftp- configuration server (often called 'next-server', 'siaddr' or 'tftp-
server-name') using DHCP (see [RFC2131]). The device then contacts server-name') using DHCP or DHXPv6 (see [RFC2131], [RFC8415]). The
this configuration server to download its initial configuration, device then contacts this configuration server to download its
which is often identified using the device's serial number, MAC initial configuration, which is often identified using the device's
address or similar. This document extends this (vendor-specific) serial number, MAC address or similar. This document extends this
paradigm by allowing the configuration file to be encrypted. (vendor-specific) paradigm by allowing the configuration file to be
encrypted.
This document uses the serial number of the device as a unique device 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 system using the serial number as the identifier for business reasons
(a competitor or similar could enumerate the serial numbers and (a competitor or similar could enumerate the serial numbers and
determine how many devices have been manufactured). Implementors are determine how many devices have been manufactured). Implementors are
free to choose some other way of generating identifiers (e.g., UUID free to choose some other way of generating identifiers (e.g., UUID
[RFC4122]), but this will likely make it somewhat harder for [RFC4122]), but this will likely make it somewhat harder for
operators to use (the serial number is usually easy to find on a operators to use (the serial number is usually easy to find on a
device, a more complex system is likely harder to track). device).
[ Ed note: This example also uses TFTP because that is what many [ Ed note: This example also uses TFTP because that is what many
vendors use in their auto-install feature. It could easily instead vendors use in their auto-install feature. It could easily instead
be HTTP, FTP, etc. ] be HTTP, FTP, etc. ]
2.1. Example Scenario 2.1. Example Scenario
Operator_A needs another peering router, and so they order another Operator_A needs another peering router, and so they order another
router from Vendor_B, to be drop-shipped to the facility. Vendor_B router from Vendor_B, to be drop-shipped to the facility. Vendor_B
begins assembling the new device, and tells Operator_A what the new begins assembling the new device, and tells Operator_A what the new
skipping to change at page 6, line 17 skipping to change at page 6, line 27
This section describes the vendor's roles and provides an overview of This section describes the vendor's roles and provides an overview of
what the device needs to do. what the device needs to do.
3.1. Device key generation 3.1. Device key generation
Each device requires a public-private key pair, and for the public Each device requires a public-private key pair, and for the public
part to be published and retrievable by the operator. The part to be published and retrievable by the operator. The
cryptographic algorithm and key lengths to be used are out of the cryptographic algorithm and key lengths to be used are out of the
scope of this document. This section illustrates one method, but, as scope of this document. This section illustrates one method, but, as
with much of this document the exact mechanism may vary by vendor. with much of this document the exact mechanism may vary by vendor.
Enrollment over Secure Transport ([RFC7030]) and [I-D.gutmann-scep] Enrollment over Secure Transport ([RFC7030]) or possibly
are methods which vendors may want to consider. [I-D.gutmann-scep] are methods which vendors may want to consider.
During the manufacturing stage, when the device is initially powered During the manufacturing stage, when the device is initially powered
on, it will generate a public-private key pair. It will send its on, it will generate a public-private key pair. It will send its
unique device identifier and the public key to the vendor's unique device identifier and the public key to the vendor's directory
Certificate Publication Server to be published. The vendor's server to be published. The vendor's directory server should only
Certificate Publication Server should only accept certificates from accept certificates from the manufacturing facility, and which match
the manufacturing facility, and which match vendor defined policies vendor defined policies (for example, extended key usage, and
(for example, extended key usage, and extensions) Note that some extensions) Note that some devices may be constrained, and so may
devices may be constrained, and so may send the raw public key and send the raw public key and unique device identifier to the
unique device identifier to the certificate publication server, while certificate publication server, while more capable devices may
more capable devices may generate and send self-signed certificates. generate and send self-signed certificates. This communication with
the directory server should be integrity protected, and in a
controlled environment.
This reference architecture needs a serialization format for the key This reference architecture needs a serialization format for the key
material. Due to the prevalence of tooling support for it on network material. Due to the prevalence of tooling support for it on network
devices, X.509 certificates are a convenient format to exchange devices, X.509 certificates are a convenient format to exchange
public keys. However, most of the meta-data that would use for public keys. However, most of the meta-data that would use for
revocation and aging will not be used and should be ignored by both revocation and aging will not be used and should be ignored by both
the client and server. 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).
3.2. Certificate Publication Server 3.2. Directory Server
The certificate publication server contains a database of The directory server contains a database of certificates. If newly
certificates. If newly manufactured devices upload certificates the manufactured devices upload certificates the directory server can
certificate publication server can simply publish these; if the simply publish these; if the devices provide the raw public keys and
devices provide the raw public keys and unique device identifier, the unique device identifier, the directory server will need to wrap
certificate publication server will need to wrap these in a these in a certificate.
certificate.
The customers (e.g., Operator_A) query this server with the serial The customers (e.g., Operator_A) query this server with the serial
number (or other provided unique identifier) of a device, and number (or other provided unique identifier) of a device, and
retrieve the associated certificate. It is expected that operators retrieve the associated certificate. It is expected that operators
will receive the unique device identifier (serial number) of devices will receive the unique device identifier (serial number) of devices
when they purchase them, and will download and store the certificate. when they purchase them, and will download and store the certificate.
This means that there is not a hard requirement on the reachability This means that there is not a hard requirement on the reachability
of the certificate publication server. of the directory server.
+------------+ +------------+
+------+ |Certificate | +------+ | |
|Device| |Publication | |Device| | Directory |
+------+ | Server | +------+ | Server |
+------------+ +------------+
+----------------+ +--------------+ +----------------+ +--------------+
| +---------+ | | | | +---------+ | | |
| | Initial | | | | | | Initial | | | |
| | boot? | | | | | | boot? | | | |
| +----+----+ | | | | +----+----+ | | |
| | | | | | | | | |
| +------v-----+ | | | | +------v-----+ | | |
| | Generate | | | | | | Generate | | | |
skipping to change at page 7, line 49 skipping to change at page 8, line 18
When purchasing a new device, the accounting department will need to When purchasing a new device, the accounting department will need to
get the unique device identifier (e.g., serial number) of the new get the unique device identifier (e.g., serial number) of the new
device and communicate it to the operations group. device and communicate it to the operations group.
4.2. Technical 4.2. Technical
The operator will contact the vendor's publication server, and The operator will contact the vendor's publication server, and
download the certificate (by providing the unique device identifier download the certificate (by providing the unique device identifier
of the device). The operator fetches the certificate using a secure of the device). The operator fetches the certificate using a secure
transport (e.g., HTTPS). The operator will then encrypt the initial transport that authenticates the source of the certificate, such as
HTTPS (confidentiality protection can provide some privacy and
metadata-leakage benefit, but is not key to the primary mechanism of
this document). The operator will then encrypt the initial
configuration (for example, using SMIME [RFC5751]) using the key in configuration (for example, using SMIME [RFC5751]) using the key in
the certificate, and place it on their configuration server. the certificate, and place it on their configuration server.
See Appendix B for examples. See Appendix B for examples.
+------------+ +------------+
+--------+ |Certificate | +--------+ | |
|Operator| |Publication | |Operator| | Directory |
+--------+ | Server | +--------+ | Server |
+------------+ +------------+
+----------------+ +----------------+ +----------------+ +----------------+
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | Fetch | | | | | | | | Fetch | | | | | |
| | Device |<------>|Certificate| | | | Device |<------>|Certificate| |
| |Certificate| | | | | | | |Certificate| | | | | |
| +-----+-----+ | | +-----------+ | | +-----+-----+ | | +-----------+ |
| | | | | | | | | |
| +-----v------+ | | | | +-----v------+ | | |
| | Encrypt | | | | | | Encrypt | | | |
skipping to change at page 9, line 21 skipping to change at page 10, line 19
process, or repeat this process until it succeeds. When retrying, process, or repeat this process until it succeeds. When retrying,
care should be taken to not overwhelm the server hosting the care should be taken to not overwhelm the server hosting the
encrypted configuration files. It is suggested that the device retry encrypted configuration files. It is suggested that the device retry
every 5 minutes for the first hour, and then every hour after that. 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 As it is expected that devices may be installed well before the
configuration file is ready, a maximum number of retries is not configuration file is ready, a maximum number of retries is not
specified. specified.
Note that the device only needs to be able to download the Note that the device only needs to be able to download the
configuration file; after the initial power-on in the factory it configuration file; after the initial power-on in the factory it
never needs to access the Internet or vendor or certificate never needs to access the Internet or vendor or directory server.
publication server. The device (and only the device) has the private The device (and only the device) has the private key and so has the
key and so has the ability to decrypt the configuration file. ability to decrypt the configuration file.
+--------+ +--------------+ +--------+ +--------------+
| Device | |Config server | | Device | |Config server |
+--------+ | (e.g. TFTP) | +--------+ | (e.g. TFTP) |
+--------------+ +--------------+
+---------------------------+ +------------------+ +---------------------------+ +------------------+
| +-----------+ | | | | +-----------+ | | |
| | | | | | | | | | | |
| | DHCP | | | | | | DHCP | | | |
| | | | | | | | | | | |
skipping to change at page 12, line 19 skipping to change at page 13, line 19
confidentiality assurances for the configuration while it is in confidentiality assurances for the configuration while it is in
transit between the configuration server and the unprovisioned device transit between the configuration server and the unprovisioned device
even if the underly transport does not provide this security service. even if the underly transport does not provide this security service.
The architecture provides no assurances about the source of the The architecture provides no assurances about the source of the
encrypted configuration or protect against theft and reuse of encrypted configuration or protect against theft and reuse of
devices. devices.
An attacker (e.g., a malicious datacenter employee, person in the An attacker (e.g., a malicious datacenter employee, person in the
supply chain, etc.) who has physical access to the device before it supply chain, etc.) who has physical access to the device before it
is connected to the network may be able to extract the device private is connected to the network, or who manages to exploit it once
key (especially if it is not stored in a TPM), pretend to be the installed, may be able to extract the device private key (especially
device when connecting to the network, and download and extract the if it is not stored in a TPM), pretend to be the device when
(encrypted) configuration file. connecting to the network, and download and extract the (encrypted)
configuration file.
An attacker with access to the configuration server (or the ability An attacker with access to the configuration server (or the ability
to route traffic to configuration server under their control) and the to route traffic to configuration server under their control) and the
device's public key could return a configuration of the attacker's device's public key could return a configuration of the attacker's
choosing to the unprovisioned device. choosing to the unprovisioned device.
This mechanism does not protect against a malicious vendor. While 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 key against a vendor who claims to do this, but instead generates the key
skipping to change at page 13, line 5 skipping to change at page 14, line 5
8. Acknowledgments 8. Acknowledgments
The authors wish to thank everyone who contributed, including Benoit The authors wish to thank everyone who contributed, including Benoit
Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael
Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided
significant comments and review, and Tom Petch provided significant significant comments and review, and Tom Petch provided significant
editorial contributions to better describe the use cases, and clarify editorial contributions to better describe the use cases, and clarify
the scope. the scope.
Roman Danyliw also provided helpful text around the certificate Roman Danyliw and Benjamin Kaduk also provided helpful text,
usage. especially around the certificate usage and security considerations.
9. Informative References 9. Informative References
[Cisco_AutoInstall] [Cisco_AutoInstall]
Cisco Systems, Inc., "Using AutoInstall to Remotely Cisco Systems, Inc., "Using AutoInstall to Remotely
Configure Cisco Networking Devices", Jan 2018, Configure Cisco Networking Devices", Jan 2018,
<https://www.cisco.com/c/en/us/td/docs/ios- <https://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/fundamentals/configuration/15mt/fundamentals-15- xml/ios/fundamentals/configuration/15mt/fundamentals-15-
mt-book/cf-autoinstall.html>. mt-book/cf-autoinstall.html>.
skipping to change at page 14, line 20 skipping to change at page 15, line 20
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
From -09 to -10 From -09 to -10
skipping to change at page 16, line 29 skipping to change at page 17, line 32
identifier is the serial number of the router, SN19842256. identifier is the serial number of the router, SN19842256.
B.1. Step 1: Generating the certificate. B.1. Step 1: Generating the certificate.
This step is performed by the router. It generates a key, then a This step is performed by the router. It generates a key, then a
Certificate Signing Request (CSR), and then a self signed Certificate Signing Request (CSR), and then a self signed
certificate. certificate.
B.1.1. Step 1.1: Generate the private key. B.1.1. Step 1.1: Generate the private key.
$ openssl genrsa -out key.pem 2048 $ openssl ecparam -out privatekey.key -name prime256v1 -genkey
Generating RSA private key, 2048 bit long modulus $
.................................................
.................................................
..........................+++
...................+++
e is 65537 (0x10001)
B.1.2. Step 1.2: Generate the certificate signing request. B.1.2. Step 1.2: Generate the certificate signing request.
$ openssl req -new -key key.pem -out SN19842256.csr $ openssl req -new -key key.pem -out SN19842256.csr
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:SN19842256 Common Name (e.g. server FQDN or YOUR name) []:SN19842256
Email Address []:.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:.
B.1.3. Step 1.3: Generate the (self signed) certificate itself. B.1.3. Step 1.3: Generate the (self signed) certificate itself.
$ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out
SN19842256.crt SN19842256.crt
The router then sends the key to the vendor's keyserver for The router then sends the key to the vendor's keyserver for
publication (not shown). publication (not shown).
B.2. Step 2: Generating the encrypted configuration. B.2. Step 2: Generating the encrypted configuration.
skipping to change at page 17, line 32 skipping to change at page 18, line 24
B.2.1. Step 2.1: Fetch the certificate. B.2.1. Step 2.1: Fetch the certificate.
$ wget http://keyserv.example.net/certificates/SN19842256.crt $ wget http://keyserv.example.net/certificates/SN19842256.crt
B.2.2. Step 2.2: Encrypt the configuration file. B.2.2. Step 2.2: Encrypt the configuration file.
S/MIME is used here because it is simple to demonstrate. This is S/MIME is used here because it is simple to demonstrate. This is
almost definitely not the best way to do this. almost definitely not the best way to do this.
$ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\ $ openssl smime -encrypt -aes-256-cbc -in SN19842256.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-----
B.2.3. Step 2.3: Copy configuration to the configuration server. B.2.3. Step 2.3: Copy configuration to the configuration server.
skipping to change at page 18, line 16 skipping to change at page 19, line 13
install it. install it.
B.3.1. Step 3.1: Fetch encrypted configuration file from configuration B.3.1. Step 3.1: Fetch encrypted configuration file from configuration
server. server.
$ tftp 2001:0db8::23 -c get SN19842256.enc $ tftp 2001:0db8::23 -c get SN19842256.enc
B.3.2. Step 3.2: Decrypt and use the configuration. B.3.2. Step 3.2: Decrypt and use the configuration.
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
-out config.cfg -inkey key.pem -out config.cfg -inkey key.pem
If an attacker does not have the correct key, they will not be able If an attacker does not have the correct key, they will not be able
to decrypt the configuration file: to decrypt the configuration file:
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ $ openssl smime -decrypt -in SN19842256.enc -inform 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 4
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
 End of changes. 34 change blocks. 
116 lines changed or deleted 125 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/