< draft-wkumari-opsawg-sdi-03.txt   draft-wkumari-opsawg-sdi-04.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: July 20, 2019 Juniper Networks Expires: December 14, 2019 Juniper Networks
January 16, 2019 June 12, 2019
Secure Device Install Secure Device Install
draft-wkumari-opsawg-sdi-03 draft-wkumari-opsawg-sdi-04
Abstract Abstract
Deploying a new network device often requires that an employee Deploying a new network device often requires that an employee
physically travel to a datacenter to perform the initial install and physically travel to a datacenter to perform the initial install and
configuration, even in shared datacenters with "smart-hands" type configuration, even in shared datacenters with "smart-hands" type
support. In many cases, this could be avoided if there were a support. In many cases, this could be avoided if there were a
standard, secure way to initially provision the devices. standard, secure way to initially provision the devices.
This document extends existing auto-install / Zero-Touch Provisioning This document extends existing auto-install / Zero-Touch Provisioning
to make the process more secure. mechanisms to make the process more secure.
[ 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 4
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 July 20, 2019. This Internet-Draft will expire on December 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 27 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Overview / Example Scenario . . . . . . . . . . . . . . . . . 4 2. Overview / Example Scenario . . . . . . . . . . . . . . . . . 4
3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5
3.1. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 5 3.1. Device key generation . . . . . . . . . . . . . . . . . . 5
3.2. Certificate Publication Server . . . . . . . . . . . . . 5 3.2. Certificate Publication Server . . . . . . . . . . . . . 5
3.3. Initial Device Boot . . . . . . . . . . . . . . . . . . . 5
3.4. Subsequent Boots . . . . . . . . . . . . . . . . . . . . 5
4. Operator Role / Responsibilities . . . . . . . . . . . . . . 6 4. Operator Role / Responsibilities . . . . . . . . . . . . . . 6
4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 6 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 6
4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Future enhancements / Discussion . . . . . . . . . . . . . . 6 4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 7
5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 6 5. Additional Considerations . . . . . . . . . . . . . . . . . . 9
5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 7 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 7 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 8 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 8 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 12
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 8 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13
B.1.2. Step 1.2: Generate the certificate signing request. . 9 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 13
B.1.2. Step 1.2: Generate the certificate signing request. . 13
B.1.3. Step 1.3: Generate the (self signed) certificate B.1.3. Step 1.3: Generate the (self signed) certificate
itself. . . . . . . . . . . . . . . . . . . . . . . . 9 itself. . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Step 2: Generating the encrypted config. . . . . . . . . 9 B.2. Step 2: Generating the encrypted config. . . . . . . . . 14
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 9 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14
B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 10 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14
B.2.3. Step 2.3: Copy config to the config server. . . . . . 10 B.2.3. Step 2.3: Copy config to the config server. . . . . . 14
B.3. Step 3: Decrypting and using the config. . . . . . . . . 10 B.3. Step 3: Decrypting and using the config. . . . . . . . . 14
B.3.1. Step 3.1: Fetch encrypted config file from config B.3.1. Step 3.1: Fetch encrypted config file from config
server. . . . . . . . . . . . . . . . . . . . . . . . 10 server. . . . . . . . . . . . . . . . . . . . . . . . 14
B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 10 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 simply deploying new devices and "forklift" upgrading are spent simply 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
datacenters (for example, Internet Exchange Points (IXP) or "carrier datacenters (for example, Internet Exchange Points (IXP) or "carrier
neutral datacenters"), which have staff on hand that can be neutral datacenters"), 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 vendor proprietary) protocols to perform initial number of (often vendor 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 to get an IP address and devices will attempt to use DHCP to get an IP address and
configuration server, and then fetch and install a configuration when configuration server, and then fetch and install a configuration when
they are first powered on. they are first powered on.
Network device configurations contain a significant amount of Network device configurations contain a significant amount of
security related and / or proprietary information (for example, security related and / or proprietary information (for example,
RADIUS or TACACS secrets). Exposing these to a third party to load RADIUS or TACACS+ secrets). Exposing these to a third party to load
onto a new device (or using an auto-install techniques which fetch an onto a new device (or using an auto-install techniques which fetch an
(unencrypted) config file via something like TFTP) is simply not (unencrypted) config file via something like TFTP) is simply not
acceptable to many operators, and so they have to send employees to acceptable to many operators, and so they have to send employees to
remote locations to perform the initial configuration work. As well remote locations to perform the initial configuration work. As well
as having a significant monetary cost, it also takes significantly as having a significant monetary cost, it also takes significantly
longer to install devices and is generally inefficient. longer to install devices and is generally inefficient.
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 devices before shipping it; asking the smart-hands to configure the devices before shipping it; asking the smart-hands 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; but these are often clumsy and have security configuration, etc; but these are often clumsy and have security
issues - for example, in the terminal server case, the console port issues - for example, in the terminal server case, the console port
connection could be easily snooped. connection could be easily snooped.
This document layers security onto existing auto-install solutions to This document layers security onto existing auto-install solutions to
provide a secure method to initially configure new devices. provide a secure method to initially configure new devices. It is
optimized for simplicity, both for the implementor and the operator;
it is explicitly not intended to be an "all singing, all dancing"
fully featured system for managing installed / deployed devices, nor
is it intended to solve all use-cases - rather it is a simple
targeted solution to solve a common operational issue. Solutions
such as Secure Zero Touch Provisioning (SZTP)" [RFC8572] are much
more fully featured, but also more complex to implement and / or are
not widely deployed yet.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overview / Example Scenario 2. Overview / Example Scenario
Sirius Cybernetics Corp needs another peering router, and so they Sirius Cybernetics Corp needs another peering router, and so they
order another router from Acme Network Widgets, to be drop-shipped to order another router from Acme Network Widgets, to be drop-shipped to
a POP. Acme begins assembling the new device, and tells Sirius what the Point of Presence (POP) / datacenter. Acme begins assembling the
the new device's serial number will be (SN:17894321). During the new device, and tells Sirius what the new device's serial number will
initial boot / testing, the router generates a public-private be (SN:17894321). When Acme first installs the firmware on the
keypair, and Acme publishes it on their keyserver (in a certificate, device and boots it, the device generates a public-private keypair,
for ease of use). and Acme publishes it on their keyserver (in a certificate, for ease
of use).
While Acme is shipping the new device, Sirius begins generating the While the device is being shipped, Sirius generates the initial
initial device configuration. Once the config is ready, Sirius device configuration, fetches the certificate from Acme keyservers by
contacts the Acme keyserver, provides the serial number of the new providing the serial number of the new device. Sirius then encrypts
device and fetches the device's public key. Sirius then encrypts the the device configuration and puts this encrypted config on a (local)
device configuration and puts this encrypted config on a (local) TFTP TFTP server.
server.
When the POP receives the new device, they install it in Sirius' When the device arrives at the POP, it gets installed in Sirius'
rack, and connect the cables as instructed. The new device powers up rack, and cabled as instructed. The new device powers up and
and discovers that it has not yet been configured. It enters its discovers that it has not yet been configured. It enters its
autoboot state, and begins DHCPing. Sirius' DHCP server provides it autoboot state, and begins the DHCP process. Sirius' DHCP server
with an IP address and the address of the configuration server. The provides it with an IP address and the address of the configuration
router uses TFTP to fetch a file named according to its serial number server. The router uses TFTP to fetch its config file (note that all
(acme_17894321.cfg). It then uses its private key to decrypt this this is existing functionality). The device attempts to load the
file, and, assuming it validates, installs the new configuration. config file - if the config file is unparsable, (new functionality)
the devies tries to uses its private key to decrypt the file, and,
assuming it validates, installs the new configuration.
Only the "correct" device will have the required private key and be Only the "correct" device will have the required private key and be
able to decrypt and use the config file (See Security able to decrypt and use the config file (See Security
Considerations). An attacker would be able to connect to the network Considerations). An attacker would be able to connect to the network
and get an IP address. They would also be able to retrieve and get an IP address. They would also be able to retrieve
(encrypted) config files by guessing serial numbers (or perhaps the (encrypted) config files by guessing serial numbers (or perhaps the
server would allow directory listing), but without the private keys server would allow directory listing), but without the private keys
an attacker will not be able to decrypt the files. an attacker will not be able to decrypt the files.
This document uses the serial number of the device as a unique
identifier for simplicity; some vendors may not want to implement the
system using the serial number as the identifier for business reasons
(a competitor or similar could enumerate the serial numbers and
determine how many devices have been manufactured). Implementors are
free to choose some other way of generating identifiers (e.g UUID
[RFC4122]), but this will likely make it somewhat harder for
operators to use (the serial number is usually easy to find on a
device, a more complex system is likely harder to track).
[ Ed note: This example uses TFTP because that is what many vendors [ Ed note: This example uses TFTP because that is what many vendors
use in their auto-install / ZTP feature. It could easily instead be use in their auto-install / ZTP feature. It could easily instead be
HTTP, FTP, etc. ] HTTP, FTP, etc. ]
3. Vendor Role / Requirements 3. Vendor Role / Requirements
This section describes the vendors roles and responsibilities and This section describes the vendors roles and responsibilities and
provides an overview of what the device needs to do. provides an overview of what the device needs to do.
3.1. CA Infrastructure 3.1. Device key generation
The vendor needs to run some (simple) CA infrastructure to sign and During the manufacturing stage, when the device is intially powered
publish certificates. When a device is initially powered on (in the on, it will generate a public-private keypair. It will send its
factory) it will generate a public / private keypair and a unique identifier and the public key to the vendor's Certificate
Certificate Signing Request (CSR), with the commonName being the Publication Server to be published. The mechanism used to do this is
Serial Number of the device. The device sends this CSR to the CA, left undefined. Note that some devices may be contrained, and so may
which signs the CSR, returns the certificate to the device and also send the raw public key and unique identifier to the certificate
sends it to a certificate publication server. publication server, while mode capable devices may generate and send
self-signed certifcates.
3.2. Certificate Publication Server 3.2. Certificate Publication Server
The certificate publication server contains a database of all signed The certificate publication server contains a database of
certificates. Customers (e.g Sirius Cybernetics Corp) query this certificates. If newly manufactured devices upload certificates the
server with a serial number, and retrieve the associated certificate. certificate publication server can simply publish these, if the
It is expected that operators will receive the serial numbers of devices provide raw public keys and unique identfiers the certificate
newly purchased devices when they purchase them, and that some publication server will need to wrap these in a certificate. Note
automated system will download and store / cache the certificate. that the certificat publication server MUST only accept certifcates
This means that there is not a hard requirement on the uptime / or keys from the vendor's manufacturing facilities.
reachability of the certificate publication server.
[ Ed: The vendor may not want to expose (for commercial reasons) how The customers (e.g Sirius Cybernetics Corp) query this server with
many devices it has made. This can be mitigated by using non- the serial number (or other provided unique identifier) of a device,
contiguous serial numbers, and simply creating "fake devices", etc. ] and retrieve the associated certificate. It is expected that
operators will receive the unique identifier (serial number) of
devices when they purchase them, and will download and store / cache
the certificate. This means that there is not a hard requirement on
the uptime / reachability of the certificate publication server.
3.3. Initial Device Boot +------------+
+------+ |Certificate |
|Device| |Publication |
+------+ | Server |
+------------+
+----------------+ +--------------+
| +---------+ | | |
| | Initial | | | |
| | boot? | | | |
| +----+----+ | | |
| | | | |
| +------v-----+ | | |
| | Generate | | | |
| |Self-signed | | | |
| |Certificate | | | |
| +------------+ | | |
| | | | +-------+ |
| +-------|---|-->|Receive| |
| | | +---+---+ |
| | | | |
| | | +---v---+ |
| | | |Publish| |
| | | +-------+ |
| | | |
+----------------+ +--------------+
When the device is powered on for the very first time, it will Initial certificate generation and publication.
generate its keypair. It then generates a CSR (including the device
serial number) and sends it to the vendor's CA, which signs the
certificate. The device receives the signed certificate and stores
it.
3.4. Subsequent Boots 4. Operator Role / Responsibilities
After the initial boot, it the device has no (valid) configuration 4.1. Administrative
file, it will perform standard an auto-install type functionality.
For example, it will perform DHCP Discovery until it gets a DHCP
offer including DHCP option 66 or 150. It will contact the server
listed in these DHCP options and download a configuration file named
config_<serial_number>.cfg. This is all existing (often vendor
proprietary) functionality.
After retrieving the config file, Secure Device Install devices will When purchasing a new device, the accounting department will need to
attempt to decrypt the configuration file using its private key. If get the unique device identifier (likely serial number) of the new
it is able to decrypt and validate the file it will install the device and communicate it to the operations group.
configuration, and start using it.
[ Ed note: SDI will also allows additional functionality, like always 4.2. Technical
storing the configs encrypted, having the device store its config
encrypted in flash (so that e.g RMAing a routing engine will not leak
config, etc. I'm not describing this in detail because:
1. I want to keep this document simple and focused and, more The operator will contact the vendor's publication server, and
importantly download the certificate (by providing the unique device identifier
of the device). The operator SHOULD fetch the certificate using a
secure transport (e.g HTTPS). The operator will then encrypt the
initial configuration to the key in the certifcate, and place it on
their TFTP server. See Appendix B for examples.
2. I left converting this into ID format until the draft cut-off and +------------+
have run out of time :-) ] +--------+ |Certificate |
|Operator| |Publication |
+--------+ | Server |
+------------+
+----------------+ +----------------+
| +-----------+ | | +-----------+ |
| | Fetch | | | | | |
| | Device |<------>|Certificate| |
| |Certificate| | | | | |
| +-----+-----+ | | +-----------+ |
| | | | |
| +-----v------+ | | |
| | Encrypt | | | |
| | Device | | | |
| | Config | | | |
| +-----+------+ | | |
| | | | |
| +-----v------+ | | |
| | Publish | | | |
| | TFTP | | | |
| | Server | | | |
| +------------+ | | |
| | | |
+----------------+ +----------------+
4. Operator Role / Responsibilities Fetching the certificate, encrypting the configuration, publishing
the encrypted configuration.
4.1. Administrative 4.3. Initial Customer Boot
When purchasing a new device, the accounting department will need to When the device is first booted by the customer (and on subsequent
get the serial number of the new device and communicate it to the boots), if the device has no valid configuration, it will use
operations group. existing auto-install type functionality - it performs DHCP Discovery
until it gets a DHCP offer including DHCP option 66 or 150, contact
the server listed in these DHCP options and download its config file.
4.2. Technical After retrieving the config file, the device will examine the file
and determine if it seems to be a valid config, and if so, proceeds
as it normally would. Note that this is existing functionality (for
example, Cisco devices fetch the config file named by the Bootfile-
Name DHCP option (67)).
The operator will contact the vendor's publication server, and If the file appears be "garbage", the device will attempt to decrypt
download the certificate (by providing the serial number of the the configuration file using its private key. If it is able to
device). They will then encrypt the initial configuration to that decrypt and validate the file it will install the configuration, and
key, and place it on the TFTP server, named config_<SN>.enc. See start using it. The exact method that the device uses to determine
Appendix B for examples. if a config file is "valid" is implementation specific, but a normal
config file looks significantly different to an encrypted blob.
5. Future enhancements / Discussion Note that the device only needs DHCP and to be able to download the
config file; after the initial power-on in the factory it never need
to access the Internet or vendor or certifcate publication server -
it (and only it) has the private key and so has the ability to
decrypt the config file.
[ Ed note: Ed / RFC Editor to remove this section before publication. +--------+ +--------------+
] | Device | |Config server |
+--------+ | (e.g TFTP) |
+--------------+
+---------------------------+ +------------------+
| +-----------+ | | |
| | | | | |
| | DHCP | | | |
| | | | | |
| +-----+-----+ | | |
| | | | |
| +-----v------+ | | +-----------+ |
| | | | | | Encrypted | |
| |Fetch config|<------------------>| config | |
| | | | | | file | |
| +-----+------+ | | +-----------+ |
| | | | |
| X | | |
| / \ | | |
| / \ Y +--------+ | | |
| |Sane?|---->|Install,| | | |
| \ / | Boot | | | |
| \ / +--------+ | | |
| V | | |
| |N | | |
| | | | |
| +-----v------+ | | |
| |Decrypt with| | | |
| |private key | | | |
| +-----+------+ | | |
| | | | |
| | +--------+ | | |
| | |Install,| | | |
| +------->| Boot | | | |
| +--------+ | | |
| | | |
| | | |
+---------------------------+ +------------------+
Device boot, fetch and install config file
5. Additional Considerations
5.1. Key storage 5.1. Key storage
Currently most network devices will store the private key in NV Ideally, the keypair would be stored in a TPM on something which is
storage (NVRAM / Flash / Disk), but some vendors are already planning identified as the "router" - for example, the chassis / backplane.
on including a TPM module in their devices. Ideally, the keypair This is so that a keypair is bound to what humans think of as the
would be stored in a TPM on something which is identified as the "device", and not, for example (redundant) routing engines. Devices
"router" - for example, the chassis / backplane. This is so that a which implement IEEE 802.1AR could choose to use the IDevID for this
keypair is bound to what humans think of as the "device", and not, purpose.
for example, (redundant) routing engines.
5.2. Key replacement 5.2. Key replacement
It is anticipated that some operator may want to replace the (vendor It is anticipated that some operator may want to replace the (vendor
provided) keys after installing the device. This would remove (some) provided) keys after installing the device. There are two options
concerns that the vendor may have kept a copy of the private key, or when implementing this - a vendor could allow the operator's key to
that the device may have been intercepted during shipping and the completely replace the initial device generated key (which means
private key duplicated. This would also allow for the use of that, if the device is ever sold, the new owner couldn't use this
certificates signed by the operator's CA (e.g using RFC7030 - technique to install the device), or the device could prefer the
Enrollment over Secure Transport) this is a trivial operation, but is operators installed key. This is an implementation decision left to
not described here (to avoid cluttering up the doc). the vendor.
5.3. Device reinstall 5.3. Device reinstall
Increasingly, operations is moving towards an automated model of Increasingly, operations is moving towards an automated model of
device management, whereby portions (or the entire) configuration is device management, whereby portions (or the entire) configuration is
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 too vendor It is expected (but not defined in this document, as it is vendor
specific) that vendors will allow the operator to e.g scp a new, specific) that vendors will allow the operator to copy a new,
encrypted config (or part of a config) onto a device and then request encrypted config (or part of a config) onto a device and then request
that the device decrypt and install it (e.g: 'load replace <filename> that the device decrypt and install it (e.g: 'load replace <filename>
encrypted)). encrypted)). The operator could also choose to reset the device to
factory defaults, and allow the device to act as though it were the
initial boot (see Section 4.3).
6. IANA Considerations 6. IANA Considerations
This document contains no IANA considerations.Template: Fill this in! This document makes no requests of the IANA.
7. Security Considerations 7. Security Considerations
This needs to be completed, including: This mechanism is intended to replace either expensive (traveling
employees) or insecure mechanisms of installing newly deployed
devices such as: unencrypted config files which can be downloaded by
connecting to unprotected ports in datacenters, mailing initial
config files on flash drives, or emailing config files and asking a
third-party to copy and paste it over a serial terminal. It does not
protect against devices with malicious firmware, nor theft and reuse
of devices.
1. We are trusting the vendor to have not kept a copy of the private An attacker (e.g a malicious datacenter employee) who has physical
key when the device initially generated its keypair. access to the device before it is connected to the network the
Unfortunately you are already trusting the vendor in many ways - attacker may be able to extract the device private key (especially if
it could have included a backdoor in it's code, etc. it isn't stored in a TPM), pretend to be the device when connecting
to the network, and download and extract the (encrypted) config file.
2. Devices should be storing their keying information in something This mechanism does not protect against a malicious vendor - while
like a TPM, to help mitigate the private key being extracted (e.g the keypair should be generated on the device, and the private key
read off disk) in shipping, when the device is first unpacked by should be securely stored, the mechanism cannot detect or protect
smart-hands, etc). A number of vendors already include a TPM for against a vendor who claims to do this, but instead generates the
other security functions. keypair off device and keeps a copy of the private key. It is
largely understood in the operator community that a malicious vendor
or attacker with physical access to the device is largely a "Game
Over" situation.
Even when using a secure bootstrapping mechanism, security conscious
operators may wish to bootstrapping devices with a minimal / less
sensitive config, and then replace this with a more complete one
after install.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank some folk, including Benoit Claise, Colin The authors wish to thank everyone who contributed, including Benoit
Doyle, Sam Ribeiro, and Sean Turner. Claise, Sam Ribeiro, Michael Richardson, Sean Turner and Kent Watsen.
Joe Clarke provided significant comments and review.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-sidr-iana-objects] [I-D.ietf-sidr-iana-objects]
Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects
issued by IANA", draft-ietf-sidr-iana-objects-03 (work in issued by IANA", draft-ietf-sidr-iana-objects-03 (work in
progress), May 2011. progress), May 2011.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<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 -00 to -01 From -00 to -01
o Nothing changed in the template! o Nothing changed in the template!
From -01 to -03:
o See github commit log (AKA, we forgot to update this!)
o Added Colin Doyle.
From -03 to -04:
Addressed a number of comments received before / at IETF104 (Prague).
These include:
o Pointer to https://datatracker.ietf.org/doc/draft-ietf-netconf-
zerotouch -- included reference to (now) RFC8572 (KW)
o Suggested that 802.1AR IDevID (or similar) could be used. Stress
that this is designed for simplicity (MR)
o Added text to explain that any unique device identifier can be
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).
o Lots of clarifications from Joe Clarke.
o Make it clear it should first try use the config, and if it
doesn't work, then try decrypt and use it.
o The CA part was confusing people - the certificate is simply a
wrapper for the key, and the Subject just an index, and so removed
that.
o Added a bunch of ASCII diagrams
Appendix B. Demo / proof of concept Appendix B. Demo / proof of concept
This section contains a rough demo / proof of concept of the system. This section contains a rough demo / proof of concept of the system.
It is only intended for illustration; presumably things like It is only intended for illustration; presumably things like
algorithms, key lengths, format / containers will provide much fodder algorithms, key lengths, format / containers will provide much fodder
for discussion. for discussion.
It uses OpenSSL from the command line, in production something more It uses OpenSSL from the command line, in production something more
automated would be used. In this example, the serial number of the automated would be used. In this example, the unique identifier is
router is SN19842256. 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
csr, and then a self signed certificate. csr, and then a self signed 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 genrsa -out key.pem 2048
Generating RSA private key, 2048 bit long modulus Generating RSA private key, 2048 bit long modulus
 End of changes. 46 change blocks. 
144 lines changed or deleted 317 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/