On Fri, May 10, 2024 at 9:12 AM Marco Tiloca <marco.til...@ri.se> 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
_______________________________________________
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org
