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

[Denis]

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 > 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

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

Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant

[Daniel Fett]

Thanks Brian! Pedram and I are still not completely sure whether we
fully understand the setting here...

Am 15.05.18 um 00:22 schrieb Brian Campbell:
> Typically when an access token is issued via the implicit grant
> directly from the authorization endpoint, it is for a client that is
> running as script in the user-agent. The AS binds the access token to
> the referred token binding, which would be the token binding between
> the user-agent (where the client is) and the protected resource. 
>
> It does mean that a hybrid style client couldn't pass the access token
> from its script front-end in the user-agent to its server backed
> (well, it could pass it but the server side couldn't use it because of
> the binding).

Section 3.1 says "For access tokens returned directly from the
authorization endpoint,
   such as with the implicit grant defined in Section 4.2 of OAuth 2.0
   [RFC6749], the Token Binding ID of the client's TLS channel to the
   protected resource is sent with the authorization request as the
   Referred Token Binding ID in the "Sec-Token-Binding" header, and is
   used to Token Bind the access token."


Just to clarify: This implies that there must be an HTTP(S) request from
the browser to the protected resource which then gets redirected to the
authorization endpoint. Is that correct?

- Daniel


-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth