< draft-ietf-opsawg-sdi-08.txt		draft-ietf-opsawg-sdi-09.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: October 23, 2020 Juniper Networks		Expires: November 8, 2020 Juniper Networks
	April 21, 2020		May 7, 2020
	Secure Device Install		Secure Device Install
	draft-ietf-opsawg-sdi-08		draft-ietf-opsawg-sdi-09
	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 datacenters with "smart-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.
	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 October 23, 2020.		This Internet-Draft will expire on November 8, 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 2, line 46 ¶		skipping to change at page 2, line 46 ¶
	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. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		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. Demo / proof of concept . . . . . . . . . . . . . . 15
	B.1. Step 1: Generating the certificate. . . . . . . . . . . . 15		B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16
	B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15		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. . . . . . . . . . . . . . . . . . . . . . . . 16
	B.2. Step 2: Generating the encrypted config. . . . . . . . . 16		B.2. Step 2: Generating the encrypted config. . . . . . . . . 16
	B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 16		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 config file. . . . . . . . . . 17
	B.2.3. Step 2.3: Copy config to the config server. . . . . . 17		B.2.3. Step 2.3: Copy config to the config server. . . . . . 17
	B.3. Step 3: Decrypting and using the config. . . . . . . . . 17		B.3. Step 3: Decrypting and using the config. . . . . . . . . 17
	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. . . . . . . . . . . . . . . . . . . . . . . . 17		server. . . . . . . . . . . . . . . . . . . . . . . . 17
	B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17		B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	[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 / ZTP feature. It could easily
	instead be HTTP, FTP, etc. ]		instead be HTTP, FTP, etc. ]
	2.1. Example Scenario		2.1. Example Scenario
	Sirius Cybernetics Corp needs another peering router, and so they		Operator_A needs another peering router, and so they order another
	order another router from Acme Network Widgets, to be drop-shipped to		router from Vendor_B, to be drop-shipped to the Point of Presence
	the Point of Presence (POP) / datacenter. Acme begins assembling the		(POP) / datacenter. Vendor_B begins assembling the new device, and
	new device, and tells Sirius what the new device's serial number will		tells Operator_A what the new device's serial number will be
	be (SN:17894321). When Acme first installs the firmware on the		(SN:17894321). When Vendor_B 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 the public key on their keyserver (in a public key		and Acme publishes the public key on their keyserver (in a public key
	certificate, for ease of use).		certificate, for ease of use).
	While the device is being shipped, Sirius generates the initial		While the device is being shipped, Operator_A generates the initial
	device configuration, fetches the certificate from Acme keyservers by		device configuration, fetches the certificate from Vendor_B
	providing the serial number of the new device. Sirius then encrypts		keyservers by providing the serial number of the new device.
	the device configuration and puts this encrypted config on a (local)		Operator_A then encrypts the device configuration and puts this
	TFTP server.		encrypted config on a (local) TFTP server.
	When the device arrives at the POP, it gets installed in Sirius'		When the device arrives at the POP, it gets installed in Operator_A'
	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. Sirius' DHCP server		autoboot state, and begins the DHCP process. Operator_A' DHCP server
	provides it with an IP address and the address of the configuration		provides it with an IP address and the address of the configuration
	server. The router uses TFTP to fetch its config file (note that all		server. The router uses TFTP to fetch its config file (note that all
	this is existing functionality). The device attempts to load the		this is existing functionality). The device attempts to load the
	config file - if the config file is unparsable, (new functionality)		config file - if the config file is unparsable, (new functionality)
	the device tries to use its private key to decrypt the file, and,		the device tries to use its private key to decrypt the file, and,
	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
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	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., Sirius Cybernetics Corp) query this server with		The customers (e.g., Operator_A) query this server with the serial
	the serial number (or other provided unique identifier) of a device,		number (or other provided unique identifier) of a device, and
	and retrieve the associated certificate. It is expected that		retrieve the associated certificate. It is expected that operators
	operators will receive the unique device identifier (serial number)		will receive the unique device identifier (serial number) of devices
	of devices when they purchase them, and will download and store /		when they purchase them, and will download and store / cache the
	cache the certificate. This means that there is not a hard		certificate. This means that there is not a hard requirement on the
	requirement on the uptime / reachability of the certificate		uptime / reachability of the certificate publication server.
	publication server.
	+------------+		+------------+
	+------+ |Certificate |		+------+ |Certificate |
	|Device| |Publication |		|Device| |Publication |
	+------+ | Server |		+------+ | Server |
	+------------+		+------------+
	+----------------+ +--------------+		+----------------+ +--------------+
	| +---------+ | | |		| +---------+ | | |
	| | Initial | | | |		| | Initial | | | |
	| | boot? | | | |		| | boot? | | | |
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 9 ¶
	described in this document. The method used to determine if the		described in this document. The method used to determine if the
	config is encrypted or not is implementation dependant; there are a		config is encrypted or not is implementation dependant; there are a
	number of (obvious) options, including having a magic string in the		number of (obvious) options, including having a magic string in the
	file header, using a file name extension (e.g., config.enc), or using		file header, using a file name extension (e.g., config.enc), or using
	specific DHCP options.		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		configurations fails, the device will either abort the auto-install
	process, or will repeat this process until it succeeds.		process, or will repeat this process until it succeeds. When
			retrying, care should be taken to not overwhelm the server hosting
			the encrypted configuration files. It is suggested that the device
			retry every 5 minutes for the first hour, and then every hour after
			that. As it is expected that devices may be installed well before
			the configuration file is ready, a maximum number of retrys is not
			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 config
	file; after the initial power-on in the factory it never needs to		file; after the initial power-on in the factory it never needs to
	access the Internet or vendor or certificate publication server - it		access the Internet or vendor or certificate publication server - it
	(and only it) has the private key and so has the ability to decrypt		(and only it) has the private key and so has the ability to decrypt
	the config file.		the config file.
	+--------+ +--------------+		+--------+ +--------------+
	| Device | |Config server |		| Device | |Config server |
	+--------+ | (e.g. TFTP) |		+--------+ | (e.g. TFTP) |
	skipping to change at page 12, line 31 ¶		skipping to change at page 12, line 31 ¶
	Over" situation.		Over" situation.
	Even when using a secure bootstrapping mechanism, security conscious		Even when using a secure bootstrapping mechanism, security conscious
	operators may wish to bootstrapping devices with a minimal / less		operators may wish to bootstrapping devices with a minimal / less
	sensitive config, and then replace this with a more complete one		sensitive config, and then replace this with a more complete one
	after install.		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, Sam Ribeiro, Michael Richardson, Sean Turner		Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael
	and Kent Watsen. Joe Clarke also provided significant comments and		Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided
	review, and Tom Petch provided significant editorial contributions to		significant comments and review, and Tom Petch provided significant
	better describe the use cases, and clarify the scope.		editorial contributions to better describe the use cases, and clarify
			the scope.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, 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 -08 to -08
			o Addressed Mirja's IETF LC comments.
			From -04 to -08
			o Please see GitHub commit log (I forgot to put them in here :-P )
	From -03 to -04		From -03 to -04
	o Addressed Joe's WGLC comments. This involved changing the "just		o Addressed Joe's WGLC comments. This involved changing the "just
	try decrypt and pray" to vendor specific, like a file extension,		try decrypt and pray" to vendor specific, like a file extension,
	magic header sting, etc.		magic header sting, etc.
	o Addressed tom's comments.		o Addressed tom's comments.
	From individual WG-01 to -03:		From individual WG-01 to -03:
End of changes. 13 change blocks.
	32 lines changed or deleted		46 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/