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

[Denis <[e-mail]>]

Hi Daniel,

> Hi Denis,
>
> Am 05.05.20 um 17:19 schrieb Denis:
>> Comments on draft-ietf-oauth-security-topics-15
>>
>> 1) Historically, the acronym RO (Resource Owner) has been used but is 
>> still used in this document.
>>     Since a client is not necessarily any more a RO, it would be more 
>> adequate to use the word "Client"
>>     instead of "RO"  in this document.
>>
> The terms Resource Owner and Client are clearly defined in RFC6749 and 
> refer to two different entities.

RFC 6749 contains the two following definitions:

resource owner
       An entity capable of granting access to a protected resource.
       When the resource owner is a person, it is referred to as an
       end-user.

client
       An application making protected resource requests *on behalf of the**
**      resource owner and* with its authorization.  The term "client" does
       not imply any particular implementation characteristics (e.g.,
       whether the application executes on a server, a desktop, or other
       devices).

The original definition of a client does not appear to be adequate any more.
It is questionable whether the definition of a client from RFC 6749 
should be reused word-to-word.

The original definition of a client mentions the resource owner and 
misses to mention the authorisation server.
I wonder whether the use of the wording "on behalf of the resource 
owner" is really adequate. A client is not
impersonating the resource owner.

A client is an application *using an authorisation server *for 
performing protected resource requests
that will be granted or not by a resource owner.

A new definition for the term client should be adopted for this 
document.  However, you are right, the two wordings shall remain.

>> 2) The structure of the document is the following:
>>
>> 1.Introduction
>> 2.Recommendations
>> 3.The Updated OAuth 2.0 Attacker Model
>>
>> It is rather odd to have recommendations placed before the Attacker 
>> Model. Before providing solutions to some problems,
>> it is important to understand what the problems are. The Updated 
>> OAuth 2.0 Attacker model should be placed after the introduction.
>>
>> The "most important recommendations of the OAuth working group for 
>> every OAuth implementor" should be placed after the "Attacks and 
>> Mitigations" section.
>>
> This structure was chosen specifically to have the recommendations - 
> arguably the most important section for everyday users of OAuth - in 
> the front.

This means that most readers will only read the recommendations section 
placed upfront and are likely to ignore the other sections,
in particular the Updated OAuth 2.0 Attacker Model. They will thus kept 
ignorant of attacks that cannot be countered using the "Best Practices".
They may then believe that their implementations are secure whereas it 
will not be the case.

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

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