Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Nov Matake]

Yes.

The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE implementation 
bug.
Yeah, all PKCE implementation MUST reject such requests, regardless it’s OAuth 
2.1 or 2.0.

(and it’s probably because of PKCE spec’s ambiguity..)

> 2020/05/20 1:13、Mike Jones のメール:
> 
> So it sounds me like the fix is to have servers reject PKCE requests with 
> incomplete parameter sets: requests that only contains one of code_challenge 
> and code_verified.  Will that eliminate the attack, Nov?
>  
>-- Mike
>  
> From: OAuth mailto:oauth-boun...@ietf.org>> On 
> Behalf Of Nov Matake
> Sent: Monday, May 18, 2020 11:50 PM
> To: Daniel Fett mailto:f...@danielfett.de>>
> Cc: oauth@ietf.org 
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>  
> Sure, feel free to add the senario to your post.
>  
> FYI:
> my OAuth2 server ruby gem rejects such token requests,
> https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28
>  
> 
> and Google also does the same.
> https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046 
> 
>  
> So I'm guessing such behavior is relatively rare-case, hopefully.
>  
> iPadから送信
> 
> 
> 2020/05/19 15:43、Daniel Fett  >のメール:
> 
>  
> Hi,
>  
> Am 19.05.20 um 04:55 schrieb Nov Matake:
> I thought the server MUST reject such token requests, but I couldn’t find 
> such definition in RFC7636...
>  
> > The client will send the code, along with a (now not matching) 
> > code_verifier to the server. The server will ignore the code_verifier (as 
> > it was not expected) and send back an access token and ID token to the 
> > client.
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack
>  
> 
>  
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack” would 
> be possible.
> I *think* that there is nothing preventing servers from sometimes using PKCE 
> and sometimes using Nonce. I assume that this is out of the scope of the 
> existing specifications.
> 
> I would be interested to hear how actual implementations handle this in 
> practice.
> 
>  
> Plus, with such AS behavior, CSRF protection using PKCE can also be bypassed 
> as below.
> 1. The attacker removes code_challenge from his/her own AuthZ Req, receives a 
> non-code_challenge-bound code, and sends it to the victim.
> 2. The client receives the attacker’s code from the victim, and sends it to 
> the AS w/ the valid code_verifier bound to the victim’s browser session.
> 3. The AS ignores the code_verifier and returns tokens.
>  
> If that’s the case, current OAuth 2.0 PKCE implementation can be weaker than 
> expected..
> Excellent point!
> 
> Would it be okay if I add that attack to the original post (with credits, of 
> course)?
> 
> -Daniel
> 
>  
> nov
> 
> 
> 2020/05/19 1:54、Daniel Fett  >のメール:
>  
> Hi all,
>  
> Talking to Torsten, we realized that providing a generic extension point here 
> is probably not a good idea. It is really hard to tell what protects you from 
> code injection and what does not, and people might come up with all sorts of 
> non-standard and potentially insecure solutions. 
>  
> Even just for PKCE vs. Nonce, it is not obvious if they provide the same 
> level of protection. In an attempt to answer this question, I tried to come 
> up with a more systematic analysis of "PKCE vs Nonce". I wrote up my results 
> here:
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ 
> 
> 
> Although this is not a formal analysis, I hope that I have covered all 
> interesting cases. Please review the text and let me know if I have missed 
> something or if there are any mistakes.
> 
> The main results are:
> In terms of protection against CSRF and code misuse, PKCE and Nonce provide 
> similar levels of security, with a slight advantage for PKCE.
> In practice, a circumvention of both mechanisms, however, is possible if an 
> AS allows a client to choose between PKCE and Nonce and the client makes use 
> of this freedom. I propose to call this attack the Nonce/PKCE Sidestep 
> Attack. → Please review the attack description in the analysis.
> To avoid the Nonce/PKCE Sidestep Attack, clients must not switch between 
> using only PKCE and only Nonce (but may use both in parallel, or switch 
> between using only PKCE and PKCE+Nonce). Authorization servers must enforce 
> PKCE unless they know that the client uses Nonce for all of its flows (and 
> checks the Nonce value). The presence of a nonce parameter in the 
> authorization request is not sufficient to det

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Mike Jones]

So it sounds me like the fix is to have servers reject PKCE requests with 
incomplete parameter sets: requests that only contains one of code_challenge 
and code_verified.  Will that eliminate the attack, Nov?

   -- Mike

From: OAuth  On Behalf Of Nov Matake
Sent: Monday, May 18, 2020 11:50 PM
To: Daniel Fett 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Sure, feel free to add the senario to your post.

FYI:
my OAuth2 server ruby gem rejects such token requests,
https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28
and Google also does the same.
https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046

So I'm guessing such behavior is relatively rare-case, hopefully.

