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 <denis.i...@free.fr>: > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no |
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
