I’ve been thinking that we could, in some eventual rewrite of OAuth and its
kin, collapse the “state”, “nonce”, and “code_challenge” values all into a
single thing. They’re all serving similar purposes but being used differently.
There was even talk of replaying the “state” value at the token endpoint, just
like we do with PKCE “plain”. So why not just use them all together? Like so:
Client creates a value, we’ll call it the “request_tag” because I want
something that doesn’t sound like any of the existing values on its own and I
don’t care what it’s actually called in the long run. Client stores this for
later use.
Client sends a request to the AS front channel and hashes the request_tag in
that request, let’s call this “request_hash”. Client also sends a kind of
“request_hash_method” to tell the AS how it hashed things. [This functions just
like the code_challenge_method today.]
AS returns to the client front channel and includes the request_hash. [This
functions just like state today.] The client can verify this hash using its
stored tag.
- If AS is doing implicit OIDC, it adds the request_hash to the ID
Token here. [This functions just like nonce today.] The client can verify this
hash using its stored tag.
If the client is doing code flow, it now talks to the token endpoint and
includes the request_tag in its request. [This functions just like
code_verifier and the proposed include-the-state-in-token-request mitigation.]
The AS can verify this tag against its stored hash.
- If the AS is doing code OIDC, it adds the request_hash to the ID
token value here. [This functions just like nonce today.] The client can verify
this hash using its stored tag.
The token response can include the request_hash in its response JSON, because
why not.
Yes I realize this requires redoing a lot of plumbing, but if we get to this
point with the protocol I think this would be simpler than the functional
patchwork we’ve got going right now.
— Justin
> On Jul 27, 2016, at 8:21 AM, Brian Campbell <bcampb...@pingidentity.com>
> wrote:
>
> Yeah, in a Connect "code" only flow, the nonce is optional but if the
> client/RP sends and checks it, that should mitigate this.
>
> On Wed, Jul 27, 2016 at 1:19 AM, nov matake <mat...@gmail.com
> <mailto:mat...@gmail.com>> wrote:
> In Connect, if RP verifies nonce value in ID Token issued from Token
> Endpoint, code cut & paste attack can be mitigated in "code" flow, not in
> "code id_token", can't it?
>
> In pure OAuth2 senario, I also think PKCE would be the simplest solution.
>
> 2016-07-27 15:45 GMT+09:00 tors...@lodderstedt.net
> <mailto:tors...@lodderstedt.net> <tors...@lodderstedt.net
> <mailto:tors...@lodderstedt.net>>:
> +1
>
> I also think PKCE is currently the simplest way to protect OAuth clients from
> injection.
>
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails
> as clean, short chats.
>
>
>
> -------- Originalnachricht --------
> Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
> overHTTPS
> Von: William Denniss <wdenn...@google.com <mailto:wdenn...@google.com>>
> An: John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>
> Cc: Oauth Wrap Wg <oauth@ietf.org <mailto:oauth@ietf.org>>
>
>
> PKCE S256 was indeed designed to protect against eavesdropping of both the
> authorization request & response. It was originally created for native apps
> where URL leakage was deemed more likely (since it goes over inter-process
> communication channels), perhaps the practice should be expanded to all
> clients.
>
> On Tue, Jul 26, 2016 at 6:11 PM, <ve7...@ve7jtb.com
> <mailto:ve7...@ve7jtb.com>> wrote:
> PS Using PKCE S256 would prevent this attack on web server clients, as long
> as the client uses a different PKCE vale for each request. Even if the
> attacker can observe both the request and response, they would not have the
> code_verifyer and if replaying the code to the client the client will use the
> wrong verifier value to exchange the code and will get an error.
>
>
>
> That is probably the simplest mitigation against this for the code flow on
> web servers and native apps.
>
>
>
> I will think about it overnight.
>
>
>
> John B.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
>
>
> From: ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>
> Sent: July 26, 2016 9:04 PM
> To: Dick Hardt <mailto:dick.ha...@gmail.com>; Oauth Wrap Wg
> <mailto:oauth@ietf.org>
> Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
> overHTTPS
>
>
>
> I need to think about it a bit, however off the top of my head based on the
> attack described the code flow should still be safe if the code is truly
> single use. (Some implementations fudge that)
>
>
>
> If the attacker can stop the browser from delivering the code to the client
> then the client would be susceptible to the cut and paste attack for
> injecting the code back into the client.
>
>
>
> The OpenID Connect “code id_token” flow is not vulnerable to this if the
> client is properly validating the id_token.
>
>
>
> I suspect that this would work against the implicit flow if the JS is sending
> the code back to its web server via a GET.
>
> That I think we recommend against doing, or should.
>
>
>
> The Token binding proposals would stop a leaked code from being used, but not
> from being stolen in this attack.
>
>
>
> The attack against a confidential client would be the cut and paste one that
> we have identified. Currently the only mitigation we have is “code id_token”
> so the blog post at.
>
> http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/
> <http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/>
>
>
> I the most relevant current advice.
>
> The thing to add is that the code leaked in this way should not be repayable
> at the client
>
>
>
> I don’t think that native apps are vulnerable to this if they are using
> custom scheme redirects.
>
>
>
> I don’t know what the risk is if they are using loopback or claimed URI. It
> may be that a browser might leak them in the same way.
>
> That would need to be tested.
>
>
>
> John B.
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
>
>
> From: Dick Hardt <mailto:dick.ha...@gmail.com>
> Sent: July 26, 2016 8:15 PM
> To: Oauth Wrap Wg <mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
>
>
>
> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/
>
> <http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/>
>
>
> Access tokens included as a URL query parameter when accessing a resource are
> susceptible to this attack.
>
>
>
> Authorization codes are also visible. From what I know, we have not depended
> on the confidentiality of the authorization code.
>
>
>
> What are the best current practices that we can point people towards to
> ensure they are not susceptible to this attack?
>
>
>
> -- Dick
>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
> projects I am working on!
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> --
> nov matake
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <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
