[OAUTH-WG] Token substitution in DPoP

[Justin Richer]

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

Re: [OAUTH-WG] Token substitution in DPoP

[Nikos Fotiou]

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

Re: [OAUTH-WG] Token substitution in DPoP

[Justin Richer]

Correct, but the choice of using different keys is entirely in the hands of the 
client, as the AS accepts whatever key the client presents in its initial DPoP 
proof to bind to the token. If it’s on the client to prevent this kind of 
thing, we should at least mention it in the security considerations. If it’s 
something we want to prevent wholesale, we should expand the signature coverage 
to the access token, or at least a hash of the token.

 — Justin

> On Nov 20, 2020, at 9:30 PM, Nikos Fotiou  wrote:
> 
> 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

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

Re: [OAUTH-WG] Token substitution in DPoP

[Brian Campbell]

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  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
> OAuth@ietf.org
> 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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token substitution in DPoP

[Daniel Fett]

Thanks Justin for bringing this to our attention.

Right now, I don't think that this is a big problem and I wasn't able to
come up with a way to improve the attack. I hope that it doesn't come
back to haunt us when somebody does a more in-depth analysis...

That said, the lack of binding to the access token makes it easier to
precompute proofs if somebody has a limited code execution opportunity
in the client. We have this paragraph in the spec:

   Malicious XSS code executed in the context of the browser-based
   client application is also in a position to create DPoP proofs with
   timestamp values in the future and exfiltrate them in conjunction
   with a token.  These stolen artifacts can later be used together
   independent of the client application to access protected resources.
   The impact of such precomputed DPoP proofs can be limited somewhat by
   a browser-based client generating and using a new DPoP key for each
   new authorization code grant.

The recommendation could be to use a fresh key pair for each token request.

-Daniel


Am 20.11.20 um 20:26 schrieb Justin Richer:
> 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


-- 
https://danielfett.de

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

Re: [OAUTH-WG] Token substitution in DPoP

[Neil Madden]

I agree with Daniel that I’d be a bit wary of assuming that this could never be 
exploited. For example, a server-side web app that signs DPoP proofs on behalf 
of client-side Javascript (to keep the key safe on the server) and reuses the 
key for different users could be a risk. 

IMO this is another symptom of the general issue of using signatures for 
authentication - they are too strong for the job. The fact that a signature is 
equally valid to all parties and at all times means you have to be very careful 
to include enough context in the signature calculation to ensure all these 
kinds of attacks are eliminated. And you have to ensure that all RSes check the 
context. 

Contrast that to my suggestion to use ECDH [1], which was already immune to 
such attacks by including the access token in the key derivation step. (And in 
such a way that requires no additional data on the wire and is almost 
impossible for the RS not to verify). Even without including the access token 
in the KDF, the attack could only happen if the client reused its key and the 
RS reused a challenge key pair. 

Macaroon access tokens [2] are also immune to this attack, as in that case the 
constraints that go in the DPoP proof are directly attached to the access token 
itself so there is no way to reuse them separately. (Interestingly, macaroons 
have a more direct analogue of DPoP in the form of discharge macaroons. Such 
discharge macaroons are required to be “prepared” before use, which 
cryptographically binds them to the equivalent of the access token - so this 
kind of attack was also considered and addressed there). 

