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