<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<!-- WK: Set category, IPR, docName --> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-opsawg-sdi-13" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes"?>

  <?rfc compact="yes" ?> number="8886" ipr="trust200902"
     obsoletes="" updates="" submissionType="IETF" category="info"
     consensus="true" xml:lang="en" tocInclude="true" symRefs="true"
     sortRefs="true" version="3">

  <front>
    <!-- WK: Set long title. -->

    <title abbrev="Secure Device Install">Secure Device Install</title>
    <seriesInfo name="RFC" value="8886"/>
    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, CA</city> View</city>
	  <region>CA</region>
          <code>94043</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <author fullname="Colin Doyle" initials="C." surname="Doyle">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1133 Innovation Way</street>

          <city>Sunnyvale, CA</city>
          <city>Sunnyvale</city>
	  <region>CA</region>
          <code>94089</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>cdoyle@juniper.net</email>
      </address>
    </author>
    <date day="24" month="June" month="September" year="2020"/>

<keyword>autoboot</keyword>
<keyword>auto-boot</keyword>
<keyword>autoinstall</keyword>
<keyword>tftp</keyword>
<keyword>install</keyword>
<keyword>bunny</keyword>

    <abstract>

      <t>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" type (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, device while still maintaining
      confidentiality of the configuration.</t>
      <t>This document extends existing vendor proprietary auto-install
     to provide limited confidentiality to initial configuration during
     bootstrapping of the device.</t>

      <t>[ Ed note: Text inside square brackets ([]) is additional background
      information, answers to frequently asked questions, general musings,
      etc. They will be removed before publication. This document is being
      collaborated on in Github at:
      https://github.com/wkumari/draft-wkumari-opsawg-sdi. The most recent
      version of the document, open issues, etc should all be available here.
      The authors (gratefully) accept pull requests. ]</t>

      <t>[ Ed note: This document introduces concepts and serves as the basic
      for discussion. Because of this, it is conversational, and would need
      to be firmed up before being published ]</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>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 datacenters"), 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 <xref target="RFC2131"></xref> target="RFC2131" format="default"/> or
      DHCPv6 <xref target="RFC8415"></xref> target="RFC8415" format="default"/> to get
      an IP address and configuration server, server and then fetch and install
      a configuration when they are first powered on.</t>
      <t>The configurations of network devices contain a significant amount of
      security-related and proprietary information (for example, RADIUS
      <xref target="RFC2865"></xref> target="RFC2865" format="default"/> or TACACS+ <xref target="I-D.ietf-opsawg-tacacs"/> target="I-D.ietf-opsawg-tacacs" format="default"/>
      secrets). Exposing these to a third party to load onto a new device (or using
      an auto-install technique which that fetches an unencrypted configuration file via
      TFTP <xref target="RFC1350"/>) target="RFC1350" format="default"/>) 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.</t>
      <t>There are some workarounds to this, such as asking the vendor to pre-
      configure
      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,
      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.</t>
      <t>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,
      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 <xref
      target="RFC8572">"Secure target="RFC8572" format="default">Secure Zero Touch
      Provisioning (SZTP)"</xref>, (SZTP)</xref>, <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>
      target="I-D.ietf-anima-bootstrapping-keyinfra"
      format="default">Bootstrapping Remote Secure Key Infrastructures (BRSKI)</xref>, and
      other voucher-based methods) are more fully featured, featured but also require
      more complicated machinery.

      This document describes something much
      simpler, at the cost of only providing limited protection.</t>
      <t>This document layers security onto existing auto-install solutions
      (one example of which is <xref target="Cisco_AutoInstall"/>) target="Cisco_AutoInstall"
      format="default"/>) 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 operator. It is explicitly not intended to be a fully featured
      system for managing installed devices, devices nor is it intended to solve all
      use cases: rather cases; rather, it is a simple targeted solution to solve a common
      operational issue where the network device has been delivered, fibre fiber has
      been laid (as appropriate) 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, file and does not protect the device itself from loading a
      malicious configuration.</t>
      <t>This document describes a concept, concept and some example ways of implementing
      this concept. As devices have different capabilities, 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.</t>
      <t>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, information or can continue to use the existing
      functionality.</t>
      <t>The issue of securely installing devices is in no way a new issue, issue
      nor is it limited to network devices; it occurs when deploying
      servers, PCs, IoT 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.</t>
    </section>
    <section title="Overview"> numbered="true" toc="default">
      <name>Overview</name>
      <t>Most network devices already include some sort of initial
      bootstrapping logic (sometimes called 'autoboot', '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' 'siaddr', or 'tftp-server-name')
      using DHCP or DHCPv6 (see <xref target="RFC2131"></xref>, target="RFC2131" format="default"/> and
      <xref target="RFC8415"></xref>). target="RFC8415" format="default"/>). The device then contacts
      this configuration server to download its initial configuration, which
      is often identified using the device's serial number, MAC address Media Access
      Control (MAC) address, or similar. This document extends this
      (vendor-specific) paradigm by allowing the configuration file to be
      encrypted.</t>
      <t>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., UUID a Universally
      Unique Identifier (UUID) <xref
      target="RFC4122"/>), target="RFC4122" format="default"/>), but
      this will likely make it somewhat harder for
      operators to use (the serial number is usually easy to find on a device).</t>

      <t>[ Ed note: This example also uses TFTP because that is what many vendors
      use in their auto-install feature. It could easily instead be
      HTTP, FTP, etc. ]</t>
      <section title="Example Scenario"> numbered="true" toc="default">
        <name>Example Scenario</name>
        <t>Operator_A needs another peering router, and so they
      order another router from Vendor_B, Vendor_B to be drop-shipped to
      the facility. Vendor_B begins assembling the new
      device,
      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 their keyserver its key server (in a public key certificate, for
      ease of use).</t>
        <t>While the device is being shipped, Operator_A generates the initial
      device configuration and fetches the certificate from Vendor_B keyservers 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.</t>
        <t>When the device arrives at the POP, Point of Presence (POP), it gets
	installed in Operator_A's
      rack, rack and cabled as instructed. The new
	device powers up and discovers that it has not yet been configured. It
	enters its autoboot state, 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, decrypted configuration.</t>
        <t>Only the "correct" device will have the required private key and be
      able to decrypt and use the configuration file (See (see
      <xref target="security">Security Considerations</xref>).
      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 keys, an attacker will not be able to
      decrypt the files.</t>
      </section>
    </section>
    <section title="Vendor Role"> numbered="true" toc="default">
      <name>Vendor Role</name>
      <t>This section describes the vendor's roles and
      provides an overview of what the device needs to do.</t>
      <section title="Device key generation"> numbered="true" toc="default">
        <name>Device Key Generation</name>
        <t>Each device requires a public-private key pair, 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 document, the exact mechanism may vary by vendor.

        Enrollment over Secure Transport (<xref target="RFC7030"/>)
        or <xref target="RFC7030"
        format="default"/> and possibly the Simple Certificate Enrollment
        Protocol <xref target="I-D.gutmann-scep"/> target="RFC8894" format="default"/> are
        methods which that vendors may want to consider.</t>
        <t>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
        (<xref target="RFC5280"/>)
        <xref target="RFC5280" format="default"/> to be published. The vendor's directory server
        should only accept certificates that are from the manufacturing facility,
	facility and which that match vendor defined vendor-defined policies (for example, extended
	key usage, usage and extensions) extensions).

	Note that some devices may be constrained, 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, protected and
