Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework
draft-ietf-ace-revoked-token-notification-09

[Ballot comment]
Thanks to the authors for their detailed response.

https://mailarchive.ietf.org/arch/msg/ace/Zikt4Dg8qwg6mELohY2tZ-bxjsE/

I believe the pull request addresses my discuss, and other comments.

I have left a few more nits for their consideration, and am switching to no objection.

[Ballot comment]
Thanks for working on this specification. Thanks to Joerg Ott for the TSVART review.

My review did not surface transport protocol related issues.However - can we define/refer/describe "diff queries" in this document? The meaning might be very obvious to the experts but describing it will improve the readablity of this specification and avoid misconceptions.

[Ballot comment]
Thank you to Dale Worley for the GENART review.

** Section 3.4
  The specifically used hash function MUST be collision-resistant on
  byte-strings, and MUST be selected from the "Named Information Hash
  Algorithm" Registry [Named.Information.Hash.Algorithm].

Is there isn’t any mandatory to implement algorithm, how is interoperability expected?

** Section 6.  I’m having trouble understanding who the “full TRL” download is for.

-- Section 13.1 says “The AS MUST ensure that ... only authorized and    authenticated administrators can retrieve the full TRL (see Section 9).”

-- Section 13.2 cautions:

  If many non-expired access tokens associated with a registered device
  are revoked, the pertaining subset of the TRL could grow to a size
  bigger than what the registered device is prepared to handle upon
  reception of a response from the TRL endpoint, especially if relying
  on a full query of the TRL (see Section 6).


It is there an assumption that administrators are operating on constrained devices to create issues with downloading the full TRL?

** Section 13.3

  In order to avoid this, a requester SHOULD NOT rely solely on the
  CoAP Observe notifications.  In particular, a requester SHOULD also
  regularly poll the AS for the most current information about revoked
  access tokens, by sending GET requests to the TRL endpoint according
  to a related application policy.

Are the requestors going to be constrained devices?  If so, both of these approaches seem problematic for device will limited battery power – either the device needs to stay awake to watch Observe notifications or it needs to poll.

** Section 13.5

  In order to minimize such a risk, if an RS relies solely on polling
  through individual requests to the TRL endpoint to learn of revoked
  access tokens, the RS SHOULD implement an adequate trade-off between
  the polling frequency and the maximum length of the vulnerable time
  window.

As above.  Would an RS ever be constrained because polling would impact the battery life.

[Ballot comment]
Thank you for writing this document -- I found it an interesting read (well, as much of it as I understood :-)). I especially liked the Examples section, which helped me a bunch...

