< draft-ietf-opsawg-sdi-07.txt		draft-ietf-opsawg-sdi-08.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 9, 2020 Juniper Networks		Expires: October 23, 2020 Juniper Networks
	April 07, 2020		April 21, 2020
	Secure Device Install		Secure Device Install
	draft-ietf-opsawg-sdi-07		draft-ietf-opsawg-sdi-08
	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 9, 2020.		This Internet-Draft will expire on October 23, 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 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	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. . . . . . . . . . . . 15
	B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15		B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15
	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. . . . . . . . . . . 16
	B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 16		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
	In a growing, global network, significant amounts of time and money		In a growing, global network, significant amounts of time and money
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	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		vendor 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,		security related and/or proprietary information (for example, RADIUS
	RADIUS [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets).		[RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing
	Exposing these to a third party to load onto a new device (or using		these to a third party to load onto a new device (or using an auto-
	an auto-install techniques which fetch an unencrypted config file via		install techniques which fetch an unencrypted config file via TFTP
	TFTP [RFC1350]) or something similar, is an unacceptable security		[RFC1350]) or something similar, is an unacceptable security risk for
	risk for many operators, and so they send employees to remote		many operators, and so they send employees to remote locations to
	locations to perform the initial configuration work; this costs, time		perform the initial configuration work; this costs, time and money.
	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 devices before shipping it; asking the smart-hands 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; but these are often clumsy and have security
	issues - for example, in the terminal server case, the console port		issues - for example, in the terminal server case, the console port
	connection could be easily snooped.		connection could be easily snooped.
	This document layers security onto existing auto-install solutions to		This document layers security onto existing auto-install solutions to
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 10 ¶
	it is explicitly not intended to be an "all singing, all dancing"		it is explicitly not intended to be an "all singing, all dancing"
	fully featured system for managing installed / deployed devices, nor		fully featured system for managing installed / deployed devices, nor
	is it intended to solve all use-cases - rather it is a simple		is it intended to solve all use-cases - rather it is a simple
	targeted solution to solve a common operational issue where the		targeted solution to solve a common operational issue where the
	network device has been delivered, fibre laid (as appropriate) but		network device has been delivered, fibre laid (as appropriate) but
	there is no trusted member of the operator's staff to perform the		there is no trusted member of the operator's staff to perform the
	initial configuration.		initial configuration.
	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/or are not
	widely deployed yet.		widely deployed yet.
	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,
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	the devices serial number, MAC address or similar. This document		the devices serial number, MAC address or similar. This document
	extends this (vendor specific) paradigm by allowing the configuration		extends this (vendor specific) paradigm by allowing the configuration
	file to be encrypted.		file to be encrypted.
	This document describes a concept, and some example ways of		This document describes a concept, and some example ways of
	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 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
	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
	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 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, 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
	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 keylenghts to be used are out of the		cryptograthic algorithm and key lenghts 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 will vary by		with much of this document the exact mechanism may vary by vendor.
	vendor. [I-D.gutmann-scep] is one method which vendors may want to		EST [RFC7030]and [I-D.gutmann-scep] are methods which vendors may
	strongly 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 identifier and the public key to the vendor's Certificate		unique device identifier and the public key to the vendor's
	Publication Server to be published. The vendor's Certificate		Certificate Publication Server to be published. The vendor's
	Publication Server should only accept certificates from the		Certificate Publication Server should only accept certificates from
	manufacturing facility, and which match vendor defined policies (for		the manufacturing facility, and which match vendor defined policies
	example, extended key usage, extensions, etc.) Note that some		(for example, extended key usage, extensions, etc.) 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 identifier to the certificate publication server, while more		unique device identifier to the certificate publication server, while
	capable devices may generate and send self-signed certificates.		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 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. Note that the certificate publication server MUST only		certificate.
	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 device identifier (serial number)
	devices when they purchase them, and will download and store / cache		of devices when they purchase them, and will download and store /
	the certificate. This means that there is not a hard requirement on		cache the certificate. This means that there is not a hard
	the uptime / reachability of the certificate publication server.		requirement on the uptime / reachability of the certificate
			publication server.
	+------------+		+------------+
	+------+ |Certificate |		+------+ |Certificate |
	|Device| |Publication |		|Device| |Publication |
	+------+ | Server |		+------+ | Server |
	+------------+		+------------+
	+----------------+ +--------------+		+----------------+ +--------------+
	| +---------+ | | |		| +---------+ | | |
	| | Initial | | | |		| | Initial | | | |
	| | boot? | | | |		| | boot? | | | |
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	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), contact the server listed		(Server-Name) or 150 (TFTP server address), contacts the server
	in these DHCP options and downloads its config file. Note that this		listed in these DHCP options and downloads its config file. Note
	is existing functionality (for example, Cisco devices fetch the		that this is existing functionality (for example, Cisco devices fetch
	config file named by the Bootfile-Name DHCP option (67)).		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 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. If able, it will install the configuration, and
	start using it. If this fails, the device with either abort the		start using it. If it cannot decrypt the file, or if parsing the
	auto-install process, or will repeat this process until it succeeds.		configurations fails, the device will either abort the auto-install
			process, or will repeat this process until it succeeds.
	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 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 | | | |		| |Give up,| | | |
	| |go home | | | |		| |go home | | | |
	| +--------+ | | |		| +--------+ | | |
	| | | |		| | | |
	+---------------------------+ +------------------+		+---------------------------+ +------------------+
	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
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	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 is not 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.
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 15 ¶
	9.2. Informative References		9.2. Informative References
	[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-40 (work in progress), April 2020.		keyinfra-41 (work in progress), April 2020.
	[I-D.ietf-opsawg-tacacs]		[I-D.ietf-opsawg-tacacs]
	Dahm, T., Ota, A., dcmgash@cisco.com, d., Carrel, D., and		Dahm, T., Ota, A., dcmgash@cisco.com, d., Carrel, D., and
	L. Grant, "The TACACS+ Protocol", draft-ietf-opsawg-		L. Grant, "The TACACS+ Protocol", draft-ietf-opsawg-
	tacacs-18 (work in progress), March 2020.		tacacs-18 (work in progress), March 2020.
	[IEEE802-1AR]		[IEEE802-1AR]
	IEEE, "IEEE Standard for Local and Metropolitan Area		IEEE, "IEEE Standard for Local and Metropolitan Area
	Networks - Secure Device Identity", June 2018,		Networks - Secure Device Identity", June 2018,
	<https://standards.ieee.org/standard/802_1AR-2018.html>.		<https://standards.ieee.org/standard/802_1AR-2018.html>.
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 5 ¶
	[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>.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, DOI 10.17487/RFC5751, January		Specification", RFC 5751, DOI 10.17487/RFC5751, January
	2010, <https://www.rfc-editor.org/info/rfc5751>.		2010, <https://www.rfc-editor.org/info/rfc5751>.
			[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
			"Enrollment over Secure Transport", RFC 7030,
			DOI 10.17487/RFC7030, October 2013,
			<https://www.rfc-editor.org/info/rfc7030>.
	[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 -03 to -04		From -03 to -04
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 39 ¶
	o Added a bunch of ASCII diagrams		o Added a bunch of ASCII diagrams
	Appendix B. Demo / proof of concept		Appendix B. Demo / proof of concept
	This section contains a rough demo / proof of concept of the system.		This section contains a rough demo / proof of concept of the system.
	It is only intended for illustration, and is not intended to be used		It is only intended for illustration, and is not intended to be used
	in production.		in 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 identifier is		automated would be used. In this example, the unique device
	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.		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
End of changes. 22 change blocks.
	48 lines changed or deleted		52 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/