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

[Nat Sakimura]

Indeed. 

In the https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01
[1], it might be a good idea to add WPAD attack to one of the potential
ways for the code leakage. Is there an issue tracker for the doc? 

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

On 2017-08-26 17:42, Torsten Lodderstedt wrote: 

> You may just refer to https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01 [1], in particular section 3.1 
> 
> Am 26.08.2017 um 10:14 schrieb Nat Sakimura <nat at sakimura.org>:
> 
> 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 [2]
 

Links:
------
[1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01
[2] http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170826/e40c79e5/attachment-0001.html>