[secdir] Re: Secdir last call review of draft-ietf-ace-revoked-token-notification-06

[Marco Tiloca <[e-mail]>]

Hello Kyle,

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 -07 of the document.

Thanks,
/Marco

[PR] https://github.com/ace-wg/ace-revoked-token-notification/pull/10

On 2024-04-01 18:14, Kyle Rose via Datatracker wrote:
> Reviewer: Kyle Rose
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
>   Document editors and WG chairs should treat these comments just like any other
> last call comments.
>
> This document is Almost Ready.
>
> * The security issue outlined in section 13.5 ("Dishonest clients") adequately
> justifies maintaining confidentiality of the full list of revoked hashes, or at
> least of recent additions to the list, without reference to privacy as
> mentioned in section 13.1. The privacy issues posed by hashes of tokens that
> are not widely distributed or visible to passive observers are not at all clear
> to me.

==>MT

Quoting the privacy-related sentence in Section 13.1:

 > Disclosing any information about revoked access tokens to entities 
other than the intended registered devices may result in privacy concerns.

Admittedly, it is hard to think of immediate, severe privacy 
consequences from revealing token hashes and their insertion/deletion in 
the update collection of non-pertaining parties.

We included that sentence with the intentionally open "may result", as a 
way to err on the side of caution. This is aligned with the generally 
good practice of not exposing more than necessary to more entities than 
necessary.

That said, we agree that the security issue discussed in Section 13.5 is 
much more concrete and sufficient to justify the security measures 
defined in Section 13.1.

Therefore, in the interest of simplicity and clarity, in Section 13.1 we 
have removed the quoted sentence "Disclosing any information ... may 
result in privacy concerns".

<==

>
> * Furthermore, doesn't the security issue identified in 13.5 imply that only
> RSes should be notified of revocations, and clients left to wonder until their
> requests are denied, or at least until after the RSes to which the token is
> relevant have been notified? Secrecy matters really only because we want to
> prevent bad actors with access to the token from taking advantage of it during
> the window between revocation and RSes being aware of that revocation: if you
> notify the bad actor proactively, it doesn't really matter that you kept it
> secret from other nefarious observers. (Note that changing this would require
> the changes to the recommendation from 13.4.)
>
>      For what it's worth, this is not a novel problem, and it is one that
>      plagues revocation systems in general. Moreover, all the possible
>      approaches are unsatisfying in some way, often relying on assumptions about
>      the state of mind/intent or expected behavior of the adversarial actor.

==>MT

We did not mean to imply that only RSs should be notified of revoked 
access tokens, and the intention was not to have Clients left to wonder.

In fact, an access token might be revoked because the RS is found 
compromised or suspected so. In such a case, informing of the revocation 
is first of all in the interest of the Client, in order to protect the 
Client from accessing resources at an RS that is deemed malevolent or 
not appropriate to access.

Informing registered devices about pertaining revoked access tokens is 
intended to work in a homogeneous way, without making assumptions about 
the state of mind/intent or expected behavior of the participants in the 
protocol, all of which may be honest actors that have to be promptly 
notified of the revocation.

What has probably created confusion here is the inappropriate focus on 
dishonest clients in Section 13.5. A comment in the GENART review 
[GENART-REVIEW] also noted that the dishonest client discussed in the 
original text is in fact only one particular case of a more general issue.

[GENART-REVIEW] 
https://mailarchive.ietf.org/arch/msg/ace/ETtaBMaSyoZKMD82kgG49P2cF9U/

Building on the suggestion in the GENART review, the new text in Section 
13.5 clarifies that the vulnerability window for the RS actually spans 
from when an access token is revoked until when the RS becomes aware of 
that, irrespective of whether the Client is honest or not and of its 
intentions.

The intended new text of Section 13.5 reads as follows:

 > 13.5 Vulnerable Time Window at the RS
 >
 > A Client may attempt to access a protected resource at an RS after 
the access token allowing such an access has been revoked, but before 
the RS is aware of the revocation.
 >
 > In such a case, if the RS is still storing the access token, the 
Client will be able to access the protected resource, even though it 
should not. Such an access is a security violation, even if the Client 
is not attempting to be malicious.
 >
 > In order to minimize such 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.


Regarding the recommendation in Section 13.4:

* The Client considered therein is honest, since it "stores an access 
token that it still believes to be valid". That said, the discussed 
consideration starts from the fact that the Client has its access 
denied, which is explained to be due to possible different reasons.

* Building on the previous point, the goal of the recommendation is 
about avoiding that the Client just rushes at the AS on a whim and 
triggers the issue of a new access token. This is not really necessary 
to happen in case the current access token stored by the Client is 
actually still valid. That's why, before asking the AS for a new access 
token, the Client should first consider to re-try its access to the 
protected resource at the RS and/or to re-upload the same access token 
to the RS.