should occur in a controlled environment.</t>
        <t>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 meta-data metadata that would
        use be used for revocation and aging will
not be used and should be ignored by both the client and server. In such  cases
cases, the signature on the certificate conveys no value value, and the consumer of
the certificate is expected to pin the end-entity key fingerprint (versus
using a PKI and signature chain).</t>
      </section>
      <section title="Directory Server"> numbered="true" toc="default">
        <name>Directory Server</name>
        <t>The directory server contains a database of
        certificates. If newly manufactured devices upload certificates 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.</t>
        <t>The customers (e.g., Operator_A) query this server with
        the serial number (or other provided unique identifier) of a device, 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, them and will download and store the
        certificate. This means that there is not a hard requirement on the
        reachability of the directory server.</t>
<figure>
          <artwork><![CDATA[
<name>Initial Certificate Generation and Publication</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
                      +------------+
     +------+         |            |
     |Device|         | Directory  |
     +------+         |   Server   |
                      +------------+
+----------------+   +--------------+
|   +---------+  |   |              |
|   | Initial |  |   |              |
|   |  boot?  |  |   |              |
|   +----+----+  |   |              |
|        |       |   |              |
| +------v-----+ |   |              |
| |  Generate  | |   |              |
| |Self-signed | |   |              |
| |Certificate | |   |              |
| +------------+ |   |              |
|        |       |   |   +-------+  |
|        +-------|---|-->|Receive|  |
|                |   |   +---+---+  |
|                |   |       |      |
|                |   |   +---v---+  |
|                |   |   |Publish|  |
|                |   |   +-------+  |
|                |   |              |
+----------------+   +--------------+]]></artwork>

          <postamble>Initial certificate generation and
          publication.</postamble>   +--------------+
]]></artwork>
</figure>
      </section>
    </section>
    <section title="Operator Role"> numbered="true" toc="default">
      <name>Operator Role</name>
      <section title="Administrative "> numbered="true" toc="default">
        <name>Administrative</name>
        <t>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.</t>
      </section>
      <section title="Technical"> numbered="true" toc="default">
        <name>Technical</name>
        <t>The operator will contact the vendor's publication server, 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, benefit but is not key to the primary
        mechanism of this document). The operator will then encrypt the initial
        configuration (for example, using SMIME S/MIME <xref target="RFC5751"/>) target="RFC8551" format="default"/>)
        using the key in the certificate, certificate and place it on their
        configuration server.</t>

        <t>See Appendix B <xref target="proof"/> for examples.</t>
