Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

[Marco Rasori <[e-mail]>]

Hi all,

Please, see below my WGLC comments.

Best,
Marco



[Section 1]

* The sentences
  "This document specifies a method for allowing registered devices
to access and possibly subscribe to a Token Revocation List (TRL)
resource on the AS, in order to obtain an updated list of revoked,
but yet not expired, pertaining Access Tokens."
and
  "Instead, registered devices simply obtain an updated list of revoked,
but yet not expired, pertaining Access Tokens, as efficiently identified
by corresponding hash values."

are valid for the full query mode only. I refer, in particular, to the
expression "but not expired yet", used in both sentences.

With the diff query mode, registered devices can obtain revoked AND expired
Access Tokens.
At the exact moment an Access Token (to be revoked) is added to the TRL,
that Access Token is not expired yet.
However, the TRL may respond to the requester with information on revoked
pertaining Access Token that have been removed from the TRL resource, and,
therefore, expired.

My suggestion is to rephrase these sentences, still without differentiating
among the modes.


[Section 2]

* The sentence
  "At any time, the registered device can send a GET request to the TRL
endpoint. When doing so, it can request for: the current list of pertaining
revoked Access Tokens (see Section 6); or the most recent TRL updates
occurred over the list of pertaining revoked Access Tokens (see Section 7)."

The usage of the term "TRL update" is misleading. At this point of the
document, such a term has not been defined yet, but it has a precise
meaning. Without the definition, one may understand that in this case he
will obtain the most recent and pertaining token hashes of Access Tokens
present in the TRL, i.e., the most recent pertaining Access Token revoked
but not expired yet.

Consider replacing the word 'TRL updates' with 'updates' to be more general.


* Figure 1 shows the dispatch of 5 messages in a timeless fashion.

The only way this figure can work according to this specification is that a
single update of the TRL includes the revocation of t1, t2, and t3.

I suggest to stress that the update to the TRL resource is one, and it
covers the revocation of three Access Tokens, following which the
notifications are sent.


[Section 3]

* In Figure 3, change the value of the key "access_token" from
   "2YotnFZFEjr1zCsicMWpAA ...
   (remainder of the Access Token omitted for brevity) ..."
to
   "2YotnFZFEjr1zCsicMWpAA"


[Section 4]

* In Section 4.1, I would specify that an update of the TRL does not
necessarily mean that a single token hash is added or removed from it.

The TRL resource COULD undergo an update that consists in the addition
and/or removal of more than one token hash.

For example, if a registered device is decommissioned, and all of its
pertaining Access Tokens have to be revoked, the AS could perform a single
update of the TRL consisting of all the token hashes related to the Access
Tokens pertaining to that registered device.


[Section 5]

* In Section 5.2, among the conditions for which AS MUST return a 4.00 (Bad
Request) response, following a GET request specifying the 'cursor' query
parameter, we have:
  "-The 'cursor' query parameter has a value other than 0 or than a
positive integer."
and
  "-The 'cursor' query parameter has a value strictly greater
than MAX_INDEX (see Section 5.1.1)."

The response for the former case includes
   "The 'error' parameter within the CBOR map carried in the response
payload MUST have value 0 ("Invalid parameter value")."
while the latter includes
   "The 'error' parameter within the CBOR map carried in the response
payload MUST have value 0 ("Invalid parameter value"). The CBOR map MUST
also include the 'cursor' parameter, which MUST specify either: the CBOR
simple value "null" (0xf6), if the update collection associated with
the requester is empty; or the corresponding current value of 'last_index'
otherwise."

I do not understand the reason to differentiate between the two cases. Why
not have a single condition checking whether the 'cursor' value is in the
range [0, MAX_INDEX]?
If not in this range, the response could contain 'error' with value
"Invalid parameter value", and 'cursor' with value the CBOR simple value
"null" (0xf6) or 'last_index', as in the response to the second condition,
thus always giving information about the cursor value to the requester.

Note that if we assume that the cursor value "was provided by the AS in a
previous response from the TRL endpoint", the AS will never give the
requester a value not in this range.
In both the conditions, the requester is using a deliberately made-up value.


[Section 7]

* I would replace the phrase
  "If the AS does not support both diff queries and the "Cursor" extension,
..."
with
  "If the AS does not support the "Cursor" extension for diff queries, ..."
or with
  "If the AS supports diff queries but not the "Cursor" extension, ..."

>From that phrase, I understand that the AS does not support both the
clauses in order for this sentence to be true, but I guess that this
applies if the AS supports the diff query mode, and not the "Cursor"
extension.

The same goes for the very next phrase:
   "In case the requester does not support both diff queries and the
"Cursor" extension, ..."
which I would replace with
   "In case the requester supports diff queries but not the "Cursor"
extension, ..."


[Section 8]

* The second paragraph refers to an AS supporting both diff queries and the
"Cursor" extension, and it says
  "The exact format of the response depends on the request being a
