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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
