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

From: [email-masked]
Date: Fri, 09 Nov 2018 00:32:56 -0800

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-09.txt
	Pages           : 35
	Date            : 2018-11-09

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-09
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09

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

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: Fri, 9 Nov 2018 10:42:19 +0100

Hi all, 

the new revision incorporates the recommendation to use more secure grant types instead of implicit we agreed to add during the WG session on Monday. It also has more text around justifications for our recommendation. Especially, there is a new section 3.6 on access token injection. 

I also posted about this topic on LinkedIn (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/) and Medium (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926)

kind regards,
Torsten. 

> Am 09.11.2018 um 09:32 schrieb [email-masked]:
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Joseph Heenan <[email-masked]>
Date: Fri, 9 Nov 2018 17:27:14 +0000

Hi Torsten,

A few comments having just read this afresh:

2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given it appears to be permitted?

I find it a little hard to understand exactly what "avoid any redirects or forwards which can be parameterized by URI query parameters” means (particularly as it comes directly after a paragraph on the redirect_uri and I initially thought it was talking about that. Perhaps something along the lines of “avoid forwarding the user’s browser to a value from a uri query parameter” might be clearer.

" Clients SHALL ensure to only process “ could just be written ‘Client SHALL only process” I think.

2.1.1:

"Authorization servers SHALL consider the”  - is ’SHALL consider’ different to ’SHOULD’? Or does it mean something like “SHALL implement at least one countermeasure from <…>”.

3.2.4:

This says "Authorization codes SHOULD be invalidated by the AS after their first use at the token endpoint”.

https://tools.ietf.org/html/rfc6749#section-10.5 says:

"Authorization codes MUST be short lived and single-use.”.

Does this "MUST be single-use” not effectively already require the code is invalidated after first use? If so why downgrade this to a “SHOULD”?

Cheers,

Joseph

> On 9 Nov 2018, at 09:42, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi all, 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 13 Nov 2018 10:07:58 +0100

Hi Joseph, 

> Am 09.11.2018 um 18:27 schrieb Joseph Heenan <[email-masked]>:
> 
> Hi Torsten,
> 

SHALL is equivalent to MUST, changed it into SHOULD for the reason you gave. 

I also changed other occurrences of SHALL to MUST as it seems people are more familiar with this term. 

> I find it a little hard to understand exactly what "avoid any redirects or forwards which can be parameterized by URI query parameters” means (particularly as it comes directly after a paragraph on…

Incorporated your text.

> " Clients SHALL ensure to only process “ could just be written ‘Client SHALL only process” I think.

That’s indeed simpler :-)

> "Authorization servers SHALL consider the”  - is ’SHALL consider’ different to ’SHOULD’? Or does it mean something like “SHALL implement at least one countermeasure from <…>”.

That wouldn't work since the text in RFC6819 gives implementors multiple mostly complementary measures. But the direction of your proposal makes sense, so I added the requirement for the AS to bind every code to a client (already stated in RFC6749) and to authenticate the client. Thanks to Dynamic Registration and PKCE this is now feasible and it seems to be the most effective mitigation to me. I also made the reference to RFC 6819 a SHOULD.

> "Authorization codes MUST be short lived and single-use.”.

Thanks for pointing this out! 

> Does this "MUST be single-use” not effectively already require the code is invalidated after first use? If so why downgrade this to a “SHOULD”?

You are right. My feeling is single use can turn out to be a really hard to implement requirement. That’s why I would like to relax it. Given we now have a stronger requirement on client authentication that should be fine. 

Question to the list: what is your implementation experience regarding one time use authorization codes?

Thanks for your feedback!

kind regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 13 Nov 2018 08:29:18 -0800

> > Does this "MUST be single-use” not effectively already require the code
> is invalidated after first use? If so why downgrade this to a “SHOULD”?
>
> You are right. My feeling is single use can turn out to be a really hard
> to implement requirement. That’s why I would like to relax it. Given we now
> have a stronger requirement on client authentication that should be fine.
>

There's a bit of discussion about this on this ticket in the Connect WG:
https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use
FWIW.

I do think that in some systems or architectures it can be difficult to
strictly guarantee that a code can only be used once. And it'd be better
for specs to come to terms with that rather than being unrealistically
strict about it.

