Re: [OAUTH-WG] Token substitution in DPoP

[Brian Campbell <[e-mail]>]

The extent of the weirdness needed leads me to feel that it's not a threat
that's in scope. To copy the proof signature from a request with T1 onto a
new request using T2, Alice would need access to the first request, which
is made directly from client to RS. That's not possible for a web server
client so the client would need to be running on Alice's machine/device.
Such on device clients aren't typically going to be acting on behalf of
multiple users. Or if they are, will need to do a lot more to securely
segment the user execution environments from each other. Most of which is
outside what can be done at this protocol application level.



On Fri, Nov 20, 2020 at 12:26 PM Justin Richer <[e-mail]> wrote:

> While working on an implementation of DPoP recently, I realized that the
> value of the access token itself is not covered by the DPoP signature at
> all. What I’m wondering is whether or not this constitutes an attack
> surface that we care about here. Here’s how it works:
>
>
> Let’s say that a client creates a DPoP key and uses that key to request
> two tokens, T1 and T2, for different users, Alice and Bob, respectively.
> Alice is malicious and wants to get Bob’s stuff. Alice manages to get a
> hold of Bob’s token value, T2, through some means. Normally DPoP wouldn’t
> let Alice create a new request using T2 since Alice doesn’t have the
> client’s key. However, if Alice gets the client to create a request for her
> using T1, she can copy the signature from that request onto a new request
> using T2. Since the signature doesn’t cover the token value and the key is
> the same, the RS should accept both requests, right?
>
> An important aspect is that the parts needed to make this attack work are
> a little weird: you’d need access to a valid signed request from the client
> with T1 as well as access to a valid T2 attached to the same key in order
> to make this substitution. However, this is effectively the same attack
> area that bearer tokens have in a lot of ways, since it doesn’t require the
> attacker gaining access to the singing key to generate or modify a
> signature, nor does it require the attacker to generate or modify an access
> token (merely obtain one).
>
>
> I’d like to understand if this is an actual attack against DPoP. If it
> isn’t, how is it countered by DPoP today? If it is, do we discuss in the
> DPoP draft? I didn’t see a mention of it there. If it’s not, should we
> discuss it there?
>
>
> The old OAuth PoP draft mitigates this attack by putting the access token
> itself inside the signature body instead of a second header. Another option
> would be to include a hash of the token value (such as OIDC’s “at_hash”
> method used in ID Tokens) in the DPoP payload. With either of these
> approaches, Alice having access to T1, T2, and a signed message for T1 does
> not allow her to use T2 effectively.
>
>  — Justin
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

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