iPadから送信


2020/05/19 15:43、Daniel Fett 
mailto:f...@danielfett.de>>のメール:

Hi,

Am 19.05.20 um 04:55 schrieb Nov Matake:
I thought the server MUST reject such token requests, but I couldn’t find such 
definition in RFC7636...

> The client will send the code, along with a (now not matching) code_verifier 
> to the server. The server will ignore the code_verifier (as it was not 
> expected) and send back an access token and ID token to the client.
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack

If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack” would be 
possible.

I *think* that there is nothing preventing servers from sometimes using PKCE 
and sometimes using Nonce. I assume that this is out of the scope of the 
existing specifications.

I would be interested to hear how actual implementations handle this in 
practice.

Plus, with such AS behavior, CSRF protection using PKCE can also be bypassed as 
below.
1. The attacker removes code_challenge from his/her own AuthZ Req, receives a 
non-code_challenge-bound code, and sends it to the victim.
2. The client receives the attacker’s code from the victim, and sends it to the 
AS w/ the valid code_verifier bound to the victim’s browser session.
3. The AS ignores the code_verifier and returns tokens.

If that’s the case, current OAuth 2.0 PKCE implementation can be weaker than 
expected..

Excellent point!

Would it be okay if I add that attack to the original post (with credits, of 
course)?

-Daniel

nov


2020/05/19 1:54、Daniel Fett mailto:f...@danielfett.de>>のメール:

Hi all,

Talking to Torsten, we realized that providing a generic extension point here 
is probably not a good idea. It is really hard to tell what protects you from 
code injection and what does not, and people might come up with all sorts of 
non-standard and potentially insecure solutions.

Even just for PKCE vs. Nonce, it is not obvious if they provide the same level 
of protection. In an attempt to answer this question, I tried to come up with a 
more systematic analysis of "PKCE vs Nonce". I wrote up my results here:
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

Although this is not a formal analysis, I hope that I have covered all 
interesting cases. Please review the text and let me know if I have missed 
something or if there are any mistakes.

The main results are:

  1.  In terms of protection against CSRF and code misuse, PKCE and Nonce 
provide similar levels of security, with a slight advantage for PKCE.
  2.  In practice, a circumvention of both mechanisms, however, is possible if 
an AS allows a client to choose between PKCE and Nonce and the client makes use 
of this freedom. I propose to call this attack the Nonce/PKCE Sidestep Attack. 
→ Please review the attack description in the analysis.
  3.  To avoid the Nonce/PKCE Sidestep Attack, clients must not switch between 
