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

[Daniel Fett <[e-mail]>]

Hi Denis,

Am 12.04.21 um 14:57 schrieb Denis:
>>
>>> 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.
>
I don't understand. This is not about believing, it is written very
clearly and conclusively in the text of the current draft.

We've had this discussion before, and, although irrelevant for the
meaning of the BCP itself, I would like to refer you again to the formal
model in our research paper, which the BCP attacker model is based on.
It has a *very* precise definition of the attacker model that does not
leave room for interpretation. The natural-language description in the
BCP, as usual, is more fuzzy than the formal definition, but both
attacker models include clients cooperating.


>
>>> 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*.
>
I did not say that there is no 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.
>
Your proposed solution does not enable an RS to identify the attack
unless used together with some form of authentication way outside the
scope of OAuth.

Again, this also goes deeply into OIDC territory.

> 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.
>
I deleted the remainder of the mail as it was not relevant to my answer
(see RFC1855, Section 3.1.1). Everybody can access your original mail on
the mailing list.

-Daniel

-- 
https://danielfett.de