draft-ietf-ace-coap-est-10.txt		draft-ietf-ace-coap-est-11.txt
	ACE P. van der Stok		ACE P. van der Stok
	Internet-Draft Consultant		Internet-Draft Consultant
	Intended status: Standards Track P. Kampanakis		Intended status: Standards Track P. Kampanakis
	Expires: September 9, 2019 Cisco Systems		Expires: November 18, 2019 Cisco Systems
	M. Richardson		M. Richardson
	SSW		SSW
	S. Raza		S. Raza
	RISE SICS		RISE SICS
	March 8, 2019		May 17, 2019
	EST over secure CoAP (EST-coaps)		EST over secure CoAP (EST-coaps)
	draft-ietf-ace-coap-est-10		draft-ietf-ace-coap-est-11
	Abstract		Abstract
	Enrollment over Secure Transport (EST) is used as a certificate		Enrollment over Secure Transport (EST) is used as a certificate
	provisioning protocol over HTTPS. Low-resource devices often use the		provisioning protocol over HTTPS. Low-resource devices often use the
	lightweight Constrained Application Protocol (CoAP) for message		lightweight Constrained Application Protocol (CoAP) for message
	exchanges. This document defines how to transport EST payloads over		exchanges. This document defines how to transport EST payloads over
	secure CoAP (EST-coaps), which allows constrained devices to use		secure CoAP (EST-coaps), which allows constrained devices to use
	existing EST functionality for provisioning certificates.		existing EST functionality for provisioning certificates.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 9, 2019.		This Internet-Draft will expire on November 18, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 28 ¶		skipping to change at page 2, line 28 ¶
	5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9		5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9
	5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12		5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
	5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12		5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13		5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13
	5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14		5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14
	5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15		5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15
	5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16		5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16
	5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18		5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18
	6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19		6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19
	7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22		8. Deployment limitations . . . . . . . . . . . . . . . . . . . 21
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22		9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22
	9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23		9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 23		10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10.1. EST server considerations . . . . . . . . . . . . . . . 23		10.1. EST server considerations . . . . . . . . . . . . . . . 23
	10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25		10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	13.1. Normative References . . . . . . . . . . . . . . . . . . 26		13.1. Normative References . . . . . . . . . . . . . . . . . . 26
	13.2. Informative References . . . . . . . . . . . . . . . . . 28		13.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30		Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30
	A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31		A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42		C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42
	C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44		C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44
	C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45		C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Change Log		1. Change Log
	EDNOTE: Remove this section before publication		EDNOTE: Remove this section before publication
			-11
			Updated Server-side keygen to simplify motivation and added
			paragraphs in Security considerations to point out that random
			numbers are still needed (feedback from Hannes).
	-10		-10
	Addressed WGLC comments		Addressed WGLC comments
	More consistent request format in the examples.		More consistent request format in the examples.
	Explained root resource difference when there is resource		Explained root resource difference when there is resource
	discovery		discovery
	Clarified when the client is supposed to do discovery		Clarified when the client is supposed to do discovery
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 7 ¶
	.		.
	.		.
	.		.
	POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->		POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->
	<-- (ACK) (2:N2/0/128) (2.01 Created) {Cert resp}		<-- (ACK) (2:N2/0/128) (2.01 Created) {Cert resp}
	Figure 3: EST-COAP enrollment with long wait		Figure 3: EST-COAP enrollment with long wait
	5.8. Server-side Key Generation		5.8. Server-side Key Generation
	Constrained devices sometimes do not have the necessary hardware to		In scenarios where it is desirable that the server generates the
	generate statistically random numbers for private keys and DTLS		private key, server-side key generation should be used. Such
	ephemeral keys. Past experience has also shown that low-resource		scenarios could be when it is considered more secure to generate at
	endpoints sometimes generate numbers which could allow someone to		the server the long-lived random private key that identifies the
	decrypt the communication or guess the private key and impersonate as		client, or when the resources spent to generate a random private key
	the device [PsQs] [RSAorig]. Additionally, random number key		at the client are considered scarce, or when the security policy
	generation is costly, thus energy draining. Even though the random		requires that the certificate public and corresponding private keys
	numbers that constitute the identity/cert do not get generated often,		are centrally generated and controlled. Of course, that does not
	an endpoint may not want to spend time and energy generating		eliminate the need for proper random numbers in various protocols
	keypairs, and just ask for one from the server.		like (D)TLS (Section 10.1).
	In these scenarios, server-side key generation can be used. The		When requesting server-side key generation, the client asks for the
	client asks for the server or proxy to generate the private key and		server or proxy to generate the private key and the certificate which
	the certificate which are transferred back to the client in the		are transferred back to the client in the server-side key generation
	server-side key generation response. In all respects, the server		response. In all respects, the server SHOULD treat the CSR as it
	SHOULD treat the CSR as it would treat any enroll or re-enroll CSR;		would treat any enroll or re-enroll CSR; the only distinction here is
	the only distinction here is that the server MUST ignore the public		that the server MUST ignore the public key values and signature in
	key values and signature in the CSR. These are included in the		the CSR. These are included in the request only to allow re-use of
	request only to allow re-use of existing codebases for generating and		existing codebases for generating and parsing such requests.
	parsing such requests.
	The client /skg request is for a certificate in a PKCS#7 container		The client /skg request is for a certificate in a PKCS#7 container
	and private key in two application/multipart-core elements.		and private key in two application/multipart-core elements.
	Respectively, an /skc request is for a single application/pkix-cert		Respectively, an /skc request is for a single application/pkix-cert
	certificate and a private key. The private key Content-Format		certificate and a private key. The private key Content-Format
	requested by the client is depicted in the PKCS#10 CSR request. If		requested by the client is depicted in the PKCS#10 CSR request. If
	the request contains SMIMECapabilities and DecryptKeyIdentifier or		the request contains SMIMECapabilities and DecryptKeyIdentifier or
	AsymmetricDecryptKeyIdentifier the client is expecting Content-Format		AsymmetricDecryptKeyIdentifier the client is expecting Content-Format
	280 for the private key. Then the private key is encrypted		280 for the private key. Then the private key is encrypted
	symmetrically or asymmetrically as per [RFC7030]. The symmetric key		symmetrically or asymmetrically as per [RFC7030]. The symmetric key
	skipping to change at page 23, line 41 ¶		skipping to change at page 23, line 25 ¶
	10. Security Considerations		10. Security Considerations
	10.1. EST server considerations		10.1. EST server considerations
	The security considerations of Section 6 of [RFC7030] are only		The security considerations of Section 6 of [RFC7030] are only
	partially valid for the purposes of this document. As HTTP Basic		partially valid for the purposes of this document. As HTTP Basic
	Authentication is not supported, the considerations expressed for		Authentication is not supported, the considerations expressed for
	using passwords do not apply.		using passwords do not apply.
	Given that the client has only limited resources and may not be able		Modern security protocols require random numbers to be available
	to generate sufficiently random keys to encrypt its identity, it is		during the protocol run, for example for nonces, ephemeral (EC)
	possible that the client uses server generated private/public keys.		Diffie-Hellman key generation. This capability to generate random
	The transport of these keys is inherently risky. Analysis SHOULD be		numbers is also needed when the constrained device generates the
	done to establish whether server-side key generation enhances or		private key (that corresponds to the public key enrolled in the CSR).
	decreases the probability of identity stealing.		When server-side key generation is used, the constrained device
			depends on the server to generate the private key randomly, but it
			still needs locally generated random numbers for use in security
			protocols, as explained in Section 12 of [RFC7925]. Additionally,
			the transport of keys generated at the server is inherently risky.
			Analysis SHOULD be done to establish whether server-side key
			generation increases or decreases the probability of digital identity
			theft.
			It is important to note that sources contributing to the randomness
			pool used to generate random numbers on laptops or desktop PCs are
			not available on many constrained devices, such as mouse movement,
			timing of keystrokes, air turbulence on the movement of hard drive
			heads, as pointed out in [PsQs]. Other sources have to be used or
			dedicated hardware has to be added. Selecting hardware for an IoT
			device that is capable of producing high-quality random numbers is
			therefore important [RSAfact].
	It is also RECOMMENDED that the Implicit Trust Anchor database used		It is also RECOMMENDED that the Implicit Trust Anchor database used
	for EST server authentication is carefully managed to reduce the		for EST server authentication is carefully managed to reduce the
	chance of a third-party CA with poor certification practices		chance of a third-party CA with poor certification practices
	jeopardizing authentication. Disabling the Implicit Trust Anchor		jeopardizing authentication. Disabling the Implicit Trust Anchor
	database after successfully receiving the Distribution of CA		database after successfully receiving the Distribution of CA
	certificates response (Section 4.1.3 of [RFC7030]) limits any risk to		certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
	the first DTLS exchange. Alternatively, in a case where a /sen		the first DTLS exchange. Alternatively, in a case where a /sen
	request immediately follows a /crt, a client MAY choose to keep the		request immediately follows a /crts, a client MAY choose to keep the
	connection authenticated by the Implicit TA open for efficiency		connection authenticated by the Implicit TA open for efficiency
	reasons (Section 4). A client that pipelines EST-coaps /crt request		reasons (Section 4). A client that pipelines EST-coaps /crts request
	with other requests in the same DTLS connection SHOULD revalidate the		with other requests in the same DTLS connection SHOULD revalidate the
	server certificate chain against the updated Explicit TA from the		server certificate chain against the updated Explicit TA from the
	/crt response before proceeding with the subsequent requests. If the		/crts response before proceeding with the subsequent requests. If
	server certificate chain does not authenticate against the database,		the server certificate chain does not authenticate against the
	the client SHOULD close the connection without completing the rest of		database, the client SHOULD close the connection without completing
	the requests. The updated Explicit TA MUST continue to be used in		the rest of the requests. The updated Explicit TA MUST continue to
	new DTLS connections.		be used in new DTLS connections.
	In cases where the IDevID used to authenticate the client is expired		In cases where the IDevID used to authenticate the client is expired
	the server MAY still authenticate the client because IDevIDs are		the server MAY still authenticate the client because IDevIDs are
	expected to live as long as the device itself (Section 4). In such		expected to live as long as the device itself (Section 4). In such
	occasions, checking the certificate revocation status or authorizing		occasions, checking the certificate revocation status or authorizing
	the client using another method is important for the server to ensure		the client using another method is important for the server to ensure
	that the client is to be trusted.		that the client is to be trusted.
	In accordance with [RFC7030], TLS cipher suites that include		In accordance with [RFC7030], TLS cipher suites that include
	"_EXPORT_" and "_DES_" in their names MUST NOT be used. More		"_EXPORT_" and "_DES_" in their names MUST NOT be used. More
	skipping to change at page 26, line 36 ¶		skipping to change at page 26, line 36 ¶
	Camezind, Bjorn Elmers and Joel Hoglund.		Camezind, Bjorn Elmers and Joel Hoglund.
	Robert Moskowitz provided code to create the examples.		Robert Moskowitz provided code to create the examples.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-core-multipart-ct]		[I-D.ietf-core-multipart-ct]
	Fossati, T., Hartke, K., and C. Bormann, "Multipart		Fossati, T., Hartke, K., and C. Bormann, "Multipart
	Content-Format for CoAP", draft-ietf-core-multipart-ct-02		Content-Format for CoAP", draft-ietf-core-multipart-ct-03
	(work in progress), August 2018.		(work in progress), March 2019.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-30 (work in progress),		1.3", draft-ietf-tls-dtls13-31 (work in progress), March
	November 2018.		2019.
	[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>.
	[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key		[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
	Infrastructure Operational Protocols: FTP and HTTP",		Infrastructure Operational Protocols: FTP and HTTP",
	RFC 2585, DOI 10.17487/RFC2585, May 1999,		RFC 2585, DOI 10.17487/RFC2585, May 1999,
	<https://www.rfc-editor.org/info/rfc2585>.		<https://www.rfc-editor.org/info/rfc2585>.
	skipping to change at page 28, line 23 ¶		skipping to change at page 28, line 23 ¶
	<https://www.iana.org/assignments/core-parameters/		<https://www.iana.org/assignments/core-parameters/
	core-parameters.xhtml>.		core-parameters.xhtml>.
	[I-D.ietf-lamps-rfc5751-bis]		[I-D.ietf-lamps-rfc5751-bis]
	Schaad, J., Ramsdell, B., and S. Turner, "Secure/		Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", draft-ietf-lamps-rfc5751-bis-12		Message Specification", draft-ietf-lamps-rfc5751-bis-12
	(work in progress), September 2018.		(work in progress), September 2018.
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,		Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
	"Connection Identifiers for DTLS 1.2", draft-ietf-tls-		Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
	dtls-connection-id-02 (work in progress), October 2018.		id-05 (work in progress), May 2019.
	[I-D.josefsson-sasl-tls-cb]		[I-D.josefsson-sasl-tls-cb]
	Josefsson, S., "Channel Bindings for TLS based on the		Josefsson, S., "Channel Bindings for TLS based on the
	PRF", draft-josefsson-sasl-tls-cb-03 (work in progress),		PRF", draft-josefsson-sasl-tls-cb-03 (work in progress),
	March 2015.		March 2015.
	[I-D.moskowitz-ecdsa-pki]		[I-D.moskowitz-ecdsa-pki]
	Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,		Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,
	"Guide for building an ECC pki", draft-moskowitz-ecdsa-		"Guide for building an ECC pki", draft-moskowitz-ecdsa-
	pki-04 (work in progress), September 2018.		pki-05 (work in progress), March 2019.
	[ieee802.15.4]		[ieee802.15.4]
	"IEEE Standard 802.15.4-2006", 2006.		"IEEE Standard 802.15.4-2006", 2006.
	[ieee802.1ar]		[ieee802.1ar]
	"IEEE 802.1AR Secure Device Identifier", December 2009.		"IEEE 802.1AR Secure Device Identifier", December 2009.
	[PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys		[PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys
	in Network Devices", USENIX Security Symposium 2012 ISBN		in Network Devices", USENIX Security Symposium 2012 ISBN
	978-931971-95-9, August 2012.		978-931971-95-9, August 2012.
	skipping to change at page 30, line 17 ¶		skipping to change at page 30, line 17 ¶
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.		<https://www.rfc-editor.org/info/rfc7925>.
	[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic		[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
	Curve Cryptography (ECC) Cipher Suites for Transport Layer		Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", RFC 8422,		Security (TLS) Versions 1.2 and Earlier", RFC 8422,
	DOI 10.17487/RFC8422, August 2018,		DOI 10.17487/RFC8422, August 2018,
	<https://www.rfc-editor.org/info/rfc8422>.		<https://www.rfc-editor.org/info/rfc8422>.
	[RSAorig] "The Million-Key Question - Investigating the Origins of		[RSAfact] "Factoring RSA keys from certified smart cards:
	RSA Public Keys", USENIX Security Symposium 2016 ISBN		Coppersmith in the wild", Advances in Cryptology -
	978-1-931971-32-4, August 2016.		ASIACRYPT 2013, August 2013.
	[tripleshake]		[tripleshake]
	"Triple Handshakes and Cookie Cutters: Breaking and Fixing		"Triple Handshakes and Cookie Cutters: Breaking and Fixing
	Authentication over TLS", IEEE Security and Privacy ISBN		Authentication over TLS", IEEE Security and Privacy ISBN
	978-1-4799-4686-0, May 2014.		978-1-4799-4686-0, May 2014.
	Appendix A. EST messages to EST-coaps		Appendix A. EST messages to EST-coaps
	This section shows similar examples to the ones presented in		This section shows similar examples to the ones presented in
	Appendix A of [RFC7030]. The payloads in the examples are the hex		Appendix A of [RFC7030]. The payloads in the examples are the hex
End of changes. 18 change blocks.
	49 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/