[Openid-specs-fapi] The reasons behind requiring PKCE for confidential clients?

[Nat Sakimura]

Thanks, Torsten.

Right. So an attack scenario I guess is a privilege escalation using 
code injection.

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.

I will add the above explanation to the ticket #11. The ticket itself 
was saying that we should document it, which we did not :-(


For Read&Write, we are mandating hybrid flow. However, for the Read 
only, we are not.
Thus, for the Read Only (Part 1), we should still mandate the use of 
PKCE.

That's why it is saying

* shall support [RFC7636] or the mechanisms defined in Financial API - 
Part 2;


---
Nat Sakimura
Research Fellow, Nomura Research Institute
Chairman of the Board, OpenID Foundation

On 2017-08-25 18:15, Torsten Lodderstedt wrote:
> Hi Nat,
> 
> just guessing - the new OAuth security BCP recommends use of PKCE for
> detecting/preventing code injection attacks. That might be the reason
> for adding the requirement to the FAPI profile.
> 
> I know the hybrid flow („code id_token“) is an alternative
> countermeasure in the OIDC space. So my question is: will FAPI allow
> use of pure authz code flow? Then recommending PKCE for code injection
> makes a lot of sense.
> 
> best regards,
> Torsten.
> 
>> Am 24.08.2017 um 19:43 schrieb Nat Sakimura via Openid-specs-fapi 
>> <openid-specs-fapi at lists.openid.net>:
>> 
>> Hi.
>> 
>> Current text reads like it is requiring PKCE support even for the 
>> confidential client.
>> Do you remember the reason for it? Or is it just an editorial error?
>> 
>> John may have mentioned a potential attack that PKCE could help but I 
>> do not quite remember the details....
>> 
>> If it is an error, then we should fix it for the final.
>> 
>> Best,
>> --
>> Nat Sakimura
>> Research Fellow, Nomura Research Institute
>> Chairman of the Board, OpenID Foundation
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi