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/16
On 2024-07-04 16:35, Niklas Widell via
Datatracker wrote:
Reviewer: Niklas Widell Review result: Ready with Nits IoT directorate review of Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework Reviewer: Niklas Widell Review result: Ready with Nits I have reviewed draft-ietf-ace-revoked-token-notification-08 from IoT point of view, as part of IoT directorate document reviews. The document is well-written, complete, and appears to be Ready (with non-blocking comments/reflections & Nits below). The document defines a mechanism for an Authorization server (AS) in the ACE framework to notify Clients and Resource Servers (RS) when access tokens are revoked. This can be useful in IoT environments as depending on token expiration is not always practical. The mechanism is designed for, but not limited to, IoT, and I did not find any directly IoT related issues in the document. ----- Comments: - General: The token revocation mechanism complements token expiration as a way to handle access. Are there any thoughts on system operator assumptions on how to balance short token expiration times vs. revocation with notification as ways to maintain the population of active access tokens?
==>MT
Building on the last paragraph of Section 6.1 of RFC 9200, most ACE RSs are expected to be constrained, intermittently connected devices.
With that in mind, a system operator in charge of the AS should actually issue access tokens with a relatively long lifetime. Of course, the specific lifetime has to be consistent with application- and system-specific requirements and with the wishes of the Resource Owner owning the RS that has to consume the issued access token in question.
Essentially, the expiration time of an access token is determined upon issuing the access token, by scheduling its retirement as deemed appropriate in the light of the specific RS and of the application and system requirements.
On the contrary, the revocation of an access token is not something expected to schedule in advance. If that was possible, scheduling the expiration to occur earlier in time is the right thing to do. Instead, a revocation is something triggered by an event that requires retiring the access token earlier than originally expected per its expiration time. Examples of such (typically unpredictable) events are listed in the second paragraph of Section 1.
That is, the current "population of active access tokens" should include all the issued tokens such that: i) they have not reached the end of their planned lifetime as per the originally intended expiration time; and ii) there has been no reason for triggering their revocation.
Yet, there is one aspect related to balancing, which is discussed in the security considerations of Section 13.2 "Size of the TRL". While, as discussed above, the lifetime of access tokens in ACE is expected to be relatively long, the AS should still avoid excessively long lifetimes in order to limit the amount of revocation information to be possibly provided, especially to devices for which several access tokens are simultaneously active.
<==
- (1.1 Administrator) The document specifies an Administrator role who's only (as far as I can tell) function is to retrieve the Token Revocation List (TRL) from the AS. Is the intent to specify other admin functions elsewhere? Furthermore, it is not clear what the value of the Administrator role is: the TRL is a list of token hashes, each of which an hash identifier derived from an actual access token. From this, I can't tell if the administrator can derive much useful information from those hashes themselves, like does client X have an access token for RS Y etc.
==>MT
On the first part of the comment, this document is not introducing further admin functions. However, the very same administrator entity might in general be entitled and authorized to perform other operations at the AS, e.g., registering/unregistering Clients and RSs, or installing/updating/removing access policies.
On both the first and second part of the comment, until now ACE has not defined a full-fledged admin interface to perform admin operations at the AS. Hoping that such an interface will exist one day, it was fair for the sake of completeness to define already in this document how an administrator could specifically interact with the TRL endpoint.
Regarding the value of fully accessing the TRL as an administrator, it is true that fetching the token hashes alone does not especially help the administrator infer any particular information. However, again building on a future full-fledged admin interface, we can consider the following example case.
When issuing an access token, the AS can also have dedicated means to provide an administrator with the token hash corresponding to the access token, as well as with the identifiers of the Client and RS for which the access token is issued. (Further information might be shared, depending on the target level of privacy in the system.) This can rely, e.g., on the methods exported by a full-fledged admin interface at the AS.
Later on, by querying/observing the TRL endpoint and obtaining the full TRL content, the administrator can become aware of when accesses are revoked, and specifically for which Clients and RSs. At the same time, it remains possible to not share with the administrator information such as the exact scope specified in the revoked access tokens.
Consistent with the above, we have extended the definition of administrator in Section 1.1 "Terminology" as follows, by adding a second paragraph within the same bullet point.
OLD:
> * Administrator: entity authorized to get full access to the TRL at the AS, and acting as a requester towards the TRL endpoint. An administrator is not necessarily a registered device as defined above, i.e., a Client requesting access tokens or an RS consuming access tokens.
NEW:
> * Administrator: entity authorized to get full access to the TRL at the AS, and acting as a requester towards the TRL endpoint. An administrator is not necessarily a registered device as defined above, i.e., a Client requesting access tokens or an RS consuming access tokens.
>
> An administrator might also be authorized to perform further administrative operations at the AS, e.g., through a dedicated admin interface that is out of the scope of this document. By considering the token hashes retrieved from the TRL together with other information obtained from the AS, the administrator becomes able to derive additional information, e.g., the fact that accesses have been revoked for specific registered devices.
<==
- (4.4 TRL) The TRL of the AS is a CBRO array of CBOR byte strings, each of which a token hash. At the same time, every time a non-administrator registered device accesses the AS TRL it should only see its own hashes, which of course requires the AS to keep track of registered devices so as to filter properly. Is it up to the implementation to handle that?
==>MT
As long as a registered device is in fact registered at the AS, then the AS indeed keeps track of its active registration. Of course, the **way** by which the AS keeps track of currently registered devices is implementation-specific. In this respect, this document is not adding anything to RFC 9200 as to the AS keeping track of its registered Clients and RSs.
If the AS receives a request to the TRL endpoint from a requester that is not recognized as a registered device (or an administrator), then the AS would not proceed with processing the request. This is consistent with the second paragraph of Section 13.1 "Content Retrieval from the TRL":
> The AS MUST ensure that, other than registered devices accessing their own pertaining subset of the TRL, only authorized and authenticated administrators can retrieve the full TRL (see Section 9).
In terms of what is **required** to provide a registered device only with the token hashes corresponding to its pertaining access tokens, the AS has to be able to unambiguously identify the requester. This is always possible by leveraging the mutually authenticated secure communication between the requester and the AS, just like it is the case when processing requests from Clients for issuing an access token, or requests from RSs for introspecting an access token.
This is consistent with the first paragraph of 13.1 "Content Retrieval from the TRL":
> The AS MUST ensure that each registered device can access and retrieve only its pertaining subset of the TRL. To this end, the AS can always perform the required filtering based on the authenticated identity of the registered device, i.e., a (non-public) identifier that the AS can securely relate to the registered device and the secure association that they use to communicate.
... and with the paragraph below from Section 9 "Registration at the Authorization Server"
> When communicating with one another, the registered devices and the AS have to use a secure communication association and be mutually authenticated (see Section 5 of [RFC9200]).
In the Pull Request addressing this review, we have extended Section 9 "Registration at the Authorization Server", by adding one new paragraph right before the paragraph "When communicating with one another, the ...". The result is as follows:
NEW:
> Once completed the registration process, the AS maintains the registration and related information until a possible deregistration occurs, hence keeping track of active administrators and registered devices. The particular way to achieve this is implementation-specific. Such a mechanism to maintain registrations is enforced in any case at the AS, in order to ensure that requests sent by Clients to the /token endpoint (see Section 5.8 of [RFC9200]) and by RSs to the /introspect endpoint (see Section 5.9 of [RFC9200]) are processed as intended.
>
> When communicating with one another, the ...
<==
- General: Given that the notification is now the way to tell a registered device that one of its tokens is revoked - how is the device suppose to handle the actual revocation?
==>MT
This is precisely what Section 10.1 "Handling of Access Tokens and Token Hashes" explains in detail.
In order to clearly suggest it upfront, we have updated the title of Section 10.1 to be more specific, i.e., "Handling of Revoked Access Tokens and Token Hashes".
<==
----- Nits: - 1. Introduction/first paragraph : add abbreviation (RS) to Resource Server first time it is used (3rd line), remove from later usage in same paragraph.
==>MT
We have fixed the text as below.
OLD
> Authentication and Authorization for Constrained Environments (ACE) [RFC9200] is a framework that enforces access control on IoT devices acting as Resource Servers. In order to use ACE, both Clients and Resource Servers have to register with an Authorization Server (AS) and become a registered device. Once registered, a Client can send a request to the AS, to obtain an access token for a Resource Server (RS).
NEW
> Authentication and Authorization for Constrained Environments (ACE) [RFC9200] is a framework that enforces access control on IoT devices acting as Resource Servers (RSs). In order to use ACE, both Clients and RSs have to register with an Authorization Server (AS) and become a registered device. Once registered, a Client can send a request to the AS, to obtain an access token for an RS.
<==
- 2. Protocol overview/first paragraph: s/ about pertaining revoked access tokens/ about revoked access tokens/
==>MT
We prefer to keep the current phrasing. Quoting the full sentence as-is:
> This protocol defines how a CoAP-based Authorization Server informs Clients and Resource Servers, i.e., registered devices, about pertaining revoked access tokens.
The use of "pertaining" is intentional and consistent with following paragraphs in the same section. Even though details of the protocol are defined later in the document, this sentence already highlights that a registered device can obtain from the TRL only information about access tokens pertaining to itself, consistent with the definition of "pertaining access token" in Section 1.1 "Terminology".
<==
-- 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.asc
Description: OpenPGP digital signature
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
