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