Hi Daniel,

Denis,

I was awaiting your mail and I admire your perseverence with bringing this topic to our attention.

[Denis] I admire your perseverence with constantly refusing to include this attack. :-)

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
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)

No.


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.


As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.


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.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017. Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


*There is no expectation that OAuth would defend against this kind of thin**g*, just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how *"OAuth can successfully defend against this kind of thin**g"*. *So* *there **IS **a solution*.

Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim. Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

I therefore propose to proceed with the Security BCP *with the inclusion of this attack*.

Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel

[Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it.

   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


--
https://danielfett.de

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to