Re: [OAUTH-WG] on PKCE for CSRF prevention instead of state parameter

[Daniel Fett <[e-mail]>]

Hi Filip,

This is an important point that you raise here. In an ideal world, the
client would be able to learn whether the AS supports PKCE or not.

My proposal for a normative text would be this:

---
If PKCE [@RFC7636] is used by the client and the authorization server
supports PKCE, clients MAY opt to not use state for protection against
Cross-Site Request Forgery, as such protection is provided by PKCE. In
this case, state MAY be used again for its original purpose, namely
transporting data about the application state of the client.

It is important to note that:

 * If state is used for carrying application state, and integrity of its
contents is a concern, clients MUST protect state against tampering and
swapping. This can be achieved by binding the contents of state to the
browser session and/or signed/encrypted state values
[@I-D.bradley-oauth-jwt-encoded-state].
 * There is no defined mechanism for clients to detect whether an
authorization server supports PKCE or not. Clients that use PKCE despite
the authorization server not supporting it will not receive any
indication of the lack of support for PKCE. If the authorization server
does not support PKCE, state MUST be used for CSRF protection.
---

- Daniel


Am 11.04.19 um 13:35 schrieb Filip Skokan:
> In Prague we've seen and talked about this point from Torsten's deck
> <https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-security-topics-00>
>  
>
>     Use PKCE for CSRF prevention instead of state parameter
>
>       * PKCE is mandatory now and can fulfill this additional task
>       * Simplifies recommendations and makes state available again for
>         original purpose (carry client transaction data)
>
>
> While PKCE is now the suggested countermeasure to some attacks and is
> to be used by Clients it's not yet mandatory to be implemented by the
> AS and the client has no way of knowing for sure if it's implemented
> (due to how PKCE is defined as backwards compatible to clients when AS
> is missing its support).
>
> Since at no point in time does the client receive anything from the AS
> suggesting that PKCE is in effect, is this a wise recommendation to
> make in the current form? Some might interpret this as if they don't
> need state to carry any client transaction data they might as well
> just use PKCE and omit state altogether altho the server does not
> support PKCE.
>  
> S pozdravem,
> *Filip Skokan*
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth