Secure Device Install
RFC 8886

Document Type RFC - Informational (September 2020; Errata)
Authors Warren Kumari  , Colin Doyle 
Last updated 2020-10-07
Replaces draft-wkumari-opsawg-sdi
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Michael Richardson
Shepherd write-up Show (last changed 2020-05-21)
IESG IESG state RFC 8886 (Informational)
Consensus Boilerplate Yes
Telechat date
Responsible AD Robert Wilton
Send notices to Michael Richardson <mcr+ietf@sandelman.ca>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions


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.
Show full document text