Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

[Neil Madden]

> On 6 Nov 2020, at 22:02, Brian Campbell  wrote:
> 
> 
> 
> 
>> On Tue, May 5, 2020 at 2:52 PM Brian Campbell  
>> wrote:
>> 
>>> 
>>> 9.1:
>>> This would be a good place to mention BREACH as an example of how a DPoP 
>>> proof (and AT) might leak, despite only being sent over a direct HTTPS 
>>> channel. Note though that adding a random jti is an effective defence 
>>> against this even if the server doesn’t check it.
>> 
>> Thanks for that note as a good reason to keep jti even if the requirements 
>> on checking it are relaxed. 
> 
> In trying to add some text that makes such mention I realized (again) that I 
> don't have a very good understanding of BREACH. With a bit of reading of the 
> overview and paper at http://breachattack.com/ it seems that BREACH is 
> applicable to attacking compression for leaking sensitive information in HTTP 
> responses. Whereas a DPoP proof is only defined to be sent in an HTTP 
> request. And ATs are only in a response once and then used in requests. 
> Perhaps it's a limitation of my own imagination or intellect but I don't see 
> how BREACH is relevant here. If you can explain it to me "for dummies" style 
> or better yet propose some text, we can certainly look at adding it. Short of 
> that though, I'm not equipped to write anything legitimate about it and will 
> just omit any such mention.  
>  

BREACH was primarily attacking web browser clients, which do indeed usually 
only allow compression in responses. But OAuth is used for other API clients 
and compression of requests, although by no means widespread, is sometimes 
used. For example [1] where it’s recommended that clients use compression for 
both requests and responses, and a Google search shows various other cases. 

So in these cases a BREACH-like attack could be used to recover a bearer token 
in those requests. However, on reflection it’s not a hugely likely attack 
vector for a number of reasons:

1. HTTP compression only compresses the request entity, not the headers or 
request URI. So this would only be a risk when sending the access token in the 
body as in [2]. And it’s not a risk for a DPoP proof as that’s always in a 
header. 

2. In order for the attack to work the attacker needs to be able to influence 
some part of the requests, which is generally a bit harder than influencing 
responses from a server. The most likely vector IMO would be XSS, in which case 
there are likely to be more direct ways to steal the token. 

I wouldn’t want to say that this is never a risk, but it perhaps doesn’t rise 
to the level that it’s worth spelling out. 

[1]: 
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_compression.htm

[2]: https://tools.ietf.org/html/rfc6750#section-2.2

— Neil
-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

[Brian Campbell]

On Tue, May 5, 2020 at 2:52 PM Brian Campbell 
wrote:

>
>
>> 9.1:
>> This would be a good place to mention BREACH as an example of how a DPoP
>> proof (and AT) might leak, despite only being sent over a direct HTTPS
>> channel. Note though that adding a random jti is an effective defence
>> against this even if the server doesn’t check it.
>>
>
> Thanks for that note as a good reason to keep jti even if the requirements
> on checking it are relaxed.
>

In trying to add some text that makes such mention I realized (again) that
I don't have a very good understanding of BREACH. With a bit of reading of
the overview and paper at http://breachattack.com/ it seems that BREACH is
applicable to attacking compression for leaking sensitive information in
HTTP responses. Whereas a DPoP proof is only defined to be sent in an HTTP
request. And ATs are only in a response once and then used in requests.
Perhaps it's a limitation of my own imagination or intellect but I don't
see how BREACH is relevant here. If you can explain it to me "for dummies"
style or better yet propose some text, we can certainly look at adding it.
Short of that though, I'm not equipped to write anything legitimate about
it and will just omit any such mention.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

[Brian Campbell]

Thanks Neil.  I do appreciate your review and feedback (even if it takes me
a nontrivial amount of time to reply). I've attempted to respond to things
inline below.

On Mon, May 4, 2020 at 5:51 AM Neil Madden 
wrote:

