[Ace] Re: Iotdir telechat review of draft-ietf-ace-revoked-token-notification-08

[Marco Tiloca <[e-mail]>]

Hello Niklas,

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: [phone]

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

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se