<figure>
          <artwork><![CDATA[
<name>Fetching the Certificate, Encrypting the Configuration, and Publishing
the Encrypted Configuration</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
                      +------------+
   +--------+         |            |
   |Operator|         | Directory  |
   +--------+         |   Server   |
                      +------------+
+----------------+  +----------------+
| +-----------+  |  |  +-----------+ |
| |   Fetch   |  |  |  |           | |
| |  Device   |<------>|Certificate| |
| |Certificate|  |  |  |           | |
| +-----+-----+  |  |  +-----------+ |
|       |        |  |                |
| +-----v------+ |  |                |
| |  Encrypt   | |  |                |
| |   Device   | |  |                |
| |   Config   | |  |                |
| +-----+------+ |  |                |
|       |        |  |                |
| +-----v------+ |  |                |
| |  Publish   | |  |                |
| |    TFTP    | |  |                |
| |   Server   | |  |                |
| +------------+ |  |                |
|                |  |                |
+----------------+  +----------------+]]></artwork>

          <postamble>Fetching the certificate, encrypting the configuration,
          publishing the encrypted configuration.</postamble>  +----------------+
]]></artwork>
</figure>
      </section>
      <section anchor="initial_cust_boot" title="Example numbered="true" toc="default">
        <name>Example Initial Customer Boot"> Boot</name>
        <t>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 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)).</t>
        <t>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.</t>
        <t>If the file is encrypted, the device will attempt to
        decrypt and parse the file. If able, it will install the configuration, configuration and
        start using it. If it cannot decrypt the file, file or if parsing the configuration fails,
        the device will either abort the auto-install process, 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, 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.</t>
        <t>Note that the device only needs to be able to download the
        configuration file; after the initial power-on power on in the factory factory, it never needs
        to access the Internet or vendor 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.</t>
