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

[Torsten Lodderstedt]

I maintain a backlog of threats/issues to be covered. What does WPAD exactly mean?

> Am 26.08.2017 um 11:36 schrieb Nat Sakimura <nat at sakimura.org>:
> 
> Indeed. 
> 
> In the https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01, 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, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170826/a9fd4887/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2378 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170826/a9fd4887/attachment.p7s>