Subject: [OAUTH-WG] BCP: Client collaborative attacks

From: Denis <[email-masked]>
Date: Mon, 26 Oct 2020 19:18:39 +0100

Hi Daniel,

Following the conversation we had today, hereafter is a proposal for 
addressing client collaborative attacks.
I propose to add a new section 4.16.

4.16 Client collaborative attacks

Two clients may agree to collaborate. In such a situation, one client 
transmits to another client an access token
that it legitimately got and also accepts to perform all the 
cryptographic computations that the other client needs
to use the access token, including when the access token is 
cryptographically bound to a key.

Since OAuth 2.0 does not mandate the use of cryptographic devices, this 
kind of attack cannot be countered in the general case.

However, if the access token contains claims that allow the RS to 
uniquely identify the legitimate holder of the access token
and if the RS only accepts access tokens that are able to uniquely 
identify the legitimate holder of the access token, then
this attack can be mitigated since the client collaborative attack 
becomes an impersonation attack.

For mitigating the collaborative attack, either a "sub" claim must be 
present or any combination of other claims allowing for the RS
to uniquely identify the holder of the access token must be present 
inside an access token, for example OpenID claims like: name,
family_name, given_name, middle_name, nickname, preferred_username, 
gender, birthdate, email, email_verified, phone_number,
phone_number_verified or address.

On the contrary, for example, an access token that would only contain a 
claim stating that the holder of the access token is over 21
or a birthdate without any claim allowing the RS to uniquely identify 
the legitimate holder of the access token, should not be accepted by the RS.

Under these conditions, it should be observed that the first user might 
be unlikely to be willing to collaborate since the other user would be able
to perform actions on behalf of the first user and the first user would 
be held responsible of the actions of the second user.

*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

---

From: Seán Kelleher <[email-masked]>
Date: Mon, 26 Oct 2020 21:18:44 +0000

I hadn't come across this idea before, it's an interesting angle and for me
it's a nice new example to help highlight the difference between authZ and
authN. It reminds me of sharing access cards to get into computer labs in
college. Some thoughts:

   - It took me a while to figure out the agent, victim, intent and impact
   for the attack based on its name and description. The presented term may
   already be accepted, but if not, would you consider the term "authorization
   sharing attack"? I feel that this conveys the intent and impact of the
   attack a bit more clearly.

However, if the access token contains claims that allow the RS to uniquely
> identify the legitimate holder of the access token
> this attack can be mitigated since the client collaborative attack becomes
> an impersonation attack.

   - Being pedantic, I don't think this mitigates the attack so much as it
   reduces it to the mentioned impersonation attack. However, I'm not sure
   that "impersonation attack" is the right term to use here, as this scenario
   seems to imply that the subject consents to the impersonation, which is in
   contrast to the standard impersonation attack where the subject is the
   victim.

> to uniquely identify the holder of the access token must be present inside
> an access token
>

   - A more general phrasing of this could be that "it should be possible
   to use an access token to uniquely identify an individual". I say this
   because this kind of identification can also be done using opaque tokens,
   in which case the claims are not necessarily "inside" the access token.

Under these conditions, it should be observed that the first user might be
> unlikely to be willing to collaborate since the other user would be able
> to perform actions on behalf of the first user and the first user would be
> held responsible of the actions of the second user.

   - This seems to be the main justification as to why the above
   mitigations are considered as such. I don't agree with the conclusion
   because I feel it's based on debateable assumptions, the main one being
   that the "first user might be unlikely to be willing to collaborate" if
   they know that their access token identifies them, which tries to predict
   human behaviour. It also depends on the user knowing whether access tokens
   can be used to identify them.
   - I'm again being pedantic, but I would also note that just being able
   to identify a user from an access token is unlikely to be a sufficient
   deterrent, it would need to be coupled with logging of all access token
   usages for auditing purposes. Again though, this assumes that we can
   predict human behaviour.
   - Following on from one of my above points, I would remove the user
   element from this section, and avoid calling it a mitigation. I'd instead
   outline that if access tokens can be used to identify individuals then it
   reduces possible authZ sharing attacks to authN sharing attacks.

I think this is an interesting attack vector, particularly because it
requires the authZ sharer to have internal knowledge of how the RS
operates, and so has relatively niche applications. It also seems to assume
that the RS in question doesn't store user IDs with access logs, at which
point, is it simpler to just recommend that authN'd requests to an RS
should be logged with user IDs?

I've written up an alternative for consideration:

Authorization sharing attack
>
> If access tokens are not used to identify individuals, and if this
> information is known to an individual, then such an individual may use
> knowledge of this to share the authorization granted to them by access
> tokens. This may be done by sharing access tokens across clients and
> individuals, at which point the RS will not be able to distinguish between
> different subjects and clients using the same access token.
>
> 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.
>

I think it's a bit too general for a BCP, and too vague around the notion
of an "individual", but it might give some food for further thought.

Kind regards,

Seán.

On Mon, 26 Oct 2020 at 18:19, Denis <[email-masked]> wrote:

> that it legitimately got and also accepts to perform all the cryptographic
> computations that the other client needs
> However, if the access token contains claims that allow the RS to uniquely
> identify the legitimate holder of the access token
> this attack can be mitigated since the client collaborative attack becomes
> an impersonation attack.
>
> to uniquely identify the holder of the access token must be present inside
> an access token, for example OpenID claims like: name,
> or a birthdate without any claim allowing the RS to uniquely identify the
> legitimate holder of the access token, should not be accepted by the RS.
>
> Under these conditions, it should be observed that the first user might be
> unlikely to be willing to collaborate since the other user would be able
> to perform actions on behalf of the first user and the first user would be
> held responsible of the actions of the second user.
>
>
>
> *Comment on section 4: "Validating JWT Access Tokens" *
> [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into
> an access token.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 26 Oct 2020 14:25:17 -0700

Thank you Seán, this is an excellent analysis and makes this attack much
easier to understand. I completely agree with your rewritten text, both
that it better describes the situation as well as the conclusion that it
ends up being a bit too general for the BCP.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Mon, Oct 26, 2020 at 2:19 PM Seán Kelleher <[email-masked]> wrote:

> I hadn't come across this idea before, it's an interesting angle and for
> me it's a nice new example to help highlight the difference between authZ
> and authN. It reminds me of sharing access cards to get into computer labs
> in college. Some thoughts:
>
>    - It took me a while to figure out the agent, victim, intent and
>    impact for the attack based on its name and description. The presented term
>    may already be accepted, but if not, would you consider the term
>    "authorization sharing attack"? I feel that this conveys the intent and
>    impact of the attack a bit more clearly.
>
>    - Being pedantic, I don't think this mitigates the attack so much as
>    it reduces it to the mentioned impersonation attack. However, I'm not sure
>> inside an access token

---

From: "Manger, James" <[email-masked]>
Date: Tue, 27 Oct 2020 01:02:59 +0000

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

---

From: Neil Madden <[email-masked]>
Date: Tue, 27 Oct 2020 06:26:44 +0000

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-masked]> wrote:
> 
> 

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Seán Kelleher <[email-masked]>
Date: Tue, 27 Oct 2020 08:59:49 +0000

@James

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

Is this implied because storing IDs with access logs means that ATs
necessarily carry user ID information (possibly indirectly through an
introspection endpoint)? I would note that the AT doesn't need to carry ID
information itself, just enough information has to be stored with request
logs to be able to later associate user IDs with requests. As a naive
example, ATs could be stored with requests and mappings from user IDs to
issued ATs could be stored on the AS. Ignoring the potential
inefficiency/insecurity of such an approach, it allows user IDs to later be
associated with requests without carrying such information in the AT itself.

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

I think this is a good example of a scenario of wanting authZ without
authN, thanks.

And I would add, specific enough. It seems more like something that should
exist in the "Security Considerations" section of a regular standard.

@Neil

But this can only discourage, not prevent, delegation. OAuth is after all a
> delegation protocol.

Following on from your side quote, this is why I would say that it only
reduces authZ sharing to authN sharing, because delegation can still be
done even if it's "discouraged".

If the RS allows anonymous requests then there is obviously no
> accountability. Does that need to be explicitly mentioned?

I think this is the crux of the issue. The "attack" then boils down to "if
you don't have a means of identifying individuals that have made requests,
then different individuals that know this might pretend to be the same
individual". At which point the follow on would seem: if you care about
this then add a "means of identifying individuals that have made requests".

On Tue, 27 Oct 2020 at 06:26, Neil Madden <[email-masked]> wrote:

> 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
>
> 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.
>
>
>
> Even crypto devices aren’t a full solution. Alice can share her
> authorization with Bob & Chris by signing-in with their crypto devices.
>
>
>
> 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.
>
>
>
>
>
> 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.
>
> 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).
>

---

From: Daniel Fett <[email-masked]>
Date: Tue, 27 Oct 2020 14:17:26 +0100

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:
> 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. 
>
>> 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.
>>
>>  
>>
>> 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.
>>
>>  
>>
>> 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.
>>
>>  
>>
>>  
>>
>> 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.
>>
>> 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).
>>

-- 
https://danielfett.de

---

From: Denis <[email-masked]>
Date: Tue, 27 Oct 2020 15:05:14 +0100

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.

Denis

>> (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).
>>
>>> to describe; none of the suggestions are quite right; and the 
>>> “right” solution heavily depends on the context.
>>>
>>> identifying information (ideally user IDs) is stored with access 
>>> logs for auditing purposes, then this reduces this attack to an 
>>> of being personally identified is far more important than any risk 
>>> of client collaboration. Staff accessing a company’s whistle-blower

---

From: "Manger, James" <[email-masked]>
Date: Thu, 29 Oct 2020 02:25:02 +0000

>> When using secure elements with specific properties, it is possible to counter the Alice & Bob Collusion attack.

You don’t just need the Secure Element’s properties (key-pair generated on SE; non-exportable private key; high-entropy key-id generated on SE; conformance cert; special APDUs), you also need the wider scheme to enforce that any user only ever has 1 SE active at a time.

Only-1-SE-per-user-at-a-time seems fairly fundamental to strongly combating collaborative attacks. But it is totally inappropriate to many (most?) scenarios where OAuth is used.

>> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

This eID scheme looks pretty good. You can see why this scheme would like particular features in a profile of OAuth.

But this is one highly specialised profile of OAuth (+ FIDO + SE + eID + …) that is quite unlike the “typical” use of OAuth. Its requirements aren’t “best practice” for all OAuth deployments.

P.S. I don’t think your content has been “deleted from this thread”. Just not every reply includes the full email trail. It is all still at https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index= for instance.

--
James Manger