<figure>
          <artwork><![CDATA[
<name>Device Boot, Fetch, and Install Configuration File</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
          +--------+                +--------------+
          | Device |                |Config server |
          +--------+                | (e.g.                |(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  |               |    |                  |
|  +--------+               |    |                  |
|                           |    |                  |
+---------------------------+    +------------------+]]></artwork>

          <postamble>Device boot, fetch and install configuration file</postamble>    +------------------+
]]></artwork>
</figure>
      </section>
    </section>
    <section title="Additional Considerations"> numbered="true" toc="default">
      <name>Additional Considerations</name>
      <section title="Key storage"> numbered="true" toc="default">
        <name>Key Storage</name>
        <t>Ideally, the key pair would be stored in a Trusted Platform Module
        (TPM) on something which that is identified as the &ldquo;router&rdquo;
        - "router"
        -- for example, the chassis / backplane. chassis/backplane. This is so that a key pair
        is bound to what humans think of as the &ldquo;device&rdquo;, "device" and
        not, for example example, (redundant) routing engines. Devices which that
        implement IEEE 802.1AR <xref target="IEEE802-1AR"/> target="IEEE802-1AR" format="default"/>
        could choose to use the IDevID Initial Device Identifier (IDevID) for this
        purpose.</t>
      </section>
      <section title="Key replacement "> numbered="true" toc="default">
        <name>Key Replacement</name>
        <t>It is anticipated that some operator may want to replace the
        (vendor provided)
        (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.</t>
      </section>
      <section title="Device reinstall"> numbered="true" toc="default">
        <name>Device Reinstall</name>
        <t>Increasingly, operations is are moving towards an automated model of
        device management, whereby portions of (or the entire) configuration is (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.: &lsquo;load (e.g., 'load
        replace &lt;filename&gt; encrypted). encrypted'). The operator could also choose to
        reset the device to factory defaults, defaults and allow the device to act as
        though it were the initial boot (see <xref target="initial_cust_boot"/>).</t> target="initial_cust_boot"
        format="default"/>).</t>
      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no requests of the IANA.</t> IANA actions.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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
      which
      that can be downloaded connecting to unprotected ports in datacenters, data centers,
      mailing initial configuration files on flash drives, or emailing configuration files
      and asking a third-party third party to copy and paste them over a serial terminal)
      or allow unrestricted access to these configurations.</t>

      <t>> This

      <t>This document describes an object level object-level security design to provide
      confidentiality assurances for the configuration stored at rest on the
      configuration server; server and for configuration while it is in transit
      between the configuration server and the unprovisioned device device, even if
      the underly underlying transport does not provide this security service.</t>
      <t>The architecture provides no assurances about the source of
      the encrypted configuration or protect against theft and
      reuse of devices.</t>
      <t>An attacker (e.g., a malicious datacenter data center employee, person in the
      supply chain, etc.) who has physical
      access to the device before it is connected to the network, network or who
      manages to exploit it once installed, 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.</t>
      <t>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.</t>
      <t>This mechanism does not protect against a malicious vendor. While
      the key pair should be generated on the device, device and the private key
      should be securely stored, the mechanism cannot detect or protect
      against a vendor who claims to do this, 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.</t>
      <t>Even when using a secure bootstrap mechanism, security-conscious
      operators may wish to bootstrap devices with a minimal or less-sensitive
      configuration,
      configuration and then replace this with a more complete one after
      install.</t>
    </section>

    <section title="Acknowledgments">
      <t>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.</t>

      <t>Roman Danyliw and Benjamin Kaduk also provided helpful text,
      especially around the certificate usage and security considerations.</t>
    </section>

  </middle>
  <back>
    <references title="Informative References">
      <?rfc include='reference.RFC.8572'?>

      <?rfc include='reference.RFC.4122'?>

      <?rfc include='reference.RFC.2131'?>

      <?rfc include='reference.RFC.8415'?>

      <?rfc include='reference.RFC.2865'?>

      <?rfc include='reference.RFC.1350'?>

      <?rfc include='reference.RFC.5751'?>

      <?rfc include='reference.RFC.7030'?>

      <?rfc include='reference.RFC.5280'?>

      <?rfc include="reference.I-D.ietf-opsawg-tacacs.xml"?>

      <?rfc include="reference.I-D.ietf-anima-bootstrapping-keyinfra.xml"?>

      <?rfc include="reference.I-D.gutmann-scep.xml"?>

<displayreference target="I-D.ietf-anima-bootstrapping-keyinfra" to="BRSKI"/>

<displayreference target="I-D.ietf-opsawg-tacacs" to="TACACS"/>

 <references>
      <name>Informative References</name>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1350.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8894.xml"/>

<reference anchor='I-D.ietf-opsawg-tacacs'>
<front>
<title>The TACACS+ Protocol</title>

<author initials='T' surname='Dahm' fullname='Thorsten Dahm'>
    <organization />
</author>

<author initials='A' surname='Ota' fullname='Andrej Ota'>
    <organization />
</author>

<author initials='D.' surname='Medway Gash' fullname='Douglas C. Medway Gash'>
    <organization />
</author>

<author initials='D' surname='Carrel' fullname='David Carrel'>
    <organization />
</author>

<author initials='L' surname='Grant' fullname='Lol Grant'>
    <organization />
</author>

<date month='March' day='20' year='2020' />

</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-opsawg-tacacs-18' />

</reference>

