Hello Roman,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].Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -09 of the document.
Thanks, /Marco [PR] https://github.com/ace-wg/ace-revoked-token-notification/pull/18 On 2024-07-10 20:58, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for draft-ietf-ace-revoked-token-notification-08: No Objection 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%7Cb05a8e3b96174bb05c1108dca1125b85%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638562347417644288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GKlAk15Tlp0Ow5my%2Fe2HSNE9KeloTZPeJw9jCtuN%2F3o%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%7Cb05a8e3b96174bb05c1108dca1125b85%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638562347417652268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f8%2FWr9SafB3Bg9RODfVC3u0SrAtt8C8%2BJ5waDr8wTbk%3D&reserved=0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Dale Worley for the GENART review. ** Section 3.4 The specifically used hash function MUST be collision-resistant on byte-strings, and MUST be selected from the "Named Information Hash Algorithm" Registry [Named.Information.Hash.Algorithm]. Is there isn’t any mandatory to implement algorithm, how is interoperability expected?
==>MTAs earlier stated in Section 3.4, the computation of the token hash uses the method defined in Section 6 of RFC 6920. That specification indicates sha-256 as mandatory to implement.
That was consistently intended to be the case in this document but we have been admittedly a bit too terse about it.
This is addressed by extending the quoted paragraph in Section 3.4 as follows.
OLD:> The specifically used hash function ... Registry [Named.Information.Hash.Algorithm].
NEW:> The specifically used hash function ... Registry [Named.Information.Hash.Algorithm]. Consistent with the compliance requirements in Section 2 of [RFC6920], the hash function sha-256 as specified in [SHA-256] is mandatory to implement.
Where [SHA-256] is:NIST, "Secure Hash Standard", FIPS 180-3, October 2008, http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf
<==
** Section 6. I’m having trouble understanding who the “full TRL” download is
for.
-- Section 13.1 says “The AS MUST ensure that ... only authorized and
authenticated administrators can retrieve the full TRL (see Section 9).”
-- Section 13.2 cautions:
If many non-expired access tokens associated with a registered device
are revoked, the pertaining subset of the TRL could grow to a size
bigger than what the registered device is prepared to handle upon
reception of a response from the TRL endpoint, especially if relying
on a full query of the TRL (see Section 6).
It is there an assumption that administrators are operating on constrained
devices to create issues with downloading the full TRL?
==>MTApologies for the confusion, clearly coming from the terms "full query" and "full TRL".
* "full TRL" is intended to mean (and should better be) "content of the whole TRL", which is already and more appropriately used in Section 2.
* A "full query" is a way of accessing the TRL. While it is fully specified in Section 6, its short definition in Section 5 says:
> ... the AS returns the token hashes of the revoked access tokens currently in the TRL and pertaining to the requester.
What is returned by the AS is generally NOT the content of whole TRL, i.e., it is generally not the "full TRL".
What is returned by the AS is guaranteed to be the content of the whole TRL only when the requester is specifically an administrator, since all the issued access tokens pertain to an administrator (see the definition of "pertaining access token" in Section 1.1).
Considering that "full TRL" is used only two times in the whole document, i.e., one in Section 9 and one in Section 13.1, this has been simply fixed by making the following changes, which also make the text of Sections 9 and 13.1 more consistent.
OLD (Section 9):> ... whether the requester is authorized to take such a role, i.e., to access the full TRL.
NEW (Section 9):> ... whether the requester is authorized to take such a role, i.e., to access the content of the whole TRL.
OLD (Section 13.1):> ... only authorized and authenticated administrators can retrieve the full TRL (see Section 9).
NEW (Section 13.1):> ... only authorized and authenticated administrators can access the content of the whole TRL (see Section 9).
<==
** Section 13.3
In order to avoid this, a requester SHOULD NOT rely solely on the
CoAP Observe notifications. In particular, a requester SHOULD also
regularly poll the AS for the most current information about revoked
access tokens, by sending GET requests to the TRL endpoint according
to a related application policy.
Are the requestors going to be constrained devices? If so, both of these
approaches seem problematic for device will limited battery power – either the
device needs to stay awake to watch Observe notifications or it needs to poll.
** Section 13.5
In order to minimize such a risk, if an RS relies solely on polling
through individual requests to the TRL endpoint to learn of revoked
access tokens, the RS SHOULD implement an adequate trade-off between
the polling frequency and the maximum length of the vulnerable time
window.
As above. Would an RS ever be constrained because polling would impact the
battery life.
==>MT This answer refers to both the two comments above.With reference to ACE clients and resource servers, they can certainly be resource-constrained devices, even though not necessarily in terms of availability and energy budget.
Besides the method specified in this document, clients might already use polling and/or observe, in particular for accessing protected resources at resource servers.
Furthermore, especially in dynamic setups, a resource server is likely online fairly regularly, since it might generally receive an uploaded access token at any time, as a first required step that enables a client to access protected resources at that resource server.
More specifically about the method specified in this document:* Regarding the use of observe, a device deliberately registers itself as an interested observer, which presumes its relatively high availability to listening to potential notifications that it might receive from then on.
Certainly, if a device operates only during sporadic and short time windows in the interest of (aggressive) energy saving, then that device has a high chance to miss notifications. However, just like for obtaining the content of any other remote resource other than the TRL, such a device should then appropriately and more regularly poll the TRL, e.g., right after waking up from a sleep state.
* Regarding the use of polling, it surely has an impact on battery life, so the frequency and pattern adopted for its use have to take into account availability and energy-saving patterns of the device in question as appropriate.
At the same time, devices that are often offline do not need to wake up explicitly in order to poll. After all, no illegitimate accesses are possible on a resource server that is offline. As soon as the resource server wakes up as already planned and intended, it can also do a polling of the TRL as a first thing.
Furthermore, the quoted text is already prescribing devices to perform a regular polling, which devices are certainly able to do once back online. Certainly, doing a regular polling of the TRL helps not only in case of notifications suppressed by an active adversary, but also in case of notifications that are missed due to the device being offline.
The mentioned "application policy" that determines how and when a regular polling is performed is also intended to take into account aspects like availability and energy-saving patterns of the device in question.
In order to cover also these aspects, the second paragraph of Section 13.3 is updated as follows.
OLD:> In order to avoid this, ... regularly poll the AS for the most current information about revoked access tokens, by sending GET requests to the TRL endpoint according to a related application policy.
NEW:> In order to avoid this, ... regularly poll the AS for the most current information about revoked access tokens, by sending GET requests to the TRL endpoint. Specific strategies and schedules for polling the AS are to be defined by a related application policy, by also taking into account the expected operational and availability patterns adopted by the requester (e.g., in the interest of energy saving and other optimizations).
<==
-- 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.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
