[Ace] Re: Orie Steele's Discuss on draft-ietf-ace-revoked-token-notification-08: (with DISCUSS and COMMENT)

[Marco Tiloca <[e-mail]>]

Hello Orie,

Thanks a lot for your review! Please find in line below our detailed 
replies to your comments.

A Github PR where we have addressed your comments is available at [PR].

Thanks,
/Marco

[PR] https://github.com/ace-wg/ace-revoked-token-notification/pull/13

On 2024-06-25 23:18, Orie Steele via Datatracker wrote:
> 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 tohttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C72300935721e46a3333e08dc955c5a7e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638549471090227810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Xp9IXGRRDf5QhFVsfuTduCPyzyUsUB8aG15YrBpexiI%3D&reserved=0 
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-revoked-token-notification%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C72300935721e46a3333e08dc955c5a7e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638549471090237972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qDQkrMmwTVpdG2wVj37CocoXhS5UaPhTVh9DmmRDhl8%3D&reserved=0
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> # Orie Steele, ART AD, comments for draft-ietf-ace-revoked-token-notification-08
> CC @OR13
>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-revoked-token-notification-08.txt%26submitcheck%3DTrue&data=05%7C02%7Cmarco.tiloca%40ri.se%7C72300935721e46a3333e08dc955c5a7e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638549471090243777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8mSA2Tn0PgJzW0KXznSsgyrLz72ngPs%2Fpr68EeTzDHo%3D&reserved=0
>
> ## 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.

==>MT

**Short answer** --- The current design reflects the best that we have 
found possible to do in the light of three points:

* Achieving the goal of deterministically "labeling" access tokens in a 
way that is not ambiguous and that works for all the three ACE actors 
involved (AS, RS, C).
* Dealing with the fact that access tokens are opaque to C.
* Living with and preserving the flexibility that the ACE framework 
provides as to CBOR/JSON message encoding and CWTs/JWTs as types of 
access tokens.


**Long answer** --- The following refers to the four cases below. Note 
that all of them are admitted in the ACE framework (RFC 9200), largely 
due to the intentional compatibility with the OAuth ecosystem based on 
JSON and JWTs.

* Case 1 - The AS-to-C response is encoded in CBOR, and it transports a CWT.
* Case 2 - The AS-to-C response is encoded in CBOR, and it transports a JWT.
* Case 3 - The AS-to-C response is encoded in JSON, and it transports a JWT.
* Case 4 - The AS-to-C response is encoded in JSON, and it transports a CWT.

Let's break this down into three parts.


**Part 1 --- The points from the review comment are correct**

* It is correct that the hash input is not always the access token. In 
fact, that's the case only in Case 3.

* It is correct that inflation and identification are separate concerns. 
However, they do not necessarily conflict, and they do not in this 
document (see also the later Part 3 of this answer).

* It is correct that the token hash should **identify** the bytes that 
are input to the token verification process.

   In three out of four cases, the token hash is not computed directly 
on the access token. Nevertheless, a token hash effectively points the 
RS, C, and the AS to a corresponding access token in an unambiguous and 
deterministic way, thereby identifying such an access token as intended.

   This document does so while also preserving the intentional 
flexibility that the ACE framework has in supporting CBOR or JSON 
encoded messages conveying CWTs or JWTs as access tokens.

Granted: the name used in the document is "token hash", even though the 
hash is not computed directly from the access token in three out of four 
cases.

However, while such a name might not 100% accurately reflect what 
actually happens, it is a simple and short name that correctly refers to 
a hash identifying an access token.

Consistently, the document talks about a token hash **corresponding** to 
an access token as its associated label, and it specifies what the exact 
hash input has to be for each case.

Given an access token, the goal is ultimately for all the three ACE 
actors (AS, RS, and C) to always converge to the same identifier of that 
access token.

Per the current definition of hash input and token hash, this document 
always achieves that goal, while still ensuring the flexibility provided 
by the ACE framework and aligned with the OAuth ecosystem.

As a result of the incremental design process made on this document, the 
current design reflects the best that we have found possible to use, in 
the light of the intended objectives as well as of how the ACE framework 
works and the flexibility that it provides. This is further elaborated 
in the next part of this answer.


