< draft-ietf-opsawg-sdi-04.txt		draft-ietf-opsawg-sdi-05.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: September 5, 2020 Juniper Networks		Expires: September 7, 2020 Juniper Networks
	March 04, 2020		March 06, 2020
	Secure Device Install		Secure Device Install
	draft-ietf-opsawg-sdi-04		draft-ietf-opsawg-sdi-05
	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 September 5, 2020.		This Internet-Draft will expire on September 7, 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 40 ¶		skipping to change at page 2, line 40 ¶
	4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7		4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7
	4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7		4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 8		4.3. 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 13		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 13
	Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 14		Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 14
	B.1. Step 1: Generating the certificate. . . . . . . . . . . . 14		B.1. Step 1: Generating the certificate. . . . . . . . . . . . 14
	B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 14		B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15
	B.1.2. Step 1.2: Generate the certificate signing request. . 15		B.1.2. Step 1.2: Generate the certificate signing request. . 15
	B.1.3. Step 1.3: Generate the (self signed) certificate		B.1.3. Step 1.3: Generate the (self signed) certificate
	itself. . . . . . . . . . . . . . . . . . . . . . . . 15		itself. . . . . . . . . . . . . . . . . . . . . . . . 15
	B.2. Step 2: Generating the encrypted config. . . . . . . . . 15		B.2. Step 2: Generating the encrypted config. . . . . . . . . 15
	B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 15		B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 15
	B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 16		B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 16
	B.2.3. Step 2.3: Copy config to the config server. . . . . . 16		B.2.3. Step 2.3: Copy config to the config server. . . . . . 16
	B.3. Step 3: Decrypting and using the config. . . . . . . . . 16		B.3. Step 3: Decrypting and using the config. . . . . . . . . 16
	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. . . . . . . . . . . . . . . . . . . . . . . . 16		server. . . . . . . . . . . . . . . . . . . . . . . . 16
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	implementing this concept. As devices have different capabilities,		implementing this concept. As devices have different capabilities,
	and use different configuration paradigms, one method will not suit		and use different configuration paradigms, one method will not suit
	all, and so it is expected that vendors will differ in exactly how		all, and so it is expected that vendors will differ in exactly how
	they implement this.		they implement this.
	This document uses the serial number of the device as a unique		This document uses the serial number of the device as a unique
	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 / 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		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 public key
	of use).		certificate, for ease of use).
	While the device is being shipped, Sirius generates the initial		While the device is being shipped, Sirius generates the initial
	device configuration, fetches the certificate from Acme keyservers by		device configuration, fetches the certificate from Acme keyservers by
	providing the serial number of the new device. Sirius then encrypts		providing the serial number of the new device. Sirius then encrypts
	the device configuration and puts this encrypted config on a (local)		the device configuration and puts this encrypted config on a (local)
	TFTP server.		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 Sirius'
	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 12 ¶		skipping to change at page 6, line 12 ¶
	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.
	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
			public part to be published and retrievable by the operator. This
			section illustrates one method, but, as with much of this document
			the exact mechanism may will vary by vendor. [I-D.gutmann-scep] is
			one method which vendors may want to strongly 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 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 vendor's Certificate
	left undefined. Note that some devices may be constrained, and so		Publication Server should only accept certificates from the
	may send the raw public key and unique identifier to the certificate		manufacturing facility, and which match vendor defined policies (for
	publication server, while mode capable devices may generate and send		example, extended key usage, extensions, etc.) Note that some
	self-signed certificates.		devices may be constrained, and so may send the raw public key and
			unique identifier to the certificate publication server, while more
			capable devices may generate and send 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 identifiers the		devices provide raw public keys and unique identifiers the
	certificate publication server will need to wrap these in a		certificate publication server will need to wrap these in a
	certificate. Note that the certificate publication server MUST only		certificate. Note that the certificate publication server MUST only
	accept certificates or keys from the vendor's manufacturing		accept certificates or keys from the vendor's manufacturing
	facilities.		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.
	+------------+		+------------+
	+------+ |Certificate |		+------+ |Certificate |
	|Device| |Publication |		|Device| |Publication |
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	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 certificate, and place it on		initial configuration (for example, using SMIME) using the key in the
	their TFTP server. See Appendix B for examples.		certificate, and place it on their TFTP server. 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 39 ¶		skipping to change at page 8, line 39 ¶
	+----------------+ +----------------+		+----------------+ +----------------+
	Fetching the certificate, encrypting the configuration, publishing		Fetching the certificate, encrypting the configuration, publishing
	the encrypted configuration.		the encrypted configuration.
	4.3. Initial Customer Boot		4.3. 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 or		DHCP Discovery until it gets a DHCP offer including DHCP option 66
	150, contact the server listed in these DHCP options and downloads		(Server-Name) or 150 (TFTP server address), contact the server listed
	its config file. Note that this is existing functionality (for		in these DHCP options and downloads its config file. Note that this
	example, Cisco devices fetch the config file named by the Bootfile-		is existing functionality (for example, Cisco devices fetch the
	Name DHCP option (67)).		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 config file, the device needs to determine if it
	is encrypted or not. If it is not encrypted, the existing behavior		is encrypted or not. If it is not encrypted, the existing behavior
	is used. If the configuration is encrypted, the process continues as		is used. If the configuration is encrypted, the process continues as
	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. It able, it will install the configuration, and		parse the file. It able, it will install the configuration, and
	start using it. If this fails, the device with either abort the		start using it. If this fails, the device with either abort the
	auto-install process, or will repeat this process until it succeeds.		auto-install process, or will repeat this process until it succeeds.
	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 needs		config file; after the initial power-on in the factory it never needs
	to access the Internet or vendor or certificate 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) |
	+--------------+		+--------------+
	+---------------------------+ +------------------+		+---------------------------+ +------------------+
	| +-----------+ | | |		| +-----------+ | | |
	| | | | | |		| | | | | |
	| | DHCP | | | |		| | DHCP | | | |
	| | | | | |		| | | | | |
	| +-----+-----+ | | |		| +-----+-----+ | | |
	| | | | |		| | | | |
	| +-----v------+ | | +-----------+ |		| +-----v------+ | | +-----------+ |
	| | | | | | Encrypted | |		| | | | | | Encrypted | |
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 9 ¶
	| +--------+ | | |		| +--------+ | | |
	| | | |		| | | |
	+---------------------------+ +------------------+		+---------------------------+ +------------------+
	Device boot, fetch and install config file		Device boot, fetch and install config file
	5. Additional Considerations		5. Additional Considerations
	5.1. Key storage		5.1. Key storage
	Ideally, the keypair would be stored in a TPM on something which is		Ideally, the keypair would be stored in a Trusted Platform Module
	identified as the "router" - for example, the chassis / backplane.		(TPM) on something which is identified as the "router" - for example,
	This is so that a keypair is bound to what humans think of as the		the chassis / backplane. This is so that a keypair is bound to what
	"device", and not, for example (redundant) routing engines. Devices		humans think of as the "device", and not, for example (redundant)
	which implement IEEE 802.1AR could choose to use the IDevID for this		routing engines. Devices which implement IEEE 802.1AR could choose
	purpose.		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		operators installed key. This is an implementation decision left to
	skipping to change at page 11, line 37 ¶		skipping to change at page 11, line 37 ¶
	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 (or the entire) configuration is
	programmatically generated. This means that operators may want to		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 config (or part of a config) onto a device and then request
	that the device decrypt and install it (e.g: 'load replace <filename>		that the device decrypt and install it (e.g.: 'load replace
	encrypted)). The operator could also choose to reset the device to		<filename> encrypted)). The operator could also choose to reset the
	factory defaults, and allow the device to act as though it were the		device to factory defaults, and allow the device to act as though it
	initial boot (see Section 4.3).		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 mechanism is intended to replace either expensive (traveling
	employees) or insecure mechanisms of installing newly deployed		employees) or insecure mechanisms of installing newly deployed
	devices such as: unencrypted config files which can be downloaded by		devices such as: unencrypted config files which can be downloaded by
	connecting to unprotected ports in datacenters, mailing initial		connecting to unprotected ports in datacenters, mailing initial
	config files on flash drives, or emailing config files and asking a		config files on flash drives, or emailing config files and asking a
	third-party to copy and paste it over a serial terminal. It does not		third-party to copy and paste it over a serial terminal. It does not
	protect against devices with malicious firmware, nor theft and reuse		protect against devices with malicious firmware, nor theft and reuse
	of devices.		of devices.
	An attacker (e.g a malicious datacenter employee) who has physical		An attacker (e.g., a malicious datacenter employee) who has physical
	access to the device before it is connected to the network the		access to the device before it is connected to the network the
	attacker may be able to extract the device private key (especially if		attacker may be able to extract the device private key (especially if
	it isn't stored in a TPM), pretend to be the device when connecting		it isn't stored in a TPM), pretend to be the device when connecting
	to the network, and download and extract the (encrypted) config file.		to the network, and download and extract the (encrypted) config file.
	This mechanism does not protect against a malicious vendor - while		This mechanism does not protect against a malicious vendor - while
	the keypair should be generated on the device, and the private key		the keypair 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
	keypair off device and keeps a copy of the private key. It is		keypair off device and keeps a copy of the private key. It is
	largely understood in the operator community that a malicious vendor		largely understood in the operator community that a malicious vendor
	or attacker with physical access to the device is largely a "Game		or attacker with physical access to the device is largely a "Game
	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. Acknowledgements		8. Acknowledgments
	The authors wish to thank everyone who contributed, including Benoit		The authors wish to thank everyone who contributed, including Benoit
	Claise, Tom Petch, Sam Ribeiro, Michael Richardson, Sean Turner and		Claise, Francis Dupont, Tom Petch, Sam Ribeiro, Michael Richardson,
	Kent Watsen. Joe Clarke provided significant comments and review.		Sean Turner and Kent Watsen. Joe Clarke also provided significant
			comments and review.
	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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
			[I-D.gutmann-scep]
			Gutmann, P., "Simple Certificate Enrolment Protocol",
			draft-gutmann-scep-15 (work in progress), February 2020.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,		DOI 10.17487/RFC4122, July 2005,
	<https://www.rfc-editor.org/info/rfc4122>.		<https://www.rfc-editor.org/info/rfc4122>.
	[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>.
	skipping to change at page 16, line 33 ¶		skipping to change at page 16, line 33 ¶
	B.3. Step 3: Decrypting and using the config.		B.3. Step 3: Decrypting and using the config.
	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		config server. It will then use TFTP to download a configuration
	file, based upon its serial number (this document modifies the		file, based upon its serial number (this document modifies the
	solution to fetch an encrypted config file (ending in .enc)). It		solution to fetch an encrypted config file (ending in .enc)). It
	will then then decrypt the config file, and install it.		will then decrypt the config 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 config file from config server.
	$ tftp 192.0.2.1 -c get SN19842256.enc		$ tftp 192.0.2.1 -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 config.
	$ 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
End of changes. 22 change blocks.
	41 lines changed or deleted		55 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/