draft-ietf-opsawg-sdi-02.txt   draft-ietf-opsawg-sdi-03.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 4, 2020 Juniper Networks Expires: August 14, 2020 Juniper Networks
February 01, 2020 February 11, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-02 draft-ietf-opsawg-sdi-03
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 4, 2020. This Internet-Draft will expire on August 14, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 / Example Scenario . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 4
3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5
3.1. Device key generation . . . . . . . . . . . . . . . . . . 5 3.1. Device key generation . . . . . . . . . . . . . . . . . . 5
3.2. Certificate Publication Server . . . . . . . . . . . . . 5 3.2. Certificate Publication Server . . . . . . . . . . . . . 6
4. Operator Role / Responsibilities . . . . . . . . . . . . . . 6 4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7
4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 6 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7
4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 7 4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 8
5. Additional Considerations . . . . . . . . . . . . . . . . . . 10 5. Additional Considerations . . . . . . . . . . . . . . . . . . 10
5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10
5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12
Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 13 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 13
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 13 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.2. Step 1.2: Generate the certificate signing request. . 14
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. . . . . . . . . . . . . . . . . . . . . . . . 14
B.2. Step 2: Generating the encrypted config. . . . . . . . . 14 B.2. Step 2: Generating the encrypted config. . . . . . . . . 14
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14
B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14
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. . . . . . 15
B.3. Step 3: Decrypting and using the config. . . . . . . . . 15 B.3. Step 3: Decrypting and using the config. . . . . . . . . 15
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. . . . . . . . . . . . . . . . . . . . . . . . 15
B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15
skipping to change at page 4, line 16 skipping to change at page 4, line 17
not widely deployed yet. 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", "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 / Example Scenario 2. Overview
Most network devices already include some sort of initial
bootstrapping logic (sometimes called 'autoboot', or 'autoinstall').
This generally works by having a newly installed / unconfigured
device obtain an IP address and address of a config server (often
called 'next-server', 'siaddr' or 'tftp-server-name') using DHCP.
The device then contacts this configuration server to download its
initial configuration, which is often identified using the devices
serial number, MAC address or similar. This document extends this
(vendor specific) paradigm by allowing the configuration file to be
encrypted.
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 also uses TFTP because that is what many
vendors use in their auto-install / ZTP feature. It could easily
instead be HTTP, FTP, etc. ]
2.1. 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
the Point of Presence (POP) / datacenter. Acme begins assembling the the Point of Presence (POP) / datacenter. Acme begins assembling the
new device, and tells Sirius what the new device's serial number will new device, and tells Sirius what the new device's serial number will
be (SN:17894321). When Acme first installs the firmware on the be (SN:17894321). When Acme first installs the firmware on the
device and boots it, the device generates a public-private keypair, device and boots it, the device generates a public-private keypair,
and Acme publishes it on their keyserver (in a certificate, for ease and Acme publishes it on their keyserver (in a certificate, for ease
of use). of use).
skipping to change at page 5, line 5 skipping to change at page 5, line 32
assuming it validates, installs the new configuration. 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
use in their auto-install / ZTP feature. It could easily instead be
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. Device key generation 3.1. Device key generation
During the manufacturing stage, when the device is intially powered During the manufacturing stage, when the device is initially powered
on, it will generate a public-private keypair. It will send its on, it will generate a public-private keypair. It will send its
unique identifier and the public key to the vendor's Certificate unique identifier and the public key to the vendor's Certificate
Publication Server to be published. The mechanism used to do this is Publication Server to be published. The mechanism used to do this is
left undefined. Note that some devices may be contrained, and so may left undefined. Note that some devices may be constrained, and so
send the raw public key and unique identifier to the certificate may send the raw public key and unique identifier to the certificate
publication server, while mode capable devices may generate and send publication server, while mode capable devices may generate and send
self-signed certifcates. self-signed certificates.
3.2. Certificate Publication Server 3.2. Certificate Publication Server
The certificate publication server contains a database of The certificate publication server contains a database of
certificates. If newly manufactured devices upload certificates the certificates. If newly manufactured devices upload certificates the
certificate publication server can simply publish these, if the certificate publication server can simply publish these, if the
devices provide raw public keys and unique identfiers the certificate devices provide raw public keys and unique identifiers the
publication server will need to wrap these in a certificate. Note certificate publication server will need to wrap these in a
that the certificat publication server MUST only accept certifcates certificate. Note that the certificate publication server MUST only
or keys from the vendor's manufacturing facilities. accept certificates or keys from the vendor's manufacturing
facilities.
The customers (e.g Sirius Cybernetics Corp) query this server with The customers (e.g Sirius Cybernetics Corp) query this server with
the serial number (or other provided unique identifier) of a device, the serial number (or other provided unique identifier) of a device,
and retrieve the associated certificate. It is expected that and retrieve the associated certificate. It is expected that
operators will receive the unique identifier (serial number) of operators will receive the unique identifier (serial number) of
devices when they purchase them, and will download and store / cache devices when they purchase them, and will download and store / cache
the certificate. This means that there is not a hard requirement on the certificate. This means that there is not a hard requirement on
the uptime / reachability of the certificate publication server. the uptime / reachability of the certificate publication server.
+------------+ +------------+
skipping to change at page 6, line 47 skipping to change at page 7, line 19
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 (likely serial number) of the new get the unique device identifier (likely 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 SHOULD fetch the certificate using a of the device). The operator SHOULD fetch the certificate using a
secure transport (e.g HTTPS). The operator will then encrypt the secure transport (e.g HTTPS). The operator will then encrypt the
initial configuration to the key in the certifcate, and place it on initial configuration to the key in the certificate, and place it on
their TFTP server. See Appendix B for examples. their TFTP server. See Appendix B for examples.
+------------+ +------------+
+--------+ |Certificate | +--------+ |Certificate |
|Operator| |Publication | |Operator| |Publication |
+--------+ | Server | +--------+ | Server |
+------------+ +------------+
+----------------+ +----------------+ +----------------+ +----------------+
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | Fetch | | | | | | | | Fetch | | | | | |
skipping to change at page 8, line 8 skipping to change at page 8, line 27
Name DHCP option (67)). Name DHCP option (67)).
If the file appears be "garbage", the device will attempt to decrypt If the file appears be "garbage", the device will attempt to decrypt
the configuration file using its private key. If it is able to the configuration file using its private key. If it is able to
decrypt and validate the file it will install the configuration, and decrypt and validate the file it will install the configuration, and
start using it. The exact method that the device uses to determine start using it. The exact method that the device uses to determine
if a config file is "valid" is implementation specific, but a normal if a config file is "valid" is implementation specific, but a normal
config file looks significantly different to an encrypted blob. config file looks significantly different to an encrypted blob.
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 need config file; after the initial power-on in the factory it never needs
to access the Internet or vendor or certifcate 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 12, line 19 skipping to change at page 12, 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 individual WG-01 to -03:
o Addressed Joe Clarke's comments -
https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw-
XtWXZIIFhH7aW_-0YY
o Many typos / nits
o Broke Overview and Example Scenario into 2 sections.
o Reordered text for above.
From individual -04 to WG-01: From individual -04 to WG-01:
o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg- o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg-
sdi-00 sdi-00
From -00 to -01 From -00 to -01
o Nothing changed in the template! o Nothing changed in the template!
From -01 to -03: From -01 to -03:
 End of changes. 15 change blocks. 
37 lines changed or deleted 64 lines changed or added

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