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

[Daniel Fett <[e-mail]>]

Am 12.04.21 um 16:56 schrieb Denis:
> Hi  Daniel,
>
>> (...)
>>>>
>>>> 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.
>>
> [Denis]. Your very last sentence is finally using two magic words that
> are not present anywhere in the BCP: "*clients cooperating*".
> However, *clients collusion* or *clients collaboration* would be more
> accurate.
>


   *  (A1) Web Attackers that can set up and operate an arbitrary number
      of network endpoints including browsers and servers (except for
      the concrete RO, AS, and RS).  Web attackers may set up web sites
      that are visited by the RO, operate their own user agents, and
      participate in the protocol.

      Web attackers may, in particular, operate OAuth clients that are
      registered at AS, and operate their own authorization and resource
      servers that can be used (in parallel) by the RO and other
      resource owners.

(...)

      Attackers can collaborate to reach a common goal.




>>
>>>>> 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.
>
> [Denis] Well, ... ask anybody else how he would interpret your statement.
>
Feel free.
>
>>> 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.
>>
> [Denis] I never said that there is "some form of authentication". The
> word "authentication" is not present in my text proposal.
>
> At the moment (/and this is a topic of its own that could be discussed
> later on/), a "sub" claim present in an access token is unrelated to
> any identifier
> used during an authentication exchange between an end-user and a RS.
>
It is very much possible that I did not understand your proposed
solution correctly. Part of the problem is that a concise and concret
attack description is missing (where end-user and clients are not
conflated). If you could provide such a description, in the style of the
mix-up attack description (i.e., using concrete protocol participants
and protocol messages), that would greatly benefit the discussion.


> PS. I re-read RFC1855, Section 3.1.1, but there is nothing in the
> Netiquette to delete or maintain some parts of a received message.
>
    - If you are sending a reply to a message or a posting be sure you
      summarize the original at the top of the message, or include just
      enough text of the original to give a context.  This will make
      sure readers understand when they start to read your response.


-- 
https://danielfett.de