draft-ietf-opsawg-sdi-12.txt   draft-ietf-opsawg-sdi-13.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational C. Doyle Intended status: Informational C. Doyle
Expires: December 10, 2020 Juniper Networks Expires: December 26, 2020 Juniper Networks
June 08, 2020 June 24, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-12 draft-ietf-opsawg-sdi-13
Abstract Abstract
Deploying a new network device in a location where the operator has Deploying a new network device in a location where the operator has
no staff of its own often requires that an employee physically travel no staff of its own often requires that an employee physically travel
to the location to perform the initial install and configuration, to the location to perform the initial install and configuration,
even in shared facilities with "remote-hands" type support. In many even in shared facilities with "remote-hands" type support. In many
cases, this could be avoided if there were an easy way to transfer cases, this could be avoided if there were an easy way to transfer
the initial configuration to a new device, while still maintaining the initial configuration to a new device, while still maintaining
confidentiality of the configuration. confidentiality of the configuration.
This document extends existing vendor proprietary auto-install to This document extends existing vendor proprietary auto-install to
provide confidentiality to initial configuration during bootstrapping provide limited confidentiality to initial configuration during
of the device. bootstrapping of the device.
[ Ed note: Text inside square brackets ([]) is additional background [ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings, information, answers to frequently asked questions, general musings,
etc. They will be removed before publication. This document is etc. They will be removed before publication. This document is
being collaborated on in Github at: https://github.com/wkumari/draft- being collaborated on in Github at: https://github.com/wkumari/draft-
wkumari-opsawg-sdi. The most recent version of the document, open wkumari-opsawg-sdi. The most recent version of the document, open
issues, etc should all be available here. The authors (gratefully) issues, etc should all be available here. The authors (gratefully)
accept pull requests. ] accept pull requests. ]
[ Ed note: This document introduces concepts and serves as the basic [ Ed note: This document introduces concepts and serves as the basic
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2020. This Internet-Draft will expire on December 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 13 skipping to change at page 4, line 13
device accepting any configuration file that comes its way and is 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). encrypted to the device's key (or not encrypted, as the case may be).
Other solutions (such as "Secure Zero Touch Provisioning (SZTP)" Other solutions (such as "Secure Zero Touch Provisioning (SZTP)"
[RFC8572], [I-D.ietf-anima-bootstrapping-keyinfra] and other voucher- [RFC8572], [I-D.ietf-anima-bootstrapping-keyinfra] and other voucher-
based methods) are more fully featured, but also require more based methods) are more fully featured, but also require more
complicated machinery. This document describes something much complicated machinery. This document describes something much
simpler, at the cost of only providing limited protection. simpler, at the cost of only providing limited protection.
This document layers security onto existing auto-install solutions This document layers security onto existing auto-install solutions
(one example of which is [Cisco_AutoInstall]) to provide a method to (one example of which is [Cisco_AutoInstall]) to provide a method to
initially configure new devices while maintaining confidentiality of initially configure new devices while maintaining (limited)
the initial configuration. It is optimized for simplicity, for both confidentiality of the initial configuration. It is optimized for
the implementor and the operator; it is explicitly not intended to be simplicity, for both the implementor and the operator; it is
a fully featured system for managing installed devices, nor is it explicitly not intended to be a fully featured system for managing
intended to solve all use cases: rather it is a simple targeted installed devices, nor is it intended to solve all use cases: rather
solution to solve a common operational issue where the network device it is a simple targeted solution to solve a common operational issue
has been delivered, fibre laid (as appropriate) and there is no where the network device has been delivered, fibre laid (as
trusted member of the operator's staff to perform the initial appropriate) and there is no trusted member of the operator's staff
configuration. This solution is only intended to increase to perform the initial configuration. This solution is only intended
confidentiality of the information in the configuration file, and to increase confidentiality of the information in the configuration
does not protect the device itself from loading a malicious file, and does not protect the device itself from loading a malicious
configuration. configuration.
This document describes a concept, and some example ways of This document describes a concept, and some example ways of
implementing this concept. As devices have different capabilities, implementing this concept. As devices have different capabilities,
and use different configuration paradigms, one method will not suit and use different configuration paradigms, one method will not suit
all, and so it is expected that vendors will differ in exactly how all, and so it is expected that vendors will differ in exactly how
they implement this. they implement this.
This solution is specifically designed to be a simple method on top This solution is specifically designed to be a simple method on top
of exiting device functionality. If devices do not support this new of exiting device functionality. If devices do not support this new
skipping to change at page 5, line 5 skipping to change at page 5, line 5
then decrypt it with a device key), this document only discusses the then decrypt it with a device key), this document only discusses the
use for network devices, such as routers and switches. use for network devices, such as routers and switches.
2. Overview 2. Overview
Most network devices already include some sort of initial Most network devices already include some sort of initial
bootstrapping logic (sometimes called 'autoboot', or 'autoinstall'). bootstrapping logic (sometimes called 'autoboot', or 'autoinstall').
This generally works by having a newly installed, unconfigured device This generally works by having a newly installed, unconfigured device
obtain an IP address for itself and discover the address of a obtain an IP address for itself and discover the address of a
configuration server (often called 'next-server', 'siaddr' or 'tftp- configuration server (often called 'next-server', 'siaddr' or 'tftp-
server-name') using DHCP or DHXPv6 (see [RFC2131], [RFC8415]). The server-name') using DHCP or DHCPv6 (see [RFC2131], [RFC8415]). The
device then contacts this configuration server to download its device then contacts this configuration server to download its
initial configuration, which is often identified using the device's initial configuration, which is often identified using the device's
serial number, MAC address or similar. This document extends this serial number, MAC address or similar. This document extends this
(vendor-specific) paradigm by allowing the configuration file to be (vendor-specific) paradigm by allowing the configuration file to be
encrypted. encrypted.
This document uses the serial number of the device as a unique device This document uses the serial number of the device as a unique device
identifier for simplicity; some vendors may not want to implement the identifier for simplicity; some vendors may not want to implement the
system using the serial number as the identifier for business reasons system using the serial number as the identifier for business reasons
(a competitor or similar could enumerate the serial numbers and (a competitor or similar could enumerate the serial numbers and
skipping to change at page 6, line 33 skipping to change at page 6, line 33
part to be published and retrievable by the operator. The part to be published and retrievable by the operator. The
cryptographic algorithm and key lengths to be used are out of the cryptographic algorithm and key lengths to be used are out of the
scope of this document. This section illustrates one method, but, as scope of this document. This section illustrates one method, but, as
with much of this document the exact mechanism may vary by vendor. with much of this document the exact mechanism may vary by vendor.
Enrollment over Secure Transport ([RFC7030]) or possibly Enrollment over Secure Transport ([RFC7030]) or possibly
[I-D.gutmann-scep] are methods which vendors may want to consider. [I-D.gutmann-scep] are methods which vendors may want to consider.
During the manufacturing stage, when the device is initially powered During the manufacturing stage, when the device is initially powered
on, it will generate a public-private key pair. It will send its 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 unique device identifier and the public key to the vendor's directory
server to be published. The vendor's directory server should only server ([RFC5280]) to be published. The vendor's directory server
accept certificates from the manufacturing facility, and which match should only accept certificates from the manufacturing facility, and
vendor defined policies (for example, extended key usage, and which match vendor defined policies (for example, extended key usage,
extensions) Note that some devices may be constrained, and so may and extensions) Note that some devices may be constrained, and so may
send the raw public key and unique device identifier to the send the raw public key and unique device identifier to the
certificate publication server, while more capable devices may certificate publication server, while more capable devices may
generate and send self-signed certificates. This communication with generate and send self-signed certificates. This communication with
the directory server should be integrity protected, and in a the directory server should be integrity protected, and in a
controlled environment. controlled environment.
This reference architecture needs a serialization format for the key This reference architecture needs a serialization format for the key
material. Due to the prevalence of tooling support for it on network material. Due to the prevalence of tooling support for it on network
devices, X.509 certificates are a convenient format to exchange devices, X.509 certificates are a convenient format to exchange
public keys. However, most of the meta-data that would use for public keys. However, most of the meta-data that would use for
skipping to change at page 9, line 48 skipping to change at page 9, line 48
use existing auto-install functionality. As an example, it performs use existing auto-install functionality. As an example, it performs
DHCP Discovery until it gets a DHCP offer including DHCP option 66 DHCP Discovery until it gets a DHCP offer including DHCP option 66
(Server-Name) or 150 (TFTP server address), contacts the server (Server-Name) or 150 (TFTP server address), contacts the server
listed in these DHCP options and downloads its configuration file. listed in these DHCP options and downloads its configuration file.
Note that this is existing functionality (for example, Cisco devices Note that this is existing functionality (for example, Cisco devices
fetch the config file named by the Bootfile-Name DHCP option (67)). fetch the config file named by the Bootfile-Name DHCP option (67)).
After retrieving the configuration file, the device needs to After retrieving the configuration file, the device needs to
determine if it is encrypted or not. If it is not encrypted, the determine if it is encrypted or not. If it is not encrypted, the
existing behavior is used. If the configuration is encrypted, the existing behavior is used. If the configuration is encrypted, the
process continues as described in this document. The method used to process continues as described in this document. If the device has
determine if the configuration is encrypted or not is implementation been configured to only support encrypted configuration and
dependent; there are a number of (obvious) options, including having determines that the configuration file is not encrypted, it should
a magic string in the file header, using a file name extension (e.g., abort. The method used to determine if the configuration is
config.enc), or using specific DHCP options. encrypted or not is implementation dependent; there are a number of
(obvious) options, including having a magic string in the file
header, using a file name extension (e.g., config.enc), or using
specific DHCP options.
If the file is encrypted, the device will attempt to decrypt and If the file is encrypted, the device will attempt to decrypt and
parse the file. If able, it will install the configuration, and parse the file. If able, it will install the configuration, and
start using it. If it cannot decrypt the file, or if parsing the start using it. If it cannot decrypt the file, or if parsing the
configuration fails, the device will either abort the auto-install configuration fails, the device will either abort the auto-install
process, or repeat this process until it succeeds. When retrying, process, or repeat this process until it succeeds. When retrying,
care should be taken to not overwhelm the server hosting the care should be taken to not overwhelm the server hosting the
encrypted configuration files. It is suggested that the device retry encrypted configuration files. It is suggested that the device retry
every 5 minutes for the first hour, and then every hour after that. every 5 minutes for the first hour, and then every hour after that.
As it is expected that devices may be installed well before the As it is expected that devices may be installed well before the
skipping to change at page 13, line 8 skipping to change at page 13, line 8
This reference architecture is intended to incrementally improve upon This reference architecture is intended to incrementally improve upon
commonly accepted "auto-install" practices used today that may commonly accepted "auto-install" practices used today that may
transmit configurations unencrypted (e.g., unencrypted configuration transmit configurations unencrypted (e.g., unencrypted configuration
files which can be downloaded connecting to unprotected ports in files which can be downloaded connecting to unprotected ports in
datacenters, mailing initial configuration files on flash drives, or datacenters, mailing initial configuration files on flash drives, or
emailing configuration files and asking a third-party to copy and emailing configuration files and asking a third-party to copy and
paste them over a serial terminal) or allow unrestricted access to paste them over a serial terminal) or allow unrestricted access to
these configurations. these configurations.
This document describes an object level security design to provide > This document describes an object level security design to provide
confidentiality assurances for the configuration while it is in confidentiality assurances for the configuration stored at rest on
the configuration server; and for configuration while it is in
transit between the configuration server and the unprovisioned device transit between the configuration server and the unprovisioned device
even if the underly transport does not provide this security service. even if the underly transport does not provide this security service.
The architecture provides no assurances about the source of the The architecture provides no assurances about the source of the
encrypted configuration or protect against theft and reuse of encrypted configuration or protect against theft and reuse of
devices. devices.
An attacker (e.g., a malicious datacenter employee, person in the An attacker (e.g., a malicious datacenter employee, person in the
supply chain, etc.) who has physical access to the device before it supply chain, etc.) who has physical access to the device before it
is connected to the network, or who manages to exploit it once is connected to the network, or who manages to exploit it once
skipping to change at page 15, line 10 skipping to change at page 15, line 10
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
 End of changes. 10 change blocks. 
29 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/