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