[1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/
[2]: 
https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/

— Neil

> On 24 Nov 2020, at 09:38, Daniel Fett  wrote:
> 
> 
> Thanks Justin for bringing this to our attention.
> 
> Right now, I don't think that this is a big problem and I wasn't able to come 
> up with a way to improve the attack. I hope that it doesn't come back to 
> haunt us when somebody does a more in-depth analysis...
> 
> That said, the lack of binding to the access token makes it easier to 
> precompute proofs if somebody has a limited code execution opportunity in the 
> client. We have this paragraph in the spec:
> 
>Malicious XSS code executed in the context of the browser-based
>client application is also in a position to create DPoP proofs with
>timestamp values in the future and exfiltrate them in conjunction
>with a token.  These stolen artifacts can later be used together
>independent of the client application to access protected resources.
>The impact of such precomputed DPoP proofs can be limited somewhat by
>a browser-based client generating and using a new DPoP key for each
>new authorization code grant.
> 
> The recommendation could be to use a fresh key pair for each token request.
> 
> -Daniel
> 
> 
> Am 20.11.20 um 20:26 schrieb Justin Richer:
>> 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 o

Re: [OAUTH-WG] Token substitution in DPoP

[Brian Campbell]

On Tue, Nov 24, 2020 at 2:39 AM Daniel Fett  wrote:

>
> The recommendation could be to use a fresh key pair for each token request.
>
>
 Public clients will have RTs bound so need to use the same key.

-- 
_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] Token substitution in DPoP

[Brian Campbell]

It took me some time to warm to the ECDH based idea but I do think it has a
lot of merit. For whatever it's worth, I put the idea forth as one
potential path forward during the general PoP interim meeting back in March
(
https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf
slide 8) but the WG consensus was to pursue a signature style PoP for the
current efforts, which was followed not long after by WG adoption of DPoP.
I could potentially see an ECDH-style-POP effort making a resurgence in the
future. But it's fundamentally pretty different.




On Tue, Nov 24, 2020 at 4:03 AM Neil Madden 
wrote:

> I agree with Daniel that I’d be a bit wary of assuming that this could
> never be exploited. For example, a server-side web app that signs DPoP
> proofs on behalf of client-side Javascript (to keep the key safe on the
> server) and reuses the key for different users could be a risk.
>
> IMO this is another symptom of the general issue of using signatures for
> authentication - they are too strong for the job. The fact that a signature
> is equally valid to all parties and at all times means you have to be very
> careful to include enough context in the signature calculation to ensure
> all these kinds of attacks are eliminated. And you have to ensure that all
> RSes check the context.
>
> Contrast that to my suggestion to use ECDH [1], which was already immune
> to such attacks by including the access token in the key derivation step.
> (And in such a way that requires no additional data on the wire and is
> almost impossible for the RS not to verify). Even without including the
> access token in the KDF, the attack could only happen if the client reused
> its key and the RS reused a challenge key pair.
>
> Macaroon access tokens [2] are also immune to this attack, as in that case
> the constraints that go in the DPoP proof are directly attached to the
> access token itself so there is no way to reuse them separately.
> (Interestingly, macaroons have a more direct analogue of DPoP in the form
> of discharge macaroons. Such discharge macaroons are required to be
> “prepared” before use, which cryptographically binds them to the equivalent
> of the access token - so this kind of attack was also considered and
> addressed there).
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/
> [2]:
> https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/
>
> — Neil
>
> On 24 Nov 2020, at 09:38, Daniel Fett  wrote:
>
> 
> Thanks Justin for bringing this to our attention.
>
> Right now, I don't think that this is a big problem and I wasn't able to
> come up with a way to improve the attack. I hope that it doesn't come back
> to haunt us when somebody does a more in-depth analysis...
>
> That said, the lack of binding to the access token makes it easier to
> precompute proofs if somebody has a limited code execution opportunity in
> the client. We have this paragraph in the spec:
>
>Malicious XSS code executed in the context of the browser-based
>client application is also in a position to create DPoP proofs with
>timestamp values in the future and exfiltrate them in conjunction
>with a token.  These stolen artifacts can later be used together
>independent of the client application to access protected resources.
>The impact of such precomputed DPoP proofs can be limited somewhat by
>a browser-based client generating and using a new DPoP key for each
>new authorization code grant.
>
> The recommendation could be to use a fresh key pair for each token request.
>
> -Daniel
>
>
> Am 20.11.20 um 20:26 schrieb Justin Richer:
>
> 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 effect

Re: [OAUTH-WG] Token substitution in DPoP

[Justin Richer]

