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

[Janak Amarasena <[e-mail]>]

Hi All,

In section *4.1.3. Countermeasures
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.1.3>*
related to *4.1.  Insufficient Redirect URI Validation* it states

   The complexity of implementing and managing pattern matching
   correctly obviously causes security issues.  This document therefore
   advises to simplify the required logic and configuration by using
   exact redirect URI matching only.  This means the authorization
   server MUST compare the two URIs using simple string comparison as
   defined in [RFC3986], Section 6.2.1
<https://tools.ietf.org/html/rfc3986#section-6.2.1>.


Does this mean that the authorisation server MUST NOT use pattern matching
at all and MUST do simple string comparison for redirect URI?
If that is the case can we change the wording a bit in this section as
having "...therefore *advises* to simplify the required logic..." gives the
impression that the AS has the choice to decide whether or not to use
pattern matching. And then when we have "...authorization server *MUST*
compare the two URIs using simple string..." give the impression that the
AS should absolutely not(MUST NOT) use pattern matching.

Best Regards,
Janak Amarasena

On Fri, May 8, 2020 at 2:53 PM Denis <[e-mail]> wrote:

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