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

Thu, 20 Apr 2023 07:24:54 -0700 

Hi Marco,
Thanks a lot for your review! We've addressed your comments in the latest version -05. 

Please see inline for detailed replies.

Best,
/Marco

On 2023-03-23 14:21, Marco Rasori wrote:

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.


==>MT

In order to not differentiate between the two modes when discussing the 
method at a high-level, we made the following two changes in Section 1.


OLD

in order to obtain an updated list of revoked, but yet not expired, 
pertaining Access Tokens.


NEW

in order to obtain updated information about pertaining Access Tokens 
that were revoked prior to their expiration.



OLD

Instead, registered devices simply obtain an updated list of revoked, 
but yet not expired, pertaining Access Tokens,


NEW

Instead, registered devices simply obtain updated information about 
pertaining Access Tokens that were revoked prior to their expiration,

<==




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


==>MT
Yes, we've updated the sentence as follows.

OLD

or the most recent TRL updates occurred over the list of pertaining 
revoked Access Tokens (see Section 7).


NEW

or the most recent updates occurred over the list of pertaining revoked 
Access Tokens (see Section 7).

<==




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


==>MT

We have revised the text preceding Figure 1. It is now composed of two 
paragraphs, stressing that the three Access Tokens in the example are 
revoked at the same time, and that the AS adds the corresponding token 
hashes to the TRL at once.

<==




[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"



==>MT
Yes. Simply fixed as follows.

OLD
"access_token" : "2YotnFZFEjr1zCsicMWpAA ...
(remainder of the Access Token omitted for brevity) ...",

NEW
"access_token" : "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.


==>MT
Indeed. We have added the following paragraph at the end of Section 4.1.


"The AS MAY perform a single update to the TRL such that one or more 
token hashes are added or removed at once. For example, this can be the 
case if multiple access tokens are revoked or expire at the same time, 
or within an acceptably narrow time window."

<==




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


==>MT
We have combined the original two error conditions into one, as suggested.
<==




[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, ..."


==>MT
Based on your suggestions, we rephrased as follows.

OLD
If the AS does not support both diff queries and the "Cursor" extension, ...

NEW

In case the AS supports diff queries but not the "Cursor" extension, 
these parameters ...


OLD

In case the requester does not support both diff queries and the 
"Cursor" extension, ...


NEW

In case the requester supports diff queries but not the "Cursor" 
extension, it MUST ...

<==




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


==>MT

The analysis above is correct for successful responses, which always 
include the parameters 'diff', 'cursor' and 'more'.



For error responses, both the query parameters 'cursor' and 'diff' 
together play a role in determining the format of an error response. 
Upon checking whether the query parameter 'diff' is present and has a 
valid value --- yes, it happens upfront --- you have the following two 
cases.



* Case A: the query parameter 'diff' is present but has a non valid 
value, irrespective of the presence and value of the query parameter 
'cursor'.



   Then, what is defined in the first bullet point of Section 5.2 
"Query Parameters" applies. That is, the error response specifies only 
the parameters 'error' and, optionally, 'error_description'.



* Case B: the query parameter 'cursor' is present and: i) the query 
parameter 'diff' is not present (irrespective of the value of the query 
parameter 'cursor'); and/or ii) the query parameter 'cursor' has a non 
valid value. Then, as defined in Section 5.2 "Query Parameters", the 
error response specifies:


   - The parameters 'error' and, optionally, 'error_description'.

   - The parameter 'cursor', but only if the condition (ii) above holds 
and (i) does not.



Therefore, the format of error responses (hence, of responses in 
general) from the AS is determined by the presence and values of the 
query parameters 'diff' and 'cursor' together. That is, when the AS 
supports both diff queries and the "Cursor" extension, then an error 
response includes the parameter 'cursor' only if all the following 
conditions hold.


- The query parameter 'diff' is present and has a valid value.
- The query parameter 'cursor' is present and does not have a valid value.


Otherwise, the parameter 'cursor' is not present in the error response, 
irrespective of the presence and value of the query parameter 'cursor'.



That said, we have made the following update to the sentence in Section 8.

OLD

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.


NEW

The exact format of the response depends on the request being a full 
query or diff query request, on the presence of the 'diff' and 'cursor' 
query parameters and their values in the diff query request, and on the 
current status of the update collection associated with the requester.




At the same time, we have made the following clarifications about the 
error handling priorities in Section 5.2 "Query Parameters".


