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

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?

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.

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.

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!

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.

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 ;-)