Also, much much thanks to Dhruv Dhody for the initial OpsDir review (https://datatracker.ietf.org/doc/review-ietf-ace-revoked-token-notification-06-opsdir-lc-dhody-2024-04-01/), and then the followup "Ready" one (https://datatracker.ietf.org/doc/review-ietf-ace-revoked-token-notification-08-opsdir-telechat-dhody-2024-07-07/)

Much appreciated!

[Ballot comment]
Thanks for the work done on this document and thanks as well to Niklas Widell for his IoT directorate review (https://datatracker.ietf.org/doc/review-ietf-ace-revoked-token-notification-08-iotdir-telechat-widell-2024-07-04/), may I suggest to the authors to reply to Niklas' comments ?

Just a nit on this I-D: the text often uses Capitalisation, which is probably not required and is just an eye distraction (e.g., "Client" or "Server") and as noted by Niklas, some acronyms are introduced several times and/or never used.

As a side note, I am unsure whether the whole section 3.1 is useful as it seems to repeat what is specified in other documents.

Also, unsure whether using CBOR only on the TRL when the actual tokens can be CBOR or JSON is a simplification for the RS.

In section 6, is there a specification of an "administrator" in `If the requester is an administrator` ?

Kudos for using SVG graphics ;-)

[Ballot comment]
Thank you to Kyle Rose for doing the secdir review of this draft.  Also thanks to the authors for the discussions and improvements.

I have one last (easy?) question:

Section 13:  I expected to see some discussion on whether it is possible for an attacker to remove a revoked access token from the TRL allowing a registered device with a revoked access token to continue to participate.  Conversely, is it possible for an attacker to add an access token to the TRL, which would deny service to the registered device.  If these situations are not possible, what feature protects the TRL both at the AS and in transit?

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-ace-revoked-token-notification-08
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-08.txt&submitcheck=True

## Discuss

### token hashes aren't always hashes of tokens

Compression or encoding (inflation for readability) are a separate concern from identifying access tokens by digest.

```
557       Note that BYTES is the binary representation of the access token,
558       irrespective of this being a CWT or a JWT.

560   *  HASH_INPUT_TEXT is the base64url-encoded text string that encodes
561       BYTES.

563   *  HASH_INPUT is the binary representation of HASH_INPUT_TEXT.

```

This also creates a mismatch in what the hash is of:

cbor access_token -> cwt -> base64url -> hash
cbor access_token -> jwt -> base64url -> hash

json access_token -> jwt -> hash
json access_token -> cwt -> base64url -> hash

Why not make hash input always the bytes of the jwt or cwt (no compression, no encoding)?

It seems this might simplify the sections that follow as well.

The general guidance should be that the token hash identifies the bytes that are input to the token verification process.

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-ace-revoked-token-notification-08
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-08.txt&submitcheck=True

## Discuss

### token hashes aren't always hashes of tokens

The current guidance uses the word "token hash" to refer to "access_token" (the response parameter), but implementations will need to store and process the decoded result in the case of CWT, and in the case of JWT, the "access_token" is a "json web token", in the case of CWT, the "access_token" is a text encoded cbor web token, and in the case of CBOR conveyance of a JWT, the "access_token" is base64url encoded json web token.

Compression or encoding (inflation for readability) are a separate concern from identifying tokens.

```
557       Note that BYTES is the binary representation of the access token,
558       irrespective of this being a CWT or a JWT.

560   *  HASH_INPUT_TEXT is the base64url-encoded text string that encodes
561       BYTES.

563   *  HASH_INPUT is the binary representation of HASH_INPUT_TEXT.

```

This also creates a mismatch in what the hash is of:

cbor access_token -> cwt -> base64url -> hash
cbor access_token -> jwt -> base64url -> hash

json access_token -> jwt -> hash
json access_token -> cwt -> base64url -> hash

Why not make hash input always the bytes of the jwt or cwt (no compression, no encoding)?

It seems this might simplify the sections that follow as well.

The general guidance should be that the token hash identifies the bytes that are input to the token verification process.

[Ballot comment]

## Comments

### commented bytes not elided

```
1296           [ h'01fa51cc/...
1297               (remainder of the token hash omitted for brevity)/',
1298             h'01748190/...
1299               (remainder of the token hash omitted for brevity)/'
```

It could be just me, but I find this style of EDN confusing.

I prefer to see elision and comments not mixed, and instead see:

```
1296           [ h'01fa51...4819', / elided for brevity /
```


### not a token hash

```
1726   The RS MUST NOT delete the stored token hashes whose corresponding
1727   access tokens do not fulfill both the two conditions above, unless it
1728   becomes necessary due to memory limitations.  In such a case, the RS
1729   MUST delete the earliest stored token hashes first.
```

Related to my discuss point, hashes of encoded or compressed tokens are different than hashes of tokens (as bytes).

I don't think saying token or encoded token hashes whose corresponding access_token ... everywhere would be an improvement.


### cti is the new jti

```
1747   When, due to the stored and corresponding token hash th2, an access
1748   token t2 that includes the 'exi' claim is expunged or is not accepted
1749   upon its upload, the RS retrieves the sequence number sn2 encoded in
1750   the 'cti' claim (see Section 5.10.3 of [RFC9200]).  Then, the RS
1751   stores sn2 as associated with th2.  If expunging or not accepting t2
1752   yields the deletion of th2, then the RS MUST associate sn2 with th2
1753   before continuing with the deletion of th2.
```

Should you comment on jti (and JWT) here?
Does this section only apply to CWT ?

### No reference to JWT BCP?

https://datatracker.ietf.org/doc/html/rfc8725

Consider if the JWT BCP is a useful reference to add to security considerations.

### warn users about mutability

Signatures can have different forms (upper / lower s), unprotected headers can change the token hash, without invalidating the signature.

Some of these techniques could be used to mount resource exhaustian attacks.

### How should unavailability be treated?

```
1862   In order to avoid this, a requester SHOULD NOT rely solely on the
1863   CoAP Observe notifications.  In particular, a requester SHOULD also
1864   regularly poll the AS for the most current information about revoked
1865   access tokens, by sending GET requests to the TRL endpoint according
1866   to a related application policy.
```

If the GET request fails, the client assumes there are no revoked tokens?

Marco:

While addressing the received IETF Last Call comments, the authors would also like to make a change for using Problem Details (RFC 9290 [1]) as payload format for error responses.

Other than being appropriate per se, the same change:

* has recently happened in draft-ietf-ace-key-groupcomm and draft-ietf-ace-oscore-gm-admin

* has happened in draft-ietf-ace-workflow-and-params as part of updating RFC 9200; and

* is planned for draft-ietf-ace-key-groupcomm-oscore, also consistent and aligned with draft-ietf-ace-key-groupcomm

Absent objections, the authors plan to make this change and use the Problem Details format, when addressing the comments received during the IETF Last Call and producing version -07 of the draft.

(there were no objections, so waiting on revised ID)

Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dale Worley. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ace-revoked-token-notification-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are four actions which we must complete.

First, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration will be made as follows:

Name: ace-trl+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Content Type: application/ace-trl+cbor
Content Coding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Comment --> We will allocate the next available number from the 261-270 range.

Third, a new registry is to be created called the ACE Token Revocation List Parameters registry. The new registry will be located in the Authentication and Authorization for Constrained Environments (ACE) registry group located at:

https://www.iana.org/assignments/ace/

The new registry is to be managed via the following rules as defined in RFC8126:

CBOR Values Registration Policy
-------------+-------------------
< -65536 Private Use
-65536 to -257 Specification Required
-256 to 255 Standards Action with Expert Review
256 to 65535 Specification Required

There are initial values to be registered upon creation of the new registry as follows:

| Name | CBOR Value | CBOR Type | Reference |
| full_set | 0 | array | [ RFC-to-be ] |
| diff_set | 1 | array | [ RFC-to-be ] |
| cursor | 2 | unsigned integer / simple value "null" | [ RFC-to-be ] |
| more | 3 | simple value "false" / simple value "true" | [ RFC-to-be ] |
| error | 4 | integer | [ RFC-to-be ] |
| error_description | 5 | text string | [ RFC-to-be ] |

Fourth, a new registry is to be created called the ACE Token Revocation List Errors registry. The new registry will also be located in the Authentication and Authorization for Constrained Environments (ACE) registry group located at:

https://www.iana.org/assignments/ace/

The new registry is to be managed via the following rules as defined in RFC8126:

CBOR Values Registration Policy
-------------+-------------------
< -65536 Private Use
-65536 to -257 Specification Required
-256 to 255 Standards Action with Expert Review
256 to 65535 Specification Required

There are initial values to be registered upon creation of the new registry as follows:

| Value | Description | Reference |
| 0 | Invalid parameter value | [ RFC-to-be ] |
| 1 | Invalid set of parameters | [ RFC-to-be ] |
| 2 | Out of bound cursor value | [ RFC-to-be ] |

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-04-05):