full query or diff query request, on the presence of the 'cursor'
query parameter in the diff query request, and on the current status of the
update collection associated with the requester."

Actually, "the presence of the 'cursor' query parameter in the diff query
request" does not influence the AS response. If the AS supports both diff
queries and the "Cursor" extension, the payload of a successful AS response
will always include a CBOR map containing the parameters 'diff', 'cursor',
and 'more', independently of the presence of 'cursor' in the diff query
request.

Also, for error responses, the presence of the 'cursor' query parameter
does not influence the format of the response produced by the AS, assuming
that the 'diff' parameter specified in the diff query request is checked
before the 'cursor' parameter, as I would deduce by reading Section 5.2.
If this assumption is not legit, then the phrase "the presence of the
'cursor' query parameter in the diff query request" should be kept,
otherwise it should be removed.


* In Section 8.1, fourth paragraph, "the 'index' value of the last series
item in the update collection associated with the requester" is exactly
'last_index'.

It might be worth specifying it to clarify.


* Again, in Section 8.2.3, case B, step 4, first inner bullet point of the
second bullet point, the "'index' value of the last series item in the
update collection." is exactly 'last_index'.

It might be worth specifying it to clarify.


[Section 10]

* I would replace the phrase
  ", if the AS does not support both diff queries and the related "Cursor"
extension ..."
with
  ", if the AS does not support the "Cursor" extension for diff queries,
..."
or with
  ", if the AS supports diff queries but not the "Cursor" extension, ..."

for the reason explained in a previous comment.


[Section 13]

* In Section 13.4, after the reading of the whole section I wonder: what if
the Access Token the Client believes to be valid was indeed revoked and
then expired?
With an AS supporting the full query mode only, there is no means for the
Client to understand whether that Access Token was revoked or not. This
might be the case of an Access Token containing the ‘exi’ claim.

Note that the same goes for an AS supporting the diff query mode, in which
the number of TRL updates —in the portion of the TRL pertaining to the
requester— after the TRL update in which that Access Token was in the
'removed' array is greater than MAX_N.

Moreover, this can happen with an Access Token t1 that has not expired, but
its token hash th1 is added to the TRL (therefore t1 was indeed revoked).
After the addition of th1, the AS adds many other tokens hashes (more than
MAX_N) of Access Tokens pertaining to the same Client. If the Client makes
a diff query request, it will not see that t1 was revoked.

Therefore, the Client cannot infer the validity of an Access Token based on
a response received from the TRL endpoint. On the contrary, if, from that
response, the Client determines that the Access Token was revoked, it can
expunge it and ask for a new one.


[Appendix C]

* I suggest adding that, in all the following examples, all the Access
Tokens issued by the AS are intended to be consumed by that RS.


[Nits]

* Section 13.4
--- s/migth/might
--- s/Autherization/Authorization

* Appendix A
--- s/MAX_N series item,/MAX_N series items,

* Appendix C
--- s/to computed/to compute
--- s/an 'max_n'/a 'max_n'

Il giorno lun 13 mar 2023 alle ore 18:37 Daniel Migault <[e-mail]>
ha scritto:

> Hi everyone,
>
> This email starts a WGLC for draft-ietf-ace-revoked-token-notification
> which ends on March 27. Please provide your support and feed backs by that
> time. We will take advantage of the IETF116 session to solve any remaining
> discussions on that draft.
>
> I am also looking for someone interested in being the document shepherd:
> Please volunteer!
>
> To the co-authors I am looking at:
> - 1) a heads-up regarding the implementations.
> - 2) a confirmation that they are or not aware of any IPR
> - 3)  a confirmation that they are willing to co-author the document.
>
> Yours,
> Logan and Daniel
>
>
> On Mon, Mar 13, 2023 at 11:36 AM <[e-mail]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the Authentication and
>> Authorization for Constrained Environments (ACE) WG of the IETF.
>>
>>    Title           : Notification of Revoked Access Tokens in the
>> Authentication and Authorization for Constrained Environments (ACE)
>> Framework
>>    Authors         : Marco Tiloca
>>                      Ludwig Seitz
>>                      Francesca Palombini
>>                      Sebastian Echeverria
>>                      Grace Lewis
>>    Filename        : draft-ietf-ace-revoked-token-notification-04.txt
>>    Pages           : 59
>>    Date            : 2023-03-13
>>
>> 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.  The method
>>    allows Clients and Resource Servers to access a Token Revocation List
>>    on the Authorization Server, with the possible additional use of
>>    resource observation for the Constrained Application Protocol (CoAP).
>>    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 IETF datatracker status page for this Internet-Draft is:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/
>>
>> There is also an HTML version available at:
>>
>> https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-04.html
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-revoked-token-notification-04
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>>
>
>
> --
> Daniel Migault
> Ericsson
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>