**Part 2 --- There is not a better and workable way**

The hash input cannot simply and always be the (possibly tagged) access 
token verbatim: that would prevent from preserving the flexibility 
provided by the ACE framework and aligned with the OAuth ecosystem, as 
to using CBOR or JSON encoded messages conveying CWTs or JWTs as access 
tokens.

If the hash input was the access token verbatim, then there would be no 
way to ensure that all the three ACE actors (AS, RS, and C) can 
deterministically compute the same hash to use as identifier of the 
given access token, in **any of the four cases** outlined above.

The following is a list of the most compelling reasons.

* In Case 4, C never receives the access token verbatim in the first 
place, but only its base64url encoding as computed by the AS.

   This is not something defined in this document, but it is rather 
admitted in the ACE framework in the interest of the flexibility and 
alignment with OAuth discussed above.

* In all the four cases, the access token is opaque to C.

   (In Case 4, as discussed in the previous point, C does not even 
receive the access token verbatim.)

   Per the current definition of hash input and token hash, this is 
however not an issue for the method defined in this document.

* Fundamentally, Case 4 is a legitimate corner case that prevents from 
simply hashing the access token verbatim while still ensuring that the 
three ACE actors (AS, RS, and C) always converge to the same identifier 
of the access token.

   Instead, we believe that the current definition of hash input and 
token hash is the best possible, because:

   - All the three ACE actors always converge to the same token hash, 
which they all use as unambiguous identifier of a given access token, as 
the ultimate intended goal.

   - The RS is always able to produce a reliable and safe token hash, in 
spite of not being able to know whether the AS-to-C response was encoded 
in CBOR (Case 1 and Case 2) or in JSON (Case 3 and Case 4).

     In this respect, as discussed in detail in Section 13.6 "Two Token 
Hashes at the RS using JWTs", we decided to deliberately penalize the 
cases where JWTs are used (Case 2 and Case 3), in favor of the cases 
where CWTs are used (Case 1 and Case 4) as the default and expected type 
of access tokens in the ACE framework.


**Part 3 --- Fundamentally, the current design works and achieves the 
intended goal**

The goal of the proposed method is to compute an identifier of an access 
token such that the following holds.

* The method allows all the three ACE actors (AS, RS, and C) to always 
deterministically compute that identifier.

* The method works in all the four cases outlined above, i.e., it 
preserves the flexibility of the ACE framework as to using CBOR or JSON 
encoded messages conveying CWTs or JWTs as access tokens.

* The method deals with the fact that access tokens are opaque to C.

* The method deals with the fact that, in AS-to-C responses encoded in 
JSON, access tokens are encoded differently depending on being JWTs 
(Case 3) or CWTs (Case 4).

* The method deals with the fact that the RS is not able to know whether 
the AS-to-C response was encoded in CBOR (Case 1 and Case 2) or in JSON 
(Case 3 and Case 4).

Since the above does hold for the proposed method and the three ACE 
actors do deterministically converge to the same identifier for the same 
access token, we do not see a real issue from the fact that the hash 
input is not always the access token verbatim.

In fact, when it is not (i.e., in Case 1, Case 2, and Case 4), the hash 
input is the base64url encoding of the access token, which is in turn 
deterministically computed from the access token verbatim.

<==

