Orie Steele has entered the following ballot position for draft-ietf-ace-revoked-token-notification-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/ ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- 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? _______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
