Hi,
The token is granted to a client based on the authorization grant and not the
client's key. Therefore, a client may use a different key per token. At least
this is an approach we are following.
Best,
Nikos
-Original Message-
From: OAuth On Behalf Of Justin Richer
Sent: Friday, November 20, 2020 9:26 PM
To: oauth
Subject: [OAUTH-WG] Token substitution in DPoP
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth