Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

[Denis <[e-mail]>]

Hi Daniel,

Thank you for pointing to your dissertation which has the following 
title : An Expressive Formal Model of the Web Infrastructure.

Since it is 240 pages long (or thick), I have not read everything but 
some sentences brought my attention.

I have experienced formal models in the past and everything depends upon 
the hypothesis that are made upfront.

On page 28:

    1.1.1. The Web Infrastructure Model

    (...)
    Altogether, the model is the *most comprehensive and detailed model
    for the web infrastructure to date* [i.e. in year 2018].
    (...)

On page 40, there is the following sentence:

    *A browser is thought to be used by one honest user*, who is modeled
    as part of the browser.


With such an hypothesis, it is impossible to consider a collusion attack 
between clients, hence the Model omits to consider such a case.
When using a formal approach, it is generally not possible to make sure 
that all attacks have been considered, but when considering
specific attacks, it is possible to demonstrate that they can be 
countered (or not).

Many models are considering "adversaries". This originates from the 
"Alice, Bob and Carol model" where both Alice and Bob
were honest and where Carol was the attacker. In the case of the "Alice 
and Bob Collusion attack", Alice and Bob are good friends.
The target of the attack is a RS. The RS is not an adversary : it does 
nothing bad. Alice and Bob are adversaries towards Carol (the RS).
This can bee seen as the revenge of "Alice and Bob" against Carol.  :-)

On page 29, the text states:

    Model of OAuth 2.0

    Using our generic web model, we build a formal model of OAuth,
    closely following the OAuth 2.0 standard [RFC6749].

On page 72, Figure 3.1 there is a diagram flow that is rather different 
from the diagram flow that is present in RFC 6749 Figure 1.
In Figure 3.1,  an entity combines the roles of the AS and the RS 
whereas in Figure 1 : Abstract Protocol Flow (Page 7), these two
roles are under the control of two separate entities. This means that 
the formal Model of OAuth is NOT closely following the OAuth 2.0
standard [RFC 6749].

On page 29, the text continues with:

    Our model includes clients and AS/RS that (simultaneously) support
    all four modes of operation available in OAuth and
    *can be dynamically corrupted by the adversary*.

With the ABC attack, clients are not /dynamically corrupted by an 
adversary/, since Alice and Bob voluntarily cooperate to achieve
a common goal: to cheat a RS. As a consequence, the dissertation does 
not consider collaborative clients or collusion between clients.

The same problem appeared with the ABC4Trust EU project (Attribute-based 
Credentials for Trust) which has now ended.
*U-Prove* from Microsoft and *Identity Mixer* from IBM were used as a 
demonstrating technology of the principles.
However during the project, no one ever considered the case of the Alice 
and Bob collusion attack. So all experts involved
in this project believed that these two technologies were secure, 
whereas they were not, even when smart cards were being used.

You wrote :

    " A commonly accepted security property for OAuth would be:

       An attacker should not be able to obtain access to or use a
    protected resource protected by an uncompromised AS
       if that resource is only used by an honest user with an
    uncompromised client and user agent."

This sentence has nothing to do with a "security property". This term is 
defined in ISO/IEC TS 19249:2017, 3.1:

    *security property*
    *property* of a system or application *that is crucial to achieve
    the security objectives defined for the system or application*

On the contrary, it is *c**rucial to prevent collaborative users to 
cheat a RS using an uncompromised AS*.

You also wrote:

    Being resistant to collusion attacks is not a commonly
    accepted/expected security property.

Being resistant to collusion attacks is indeed a security property.

Considering only honest users is an hypothesis that does not correspond 
to the real world. Currently, when reading the current document
even through the lines, it is impossible to guess that the ABC attack 
may ever exist.

Now, the question is : Is OAuth 2.0 able to meet such a property ? I 
read again my previous emails and the answer is ... *YES*.

I considered two cases:

    a) When the JWT contains one or more attributes that uniquely allow
    to identify the collaborative user, then the other client
    will be in a position to impersonate the collaborative user. There
    is no advantage for Alice because she will simply be able to
    impersonate Bob and she will not take any advantage of the
    attributes from Bob for herself.

    b) When the JWT does not contain a sufficient number of attributes
    that would allow to identify the user,
    the collaborative user can transmit it to anybody else, without the
    risk to be detected by the RS.  E.g. it
    only contains the age of the user and a membership to a large group
    of people. This case can only be countered
    using secure elements with specific properties.

When the token contains one or more attributes that uniquely allow to 
identify the collaborative user (e.g. a "sub" claim),
then Alice can only impersonate the collaborative user and such a case 
can easily be obtained using TeamViewer.

      * Unfortunately using the "sub" claim is not "privacy friendly",
        since collaborative RSs will be able to link the accounts
        of their respective users.  Nevertheless, this a good news for
        Vittorio, since the "sub" claim is REQUIRED in the
        "Profile for OAuth 2.0 Access Tokens". This means that, *when
        this profile is being used, OAuth 2.0 is resistant **to
        the ABC attack*.

      * Using a different claim that would only contain an identifier
        that is unique to the RS (such as a pseudo) would be
        more appropriate (as FIDO does), but I am not aware of a claim
        that has been defined which would have such a semantics.

The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships
involving multiple parties_. As explained above, this is not the case 
for clients since multiple clients have not been considered.
This is also not the case for RSs since multiple RSs have not been 
considered.

Anyway, in order to correctly explain the cases, there needs to be a 
discussion in this document both about the ABC attack
_and_ the content of the token. There should also be a discussion about 
multiple RSs where an RS attempts to forward a received token
to another RS. Even if the countermeasure is obvious, it should be 
mentioned in this document.