With the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I think 
we might have a good avenue for this ECDH-with-KDF flavor of message signature 
in that arena instead of trying to twist it into DPoP. I think that this 
signing mechanism will be a better base for a general PoP effort in OAuth, and 
I still believe that this could live alongside DPoP’s more specific focus and 
intentional limitations. 

 — Justin

[1] https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html 


[2] https://github.com/httpwg/http-extensions/ 



> On Nov 24, 2020, at 4:18 PM, Brian Campbell 
>  wrote:
> 
> It took me some time to warm to the ECDH based idea but I do think it has a 
> lot of merit. For whatever it's worth, I put the idea forth as one potential 
> path forward during the general PoP interim meeting back in March 
> (https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf
>  
> 
>  slide 8) but the WG consensus was to pursue a signature style PoP for the 
> current efforts, which was followed not long after by WG adoption of DPoP. I 
> could potentially see an ECDH-style-POP effort making a resurgence in the 
> future. But it's fundamentally pretty different.  
> 
> 
> 
> 
> On Tue, Nov 24, 2020 at 4:03 AM Neil Madden  > wrote:
> I agree with Daniel that I’d be a bit wary of assuming that this could never 
> be exploited. For example, a server-side web app that signs DPoP proofs on 
> behalf of client-side Javascript (to keep the key safe on the server) and 
> reuses the key for different users could be a risk. 
> 
> IMO this is another symptom of the general issue of using signatures for 
> authentication - they are too strong for the job. The fact that a signature 
> is equally valid to all parties and at all times means you have to be very 
> careful to include enough context in the signature calculation to ensure all 
> these kinds of attacks are eliminated. And you have to ensure that all RSes 
> check the context. 
> 
> Contrast that to my suggestion to use ECDH [1], which was already immune to 
> such attacks by including the access token in the key derivation step. (And 
> in such a way that requires no additional data on the wire and is almost 
> impossible for the RS not to verify). Even without including the access token 
> in the KDF, the attack could only happen if the client reused its key and the 
> RS reused a challenge key pair. 
> 
> Macaroon access tokens [2] are also immune to this attack, as in that case 
> the constraints that go in the DPoP proof are directly attached to the access 
> token itself so there is no way to reuse them separately. (Interestingly, 
> macaroons have a more direct analogue of DPoP in the form of discharge 
> macaroons. Such discharge macaroons are required to be “prepared” before use, 
> which cryptographically binds them to the equivalent of the access token - so 
> this kind of attack was also considered and addressed there). 
> 
> [1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/ 
> 
> [2]: 
> https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/
>  
> 
> 
> — Neil
> 
>> On 24 Nov 2020, at 09:38, Daniel Fett > > wrote:
>> 
>> 
>> Thanks Justin for bringing this to our attention.
>> 
>> Right now, I don't think that this is a big problem and I wasn't able to 
>> come up with a way to improve the attack. I hope that it doesn't come back 
>> to haunt us when somebody does a more in-depth analysis...
>> 
>> That said, the lack of binding to the access token makes it easier to 
>> precompute proofs if somebody has a limited code execution opportunity in 
>> the client. We have this paragraph in the spec:
>> 
>>Malicious XSS code executed in the context of the browser-based
>>client application is also in a position to create DPoP proofs with
>>timestamp values in the future and exfiltrate them in conjunction
>>with a token.  These stolen artifacts can later be used together
>>independent of the client application to access protected resources.
>>The impact of such precomputed DPoP proofs can be limited somewhat by
>>a browser-based client generating and using a new DPoP key for each
>>new authorization code grant.
>> 
>> The recommendation could be to use a fresh key pair for each token request.
>> 
>> -Daniel
>> 
>> 
>> Am 20.11.20 um 20:26 schrieb Justin Richer

Re: [OAUTH-WG] Token substitution in DPoP

[Neil Madden]

I’d be interested in hearing why people think digital signatures are a good 
choice for PoP. As far as I can tell that choice has not been clearly 
motivated. 

I have no interest in canonicalised HTTP message signing. I don’t think it’s a 
good idea. 

— Neil

> On 24 Nov 2020, at 23:32, Justin Richer  wrote:
> 
> With the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I 
> think we might have a good avenue for this ECDH-with-KDF flavor of message 
> signature in that arena instead of trying to twist it into DPoP. I think that 
> this signing mechanism will be a better base for a general PoP effort in 
> OAuth, and I still believe that this could live alongside DPoP’s more 
> specific focus and intentional limitations. 
> 
>  — Justin
> 
> [1] https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html
> 
> [2] https://github.com/httpwg/http-extensions/
> 
> 
>> On Nov 24, 2020, at 4:18 PM, Brian Campbell 
>>  wrote:
>> 
>> It took me some time to warm to the ECDH based idea but I do think it has a 
>> lot of merit. For whatever it's worth, I put the idea forth as one potential 
>> path forward during the general PoP interim meeting back in March 
>> (https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf
>>  slide 8) but the WG consensus was to pursue a signature style PoP for the 
>> current efforts, which was followed not long after by WG adoption of DPoP. I 
>> could potentially see an ECDH-style-POP effort making a resurgence in the 
>> future. But it's fundamentally pretty different.  
>> 
>> 
>> 
>> 
>> On Tue, Nov 24, 2020 at 4:03 AM Neil Madden  
>> wrote:
>>> I agree with Daniel that I’d be a bit wary of assuming that this could 
>>> never be exploited. For example, a server-side web app that signs DPoP 
>>> proofs on behalf of client-side Javascript (to keep the key safe on the 
>>> server) and reuses the key for different users could be a risk. 
>>> 
>>> IMO this is another symptom of the general issue of using signatures for 
>>> authentication - they are too strong for the job. The fact that a signature 
>>> is equally valid to all parties and at all times means you have to be very 
>>> careful to include enough context in the signature calculation to ensure 
>>> all these kinds of attacks are eliminated. And you have to ensure that all 
>>> RSes check the context. 
>>> 
>>> Contrast that to my suggestion to use ECDH [1], which was already immune to 
>>> such attacks by including the access token in the key derivation step. (And 
>>> in such a way that requires no additional data on the wire and is almost 
>>> impossible for the RS not to verify). Even without including the access 
>>> token in the KDF, the attack could only happen if the client reused its key 
>>> and the RS reused a challenge key pair. 
>>> 
>>> Macaroon access tokens [2] are also immune to this attack, as in that case 
>>> the constraints that go in the DPoP proof are directly attached to the 
>>> access token itself so there is no way to reuse them separately. 
>>> (Interestingly, macaroons have a more direct analogue of DPoP in the form 
>>> of discharge macaroons. Such discharge macaroons are required to be 
>>> “prepared” before use, which cryptographically binds them to the equivalent 
>>> of the access token - so this kind of attack was also considered and 
>>> addressed there). 
>>> 
>>> [1]: 
>>> https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/
>>> [2]: 
>>> https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/
>>> 
>>> — Neil
>>> 
 On 24 Nov 2020, at 09:38, Daniel Fett  wrote:
 
 
 Thanks Justin for bringing this to our attention.
 
 Right now, I don't think that this is a big problem and I wasn't able to 
 come up with a way to improve the attack. I hope that it doesn't come back 
 to haunt us when somebody does a more in-depth analysis...
 
 That said, the lack of binding to the access token makes it easier to 
 precompute proofs if somebody has a limited code execution opportunity in 
 the client. We have this paragraph in the spec:
 
Malicious XSS code executed in the context of the browser-based
client application is also in a position to create DPoP proofs with
timestamp values in the future and exfiltrate them in conjunction
with a token.  These stolen artifacts can later be used together
independent of the client application to access protected resources.
The impact of such precomputed DPoP proofs can be limited somewhat by
a browser-based client generating and using a new DPoP key for each
new authorization code grant.
 
 The recommendation could be to use a fresh key pair for each token request.
 
 -Daniel
 
 
 Am 20.11.20 um 20:26 schrieb Justin Richer:
> While working on an