[OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt

[Denis <[e-mail]>]

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