> Some review comments:
>
> Section 1:
> I think terms like “relatively simple” are subjective and should be left
> out. I don’t think the machinery of JWS signature verification (and
> associated security issues) is necessarily simple at all.
>

That's fair. It was subjectively true to me as I wrote it but I take your
point.


>
> “stronger methods … such as [RFC8705] or [token binding]”
> I would dispute that these are actually stronger methods in the context of
> an SPA, putting aside the usability issues. As has been discussed before,
> TLS is a shared context in a web browser - the same TLS connection will be
> reused for all requests, regardless of the origin they come from. The
> situation is better for cert-bound ATs because you need the CORS
> Access-Control-Allow-Credentials to be set to make a cross-origin request
> with a client certificate, but as I describe below there are also other
> attacks against TLS that don’t apply to DPoP (and would be a good reason to
> adopt DPoP).
>

The “stronger methods" was preceded with "potentially" in hopes of toning
down the strength of the statement about strength somewhat. But yes it
could be reworded to take away any comparative language.



>
> I think this section should also mention mobile use-cases, as IMO the case
> for DPoP is much stronger in those environments. Many of our customers are
> looking for a PoP solution for mobile and have rejected mTLS for various
> reasons (which have previously been discussed on this list, e.g.
> incompatible middleboxes). DPoP is potentially really nice for these
> environments as they often have a nice secure element available to store
> the private key and are much less susceptible to XSS and so on, but may
> still worry about a malicious RS.
>

Agree that mobile/native use-cases deserve a mention.


> IoT applications may also be a use-case as requests are often relayed over
> multiple hops and different transport protocols, so TLS cannot be used for
> end-to-end security (although in that case you probably want a full request
> signing approach).
>
> Section 2:
> I think the “Main Objective” in section 2 could be improved. The vast
> majority of the mechanisms described in the draft do nothing to address
> this main objective, and are in fact intended to prevent DPoP proof replay
> which is relegated to a “secondary objective” in section 9. Only the “htu”
> claim really has anything at all to do with the main objective. I think
> some of these secondary objectives, especially the anti-replay one, should
> be brought forward to section 2 to better justify what follows.
>
> It has been mentioned several times on this list that an audience
> restriction in the AT would also solve this main objective, and the
> response has generally been that adding audience restrictions is hard in
> practice - e.g. due to the AS not knowing where the AT is intended to be
> used. I think it would be useful to explicitly add some discussion of this,
> and perhaps a comparison with things like resource indicators that
> presumably could solve at least some of the issues with audience
> restrictions.
>
> I think there *are* significant advantages of DPoP that address real-world
> attacks that cannot be solved in any other way currently. For example, I
> was reading [1] recently about CRIME/BREACH attacks against CSRF tokens and
> it occurred to me that exactly the same kind of attack is a real threat to
> access tokens in a browser and that DPoP is an effective mitigation against
> it. To summarise, these attacks exploit vulnerabilities in TLS when
> combined with compression (either in TLS itself or HTTP compression) and
> can allow an attacker to steal bearer tokens or cookies after observing
> enough requests with the same token (and being able to influence some other
> content in the same request/response). One recommended mitigation is to
> randomize tokens so that they are different on every request, which thwarts
> the attack. Although DPoP doesn’t directly randomize the AT the AT is
> useless without a DPoP proof and a unique “jti” claim ensures that the DPoP
> proof is randomized and so not recoverable through this attack. Given that
> BREACH is largely unmitigated in practice, due to the usefulness of
> compression, adding a description of this attack to the justification would
> IMO significantly improve the rationale for DPoP.
>

Daniel is way way way more adept than I when it comes to threat and
attacker modeling. He also penned the original text of the draft, much of
which is still present. In trying not to step on his toes and also be
mindful of the disparity in our competency, I'm really hoping that he can
do an overhaul of the threat model, objectives, security considerations,
etc. to address this and 

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

[Neil Madden]

Some review comments:

Section 1:
I think terms like “relatively simple” are subjective and should be left out. I 
don’t think the machinery of JWS signature verification (and associated 
security issues) is necessarily simple at all.

