< draft-ietf-opsawg-sdi-05.txt   draft-ietf-opsawg-sdi-06.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: September 7, 2020 Juniper Networks Expires: October 5, 2020 Juniper Networks
March 06, 2020 April 03, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-05 draft-ietf-opsawg-sdi-06
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 September 7, 2020. This Internet-Draft will expire on October 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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . . . . . . . 5 2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5
3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 6 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 6
3.1. Device key generation . . . . . . . . . . . . . . . . . . 6 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. Example Initial Customer Boot . . . . . . . . . . . . . . 8
5. Additional Considerations . . . . . . . . . . . . . . . . . . 11 5. Additional Considerations . . . . . . . . . . . . . . . . . . 11
5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11
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. . . . . . . . . . . . . . . 13 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14
Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 14 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 14 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 15
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15
B.1.2. Step 1.2: Generate the certificate signing request. . 15 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. . . . . . . . . . . . . . . . . . . . . . . . 15 itself. . . . . . . . . . . . . . . . . . . . . . . . 16
B.2. Step 2: Generating the encrypted config. . . . . . . . . 15 B.2. Step 2: Generating the encrypted config. . . . . . . . . 16
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 15 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 16
B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 16 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 16
B.2.3. Step 2.3: Copy config to the config server. . . . . . 16 B.2.3. Step 2.3: Copy config to the config server. . . . . . 17
B.3. Step 3: Decrypting and using the config. . . . . . . . . 16 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. . . . . . . . . . . . . . . . . . . . . . . . 16 server. . . . . . . . . . . . . . . . . . . . . . . . 17
B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 16 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 [RFC2131]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 [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets).
onto a new device (or using an auto-install techniques which fetch an Exposing these to a third party to load onto a new device (or using
unencrypted config file via something like TFTP) is simply not an auto-install techniques which fetch an unencrypted config file via
acceptable to many operators, and so they have to send employees to something like TFTP [RFC1350]) is simply not acceptable to many
remote locations to perform the initial configuration work. As well operators, and so they have to send employees to remote locations to
as having a significant monetary cost, it also takes significantly perform the initial configuration work. As well as having a
longer to install devices and is generally inefficient. significant monetary cost, it also takes significantly 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. 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],
more fully featured, but also more complex to implement and / or are [I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more
not widely deployed yet. fully featured, but also more complex to implement and / or are not
widely deployed yet.
This solution is specifically designed to be a simple method on top This solution is specifically designed to be a simple method on top
of exiting device functionality. If devices do not support this new of exiting device functionality. If devices do not support this new
method, they can continue to use the existing functionality. In method, they can continue to use the existing functionality. In
addition, operators can choose to use this to protect their addition, operators can choose to use this to protect their
configuration information, or can continue to use the existing configuration information, or can continue to use the existing
functionality. functionality.
The issue of securely installing devices is in no way a new issue, The issue of securely installing devices is in no way a new issue,
nor is it limited to network devices; it occurs when deploying nor is it limited to network devices; it occurs when deploying
skipping to change at page 4, line 37 skipping to change at page 4, line 39
"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
Most network devices already include some sort of initial Most network devices already include some sort of initial
bootstrapping logic (sometimes called 'autoboot', or 'autoinstall'). bootstrapping logic (sometimes called 'autoboot', or 'autoinstall').
This generally works by having a newly installed / unconfigured 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 (see
The device then contacts this configuration server to download its [RFC2131]). The device then contacts this configuration server to
initial configuration, which is often identified using the devices download its initial configuration, which is often identified using
serial number, MAC address or similar. This document extends this the devices serial number, MAC address or similar. This document
(vendor specific) paradigm by allowing the configuration file to be extends this (vendor specific) paradigm by allowing the configuration
encrypted. file to be encrypted.
This document describes a concept, and some example ways of This document describes a concept, and some example ways of
implementing this concept. As devices have different capabilities, implementing this concept. As devices have different capabilities,
and use different configuration paradigms, one method will not suit and use different configuration paradigms, one method will not suit
all, and so it is expected that vendors will differ in exactly how all, and so it is expected that vendors will differ in exactly how
they implement this. they implement this.
This 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
skipping to change at page 6, line 13 skipping to change at page 6, line 15
an attacker will not be able to decrypt the files. an attacker will not be able to decrypt the files.
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
Each devices requires a public-private key keypair, and for the Each devices requires a public-private key keypair, and for the
public part to be published and retrievable by the operator. This public part to be published and retrievable by the operator. The
section illustrates one method, but, as with much of this document cryptograthic algorithm and keylenghts to be used are out of the
the exact mechanism may will vary by vendor. [I-D.gutmann-scep] is scope of this document. This section illustrates one method, but, as
one method which vendors may want to strongly consider. with much of this document the exact mechanism may will vary by
vendor. [I-D.gutmann-scep] is one method which vendors may want to
strongly consider.
During the manufacturing stage, when the device is initially powered During the manufacturing stage, when the device is initially powered
on, it will generate a public-private 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 vendor's Certificate Publication Server to be published. The vendor's Certificate
Publication Server should only accept certificates from the Publication Server should only accept certificates from the
manufacturing facility, and which match vendor defined policies (for manufacturing facility, and which match vendor defined policies (for
example, extended key usage, extensions, etc.) Note that some example, extended key usage, extensions, etc.) Note that some
devices may be constrained, and so may send the raw public key and devices may be constrained, and so may send the raw public key and
unique identifier to the certificate publication server, while more unique identifier to the certificate publication server, while more
skipping to change at page 7, line 47 skipping to change at page 7, line 47
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 (for example, using SMIME) using the key in the initial configuration (for example, using SMIME [RFC5751]) using the
certificate, and place it on their TFTP server. See Appendix B for key in the certificate, and place it on their TFTP server. See
examples. Appendix B for examples.
+------------+ +------------+
+--------+ |Certificate | +--------+ |Certificate |
|Operator| |Publication | |Operator| |Publication |
+--------+ | Server | +--------+ | Server |
+------------+ +------------+
+----------------+ +----------------+ +----------------+ +----------------+
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| | Fetch | | | | | | | | Fetch | | | | | |
| | Device |<------>|Certificate| | | | Device |<------>|Certificate| |
skipping to change at page 8, line 34 skipping to change at page 8, line 34
| | Publish | | | | | | Publish | | | |
| | TFTP | | | | | | TFTP | | | |
| | Server | | | | | | Server | | | |
| +------------+ | | | | +------------+ | | |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
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. Example 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 does not have a valid configuration, it will boots), if the device does not have a valid configuration, it will
use existing auto-install functionality. As an example, it performs use existing auto-install functionality. As an example, it performs
DHCP Discovery until it gets a DHCP offer including DHCP option 66 DHCP Discovery until it gets a DHCP offer including DHCP option 66
(Server-Name) or 150 (TFTP server address), contact the server listed (Server-Name) or 150 (TFTP server address), contact the server listed
in these DHCP options and downloads its config file. Note that this in these DHCP options and downloads its config file. Note that this
is existing functionality (for example, Cisco devices fetch the is existing functionality (for example, Cisco devices fetch the
config file named by the Bootfile-Name DHCP option (67)). config file named by the Bootfile-Name DHCP option (67)).
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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. It able, it will install the configuration, and parse the file. It able, it will install the configuration, and
start using it. If this fails, the device with either abort the start using it. If this fails, the device with either abort the
auto-install process, or will repeat this process until it succeeds. 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 to be able to download the config
config file; after the initial power-on in the factory it never needs file; after the initial power-on in the factory it never needs to
to access the Internet or vendor or certificate publication server - access the Internet or vendor or certificate publication server - it
it (and only it) has the private key and so has the ability to (and only it) has the private key and so has the ability to decrypt
decrypt the config file. the config file.
+--------+ +--------------+ +--------+ +--------------+
| Device | |Config server | | Device | |Config server |
+--------+ | (e.g. TFTP) | +--------+ | (e.g. TFTP) |
+--------------+ +--------------+
+---------------------------+ +------------------+ +---------------------------+ +------------------+
| +-----------+ | | | | +-----------+ | | |
| | | | | | | | | | | |
| | DHCP | | | | | | DHCP | | | |
| | | | | | | | | | | |
skipping to change at page 11, line 13 skipping to change at page 11, line 13
Device boot, fetch and install config file Device boot, fetch and install config file
5. Additional Considerations 5. Additional Considerations
5.1. Key storage 5.1. Key storage
Ideally, the keypair would be stored in a Trusted Platform Module Ideally, the keypair would be stored in a Trusted Platform Module
(TPM) on something which is identified as the "router" - for example, (TPM) on something which is identified as the "router" - for example,
the chassis / backplane. This is so that a keypair is bound to what the chassis / backplane. This is so that a keypair is bound to what
humans think of as the "device", and not, for example (redundant) humans think of as the "device", and not, for example (redundant)
routing engines. Devices which implement IEEE 802.1AR could choose routing engines. Devices which implement IEEE 802.1AR [IEEE802-1AR]
to use the IDevID for this purpose. could choose to use the IDevID for this purpose.
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. There are two options provided) keys after installing the device. There are two options
when implementing this - a vendor could allow the operator's key to when implementing this - a vendor could allow the operator's key to
completely replace the initial device generated key (which means completely replace the initial device generated key (which means
that, if the device is ever sold, the new owner couldn't use this that, if the device is ever sold, the new owner couldn't use this
technique to install the device), or the device could prefer the technique to install the device), or the device could prefer the
operators installed key. This is an implementation decision left to operators installed key. This is an implementation decision left to
skipping to change at page 13, line 9 skipping to change at page 13, line 9
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.gutmann-scep] [I-D.gutmann-scep]
Gutmann, P., "Simple Certificate Enrolment Protocol", Gutmann, P., "Simple Certificate Enrolment Protocol",
draft-gutmann-scep-15 (work in progress), February 2020. draft-gutmann-scep-16 (work in progress), March 2020.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-40 (work in progress), April 2020.
[I-D.ietf-opsawg-tacacs]
Dahm, T., Ota, A., dcmgash@cisco.com, d., Carrel, D., and
L. Grant, "The TACACS+ Protocol", draft-ietf-opsawg-
tacacs-18 (work in progress), March 2020.
[IEEE802-1AR]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", June 2018,
<https://standards.ieee.org/standard/802_1AR-2018.html>.
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, DOI 10.17487/RFC1350, July 1992,
<https://www.rfc-editor.org/info/rfc1350>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[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 From -03 to -04
skipping to change at page 16, line 37 skipping to change at page 17, line 32
that does not have a valid configuration file, and will start the that does not have a valid configuration file, and will start the
"autoboot" process. This is a well documented process, but the high "autoboot" process. This is a well documented process, but the high
level overview is that it will use DHCP to obtain an IP address and level overview is that it will use DHCP to obtain an IP address and
config server. It will then use TFTP to download a configuration config server. It will then use TFTP to download a configuration
file, based upon its serial number (this document modifies the file, based upon its serial number (this document modifies the
solution to fetch an encrypted config file (ending in .enc)). It solution to fetch an encrypted config file (ending in .enc)). It
will then decrypt the config file, and install it. will then decrypt the config file, and install it.
B.3.1. Step 3.1: Fetch encrypted config file from config server. B.3.1. Step 3.1: Fetch encrypted config file from config server.
$ tftp 192.0.2.1 -c get SN19842256.enc $ tftp 2001:0db8::23 -c get SN19842256.enc
B.3.2. Step 3.2: Decrypt and use the config. B.3.2. Step 3.2: Decrypt and use the config.
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
-out config.cfg -inkey key.pem -out config.cfg -inkey key.pem
If an attacker does not have the correct key, they will not be able If an attacker does not have the correct key, they will not be able
to decrypt the config: to decrypt the config:
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
 End of changes. 21 change blocks. 
51 lines changed or deleted 89 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/