We have an AS implementation that does do strict one-time use of the code.
But it comes at a cost including some difficulties with resiliency for any
particular code. Not to mention some troubleshooting and support
issues/questions about it. We haven't gotten to the point of changing
anything but have, from time to time, considered changing the
implementation approach for code to something that would appear to behave
the same but might not 100% guarantee a code could only be used once.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Daniel Fett <[email-masked]>
Date: Wed, 14 Nov 2018 09:26:31 +0100

Am 13.11.18 um 17:29 schrieb Brian Campbell:
>
>     > Does this "MUST be single-use” not effectively already require
>     the code is invalidated after first use? If so why downgrade this
>     to a “SHOULD”?
>
>     You are right. My feeling is single use can turn out to be a
>     really hard to implement requirement. That’s why I would like to
>     relax it. Given we now have a stronger requirement on client
>     authentication that should be fine.
>
>     Question to the list: what is your implementation experience
>     regarding one time use authorization codes?
>
>
> I do think that in some systems or architectures it can be difficult
> to strictly guarantee that a code can only be used once. And it'd be
> better for specs to come to terms with that rather than being
> unrealistically strict about it.
>
> We have an AS implementation that does do strict one-time use of the
> code. But it comes at a cost including some difficulties with
> resiliency for any particular code. Not to mention some
> troubleshooting and support issues/questions about it. We haven't
> gotten to the point of changing anything but have, from time to time,
> considered changing the implementation approach for code to something
> that would appear to behave the same but might not 100% guarantee a
> code could only be used once.

>From a security point of view: What do we want to achieve?

I assume that the original text in 6749 tried to ensure that even if an
authz code leaks to an attacker, the attacker (or a client on behalf of
the attacker) cannot obtain an access token using this code.

To capture this in a (very strong) security property, we could say: Even
if the whole authz response leaks to an attacker, including all browser
cookies, the attacker must not be able to obtain a token (or make the
client obtain a token) with it (after the legitimate user used the code).

With the current state of the draft, we can achieve this: We have client
authentication and injection prevention (read: PKCE) to prevent any
direct use of the code or use of the code in a new session with the
client. We further require that each authz response is accepted only
once by a client, in particular, we suggest to use a single-use "state"
for this purpose.

TL;DR: With single-use state and client authentication we do not gain
security from single-use codes.

I would be fine with relaxing the requirement on single-use codes in 6749.

-Daniel

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Nov 2018 10:48:32 +0100

Hi,

here is the respective text proposal for section 2.1. (Note: we also refactored the text in order to disentangle CSRF/replay and mix-up detection).

----
Clients MUST prevent CSRF and ensure that each authorization response is only accepted once. One-time use CSRF tokens carried in the state parameter, which are securely bound to the user agent, SHOULD be used for that purpose.

In order to prevent mix-up attacks, clients MUST only process redirect responses of the OAuth authorization server they send the respective request to and from the same user agent this authorization request was initiated with. Clients MUST memorize which authorization server they sent an authorization request to and bind this information to the user agent and ensure any sub-sequent messages are sent to the same authorization server. Clients SHOULD use AS-specific redirect URIs as a means to identify the AS a particular response came from.
----

kind regards,
Torsten. 

> Am 14.11.2018 um 09:26 schrieb Daniel Fett <[email-masked]>:
> 
>> There's a bit of discussion about this on this ticket in the Connect WG: https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use FWIW.
>> 
>> I do think that in some systems or architectures it can be difficult to strictly guarantee that a code can only be used once. And it'd be better for specs to come to terms with that rather than being unrealistically strict about it.
>> 
>> We have an AS implementation that does do strict one-time use of the code. But it comes at a cost including some difficulties with resiliency for any particular code. Not to mention some troubleshooting and support issues/questions about it. We haven't gotten to the point of changing anything but have, from time to time, considered changing the implementation approach for code to something that would appear to behave the same but might not 100% guarantee a code could only be used once. 
> I assume that the original text in 6749 tried to ensure that even if an authz code leaks to an attacker, the attacker (or a client on behalf of the attacker) cannot obtain an access token using this code.
> 
> To capture this in a (very strong) security property, we could say: Even if the whole authz response leaks to an attacker, including all browser cookies, the attacker must not be able to obtain a token (or make the client obtain a token) with it (after the legitimate user used the code).
> 
> With the current state of the draft, we can achieve this: We have client authentication and injection prevention (read: PKCE) to prevent any direct use of the code or use of the code in a new session with the client. We further require that each authz response is accepted only once by a client, in particular, we suggest to use a single-use "state" for this purpose.
> 
> TL;DR: With single-use state and client authentication we do not gain security from single-use codes.
>