Hi Rikard,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-25 05:46, Rikard Höglund wrote:
Hello.Please find my review of draft-ietf-ace-revoked-token-notification-04 below.Best Rikard Höglund [Abstract]*"with the possible additional use of resource observation for the Constrained Application Protocol (CoAP)"Seems to me that CoAP is mentioned quite late here. Not only the observations, but the whole functionality of this draft is based on CoAP messages. Same comment is applicable to the introduction.
==>MTRight. With the exception of the Observe feature, other protocols that can be used in ACE can be used for this method.
We have updated the abstract can be changed as follows: OLD: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).
NEW:As specified in this document, the method allows Clients and Resource Servers to access a Token Revocation List on the Authorization Server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation.
We have updated the Section 1 "Introduction" as follows: OLD: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. In particular, registered devices can subscribe to the TRL at the AS by using resource observation [RFC7641] for the Constrained Application Protocol (CoAP) [RFC7252].
NEW:This document specifies a method for allowing registered devices to access and possibly subscribe to a Token Revocation List (TRL) on the AS, in order to obtain updated information about pertaining access tokens that were revoked prior to their expiration. As specified in this document, the registered devices use the Constrained Application Protocol (CoAP) [RFC7252] to communicate with the AS and with one another, and can subscribe to the TRL on the AS by using resource observation for CoAP [RFC7641]. Other underlying protocols than CoAP are not prohibited from being supported in the future, if they are defined to use in the ACE framework for Authentication and Authorization.
<==
[Section 1.1]*What is the difference between "TRL resource" and "TRL endpoint"? Earlier in the terminology it says that "endpoint" is used for denoting resources.
==>MTThey mean the same thing, but "TRL endpoint" seems to have been used specifically for the resources pertaining to the ACE workflow, i.e., /token and /introspect at the AS, as well as /authz-info at the RS. Based on that, this document should mostly use "TRL endpoint".
According to that, we have made the following changes throughout the document. As a result, "TRL resource" is not used anymore.
* When referring to the content of what was mentioned as "TRL resource", it is sufficient to say "TRL". For example, the new text says: "query of the TRL", "subscribe to the TRL", "update the TRL".
* When referring to the "TRL resource" as something accessible through a request, "TRL endpoint" is used instead. For example, the new text says: "observe the TRL endpoint", "caller of the TRL endpoint", "request to the TRL endpoint".
* In Section 1.1 "Terminology" * Removed the definition of "TRL resource" altogether.* The definition of TRL endpoint is updated to say "an endpoint on the AS with a TRL as its representation."
<==
*"A registered device acts as a caller of the TRL endpoint."Perhaps it can be rephrased or another word than "caller" used? I don't see caller used in RFC9200, RFC7252, or RFC6749. Practically the registered device will perform a request to the TRL endpoint right?
==>MTThe use of "caller" was suggested by Travis Spencer in a very early review, to not distinguish between Clients, Resource Servers and Administrators when any of those sends a request to the TRL endpoint.
https://mailarchive.ietf.org/arch/msg/ace/1UK5QuLh4kmzlH211JBtotdchfQ/ We have changed the text as follows:* "caller of the TRL endpoint" has become "requester towards the TRL endpoint" (multiple instances)
* In Section 5: OLDFurthermore, responses from the AS to the caller MUST be bound to the caller's request.
NEWFurthermore, responses from the AS to the requester MUST be bound to the corresponding requests.
<==
[Section 2] *Regarding the following 3 sentences:"the registered device can send an Observation Request to the TRL resource""the registered device can send a GET request to the TRL endpoint" "An administrator can access and subscribe to the TRL like"First "resource" is used, then "endpoint" is used, and in the last instance neither is used. Best to stick to one choice. This is a comment applicable to the document overall.
==>MT This was addressed by addressing the related comment above. <==
*"provides the current updated list of revoked Access Tokens in the portion of the TRL pertaining to that device"Why not instead?"provides the current updated list of revoked Access Tokens from the TRL pertaining to that device" "Pertaining Access Token" was already defined in the terminology. I'm not sure also the concept of "portions" of the TRL are needed.The concept of "portion of the TRL" comes back multiple times in the document, but is it really needed?
==>MTYes, the TRL is only one. That proposed change would (at least) suggest that there is one TRL per caller, and that the right one is selected. That was the case at the very beginning, until the first review from Travis Spencer, after which we converged to exactly one TRL at the AS.
Instead, depending on who the requester is, the AS selects the portion of the TRL pertaining to that requester. By definition, this portion includes the token hashes of the Access Tokens pertaining to the requester.
To avoid any misunderstanding, we have replaced "portion of the TRL" with "subset of the TRL" throughout the document.
<==
[Section 3]*Is it neccessary to have both parameters ENCODED_TOKEN and HASH_INPUT. Can't the value of HASH_INPUT be defined directly?
==>MTWhen JSON is used, they are two different things, and ENCODED_TOKEN allowed to avoid a lot of repetitions.
We have revised the text and used the new formulation below. This does not use ENCODED_TOKEN, and presents the two cases based on either CBOR and JSON.
"The token hash of an Access Token is computed as follows.1. The AS considers the content of the 'access_token' parameter in the AS-to-Client response (see Section 5.8.2 of [RFC9200]), where the Access Token was included and provided to the requesting Client.
2. The AS defines HASH_INPUT as follows.* If the content of the 'access_token' parameter from step 1 is a CBOR byte string, then HASH_INPUT takes the binary serialization of that CBOR byte string. This is the case where CBOR was used to transport the Access Token (as a CWT or JWT).
With reference to the example in Figure 2, and assuming the string's length in bytes to be 119 (i.e., 0x77 in hexadecimal), then HASH_INPUT takes the bytes {0x58 0x77 0xd0 0x83 0x44 0xa1 ...}, i.e., the raw content of the 'access_token' parameter.
* If the content of the 'access_token' parameter from step 1 is a text string, then HASH_INPUT takes the binary serialization of that text string. This is the case where JSON was used to transport the Access Token (as a CWT or JWT).
With reference to the example in Figure 3, HASH_INPUT is the binary serialization of "2YotnFZFEjr1zCsicMWpAA", i.e., of the raw content of the 'access_token' parameter. In either case, HASH_INPUT results in the binary representation of the raw content of the 'access_token' parameter from the AS- to-Client response.
3. The AS generates a hash value of HASH_INPUT as per ... " <==
[Section 4]*"The order of the token hashes in the CBOR array is irrelevant, and the CBOR array MUST be treated as a set in which the order of elements has no significant meaning."It seems this sentence is saying the same thing twice. This kind of construction occurs multiple times in the document.
==>MT We have revised the sentence to simply say:"The CBOR array MUST be treated as a set, i.e., the order of its elements has no meaning."
In the same way, we have revised two similar sentences in Section 6 and Section 7.
<==
[Section 5] s/two types of query of the TRL/two types of queries of the TRL
==>MT Fixed as suggested. Both forms are correct, but the latter is more used in American English. https://english.stackexchange.com/questions/257027/two-types-of-user-or-two-types-of-users#257084 <==
[Section 5.1.1] *"where "**" is the exponentiation operator" Any reason not to use the ^ notation instead?
==>MT Fixed; now using "^" instead. <==
[Section 6]*"does not support the "Cursor" extension (if it supports diff queries at all)"Suggested rephrasing: "does not support the "Cursor" extension nor diff queries"
==>MT We rephrased according to the most straightforward order, i.e.: "does not support diff queries nor the "Cursor" extension" <==
[Section 7]*In this section I miss a mention of "trl_patch". Should it not be used here, as it is defined in CDDL in Figure 6 and described in Section 5.1? Alternatively remove the mention of "trl_patch", and just describe it as a CBOR array of token_hash values.
==>MT In Section 7, we have rephrased the text within Step 3 as follows. OLD: The first element is a CBOR array 'removed'. NEW:The first element is a 'trl_patch' set of token hashes, encoded as a CBOR array 'removed'.
OLD: The second element is a CBOR array ’added’. NEW:The second element is a 'trl_patch' set of token hashes, encoded as a CBOR array 'added'.
<==
*Section 5.1 says the following:"The series items in the update collection MUST be strictly ordered in a chronological fashion."Then in Section 7 it says:"Within 'diff_set_value', the CBOR arrays 'diff_entry' MUST be sorted to reflect the corresponding updates to the TRL in reverse chronological order."Why mandate to store in one order, and send in another?
==>MT The updates are numbered by a growing integer index.Without considering the index wrap-around for simplicity, this storing strategy at the AS ensures that a higher index corresponds to a more recent update.
The sending order is intentionally reversed. When parsing 'diff_set_value', the registered device is able to see the most recent updates first.
No action taken on this point. <==
[Section 8.2.1] s/regardless whether/regardless of whether
==>MT Fixed (2 instances in the whole document). <==
[Section 8.2.2]If the request does not include the 'cursor' query parameter, why does the AS still use it in the response? What if the requester doesn't support and/or doesn't want to use it at all? Cannot the decision to use the 'cursor' be an explicit indication by the requester, like having to include 'cursor' with value 0 in the request, or similar?The requester may know MAX_N and expect behaviour according to that. Even if it got MAX_DIFF_BATCH during the registration procedure, it may not understand that parameter if it doesn't support the 'cursor' extension.
==>MTThe current design is intentional and aligned with the outcome of meeting+hallway discussions from the IETF 113 meeting in Vienna, in March 2022.
The idea was to:* Have all the response messages using a CBOR map as payload, with a format that depends on the capabilities of the AS, but not on those of the specific requester to which the AS is replying to.
* Have the actual outcome of an exchange to seamlessly be as comprehensive as possible, based on the features that both the AS and the requester support.
No action taken on this comment. Below some detailed answers, one point at the time.
> If the request does not include the 'cursor' query parameter, why does the AS still use it in the response?
Because the requester may use it for later requests, provided that it supports the "Cursor" extension.
> What if the requester doesn't support and/or doesn't want to use it at all?
Then the requester would silently ignore that parameter and make no use of it. This also spares the AS to learn about requesters' capabilities (e.g., at registration time) and have a different payload format for the response to different requesters.
> Cannot the decision to use the 'cursor' be an explicit indication by the requester, like having to include 'cursor' with value 0 in the request, or similar?
Consistent with the above and in the interest of simplicity, the AS always internally uses the "Cursor" extension and includes a value as 'cursor' in a response, irrespective of the support from the specific requester (that, in the worst case, will ignore the parameter).
However, the response from the AS might include diff entries different from the most recent ones only if the requester requests so by explicitly including 'cursor' as a query parameter in the request.
Note that the query parameter 'cursor' with value 0 means a specific thing, i.e., requesting the pertaining TRL updates starting from index = 1.
> The requester may know MAX_N and expect behaviour according to that. Even if it got MAX_DIFF_BATCH during the registration procedure, it may not understand that parameter if it doesn't support the 'cursor' extension.
Correct. Even if MAX_N entries are currently stored at the AS, the requester should not expect to receive MAX_N entries from the AS, following a diff query request.
The case considered here is limited to when all the following conditions hold:
* The AS supports diff query and the 'Cursor' extension. * The requester supports diff query but not the 'Cursor' extension.* The requester sends a diff query request, which is processed as per Section 8.2.2.
* When the AS processes the request, U > MAX_DIFF_BATCH. Note the definition of 'diff' in Section 5.2> 'diff': if included, it indicates to perform a diff query of the TRL (see Section 7). Its value MUST be either:
>> * the integer 0, indicating that a (notification) response should include as many diff entries as the AS can provide in the response; or > * a positive integer strictly greater than 0, indicating the maximum number of diff entries that a (notification) response should include.
The idea is that the AS will do "its best" (taking into account its own possible use of MAX_DIFF_BATCH), while not exceeding the amount of updates indicated by the requester in the 'diff' query parameter.
<==
[Section 10.1] *"A response from the TRL endpoint indicating that t1 has expired."Could be good to clarify this sentence to say that this indication is about th1 having been removed from the TRL.
==>MT We have revised and extended that sentence as follows."A response from the TRL endpoint indicating that t1 has expired after its earlier revocation, i.e., the token hash th1 has been removed from the TRL. This can be indicated, for instance, in a response from the TRL endpoint following a diff query of the TRL (see Section 7)."
<==
*"If expunging or not accepting t2 yields the deletion of th2 as per the two conditions specified above"Suggested rephrasing:"If receiving t2 yields the deletion of th2 as per the two conditions specified above" It is the "receiving and seeing" that is criteria 1. "Expunging" or "not accepting" is not part of critera 1 or 2.
==>MTActually, "as per the two conditions specified above" can be just removed. What has to result in associating sn2 and th2 is the scheduled deletion/block of t2, irrespective of the reason why this happens.
Note that, if a Token is expunged or not accepted (for whatever reason), it has also been "seen".
Considering the above, we have simplified the sentence as follows. OLD:If expunging or not accepting t2 yields the deletion of th2 as per the two conditions specified above, then the RS MUST associate sn2 with th2 before continuing with the deletion of th2.
NEW:If expunging or not accepting t2 yields the deletion of th2, then the RS MUST associate sn2 with th2 before continuing with the deletion of th2.
<==
*"iii) has the sequence number encoded in the 'cti' claim not greater than the highest sequence number among the expired Access Tokens specifying the 'exi' claim"Should this say "is greater" rather than "not greater"? If for instance the sequence number is lower, then should not the procedure in 5.10.3 of RFC9200 make such an Access Token be rejected in the first place?
==>MT Of course, the trap of double negation...Simply fixed by replacing "claim not greater than" with "claim greater than".
<==
[Section 13.4] s/Client migth/Client might s/the Autherization Server/the Authorization Server
==>MT Fixed. <==
[Appendix B]The table states that MAX_DIFF_BATCH is not a single instance parameter, and in Section 9 it states that a registered device may receive MAX_DIFF_BATCH from the AS during registration. Why is MAX_DIFF_BATCH not a single instance parameter, but MAX_N is? Or rather, why are they not both single instance, or not single instance?
==>MTBecause MAX_N has an impact only on the storage of the AS, hence it can be just the same value for each requester.
Having a different MAX_DIFF_BATCH per registered devices allows the AS to personalize the size of TRL chunks transferred to different registered devices, for example taking into account the quality of the link between the two.
No action taken on this point. Thanks a lot again! <==
------------------------------------------------------------------------*From:* Ace <ace-boun...@ietf.org> on behalf of Daniel Migault <mglt.i...@gmail.com>*Sent:* Monday, March 13, 2023 18:36 *To:* Ace Wg <ace@ietf.org> *Subject:* [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt 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%7Cf8c81558768b40f3554408db2cebeab2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638153164014460792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jMU%2BtaPT5%2BFT3vtJcU0wO32RsneniETDUgWA%2Blh5VlM%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%7Cf8c81558768b40f3554408db2cebeab2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638153164014460792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yfcYJK9gempnIEQK%2FYzhT6lcLRymV5fL3Zk5dXucG9Y%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%7Cf8c81558768b40f3554408db2cebeab2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638153164014460792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wt4WD9JnJTlP6M%2BRVozLEqx6kQ8fWndTSHylffzygrA%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%7Cf8c81558768b40f3554408db2cebeab2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638153164014460792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b%2Fmg3NQulAgMXXdt1HHJbmpQv7TVA0NqoyZgVkwgJD4%3D&reserved=0> -- Daniel Migault Ericsson _______________________________________________ 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
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