“stronger methods … such as [RFC8705] or [token binding]”
I would dispute that these are actually stronger methods in the context of an 
SPA, putting aside the usability issues. As has been discussed before, TLS is a 
shared context in a web browser - the same TLS connection will be reused for 
all requests, regardless of the origin they come from. The situation is better 
for cert-bound ATs because you need the CORS Access-Control-Allow-Credentials 
to be set to make a cross-origin request with a client certificate, but as I 
describe below there are also other attacks against TLS that don’t apply to 
DPoP (and would be a good reason to adopt DPoP). 

I think this section should also mention mobile use-cases, as IMO the case for 
DPoP is much stronger in those environments. Many of our customers are looking 
for a PoP solution for mobile and have rejected mTLS for various reasons (which 
have previously been discussed on this list, e.g. incompatible middleboxes). 
DPoP is potentially really nice for these environments as they often have a 
nice secure element available to store the private key and are much less 
susceptible to XSS and so on, but may still worry about a malicious RS. IoT 
applications may also be a use-case as requests are often relayed over multiple 
hops and different transport protocols, so TLS cannot be used for end-to-end 
security (although in that case you probably want a full request signing 
approach).

Section 2:
I think the “Main Objective” in section 2 could be improved. The vast majority 
of the mechanisms described in the draft do nothing to address this main 
objective, and are in fact intended to prevent DPoP proof replay which is 
relegated to a “secondary objective” in section 9. Only the “htu” claim really 
has anything at all to do with the main objective. I think some of these 
secondary objectives, especially the anti-replay one, should be brought forward 
to section 2 to better justify what follows.

It has been mentioned several times on this list that an audience restriction 
in the AT would also solve this main objective, and the response has generally 
been that adding audience restrictions is hard in practice - e.g. due to the AS 
not knowing where the AT is intended to be used. I think it would be useful to 
explicitly add some discussion of this, and perhaps a comparison with things 
like resource indicators that presumably could solve at least some of the 
issues with audience restrictions.

I think there *are* significant advantages of DPoP that address real-world 
attacks that cannot be solved in any other way currently. For example, I was 
reading [1] recently about CRIME/BREACH attacks against CSRF tokens and it 
occurred to me that exactly the same kind of attack is a real threat to access 
tokens in a browser and that DPoP is an effective mitigation against it. To 
summarise, these attacks exploit vulnerabilities in TLS when combined with 
compression (either in TLS itself or HTTP compression) and can allow an 
attacker to steal bearer tokens or cookies after observing enough requests with 
the same token (and being able to influence some other content in the same 
request/response). One recommended mitigation is to randomize tokens so that 
they are different on every request, which thwarts the attack. Although DPoP 
doesn’t directly randomize the AT the AT is useless without a DPoP proof and a 
unique “jti” claim ensures that the DPoP proof is randomized and so not 
recoverable through this attack. Given that BREACH is largely unmitigated in 
practice, due to the usefulness of compression, adding a description of this 
attack to the justification would IMO significantly improve the rationale for 
DPoP.

Section 3:
The second bullet point of step (B) isn’t clear - is it implying that refresh 
tokens for confidential clients shouldn’t be DPoP-bound? Must not?

Step (C) implies that only JWT-structured ATs or token introspection are 
supported for communicating the public key. Presumably deployers are free to 
use another secure mechanism if they wish?

The last bullet point about requiring a DPoP proof for refresh tokens is 
ambiguous about what happens in the case of confidential clients if the refresh 
token is not DPoP-bound. Do they not supply a DPoP proof at all (and it reuses 
the original one), or must they supply a new one? Can they supply a *different* 
DPoP proof to e.g. rotate their key pair?

Section 4:
Maybe a forward reference to section 6 when mentioning the DPoP header field, 
as that’s where it is defined.

4.1:
I’m not keen about including the full “jwk” in every DPoP proof. It never 
changes for the life of the AT and adds considerable overhead to the size of 
the proof. If the RS is using token