From: The IESG
To: IETF-Announce
CC: ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-revoked-token-notification@ietf.org, goran.selander@ericsson.com, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'Notification of Revoked Access Tokens in the Authentication and
  Authorization for Constrained Environments (ACE) Framework'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-04-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a method of the Authentication and
  Authorization for Constrained Environments (ACE) framework, which
  allows an Authorization Server to notify Clients and Resource Servers
  (i.e., registered devices) about revoked access tokens.  As specified
  in this document, the method allows Clients and Resource Servers to
  access a Token Revocation List on the Authorization Server by using
  the Constrained Application Protocol (CoAP), with the possible
  additional use of resource observation.  Resulting (unsolicited)
  notifications of revoked access tokens complement alternative
  approaches such as token introspection, while not requiring
  additional endpoints on Clients and Resource Servers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/



No IPR declarations have been submitted directly on this I-D.

Here is my shepherd review of draft-ietf-ace-revoked-token-notification.



1. The working group consensus represents a strong concurrence of 7+ individuals with others being silent.



2-3. No controversy / discontent regarding particular points has been recorded.



4.  There is an existing implementation by Marco Rasori, CNR:



https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/



5. The contents relate to the constrained RESTful cluster of work which covers several working groups, but is essentially a "leaf-draft" which provides a feature for the ACE framework.



6. MIB and YANG seems not relevant. Media type and CoAP content-format review criteria are met.



7. The document does not contain YANG



8. No formal review tools have been used. Two simple examples of CDDL are included.



