Hi Daniel,
OK. The good news is that the BCP document will now address this issue.
Let us wait to see which text you will propose.
Yesterday, I wrote: "Since OAuth 2.0 does not mandate the use of
cryptographic devices, this kind of attack cannot be countered in the
general case".
James Manger replied: "Even crypto devices aren’t a full solution. Alice
can share her authorization with Bob & Chris by signing-in with their
crypto devices".
James is right. I should have use the term "secure element". When using
secure elements /with specific properties/, it is possible to counter
the Alice & Bob Collusion attack.
A conversation took place on the OAuth mailing list on February 6, 2017.
The following statements were made:
"Sharing bearer tokens is a well known attack surface and there's
really no way to stop that.
Even PoP-style tokens can be shared since nothing stops Bob and
Alice from sharing their secrets with each other".
The same email also states:
"There's literally nothing in the world that can prevent that level
of collusion -- PoP, token binding, DRM... nothing".
So at this time, it seemed that one belief was "nothing can be done
anyway". However, at least two solutions, using secure elements /with
different specific properties/, exist.
At the OAuth workshop in in Zürich in 2017, I presented a paper
explaining how this could be done. It is still available at:
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf
For this workshop, I also proposed another paper (4 pages) with the
following abstract, but only the first paper had been accepted:
OAuth 2.0 was originally intended to be used for delegation but can
also be used for access
control. OAuth 2.0 is currently unable to defeat collusion attacks
between clients, even if a secure element
is being used to protect the corresponding private key or shared
secret that is bound to the access token.
This does not mean that OAuth 2.0 cannot be used any more, but that
its applicability, in the field of access
control, will be reduced to Identity-based Access Control (IBAC)
which means that access tokens must
contain a set of attributes that allows to unambiguously identify
the token holder, otherwise a specific kind of
attack, named the "Alice and Bob Collusion attack" is possible.
I will create a new thread to discuss the end of my email from yesterday
(/which has been deleted in this thread ... as well as the original
message/):
*Comment on section 4: "Validating JWT Access Tokens"
*
The JWT profile for OAuth 2.0 access tokens
[draft-ietf-oauth-access-token-jwt] mandates to include a "sub"
claim into an access token.
However, this section does not mandate the RS to verify that claims
allowing for the RS to uniquely identify the holder of the access token
are indeed be present inside an access token.
It might be useful to add it, so that the above text can refer to it.
Denis
Thanks Neil, this very much sums up my thoughts on this topic.
Since this has been mentioned in yesterday's call, I'll be happy to
clarify in the attacker model that web attackers can collaborate to
reach a common goal. I think we can also mention that
sender-constraining does not prevent collaborating entities to share
their tokens with each other.
-Daniel
Am 27.10.20 um 07:26 schrieb Neil Madden:
It sounds like we’re trying to redefine cooperation/delegation as an
“attack”. People delegate and you can’t generally prevent it without
incarceration. Anything Bob could do with Alice’s access token he
could also do by asking Alice to do it on his behalf. In other words,
any credential/token sharing can be replaced by proxying: If Alice
wants to help underage Bob buy liquor she doesn’t have to share her
access token, she can just buy it herself and give it to him.
If the RS cares about accountability then the token (or some other
means) should identify the user - perhaps pseudonymously like OIDC
pairwise identifiers - and this should be logged for audit. But this
can only discourage, not prevent, delegation. OAuth is after all a
delegation protocol.
(In the post-shame world we now live in, the idea that you can
enforce norms through identification seems almost quaint, but I’m not
sure I’m ready to be that cynical).
If the RS allows anonymous requests then there is obviously no
accountability. Does that need to be explicitly mentioned?
— Neil
On 27 Oct 2020, at 01:04, Manger, James
<[email protected]> wrote:
It is worth mentioning “client collaborative attacks” or
“authorization sharing attacks” because OAuth can make them easier
(by packaging authority into an access token), compared to the
alternative of user’s signing-in to an RS directly. But it is tricky
to describe; none of the suggestions are quite right; and the
“right” solution heavily depends on the context.
>> If access tokens are used to identify individuals, and such
identifying information (ideally user IDs) is stored with access
logs for auditing purposes, then this reduces this attack to an
authentication sharing attack.
While this text from Seán may be true, it is bad advice. It implies
we should make access tokens as dangerous as possible (conveying all
a person’s authority) just to discourage sharing.
> Since OAuth 2.0 does not mandate the use of cryptographic devices,
this kind of attack cannot be countered in the general case.
Even crypto devices aren’t a full solution. Alice can share her
authorization with Bob & Chris by signing-in with their crypto devices.
> an access token … only stating that the holder … is over 21 … should
not be accepted by the RS
While this may generally be true for an “over 21” claim, it will not
always be true for other claims. In some situations the privacy risk
of being personally identified is far more important than any risk
of client collaboration. Staff accessing a company’s whistle-blower
service could be an example: need a {staff:true} claim to combat
spam/gossip; but definitely don’t want to include a staff id.
A handful of partial strategies appropriate in various circumstances
(but all with downsides) could include:
1. The AS ensures there is only 1 valid access token (or just a few)
at any point in time for a specific claim of a given user.
2. Access token bound to a crypto key locked to one device.
3. Each access token is unique (eg includes a "jti" claim) so an RS
can notice if the same token is presented in different contexts.
4. Access token with "sub" (or provides "sub" via token
introspection) to aid accountability (even if only in a later
audit/investigation).
5. Frequent token replacement.
6. Nothing (beyond minimal necessary claims) – to maximize privacy.
What is applicable widely enough to mention in a BCP?
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
https://danielfett.de
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
