rfc9770v7.txt		rfc9770.txt
	Internet Engineering Task Force (IETF) M. Tiloca		Internet Engineering Task Force (IETF) M. Tiloca
	Request for Comments: 9770 RISE AB		Request for Comments: 9770 RISE AB
	Category: Standards Track F. Palombini		Category: Standards Track F. Palombini
	ISSN: 2070-1721 Ericsson AB		ISSN: 2070-1721 Ericsson AB
	S. Echeverria		S. Echeverria
	G. Lewis		G. Lewis
	CMU SEI		CMU SEI
	May 2025		June 2025
	Notification of Revoked Access Tokens in the Authentication and		Notification of Revoked Access Tokens in the Authentication and
	Authorization for Constrained Environments (ACE) Framework		Authorization for Constrained Environments (ACE) Framework
	Abstract		Abstract
	This document specifies a method of the Authentication and		This document specifies a method of the Authentication and
	Authorization for Constrained Environments (ACE) framework, which		Authorization for Constrained Environments (ACE) framework, which
	allows an authorization server to notify clients and resource servers		allows an authorization server to notify clients and resource servers
	(i.e., registered devices) about revoked access tokens. As specified		(i.e., registered devices) about revoked access tokens. As specified
	skipping to change at line 87 ¶		skipping to change at line 87 ¶
	6. The TRL Endpoint		6. The TRL Endpoint
	6.1. Error Responses with Problem Details		6.1. Error Responses with Problem Details
	6.2. Supporting Diff Queries		6.2. Supporting Diff Queries
	6.2.1. Supporting the "Cursor" Extension		6.2.1. Supporting the "Cursor" Extension
	6.3. Query Parameters		6.3. Query Parameters
	7. Full Query of the TRL		7. Full Query of the TRL
	8. Diff Query of the TRL		8. Diff Query of the TRL
	9. Response Messages when Using the "Cursor" Extension		9. Response Messages when Using the "Cursor" Extension
	9.1. Response to Full Query		9.1. Response to Full Query
	9.2. Response to Diff Query		9.2. Response to Diff Query
	9.2.1. Empty Collection		9.2.1. Empty Update Collection
	9.2.2. Cursor Not Included in the Diff Query Request		9.2.2. Cursor Not Included in the Diff Query Request
	9.2.3. Cursor Included in the Diff Query Request		9.2.3. Cursor Included in the Diff Query Request
	10. Registration at the Authorization Server		10. Registration at the Authorization Server
	11. Notification of Revoked Access Tokens		11. Notification of Revoked Access Tokens
	11.1. Handling of Revoked Access Tokens and Token Hashes		11.1. Handling of Revoked Access Tokens and Token Hashes
	12. ACE Token Revocation List Parameters		12. ACE Token Revocation List Parameters
	13. ACE Token Revocation List Error Identifiers		13. ACE Token Revocation List Error Identifiers
	14. Security Considerations		14. Security Considerations
	14.1. Content Retrieval from the TRL		14.1. Content Retrieval from the TRL
	14.2. Size of the TRL		14.2. Size of the TRL
	skipping to change at line 589 ¶		skipping to change at line 589 ¶
	the payload of the POST request.		the payload of the POST request.
	* The access token can be uploaded to the RS by means of a POST		* The access token can be uploaded to the RS by means of a POST
	request to the /authz-info endpoint, using the media-type		request to the /authz-info endpoint, using the media-type
	"application/ace+cbor". When doing so (e.g., like in [RFC9203]),		"application/ace+cbor". When doing so (e.g., like in [RFC9203]),
	TOKEN_INFO is the value of the CBOR byte string conveyed by the		TOKEN_INFO is the value of the CBOR byte string conveyed by the
	'access_token' parameter, within the CBOR map specified as payload		'access_token' parameter, within the CBOR map specified as payload
	of the POST request.		of the POST request.
	* The access token can be uploaded to the RS during a DTLS session		* The access token can be uploaded to the RS during a DTLS session
	establishment, e.g., like it is defined in Section 3.2.2 of		establishment, e.g., like it is defined in Section 3.3.2 of
	[RFC9202]. When doing so, TOKEN_INFO is the value of the		[RFC9202]. When doing so, TOKEN_INFO is the value of the
	'psk_identity' field of the ClientKeyExchange message (when using		'psk_identity' field of the ClientKeyExchange message (when using
	DTLS 1.2 [RFC6347]) or of the 'identity' field of a PSKIdentity,		DTLS 1.2 [RFC6347]) or of the 'identity' field of a PSKIdentity,
	within the PreSharedKeyExtension of a ClientHello message (when		within the PreSharedKeyExtension of a ClientHello message (when
	using DTLS 1.3 [RFC9147]).		using DTLS 1.3 [RFC9147]).
	* The access token can be uploaded to the RS within the MQTT CONNECT		* The access token can be uploaded to the RS within the MQTT CONNECT
	packet, e.g., like it is defined in Section 2.2.4.1 of [RFC9431].		packet, e.g., like it is defined in Section 2.2.4.1 of [RFC9431].
	When doing so, TOKEN_INFO is specified within the 'Authentication		When doing so, TOKEN_INFO is specified within the 'Authentication
	Data' field of the MQTT CONNECT packet, following the property		Data' field of the MQTT CONNECT packet, following the property
	skipping to change at line 721 ¶		skipping to change at line 721 ¶
	NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52		NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
	YCitxoQVPzjbl7WBuB7AohdBoZOdZ24W		YCitxoQVPzjbl7WBuB7AohdBoZOdZ24W
	lN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a		lN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
	1rZgN5TiysnmzTROF869lQ.		1rZgN5TiysnmzTROF869lQ.
	AxY8DCtDaGlsbGljb3RoZQ.		AxY8DCtDaGlsbGljb3RoZQ.
	MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW		MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW
	nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM		nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
	HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7		HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7
	sln1Eu9g3J8.		sln1Eu9g3J8.
	fiK51VwhsxJ-siBMR-YFiA",		fiK51VwhsxJ-siBMR-YFiA",
	"token_type" : "pop",		"token_type" : "PoP",
	"expires_in" : 86400,		"expires_in" : 86400,
	"ace_profile" : "1"		"ace_profile" : "coap_dtls"
	}		}
	Figure 4: Example of AS-to-Client HTTP Response Using JSON		Figure 4: Example of AS-to-Client HTTP Response Using JSON
	4.3. HASH_INPUT on the RS		4.3. HASH_INPUT on the RS
	The following defines how the RS determines the HASH_INPUT value to		The following defines how the RS determines the HASH_INPUT value to
	use as input for computing the token hash of an access token,		use as input for computing the token hash of an access token,
	depending on the RS using either CWTs (see Section 4.3.1) or JWTs		depending on the RS using either CWTs (see Section 4.3.1) or JWTs
	(see Section 4.3.2).		(see Section 4.3.2).
	skipping to change at line 927 ¶		skipping to change at line 927 ¶
	contains a set of token hashes pertaining to the requester. In		contains a set of token hashes pertaining to the requester. In
	particular, all such token hashes were added to the TRL or		particular, all such token hashes were added to the TRL or
	removed from the TRL at the update related to the diff entry in		removed from the TRL at the update related to the diff entry in
	question.		question.
	The AS MAY support this type of query. In such a case, the AS		The AS MAY support this type of query. In such a case, the AS
	maintains the history of updates to the TRL as defined in		maintains the history of updates to the TRL as defined in
	Section 6.2. The processing of a diff query and the related		Section 6.2. The processing of a diff query and the related
	response format are defined in Section 8.		response format are defined in Section 8.
	If it supports diff queries, the AS MAY additionally support its		If it supports diff queries, the AS MAY additionally support the
	"Cursor" extension, which has two benefits:		related "Cursor" extension, which has two benefits:
	1. The AS can avoid excessively long messages when several diff		1. The AS can avoid excessively long messages when several diff
	entries have to be transferred by delivering several diff query		entries have to be transferred by delivering several diff query
	responses, each containing one adjacent subset of diff entries at		responses, each containing one adjacent subset of diff entries at
	a time.		a time.
	2. A requester can retrieve diff entries associated with TRL updates		2. A requester can retrieve diff entries associated with TRL updates
	that, even if not the most recent ones, occurred after a TRL		that, even if not the most recent ones, occurred after a TRL
	update associated with a diff entry indicated as a reference		update associated with a diff entry indicated as a reference
	point.		point.
	skipping to change at line 1492 ¶		skipping to change at line 1492 ¶
	requester (see Section 6.2.1) as corresponding to the most recent TRL		requester (see Section 6.2.1) as corresponding to the most recent TRL
	update pertaining to the requester. In fact, such a value is the		update pertaining to the requester. In fact, such a value is the
	current value of 'last_index' for the update collection associated		current value of 'last_index' for the update collection associated
	with the requester.		with the requester.
	9.2. Response to Diff Query		9.2. Response to Diff Query
	When processing a diff query request to the TRL endpoint, the AS		When processing a diff query request to the TRL endpoint, the AS
	composes a response as defined in the following subsections.		composes a response as defined in the following subsections.
	9.2.1. Empty Collection		9.2.1. Empty Update Collection
	If the update collection associated with the requester has no		If the update collection associated with the requester has no
	elements, the AS returns a 2.05 (Content) response. The response		elements, the AS returns a 2.05 (Content) response. The response
	MUST have Content-Format set to "application/ace-trl+cbor", and its		MUST have Content-Format set to "application/ace-trl+cbor", and its
	payload MUST be a CBOR map formatted as follows:		payload MUST be a CBOR map formatted as follows:
	* The 'diff_set' parameter MUST be included and MUST encode the		* The 'diff_set' parameter MUST be included and MUST encode the
	empty CBOR array.		empty CBOR array.
	* The 'cursor' parameter MUST be included and MUST encode the CBOR		* The 'cursor' parameter MUST be included and MUST encode the CBOR
	skipping to change at line 1761 ¶		skipping to change at line 1761 ¶
	used by the requester when establishing the mutually authenticated		used by the requester when establishing the mutually authenticated
	secure communication association with the AS.		secure communication association with the AS.
	Further details about the registration process at the AS are out of		Further details about the registration process at the AS are out of
	scope for this specification. Note that the registration process is		scope for this specification. Note that the registration process is
	also out of the scope of the ACE framework (see Section 5.5 of		also out of the scope of the ACE framework (see Section 5.5 of
	[RFC9200]).		[RFC9200]).
	11. Notification of Revoked Access Tokens		11. Notification of Revoked Access Tokens
	Once registered at the AS, the administrator or registered device can		Once registered at the AS, the administrator or a registered device
	send a GET request to the TRL endpoint at the AS. The request can		can send a GET request to the TRL endpoint at the AS. The request
	express the wish for a full query (see Section 7) or a diff query		can express the wish for a full query (see Section 7) or a diff query
	(see Section 8) of the TRL. Also, the request can include the CoAP		(see Section 8) of the TRL. Also, the request can include the CoAP
	Observe Option set to 0 (register) in order to start an observation		Observe Option set to 0 (register) in order to start an observation
	of the TRL endpoint as per Section 3.1 of [RFC7641].		of the TRL endpoint as per Section 3.1 of [RFC7641].
	In case the request is successfully processed, the AS replies with a		In case the request is successfully processed, the AS replies with a
	2.05 (Content) response. In particular, if the AS supports diff		2.05 (Content) response. In particular, if the AS supports diff
	queries but not the "Cursor" extension (see Sections 6.2 and 6.2.1),		queries but not the "Cursor" extension (see Sections 6.2 and 6.2.1),
	then the payload of the response is formatted as defined in Sections		then the payload of the response is formatted as defined in Sections
	7 or 8, in case the GET request has yielded the execution of a full		7 or 8, in case the GET request has yielded the execution of a full
	query or of a diff query of the TRL, respectively. Instead, if the		query or of a diff query of the TRL, respectively. Instead, if the
	skipping to change at line 2172 ¶		skipping to change at line 2172 ¶
	computed and stored by C and the AS. Finally, the RS stores the		computed and stored by C and the AS. Finally, the RS stores the
	manipulated access token and the corresponding wrong token hash.		manipulated access token and the corresponding wrong token hash.
	Later on, if the access token is revoked and the AS provides the RS		Later on, if the access token is revoked and the AS provides the RS
	with the corresponding correct token hash, the RS does not recognize		with the corresponding correct token hash, the RS does not recognize
	the received token hash among the stored ones; therefore, the RS does		the received token hash among the stored ones; therefore, the RS does
	not delete the revoked access token.		not delete the revoked access token.
	14.7. Two Token Hashes at the RS Using JWTs		14.7. Two Token Hashes at the RS Using JWTs
	Section 4.3.2 states that an RS using JWTs as access tokens has to		Section 4.3.2 specifies that an RS using JWTs as access tokens has to
	compute and store two token hashes associated with the same access		compute and store two token hashes associated with the same access
	token. This is because the RS does not know for sure if the AS		token. This is because the RS does not know for sure if the AS
	provided the access token to the client by means of an AS-to-Client		provided the access token to the client by means of an AS-to-Client
	response encoded in CBOR or in JSON.		response encoded in CBOR or in JSON.
	Taking advantage of that, a dishonest client can attempt to perform		Taking advantage of that, a dishonest client can attempt to perform
	an attack against the RS. That is, the client can first receive the		an attack against the RS. That is, the client can first receive the
	JWT in an AS-to-Client response encoded in CBOR (JSON). Then, the		JWT in an AS-to-Client response encoded in CBOR (JSON). Then, the
	client can upload the JWT to the RS in a way that makes the RS		client can upload the JWT to the RS in a way that makes the RS
	believe that the client instead received the JWT in an AS-to-Client		believe that the client instead received the JWT in an AS-to-Client
	skipping to change at line 2197 ¶		skipping to change at line 2197 ¶
	computes a token hash h' different from the token hash h computed by		computes a token hash h' different from the token hash h computed by
	the AS and the client. It follows that, if the AS revokes the access		the AS and the client. It follows that, if the AS revokes the access
	token and advertises the right token hash h, then the RS will not		token and advertises the right token hash h, then the RS will not
	learn about the access token revocation; therefore, the RS will not		learn about the access token revocation; therefore, the RS will not
	delete the access token.		delete the access token.
	Fundamentally, this would happen because the HASH_INPUT used to		Fundamentally, this would happen because the HASH_INPUT used to
	compute the token hash of a JWT depends on whether the AS-to-Client		compute the token hash of a JWT depends on whether the AS-to-Client
	response is encoded in CBOR or in JSON. This makes the RS vulnerable		response is encoded in CBOR or in JSON. This makes the RS vulnerable
	to the attack described above when JWTs are used as access tokens.		to the attack described above when JWTs are used as access tokens.
	However, this is not a problem if the access token is a CWT since the		However, this is not a problem if the access token is a CWT, since
	HASH_INPUT used to compute the token hash of a CWT does not depend on		the HASH_INPUT used to compute the token hash of a CWT does not
	whether the AS-to-Client response is encoded in CBOR or in JSON.		depend on whether the AS-to-Client response is encoded in CBOR or in
			JSON.
	While this asymmetry cannot be avoided altogether, the method defined		While this asymmetry cannot be avoided altogether, the method defined
	for the AS and the client in Section 4.2 deliberately penalizes the		for the AS and the client in Section 4.2 deliberately penalizes the
	case where the RS uses JWTs as access tokens. In such a case, the RS		case where the RS uses JWTs as access tokens. In such a case, the RS
	effectively neutralizes the attack described above by computing and		effectively neutralizes the attack described above by computing and
	storing two token hashes associated with the same access token (see		storing two token hashes associated with the same access token (see
	Section 4.3.2).		Section 4.3.2).
	Conversely, this design deliberately favors the case where the RS		Conversely, this design deliberately favors the case where the RS
	uses CWTs as access tokens, which is a preferable option for		uses CWTs as access tokens, which is a preferable option for
	skipping to change at line 2737 ¶		skipping to change at line 2738 ¶
	Appendix C. Interaction Examples		Appendix C. Interaction Examples
	This section provides examples of interactions between an RS as a		This section provides examples of interactions between an RS as a
	registered device and an AS. In the examples, all the access tokens		registered device and an AS. In the examples, all the access tokens
	issued by the AS are intended to be consumed by the considered RS.		issued by the AS are intended to be consumed by the considered RS.
	The AS supports both full queries and diff queries of the TRL, as		The AS supports both full queries and diff queries of the TRL, as
	defined in Sections 7 and 8, respectively.		defined in Sections 7 and 8, respectively.
	Registration is assumed to be done by the RS sending a POST request		The RS registration is assumed to be done by the RS sending a POST
	with an unspecified payload to the AS, which replies with a 2.01		request with an unspecified payload to the AS, which replies with a
	(Created) response. The payload of the registration response is		2.01 (Created) response. The payload of the registration response is
	assumed to be a CBOR map, which, in turn, is assumed to include the		assumed to be a CBOR map, which, in turn, is assumed to include the
	following entries:		following entries:
	* a 'trl_path' parameter specifying the path of the TRL endpoint;		* a 'trl_path' parameter specifying the path of the TRL endpoint;
	* a 'trl_hash' parameter specifying the "Hash Name String" of the		* a 'trl_hash' parameter specifying the "Hash Name String" of the
	hash function used to compute token hashes as defined in		hash function used to compute token hashes as defined in
	Section 4;		Section 4;
	* a 'max_n' parameter specifying the value of MAX_N, i.e., the		* a 'max_n' parameter specifying the value of MAX_N, i.e., the
	maximum number of series items that the AS retains in the update		maximum number of series items that the AS retains in the update
	collection associated with a registered device (see Section 8);		collection associated with a registered device (see Section 6.2);
	* possible further parameters related to the registration process.		* possible further parameters related to the registration process.
	Furthermore, 'h(x)' refers to the hash function used to compute the		Furthermore, 'h(x)' refers to the hash function used to compute the
	token hashes, as defined in Section 4 of this specification and		token hashes, as defined in Section 4 of this specification and
	according to [RFC6920]. Assuming the usage of CWTs transported in		according to [RFC6920]. Assuming the usage of CWTs transported in
	AS-to-Client responses encoded in CBOR (see Section 4.2.1),		AS-to-Client responses encoded in CBOR (see Section 4.2.1),
	'bstr.h(t1)' and 'bstr.h(t2)' denote CBOR byte strings, whose values		'bstr.h(t1)' and 'bstr.h(t2)' denote CBOR byte strings, whose values
	are the token hashes of the access tokens t1 and t2, respectively.		are the token hashes of the access tokens t1 and t2, respectively.
End of changes. 12 change blocks.
	19 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.48.