< draft-ietf-opsawg-sdi-02.txt		draft-ietf-opsawg-sdi-03.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: August 4, 2020 Juniper Networks		Expires: August 14, 2020 Juniper Networks
	February 01, 2020		February 11, 2020
	Secure Device Install		Secure Device Install
	draft-ietf-opsawg-sdi-02		draft-ietf-opsawg-sdi-03
	Abstract		Abstract
	Deploying a new network device often requires that an employee		Deploying a new network device often requires that an employee
	physically travel to a datacenter to perform the initial install and		physically travel to a datacenter to perform the initial install and
	configuration, even in shared datacenters with "smart-hands" type		configuration, even in shared datacenters with "smart-hands" type
	support. In many cases, this could be avoided if there were a		support. In many cases, this could be avoided if there were a
	standard, secure way to initially provision the devices.		standard, secure way to initially provision the devices.
	This document extends existing auto-install / Zero-Touch Provisioning		This document extends existing auto-install / Zero-Touch Provisioning
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 August 4, 2020.		This Internet-Draft will expire on August 14, 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		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
	2. Overview / Example Scenario . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
			2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 4
	3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5		3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5
	3.1. Device key generation . . . . . . . . . . . . . . . . . . 5		3.1. Device key generation . . . . . . . . . . . . . . . . . . 5
	3.2. Certificate Publication Server . . . . . . . . . . . . . 5		3.2. Certificate Publication Server . . . . . . . . . . . . . 6
	4. Operator Role / Responsibilities . . . . . . . . . . . . . . 6		4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7
	4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 6		4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 7		4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 8
	5. Additional Considerations . . . . . . . . . . . . . . . . . . 10		5. Additional Considerations . . . . . . . . . . . . . . . . . . 10
	5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10		5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10		5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12
	Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 13		Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 13
	B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13		B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13
	B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 13		B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 13
	B.1.2. Step 1.2: Generate the certificate signing request. . 13		B.1.2. Step 1.2: Generate the certificate signing request. . 14
	B.1.3. Step 1.3: Generate the (self signed) certificate		B.1.3. Step 1.3: Generate the (self signed) certificate
	itself. . . . . . . . . . . . . . . . . . . . . . . . 14		itself. . . . . . . . . . . . . . . . . . . . . . . . 14
	B.2. Step 2: Generating the encrypted config. . . . . . . . . 14		B.2. Step 2: Generating the encrypted config. . . . . . . . . 14
	B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14		B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14
	B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14		B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14
	B.2.3. Step 2.3: Copy config to the config server. . . . . . 15		B.2.3. Step 2.3: Copy config to the config server. . . . . . 15
	B.3. Step 3: Decrypting and using the config. . . . . . . . . 15		B.3. Step 3: Decrypting and using the config. . . . . . . . . 15
	B.3.1. Step 3.1: Fetch encrypted config file from config		B.3.1. Step 3.1: Fetch encrypted config file from config
	server. . . . . . . . . . . . . . . . . . . . . . . . 15		server. . . . . . . . . . . . . . . . . . . . . . . . 15
	B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15		B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 17 ¶
	not widely deployed yet.		not widely deployed yet.
	1.1. Requirements notation		1.1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Overview / Example Scenario		2. Overview
			Most network devices already include some sort of initial
			bootstrapping logic (sometimes called 'autoboot', or 'autoinstall').
			This generally works by having a newly installed / unconfigured
			device obtain an IP address and address of a config server (often
			called 'next-server', 'siaddr' or 'tftp-server-name') using DHCP.
			The device then contacts this configuration server to download its
			initial configuration, which is often identified using the devices
			serial number, MAC address or similar. This document extends this
			(vendor specific) paradigm by allowing the configuration file to be
			encrypted.
			This document uses the serial number of the device as a unique
			identifier for simplicity; some vendors may not want to implement the
			system using the serial number as the identifier for business reasons
			(a competitor or similar could enumerate the serial numbers and
			determine how many devices have been manufactured). Implementors are
			free to choose some other way of generating identifiers (e.g UUID
			[RFC4122]), but this will likely make it somewhat harder for
			operators to use (the serial number is usually easy to find on a
			device, a more complex system is likely harder to track).
			[ Ed note: This example also uses TFTP because that is what many
			vendors use in their auto-install / ZTP feature. It could easily
			instead be HTTP, FTP, etc. ]
			2.1. Example Scenario
	Sirius Cybernetics Corp needs another peering router, and so they		Sirius Cybernetics Corp needs another peering router, and so they
	order another router from Acme Network Widgets, to be drop-shipped to		order another router from Acme Network Widgets, to be drop-shipped to
	the Point of Presence (POP) / datacenter. Acme begins assembling the		the Point of Presence (POP) / datacenter. Acme begins assembling the
	new device, and tells Sirius what the new device's serial number will		new device, and tells Sirius what the new device's serial number will
	be (SN:17894321). When Acme first installs the firmware on the		be (SN:17894321). When Acme first installs the firmware on the
	device and boots it, the device generates a public-private keypair,		device and boots it, the device generates a public-private keypair,
	and Acme publishes it on their keyserver (in a certificate, for ease		and Acme publishes it on their keyserver (in a certificate, for ease
	of use).		of use).
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 32 ¶
	assuming it validates, installs the new configuration.		assuming it validates, installs the new 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 config file (See Security
	Considerations). An attacker would be able to connect to the network		Considerations). An attacker would be able to connect to the network
	and get an IP address. They would also be able to retrieve		and get an IP address. They would also be able to retrieve
	(encrypted) config files by guessing serial numbers (or perhaps the		(encrypted) config files by guessing serial numbers (or perhaps the
	server would allow directory listing), but without the private keys		server would allow directory listing), but without the private keys
	an attacker will not be able to decrypt the files.		an attacker will not be able to decrypt the files.
	This document uses the serial number of the device as a unique
	identifier for simplicity; some vendors may not want to implement the
	system using the serial number as the identifier for business reasons
	(a competitor or similar could enumerate the serial numbers and
	determine how many devices have been manufactured). Implementors are
	free to choose some other way of generating identifiers (e.g UUID
	[RFC4122]), but this will likely make it somewhat harder for
	operators to use (the serial number is usually easy to find on a
	device, a more complex system is likely harder to track).
	[ Ed note: This example uses TFTP because that is what many vendors
	use in their auto-install / ZTP feature. It could easily instead be
	HTTP, FTP, etc. ]
	3. Vendor Role / Requirements		3. Vendor Role / Requirements
	This section describes the vendors roles and responsibilities and		This section describes the vendors roles and responsibilities and
	provides an overview of what the device needs to do.		provides an overview of what the device needs to do.
	3.1. Device key generation		3.1. Device key generation
	During the manufacturing stage, when the device is intially 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 keypair. It will send its
	unique identifier and the public key to the vendor's Certificate		unique identifier and the public key to the vendor's Certificate
	Publication Server to be published. The mechanism used to do this is		Publication Server to be published. The mechanism used to do this is
	left undefined. Note that some devices may be contrained, and so may		left undefined. Note that some devices may be constrained, and so
	send the raw public key and unique identifier to the certificate		may send the raw public key and unique identifier to the certificate
	publication server, while mode capable devices may generate and send		publication server, while mode capable devices may generate and send
	self-signed certifcates.		self-signed certificates.
	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 raw public keys and unique identfiers the certificate		devices provide raw public keys and unique identifiers the
	publication server will need to wrap these in a certificate. Note		certificate publication server will need to wrap these in a
	that the certificat publication server MUST only accept certifcates		certificate. Note that the certificate publication server MUST only
	or keys from the vendor's manufacturing facilities.		accept certificates or keys from the vendor's manufacturing
			facilities.
	The customers (e.g Sirius Cybernetics Corp) query this server with		The customers (e.g Sirius Cybernetics Corp) query this server with
	the serial number (or other provided unique identifier) of a device,		the serial number (or other provided unique identifier) of a device,
	and retrieve the associated certificate. It is expected that		and retrieve the associated certificate. It is expected that
	operators will receive the unique identifier (serial number) of		operators will receive the unique identifier (serial number) of
	devices when they purchase them, and will download and store / cache		devices when they purchase them, and will download and store / cache
	the certificate. This means that there is not a hard requirement on		the certificate. This means that there is not a hard requirement on
	the uptime / reachability of the certificate publication server.		the uptime / reachability of the certificate publication server.
	+------------+		+------------+
	skipping to change at page 6, line 47 ¶		skipping to change at page 7, line 19 ¶
	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 (likely 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 SHOULD fetch the certificate using a
	secure transport (e.g HTTPS). The operator will then encrypt the		secure transport (e.g HTTPS). The operator will then encrypt the
	initial configuration to the key in the certifcate, and place it on		initial configuration to the key in the certificate, and place it on
	their TFTP server. See Appendix B for examples.		their TFTP server. See Appendix B for examples.
	+------------+		+------------+
	+--------+ |Certificate |		+--------+ |Certificate |
	|Operator| |Publication |		|Operator| |Publication |
	+--------+ | Server |		+--------+ | Server |
	+------------+		+------------+
	+----------------+ +----------------+		+----------------+ +----------------+
	| +-----------+ | | +-----------+ |		| +-----------+ | | +-----------+ |
	| | Fetch | | | | | |		| | Fetch | | | | | |
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 27 ¶
	Name DHCP option (67)).		Name DHCP option (67)).
	If the file appears be "garbage", the device will attempt to decrypt		If the file appears be "garbage", the device will attempt to decrypt
	the configuration file using its private key. If it is able to		the configuration file using its private key. If it is able to
	decrypt and validate the file it will install the configuration, and		decrypt and validate the file it will install the configuration, and
	start using it. The exact method that the device uses to determine		start using it. The exact method that the device uses to determine
	if a config file is "valid" is implementation specific, but a normal		if a config file is "valid" is implementation specific, but a normal
	config file looks significantly different to an encrypted blob.		config file looks significantly different to an encrypted blob.
	Note that the device only needs DHCP and to be able to download the		Note that the device only needs DHCP and to be able to download the
	config file; after the initial power-on in the factory it never need		config file; after the initial power-on in the factory it never needs
	to access the Internet or vendor or certifcate publication server -		to access the Internet or vendor or certificate publication server -
	it (and only it) has the private key and so has the ability to		it (and only it) has the private key and so has the ability to
	decrypt the config file.		decrypt the config file.
	+--------+ +--------------+		+--------+ +--------------+
	| Device | |Config server |		| Device | |Config server |
	+--------+ | (e.g TFTP) |		+--------+ | (e.g TFTP) |
	+--------------+		+--------------+
	+---------------------------+ +------------------+		+---------------------------+ +------------------+
	| +-----------+ | | |		| +-----------+ | | |
	| | | | | |		| | | | | |
	skipping to change at page 12, line 19 ¶		skipping to change at page 12, line 19 ¶
	[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero		[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
	Touch Provisioning (SZTP)", RFC 8572,		Touch Provisioning (SZTP)", RFC 8572,
	DOI 10.17487/RFC8572, April 2019,		DOI 10.17487/RFC8572, April 2019,
	<https://www.rfc-editor.org/info/rfc8572>.		<https://www.rfc-editor.org/info/rfc8572>.
	Appendix A. Changes / Author Notes.		Appendix A. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
			From individual WG-01 to -03:
			o Addressed Joe Clarke's comments -
			https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw-
			XtWXZIIFhH7aW_-0YY
			o Many typos / nits
			o Broke Overview and Example Scenario into 2 sections.
			o Reordered text for above.
	From individual -04 to WG-01:		From individual -04 to WG-01:
	o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg-		o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg-
	sdi-00		sdi-00
	From -00 to -01		From -00 to -01
	o Nothing changed in the template!		o Nothing changed in the template!
	From -01 to -03:		From -01 to -03:
End of changes. 15 change blocks.
	37 lines changed or deleted		64 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/