Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

[Denis <[e-mail]>]

To all,

In RFC 6819 OAuth 2.0 Security), it is assumed in section 2.2 (Attack 
Assumptions)that :

  * two of the three parties involved in the OAuth protocol may collude
    to mount an attack against the 3rd party.
    For example, the client and authorization server may be under
    control of an attacker and collude to trick a user to gain access to
    resources.

These three parties are the client, the AS and the RS.

The case where two clients collude to mount an attack against a RS is 
not addressed. It now needs to be addressed.

This should be added in section 1 ( Introduction)

The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) 
clearly states:

     " In the following, this attacker model is updated (...) to include 
new types of attackers and to define the attacker model more clearly".

Section 3 should include the case of a collusion or a collaboration 
attack between clients against a RS, where one of them is a legitimate 
client
voluntarily "helping" another client to use or to request access tokens 
that would normally "belong" to the legitimate client.

Finally, section 4 (Attacks and Mitigations) should include an 
additional subsection, e.g. section 4.16, addressing the case of a 
collaboration attack
between clients against a RS.

This sub-section would need to include to other sub-sections:

4.16.1Attack Description
4.16.2Countermeasures

The following text is a skeleton proposed for these subsections:

*4.16****Collaboration attack between clients against a RS*

The goal of the attack is for an illegitimate client to obtain an access 
token from an authorization server with the help of a client of the 
authorization server.

*4.16.1****Attack Description*

The legitimate client performs in real time all the cryptographic 
computations needed by the illegitimate client to get an access token 
and to present it to a RS.
This attack is not a replay of a access token, but the use of a 
legitimate access token by an illegitimate client with the complicity of 
the legitimate client.

It should be observed that protecting some private keys into a secure 
element is ineffective to counter this kind of attack, since the 
legitimate client can perform
all the computations needed by the illegitimate client, without the need 
to know or to transfer the values of these private keys.

*4.16.2****Countermeasures*

This attack may be countered by using a "sub" claim into the access 
token. It should be observed that the "sub" claim is a REQUIRED claim in 
the JWT access token
data structure. See section 2.2 from JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens.

Section 5 (Security Considerations) from JSON Web Token (JWT) Profile 
for OAuth 2.0 Access Tokens states:

Authorization servers should prevent scenarios where clients can affect 
the value of the "sub" claim in ways that could confuse resource servers.

This statement is correct but insufficient, since it does not say how 
resources servers cannot get confused.

Section 6(Privacy Considerations) states:

      This profile mandates the presence of the "sub" claim in every JWT 
access token, making it possible for resource servers to rely on that 
information
      for correlating incoming requests with data stored locally for the 
authenticated principal.

This statement is correct but is unclear. To be more precise, in order 
to counter the collaboration attack between clients against a RS, the RS 
should manage
user accounts associated either with a globally unique identifier or an 
identifier specific to an AS-RS pair while the "sub" claim shall contain 
either
a globally unique identifier or an identifier specific to an AS-RS pair 
which shall be compared with the identifier of the user account. If 
there is no match,
the access token shall be discarded.

In this way, the access token will be linked to the user account of the 
legitimate client and the illegitimate client cannot take advantage of 
the claims
contained into the access token.

Denis


>   All,
>
> The coming OAuth WG Interim meeting is this coming* Monday, April 
> 12th, at 12:00 pm EDT.*
> The meeting will be focused on the *Security BCP *document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ 
> <https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/>
>
> The following link has links to the slide and draft and will be used 
> to capture the notes and attendees:
> https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both 
> <https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both>
>
> *Webex Meeting Link:*
> https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b 
> <https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b>
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth