doc: Add RFC documents

1 files changed, 757 insertions, 0 deletions

diff --git a/doc/rfc/rfc8886.txt b/doc/rfc/rfc8886.txt
new file mode 100644
index 0000000..257200c
--- /dev/null
+++ b/doc/rfc/rfc8886.txt
@@ -0,0 +1,757 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         W. Kumari
+Request for Comments: 8886                                        Google
+Category: Informational                                         C. Doyle
+ISSN: 2070-1721                                         Juniper Networks
+                                                          September 2020
+
+
+                         Secure Device Install
+
+Abstract
+
+   Deploying a new network device in a location where the operator has
+   no staff of its own often requires that an employee physically travel
+   to the location to perform the initial install and configuration,
+   even in shared facilities with "remote-hands" (or similar) support.
+   In many cases, this could be avoided if there were an easy way to
+   transfer the initial configuration to a new device while still
+   maintaining confidentiality of the configuration.
+
+   This document extends existing vendor proprietary auto-install to
+   provide limited confidentiality to initial configuration during
+   bootstrapping of the device.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8886.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Overview
+     2.1.  Example Scenario
+   3.  Vendor Role
+     3.1.  Device Key Generation
+     3.2.  Directory Server
+   4.  Operator Role
+     4.1.  Administrative
+     4.2.  Technical
+     4.3.  Example Initial Customer Boot
+   5.  Additional Considerations
+     5.1.  Key Storage
+     5.2.  Key Replacement
+     5.3.  Device Reinstall
+   6.  IANA Considerations
+   7.  Security Considerations
+   8.  Informative References
+   Appendix A.  Proof of Concept
+     A.1.  Step 1: Generating the Certificate
+       A.1.1.  Step 1.1: Generate the Private Key
+       A.1.2.  Step 1.2: Generate the Certificate Signing Request
+       A.1.3.  Step 1.3: Generate the (Self-Signed) Certificate Itself
+     A.2.  Step 2: Generating the Encrypted Configuration
+       A.2.1.  Step 2.1: Fetch the Certificate
+       A.2.2.  Step 2.2: Encrypt the Configuration File
+       A.2.3.  Step 2.3: Copy Configuration to the Configuration
+               Server
+     A.3.  Step 3: Decrypting and Using the Configuration
+       A.3.1.  Step 3.1: Fetch Encrypted Configuration File from
+               Configuration Server
+       A.3.2.  Step 3.2: Decrypt and Use the Configuration
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   In a growing, global network, significant amounts of time and money
+   are spent deploying new devices and "forklift" upgrading existing
+   devices.  In many cases, these devices are in shared facilities (for
+   example, Internet Exchange Points (IXP) or "carrier-neutral data
+   centers"), which have staff on hand that can be contracted to perform
+   tasks including physical installs, device reboots, loading initial
+   configurations, etc.  There are also a number of (often proprietary)
+   protocols to perform initial device installs and configurations.  For
+   example, many network devices will attempt to use DHCP [RFC2131] or
+   DHCPv6 [RFC8415] to get an IP address and configuration server and
+   then fetch and install a configuration when they are first powered
+   on.
+
+   The configurations of network devices contain a significant amount of
+   security-related and proprietary information (for example, RADIUS
+   [RFC2865] or TACACS+ [TACACS] secrets).  Exposing these to a third
+   party to load onto a new device (or using an auto-install technique
+   that fetches an unencrypted configuration file via TFTP [RFC1350]) or
+   something similar is an unacceptable security risk for many
+   operators, and so they send employees to remote locations to perform
+   the initial configuration work; this costs time and money.
+
+   There are some workarounds to this, such as asking the vendor to
+   preconfigure the device before shipping it; asking the remote support
+   to install a terminal server; providing a minimal, unsecured
+   configuration and using that to bootstrap to a complete
+   configuration; etc.  However, these are often clumsy and have
+   security issues.  As an example, in the terminal server case, the
+   console port connection could be easily snooped.
+
+   An ideal solution in this space would protect both the
+   confidentiality of device configuration in transit and the
+   authenticity (and authorization status) of configuration to be used
+   by the device.  The mechanism described in this document only
+   addresses the former and makes no effort to do the latter, with the
+   device accepting any configuration file that comes its way and is
+   encrypted to the device's key (or not encrypted, as the case may be).
+   Other solutions (such as Secure Zero Touch Provisioning (SZTP)
+   [RFC8572], Bootstrapping Remote Secure Key Infrastructures (BRSKI)
+   [BRSKI], and other voucher-based methods) are more fully featured but
+   also require more complicated machinery.  This document describes
+   something much simpler, at the cost of only providing limited
+   protection.
+
+   This document layers security onto existing auto-install solutions
+   (one example of which is [Cisco_AutoInstall]) to provide a method to
+   initially configure new devices while maintaining (limited)
+   confidentiality of the initial configuration.  It is optimized for
+   simplicity, for both the implementor and the operator.  It is
+   explicitly not intended to be a fully featured system for managing
+   installed devices nor is it intended to solve all use cases; rather,
+   it is a simple targeted solution to solve a common operational issue
+   where the network device has been delivered, fiber has been laid (as
+   appropriate), and there is no trusted member of the operator's staff
+   to perform the initial configuration.  This solution is only intended
+   to increase confidentiality of the information in the configuration
+   file and does not protect the device itself from loading a malicious
+   configuration.
+
+   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 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, Internet of Things (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.
+
+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 for itself and discover the address of a
+   configuration server (often called 'next-server', 'siaddr', or 'tftp-
+   server-name') using DHCP or DHCPv6 (see [RFC2131] and [RFC8415]).
+   The device then contacts this configuration server to download its
+   initial configuration, which is often identified using the device's
+   serial number, Media Access Control (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 device
+   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., a
+   Universally Unique Identifier (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).
+
+2.1.  Example Scenario
+
+   Operator_A needs another peering router, and so they order another
+   router from Vendor_B to be drop-shipped to the facility.  Vendor_B
+   begins assembling the new device and tells Operator_A what the new
+   device's serial number will be (SN:17894321).  When Vendor_B first
+   installs the firmware on the device and boots it, the device
+   generates a public-private key pair, and Vendor_B publishes the
+   public key on its key server (in a public key certificate, for ease
+   of use).
+
+   While the device is being shipped, Operator_A generates the initial
+   device configuration and fetches the certificate from Vendor_B key
+   servers by providing the serial number of the new device.  Operator_A
+   then encrypts the device configuration and puts this encrypted
+   configuration on a (local) TFTP server.
+
+   When the device arrives at the Point of Presence (POP), it gets
+   installed in Operator_A's rack and cabled as instructed.  The new
+   device powers up and discovers that it has not yet been configured.
+   It enters its autoboot state and begins the DHCP process.
+   Operator_A's DHCP server provides it with an IP address and the
+   address of the configuration server.  The router uses TFTP to fetch
+   its configuration file.  Note that all of this is existing
+   functionality.  The device attempts to load the configuration file.
+   As an added step, if the configuration file cannot be parsed, the
+   device tries to use its private key to decrypt the file and, assuming
+   it validates, proceeds to install the new, decrypted configuration.
+
+   Only the "correct" device will have the required private key and be
+   able to decrypt and use the configuration file (see Security
+   Considerations (Section 7)).  An attacker would be able to connect to
+   the network and get an IP address.  They would also be able to
+   retrieve (encrypted) configuration files by guessing serial numbers
+   (or perhaps the server would allow directory listing), but without
+   the private keys, an attacker will not be able to decrypt the files.
+
+3.  Vendor Role
+
+   This section describes the vendor's roles and provides an overview of
+   what the device needs to do.
+
+3.1.  Device Key Generation
+
+   Each device requires a public-private key pair and for the public
+   part to be published and retrievable by the operator.  The
+   cryptographic algorithm and key lengths to be used are out of the
+   scope of this document.  This section illustrates one method, but, as
+   with much of this document, the exact mechanism may vary by vendor.
+   Enrollment over Secure Transport [RFC7030] and possibly the Simple
+   Certificate Enrollment Protocol [RFC8894] are methods that vendors
+   may want to consider.
+
+   During the manufacturing stage, when the device is initially powered
+   on, it will generate a public-private key pair.  It will send its
+   unique device identifier and the public key to the vendor's directory
+   server [RFC5280] to be published.  The vendor's directory server
+   should only accept certificates that are from the manufacturing
+   facility and that match vendor-defined policies (for example,
+   extended key usage and extensions).  Note that some devices may be
+   constrained and so may send the raw public key and unique device
+   identifier to the certificate publication server, while more capable
+   devices may generate and send self-signed certificates.  This
+   communication with the directory server should be integrity protected
+   and should occur in a controlled environment.
+
+   This reference architecture needs a serialization format for the key
+   material.  Due to the prevalence of tooling support for it on network
+   devices, X.509 certificates are a convenient format to exchange
+   public keys.  However, most of the metadata that would be used for
+   revocation and aging will not be used and should be ignored by both
+   the client and server.  In such cases, the signature on the
+   certificate conveys no value, and the consumer of the certificate is
+   expected to pin the end-entity key fingerprint (versus using a PKI
+   and signature chain).
+
+3.2.  Directory Server
+
+   The directory server contains a database of certificates.  If newly
+   manufactured devices upload certificates, the directory server can
+   simply publish these; if the devices provide the raw public keys and
+   unique device identifier, the directory server will need to wrap
+   these in a certificate.
+
+   The customers (e.g., Operator_A) query this server with the serial
+   number (or other provided unique identifier) of a device and retrieve
+   the associated certificate.  It is expected that operators will
+   receive the unique device identifier (serial number) of devices when
+   they purchase them and will download and store the certificate.  This
+   means that there is not a hard requirement on the reachability of the
+   directory server.
+
+                         +------------+
+        +------+         |            |
+        |Device|         | Directory  |
+        +------+         |   Server   |
+                         +------------+
+   +----------------+   +--------------+
+   |   +---------+  |   |              |
+   |   | Initial |  |   |              |
+   |   |  boot?  |  |   |              |
+   |   +----+----+  |   |              |
+   |        |       |   |              |
+   | +------v-----+ |   |              |
+   | |  Generate  | |   |              |
+   | |Self-signed | |   |              |
+   | |Certificate | |   |              |
+   | +------------+ |   |              |
+   |        |       |   |   +-------+  |
+   |        +-------|---|-->|Receive|  |
+   |                |   |   +---+---+  |
+   |                |   |       |      |
+   |                |   |   +---v---+  |
+   |                |   |   |Publish|  |
+   |                |   |   +-------+  |
+   |                |   |              |
+   +----------------+   +--------------+
+
+          Figure 1: Initial Certificate Generation and Publication
+
+4.  Operator Role
+
+4.1.  Administrative
+
+   When purchasing a new device, the accounting department will need to
+   get the unique device identifier (e.g., serial number) of the new
+   device and communicate it to the operations group.
+
+4.2.  Technical
+
+   The operator will contact the vendor's publication server and
+   download the certificate (by providing the unique device identifier
+   of the device).  The operator fetches the certificate using a secure
+   transport that authenticates the source of the certificate, such as
+   HTTPS (confidentiality protection can provide some privacy and
+   metadata-leakage benefit but is not key to the primary mechanism of
+   this document).  The operator will then encrypt the initial
+   configuration (for example, using S/MIME [RFC8551]) using the key in
+   the certificate and place it on their configuration server.
+
+   See Appendix A for examples.
+
+                         +------------+
+      +--------+         |            |
+      |Operator|         | Directory  |
+      +--------+         |   Server   |
+                         +------------+
+   +----------------+  +----------------+
+   | +-----------+  |  |  +-----------+ |
+   | |   Fetch   |  |  |  |           | |
+   | |  Device   |<------>|Certificate| |
+   | |Certificate|  |  |  |           | |
+   | +-----+-----+  |  |  +-----------+ |
+   |       |        |  |                |
+   | +-----v------+ |  |                |
+   | |  Encrypt   | |  |                |
+   | |   Device   | |  |                |
+   | |   Config   | |  |                |
+   | +-----+------+ |  |                |
+   |       |        |  |                |
+   | +-----v------+ |  |                |
+   | |  Publish   | |  |                |
+   | |    TFTP    | |  |                |
+   | |   Server   | |  |                |
+   | +------------+ |  |                |
+   |                |  |                |
+   +----------------+  +----------------+
+
+   Figure 2: Fetching the Certificate, Encrypting the Configuration, and
+                   Publishing the Encrypted Configuration
+
+4.3.  Example Initial Customer Boot
+
+   When the device is first booted by the customer (and on subsequent
+   boots), if the device does not have a valid configuration, it will
+   use existing auto-install functionality.  As an example, it performs
+   DHCP Discovery until it gets a DHCP offer including DHCP option 66
+   (Server-Name) or 150 (TFTP server address), contacts the server
+   listed in these DHCP options, and downloads its configuration file.
+   Note that this is existing functionality (for example, Cisco devices
+   fetch the config file named by the Bootfile-Name DHCP option (67)).
+
+   After retrieving the configuration file, the device needs to
+   determine if it is encrypted or not.  If it is not encrypted, the
+   existing behavior is used.  If the configuration is encrypted, the
+   process continues as described in this document.  If the device has
+   been configured to only support encrypted configuration and
+   determines that the configuration file is not encrypted, it should
+   abort.  The method used to determine if the configuration is
+   encrypted or not is implementation dependent; there are a 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.  If able, it will install the configuration and start
+   using it.  If it cannot decrypt the file or if parsing the
+   configuration fails, the device will either abort the auto-install
+   process or 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 retries is not
+   specified.
+
+   Note that the device only needs to be able to download the
+   configuration file; after the initial power on in the factory, it
+   never needs to access the Internet, vendor, or directory server.  The
+   device (and only the device) has the private key and so has the
+   ability to decrypt the configuration file.
+
+             +--------+                +--------------+
+             | Device |                |Config server |
+             +--------+                |(e.g., TFTP)  |
+                                       +--------------+
+   +---------------------------+    +------------------+
+   | +-----------+             |    |                  |
+   | |           |             |    |                  |
+   | |   DHCP    |             |    |                  |
+   | |           |             |    |                  |
+   | +-----+-----+             |    |                  |
+   |       |                   |    |                  |
+   | +-----v------+            |    |  +-----------+   |
+   | |            |            |    |  | Encrypted |   |
+   | |Fetch config|<------------------>|  config   |   |
+   | |            |            |    |  |   file    |   |
+   | +-----+------+            |    |  +-----------+   |
+   |       |                   |    |                  |
+   |       X                   |    |                  |
+   |      / \                  |    |                  |
+   |     /   \ N    +--------+ |    |                  |
+   |    | Enc?|---->|Install,| |    |                  |
+   |     \   /      |  Boot  | |    |                  |
+   |      \ /       +--------+ |    |                  |
+   |       V                   |    |                  |
+   |       |Y                  |    |                  |
+   |       |                   |    |                  |
+   | +-----v------+            |    |                  |
+   | |Decrypt with|            |    |                  |
+   | |private key |            |    |                  |
+   | +-----+------+            |    |                  |
+   |       |                   |    |                  |
+   |       v                   |    |                  |
+   |      / \                  |    |                  |
+   |     /   \ Y    +--------+ |    |                  |
+   |    |Sane?|---->|Install,| |    |                  |
+   |     \   /      |  Boot  | |    |                  |
+   |      \ /       +--------+ |    |                  |
+   |       V                   |    |                  |
+   |       |N                  |    |                  |
+   |       |                   |    |                  |
+   |  +----v---+               |    |                  |
+   |  |Retry or|               |    |                  |
+   |  | abort  |               |    |                  |
+   |  +--------+               |    |                  |
+   |                           |    |                  |
+   +---------------------------+    +------------------+
+
+        Figure 3: Device Boot, Fetch, and Install Configuration File
+
+5.  Additional Considerations
+
+5.1.  Key Storage
+
+   Ideally, the key pair would be stored in a Trusted Platform Module
+   (TPM) on something that is identified as the "router" -- for example,
+   the chassis/backplane.  This is so that a key pair is bound to what
+   humans think of as the "device" and not, for example, (redundant)
+   routing engines.  Devices that implement IEEE 802.1AR [IEEE802-1AR]
+   could choose to use the Initial Device Identifier (IDevID) for this
+   purpose.
+
+5.2.  Key Replacement
+
+   It is anticipated that some operator may want to replace the (vendor-
+   provided) keys after installing the device.  There are two options
+   when implementing this: a vendor could allow the operator's key to
+   completely replace the initial device-generated key (which means
+   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
+   operator's installed key.  This is an implementation decision left to
+   the vendor.
+
+5.3.  Device Reinstall
+
+   Increasingly, operations are moving towards an automated model of
+   device management, whereby portions of the configuration (or the
+   entire configuration) are programmatically generated.  This means
+   that operators may want to generate an entire configuration after the
+   device has been initially installed and ask the device to load and
+   use this new configuration.  It is expected (but not defined in this
+   document, as it is vendor specific) that vendors will allow the
+   operator to copy a new, encrypted configuration (or part of a
+   configuration) onto a device and then request that the device decrypt
+   and install it (e.g., 'load replace <filename> encrypted').  The
+   operator could also choose to reset the device to factory defaults
+   and allow the device to act as though it were the initial boot (see
+   Section 4.3).
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  Security Considerations
+
+   This reference architecture is intended to incrementally improve upon
+   commonly accepted "auto-install" practices used today that may
+   transmit configurations unencrypted (e.g., unencrypted configuration
+   files that can be downloaded connecting to unprotected ports in data
+   centers, mailing initial configuration files on flash drives, or
+   emailing configuration files and asking a third party to copy and
+   paste them over a serial terminal) or allow unrestricted access to
+   these configurations.
+
+   This document describes an object-level security design to provide
+   confidentiality assurances for the configuration stored at rest on
+   the configuration server and for configuration while it is in transit
+   between the configuration server and the unprovisioned device, even
+   if the underlying transport does not provide this security service.
+
+   The architecture provides no assurances about the source of the
+   encrypted configuration or protect against theft and reuse of
+   devices.
+
+   An attacker (e.g., a malicious data center employee, person in the
+   supply chain, etc.) who has physical access to the device before it
+   is connected to the network or who manages to exploit it once
+   installed may be able to extract the device private key (especially
+   if it is not stored in a TPM), pretend to be the device when
+   connecting to the network, and download and extract the (encrypted)
+   configuration file.
+
+   An attacker with access to the configuration server (or the ability
+   to route traffic to configuration server under their control) and the
+   device's public key could return a configuration of the attacker's
+   choosing to the unprovisioned device.
+
+   This mechanism does not protect against a malicious vendor.  While
+   the key pair should be generated on the device and the private key
+   should be securely stored, the mechanism cannot detect or protect
+   against a vendor who claims to do this but instead generates the key
+   pair off device and keeps a copy of the private key.  It is largely
+   understood in the operator community that a malicious vendor or
+   attacker with physical access to the device is largely a "Game Over"
+   situation.
+
+   Even when using a secure bootstrap mechanism, security-conscious
+   operators may wish to bootstrap devices with a minimal or less-
+   sensitive configuration and then replace this with a more complete
+   one after install.
+
+8.  Informative References
+
+   [BRSKI]    Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
+              and K. Watsen, "Bootstrapping Remote Secure Key
+              Infrastructures (BRSKI)", Work in Progress, Internet-
+              Draft, draft-ietf-anima-bootstrapping-keyinfra-44, 21
+              September 2020, <https://tools.ietf.org/html/draft-ietf-
+              anima-bootstrapping-keyinfra-44>.
+
+   [Cisco_AutoInstall]
+              Cisco Systems, Inc., "Using AutoInstall to Remotely
+              Configure Cisco Networking Devices", Configuration
+              Fundamentals Configuration Guide, Cisco IOS Release 15M&T,
+              January 2018, <https://www.cisco.com/c/en/us/td/docs/ios-
+              xml/ios/fundamentals/configuration/15mt/fundamentals-15-
+              mt-book/cf-autoinstall.html>.
+
+   [IEEE802-1AR]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks - Secure Device Identity", IEEE Std 802-1AR, 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
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              DOI 10.17487/RFC4122, July 2005,
+              <https://www.rfc-editor.org/info/rfc4122>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
+              "Enrollment over Secure Transport", RFC 7030,
+              DOI 10.17487/RFC7030, October 2013,
+              <https://www.rfc-editor.org/info/rfc7030>.
+
+   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
+              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
+              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+              RFC 8415, DOI 10.17487/RFC8415, November 2018,
+              <https://www.rfc-editor.org/info/rfc8415>.
+
+   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
+              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
+
+   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
+              Touch Provisioning (SZTP)", RFC 8572,
+              DOI 10.17487/RFC8572, April 2019,
+              <https://www.rfc-editor.org/info/rfc8572>.
+
+   [RFC8894]  Gutmann, P., "Simple Certificate Enrolment Protocol",
+              RFC 8894, DOI 10.17487/RFC8894, September 2020,
+              <https://www.rfc-editor.org/info/rfc8894>.
+
+   [TACACS]   Dahm, T., Ota, A., Medway Gash, D., Carrel, D., and L.
+              Grant, "The TACACS+ Protocol", Work in Progress, Internet-
+              Draft, draft-ietf-opsawg-tacacs-18, 20 March 2020,
+              <https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-18>.
+
+Appendix A.  Proof of Concept
+
+   This section contains a proof of concept of the system.  It is only
+   intended for illustration and is not intended to be used in
+   production.
+
+   It uses OpenSSL from the command line.  In production, something more
+   automated would be used.  In this example, the unique device
+   identifier is the serial number of the router, SN19842256.
+
+A.1.  Step 1: Generating the Certificate
+
+   This step is performed by the router.  It generates a key, then a
+   Certificate Signing Request (CSR), and then a self-signed
+   certificate.
+
+A.1.1.  Step 1.1: Generate the Private Key
+
+   $ openssl ecparam -out privatekey.key -name prime256v1 -genkey
+   $
+
+A.1.2.  Step 1.2: Generate the Certificate Signing Request
+
+   $ openssl req -new -key key.pem -out SN19842256.csr
+   Common Name (e.g., server FQDN or YOUR name) []:SN19842256
+
+A.1.3.  Step 1.3: Generate the (Self-Signed) Certificate Itself
+
+   $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr
+   -out SN19842256.crt
+
+   The router then sends the key to the vendor's key server for
+   publication (not shown).
+
+A.2.  Step 2: Generating the Encrypted Configuration
+
+   The operator now wants to deploy the new router.
+
+   They generate the initial configuration (using whatever magic tool
+   generates router configs!), fetch the router's certificate, and
+   encrypt the configuration file to that key.  This is done by the
+   operator.
+
+A.2.1.  Step 2.1: Fetch the Certificate
+
+   $ wget http://keyserv.example.net/certificates/SN19842256.crt
+
+A.2.2.  Step 2.2: Encrypt the Configuration File
+
+   S/MIME is used here because it is simple to demonstrate.  This is
+   almost definitely not the best way to do this.
+
+   $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\
+      -out SN19842256.enc -outform PEM SN19842256.crt
+   $ more SN19842256.enc
+   -----BEGIN PKCS7-----
+   MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV
+   BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3
+   ...
+   LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt
+   -----END PKCS7-----
+
+A.2.3.  Step 2.3: Copy Configuration to the Configuration Server
+
+   $ scp SN19842256.enc config.example.com:/tftpboot
+
+A.3.  Step 3: Decrypting and Using the Configuration
+
+   When the router connects to the operator's network, it will detect
+   that it does not have a valid configuration file and will start the
+   "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
+   configuration server.  It will then use TFTP to download a
+   configuration file, based upon its serial number (this document
+   modifies the solution to fetch an encrypted configuration file
+   (ending in .enc)).  It will then decrypt the configuration file and
+   install it.
+
+A.3.1.  Step 3.1: Fetch Encrypted Configuration File from Configuration
+        Server
+
+   $ tftp 2001:0db8::23 -c get SN19842256.enc
+
+A.3.2.  Step 3.2: Decrypt and Use the Configuration
+
+   $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
+      -out config.cfg -inkey key.pem
+
+   If an attacker does not have the correct key, they will not be able
+   to decrypt the configuration file:
+
+   $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
+      -out config.cfg -inkey wrongkey.pem
+   Error decrypting PKCS#7 structure
+   140352450692760:error:06065064:digital envelope
+    routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592:
+   $ echo $?
+   4
+
+Acknowledgments
+
+   The authors wish to thank everyone who contributed, including Benoit
+   Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael
+   Richardson, Sean Turner, and Kent Watsen.  Joe Clarke also provided
+   significant comments and review, and Tom Petch provided significant
+   editorial contributions to better describe the use cases and clarify
+   the scope.
+
+   Roman Danyliw and Benjamin Kaduk also provided helpful text,
+   especially around the certificate usage and security considerations.
+
+Authors' Addresses
+
+   Warren Kumari
+   Google
+   1600 Amphitheatre Parkway
+   Mountain View, CA 94043
+   United States of America
+
+   Email: warren@kumari.net
+
+
+   Colin Doyle
+   Juniper Networks
+   1133 Innovation Way
+   Sunnyvale, CA 94089
+   United States of America
+
+   Email: cdoyle@juniper.net