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