<xi:include
    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml"/>

      <reference anchor="IEEE802-1AR" target="https://standards.ieee.org/standard/802_1AR-2018.html">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title>
          <author>
            <organization>IEEE</organization>
          </author>
          <date month="June" year="2018"/>
        </front>
                <format type="TXT" target="https://standards.ieee.org/standard/802_1AR-2018.html"/>
     <seriesInfo name="IEEE Std" value="802-1AR"/>
      </reference>

      <reference anchor="Cisco_AutoInstall" target="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/configuration/15mt/fundamentals-15-mt-book/cf-autoinstall.html">
        <front>
          <title>Using AutoInstall to Remotely Configure Cisco Networking Devices</title>
          <author>
            <organization>Cisco Systems, Inc.</organization>
          </author>
          <date month="Jan" month="January" year="2018"/>
        </front>
                <format type="TXT" target="https://standards.ieee.org/standard/802_1AR-2018.html"/>
	<refcontent>Configuration Fundamentals Configuration Guide, Cisco IOS
	Release 15M&amp;T</refcontent>
      </reference>
    </references>

    <section title="Changes / Author Notes.">
      <t>[RFC Editor: Please remove this section before publication ]</t>

        <t>From -09 to -10</t>
      <t><list style="symbols">
          <t>Typos - "lenghts" => "lengths", missed a reference to Acme.</t>
      </list></t>

      <t>From -08 to -09</t>
      <t><list style="symbols">
          <t>Addressed Mirja's IETF LC comments.</t>
      </list></t>

      <t>From -04 to -08</t>
      <t><list style="symbols">
          <t>Please see GitHub commit log (I forgot to put them in here :-P )</t>
      </list></t>

      <t>From -03 to -04</t>
      <t><list style="symbols">
          <t>Addressed Joe's WGLC comments. This involved changing the "just try decrypt and pray" to vendor specific, like a file extension, magic header sting, etc.</t>
          <t>Addressed tom's comments.</t>
      </list></t>

      <t>From individual WG-01 to -03:</t>
      <t><list style="symbols">
          <t>Addressed Joe Clarke's comments - https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw-XtWXZIIFhH7aW_-0YY</t>
          <t>Many typos / nits</t>
          <t>Broke Overview and Example Scenario into 2 sections.</t>
          <t>Reordered text for above.</t>
        </list></t>

      <t>From individual -04 to WG-01:</t>

      <t><list style="symbols">
          <t>Renamed from draft-wkumari-opsawg-sdi-04 -&gt;
          draft-ietf-opsawg-sdi-00</t>
        </list></t>

      <t>From -00 to -01</t>

      <t><list style="symbols">
          <t>Nothing changed in the template!</t>
        </list>From -01 to -03:<list style="symbols">
          <t>See github commit log (AKA, we forgot to update this!)</t>

          <t>Added Colin Doyle.</t>
        </list></t>

      <t>From -03 to -04:</t>

      <t>Addressed a number of comments received before / at IETF104 (Prague).
      These include:<list style="symbols">
          <t>Pointer to
          https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch --
          included reference to (now) RFC8572 (KW)</t>

          <t>Suggested that 802.1AR IDevID (or similar) could be used. Stress
          that this is designed for simplicity (MR)</t>

          <t>Added text to explain that any unique device identifier can be
          used, not just serial number - serial number is simple and easy, but
          anything which is unique (and can be communicated to the customer)
          will work (BF).</t>

          <t>Lots anchor="proof" numbered="true" toc="default">
      <name>Proof of clarifications from Joe Clarke.</t>

          <t>Make it clear it should first try use the config, and if it
          doesn't work, then try decrypt and use it.</t>

          <t>The CA part was confusing people - the certificate is simply a
          wrapper for the key, and the Subject just an index, and so removed
          that.</t>

          <t>Added a bunch of ASCII diagrams</t>
        </list></t>
    </section>

    <section title="Proof of Concept"> Concept</name>

      <t>This section contains a proof of concept of the system.
      It is only intended for illustration, illustration and is not intended to be used
      in production.</t>
      <t>It uses OpenSSL from the command line. In production production, something more
      automated would be used. In this example, the unique device identifier is the
      serial number of the router, SN19842256.</t>
      <section title="Step numbered="true" toc="default">
        <name>Step 1: Generating the certificate. "> Certificate</name>
        <t>This step is performed by the router. It generates a key, then a
        Certificate Signing Request (CSR), and then a self signed self-signed certificate.</t>
        <section title="Step numbered="true" toc="default">
          <name>Step 1.1: Generate the private key. ">
          <figure>
            <artwork><![CDATA[ Private Key</name>
<sourcecode name="" type=""><![CDATA[
$ openssl ecparam -out privatekey.key -name prime256v1 -genkey
$
]]></artwork>
          </figure>
]]></sourcecode>
        </section>
        <section title="Step numbered="true" toc="default">
          <name>Step 1.2: Generate the certificate signing request.">
          <figure>
            <artwork><![CDATA[$ Certificate Signing Request</name>
<sourcecode name="" type=""><![CDATA[
$ openssl req -new -key key.pem -out SN19842256.csr
Common Name (e.g. (e.g., server FQDN or YOUR name) []:SN19842256

]]></artwork>
          </figure>
]]></sourcecode>
        </section>
        <section title="Step numbered="true" toc="default">
          <name>Step 1.3: Generate the (self signed) certificate itself. ">
          <t>$ (Self-Signed) Certificate Itself</name>
<sourcecode name="" type=""><![CDATA[
$ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr
-out SN19842256.crt</t> SN19842256.crt
]]></sourcecode>
          <t>The router then sends the key to the vendor&rsquo;s keyserver vendor's key server for
          publication (not shown).</t>
        </section>
      </section>
      <section title="Step numbered="true" toc="default">
        <name>Step 2: Generating the encrypted configuration. "> Encrypted Configuration</name>
        <t>The operator now wants to deploy the new router.</t>
        <t>They generate the initial configuration (using whatever magic tool
        generates router configs!), fetch the router&rsquo;s certificate router's certificate, and
        encrypt the configuration file to that key. This is done by the operator.</t>
        <section title="Step numbered="true" toc="default">
          <name>Step 2.1: Fetch the certificate.">
          <t>$ Certificate</name>
<sourcecode name="" type=""><![CDATA[
$ wget http://keyserv.example.net/certificates/SN19842256.crt</t> http://keyserv.example.net/certificates/SN19842256.crt
]]></sourcecode>
        </section>
        <section title="Step numbered="true" toc="default">
          <name>Step 2.2: Encrypt the configuration file. "> Configuration File</name>
          <t>S/MIME is used here because it is simple to demonstrate. This is
          almost definitely not the best way to do this.</t>

          <figure>
            <artwork><![CDATA[$
<sourcecode name="" type=""><![CDATA[
$ 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-----
]]></artwork>
          </figure>
]]></sourcecode>
        </section>
        <section title="Step numbered="true" toc="default">
          <name>Step 2.3: Copy configuration Configuration to the configuration server.">
          <figure>
            <artwork><![CDATA[$ Configuration Server</name>
<sourcecode name="" type=""><![CDATA[
$ scp SN19842256.enc config.example.com:/tftpboot
]]></artwork>
          </figure>
]]></sourcecode>
        </section>
      </section>
      <section title="Step numbered="true" toc="default">
        <name>Step 3: Decrypting and using Using the configuration. "> Configuration</name>
        <t>When the router connects to the operator's network network, it will detect
        that it does not have a valid configuration file, file and will start the
        &ldquo;autoboot&rdquo;
        "autoboot" process. This is a well documented well-documented process, but
        the high level 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, file and install it.</t>

        <t/>
        <section title="Step numbered="true" toc="default">
          <name>Step 3.1: Fetch encrypted configuration file Encrypted Configuration File from configuration server.">
          <figure>
            <artwork><![CDATA[$ Configuration Server</name>
<sourcecode name="" type=""><![CDATA[
$ tftp 2001:0db8::23 -c get SN19842256.enc
]]></artwork>
          </figure>
]]></sourcecode>
        </section>
        <section title="Step numbered="true" toc="default">
          <name>Step 3.2: Decrypt and use Use the configuration. ">
          <figure>
            <artwork><![CDATA[$ Configuration</name>
<sourcecode name="" type=""><![CDATA[
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
   -out config.cfg -inkey key.pem
]]></artwork>
          </figure>
]]></sourcecode>
          <t>If an attacker does not have the correct key, they will not be
          able to decrypt the configuration file:</t>

          <figure>
            <artwork><![CDATA[$
<sourcecode name="" type=""><![CDATA[
$ 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]]></artwork>
          </figure>
4]]></sourcecode>
        </section>
      </section>
    </section>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors wish to thank everyone who contributed, including
      <contact fullname="Benoit Claise"/>, <contact fullname="Francis
      Dupont"/>, <contact fullname="Mirja Kuehlewind"/>, <contact
      fullname="Sam Ribeiro"/>, <contact fullname="Michael Richardson"/>,
      <contact fullname="Sean Turner"/>, and <contact fullname="Kent
      Watsen"/>. <contact fullname="Joe Clarke"/> also provided significant
      comments and review, and <contact fullname="Tom Petch"/> provided
      significant editorial contributions to better describe the use cases
      and clarify the scope.</t>
      <t><contact fullname="Roman Danyliw"/> and <contact fullname="Benjamin
      Kaduk"/> also provided helpful text, especially around the certificate
      usage and security considerations.</t>
    </section>
  </back>

</rfc>