OAuth Profile should mandate RFC7636 (PKCE) for code flow

[Nat Sakimura]

There is going to be a demonstration of Browser TLS intercept at Blackhat today. (WPAD Attack).

There is a news article as well: New attack bypasses HTTPS protection on Macs, Windows, and Linux

We knew of the possibility but not it has become the reality.

Given the situation, mandating RFC7636 for all the Clients (including confidential clients) for code flow seems prudent.

[Nat Sakimura]

Now it is mandated.

We should make note of the relationship between PKCE and WPAD somewhere (not in the spec itself.)

[Nat Sakimura]

PKCE or Hybrid Flow is mandated in Part 1. This is to avoid the code injection attack. The explanation of the attack is as follows.

Environment

• RFC6749 code grant with a confidential client (e.g. web server client)
• The victim's front channel communication is somehow compromised (e.g., through WPAD attack, server log, etc.)
• The client is implementing RFC6749 properly with XSRF protection etc.

Attack Scenario

1. The victim and the attacker are using the same web client.
2. The attacker gets the victim's code somehow, e.g., WPAD attack.
3. The attacker inserts the code into the session he started.
4. The client sends the code with its client secret to the token endpoint.
5. The token endpoint verifies the client secret and that the code was issued to the client.
6. The token endpoint sends the access token back to the client.
7. The client accesses the victim's protected resource successfully and returns it to the attacker. SUCCESS.

Mitigation

Use PKCE with S256. By doing so, the above scenario changes to:

1. The victim and the attacker are using the same web client.
2. The attacker gets the victim's code somehow, e.g., WPAD attack.
3. The attacker inserts the code into the session he started.
4. The client sends the code with its client secret and the code verifier to the token endpoint.
5. The token endpoint verifies the client secret and that the code was issued to the client. 5a. The token endpoint verifies the code verifier matches the one tied to the code. This fails.
6. The token endpoint sends the error back to the client.
7. The attack FAILED.

[Joseph Heenan]

Kudo san at Authlete asked me about this ticket and how it was resolved in part 1.

I looked and can't figure out how it was resolved - part 1 does not seem to require PKCE for confidential clients, it doesn't require hybrid flow, and I can't spot any other mitigation in part1. Did we lose the fix in one of the other edits?

[Joseph Heenan]

Reopening to make sure we've addressed/do address it.

[Joseph Heenan]

This was discussed on today's call - it was felt that we should mitigate against this attack by requiring PKCE for confidential clients in part 1, but this should be done in such a way that it doesn't mean it's required in part 2.

[Joseph Heenan]

I've created a pull request here: https://bitbucket.org/openid/fapi/pull-requests/56/require-pkce-for-confidential-clients

One point I wasn't 100% sure on - should part2 public clients use PKCE or not?

[Nat Sakimura]

Require PKCE for part 1 confidential clients

This should mitigate some potential attacks against the code flow in confidential clients as discussed in #11. PKCE is already required for public clients.

Update part 2 so that confidential clients don't inherit this requirement, as part2 confidential clients should already be immune to the potential attacks due to the use of hybrid flow / signed request objects / token binding.

I think we did previously require PKCE for confidential clients and this was accidentally removed as part of commit 8d420fd67b79a1b72c29fac4ea38e6db2b0ff61d

closes #11

→ <<cset 125197d3171c>>