To expand on this case, we have extended the second paragraph of Section 
13.4, and mentioned one more possible reason why the Client can receive 
a genuine 4.01 (Unauthorized) response from the RS, even when the access 
token stored by the Client is still valid. That is:

OLD:
 > This can be due to different reasons. For example, the access token 
has actually been revoked and the Client is not aware about that yet, 
while the RS has gained knowledge about that and has expunged the access 
token. Also, an on-path, active adversary might have injected a forged 
4.01 (Unauthorized) response.

NEW (emphasis mine):
 > This can be due to different reasons. For example, the access token 
has actually been revoked and the Client is not aware about that yet, 
while the RS has gained knowledge about that and has expunged the access 
token. **As another example, the access token is still valid, but an 
on-path active adversary might have injected a forged 4.01 
(Unauthorized) response, or the RS might have deleted the access token 
from its local storage due to its dedicated storage space being all 
consumed.**

<==

> * I do not understand the criteria specified for purging hashes of revoked
> tokens in section 10.1. In particular, why is the first criteria required? If
> an RS never sees a particular token, this implies the hash would be kept
> forever, or at least until memory pressure is encountered. Should the RS not
> also be allowed to expunge a hash if the TRL endpoint signals removal via
> expiry? At that point the token would be invalid anyway, revoked or not.

==>MT

The first criterion is also necessary, in order to counteract what is 
described later in the same section, in the paragraph starting with 
"Retaining the stored token hashes as specified above ...". The 
following explains why, also by means of an example.

Quoting the text about the two criteria:

 > An RS stores a token hash th1 corresponding to an access token t1 
until both the following conditions hold.
 >
 > * The RS has received and seen t1, irrespective of having accepted 
and stored it.
 >
 > * The RS has gained knowledge that t1 has expired. This can be 
achieved, e.g., through the following means. ...

**If the first criterion above was not taken into account**, then the 
following undesired outcome can occur. Let's assume that the RS has used 
CoAP Observe and is thus subscribed to updates at the TRL endpoint of 
the AS.

1. The AS issues an access token TOKEN with a lifetime of X seconds. 
Instead of the 'exp' claim specifying an expiration time, TOKEN includes 
the 'exi' claim with value X (see Section 5.10.3 of RFC 9200). Then, the 
AS provides C with TOKEN.

2. Either of the two happens:

    - C (dishonestly) retains TOKEN without uploading it; or

    - C attempts to upload TOKEN at the RS, but its message gets 
severely delayed in transmission.

    In either case, the RS does not receive, hence does not see, TOKEN.

3. Later at some point, TOKEN gets revoked.

    When this happens, the AS adds the corresponding token hash 
TOKEN_HASH to the TRL, and sends an Observe notification to the RS.

    As a consequence, the RS learns that TOKEN has been revoked. In 
particular, the RS stores TOKEN_HASH after retrieving it from the 
received notification.

4. Time passes, with the RS still not having received TOKEN. Eventually, 
after X seconds have passed since the issuing of TOKEN, the AS declares 
TOKEN to be expired.

    Therefore, the AS removes TOKEN_HASH from the TRL and sends a 
notification to the RS. As a consequence, the RS learns that TOKEN has 
eventually expired.

5. Since the second criterion is fulfilled and the first one is not 
taken into account, the RS deletes TOKEN_HASH.

6. C successfully uploads TOKEN at the RS. That is, C stops retaining 
TOKEN and finally uploads it at the RS, or the severely delayed message 
conveying TOKEN finally reaches the RS. In either case:

    - The RS does not consider TOKEN to be revoked, because it is not 
storing the corresponding TOKEN_HASH; and

    - The RS does not consider the TOKEN as expired either, since it 
determines the expiration time to be its current local time plus X 
seconds, per the value indicated in the 'exi' claim of TOKEN.

    Therefore, the RS accepts and stores TOKEN even though that has been 
revoked and later expired.


If, as in the original text, the first criterion is also taken into 
account as we intend, then at step 5 the RS does **not** delete 
TOKEN_HASH, since it has not seen TOKEN yet.

Then, in case TOKEN is uploaded at the RS after that, the RS still 
stores TOKEN_HASH, and hence does not accept TOKEN. Furthermore, as 
defined in the second from last and third from last paragraphs of 
Section 10.1, the following occurs:

* The RS retrieves from the 'cti' claim of TOKEN the sequence number SN 
encoded therein, and pairs SN with TOKEN_HASH. Then the RS discards TOKEN.

* The RS can delete TOKEN_HASH. Before doing so, since SN is associated 
with TOKEN_HASH, the RS checks whether SN is greater than the highest 
sequence number SN* among any of the previously received and expired 
access tokens that included the 'exi' claim (see Section 5.10.3 of RFC 
9200). If that is the case, then RS sets SN as the new value of SN*.

