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

[Denis <[e-mail]>]

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.

>
>>>> 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.


>> 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.

This means that your statement is incorrect.

*"OAuth can successfully defend against this kind of thin**g" and, since 
countermeasures exist, they should be described.
*

> 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
>
I re-established the remainder of the mail as it is relevant to *my 
*answer.

However, reading it again, the "Attack description" does not refer to a 
JWT access token whereas it is not the case for the two other sub-sections.
Nevertheless, these two sub-sections could be easily generalized to also 
address the case where JWT access tokens are not being used.

    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.

    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.

Denis

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.


> -- 
> https://danielfett.de