< draft-ietf-opsawg-sdi-09.txt		draft-ietf-opsawg-sdi-10.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 8, 2020 Juniper Networks		Expires: November 12, 2020 Juniper Networks
	May 7, 2020		May 11, 2020
	Secure Device Install		Secure Device Install
	draft-ietf-opsawg-sdi-09		draft-ietf-opsawg-sdi-10
	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 November 8, 2020.		This Internet-Draft will expire on November 12, 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 51 ¶		skipping to change at page 2, line 51 ¶
	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. . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . . . . . . 16
	B.2. Step 2: Generating the encrypted config. . . . . . . . . 16		B.2. Step 2: Generating the encrypted config. . . . . . . . . 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 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. . . . . . . . . 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 datacenters (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
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	instead be HTTP, FTP, etc. ]		instead 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 Point of Presence
	(POP) / datacenter. Vendor_B begins assembling the new device, and		(POP) / datacenter. Vendor_B begins assembling the new device, and
	tells Operator_A what the new device's serial number will be		tells Operator_A what the new device's serial number will be
	(SN:17894321). When Vendor_B 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 Vendor_B publishes the public key on their keyserver (in a public
	certificate, for ease of use).		key certificate, for ease 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, 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 config 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'
	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
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 18 ¶
	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
	Each devices requires a public-private key keypair, and for the		Each devices requires a public-private key keypair, and for the
	public part to be published and retrievable by the operator. The		public part to be published and retrievable by the operator. The
	cryptograthic algorithm and key lenghts to be used are out of the		cryptograthic 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		EST [RFC7030]and [I-D.gutmann-scep] are methods which vendors may
	want to consider.		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 keypair. 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
	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		From -09 to -10
			o Typos - "lenghts" => "lengths", missed a reference to Acme.
			From -08 to -09
	o Addressed Mirja's IETF LC comments.		o Addressed Mirja's IETF LC comments.
	From -04 to -08		From -04 to -08
	o Please see GitHub commit log (I forgot to put them in here :-P )		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
End of changes. 8 change blocks.
	10 lines changed or deleted		14 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/