* Finally, RS can safely delete TOKEN_HASH. If the RS receives TOKEN in 
the future, there will be no stored TOKEN_HASH that the RS can rely on 
for rejecting TOKEN. However, the RS will still be able to reject TOKEN 
by leveraging the stored sequence number SN*.

<==

> Other comments:
>
> * I did not review the properties of, or analyze the correctness of, the
> database consistency algorithm and associated update protocol used to keep
> registered devices up-to-date with relevant token hashes. I do not know if this
> algorithm and protocol were based on something specific, so if that is not the
> case then my main observation would be that the consistency requirements here
> are not unique to the proposed revocation function, so it may be worth
> reviewing literature relevant to the problem space associated with database
> view consistency across distributed and intermittently-connected devices to see
> if there is something more generic that can be leveraged in solving this
> problem.

==>MT

We separately reply about the two different aspects raised in the comment.

**Database consistency algorithm** - This is an important component of 
an AS that relies specifically on a database.

The AS is supposed to rely on a database for the storage and maintenance 
of, among other things: i) credentials or secrets of registered devices; 
ii) access policies for Clients at RSs; iii) issued and still valid 
access tokens, if supporting token introspection (see Section 5.9 of RFC 
9200).

In a similar fashion, the AS can rely on its database for concretely 
representing its TRL and the associated update collections. Indeed, 
consistency requirements are not unique to the proposed method for 
notifying about revoked access tokens. However, we believe that this 
aspect is implementation-specific and out of the scope of this 
specification.

More generally, database consistency can be enforced by the same means 
that the AS already uses to ensure the reliability of its database for 
other, more traditional reasons listed above.

Looking at other related documents:

* Neither RFC 9200 (ACE) nor RFC 6749 (OAuth 2.0, which ACE builds on 
and inherits security considerations from) provide considerations on the 
particular topic of view consistency.

* RFC 6819 provides security considerations related to the AS' database 
in OAuth 2.0, but in terms of countermeasures to address possible 
attacks against the AS, without covering the particular topic of view 
consistency.

* RFC 7662 defines token introspection for OAuth 2.0. In its Section 4, 
its security considerations (also inherited by ACE when supporting token 
introspection) outline that an AS providing token introspection has to 
be able to understand tokens for which introspection is requested (e.g., 
by storing token-related information in a database), but that the exact 
means to achieve that is implementation specific and out of scope.

Please note that the database in question is limited to the AS, and does 
not involve registered devices. That is, from a logical point-of-view, 
the AS is the centralized source of truth about the token hashes, just 
like it is for the status of issued access tokens if it provides token 
introspection.

If the AS' database is specifically implemented in a distributed fashion 
and/or relying on different replica to be kept in sync, that feels even 
more out of the scope of ACE and of this specification.


**Update protocol used to keep registered devices up-to-date** - This 
document defines the new TRL endpoint at the AS. Per RFC 9200, 
communications between C/RS and AS are expected to use CoAP 
(recommended) or alternatively HTTP.

In either case, the update protocol used to keep registered devices 
up-to-date boils down to the exchange of CoAP/HTTP messages with the AS, 
in order to perform RESTful accesses to the TRL at the AS. That is, when 
receiving a GET request to the TRL endpoint, the AS returns a response 
that conveys the current representation of (the pertaining portion of) 
the TRL to the requester.

In turn, the representation of the TRL at the AS is updated by the AS as 
defined in Section 4.1, based on only two possible triggering events: i) 
a non-expired access token is revoked; or ii) a revoked access token 
expires.

When specifically using CoAP and its extension Observe (RFC 7641), the 
AS also sends automatic Observe notification responses to the registered 
devices that have been observing the TRL endpoint (see Section 4.2 of 
RFC 7641), upon changes to (the pertaining portion of) the TRL. In 
particular, each Observe notification specifies the current 
representation of (the pertaining portion of) the TRL, like if replying 
to a just received GET request.

Furthermore, CoAP Observe specifically relies on the "eventual 
consistency" model (see Section 1.3 of RFC 7641). That is, quoting the 
abstract of RFC 7641 (with "(CoAP)" being my addition), CoAP Observe follows

 > a best-effort approach for sending new representations to (CoAP) 
clients and provides eventual consistency between the state observed by 
each (CoAP) client and the actual resource state at the (CoAP) server.

Note that Section 13.3 "Communication Patterns" of this document 
recommends that registered devices do not solely rely on Observe 
notifications from the TRL endpoint, but instead complement it with 
regular polling requests according to application policies.

<==

> * I also did not review any of the appendices.
>
>
>

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