<?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"> <rfccategory="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>MountainView, 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> <dateday="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 newdevice,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> <sectiontitle="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-neutraldatacenters"),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 <xreftarget="RFC2131"></xref>target="RFC2131" format="default"/> or DHCPv6 <xreftarget="RFC8415"></xref>target="RFC8415" format="default"/> to get an IP address and configurationserver,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 <xreftarget="RFC2865"></xref>target="RFC2865" format="default"/> or TACACS+ <xreftarget="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 techniquewhichthat fetches an unencrypted configuration file via TFTP <xreftarget="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 topre- configurepreconfigure 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 completeconfiguration,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 theformer,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 <xreftarget="RFC8572">"Securetarget="RFC8572" format="default">Secure Zero Touch Provisioning(SZTP)"</xref>,(SZTP)</xref>, <xreftarget="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 fullyfeatured,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 <xreftarget="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 theoperator; itoperator. It is explicitly not intended to be a fully featured system for managing installeddevices,devices nor is it intended to solve all usecases: rathercases; rather, it is a simple targeted solution to solve a common operational issue where the network device has been delivered,fibrefiber has been laid (asappropriate)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 configurationfile,file and does not protect the device itself from loading a malicious configuration.</t> <t>This document describes aconcept,concept and some example ways of implementing this concept. As devices have differentcapabilities,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 configurationinformation,information or can continue to use the existing functionality.</t> <t>The issue of securely installing devices is in no way a newissue,issue nor is it limited to network devices; it occurs when deploying servers, PCs,IoTInternet 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> <sectiontitle="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 <xreftarget="RFC2131"></xref>,target="RFC2131" format="default"/> and <xreftarget="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 addressMedia 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.,UUIDa Universally Unique Identifier (UUID) <xreftarget="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><sectiontitle="Example Scenario">numbered="true" toc="default"> <name>Example Scenario</name> <t>Operator_A needs another peering router, and so they order another router fromVendor_B,Vendor_B to be drop-shipped to the facility. Vendor_B begins assembling the newdevice,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 ontheir keyserverits 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_Bkeyserverskey 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 thePOP,Point of Presence (POP), it gets installed in Operator_A'srack,rack and cabled as instructed. The new device powers up and discovers that it has not yet been configured. It enters its autobootstate,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 privatekeyskeys, an attacker will not be able to decrypt the files.</t> </section> </section> <sectiontitle="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> <sectiontitle="Device key generation">numbered="true" toc="default"> <name>Device Key Generation</name> <t>Each device requires a public-private keypair,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 thisdocumentdocument, 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 <xreftarget="I-D.gutmann-scep"/>target="RFC8894" format="default"/> are methodswhichthat 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 manufacturingfacility,facility andwhichthat matchvendor definedvendor-defined policies (for example, extended keyusage,usage andextensions)extensions). Note that some devices may beconstrained,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 integrityprotected,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 themeta-datametadata that wouldusebe used for revocation and aging will not be used and should be ignored by both the client and server. In suchcasescases, the signature on the certificate conveys novaluevalue, and the consumer of the certificate is expected to pin the end-entity key fingerprint (versus using a PKI and signature chain).</t> </section> <sectiontitle="Directory Server">numbered="true" toc="default"> <name>Directory Server</name> <t>The directory server contains a database of certificates. If newly manufactured devices uploadcertificatescertificates, 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 adevice,device and retrieve the associated certificate. It is expected that operators will receive the unique device identifier (serial number) of devices when they purchasethem,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> <sectiontitle="Operator Role">numbered="true" toc="default"> <name>Operator Role</name> <sectiontitle="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> <sectiontitle="Technical">numbered="true" toc="default"> <name>Technical</name> <t>The operator will contact the vendor's publicationserver,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-leakagebenefit,benefit but is not key to the primary mechanism of this document). The operator will then encrypt the initial configuration (for example, usingSMIMES/MIME <xreftarget="RFC5751"/>)target="RFC8551" format="default"/>) using the key in thecertificate,certificate and place it on their configuration server.</t> <t>SeeAppendix 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="Examplenumbered="true" toc="default"> <name>Example Initial CustomerBoot">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 DHCPoptionsoptions, 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 theconfiguration,configuration and start using it. If it cannot decrypt thefile,file or if parsing the configuration fails, the device will either abort the auto-installprocess,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 firsthour,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 initialpower-onpower on in thefactoryfactory, it never needs to access theInternet or vendorInternet, 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> <sectiontitle="Additional Considerations">numbered="true" toc="default"> <name>Additional Considerations</name> <sectiontitle="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 somethingwhichthat is identified as the“router” -"router" -- for example, thechassis / backplane.chassis/backplane. This is so that a key pair is bound to what humans think of as the“device”,"device" and not, forexampleexample, (redundant) routing engines. Deviceswhichthat implement IEEE 802.1AR <xreftarget="IEEE802-1AR"/>target="IEEE802-1AR" format="default"/> could choose to use theIDevIDInitial Device Identifier (IDevID) for this purpose.</t> </section> <sectiontitle="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> <sectiontitle="Device reinstall">numbered="true" toc="default"> <name>Device Reinstall</name> <t>Increasingly, operationsisare moving towards an automated model of device management, whereby portions of(ortheentire)configurationis(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(e.g., 'load replace <filename>encrypted).encrypted'). The operator could also choose to reset the device to factorydefaults,defaults and allow the device to act as though it were the initial boot (see <xreftarget="initial_cust_boot"/>).</t>target="initial_cust_boot" format="default"/>).</t> </section> </section> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas norequests 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 fileswhichthat can be downloaded connecting to unprotected ports indatacenters,data centers, mailing initial configuration files on flash drives, or emailing configuration files and asking athird-partythird party to copy and paste them over a serial terminal) or allow unrestricted access to these configurations.</t><t>> This<t>This document describes anobject levelobject-level security design to provide confidentiality assurances for the configuration stored at rest on the configurationserver;server and for configuration while it is in transit between the configuration server and the unprovisioneddevicedevice, even if theunderlyunderlying 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 maliciousdatacenterdata center employee, person in the supply chain, etc.) who has physical access to the device before it is connected to thenetwork,network or who manages to exploit it onceinstalled,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 thedevice,device and the private key should be securely stored, the mechanism cannot detect or protect against a vendor who claims to dothis,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-sensitiveconfiguration,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> <datemonth="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&T</refcontent> </reference> </references> <sectiontitle="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 -> 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>Lotsanchor="proof" numbered="true" toc="default"> <name>Proof ofclarifications 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 forillustration,illustration and is not intended to be used in production.</t> <t>It uses OpenSSL from the command line. Inproductionproduction, something more automated would be used. In this example, the unique device identifier is the serial number of the router, SN19842256.</t> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 1: Generating thecertificate. ">Certificate</name> <t>This step is performed by the router. It generates a key, then a Certificate Signing Request (CSR), and then aself signedself-signed certificate.</t> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 1.1: Generate theprivate key. "> <figure> <artwork><![CDATA[Private Key</name> <sourcecode name="" type=""><![CDATA[ $ openssl ecparam -out privatekey.key -name prime256v1 -genkey $]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 1.2: Generate thecertificate 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> <sectiontitle="Stepnumbered="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 -outSN19842256.crt</t>SN19842256.crt ]]></sourcecode> <t>The router then sends the key to thevendor’s keyservervendor's key server for publication (not shown).</t> </section> </section> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 2: Generating theencrypted 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 therouter’s certificaterouter's certificate, and encrypt the configuration file to that key. This is done by the operator.</t> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 2.1: Fetch thecertificate."> <t>$Certificate</name> <sourcecode name="" type=""><![CDATA[ $ wgethttp://keyserv.example.net/certificates/SN19842256.crt</t>http://keyserv.example.net/certificates/SN19842256.crt ]]></sourcecode> </section> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 2.2: Encrypt theconfiguration 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> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 2.3: CopyconfigurationConfiguration to theconfiguration server."> <figure> <artwork><![CDATA[$Configuration Server</name> <sourcecode name="" type=""><![CDATA[ $ scp SN19842256.enc config.example.com:/tftpboot]]></artwork> </figure>]]></sourcecode> </section> </section> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 3: Decrypting andusingUsing theconfiguration. ">Configuration</name> <t>When the router connects to the operator'snetworknetwork, it will detect that it does not have a valid configurationfile,file and will start the“autoboot”"autoboot" process. This is awell documentedwell-documented process, but thehigh levelhigh-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 configurationfile,file and install it.</t><t/><sectiontitle="Stepnumbered="true" toc="default"> <name>Step 3.1: Fetchencrypted configuration fileEncrypted Configuration File fromconfiguration server."> <figure> <artwork><![CDATA[$Configuration Server</name> <sourcecode name="" type=""><![CDATA[ $ tftp 2001:0db8::23 -c get SN19842256.enc]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="Stepnumbered="true" toc="default"> <name>Step 3.2: Decrypt anduseUse theconfiguration. "> <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>