[OAUTH-WG] BCP: Client collaborative attacks

[Denis <[e-mail]>]

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