using only PKCE and only Nonce (but may use both in parallel, or switch between 
using only PKCE and PKCE+Nonce). Authorization servers must enforce PKCE unless 
they know that the client uses Nonce for all of its flows (and checks the Nonce 
value). The presence of a nonce parameter in the authorization request is not 
sufficient to determine if a client actually checks the nonce claim in the ID 
token.
As you can see, already having two more-or-less well-understood mechanisms is 
hard enough to wrap your head around from a security standpoint. We should 
therefore make PKCE the default and Nonce an option for backwards compatibility.
To this end, I would like to propose the follwing strawman, based on Torsten's 
and Aaron's suggestions:
An AS MUST reject requests without a code_challenge from public
clients, and MUST reject such requests from other clients unless there
is reasonable assurance that the client mitigates authorization code
injection using the OpenID Connect Nonce mechanism and that this
mitigation is used for all interactions with the client. See section
9.7 for details.

Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. The use of the
`code_ch

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Filip Skokan]

This is a RE: to yesterday's interim meeting discussion, largely related to
the first rollout step where we want to constrain refresh tokens but leave
protected resource access intact.

I'll start off with a case that I hope we can agree is absolutely necessary
for DPoP to solve - that is constraining refresh tokens for browser based
applications. Now, *do we see this as a secondary objective? I think it
should be on par with access token constraining.* SPAs using code flow and
having access to refresh tokens as means against the continuous browser
efforts to cut down on storage access is a real case servers will be
eventually forced to adopt.

Since rollout for DPoP needs to begin with the AS and Client supporting it
(regardless what order i guess) there are going to be instances where the
RS will be supporting both Bearer and DPoP at the same time.

As discussed yesterday, the client shouldn't know/care and change its
behaviour when it comes to using access tokens.

*But what is the client behaviour we take for standard?* Because I can see
two conflicting implementations in the wild

   1. The client echoes the token_type it received from the token endpoint
   as the authorization scheme
  - (optionally) throws on unrecognized token type values
   2. The client uses Bearer as a fixed authorization scheme and ignores
   the token_type it received

#2 is an implementation which I suspect has no idea about DPoP, but if
extended to send DPoP headers (through various mechanism - library
extensions or even manipulating the `XMLHttpRequest` prototype) will

   - 🎉 get the benefit of having its Refresh Tokens bound
   - 🎉 most likely continue to work with RSs that only support Bearer
   - ❌ will cease to work with RSs that will adopt support for DPoP because
   it'll be using the wrong scheme, that is unless (🎉) RSs supporting DPoP
   choose to suspend the requirement to use the new scheme and instead depend
   on the presence of `cnf.jkt` as means to trigger DPoP validation. *Q: is
   that an acceptable thing to do?*

Arguably, client behaviour #1 is what a client should be using if it
supports other schemes besides Bearer. But it may as well be the behaviour
of a client that has no clue about DPoP, right? Again, such client can be
made to support DPoP in a SPA through manipulation of the XMLHttpRequest
prototype, in which case the developer needs to do the same for
the protected resource calls. But at this point the developer has to know
which RS to apply DPoP to and which not - ergo - which to send Bearer vs.
DPoP scheme to? The developer will have to write a whitelist of resource
servers anyway - and there we get to the point where client has information
and functionality that it shouldn't /need to/ have.

Its great that we have token_type, authorization header schemes, etc...,
but we don't seem have a well defined (or at least followed) behaviour for
our clients around handling the token_type response values and their usage.

A developer has to resolve to navigate this monkey course unless the RS
definition on the AS is aware of the fact that the RS does support DPoP, so
that the issued token_type is always correct for the RS. So, *should we
make that a recommended way of 'indicating' when to issue Bearer vs DPoP
access tokens?*

What else could we do that doesn't give more decision making to the clients
so that the very first step - *Refresh Tokens get constrained* - is achieved*
but Protected Resource access is unaffected?*

Note that this was not "a thing" for mTLS because it continues to use the
Bearer scheme (for better or worse) and it completely omits possible
continuous rollout or discussing what are the signals the RS must use to
require mTLS to be used), same for the abandoned OAuth 2.0 Token Binding
draft (also continued to use the Bearer scheme).

I suspect we have just this opportunity to fix token types and their use
and if we can't, we'll have to resolve to abandon that extension point as
one that doesn't support continued rollout of real sender constraining
mechanism (e.g. http signatures in the future) and just continue using
Bearer because in the end, given that RSs could be relying on the presence
of the cnf claim to figure out the token's constraining mechanism, would
that be such a bad thing?

Put it the other way around. By introducing Bearer scheme, do we actually
gain anything of value that can't be gained through other means?

Note that this message didn't start with the goal of questioning the new
scheme use, it just sort of landed there... My pedantic nature would love
to see the new scheme and token_type extension point used as it was meant
to be but I also recognize the many issues it brings that could be
sidestepped by not introducing it in the first place, all without losing
capabilities.

Previous material on the topic

   - https://github.com/danielfett/draft-dpop/issues/41, decision to break
   backwards compatibility amongst the authors
   - ML
   

[OAUTH-WG] JAR: JWT typ

[Dominick Baier]

Hi,

This has been brought up before - but no response.

Either I can’t find it - or it is missing. But is the setting the JWT typ
explicitly mentioned somewhere?

I think it should to prevent cross JWT confusion.

Thanks
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18

[Rifaat Shekh-Yusef]

Hi Filip,

I have uploaded the slides to the materials page here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop


Regards,
 Rifaat


On Tue, May 19, 2020 at 5:39 AM Filip Skokan  wrote:

> Hello Brian,
>
> can you share the slide deck from yesterday so that we may continue
> the discussion on the mentioned open questions here on the list?
>
> Thank you,
>
> Best,
> *Filip*
>
>
> On Wed, 13 May 2020 at 20:43, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Just wanted to note that there is a newer -01 revision of the document on
>> the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>>
>> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
>> wrote:
>>
>>> The Web Authorization Protocol (oauth) Working Group will hold
>>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00
>>> Europe/Vienna (16:00 to 17:00 UTC).
>>>
>>> Agenda:
>>> DPOP
>>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>>
>>> Information about remote participation:
>>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>>
>>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>>
>>> ___
>>> IETF-Announce mailing list
>>> ietf-annou...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>
>>
>> *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.*
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18

[Filip Skokan]

Hello Brian,

can you share the slide deck from yesterday so that we may continue
the discussion on the mentioned open questions here on the list?

Thank you,

Best,
*Filip*


On Wed, 13 May 2020 at 20:43, Brian Campbell  wrote:

> Just wanted to note that there is a newer -01 revision of the document on
> the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>
> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
> wrote:
>
>> The Web Authorization Protocol (oauth) Working Group will hold
>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna
>> (16:00 to 17:00 UTC).
>>
>> Agenda:
>> DPOP
>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>
>> Information about remote participation:
>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>
>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>
> *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.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth