Diff: rfc9148v2.txt - rfc9148.txt

	rfc9148v2.txt	rfc9148.txt

	Internet Engineering Task Force (IETF) P. van der Stok	Internet Engineering Task Force (IETF) P. van der Stok
	Request for Comments: 9148 Consultant	Request for Comments: 9148 Consultant
	Category: Standards Track P. Kampanakis	Category: Standards Track P. Kampanakis
	ISSN: 2070-1721 Cisco Systems	ISSN: 2070-1721 Cisco Systems
	M. Richardson	M. Richardson
	SSW	SSW
	S. Raza	S. Raza
	RISE Research Institutes of Sweden	RISE Research Institutes of Sweden

	August 2021	March 2022

	EST-coaps: Enrollment over Secure Transport with the Secure Constrained	EST-coaps: Enrollment over Secure Transport with the Secure Constrained
	Application Protocol	Application Protocol

	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

	skipping to change at line 40 ¶	skipping to change at line 40 ¶
	received public review and has been approved for publication by the	received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on	Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.	Internet Standards is available in Section 2 of RFC 7841.

	Information about the current status of this document, any errata,	Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at	and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9148.	https://www.rfc-editor.org/info/rfc9148.

	Copyright Notice	Copyright Notice


	Copyright (c) 2021 IETF Trust and the persons identified as the	Copyright (c) 2022 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
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the	include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described	Trust Legal Provisions and are provided without warranty as described

	skipping to change at line 216 ¶	skipping to change at line 216 ¶
	link proof-of-identity with an established connection. Connection-	link proof-of-identity with an established connection. Connection-
	based proof-of-possession is OPTIONAL for EST-coaps clients and	based proof-of-possession is OPTIONAL for EST-coaps clients and
	servers. When proof-of-possession is desired, a set of actions are	servers. When proof-of-possession is desired, a set of actions are
	required regarding the use of tls-unique, described in Section 3.5 of	required regarding the use of tls-unique, described in Section 3.5 of
	[RFC7030]. The tls-unique information consists of the contents of	[RFC7030]. The tls-unique information consists of the contents of
	the first Finished message in the (D)TLS handshake between server and	the first Finished message in the (D)TLS handshake between server and
	client [RFC5929]. The client adds the Finished message as a	client [RFC5929]. The client adds the Finished message as a
	challengePassword in the attributes section of the PKCS #10	challengePassword in the attributes section of the PKCS #10
	CertificationRequest [RFC5967] to prove that the client is indeed in	CertificationRequest [RFC5967] to prove that the client is indeed in
	control of the private key at the time of the (D)TLS session	control of the private key at the time of the (D)TLS session

	establishment.	establishment. In the case of handshake message fragmentation, if
		proof-of-possession is desired, the Finished message added as the
	In the case of handshake message fragmentation, if proof-of-
	possession is desired, the Finished message added as the
	challengePassword in the Certificate Signing Request (CSR) is	challengePassword in the Certificate Signing Request (CSR) is

	calculated as specified by the DTLS standards. We summarize it here	calculated as specified by (D)TLS. We summarize it here for
	for convenience. For DTLS 1.2, in the event of handshake message	convenience. For DTLS 1.2, in the event of handshake message
	fragmentation, the hash of the handshake messages used in the Message	fragmentation, the hash of the handshake messages used in the Message
	Authentication Code (MAC) calculation of the Finished message must be	Authentication Code (MAC) calculation of the Finished message must be
	computed on each reassembled message, as if each message had not been	computed on each reassembled message, as if each message had not been
	fragmented (Section 4.2.6 of [RFC6347]). The Finished message is	fragmented (Section 4.2.6 of [RFC6347]). The Finished message is

	calculated as shown in Section 7.4.9 of [RFC5246]. Similarly, for	calculated as shown in Section 7.4.9 of [RFC5246].
	DTLS 1.3, the Finished message must be computed as if each handshake
	message had been sent as a single fragment (Section 5.8 of [RFC9147])	For (D)TLS 1.3, Appendix C.5 of [RFC8446] describes the lack of
	following the algorithm described in Section 4.4.4 of [RFC8446].	channel bindings similar to tls-unique. [TLS13-CHANNEL-BINDINGS] can
		be used instead to derive a 32-byte tls-exporter binding from the
		(D)TLS 1.3 master secret by using a PRF negotiated in the (D)TLS 1.3
		handshake, "EXPORTER-Channel-Binding" with no terminating NUL as the
		label, the ClientHello.random and ServerHello.random, and a zero-
		length context string. When proof-of-possession is desired, the
		client adds the tls-exporter value as a challengePassword in the
		attributes section of the PKCS #10 CertificationRequest [RFC5967] to
		prove that the client is indeed in control of the private key at the
		time of the (D)TLS session establishment.

	In a constrained CoAP environment, endpoints can't always afford to	In a constrained CoAP environment, endpoints can't always afford to
	establish a DTLS connection for every EST transaction. An EST-coaps	establish a DTLS connection for every EST transaction. An EST-coaps
	DTLS connection MAY remain open for sequential EST transactions,	DTLS connection MAY remain open for sequential EST transactions,
	which was not the case with [RFC7030]. For example, if a /crts	which was not the case with [RFC7030]. For example, if a /crts
	request is followed by a /sen request, both can use the same	request is followed by a /sen request, both can use the same
	authenticated DTLS connection. However, when a /crts request is	authenticated DTLS connection. However, when a /crts request is
	included in the set of sequential EST transactions, some additional	included in the set of sequential EST transactions, some additional
	security considerations apply regarding the use of the Implicit and	security considerations apply regarding the use of the Implicit and
	Explicit TA database as explained in Section 9.1.	Explicit TA database as explained in Section 9.1.

	skipping to change at line 833 ¶	skipping to change at line 840 ¶
	Figure 5: EST-coaps-to-HTTPS Registrar at the CoAP Boundary	Figure 5: EST-coaps-to-HTTPS Registrar at the CoAP Boundary

	The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream	The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream
	and initiate EST connections over TLS upstream. The Registrar MUST	and initiate EST connections over TLS upstream. The Registrar MUST
	authenticate and optionally authorize the client requests while it	authenticate and optionally authorize the client requests while it
	MUST be authenticated by the EST server or CA. The trust	MUST be authenticated by the EST server or CA. The trust
	relationship between the Registrar and the EST server SHOULD be pre-	relationship between the Registrar and the EST server SHOULD be pre-
	established for the Registrar to proxy these connections on behalf of	established for the Registrar to proxy these connections on behalf of
	various clients.	various clients.


	When enforcing Proof-of-Possession (POP) linking, the DTLS tls-unique	When enforcing Proof-of-Possession (POP) linking, the tls-unique or
	value of the (D)TLS session is used to prove that the private key	tls-exporter value of the session for DTLS 1.2 and DTLS 1.3,
	corresponding to the public key is in the possession of the client	respectively, is used to prove that the private key corresponding to
	and was used to establish the connection as explained in Section 3.	the public key is in the possession of the client and was used to
	The POP linking information is lost between the EST-coaps client and	establish the connection as explained in Section 3. The POP linking
	the EST server when a Registrar is present. The EST server becomes	information is lost between the EST-coaps client and the EST server
	aware of the presence of a Registrar from its TLS client certificate	when a Registrar is present. The EST server becomes aware of the
	that includes the id-kp-cmcRA extended key usage (EKU) extension	presence of a Registrar from its TLS client certificate that includes
	[RFC6402]. As explained in Section 3.7 of [RFC7030], the "EST server	the id-kp-cmcRA extended key usage (EKU) extension [RFC6402]. As
	SHOULD apply authorization policy consistent with an RA client ...	explained in Section 3.7 of [RFC7030], the "EST server SHOULD apply
	the EST server could be configured to accept POP linking information	authorization policy consistent with an RA client ... the EST server
	that does not match the current TLS session because the authenticated	could be configured to accept POP linking information that does not
	EST client RA has verified this information when acting as an EST	match the current TLS session because the authenticated EST client RA
	server".	has verified this information when acting as an EST server".

	Table 1 contains the URI mappings between EST-coaps and EST that the	Table 1 contains the URI mappings between EST-coaps and EST that the
	Registrar MUST adhere to. Section 4.5 of this specification and	Registrar MUST adhere to. Section 4.5 of this specification and
	Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP	Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP
	response codes that determine how the Registrar MUST translate CoAP	response codes that determine how the Registrar MUST translate CoAP
	response codes from/to HTTP status codes. The mapping from CoAP	response codes from/to HTTP status codes. The mapping from CoAP
	Content-Format to HTTP Content-Type is defined in Section 8.1.	Content-Format to HTTP Content-Type is defined in Section 8.1.
	Additionally, a conversion from CBOR major type 2 to Base64 encoding	Additionally, a conversion from CBOR major type 2 to Base64 encoding
	MUST take place at the Registrar. If CMS end-to-end encryption is	MUST take place at the Registrar. If CMS end-to-end encryption is
	employed for the private key, the encrypted CMS EnvelopedData blob	employed for the private key, the encrypted CMS EnvelopedData blob

	skipping to change at line 1083 ¶	skipping to change at line 1090 ¶
	be trusted.	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
	recommendations for secure use of TLS and DTLS are included in	recommendations for secure use of TLS and DTLS are included in
	[BCP195].	[BCP195].

	As described in Certificate Management over CMS (CMC), Section 6.7 of	As described in Certificate Management over CMS (CMC), Section 6.7 of
	[RFC5272], "For keys that can be used as signature keys, signing the	[RFC5272], "For keys that can be used as signature keys, signing the
	certification request with the private key serves as a POP on that	certification request with the private key serves as a POP on that

	key pair". The inclusion of tls-unique in the certificate request	key pair". In (D)TLS 1.2, the inclusion of tls-unique in the
	links the proof-of-possession to the TLS proof-of-identity. This	certificate request links the proof-of-possession to the (D)TLS
	implies but does not prove that only the authenticated client	proof-of-identity. This implies but does not prove that only the
	currently has access to the private key.	authenticated client currently has access to the private key.

	What's more, CMC POP linking uses tls-unique as it is defined in	What's more, CMC POP linking uses tls-unique as it is defined in
	[RFC5929]. The 3SHAKE attack [TRIPLESHAKE] poses a risk by allowing	[RFC5929]. The 3SHAKE attack [TRIPLESHAKE] poses a risk by allowing
	an on-path active attacker to leverage session resumption and	an on-path active attacker to leverage session resumption and
	renegotiation to inject itself between a client and server even when	renegotiation to inject itself between a client and server even when
	channel binding is in use. Implementers should use the Extended	channel binding is in use. Implementers should use the Extended
	Master Secret Extension in DTLS [RFC7627] to prevent such attacks.	Master Secret Extension in DTLS [RFC7627] to prevent such attacks.
	In the context of this specification, an attacker could invalidate	In the context of this specification, an attacker could invalidate
	the purpose of the POP linking challengePassword in the client	the purpose of the POP linking challengePassword in the client
	request by resuming an EST-coaps connection. Even though the	request by resuming an EST-coaps connection. Even though the
	practical risk of such an attack to EST-coaps is not devastating, we	practical risk of such an attack to EST-coaps is not devastating, we

	would rather use a more secure channel-binding mechanism. Such a	would rather use a more secure channel-binding mechanism. In this
	mechanism could include an updated tls-unique value generation like	specification, we still depend on the tls-unique mechanism defined in
	the tls-unique-prf defined in [BINDINGS-TLS-PRF] by using a TLS	[RFC5929] for DTLS 1.2 because a 3SHAKE attack does not expose
	exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter	messages exchanged with EST-coaps. But for DTLS 1.3,
	(Section 7.5 of [RFC8446]) value in place of the tls-unique value in	[TLS13-CHANNEL-BINDINGS] is used instead to derive a 32-byte tls-
	the CSR. Such a mechanism has not been standardized yet. Adopting a	exporter binding in place of the tls-unique value in the CSR. That
	channel-binding value generated from an exporter would break	would alleviate the risks from the 3SHAKE attack [TRIPLESHAKE].
	backwards compatibility for an RA that proxies through to a classic
	EST server. Thus, in this specification, we still depend on the tls-
	unique mechanism defined in [RFC5929], especially since a 3SHAKE
	attack does not expose messages exchanged with EST-coaps.

	Interpreters of ASN.1 structures should be aware of the use of	Interpreters of ASN.1 structures should be aware of the use of
	invalid ASN.1 length fields and should take appropriate measures to	invalid ASN.1 length fields and should take appropriate measures to
	guard against buffer overflows, stack overruns in particular, and	guard against buffer overflows, stack overruns in particular, and
	malicious content in general.	malicious content in general.

	9.2. HTTPS-CoAPS Registrar Considerations	9.2. HTTPS-CoAPS Registrar Considerations

	The Registrar proposed in Section 5 must be deployed with care and	The Registrar proposed in Section 5 must be deployed with care and
	only when direct client-server connections are not possible. When	only when direct client-server connections are not possible. When

	skipping to change at line 1248 ¶	skipping to change at line 1251 ¶

	10.2. Informative References	10.2. Informative References

	[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,	[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer	"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security	Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, May 2015.	(DTLS)", BCP 195, RFC 7525, May 2015.

	<https://www.rfc-editor.org/info/bcp195>	<https://www.rfc-editor.org/info/bcp195>


	[BINDINGS-TLS-PRF]
	Josefsson, S., "Channel Bindings for TLS based on the
	PRF", Work in Progress, Internet-Draft, draft-josefsson-
	sasl-tls-cb-03, 2 March 2015,
	<https://datatracker.ietf.org/doc/html/draft-josefsson-
	sasl-tls-cb-03>.

	[CORE-PARAMS]	[CORE-PARAMS]
	IANA, "Constrained RESTful Environments (CoRE)	IANA, "Constrained RESTful Environments (CoRE)
	Parameters",	Parameters",
	<https://www.iana.org/assignments/core-parameters/>.	<https://www.iana.org/assignments/core-parameters/>.

	[IEEE802.15.4]	[IEEE802.15.4]
	IEEE, "IEEE 802.15.4-2020 - IEEE Standard for Low-Rate	IEEE, "IEEE 802.15.4-2020 - IEEE Standard for Low-Rate
	Wireless Networks", May 2020.	Wireless Networks", May 2020.

	[IEEE802.1AR]	[IEEE802.1AR]

	skipping to change at line 1290 ¶	skipping to change at line 1286 ¶
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):	over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals",	Overview, Assumptions, Problem Statement, and Goals",
	RFC 4919, DOI 10.17487/RFC4919, August 2007,	RFC 4919, DOI 10.17487/RFC4919, August 2007,
	<https://www.rfc-editor.org/info/rfc4919>.	<https://www.rfc-editor.org/info/rfc4919>.

	[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS	[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
	(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,	(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
	<https://www.rfc-editor.org/info/rfc5272>.	<https://www.rfc-editor.org/info/rfc5272>.


	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <https://www.rfc-editor.org/info/rfc5705>.

	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,	for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
	<https://www.rfc-editor.org/info/rfc5929>.	<https://www.rfc-editor.org/info/rfc5929>.

	[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)	[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
	Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,	Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
	<https://www.rfc-editor.org/info/rfc6402>.	<https://www.rfc-editor.org/info/rfc6402>.

	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,	Constrained-Node Networks", RFC 7228,

	skipping to change at line 1341 ¶	skipping to change at line 1333 ¶
	[RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and	[RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and
	A. Kraus, "Connection Identifiers for DTLS 1.2", RFC 9146,	A. Kraus, "Connection Identifiers for DTLS 1.2", RFC 9146,
	DOI 10.17487/RFC9146, August 2021,	DOI 10.17487/RFC9146, August 2021,
	<https://www.rfc-editor.org/info/rfc9146>.	<https://www.rfc-editor.org/info/rfc9146>.

	[RSA-FACT] Bernstein, D., Chang, Y., Cheng, C., Chou, L., Heninger,	[RSA-FACT] Bernstein, D., Chang, Y., Cheng, C., Chou, L., Heninger,
	N., Lange, T., and N. Someren, "Factoring RSA keys from	N., Lange, T., and N. Someren, "Factoring RSA keys from
	certified smart cards: Coppersmith in the wild", Advances	certified smart cards: Coppersmith in the wild", Advances
	in Cryptology - ASIACRYPT 2013, August 2013.	in Cryptology - ASIACRYPT 2013, August 2013.


		[TLS13-CHANNEL-BINDINGS]
		Whited, S., "Channel Bindings for TLS 1.3", Work in
		Progress, Internet-Draft, draft-ietf-kitten-tls-channel-
		bindings-for-tls13-15, 4 March 2022,
		<https://datatracker.ietf.org/doc/html/draft-ietf-kitten-
		tls-channel-bindings-for-tls13-15>.

	[TRIPLESHAKE]	[TRIPLESHAKE]
	Bhargavan, B., Delignat-Lavaud, A., Fournet, C., Pironti,	Bhargavan, B., Delignat-Lavaud, A., Fournet, C., Pironti,
	A., and P. Strub, "Triple Handshakes and Cookie Cutters:	A., and P. Strub, "Triple Handshakes and Cookie Cutters:
	Breaking and Fixing Authentication over TLS",	Breaking and Fixing Authentication over TLS",
	ISBN 978-1-4799-4686-0, DOI 10.1109/SP.2014.14, May 2014,	ISBN 978-1-4799-4686-0, DOI 10.1109/SP.2014.14, May 2014,
	<https://doi.org/10.1109/SP.2014.14>.	<https://doi.org/10.1109/SP.2014.14>.

	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

	skipping to change at line 2090 ¶	skipping to change at line 2089 ¶
	importance of the subject.	importance of the subject.

	Authors' Addresses	Authors' Addresses

	Peter van der Stok	Peter van der Stok
	Consultant	Consultant
	Email: stokcons@bbhmail.nl	Email: stokcons@bbhmail.nl

	Panos Kampanakis	Panos Kampanakis
	Cisco Systems	Cisco Systems

	Email: pankab@gmail.com	Email: pkampana@cisco.com

	Michael C. Richardson	Michael C. Richardson
	Sandelman Software Works	Sandelman Software Works
	Email: mcr+ietf@sandelman.ca	Email: mcr+ietf@sandelman.ca
	URI: https://www.sandelman.ca/	URI: https://www.sandelman.ca/

	Shahid Raza	Shahid Raza
	RISE Research Institutes of Sweden	RISE Research Institutes of Sweden
	Isafjordsgatan 22	Isafjordsgatan 22
	SE-16440 Kista, Stockholm	SE-16440 Kista, Stockholm

End of changes. 12 change blocks.
	53 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/