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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
