< draft-ietf-opsawg-sdi-03.txt   draft-ietf-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: August 14, 2020 Juniper Networks Expires: September 5, 2020 Juniper Networks
February 11, 2020 March 04, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-03 draft-ietf-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
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 August 14, 2020. This Internet-Draft will expire on September 5, 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 26 skipping to change at page 2, line 26
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 4 2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5
3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 6
3.1. Device key generation . . . . . . . . . . . . . . . . . . 5 3.1. Device key generation . . . . . . . . . . . . . . . . . . 6
3.2. Certificate Publication Server . . . . . . . . . . . . . 6 3.2. Certificate Publication Server . . . . . . . . . . . . . 6
4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7 4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7
4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7
4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 8 4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 8
5. Additional Considerations . . . . . . . . . . . . . . . . . . 10 5. Additional Considerations . . . . . . . . . . . . . . . . . . 11
5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11
5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 13
Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 13 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 14
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 14
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 13 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 14
B.1.2. Step 1.2: Generate the certificate signing request. . 14 B.1.2. Step 1.2: Generate the certificate signing request. . 15
B.1.3. Step 1.3: Generate the (self signed) certificate B.1.3. Step 1.3: Generate the (self signed) certificate
itself. . . . . . . . . . . . . . . . . . . . . . . . 14 itself. . . . . . . . . . . . . . . . . . . . . . . . 15
B.2. Step 2: Generating the encrypted config. . . . . . . . . 14 B.2. Step 2: Generating the encrypted config. . . . . . . . . 15
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 15
B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 16
B.2.3. Step 2.3: Copy config to the config server. . . . . . 15 B.2.3. Step 2.3: Copy config to the config server. . . . . . 16
B.3. Step 3: Decrypting and using the config. . . . . . . . . 15 B.3. Step 3: Decrypting and using the config. . . . . . . . . 16
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. . . . . . . . . . . . . . . . . . . . . . . . 15 server. . . . . . . . . . . . . . . . . . . . . . . . 16
B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 4, line 9 skipping to change at page 4, line 9
provide a secure method to initially configure new devices. It is provide a secure method to initially configure new devices. It is
optimized for simplicity, both for the implementor and the operator; optimized for simplicity, both for the implementor and the operator;
it is explicitly not intended to be an "all singing, all dancing" it is explicitly not intended to be an "all singing, all dancing"
fully featured system for managing installed / deployed devices, nor fully featured system for managing installed / deployed devices, nor
is it intended to solve all use-cases - rather it is a simple is it intended to solve all use-cases - rather it is a simple
targeted solution to solve a common operational issue. Solutions targeted solution to solve a common operational issue. Solutions
such as Secure Zero Touch Provisioning (SZTP)" [RFC8572] are much such as Secure Zero Touch Provisioning (SZTP)" [RFC8572] are much
more fully featured, but also more complex to implement and / or are more fully featured, but also more complex to implement and / or are
not widely deployed yet. not widely deployed yet.
This solution is specifically designed to be a simple method on top
of exiting device functionality. If devices do not support this new
method, they can continue to use the existing functionality. In
addition, operators can choose to use this to protect their
configuration information, or can continue to use the existing
functionality.
The issue of securely installing devices is in no way a new issue,
nor is it limited to network devices; it occurs when deploying
servers, PCs, IoT devices, and in many other situations. While the
solution described in this document is obvious (encrypt the config,
then decrypt it with a device key), this document only discusses the
use for network devices, such as routers and switches.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview 2. Overview
skipping to change at page 4, line 30 skipping to change at page 4, line 44
bootstrapping logic (sometimes called 'autoboot', or 'autoinstall'). bootstrapping logic (sometimes called 'autoboot', or 'autoinstall').
This generally works by having a newly installed / unconfigured This generally works by having a newly installed / unconfigured
device obtain an IP address and address of a config server (often device obtain an IP address and address of a config server (often
called 'next-server', 'siaddr' or 'tftp-server-name') using DHCP. called 'next-server', 'siaddr' or 'tftp-server-name') using DHCP.
The device then contacts this configuration server to download its The device then contacts this configuration server to download its
initial configuration, which is often identified using the devices initial configuration, which is often identified using the devices
serial number, MAC address or similar. This document extends this serial number, MAC address or similar. This document extends this
(vendor specific) paradigm by allowing the configuration file to be (vendor specific) paradigm by allowing the configuration file to be
encrypted. encrypted.
This document describes a concept, and some example ways of
implementing this concept. As devices have different capabilities,
and use different configuration paradigms, one method will not suit
all, and so it is expected that vendors will differ in exactly how
they implement this.
This document uses the serial number of the device as a unique This document uses the serial number of the device as a unique
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, a more complex system is likely harder to track).
skipping to change at page 8, line 8 skipping to change at page 8, line 37
| +------------+ | | | | +------------+ | | |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
Fetching the certificate, encrypting the configuration, publishing Fetching the certificate, encrypting the configuration, publishing
the encrypted configuration. the encrypted configuration.
4.3. Initial Customer Boot 4.3. Initial Customer Boot
When the device is first booted by the customer (and on subsequent When the device is first booted by the customer (and on subsequent
boots), if the device has no valid configuration, it will use boots), if the device does not have a valid configuration, it will
existing auto-install type functionality - it performs DHCP Discovery use existing auto-install functionality. As an example, it performs
until it gets a DHCP offer including DHCP option 66 or 150, contact DHCP Discovery until it gets a DHCP offer including DHCP option 66 or
the server listed in these DHCP options and download its config file. 150, contact the server listed in these DHCP options and downloads
its config file. Note that this is existing functionality (for
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- example, Cisco devices fetch the config file named by the Bootfile-
Name DHCP option (67)). Name DHCP option (67)).
If the file appears be "garbage", the device will attempt to decrypt After retrieving the config file, the device needs to determine if it
the configuration file using its private key. If it is able to is encrypted or not. If it is not encrypted, the existing behavior
decrypt and validate the file it will install the configuration, and is used. If the configuration is encrypted, the process continues as
start using it. The exact method that the device uses to determine described in this document. The method used to determine if the
if a config file is "valid" is implementation specific, but a normal config is encrypted or not is implementation dependant; there are a
config file looks significantly different to an encrypted blob. number of (obvious) options, including having a magic string in the
file header, using a file name extension (e.g config.enc), or using
specific DHCP options.
If the file is encrypted, the device will attempt to decrypt and
parse the file. It able, it will install the configuration, and
start using it. If this fails, the device with either abort the
auto-install process, or will repeat this process until it succeeds.
Note that the device only needs DHCP and to be able to download the 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 needs config file; after the initial power-on in the factory it never needs
to access the Internet or vendor or certificate publication server - to access the Internet or vendor or certificate publication server -
it (and only it) has the private key and so has the ability to it (and only it) has the private key and so has the ability to
decrypt the config file. decrypt the config file.
+--------+ +--------------+ +--------+ +--------------+
| Device | |Config server | | Device | |Config server |
+--------+ | (e.g TFTP) | +--------+ | (e.g TFTP) |
skipping to change at page 9, line 24 skipping to change at page 10, line 24
| +-----+-----+ | | | | +-----+-----+ | | |
| | | | | | | | | |
| +-----v------+ | | +-----------+ | | +-----v------+ | | +-----------+ |
| | | | | | Encrypted | | | | | | | | Encrypted | |
| |Fetch config|<------------------>| config | | | |Fetch config|<------------------>| config | |
| | | | | | file | | | | | | | | file | |
| +-----+------+ | | +-----------+ | | +-----+------+ | | +-----------+ |
| | | | | | | | | |
| X | | | | X | | |
| / \ | | | | / \ | | |
| / \ Y +--------+ | | | | / \ N +--------+ | | |
| |Sane?|---->|Install,| | | | | | Enc?|---->|Install,| | | |
| \ / | Boot | | | | | \ / | Boot | | | |
| \ / +--------+ | | | | \ / +--------+ | | |
| V | | | | V | | |
| |N | | | | |Y | | |
| | | | | | | | | |
| +-----v------+ | | | | +-----v------+ | | |
| |Decrypt with| | | | | |Decrypt with| | | |
| |private key | | | | | |private key | | | |
| +-----+------+ | | | | +-----+------+ | | |
| | | | | | | | | |
| v | | | | v | | |
| / \ | | | | / \ | | |
| / \ Y +--------+ | | | | / \ Y +--------+ | | |
| |Sane?|---->|Install,| | | | | |Sane?|---->|Install,| | | |
skipping to change at page 11, line 31 skipping to change at page 12, line 31
Over" situation. Over" situation.
Even when using a secure bootstrapping mechanism, security conscious Even when using a secure bootstrapping mechanism, security conscious
operators may wish to bootstrapping devices with a minimal / less operators may wish to bootstrapping devices with a minimal / less
sensitive config, and then replace this with a more complete one sensitive config, and then replace this with a more complete one
after install. after install.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank everyone who contributed, including Benoit The authors wish to thank everyone who contributed, including Benoit
Claise, Sam Ribeiro, Michael Richardson, Sean Turner and Kent Watsen. Claise, Tom Petch, Sam Ribeiro, Michael Richardson, Sean Turner and
Joe Clarke provided significant comments and review. 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>.
skipping to change at page 12, line 19 skipping to change at page 13, line 19
[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 -03 to -04
o 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.
o Addressed tom's comments.
From individual WG-01 to -03: From individual WG-01 to -03:
o Addressed Joe Clarke's comments - o Addressed Joe Clarke's comments -
https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw- https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw-
XtWXZIIFhH7aW_-0YY XtWXZIIFhH7aW_-0YY
o Many typos / nits o Many typos / nits
o Broke Overview and Example Scenario into 2 sections. o Broke Overview and Example Scenario into 2 sections.
skipping to change at page 13, line 27 skipping to change at page 14, line 35
o The CA part was confusing people - the certificate is simply a 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 wrapper for the key, and the Subject just an index, and so removed
that. that.
o Added a bunch of ASCII diagrams 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, and is not intended to be used
algorithms, key lengths, format / containers will provide much fodder in production.
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 unique identifier is automated would be used. In this example, the unique identifier is
the serial number of the router, 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.
 End of changes. 17 change blocks. 
54 lines changed or deleted 85 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/