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

[Seán Kelleher <[e-mail]>]

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


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

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
>

   - 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 <[e-mail]> wrote:

> 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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>