On Fri, May 10, 2024 at 9:12 AM Marco Tiloca <marco.tiloca@xxxxx> wrote:
* 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.
I guess I would say that unless you can articulate a specific privacy implication, stating that there "may result" some privacy concern is more CYA than actually informational to readers or implementors. When this is done broadly, it winds up sounding a bit like the CA prop 65 warnings on literally everything in the sense that it provides no useful guidance on how to evaluate alternatives against each other. So I agree with removing this *unless* you can articulate a specific privacy concern.
* 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.
It seems like the right way to terminate the ability of a compromised RS to communicate is to revoke its server certificate so all clients will fail (D)TLS handshakes, tokens aside. From a security engineering perspective, this is really the proper solution: revoke the credential that authenticates the server. (The access tokens, by contrast, are really credentials that authenticate and authorize the client.)
But if you decide instead to move ahead with revoking tokens as a proxy for deauthenticating the server, perhaps the guidance should be to leave the suspected compromised party wondering and only proactively notify the other parties to the token. That implies maybe having two classes of TRL: one for clients and one for RSes, and to issue the revocation to one or the other depending on the situation.
All of this is lipstick on a pig, however, as the unavoidable problem with revocation is the polling period of the list. There's a certain degree of "best effort" involved in using revocation of offline credentials to prevent interactions after learning of a compromise. Maybe that's what really should appear under security considerations: a statement of the inherent limitations of revocation lists and how that should be taken into consideration when designing systems that leverage these tokens for authentication and authorization.
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.**
How can an on-path active adversary inject forged messages into communication between two endpoints? I admit to having very little knowledge of ACE: is the communication not end-to-end integrity protected with server authentication, a la DTLS? (If that's not the case, then frankly all bets are off.)
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.
Aha, so "exi" is the source of the problem. If that weren't permitted by spec, and explicit deterministic timestamps were required for expiration, you would eliminate this entire class of problem. I suggest doing an RFC 9200bis to remove things like this, and maybe get the entire ecosystem reviewed by security experts to avoid basic but preventable architecture flaws that unnecessarily complicate the security story.
<==
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.
I'm using the term "database" abstractly. In the simple case, this represents what every node in the network would see if they were synchronously accessing the same single copy of the data, which is by definition always consistent with itself.
By contrast, in the case described in this document, the database (the TRL of unexpired tokens) is distributed into instances (the RSes) with updates flowing to it at different times (via TRL polling), which means you'd ideally like some kind of consistency model (e.g., sequential consistency, serializability, etc.) to allow you to reason about what two nodes acting independently might see when querying their local instances at a particular time.
This is one of the foundational problems in distributed systems. There's no reason to reinvent the wheel here. My recommendation is that if there is a model that does what you want in the distributed systems literature, you should just implement that. But deriving benefit from using a standard database consistency model might also depend on eliminating things like the aforementioned relative expiry "exi", which complicates not the database update but a node's behavior at the moment a token is received.
Kyle
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