To summarize my findings about the dissertation, it is not able to 
address these cases since it only consider attackers that can either be :

  * "Web attackers (who can listen to and send messages from their own
    addresses only)" or
  * "Network attackers (who may listen to and spoof all addresses and
    therefore are the most powerful attackers)".

Denis

> Hi Denis,
>
> Am 07.05.20 um 14:46 schrieb Denis:
>> (...)
>>
>> A new definition for the term client should be adopted for this 
>> document.  However, you are right, the two wordings shall remain.
>>
> I cannot follow any of this, sorry.
>
>>>>
>>>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have 
>>>> been "updated to account for the potentially _dynamic relationships 
>>>> involving multiple parties_".
>>>> However, it still misses to address the case of _dynamic 
>>>> relationships between clients_, which include scenarios of 
>>>> _collaborative clients_.
>>>>
>>> That is not correct. Web attackers (A1) can participate in the 
>>> protocol as one or more users (resource owners) or clients. Of 
>>> course, these can collaborate between each other.
>>>
>> Section 3 states:
>>
>> *OAuth MUST ensure that* the authorization of the resource owner 
>> (RO)  (with a user agent) at the authorization server (AS) and
>>    the subsequent usage of the access token at the resource server 
>> (RS) *is protected _at least_ against the following attackers*:
>>
>>   *  (A1) *Web Attackers *(...)
>>
>> If a collaboration / collusion between clients were covered under 
>> this case, then it would mean that *OAUTH MUST provide a protection 
>> for it*,
>> whereas this is technically impossible.
>>
> You are confusing the attacker model with the security goals (aka 
> security properties).
>
> A commonly accepted security property for OAuth would be:
>
> "An attacker should not be able to obtain access to or use a protected 
> resource protected by an uncompromised AS if that resource is only 
> used by an honest user with an uncompromised client and user agent."
>
> (roughly equivalent to the one in 
> https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)
>
> Being resistant to collusion attacks is not a commonly 
> accepted/expected security property.
>
> So: Yes, attackers are free to collude, and that is part of the model. 
> No, that is not a problem, as they are not breaking anything anyone 
> would expect.
>
> -Daniel
>
>
>> Since AOuth is unable to protect against a collusion attack between 
>> clients, the collusion attack cannot belong to this section, in 
>> particular under (A1).
>>
>> Section 3 is confusing the threat model with the resistance of OAuth 
>> to these threats.
>>
>> At this time, an RFC reader may not catch the fact that a collusion 
>> attack between clients may ever exist and thus may not
>> grasp the fact that this kind of attack cannot be countered by OAuth, 
>> even when following the Best Practices.
>>
>> The "Updated OAuth 2.0 Attacker Model" does not take into "account 
>> for the potentially _dynamic relationships involving multiple parties_".
>> as it is advertised, in particular the case of _dynamic relationships 
>> between clients_ which include the case of _collaborative clients_.
>>
>> The text currently does not  incorporate words like "collusion", 
>> "colluding", whereas it should. The text should clearly indicate that
>> a protection against a collusion between clients is currently not 
>> possible using OAuth.
>>
>>>> Such a collaboration between clients is possible and should be 
>>>> considered in the "updated model".
>>>>
>>> This is considered in the model.
>>
>> See my comments above. While promised by the text, the case of 
>> collaborative clients is not considered in the model.
>>
>>>> which are human beings, it cannot be assumed that all the human 
>>>> beings in the world will necessary be honest. Whether or not Auth 
>>>> 2.0 is able or not
>>>> to counter such an attack is another issue.
>>>>
>>> This as well. 
>>
>> As said above, the model should only express the threats (or the 
>> possible attacks) and another section should indicate which threats 
>> cannot countered.
>>
>>>> In another section, it should be mentioned that OAuth 2.0 is unable 
>>>> to counter such an attack.
>>>>
>>> The problem is not that this type of collusion attack is not 
>>> possible under the model. The problem is it is not commonly expected 
>>> that OAuth protects against this type of attack.
>>>
>> RFC readers who have not followed or participated to this thread will 
>> not necessarily know that OAuth does not protect against this type of 
>> attack.
>>
>> The purpose of this document is to inform the reader about _all_ 
>> known types of attacks, whether they can be defeated or not by OAuth 2.0.
>>
>> Denis
>>
>>> -Daniel
>>>
>>>> Stating that such an attack is "out of the scope" of OAuth 2.0 
>>>> would not be an appropriate statement.
>>>>
>>>> It should not be forgotten, that the purpose of this document is to 
>>>> inform the reader about _all_ the relevant security issues.
>>>>
>>>> Denis
>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>>>
>>>>>          Title           : OAuth 2.0 Security Best Current Practice
>>>>>          Authors         : Torsten Lodderstedt
>>>>>                            John Bradley
>>>>>                            Andrey Labunets
>>>>>                            Daniel Fett
>>>>> 	Filename        : draft-ietf-oauth-security-topics-15.txt
>>>>> 	Pages           : 46
>>>>> 	Date            : 2020-04-05
>>>>>
>>>>> Abstract:
>>>>>     This document describes best current security practice for OAuth 2.0.
>>>>>     It updates and extends the OAuth 2.0 Security Threat Model to
>>>>>     incorporate practical experiences gathered since OAuth 2.0 was
>>>>>     published and covers new threats relevant due to the broader
>>>>>     application of OAuth 2.0.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>>
>>>>> There are also htmlized versions available at:
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth