draft-ietf-opsawg-sdi-08.txt   draft-ietf-opsawg-sdi-09.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: October 23, 2020 Juniper Networks Expires: November 8, 2020 Juniper Networks
April 21, 2020 May 7, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-08 draft-ietf-opsawg-sdi-09
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 datacenters with "smart-hands" type support. In many even in shared datacenters with "smart-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 a secure way to initially
provision the device. provision the device.
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 October 23, 2020. This Internet-Draft will expire on November 8, 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 46 skipping to change at page 2, line 46
5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11
5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14
Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 15 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16
B.1.2. Step 1.2: Generate the certificate signing request. . 16 B.1.2. Step 1.2: Generate the certificate signing request. . 16
B.1.3. Step 1.3: Generate the (self signed) certificate B.1.3. Step 1.3: Generate the (self signed) certificate
itself. . . . . . . . . . . . . . . . . . . . . . . . 16 itself. . . . . . . . . . . . . . . . . . . . . . . . 16
B.2. Step 2: Generating the encrypted config. . . . . . . . . 16 B.2. Step 2: Generating the encrypted config. . . . . . . . . 16
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 16 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17
B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 17 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 17
B.2.3. Step 2.3: Copy config to the config server. . . . . . 17 B.2.3. Step 2.3: Copy config to the config server. . . . . . 17
B.3. Step 3: Decrypting and using the config. . . . . . . . . 17 B.3. Step 3: Decrypting and using the config. . . . . . . . . 17
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. . . . . . . . . . . . . . . . . . . . . . . . 17 server. . . . . . . . . . . . . . . . . . . . . . . . 17
B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
skipping to change at page 5, line 23 skipping to change at page 5, line 23
[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).
[ 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 / ZTP feature. It could easily vendors use in their auto-install / ZTP feature. It could easily
instead be HTTP, FTP, etc. ] instead be HTTP, FTP, etc. ]
2.1. Example Scenario 2.1. Example Scenario
Sirius Cybernetics Corp needs another peering router, and so they Operator_A needs another peering router, and so they order another
order another router from Acme Network Widgets, to be drop-shipped to router from Vendor_B, to be drop-shipped to the Point of Presence
the Point of Presence (POP) / datacenter. Acme begins assembling the (POP) / datacenter. Vendor_B begins assembling the new device, and
new device, and tells Sirius what the new device's serial number will tells Operator_A what the new device's serial number will be
be (SN:17894321). When Acme first installs the firmware on the (SN:17894321). When Vendor_B 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 the public key on their keyserver (in a public key and Acme publishes the public key on their keyserver (in a public key
certificate, for ease of use). certificate, for ease of use).
While the device is being shipped, Sirius generates the initial While the device is being shipped, Operator_A generates the initial
device configuration, fetches the certificate from Acme keyservers by device configuration, fetches the certificate from Vendor_B
providing the serial number of the new device. Sirius then encrypts keyservers by providing the serial number of the new device.
the device configuration and puts this encrypted config on a (local) Operator_A then encrypts the device configuration and puts this
TFTP server. encrypted config on a (local) TFTP server.
When the device arrives at the POP, it gets installed in Sirius' When the device arrives at the POP, it gets installed in Operator_A'
rack, and cabled as instructed. The new device powers up and rack, and cabled as instructed. The new device powers up 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 the DHCP process. Sirius' DHCP server autoboot state, and begins the DHCP process. Operator_A' DHCP server
provides it with an IP address and the address of the configuration provides it with an IP address and the address of the configuration
server. The router uses TFTP to fetch its config file (note that all server. The router uses TFTP to fetch its config file (note that all
this is existing functionality). The device attempts to load the this is existing functionality). The device attempts to load the
config file - if the config file is unparsable, (new functionality) config file - if the config file is unparsable, (new functionality)
the device tries to use its private key to decrypt the file, and, the device tries to use its private key to decrypt the file, and,
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
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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 the raw public keys and unique device identifier, the devices provide the raw public keys and unique device identifier, the
certificate publication server will need to wrap these in a certificate publication server will need to wrap these in a
certificate. certificate.
The customers (e.g., Sirius Cybernetics Corp) query this server with The customers (e.g., Operator_A) query this server with the serial
the serial number (or other provided unique identifier) of a device, number (or other provided unique identifier) of a device, and
and retrieve the associated certificate. It is expected that retrieve the associated certificate. It is expected that operators
operators will receive the unique device identifier (serial number) will receive the unique device identifier (serial number) of devices
of devices when they purchase them, and will download and store / when they purchase them, and will download and store / cache the
cache the certificate. This means that there is not a hard certificate. This means that there is not a hard requirement on the
requirement on the uptime / reachability of the certificate uptime / reachability of the certificate publication server.
publication server.
+------------+ +------------+
+------+ |Certificate | +------+ |Certificate |
|Device| |Publication | |Device| |Publication |
+------+ | Server | +------+ | Server |
+------------+ +------------+
+----------------+ +--------------+ +----------------+ +--------------+
| +---------+ | | | | +---------+ | | |
| | Initial | | | | | | Initial | | | |
| | boot? | | | | | | boot? | | | |
skipping to change at page 9, line 9 skipping to change at page 9, line 9
described in this document. The method used to determine if the described in this document. The method used to determine if the
config is encrypted or not is implementation dependant; there are a config is encrypted or not is implementation dependant; there are a
number of (obvious) options, including having a magic string in the number of (obvious) options, including having a magic string in the
file header, using a file name extension (e.g., config.enc), or using file header, using a file name extension (e.g., config.enc), or using
specific DHCP options. specific DHCP options.
If the file is encrypted, the device will attempt to decrypt and If the file is encrypted, the device will attempt to decrypt and
parse the file. If able, it will install the configuration, and parse the file. If able, it will install the configuration, and
start using it. If it cannot decrypt the file, or if parsing the start using it. If it cannot decrypt the file, or if parsing the
configurations fails, the device will either abort the auto-install configurations fails, the device will either abort the auto-install
process, or will repeat this process until it succeeds. process, or will repeat this process until it succeeds. When
retrying, care should be taken to not overwhelm the server hosting
the encrypted configuration files. It is suggested that the device
retry every 5 minutes for the first hour, and then every hour after
that. As it is expected that devices may be installed well before
the configuration file is ready, a maximum number of retrys is not
specified.
Note that the device only needs to be able to download the config Note that the device only needs to be able to download the config
file; after the initial power-on in the factory it never needs to file; after the initial power-on in the factory it never needs to
access the Internet or vendor or certificate publication server - it access the Internet or vendor or certificate publication server - it
(and only it) has the private key and so has the ability to decrypt (and only it) has the private key and so has the ability to decrypt
the config file. the config file.
+--------+ +--------------+ +--------+ +--------------+
| Device | |Config server | | Device | |Config server |
+--------+ | (e.g. TFTP) | +--------+ | (e.g. TFTP) |
skipping to change at page 12, 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. 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, Sam Ribeiro, Michael Richardson, Sean Turner Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael
and Kent Watsen. Joe Clarke also provided significant comments and Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided
review, and Tom Petch provided significant editorial contributions to significant comments and review, and Tom Petch provided significant
better describe the use cases, and clarify the scope. editorial contributions to better describe the use cases, and clarify
the scope.
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 14, line 19 skipping to change at page 14, 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 -08 to -08
o Addressed Mirja's IETF LC comments.
From -04 to -08
o Please see GitHub commit log (I forgot to put them in here :-P )
From -03 to -04 From -03 to -04
o Addressed Joe's WGLC comments. This involved changing the "just o Addressed Joe's WGLC comments. This involved changing the "just
try decrypt and pray" to vendor specific, like a file extension, try decrypt and pray" to vendor specific, like a file extension,
magic header sting, etc. magic header sting, etc.
o Addressed tom's comments. o Addressed tom's comments.
From individual WG-01 to -03: From individual WG-01 to -03:
 End of changes. 13 change blocks. 
32 lines changed or deleted 46 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/