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

[Steinar Noem <[e-mail]>]

Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.

As far as I know OAuth doesn't require a specific token format, so the
countermeasure you describe is based on an assumption that the AT is a JWT.
If that's the case, isn't what you are describing as a countermeasure
related and already covered by the work being done in the JWT spec for
Access Tokens?

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5

S

man. 12. apr. 2021 kl. 14:58 skrev Denis <[e-mail]>:

> 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.1  Attack Description
> 4.16.2  Countermeasures
>
> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [e-mail] | [e-mail]  | [phone] | www.udelt.no |