>
>
> ----------------------------------------------------------------------
> 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 /
> ```

==>MT

We have accordingly revised all the examples that use CBOR diagnostic 
notation with elision.

This applies to:

* Figure 6: Example of response following a full query request to the 
TRL endpoint

* Figure 8: Example of response following a diff query request to the 
TRL endpoint

<==

> ### 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.

==>MT

This answer largely builds on the answer to the main DISCUSS point above.

True, the hash input used to compute a token hash is not the access 
token verbatim in three cases out of four. However, the result is indeed 
a value that unambiguously corresponds to the access token and can be 
deterministically computed by all the three ACE Actors (AS, RS, and C).

Practically, we need token identifiers that all the three ACE actors can 
independently and deterministically compute, in a way that works for all 
the cases admitted by ACE, i.e., preserving the flexibility of the ACE 
framework in supporting CBOR or JSON encoded messages conveying CWTs or 
JWTs as access tokens.

So "token hash" might not 100% accurately reflect what actually happens, 
but we think that it is a term still appropriate and convenient to use, 
since:

* It is simple and short.

* It reflects the fact that its value is computed as the result of a 
hash operation.

* It reflects the fact that its value is associated with an access token.

* It deliberately avoids the word "identifier", thus avoiding confusion 
with other identifiers such as 'jti' for JWTs and 'cti' for CWTs (see 
also the remark in the first bullet point of Section 1.1 "Terminology"), 
which are also not pertaining to C.

Therefore, we would prefer to keep the term "token hash".

<==

> ### 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 ?

==>MT

In the quoted text from Section 10.1 "Handling of Access Tokens and 
Token Hashes", the 'cti' claim embeds a Sequence Number value for 
securely handling specifically CWTs that include the 'exi' claim. Such a 
method is defined in Section 5.10.3 of RFC 9200.

In fact, Section 5.10.3 of RFC 9200 does define that the same secure 
handling is used also for JWTs that include the 'exi' claim, by 
embedding a Sequence Number in their 'jti' claim.

We have extended the text in Section 10.1 "Handling of Access Tokens and 
Token Hashes" to cover also JWTs as follows.

OLD:
 > ... and iii) has the sequence number encoded in the 'cti' claim 
greater than the highest sequence number among the expired access tokens 
specifying the 'exi' claim for the RS (see Section 5.10.3 of [RFC9200]).

NEW:
 > ... and iii) has the sequence number encoded in the 'cti' claim (for 
CWTs) or in the 'jti' claim (for JWTs) greater than the highest sequence 
number among the expired access tokens specifying the 'exi' claim for 
the RS (see Section 5.10.3 of [RFC9200]).


OLD:
 > When, due to the stored and corresponding token hash th2, an access 
token t2 that includes the 'exi' claim is expunged or is not accepted 
upon its upload, the RS retrieves the sequence number sn2 encoded in the 
'cti' claim (see Section 5.10.3 of [RFC9200]).

NEW:
 > When, due to the stored and corresponding token hash th2, an access 
token t2 that includes the 'exi' claim is expunged or is not accepted 
upon its upload, the RS retrieves the sequence number sn2 encoded in the 
'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) (see Section 
5.10.3 of [RFC9200]).

<==

> ### No reference to JWT BCP?
>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8725&data=05%7C02%7Cmarco.tiloca%40ri.se%7C72300935721e46a3333e08dc955c5a7e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638549471090248190%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QLesQ%2FfXPRdb6l3PPTeIgj2cbmxADV%2B4qOi2ETa6zFM%3D&reserved=0
>
> Consider if the JWT BCP is a useful reference to add to security considerations.

==>MT

We have revised the first paragraph of the Section 13.0 "Security 
Considerations" as follows, by extending the list of inherited 
considerations as pointing also to RFC 8725.

OLD:
 > The protocol defined in this document inherits the security 
considerations from the ACE framework for Authentication and 
Authorization [RFC9200], from [RFC8392] as to the usage of CWTs, from 
[RFC7519] as to the usage of JWTs, from [RFC7641] as to the usage of 
CoAP Observe, and from [RFC6920] with regard to computing the token 
hashes. The following considerations also apply.

NEW (emphasis mine):
 > The protocol defined in this document inherits the security 
considerations from the ACE framework for Authentication and 
Authorization [RFC9200], from [RFC8392] as to the usage of CWTs, from 
[RFC7519] **and [RFC8725]** as to the usage of JWTs, from [RFC7641] as 
to the usage of CoAP Observe, and from [RFC6920] with regard to 
computing the token hashes. The following considerations also apply.

<==

> ### 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.

==>MT

(This is a long answer)

It is not clear what "signature" refers to (the word is not used in the 
document) and what exhaustion attack is possible because of the method 
proposed in this document. Access tokens might be issued specifically as 
signed objects, but that does not play a role here.

The hash input used to compute the token hash of an access token is 
deterministically prepared based on what is on the wire, i.e., what is 
in the AS-to-C response or in the message sent to the RS for uploading 
the access token.

Note that the RS does not store a token hash in case the RS fails to 
validate the corresponding, uploaded access token (which the RS also 
discards).

Specifically on exhaustion attacks, that is possibly a general concern 
when signed access tokens are repeatedly sent to the RS that attempts to 
verify those. In this respect, the method proposed in this document does 
not make such a general concern any worse. For the RS, computing the 
token hash is a parallel and orthogonal process to the verification of 
an access token, and certainly orders of magnitude lighter than the 
verification of a signature.


Yet, thanks to this comment and while thinking through it, we also 
noticed one more detail to fix, in order to ensure that the RS always 
computes the right token hash as intended by the AS.

Otherwise, an attack is possible in case the access token is uploaded to 
the RS over an unprotected communication channel (which is the basic 
case in the ACE framework). In particular, an active adversary can 
intercept the access token when this is sent to the RS and perform the 
following actions.

* The adversary manipulates the access token in a way which is going to 
be unnoticed by the RS, but without preventing the successful, 
cryptographic validation of the access token at the RS. To this end, the 
adversary has two possible options:
     - Adding and/or removing fields in the unprotected header(s) of the 
access token, as long as those fields do not play a role in the 
cryptographic validation of the access token.
     - Specifically when access tokens are CWTs, adding/removing or 
manipulating possible CBOR tag(s) enclosing the access tokens.

* The adversary sends the manipulated access token to the RS.

* Since the content of the unprotected header(s) as well as possible 
CBOR tags are not integrity-protected, the manipulations mentioned above 
does not impact the outcome of the access token validation performed by 
the RS, and it will go unnoticed.

* After a successful validation of the access token, the RS computes a 
corresponding token hash different from the one computed and stored by C 
and the AS.

* The RS stores the access token and the corresponding, wrong token hash.

If later on the access token is revoked, the AS provides the 
corresponding, correct token hash to the RS. However, the RS does not 
recognize the received token hash among the stored ones, and does not 
delete the revoked access token.


Intuitively, the attack above can be prevented as follows.

**An AS** providing the service defined in this document must issue 
access tokens such that the following holds.

* The access tokens do not include any parameter in the unprotected 
headers. That is, unprotected headers must be empty in CWTs and absent 
in JWTs.

   Instead, information to be conveyed by such parameters must be 
specified by parameters included in the protected headers, which are 
integrity-protected by the AS.

* When access tokens are specifically CWTs, they are always enclosed by 
exactly two CBOR tags.

   - The inner tag has number 16/17/18/96/97/98, consistent with the 
used COSE data item (e.g., COSE_Encrypt0 and tag number 16). That is, a 
CWT must be computed as a COSE_Tagged_Message (see Section 2 of RFC 9052).

   - The outer tag has number 61 (see RFC 8392), consistent with the 
fact that the access token is a CWT.

     (In a general case, the outer tag 61 would be optional to include. 
However, it feels safer for future use cases that might really need its 
presence to have it included rather than not in this deterministic 
construction.)

   - The number of both the inner and outer tag must be encoded to have 
the minimum possible length. E.g., the tag number 16 must be encoded 
exactly as 0xd0.

     (Section 9 of RFC 9052 does make restrictions of this sort, but not 
on the encoding of CBOR tag numbers applied to COSE messages)

**An RS** that uses the service defined in this document with the AS 
that has issued the access token must not accept and must discard an 
access token such that:

* The access token does not fulfill all the requirements above; or

* The access token is a CWT, and the tag number of the inner tag is not 
consistent with the actual type of the COSE data item to process (e.g., 
the tag number of the inner tag is 16, but the CWT is actually a COSE_Sign).

   (We would have expected that such consistency check was already 
mandated by COSE, but apparently it is not the case.)



What follows is the list of related, intended updates in the document 
and already in the Github PR.

(Some updated text referring to "(tagged) access token" is actually more 
accurate and good to have anyway, as it explicitly considers also the 
case of tagged CWTs.)

We have also discussed this fix with an implementer and reviewer of the 
draft, who agrees that this fix is simple and effective.


**New Section "Issuing of Access Tokens at the AS"**

This section defines requirements on the access tokens issued by the AS, 
separately for CWTs and JWTs.

It fits well between the current Section 2 "Protocol Overview" and 
Section 3 "Token Hash" of version -08.

The text of this new section is as follows.

NEW:
 > An AS that supports the method defined in this document MUST adhere 
to the following rules when issuing an access token.
 >
 > * All the intended header parameters in the access token MUST be 
specified within integrity-protected fields.
 >
 > * If the access token is a CWT, the following applies.
 >
 >   - Any "unprotected" field MUST be empty, i.e., its value MUST be 
encoded as the empty CBOR map (0xa0). This applies to: the top-level 
"unprotected" field of the COSE object used for the CWT; the 
"unprotected" field of each element of the "signatures" array; and the 
"unprotected" field of each element of any "recipients" array (see 
Sections 2, 3, 4, 5, and 6 of [RFC9052]).
 >
 >   - Consistent with the specific COSE object used for the CWT, the 
corresponding tagged structure in the set COSE_Tagged_Message MUST be 
used (see Section 2 of [RFC9052]). That is, the CBOR array that encodes 
the CWT MUST be tagged by using the COSE CBOR tag corresponding to the 
used COSE object. Table 1 in Section 2 of [RFC9052] specifies the tag 
numbers in question.
 >
 >     In turn, the resulting tagged data item MUST be tagged by using 
the CWT CBOR tag with tag number 61 (see Section 6 of [RFC8392]). After 
that, the resulting data item MUST NOT be further tagged.
 >
 >     Encoding of the tag numbers MUST be done using definite lengths, 
and the length of the encoded tag numbers MUST be the minimum possible 
length. This means that the tag number 16 is encoded as 0xd0 and not as 
0xd810.
 >
 >     The example in Figure \<FIGURE_NUMBER\> shows a CWT that uses the 
COSE object COSE_Encrypt0 (see Section 5.2 of [RFC9052]).
 >
 > * If the access token is a JWT, the following applies.
 >
 >   - If the access token is specifically a JWS [RFC7515] that uses the 
JWS JSON Serialization, it MUST NOT include the JWS Unprotected Header.
 >
 >   - If the access token is specifically a JWE [RFC7516] that uses the 
JWE JSON Serialization, it MUST NOT include the JWE Shared Unprotected 
Header and it MUST NOT include the "header" member in any of the 
elements of the "recipients" array.

```
/ CWT CBOR tag / 61(
   / COSE_Encrypt0 CBOR tag / 16(
     / COSE_Encrypt0 object / [
       / protected /   h'a3010a044c53796d6d65747269633132
                         38054d99a0d7846e762c49ffe8a63e0b',
       / unprotected / {},
       / ciphertext /  h'b918a11fd81e438b7f973d9e2e119bcb
                         22424ba0f38a80f27562f400ee1d0d6c
                         0fdb559c02421fd384fc2ebe22d70713
                         78b0ea7428fff157444d45f7e6afcda1
                         aae5f6495830c58627087fc5b4974f31
                         9a8707a635dd643b'
     ]
   )
)

