< draft-ietf-opsawg-sdi-10.txt		draft-ietf-opsawg-sdi-11.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: November 12, 2020 Juniper Networks		Expires: November 21, 2020 Juniper Networks
	May 11, 2020		May 20, 2020
	Secure Device Install		Secure Device Install
	draft-ietf-opsawg-sdi-10		draft-ietf-opsawg-sdi-11
	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 datacenters with "smart-hands" type support. In many		even in shared facilities with "remote-hands" type support. In many
	cases, this could be avoided if there were a secure way to initially		cases, this could be avoided if there were a secure way to initially
	provision the device.		provision the device.
	This document extends existing auto-install / Zero-Touch Provisioning		This document extends existing vendor proprietary auto-install to
	mechanisms to make the process more secure.		make the process more secure.
	[ 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
	for discussion - because of this, it is conversational, and would		for discussion. Because of this, it is conversational, and would
	need to be firmed up before being published ]		need to be firmed up before being published ]
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 12, 2020.		This Internet-Draft will expire on November 21, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5		2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5
	3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 6		3. Vendor Role . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Device key generation . . . . . . . . . . . . . . . . . . 6		3.1. Device key generation . . . . . . . . . . . . . . . . . . 6
	3.2. Certificate Publication Server . . . . . . . . . . . . . 6		3.2. Certificate Publication Server . . . . . . . . . . . . . 6
	4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7		4. Operator Role . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7		4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Example Initial Customer Boot . . . . . . . . . . . . . . 8		4.3. Example Initial Customer Boot . . . . . . . . . . . . . . 8
	5. Additional Considerations . . . . . . . . . . . . . . . . . . 11		5. Additional Considerations . . . . . . . . . . . . . . . . . . 11
	5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11		5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11		5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11
	5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11		5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Informative References . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14
	Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15		Appendix B. Proof of Concept . . . . . . . . . . . . . . . . . . 16
	B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16		B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16
	B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16		B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16
	B.1.2. Step 1.2: Generate the certificate signing request. . 16		B.1.2. Step 1.2: Generate the certificate signing request. . 16
	B.1.3. Step 1.3: Generate the (self signed) certificate		B.1.3. Step 1.3: Generate the (self signed) certificate
	itself. . . . . . . . . . . . . . . . . . . . . . . . 16		itself. . . . . . . . . . . . . . . . . . . . . . . . 17
	B.2. Step 2: Generating the encrypted config. . . . . . . . . 17		B.2. Step 2: Generating the encrypted configuration. . . . . . 17
	B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17		B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17
	B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 17		B.2.2. Step 2.2: Encrypt the configuration file. . . . . . . 17
	B.2.3. Step 2.3: Copy config to the config server. . . . . . 17		B.2.3. Step 2.3: Copy configuration to the configuration
	B.3. Step 3: Decrypting and using the config. . . . . . . . . 17
	B.3.1. Step 3.1: Fetch encrypted config file from config
	server. . . . . . . . . . . . . . . . . . . . . . . . 17		server. . . . . . . . . . . . . . . . . . . . . . . . 17
	B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 18		B.3. Step 3: Decrypting and using the configuration. . . . . . 17
			B.3.1. Step 3.1: Fetch encrypted configuration file from
			configuration server. . . . . . . . . . . . . . . . . 18
			B.3.2. Step 3.2: Decrypt and use the configuration. . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	In a growing, global network, significant amounts of time and money		In a growing, global network, significant amounts of time and money
	are spent deploying new devices and "forklift" upgrading existing		are spent deploying new devices and "forklift" upgrading existing
	devices. In many cases, these devices are in shared datacenters (for		devices. In many cases, these devices are in shared facilities (for
	example, Internet Exchange Points (IXP) or "carrier neutral		example, Internet Exchange Points (IXP) or "carrier-neutral
	datacenters"), which have staff on hand that can be contracted to		datacenters"), which have staff on hand that can be contracted to
	perform tasks including physical installs, device reboots, loading		perform tasks including physical installs, device reboots, loading
	initial configurations, etc. There are also a number of (often		initial configurations, etc. There are also a number of (often
	vendor proprietary) protocols to perform initial device installs and		proprietary) protocols to perform initial device installs and
	configurations - for example, many network devices will attempt to		configurations. For example, many network devices will attempt to
	use DHCP [RFC2131]to get an IP address and configuration server, and		use DHCP [RFC2131] to get an IP address and configuration server, and
	then fetch and install a configuration when they are first powered		then fetch and install a configuration when they are first powered
	on.		on.
	The configurations of network devices contain a significant amount of		The configurations of network devices contain a significant amount of
	security related and/or proprietary information (for example, RADIUS		security-related and proprietary information (for example, RADIUS
	[RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing		[RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing
	these to a third party to load onto a new device (or using an auto-		these to a third party to load onto a new device (or using an auto-
	install techniques which fetch an unencrypted config file via TFTP		install technique which fetches an unencrypted configuration file via
	[RFC1350]) or something similar, is an unacceptable security risk for		TFTP [RFC1350]) or something similar is an unacceptable security risk
	many operators, and so they send employees to remote locations to		for many operators, and so they send employees to remote locations to
	perform the initial configuration work; this costs, time and money.		perform the initial configuration work; this costs time and money.
	There are some workarounds to this, such as asking the vendor to pre-		There are some workarounds to this, such as asking the vendor to pre-
	configure the devices before shipping it; asking the smart-hands to		configure the device before shipping it; asking the remote support to
	install a terminal server; providing a minimal, unsecured		install a terminal server; providing a minimal, unsecured
	configuration and using that to bootstrap to a complete		configuration and using that to bootstrap to a complete
	configuration, etc; but these are often clumsy and have security		configuration, etc. However, these are often clumsy and have
	issues - for example, in the terminal server case, the console port		security issues. As an example, in the terminal server case, the
	connection could be easily snooped.		console port connection could be easily snooped.
	This document layers security onto existing auto-install solutions to		This document layers security onto existing auto-install solutions
	provide a secure method to initially configure new devices. It is		(one example of which is [Cisco_AutoInstall]) to provide a secure
	optimized for simplicity, both for the implementor and the operator;		method to initially configure new devices. It is optimized for
	it is explicitly not intended to be an "all singing, all dancing"		simplicity, for both the implementor and the operator; it is
	fully featured system for managing installed / deployed devices, nor		explicitly not intended to be a fully featured system for managing
	is it intended to solve all use-cases - rather it is a simple		installed devices, nor is it intended to solve all use cases: rather
	targeted solution to solve a common operational issue where the		it is a simple targeted solution to solve a common operational issue
	network device has been delivered, fibre laid (as appropriate) but		where the network device has been delivered, fibre laid (as
	there is no trusted member of the operator's staff to perform the		appropriate) but there is no trusted member of the operator's staff
	initial configuration.		to perform the initial configuration. This solution is only intended
			to increase confidentiality of the information in the configuration
			file, not to protect the device itself.
	Solutions such as Secure Zero Touch Provisioning (SZTP)" [RFC8572],		Solutions such as "Secure Zero Touch Provisioning (SZTP)" [RFC8572],
	[I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more		[I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more
	fully featured, but also more complex to implement and/or are not		fully featured, but also more complex to implement and are not widely
	widely deployed yet.		deployed yet. In addition, work in the IETF "Software Updates for
			Internet of Things (suit)" WG is expected to provide mechanisms for
			firmware updates, and are out of scope for this document.
			This document describes a concept, and some example ways of
			implementing this concept. As devices have different capabilities,
			and use different configuration paradigms, one method will not suit
			all, and so it is expected that vendors will differ in exactly how
			they implement this.
	This solution is specifically designed to be a simple method on top		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
	method, they can continue to use the existing functionality. In		method, they can continue to use the existing functionality. In
	addition, operators can choose to use this to protect their		addition, operators can choose to use this to protect their
	configuration information, or can continue to use the existing		configuration information, or can continue to use the existing
	functionality.		functionality.
	The issue of securely installing devices is in no way a new issue,		The issue of securely installing devices is in no way a new issue,
	nor is it limited to network devices; it occurs when deploying		nor is it limited to network devices; it occurs when deploying
	servers, PCs, IoT devices, and in many other situations. While the		servers, PCs, IoT devices, and in many other situations. While the
	solution described in this document is obvious (encrypt the config,		solution described in this document is obvious (encrypt the config,
	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.
	1.1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.
	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		This generally works by having a newly installed, unconfigured device
	device obtain an IP address and address of a config server (often		obtain an IP address for itself and discover the address of a
	called 'next-server', 'siaddr' or 'tftp-server-name') using DHCP (see		configuration server (often called 'next-server', 'siaddr' or 'tftp-
	[RFC2131]). The device then contacts this configuration server to		server-name') using DHCP (see [RFC2131]). The device then contacts
	download its initial configuration, which is often identified using		this configuration server to download its initial configuration,
	the devices serial number, MAC address or similar. This document		which is often identified using the device's serial number, MAC
	extends this (vendor specific) paradigm by allowing the configuration		address or similar. This document extends this (vendor-specific)
	file to be encrypted.		paradigm by allowing the configuration file to be encrypted.
	This document describes a concept, and some example ways of
	implementing this concept. As devices have different capabilities,
	and use different configuration paradigms, one method will not suit
	all, and so it is expected that vendors will differ in exactly how
	they implement this.
	This 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
	determine how many devices have been manufactured). Implementors are		determine how many devices have been manufactured). Implementors are
	free to choose some other way of generating identifiers (e.g., UUID		free to choose some other way of generating identifiers (e.g., UUID
	[RFC4122]), but this will likely make it somewhat harder for		[RFC4122]), but this will likely make it somewhat harder for
	operators to use (the serial number is usually easy to find on a		operators to use (the serial number is usually easy to find on a
	device, a more complex system is likely harder to track).		device, a more complex system is likely harder to track).
	[ Ed note: This example also uses TFTP because that is what many		[ Ed note: This example also uses TFTP because that is what many
	vendors use in their auto-install / ZTP feature. It could easily		vendors use in their auto-install feature. It could easily instead
	instead be HTTP, FTP, etc. ]		be HTTP, FTP, etc. ]
	2.1. Example Scenario		2.1. Example Scenario
	Operator_A needs another peering router, and so they order another		Operator_A needs another peering router, and so they order another
	router from Vendor_B, to be drop-shipped to the Point of Presence		router from Vendor_B, to be drop-shipped to the facility. Vendor_B
	(POP) / datacenter. Vendor_B begins assembling the new device, and		begins assembling the new device, and tells Operator_A what the new
	tells Operator_A what the new device's serial number will be		device's serial number will be (SN:17894321). When Vendor_B first
	(SN:17894321). When Vendor_B first installs the firmware on the		installs the firmware on the device and boots it, the device
	device and boots it, the device generates a public-private keypair,		generates a public-private key pair, and Vendor_B publishes the
	and Vendor_B publishes the public key on their keyserver (in a public		public key on their keyserver (in a public key certificate, for ease
	key certificate, for ease of use).		of use).
	While the device is being shipped, Operator_A generates the initial		While the device is being shipped, Operator_A generates the initial
	device configuration, fetches the certificate from Vendor_B		device configuration and fetches the certificate from Vendor_B
	keyservers by providing the serial number of the new device.		keyservers by providing the serial number of the new device.
	Operator_A then encrypts the device configuration and puts this		Operator_A then encrypts the device configuration and puts this
	encrypted config on a (local) TFTP server.		encrypted configuration on a (local) TFTP server.
	When the device arrives at the POP, it gets installed in Operator_A'		When the device arrives at the POP, it gets installed in Operator_A's
	rack, and cabled as instructed. The new device powers up and		rack, and cabled as instructed. The new device powers up and
	discovers that it has not yet been configured. It enters its		discovers that it has not yet been configured. It enters its
	autoboot state, and begins the DHCP process. Operator_A' DHCP server		autoboot state, and begins the DHCP process. Operator_A's DHCP
	provides it with an IP address and the address of the configuration		server provides it with an IP address and the address of the
	server. The router uses TFTP to fetch its config file (note that all		configuration server. The router uses TFTP to fetch its
	this is existing functionality). The device attempts to load the		configuration file. Note that all of this is existing functionality.
	config file - if the config file is unparsable, (new functionality)		The device attempts to load the configuration file. As an added
	the device tries to use its private key to decrypt the file, and,		step, if the configuration file cannot be parsed, the device tries to
	assuming it validates, installs the new configuration.		use its private key to decrypt the file and, assuming it validates,
			proceeds to install the new, decrypted, configuration.
	Only the "correct" device will have the required private key and be		Only the "correct" device will have the required private key and be
	able to decrypt and use the config file (See Security		able to decrypt and use the configuration file (See Security
	Considerations). An attacker would be able to connect to the network		Considerations (Section 7)). An attacker would be able to connect to
	and get an IP address. They would also be able to retrieve		the network and get an IP address. They would also be able to
	(encrypted) config files by guessing serial numbers (or perhaps the		retrieve (encrypted) configuration files by guessing serial numbers
	server would allow directory listing), but without the private keys		(or perhaps the server would allow directory listing), but without
	an attacker will not be able to decrypt the files.		the private keys an attacker will not be able to decrypt the files.
	3. Vendor Role / Requirements		3. Vendor Role
	This section describes the vendors roles and responsibilities and		This section describes the vendor's roles and provides an overview of
	provides an overview of what the device needs to do.		what the device needs to do.
	3.1. Device key generation		3.1. Device key generation
	Each devices requires a public-private key keypair, and for the		Each device requires a public-private key pair, and for the public
	public part to be published and retrievable by the operator. The		part to be published and retrievable by the operator. The
	cryptograthic 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.
	EST [RFC7030]and [I-D.gutmann-scep] are methods which vendors may		Enrollment over Secure Transport ([RFC7030]) and [I-D.gutmann-scep]
	want to consider.		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 keypair. 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		unique device identifier and the public key to the vendor's
	Certificate Publication Server to be published. The vendor's		Certificate Publication Server to be published. The vendor's
	Certificate Publication Server should only accept certificates from		Certificate Publication Server should only accept certificates from
	the manufacturing facility, and which match vendor defined policies		the manufacturing facility, and which match vendor defined policies
	(for example, extended key usage, extensions, etc.) Note that some		(for example, extended key usage, and extensions) Note that some
	devices may be constrained, and so may send the raw public key and		devices may be constrained, and so may send the raw public key and
	unique device identifier to the certificate publication server, while		unique device identifier to the certificate publication server, while
	more capable devices may generate and send self-signed certificates.		more capable devices may generate and send self-signed certificates.
			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 that would use for
			revocation and aging will not be used and should be ignored by both
			the client and server.
	3.2. Certificate Publication Server		3.2. Certificate Publication Server
	The certificate publication server contains a database of		The certificate publication server contains a database of
	certificates. If newly manufactured devices upload certificates the		certificates. If newly manufactured devices upload certificates the
	certificate publication server can simply publish these; if the		certificate publication server can simply publish these; if the
	devices provide the raw public keys and unique device identifier, the		devices provide the raw public keys and unique device identifier, the
	certificate publication server will need to wrap these in a		certificate publication server will need to wrap these in a
	certificate.		certificate.
	The customers (e.g., Operator_A) query this server with the serial		The customers (e.g., Operator_A) query this server with the serial
	number (or other provided unique identifier) of a device, and		number (or other provided unique identifier) of a device, and
	retrieve the associated certificate. It is expected that operators		retrieve the associated certificate. It is expected that operators
	will receive the unique device identifier (serial number) of devices		will receive the unique device identifier (serial number) of devices
	when they purchase them, and will download and store / cache the		when they purchase them, and will download and store the certificate.
	certificate. This means that there is not a hard requirement on the
	uptime / reachability of the certificate publication server.		This means that there is not a hard requirement on the reachability
			of the certificate publication server.
	+------------+		+------------+
	+------+ |Certificate |		+------+ |Certificate |
	|Device| |Publication |		|Device| |Publication |
	+------+ | Server |		+------+ | Server |
	+------------+		+------------+
	+----------------+ +--------------+		+----------------+ +--------------+
	| +---------+ | | |		| +---------+ | | |
	| | Initial | | | |		| | Initial | | | |
	| | boot? | | | |		| | boot? | | | |
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 36 ¶
	| | | +---+---+ |		| | | +---+---+ |
	| | | | |		| | | | |
	| | | +---v---+ |		| | | +---v---+ |
	| | | |Publish| |		| | | |Publish| |
	| | | +-------+ |		| | | +-------+ |
	| | | |		| | | |
	+----------------+ +--------------+		+----------------+ +--------------+
	Initial certificate generation and publication.		Initial certificate generation and publication.
	4. Operator Role / Responsibilities		4. Operator Role
	4.1. Administrative		4.1. Administrative
	When purchasing a new device, the accounting department will need to		When purchasing a new device, the accounting department will need to
	get the unique device identifier (likely serial number) of the new		get the unique device identifier (e.g., serial number) of the new
	device and communicate it to the operations group.		device and communicate it to the operations group.
	4.2. Technical		4.2. Technical
	The operator will contact the vendor's publication server, and		The operator will contact the vendor's publication server, and
	download the certificate (by providing the unique device identifier		download the certificate (by providing the unique device identifier
	of the device). The operator SHOULD fetch the certificate using a		of the device). The operator fetches the certificate using a secure
	secure transport (e.g., HTTPS). The operator will then encrypt the		transport (e.g., HTTPS). The operator will then encrypt the initial
	initial configuration (for example, using SMIME [RFC5751]) using the		configuration (for example, using SMIME [RFC5751]) using the key in
	key in the certificate, and place it on their TFTP server. See		the certificate, and place it on their configuration server.
	Appendix B for examples.
			See Appendix B for examples.
	+------------+		+------------+
	+--------+ |Certificate |		+--------+ |Certificate |
	|Operator| |Publication |		|Operator| |Publication |
	+--------+ | Server |		+--------+ | Server |
	+------------+		+------------+
	+----------------+ +----------------+		+----------------+ +----------------+
	| +-----------+ | | +-----------+ |		| +-----------+ | | +-----------+ |
	| | Fetch | | | | | |		| | Fetch | | | | | |
	| | Device |<------>|Certificate| |		| | Device |<------>|Certificate| |
	skipping to change at page 8, line 41 ¶		skipping to change at page 8, line 43 ¶
	Fetching the certificate, encrypting the configuration, publishing		Fetching the certificate, encrypting the configuration, publishing
	the encrypted configuration.		the encrypted configuration.
	4.3. Example Initial Customer Boot		4.3. Example Initial Customer Boot
	When the device is first booted by the customer (and on subsequent		When the device is first booted by the customer (and on subsequent
	boots), if the device does not have a valid configuration, it will		boots), if the device does not have a valid configuration, it will
	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 config file. Note		listed in these DHCP options and downloads its configuration file.
	that this is existing functionality (for example, Cisco devices fetch		Note that this is existing functionality (for example, Cisco devices
	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 config file, the device needs to determine if it		After retrieving the configuration file, the device needs to
	is encrypted or not. If it is not encrypted, the existing behavior		determine if it is encrypted or not. If it is not encrypted, the
	is used. If the configuration is encrypted, the process continues as		existing behavior is used. If the configuration is encrypted, the
	described in this document. The method used to determine if the		process continues as described in this document. The method used to
	config is encrypted or not is implementation dependant; there are a		determine if the configuration is encrypted or not is implementation
	number of (obvious) options, including having a magic string in the		dependent; there are a number of (obvious) options, including having
	file header, using a file name extension (e.g., config.enc), or using		a magic string in the file header, using a file name extension (e.g.,
	specific DHCP options.		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
	configurations fails, the device will either abort the auto-install		configuration fails, the device will either abort the auto-install
	process, or will repeat this process until it succeeds. When		process, or repeat this process until it succeeds. When retrying,
	retrying, care should be taken to not overwhelm the server hosting		care should be taken to not overwhelm the server hosting the
	the encrypted configuration files. It is suggested that the device		encrypted configuration files. It is suggested that the device retry
	retry every 5 minutes for the first hour, and then every hour after		every 5 minutes for the first hour, and then every hour after that.
	that. As it is expected that devices may be installed well before		As it is expected that devices may be installed well before the
	the configuration file is ready, a maximum number of retrys is not		configuration file is ready, a maximum number of retries is not
	specified.		specified.
	Note that the device only needs to be able to download the config		Note that the device only needs to be able to download the
	file; after the initial power-on in the factory it never needs to		configuration file; after the initial power-on in the factory it
	access the Internet or vendor or certificate publication server - it		never needs to access the Internet or vendor or certificate
	(and only it) has the private key and so has the ability to decrypt		publication server. The device (and only the device) has the private
	the config file.		key and so has the ability to decrypt the configuration file.
	+--------+ +--------------+		+--------+ +--------------+
	| Device | |Config server |		| Device | |Config server |
	+--------+ | (e.g. TFTP) |		+--------+ | (e.g. TFTP) |
	+--------------+		+--------------+
	+---------------------------+ +------------------+		+---------------------------+ +------------------+
	| +-----------+ | | |		| +-----------+ | | |
	| | | | | |		| | | | | |
	| | DHCP | | | |		| | DHCP | | | |
	| | | | | |		| | | | | |
	skipping to change at page 10, line 46 ¶		skipping to change at page 10, line 46 ¶
	| v | | |		| v | | |
	| / \ | | |		| / \ | | |
	| / \ Y +--------+ | | |		| / \ Y +--------+ | | |
	| |Sane?|---->|Install,| | | |		| |Sane?|---->|Install,| | | |
	| \ / | Boot | | | |		| \ / | Boot | | | |
	| \ / +--------+ | | |		| \ / +--------+ | | |
	| V | | |		| V | | |
	| |N | | |		| |N | | |
	| | | | |		| | | | |
	| +----v---+ | | |		| +----v---+ | | |
	| |Give up,| | | |		| |Retry or| | | |
	| |go home | | | |		| | abort | | | |
	| +--------+ | | |		| +--------+ | | |
	| | | |		| | | |
	+---------------------------+ +------------------+		+---------------------------+ +------------------+
	Device boot, fetch and install config file		Device boot, fetch and install configuration file
	5. Additional Considerations		5. Additional Considerations
	5.1. Key storage		5.1. Key storage
	Ideally, the keypair would be stored in a Trusted Platform Module		Ideally, the key pair would be stored in a Trusted Platform Module
	(TPM) on something which is identified as the "router" - for example,		(TPM) on something which is identified as the "router" - for example,
	the chassis / backplane. This is so that a keypair is bound to what		the chassis / backplane. This is so that a key pair is bound to what
	humans think of as the "device", and not, for example (redundant)		humans think of as the "device", and not, for example (redundant)
	routing engines. Devices which implement IEEE 802.1AR [IEEE802-1AR]		routing engines. Devices which implement IEEE 802.1AR [IEEE802-1AR]
	could choose to use the IDevID for this purpose.		could choose to use the IDevID for this purpose.
	5.2. Key replacement		5.2. Key replacement
	It is anticipated that some operator may want to replace the (vendor		It is anticipated that some operator may want to replace the (vendor
	provided) keys after installing the device. There are two options		provided) keys after installing the device. There are two options
	when implementing this - a vendor could allow the operator's key to		when implementing this: a vendor could allow the operator's key to
	completely replace the initial device generated key (which means		completely replace the initial device-generated key (which means
	that, if the device is ever sold, the new owner couldn't use this		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		technique to install the device), or the device could prefer the
	operators installed key. This is an implementation decision left to		operator's installed key. This is an implementation decision left to
	the vendor.		the vendor.
	5.3. Device reinstall		5.3. Device reinstall
	Increasingly, operations is moving towards an automated model of		Increasingly, operations is moving towards an automated model of
	device management, whereby portions (or the entire) configuration is		device management, whereby portions of (or the entire) configuration
	programmatically generated. This means that operators may want to		is programmatically generated. This means that operators may want to
	generate an entire configuration after the device has been initially		generate an entire configuration after the device has been initially
	installed and ask the device to load and use this new configuration.		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		It is expected (but not defined in this document, as it is vendor
	specific) that vendors will allow the operator to copy a new,		specific) that vendors will allow the operator to copy a new,
	encrypted config (or part of a config) onto a device and then request		encrypted configuration (or part of a configuration) onto a device
	that the device decrypt and install it (e.g.: 'load replace		and then request that the device decrypt and install it (e.g.: 'load
	<filename> encrypted)). The operator could also choose to reset the		replace <filename> encrypted). The operator could also choose to
	device to factory defaults, and allow the device to act as though it		reset the device to factory defaults, and allow the device to act as
	were the initial boot (see Section 4.3).		though it were the initial boot (see Section 4.3).
	6. IANA Considerations		6. IANA Considerations
	This document makes no requests of the IANA.		This document makes no requests of the IANA.
	7. Security Considerations		7. Security Considerations
	This mechanism is intended to replace either expensive (traveling		This reference architecture is intended to incrementally improve upon
	employees) or insecure mechanisms of installing newly deployed		commonly accepted "auto-install" practices used today that may
	devices such as: unencrypted config files which can be downloaded by		transmit configurations unencrypted (e.g., unencrypted configuration
	connecting to unprotected ports in datacenters, mailing initial		files which can be downloaded connecting to unprotected ports in
	config files on flash drives, or emailing config files and asking a		datacenters, mailing initial configuration files on flash drives, or
	third-party to copy and paste it over a serial terminal. It does not		emailing configuration files and asking a third-party to copy and
	protect against devices with malicious firmware, nor theft and reuse		paste them over a serial terminal) or allow unrestricted access to
	of devices.		these configurations.
	An attacker (e.g., a malicious datacenter employee) who has physical		This document describes an object level security design to provide
	access to the device before it is connected to the network the		confidentiality assurances for the configuration while it is in
	attacker may be able to extract the device private key (especially if		transit between the configuration server and the unprovisioned device
	it is not stored in a TPM), pretend to be the device when connecting		even if the underly transport does not provide this security service.
	to the network, and download and extract the (encrypted) config file.
	This mechanism does not protect against a malicious vendor - while		The architecture provides no assurances about the source of the
	the keypair should be generated on the device, and the private key		encrypted configuration or protect against theft and reuse of
			devices.
			An attacker (e.g., a malicious datacenter employee, person in the
			supply chain, etc.) who has physical access to the device before it
			is connected to the network may be able to extract the device private
			key (especially if it is not stored in a TPM), pretend to be the
			device when connecting to the network, and download and extract the
			(encrypted) configuration file.
			An attacker with access to the configuration server (or the ability
			to route traffic to configuration server under their control) and the
			device's public key could return a configuration of the attacker's
			choosing to the unprovisioned device.
			This mechanism does not protect against a malicious vendor. While
			the key pair should be generated on the device, and the private key
	should be securely stored, the mechanism cannot detect or protect		should be securely stored, the mechanism cannot detect or protect
	against a vendor who claims to do this, but instead generates the		against a vendor who claims to do this, but instead generates the key
	keypair off device and keeps a copy of the private key. It is		pair off device and keeps a copy of the private key. It is largely
	largely understood in the operator community that a malicious vendor		understood in the operator community that a malicious vendor or
	or attacker with physical access to the device is largely a "Game		attacker with physical access to the device is largely a "Game Over"
	Over" situation.		situation.
	Even when using a secure bootstrapping mechanism, security conscious		Even when using a secure bootstrap mechanism, security-conscious
	operators may wish to bootstrapping devices with a minimal / less		operators may wish to bootstrap devices with a minimal or less-
	sensitive config, and then replace this with a more complete one		sensitive configuration, and then replace this with a more complete
	after install.		one after install.
	8. Acknowledgments		8. Acknowledgments
	The authors wish to thank everyone who contributed, including Benoit		The authors wish to thank everyone who contributed, including Benoit
	Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael		Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael
	Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided		Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided
	significant comments and review, and Tom Petch provided significant		significant comments and review, and Tom Petch provided significant
	editorial contributions to better describe the use cases, and clarify		editorial contributions to better describe the use cases, and clarify
	the scope.		the scope.
	9. References		Roman Danyliw also provided helpful text around the certificate
			usage.
	9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		9. Informative References
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		[Cisco_AutoInstall]
			Cisco Systems, Inc., "Using AutoInstall to Remotely
			Configure Cisco Networking Devices", Jan 2018,
			<https://www.cisco.com/c/en/us/td/docs/ios-
			xml/ios/fundamentals/configuration/15mt/fundamentals-15-
			mt-book/cf-autoinstall.html>.
	[I-D.gutmann-scep]		[I-D.gutmann-scep]
	Gutmann, P., "Simple Certificate Enrolment Protocol",		Gutmann, P., "Simple Certificate Enrolment Protocol",
	draft-gutmann-scep-16 (work in progress), March 2020.		draft-gutmann-scep-16 (work in progress), March 2020.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,		Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
	and K. Watsen, "Bootstrapping Remote Secure Key		and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-41 (work in progress), April 2020.		keyinfra-41 (work in progress), April 2020.
	skipping to change at page 15, line 45 ¶		skipping to change at page 16, line 11 ¶
	o Make it clear it should first try use the config, and if it		o Make it clear it should first try use the config, and if it
	doesn't work, then try decrypt and use it.		doesn't work, then try decrypt and use it.
	o The CA part was confusing people - the certificate is simply a		o The CA part was confusing people - the certificate is simply a
	wrapper for the key, and the Subject just an index, and so removed		wrapper for the key, and the Subject just an index, and so removed
	that.		that.
	o Added a bunch of ASCII diagrams		o Added a bunch of ASCII diagrams
	Appendix B. Demo / proof of concept		Appendix B. Proof of Concept
	This section contains a rough demo / proof of concept of the system.		This section contains a proof of concept of the system. It is only
	It is only intended for illustration, and is not intended to be used		intended for illustration, and is not intended to be used in
	in production.		production.
	It uses OpenSSL from the command line, in production something more		It uses OpenSSL from the command line. In production something more
	automated would be used. In this example, the unique device		automated would be used. In this example, the unique device
	identifier is the serial number of the router, SN19842256.		identifier is the serial number of the router, SN19842256.
	B.1. Step 1: Generating the certificate.		B.1. Step 1: Generating the certificate.
	This step is performed by the router. It generates a key, then a		This step is performed by the router. It generates a key, then a
	csr, and then a self signed certificate.		Certificate Signing Request (CSR), and then a self signed
			certificate.
	B.1.1. Step 1.1: Generate the private key.		B.1.1. Step 1.1: Generate the private key.
	$ openssl genrsa -out key.pem 2048		$ openssl genrsa -out key.pem 2048
	Generating RSA private key, 2048 bit long modulus		Generating RSA private key, 2048 bit long modulus
	.................................................		.................................................
	.................................................		.................................................
	..........................+++		..........................+++
	...................+++		...................+++
	e is 65537 (0x10001)		e is 65537 (0x10001)
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 13 ¶
	An optional company name []:.		An optional company name []:.
	B.1.3. Step 1.3: Generate the (self signed) certificate itself.		B.1.3. Step 1.3: Generate the (self signed) certificate itself.
	$ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out		$ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out
	SN19842256.crt		SN19842256.crt
	The router then sends the key to the vendor's keyserver for		The router then sends the key to the vendor's keyserver for
	publication (not shown).		publication (not shown).
	B.2. Step 2: Generating the encrypted config.		B.2. Step 2: Generating the encrypted configuration.
	The operator now wants to deploy the new router.		The operator now wants to deploy the new router.
	They generate the initial config (using whatever magic tool generates		They generate the initial configuration (using whatever magic tool
	router configs!), fetch the router's certificate and encrypt the		generates router configs!), fetch the router's certificate and
	config file to that key. This is done by the operator.		encrypt the configuration file to that key. This is done by the
			operator.
	B.2.1. Step 2.1: Fetch the certificate.		B.2.1. Step 2.1: Fetch the certificate.
	$ wget http://keyserv.example.net/certificates/SN19842256.crt		$ wget http://keyserv.example.net/certificates/SN19842256.crt
	B.2.2. Step 2.2: Encrypt the config file.		B.2.2. Step 2.2: Encrypt the configuration file.
	I'm using S/MIME because it is simple to demonstrate. This is almost		S/MIME is used here because it is simple to demonstrate. This is
	definitely not the best way to do this.		almost definitely not the best way to do this.
	$ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\		$ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\
	-out SN19842256.enc -outform PEM SN19842256.crt		-out SN19842256.enc -outform PEM SN19842256.crt
	$ more SN19842256.enc		$ more SN19842256.enc
	-----BEGIN PKCS7-----		-----BEGIN PKCS7-----
	MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV		MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV
	BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3		BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3
	...		...
	LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt		LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt
	-----END PKCS7-----		-----END PKCS7-----
	B.2.3. Step 2.3: Copy config to the config server.		B.2.3. Step 2.3: Copy configuration to the configuration server.
	$ scp SN19842256.enc config.example.com:/tftpboot		$ scp SN19842256.enc config.example.com:/tftpboot
	B.3. Step 3: Decrypting and using the config.		B.3. Step 3: Decrypting and using the configuration.
	When the router connects to the operator's network it will detect		When the router connects to the operator's network it will detect
	that does not have a valid configuration file, and will start the		that does not have a valid configuration file, and will start the
	"autoboot" process. This is a well documented process, but the high		"autoboot" process. This is a well documented process, but the high
	level overview is that it will use DHCP to obtain an IP address and		level overview is that it will use DHCP to obtain an IP address and
	config server. It will then use TFTP to download a configuration		configuration server. It will then use TFTP to download a
	file, based upon its serial number (this document modifies the		configuration file, based upon its serial number (this document
	solution to fetch an encrypted config file (ending in .enc)). It		modifies the solution to fetch an encrypted configuration file
	will then decrypt the config file, and install it.		(ending in .enc)). It will then decrypt the configuration file, and
			install it.
	B.3.1. Step 3.1: Fetch encrypted config file from config server.		B.3.1. Step 3.1: Fetch encrypted configuration file from configuration
			server.
	$ tftp 2001:0db8::23 -c get SN19842256.enc		$ tftp 2001:0db8::23 -c get SN19842256.enc
	B.3.2. Step 3.2: Decrypt and use the config.		B.3.2. Step 3.2: Decrypt and use the configuration.
	$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\		$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
	-out config.cfg -inkey key.pem		-out config.cfg -inkey key.pem
	If an attacker does not have the correct key, they will not be able		If an attacker does not have the correct key, they will not be able
	to decrypt the config:		to decrypt the configuration file:
	$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\		$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
	-out config.cfg -inkey wrongkey.pem		-out config.cfg -inkey wrongkey.pem
	Error decrypting PKCS#7 structure		Error decrypting PKCS#7 structure
	140352450692760:error:06065064:digital envelope		140352450692760:error:06065064:digital envelope
	routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592:		routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592:
	$ echo $?		$ echo $?
	4		4
	Authors' Addresses		Authors' Addresses
End of changes. 77 change blocks.
	212 lines changed or deleted		232 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/