rfc9202v4.txt		rfc9202.txt
	Internet Engineering Task Force (IETF) S. Gerdes		Internet Engineering Task Force (IETF) S. Gerdes
	Request for Comments: 9202 O. Bergmann		Request for Comments: 9202 O. Bergmann
	Category: Standards Track C. Bormann		Category: Standards Track C. Bormann
	ISSN: 2070-1721 Universität Bremen TZI		ISSN: 2070-1721 Universität Bremen TZI
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	L. Seitz		L. Seitz
	Combitech		Combitech
	March 2022		August 2022
	Datagram Transport Layer Security (DTLS) Profile for Authentication and		Datagram Transport Layer Security (DTLS) Profile for Authentication and
	Authorization for Constrained Environments (ACE)		Authorization for Constrained Environments (ACE)
	Abstract		Abstract
	This specification defines a profile of the Authentication and		This specification defines a profile of the Authentication and
	Authorization for Constrained Environments (ACE) framework that		Authorization for Constrained Environments (ACE) framework that
	allows constrained servers to delegate client authentication and		allows constrained servers to delegate client authentication and
	authorization. The protocol relies on DTLS version 1.2 for		authorization. The protocol relies on DTLS version 1.2 or later for
	communication security between entities in a constrained network		communication security between entities in a constrained network
	using either raw public keys or pre-shared keys. A resource-		using either raw public keys or pre-shared keys. A resource-
	constrained server can use this protocol to delegate management of		constrained server can use this protocol to delegate management of
	authorization information to a trusted host with less-severe		authorization information to a trusted host with less-severe
	limitations regarding processing power and memory.		limitations regarding processing power and memory.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	skipping to change at line 94 ¶		skipping to change at line 94 ¶
	10.2. Informative References		10.2. Informative References
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This specification defines a profile of the ACE framework [RFC9200].		This specification defines a profile of the ACE framework [RFC9200].
	In this profile, a client (C) and a resource server (RS) use the		In this profile, a client (C) and a resource server (RS) use the
	Constrained Application Protocol (CoAP) [RFC7252] over DTLS version		Constrained Application Protocol (CoAP) [RFC7252] over DTLS version
	1.2 [RFC6347] to communicate. This specification uses DTLS 1.2		1.2 [RFC6347] to communicate. This specification uses DTLS 1.2
	terminology, but later versions such as DTLS 1.3 can be used instead.		terminology, but later versions such as DTLS 1.3 [RFC9147] can be
	The client obtains an access token bound to a key (the proof-of-		used instead. The client obtains an access token bound to a key (the
	possession (PoP) key) from an authorization server (AS) to prove its		proof-of-possession (PoP) key) from an authorization server (AS) to
	authorization to access protected resources hosted by the resource		prove its authorization to access protected resources hosted by the
	server. Also, the client and the resource server are provided by the		resource server. Also, the client and the resource server are
	authorization server with the necessary keying material to establish		provided by the authorization server with the necessary keying
	a DTLS session. The communication between the client and		material to establish a DTLS session. The communication between the
	authorization server may also be secured with DTLS. This		client and authorization server may also be secured with DTLS. This
	specification supports DTLS with raw public keys (RPKs) [RFC7250] and		specification supports DTLS with raw public keys (RPKs) [RFC7250] and
	with pre-shared keys (PSKs) [RFC4279]. How token introspection		with pre-shared keys (PSKs) [RFC4279]. How token introspection
	[RFC7662] is performed between the RS and AS is out of scope for this		[RFC7662] is performed between the RS and AS is out of scope for this
	specification.		specification.
	The ACE framework requires that the client and server mutually		The ACE framework requires that the client and server mutually
	authenticate each other before any application data is exchanged.		authenticate each other before any application data is exchanged.
	DTLS enables mutual authentication if both the client and server		DTLS enables mutual authentication if both the client and server
	prove their ability to use certain keying material in the DTLS		prove their ability to use certain keying material in the DTLS
	handshake. The authorization server assists in this process on the		handshake. The authorization server assists in this process on the
	skipping to change at line 140 ¶		skipping to change at line 140 ¶
	As recommended in Section 5.8 of [RFC9200], this specification uses		As recommended in Section 5.8 of [RFC9200], this specification uses
	Concise Binary Object Representation (CBOR) web tokens to convey		Concise Binary Object Representation (CBOR) web tokens to convey
	claims within an access token issued by the server. While other		claims within an access token issued by the server. While other
	formats could be used as well, those are out of scope for this		formats could be used as well, those are out of scope for this
	document.		document.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Readers are expected to be familiar with the terms and concepts		Readers are expected to be familiar with the terms and concepts
	described in [RFC9200] and [RFC9201].		described in [RFC9200] and [RFC9201].
	The authorization information (authz-info) resource refers to the		The authorization information (authz-info) resource refers to the
	authorization information endpoint, as specified in [RFC9200]. The		authorization information endpoint, as specified in [RFC9200]. The
	term claim is used in this document with the same semantics as in		term claim is used in this document with the same semantics as in
	[RFC9200], i.e., it denotes information carried in the access token		[RFC9200], i.e., it denotes information carried in the access token
	or returned from introspection.		or returned from introspection.
	skipping to change at line 710 ¶		skipping to change at line 710 ¶
	A1 08 A1 01 A2 01 04 02 48 3D 02 78 33 FC 62 67 CE		A1 08 A1 01 A2 01 04 02 48 3D 02 78 33 FC 62 67 CE
	As an alternative to the access token upload, the client can provide		As an alternative to the access token upload, the client can provide
	the most recent access token in the psk_identity field of the		the most recent access token in the psk_identity field of the
	ClientKeyExchange message. To do so, the client MUST treat the		ClientKeyExchange message. To do so, the client MUST treat the
	contents of the access_token field from the AS-to-client response as		contents of the access_token field from the AS-to-client response as
	opaque data, as specified in Section 4.2 of [RFC7925], and not		opaque data, as specified in Section 4.2 of [RFC7925], and not
	perform any recoding. This allows the resource server to retrieve		perform any recoding. This allows the resource server to retrieve
	the shared secret directly from the cnf claim of the access token.		the shared secret directly from the cnf claim of the access token.
	DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3,		DTLS 1.3 [RFC9147] does not use the ClientKeyExchange message; for
	the access token is placed in the identity field of a PSKIdentity		DTLS 1.3, the access token is placed in the identity field of a
	within the PreSharedKeyExtension of the ClientHello.		PSKIdentity within the PreSharedKeyExtension of the ClientHello.
	If a resource server receives a ClientKeyExchange message that		If a resource server receives a ClientKeyExchange message that
	contains a psk_identity with a length greater than zero, it MUST		contains a psk_identity with a length greater than zero, it MUST
	parse the contents of the psk_identity field as a CBOR data structure		parse the contents of the psk_identity field as a CBOR data structure
	and process the contents as following:		and process the contents as following:
	* If the data contains a cnf field with a COSE_Key structure with a		* If the data contains a cnf field with a COSE_Key structure with a
	kid, the resource server continues the DTLS handshake with the		kid, the resource server continues the DTLS handshake with the
	associated key that corresponds to this kid.		associated key that corresponds to this kid.
	skipping to change at line 969 ¶		skipping to change at line 969 ¶
	and a server. As this specification aims at constrained devices and		and a server. As this specification aims at constrained devices and
	uses CoAP [RFC7252] as the transfer protocol, at least the cipher		uses CoAP [RFC7252] as the transfer protocol, at least the cipher
	suite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported. The		suite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported. The
	access tokens and the corresponding shared secrets generated by the		access tokens and the corresponding shared secrets generated by the
	authorization server are expected to be sufficiently short-lived to		authorization server are expected to be sufficiently short-lived to
	provide similar forward-secrecy properties to using ephemeral Diffie-		provide similar forward-secrecy properties to using ephemeral Diffie-
	Hellman (DHE) key exchange mechanisms. For longer-lived access		Hellman (DHE) key exchange mechanisms. For longer-lived access
	tokens, DHE cipher suites should be used, i.e., cipher suites of the		tokens, DHE cipher suites should be used, i.e., cipher suites of the
	form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.		form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.
	Constrained devices that use DTLS [RFC6347] are inherently vulnerable		Constrained devices that use DTLS [RFC6347] [RFC9147] are inherently
	to Denial of Service (DoS) attacks, as the handshake protocol		vulnerable to Denial of Service (DoS) attacks, as the handshake
	requires creation of internal state within the device. This is		protocol requires creation of internal state within the device. This
	specifically of concern where an adversary is able to intercept the		is specifically of concern where an adversary is able to intercept
	initial cookie exchange and interject forged messages with a valid		the initial cookie exchange and interject forged messages with a
	cookie to continue with the handshake. A similar issue exists with		valid cookie to continue with the handshake. A similar issue exists
	the unprotected authorization information endpoint when the resource		with the unprotected authorization information endpoint when the
	server needs to keep valid access tokens for a long time.		resource server needs to keep valid access tokens for a long time.
	Adversaries could fill up the constrained resource server's internal		Adversaries could fill up the constrained resource server's internal
	storage for a very long time with intercepted or otherwise retrieved		storage for a very long time with intercepted or otherwise retrieved
	valid access tokens. To mitigate against this, the resource server		valid access tokens. To mitigate against this, the resource server
	should set a time boundary until an access token that has not been		should set a time boundary until an access token that has not been
	used until then will be deleted.		used until then will be deleted.
	The protection of access tokens that are stored in the authorization		The protection of access tokens that are stored in the authorization
	information endpoint depends on the keying material that is used		information endpoint depends on the keying material that is used
	between the authorization server and the resource server; the		between the authorization server and the resource server; the
	resource server must ensure that it processes only access tokens that		resource server must ensure that it processes only access tokens that
	skipping to change at line 1161 ¶		skipping to change at line 1161 ¶
	[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March		Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
	2020, <https://www.rfc-editor.org/info/rfc8747>.		2020, <https://www.rfc-editor.org/info/rfc8747>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
			[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
			Datagram Transport Layer Security (DTLS) Protocol Version
			1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
			<https://www.rfc-editor.org/info/rfc9147>.
	[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) Using the OAuth 2.0		Constrained Environments (ACE) Using the OAuth 2.0
	Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200,		Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200,
	March 2022, <https://www.rfc-editor.org/info/rfc9200>.		August 2022, <https://www.rfc-editor.org/info/rfc9200>.
	[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication		[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication
	and Authorization for Constrained Environments (ACE)",		and Authorization for Constrained Environments (ACE)",
	RFC 9201, DOI 10.17487/RFC9201, March 2022,		RFC 9201, DOI 10.17487/RFC9201, August 2022,
	<https://www.rfc-editor.org/info/rfc9201>.		<https://www.rfc-editor.org/info/rfc9201>.
	10.2. Informative References		10.2. Informative References
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
	[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for		[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
End of changes. 9 change blocks.
	25 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48.