Ballot for draft-ietf-ace-revoked-token-notification
Discuss
Yes
No Objection
Recuse
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
# 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.
## 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?
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?
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 ;-)