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

From: [email-masked]
Date: Sun, 20 May 2018 04:38:17 -0700

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-06.txt
	Pages           : 31
	Date            : 2018-05-20

Abstract:
   This document describes best current security practices 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-06
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-06

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/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 20 May 2018 13:42:55 +0200

Hi all,

the new revision contains the following changes: 
	• reworked section 3.8.1
	• incorporated Phil Hunt's feedback
	• reworked section on mix-up
	• extended section on code leakage via referrer header to also cover state leakage
	• added Daniel Fett as author
	• replaced text intended to inform WG discussion by recommendations to implementors
	• modified example URLs to conform to RFC 2606

Please join me in welcoming Daniel Fett (one of the researches who discovered the mix up attack) as another co-author of the draft!

best regards,
Torsten. 

> Am 20.05.2018 um 13:38 schrieb [email-masked]:
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Tue, 22 May 2018 15:05:53 +0200

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

---

From: Joseph Heenan <[email-masked]>
Date: Tue, 22 May 2018 19:20:47 +0100

Hi Denis,

> On 22 May 2018, at 14:05, Denis <[email-masked]> wrote:
>        "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).
> 
That is not really the full story as we've seen attacks where URLs that you would expect to be protected by TLS are vulnerable; one example is:

https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf

IMHO it would be sane to use PKCE anywhere where a code is returned in the URL and there isn't another proof of possession / token binding mechanism in play.

Joseph

---

From: Denis <[email-masked]>
Date: Wed, 23 May 2018 13:58:42 +0200

Hi Joseph,

Among these 39 slides, to which attack(s) are you referring ?

I wrote:"It is quite hard to understand under which /context(s) /and 
conditions OAuth 2.0 could be safely used".

For each counter-measure, it would be useful to explain under which 
context(s) or under which assumptions
it should be used.

Denis

> Hi Denis,
>
>> On 22 May 2018, at 14:05, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>        "Clients shall use PKCE [RFC7636] in order to (with the help 
>> of the authorization server) detect and prevent attempts
>> 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).
>>
> That is not really the full story as we've seen attacks where URLs 
> that you would expect to be protected by TLS are vulnerable; one 
> example is:
>
> IMHO it would be sane to use PKCE anywhere where a code is returned in 
> the URL and there isn't another proof of possession / token binding 
> mechanism in play.
>
> Joseph
>

---

From: Joseph Heenan <[email-masked]>
Date: Thu, 24 May 2018 19:52:44 +0100

Hi Denis,

This presentation is only describing one attack. Page 12 summarises it. The attack is not a full attack targeted against oauth, but it shows how a malicious network can steal any codes returned to the browser in the URL, even if the codes are always sent over TLS.

I was only responding to your assertion that PKCE is not required when TLS is in use. I believe that assertion was not right, as the above attack is against TLS enabled servers and PKCE would have made any stolen auth code useless, so PKCE still has value even when using TLS.

Thanks

Joseph

> On 23 May 2018, at 12:58, Denis <[email-masked]> wrote:
> 
> Hi Joseph,
> 
> I wrote:"It is quite hard to understand under which context(s) and conditions OAuth 2.0 could be safely used".
> 
> For each counter-measure, it would be useful to explain under which context(s) or under which assumptions 
> it should be used. 
> 
> Denis
> 
>> Hi Denis,
>> 
>>> On 22 May 2018, at 14:05, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>> https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf <https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf>
>>