Comments on OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-06
The text is scaring ! It is quite hard to understand under which
/context(s) /and conditions OAuth 2.0 could be safely used.
1° A "Privacy considerations" section should be added. It is important
to place the AS at the center of the picture
and to observe whether it would be able to act as Big brother (or not).
Several counter-measures are not 'privacy friendly'.
As an example, in section 3.7.1.3 the text states:
The audience can basically be expressed using logical names or physical
addresses (like URLs).
Since this URL will be known to the AS, the AS will be able to act as
Big Brother. There are cases where this will not be important
but there are cases where it will be. The text states later on:
Instead of the URL, it is also possible to utilize the fingerprint
of the resource server’s X.509 certificate as audience value.
This is obviously better, but it is not a panacea. The AS will know how
often a particular user accesses a particular server.
The AS would have also plenty of time to try various URLs and to check
whether they match with the fingerprint and hence
might be able to discover the URL.
As another example, in section 3.7.1.1, the text states:
An authorization server could provide the client with additional
information about the location where it is safe
to use its access tokens. In the simplest form, this would require
the AS to publish a list of its known resource servers,
illustrated in the following example using a metadata parameter
"resource_servers".
This is not "privacy friendly" since relying parties will know with
which resource servers the AS has made an agreement
and the AS will know at the minimum where the access tokens it issues
can be used.
2° There is one important threat that was not discussed in the OAuth 2.0
"Threat Model and Security Considerations from 2013" [RFC6819]:
collusion between users. In particular, when a user got an access token
that does not allow to fully identify him and where he would allow
another user to use it. A typical case would be an access token only
stating that the user is over 18. This case should be mentioned.
My current belief is that OAuth 2.0 is unable to counter this kind of
attack, even when private ore secret keys are protected by a secure element.
In section 3.5.1. Token Binding is mentioned "as a secure and convenient
mechanism (due to its browser integration)".
However, it should also be mentioned that this mechanism is inefficient
in case of a collusion attack.
3° Section2 describes the set of security mechanisms the OAuth working
group recommended to OAuth implementers.
However, the text that follows uses the verb" shall", hence it is no
more a recommendation but a requirement.
The use of the verb "should" should be considered instead.
In particular, the text states:
"Clients shall use PKCE [RFC7636] in order to (with the help of the
authorization server) detect and prevent attempts
to inject (replay) authorization codes into the authorization
response".
This is incorrect, since RFC7636 should be used when the authorization
code is returned from the authorization endpoint
within a communication path that is _not protected_ by Transport Layer
Security (TLS).
Instead of placing requirements one after another, the document should
be restructured to highlight the contexts
where these recommendations are being done, in particular for:
- static relationships between client, authorization server and
resource servers, and
- dynamic establishment relationships between clients on one side and
authorization servers and resource servers on the other side.
Denis
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