OLD

Otherwise, the AS MUST return a 4.00 (Bad Request) response in case the 
'diff' query parameter of the GET request specifies a value other than 0 
or than a positive integer.


NEW

Otherwise, the AS MUST return a 4.00 (Bad Request) response in case the 
'diff' query parameter of the GET request specifies a value other than 0 
or than a positive integer, irrespective of the presence of the 'cursor' 
parameter and its value (see below).


OLD
The GET request does not specify the 'diff' query parameter.

NEW

The GET request does not specify the 'diff' query parameter, 
irrespective of the value of the 'cursor' parameter.

<==





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


==>MT
Clarified by adding the sentence:


"Such a value is in fact the current value of 'last_index' for the 
update collection associated with the requester."

<==





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


==>MT
Clarified by adding the sentence:


"Such a value is in fact the current value of 'last_index' for the 
update collection."

<==




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


==>MT
We have rephrased as suggested.
<==




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


==>MT

You are right; depending on the specific sequence of event and message 
exchanges, it is possible for the Client to learn of the Access Token 
being not valid anymore from the AS, but it is not necessarily the case.



In order to set the right expectations, we have made the following 
rephrasing in the last paragraph.


OLD

Instead, the Client SHOULD send a request to the TRL resource at the AS, 
in order to assert whether the Access Token is still valid. If this is 
the case, the Client SHOULD NOT ask for a new Access Token.


NEW

Instead, the Client SHOULD send a request to the TRL endpoint at the AS. 
If the Client gains knowledge that the access token is not valid 
anymore, the Client expunges the access token and can ask for a new one. 
Otherwise, the Client can try again to upload the same access token to 
the RS, or instead to request 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.




==>MT
We have added the following sentence to the first paragraph:


"In the examples, all the Access Tokens issued by the AS are intended to 
be consumed by the considered 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'


==>MT
We have fixed all the nits above.

Thanks a lot again!
<==




Il giorno lun 13 mar 2023 alle ore 18:37 Daniel Migault 
<mglt.i...@gmail.com> 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 <internet-dra...@ietf.org> 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/
        
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-revoked-token-notification%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C6470503b3a784075b45b08db2ba19e90%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638151745390413298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MECA8%2Fon2HjjAQgWLP2bHZ4HRD%2FacMFaJPEnPm5r8BU%3D&reserved=0>

        There is also an HTML version available at:
        
https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-04.html
        
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-revoked-token-notification-04.html&data=05%7C01%7Cmarco.tiloca%40ri.se%7C6470503b3a784075b45b08db2ba19e90%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638151745390413298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aHPSUATQ4zB0LT2h3o54axhIVvCfbJBXTHQPZ1sL7nM%3D&reserved=0>

        A diff from the previous version is available at:
        
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-revoked-token-notification-04
        
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ace-revoked-token-notification-04&data=05%7C01%7Cmarco.tiloca%40ri.se%7C6470503b3a784075b45b08db2ba19e90%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638151745390413298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6a9BwG%2Bp%2BB7ffcdm29boAg8Vs65KTZTtrCM6xsKlp8E%3D&reserved=0>

        Internet-Drafts are also available by rsync at
        rsync.ietf.org::internet-drafts


        _______________________________________________
        Ace mailing list
        Ace@ietf.org
        https://www.ietf.org/mailman/listinfo/ace
        
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=05%7C01%7Cmarco.tiloca%40ri.se%7C6470503b3a784075b45b08db2ba19e90%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638151745390413298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LofEw%2FYi468TpPvhcmxu0wJY7PbowqOEg5htzw6pQcI%3D&reserved=0>




    -- 
    Daniel Migault

    Ericsson
    _______________________________________________
    Ace mailing list
    Ace@ietf.org
    https://www.ietf.org/mailman/listinfo/ace
    
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=05%7C01%7Cmarco.tiloca%40ri.se%7C6470503b3a784075b45b08db2ba19e90%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638151745390413298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LofEw%2FYi468TpPvhcmxu0wJY7PbowqOEg5htzw6pQcI%3D&reserved=0>


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


--
Marco Tiloca
Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

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

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se




Attachment:
OpenPGP_0xEE2664B40E58DA43.asc

Description: OpenPGP public key



Attachment:
OpenPGP_signature

Description: OpenPGP digital signature


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace






















					Reply via email to