9. The draft is ready for AD review



10. No areas have identified any issues, area reviews still to come



11. The draft aims to be Proposed Standard, which is the proper type of RFC for this kind of protocol.

The datatracker state attributes correctly reflect this intent.



12. None of the authors of the current version (-05) are aware of any IPR that affects this draft. (Question asked by ACE chair earlier this year.)



13. All authors of the current version (-05) are willing to be listed as an author. (Question asked by ACE chair earlier this year.)



14. No remaining nits were found.



15. Normative and Informative References seems to be correctly attributed.



16. All normative references are freely available to anyone.



17. No normative downward references. All normative references are either BCP, Proposed Standard or Internet Standard.



18. No normative references to documents that are not ready to be submitted to the IESG for publication or otherwise in unclear state.



19. Publication of this document will not change the status of any existing RFCs.



20. IANA considerations



The required IANA assignments are complete and appropriate. The IANA considerations contain two registrations:

- media type for messages defined in this protocol and

- the associated CoAP content format.

and two new registries, listed in the next point.



The required IANA assignments are associated with the appropriate reservations in IANA registries. The referenced IANA registries have been clearly identified. Each newly created IANA registry specifies initial contents,

allocations procedures, and have a reasonable name .



21. The following new IANA registries are requested:



- ACE Token Revocation List Parameters

- ACE Token Revocation List Errors



The instructions to the Designated Expert are clear, but there are seem to be duplicate instructions in bullets 2 and 4:



- 'Specifications are needed for the "Expert Review" range if they are expected to be used outside of closed environments in an interoperable way.  When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.'



- ‘When specifications are not provided for a request where "Expert Review" is the assignment policy, the description provided needs to have sufficient information to verify the code points above.'



Some of the authors should be request to be designated experts.







In summary, with possible exception for the duplicate instructions mentioned in item 21, the document is ready to progress.



Göran

Here is my shepherd review of draft-ietf-ace-revoked-token-notification.



1. The working group consensus represents a strong concurrence of 7+ individuals with others being silent.



2-3. No controversy / discontent regarding particular points has been recorded.



4.  There is an existing implementation by Marco Rasori, CNR:



https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/



5. The contents relate to the constrained RESTful cluster of work which covers several working groups, but is essentially a "leaf-draft" which provides a feature for the ACE framework.



6. MIB and YANG seems not relevant. Media type and CoAP content-format review criteria are met.



7. The document does not contain YANG



8. No formal review tools have been used. Two simple examples of CDDL are included.



9. The draft is ready for AD review



10. No areas have identified any issues, area reviews still to come



11. The draft aims to be Proposed Standard, which is the proper type of RFC for this kind of protocol.

The datatracker state attributes correctly reflect this intent.



12. None of the authors of the current version (-05) are aware of any IPR that affects this draft. (Question asked by ACE chair earlier this year.)



13. All authors of the current version (-05) are willing to be listed as an author. (Question asked by ACE chair earlier this year.)



14. No remaining nits were found.



15. Normative and Informative References seems to be correctly attributed.



16. All normative references are freely available to anyone.



17. No normative downward references. All normative references are either BCP, Proposed Standard or Internet Standard.



18. No normative references to documents that are not ready to be submitted to the IESG for publication or otherwise in unclear state.



19. Publication of this document will not change the status of any existing RFCs.



20. IANA considerations



The required IANA assignments are complete and appropriate. The IANA considerations contain two registrations:

- media type for messages defined in this protocol and

- the associated CoAP content format.

and two new registries, listed in the next point.



The required IANA assignments are associated with the appropriate reservations in IANA registries. The referenced IANA registries have been clearly identified. Each newly created IANA registry specifies initial contents,

allocations procedures, and have a reasonable name .



21. The following new IANA registries are requested:



- ACE Token Revocation List Parameters

- ACE Token Revocation List Errors



The instructions to the Designated Expert are clear, but there are seem to be duplicate instructions in bullets 2 and 4:



- 'Specifications are needed for the "Expert Review" range if they are expected to be used outside of closed environments in an interoperable way.  When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.'



- ‘When specifications are not provided for a request where "Expert Review" is the assignment policy, the description provided needs to have sufficient information to verify the code points above.'



Some of the authors should be request to be designated experts.







In summary, with possible exception for the duplicate instructions mentioned in item 21, the document is ready to progress.



Göran