Figure \<FIGURE_NUMBER\>
```

 > Section \<"Preventing Unnoticed Manipulation of Access Tokens"\> 
discusses how adhering to the rules above neutralizes an attack against 
the RS, where an active adversary can induce the RS to compute a token 
hash different from the correct one.


**Section 3.0 of v -08**

New paragraphs at the end of the section.

NEW:
 > Consistent with Section 3.4 of [RFC8949], the term "tag" is used for 
the entire CBOR data item consisting of both a tag number and the tag 
content: the tag content is the CBOR data item that is being tagged.
 >
 > Also, "tagged access token" is used to denote nested CBOR tags 
(possibly a single one), with the innermost tag content being a CWT.


**Section 3.1.1 of v -08**

OLD:
 > This implies that, within the CBOR map specified as message payload, 
the parameter 'access_token' is a CBOR data item of type CBOR byte 
string and with value the binary representation BYTES of the access 
token. In particular:
 >
 > * If the access token is a CWT, then BYTES is the binary 
representation of the CWT (i.e., of the CBOR array that encodes the CWT).
 > ...

NEW:
 > This implies that, within the CBOR map specified as message payload, 
the parameter 'access_token' is a CBOR data item of type CBOR byte 
string and with value BYTES. In particular:
 >
 > * If the access token is a CWT, then BYTES is the binary 
representation of the CWT (i.e., of the CBOR array that encodes the 
untagged CWT) or of a tagged access token with the CWT as innermost tag 
content.
 > ...


OLD:
 > This implies that, within the JSON object specified as message 
payload, the parameter 'access_token' has as value a text string TEXT 
encoding the access token. In particular:
 > ...
 > * If the access token is a CWT, then TEXT is the base64url-encoded 
text string of the binary representation of the CWT (i.e., of the CBOR 
array that encodes the CWT).

NEW:
 > This implies that, within the JSON object specified as message 
payload, the parameter 'access_token' has as value a text string TEXT. 
In particular:
 > ...
 > * If the access token is a CWT, then TEXT is the base64url-encoded 
text string of BYTES, which is the binary representation of the CWT 
(i.e., of the CBOR array that encodes the untagged CWT) or of a tagged 
access token with the CWT as innermost tag content.


**Section 3.1.2 of v -08**

OLD:
 > If the AS-to-Client response was encoded in CBOR, then TOKEN_INFO is 
the value of the CBOR byte string conveyed by the 'access_token' 
parameter of that response. This is irrespective of the access token 
being a CWT or a JWT. That is, TOKEN_INFO is the binary representation 
of the access token.

NEW:
 > If the AS-to-Client response was encoded in CBOR, then TOKEN_INFO is 
the value of the CBOR byte string conveyed by the 'access_token' 
parameter of that response. That is, TOKEN_INFO is the binary 
representation of the (tagged) access token.


OLD:
 > If the AS-to-Client response was encoded in JSON and the access token 
is a CWT, then ... text string that encodes the binary representation of 
the access token. That is, ...

NEW:
 > If the AS-to-Client response was encoded in JSON and the access token 
is a CWT, then ... text string that encodes the binary representation of 
the (tagged) access token. That is, ...


OLD (4 instances):
 > The access token can be uploaded to the RS ...

NEW (4 instances):
 > The (tagged) access token can be uploaded to the RS ...


**Section 3.2.0 of v -08**

OLD:
 > ... where the access token is included and provided to the requester 
Client.

NEW:
 > ... where the (tagged) access token is included and provided to the 
requester Client.


**Section 3.2.1 of v -08**

OLD
 > With reference to the example in Figure 2, BYTES is the bytes {0xd0 
0x83 0x43 ... 0x64 0x3b}.

NEW
 > With reference to the example in Figure 2, BYTES is the bytes {0xd8 
0x3d 0xd0 ... 0x64 0x3b}.


OLD:
 > Note that BYTES is the binary representation of the access token, 
irrespective of this being a CWT or a JWT.

NEW:
 > Note that BYTES is the binary representation of the tagged access 
token if this is a CWT (as per Section \<"Issuing of Access Tokens at 
the AS"\>), or of the access token if this is a JWT.


OLD
```
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Max-Age: 85800
Payload:
{
    / access_token / 1 : h'd08343a1010aa2044c53796d6d65
                           74726963313238054d99a0d7846e
                           762c49ffe8a63e0b5858b918a11f
                           d81e438b7f973d9e2e119bcb2242
                           4ba0f38a80f27562f400ee1d0d6c
                           0fdb559c02421fd384fc2ebe22d7
                           071378b0ea7428fff157444d45f7
                           e6afcda1aae5f6495830c5862708
                           7fc5b4974f319a8707a635dd643b',
    / token_type /  34 : 2 / PoP /,
    / expires_in /   2 : 86400,
    / ace_profile / 38 : 1 / coap_dtls /,
    / (remainder of the response omitted for brevity) /
}
```

NEW
```
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Max-Age: 85800
Payload:
{
    / access_token / 1 : h'd83dd0835820a3010a044c53796d6d
                           6574726963313238054d99a0d7846e
                           762c49ffe8a63e0ba05858b918a11f
                           d81e438b7f973d9e2e119bcb22424b
                           a0f38a80f27562f400ee1d0d6c0fdb
                           559c02421fd384fc2ebe22d7071378
                           b0ea7428fff157444d45f7e6afcda1
                           aae5f6495830c58627087fc5b4974f
                           319a8707a635dd643b',
    / token_type /  34 : 2 / PoP /,
    / expires_in /   2 : 86400,
    / ace_profile / 38 : 1 / coap_dtls /,
    / (remainder of the response omitted for brevity) /
}
```


**Section 3.2.2 of v -08**

OLD
 > With reference to the example in Figure 3, HASH_INPUT is the binary 
representation of "2YotnFZFEjr1zCsicMWpAA".

NEW (JWT taken from Appendix A.1 of RFC 7519):
 > With reference to the example in Figure 3, HASH_INPUT is the binary 
representation of "eyJh...YFiA". When showing the access token, Figure 3 
uses line breaks for display purposes only.
 > ...


OLD:
 > * If the access token is a CWT, then HASH_INPUT is the binary 
representation of the base64url-encoded text string that encodes the 
binary representation of the CWT.

NEW:
 > * If the access token is a CWT, then HASH_INPUT is the binary 
representation of a base64url-encoded text string, which encodes the 
binary representation of a tagged access token with the CWT as innermost 
tag content (as per Section \<"Issuing of Access Tokens at the AS"\>).


OLD
```
HTTP/1.1 200 OK
Content-Type: application/ace+json
Cache-Control: no-store
Pragma: no-cache
Payload:
{
    "access_token" : "2YotnFZFEjr1zCsicMWpAA",
    "token_type"   : "pop",
    "expires_in"   : 86400,
    "ace_profile"  : "1"
}
```

NEW (JWT taken from Appendix A.1 of RFC 7519):
```
HTTP/1.1 200 OK
Content-Type: application/ace+json
Cache-Control: no-store
Pragma: no-cache
Payload:
{
    "access_token" : "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB
                      MTI4Q0JDLUhTMjU2In0.
                      QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8
                      qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
                      oNfABIPJaZm0HaA415sv3aeuBWnD8J-U
                      i7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
                      TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvW
                      n_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
                      sOTsgruobpYGoQcXUwFDn7moXPRfDE8-
                      NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
                      YCitxoQVPzjbl7WBuB7AohdBoZOdZ24W
                      lN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
                      1rZgN5TiysnmzTROF869lQ.
                      AxY8DCtDaGlsbGljb3RoZQ.
                      MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW
                      nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
                      HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7
                      sln1Eu9g3J8.
                      fiK51VwhsxJ-siBMR-YFiA",
    "token_type"   : "pop",
    "expires_in"   : 86400,
    "ace_profile"  : "1"
}
```


**Section 3.3.1 of v -08**

OLD:
 > Hence, the RS assumes TOKEN_INFO to be the binary representation of 
the access token.

NEW:
 > Hence, the RS assumes TOKEN_INFO to be the binary representation of 
the tagged access token with the CWT as innermost tag content (as per 
Section \<"Issuing of Access Tokens at the AS"\>).


OLD:
 > Hence, the RS assumes TOKEN_INFO to be the binary representation of 
HASH_INPUT_TEXT, which is the base64url-encoded text string that encodes 
the binary representation of the access token.

NEW:
 > Hence, the RS assumes TOKEN_INFO to be the binary representation of 
HASH_INPUT_TEXT. In turn, HASH_INPUT_TEXT is the base64url-encoded text 
string that encodes the binary representation of the tagged access token 
with the CWT as innermost tag content (as per Section \<"Issuing of 
Access Tokens at the AS"\>).


OLD:
 > ... and considers the result as the binary representation of the 
access token.

NEW:
 > ... and considers the result as the binary representation of the 
tagged access token.


**Section 10.1 of v -08**

OLD:
 > An RS MUST NOT accept and store an access token, if the corresponding 
token hash is among the currently stored ones.

NEW:
 > If an RS uses the method defined in this document with the AS that 
has issued an access token, then the RS MUST NOT accept and store that 
access token if any of the following holds.
 >
 > * The token hash corresponding to the access token is among the 
currently stored ones.
 >
 > * The access token is a CWT and any of the following holds.
 >
 >   - The access token includes a non-empty "unprotected" field, i.e., 
the value of the field is not encoded as the empty CBOR map (0xa0). This 
applies to: the top-level "unprotected" field of the COSE object used 
for the CWT; the "unprotected" field of each element of the "signatures" 
array; and the "unprotected" field of each element of any "recipients" 
array.
 >
 >   - The received CBOR data item that embodies the access token does 
not comply with what is defined in Section \<"Issuing of Access Tokens 
at the AS"\>. This concerns: the use of exactly two nested CBOR tags, 
where the outer tag is the CWT CBOR tag and the inner tag is one of the 
COSE CBOR tags; the tag numbers encoded with the minimum possible 
length; and the access token being the innermost tag content of the 
received CBOR data item.
 >
 >   - In the received CBOR data item that embodies the access token, 
the inner tag has a tag number that is not consistent with the actual 
COSE data item to process. For instance, the inner tag number is 16 
(COSE_Encrypt0), but the CWT is actually a COSE_Sign data item.
 >
 > * The access token is a JWT and any of the following holds.
 >
 >   - The access token is specifically a JWS [RFC7515] using the JWS 
JSON Serialization, and it includes the JWS Unprotected Header.
 >
 >   - The access token is specifically a JWE [RFC7516] using the JWE 
JSON Serialization, and it includes the JWE Shared Unprotected Header 
and/or includes the "header" member in any of the elements of the 
"recipients" array.


**New Section "Preventing Unnoticed Manipulation of Access Tokens"**

This section provides security considerations on this topic.

It fits well between Section 13.5 "Vulnerable Time Window at the RS" and 
Section 13.6 "Two Token Hashes at the RS using JWTs" of version -08.

The text of this new section is as follows.

NEW:
 > As defined in Section \<"Issuing of Access Tokens at the AS"\>, 
issued access tokens MUST NOT rely on unprotected headers to specify 
information as header parameters. Also, when issued access tokens are 
CWTs, they MUST be tagged by using the COSE CBOR tag corresponding to 
the used COSE object, the result MUST be in turn tagged by using the CWT 
CBOR tag, and no further tagging is performed.
 >
 > This ensures that the RS always computes the correct token hash 
corresponding to an access token, i.e., the same token hash computed by 
the AS and C for that access token.
 >
 > By construction, the rules defined in Section \<"Issuing of Access 
Tokens at the AS"\> prevent an active adversary from successfully 
performing an attack against the RS, which would otherwise be possible 
in case the access token is uploaded to the RS over an unprotected 
communication channel.
 >
 > In such an attack, the adversary intercepts the access token when 
this is sent to the RS. Then, the adversary manipulates the access token 
in a way which is going to be unnoticed by the RS, but without 
preventing the successful, cryptographic validation of the access token 
at the RS. To this end, the adversary has two possible options:
 >
 > * Adding and/or removing fields within the unprotected header(s) of 
the access token, as long as those fields do not play a role in the 
cryptographic validation of the access token.
 > * Specifically when the access token is a CWT, adding/removing or 
manipulating possible CBOR tag(s) enclosing the access token.
 >
 > After that, the adversary sends the manipulated access token to the RS.
 >
 > After having successfully validated the manipulated access token, the 
RS computes a corresponding token hash different from the one computed 
and stored by C and the AS. Finally, the RS stores the manipulated 
access token and the corresponding wrong token hash.
 >
 > 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 the 
received token hash among the stored ones, and therefore does not delete 
the revoked access token.

<==

> ### 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?
>

==>MT

No. In case a requester does not receive a response from the TRL 
endpoint or it receives an error response from the TRL endpoint, the 
requester makes no assumption regarding the revocation or expiration of 
its pertaining access tokens.

We have explicitly clarified it in the earlier Section 10 "Notification 
of Revoked Access Tokens", by including a new paragraph between the 
current second paragraph and the current third paragraph.

OLD:
 > In case the request is successfully processed, ...
 >
 > When the TRL is updated (see Section 4.1) ...

NEW:
 > In case the request is successfully processed, ...
 >
 > In case a requester does not receive a response from the TRL endpoint 
or it receives an error response from the TRL endpoint, the requester 
does not make any assumption or draw any conclusion regarding the 
revocation or expiration of its pertaining access tokens.
 >
 > When the TRL is updated (see Section 4.1) ...


Many thanks again for your comments!

<==


-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se