Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt

Hi Denis,

This presentation is only describing one attack. Page 12 summarises it. The attack is not a full attack targeted against oauth, but it shows how a malicious network can steal any codes returned to the browser in the URL, even if the codes are always sent over TLS.

I was only responding to your assertion that PKCE is not required when TLS is in use. I believe that assertion was not right, as the above attack is against TLS enabled servers and PKCE would have made any stolen auth code useless, so PKCE still has value even when using TLS.

Thanks

Joseph

> On 23 May 2018, at 12:58, Denis <denis.ietf@free.fr> wrote:
> 
> Hi Joseph,
> 
> Among these 39 slides, to which attack(s) are you referring ?
> 
> I wrote:"It is quite hard to understand under which context(s) and conditions OAuth 2.0 could be safely used".
> 
> For each counter-measure, it would be useful to explain under which context(s) or under which assumptions 
> it should be used. 
> 
> Denis
> 
>> Hi Denis,
>> 
>>> On 22 May 2018, at 14:05, Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
>>> In particular, the text states:
>>> 
>>>        "Clients shall use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts 
>>>         to inject (replay) authorization codes into the authorization response".
>>> 
>>> This is incorrect, since RFC7636 should be used when the authorization code is returned from the authorization endpoint
>>> within a communication path that is not protected by Transport Layer Security (TLS).
>>> 
>> That is not really the full story as we've seen attacks where URLs that you would expect to be protected by TLS are vulnerable; one example is:
>> 
>> https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf <https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf>
>> 
>> IMHO it would be sane to use PKCE anywhere where a code is returned in the URL and there isn't another proof of possession / token binding mechanism in play.
>> 
>> Joseph
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth