Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Torsten Lodderstedt <[e-mail]>]

Hi, 

I'm failing to understand why binding the proof to the access token ensures freshness of the proof. I would rather think if the client is forced to create proofs with a reasonable short lifetime, chances for replay could be reduced. 

Beside that as far as I remember the primary replay counter measure is the inclusion of the endpoint URL and HTTP method in the proof, since it reduces the attack surface to a particular URL. So in the context of freshness, we are talking about using the same proof with the same URL again. 

best regards,
Torsten. 

> Am 03.12.2020 um 10:20 schrieb Filip Skokan <[e-mail]>:
> 
> Hi Brian, everyone,
> 
> While the attack vector allows direct use, there is the option where a smarter attacker will not abuse the gained artifacts straight away. Think public client browser scenario with the non-extractable private key stored in IndexedDB (the only place to persist them really), they wouldn't use the tokens but instead, exfiltrate them, together with a bunch of pre-generated DPoP proofs. They'll get the refresh token and a bunch of DPoP proofs for both the RS and AS. With those they'll be able to get a fresh AT and use it with pre-generated Proofs after the end-user leaves the site. No available protection (e.g. RT already rotated) will be able to kick in until the end-user opens the page again.
> 
> OTOH with a hash of the AT in the Proof only direct use remains.
> 
> If what I describe above is something we don't want to deal with because of direct use already allowing access to protected resources, it's sufficiently okay as is (option #1). However, if this scenario, one allowing prolonged access to protected resources, is not acceptable, it's option #2.
> 
> Ad #2a vs #2b vs #2c. My pre-emptive answer is #2a, simply because we already have the tools needed to generate and validate these hashes. But further thinking about it, it would feel awkward if this JWS algorithm driven at_hash digest selection wouldn't get stretched to the confirmations, when this are placed in a JWT access token, cool - we can do that, but when these are put in a basic token introspection response it's unfortunately not an option. So, #2b (just use sha-256 just like the confirmations do).
> 
> Best,
> Filip
> 
> 
> On Wed, 2 Dec 2020 at 21:50, Brian Campbell <bcampbell=[e-mail]> wrote:
> There were a few items discussed somewhat during the recent interim that I committed to bringing back to the list. The slide below (also available as slide #17 from the interim presentation) is the first one of them, which is difficult to summarize but kinda boils down to how much assurance there is that the DPoP proof was 'freshly' created and that can dovetail into the question of whether the token is covered by the signature of the proof. 
> There are many directions a "resolution" here could go but my sense of the room during the meeting was that the contending options were:
> 	•  It's sufficiently okay as it is
> 	•  Include a hash of the access token in the DPoP proof (when an access token is present)
> 
> Going with #2 would mean the draft would also have to define how the hashing is done and deal with or at least speak to algorithm agility. Options (that I can think of) include:
> 	• 2a) Use the at_hash claim defined in OIDC core https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken. Using something that already exists is appealing. But its hash alg selection routine can be a bit of a pain. And the algorithm agility based on the signature that it's supposed to provide hasn't worked out as well as hoped in practice for "new" JWS signatures https://bitbucket.org/openid/connect/issues/1125/_hash-algorithm-for-eddsa-id-tokens
> 	• 2b) Define a new claim ("ah", "ath", "atd", "ad" or something like that maybe) and just use SHA-256. Explain why it's good enough for now and the foreseeable future. Also include some text about introducing a new claim in the future if/when SHA-256 proves to be insufficient. Note that this is effectively the same as how the confirmation claim value is currently defined in this document and in RFC8705.
> 	• 2c) Define a new claim with its own hash algorithm agility scheme (likely similar to how the Digest header value or Subresource Integrity string is done).
> 
> I'm requesting that interested WG participants indicate their preference for #1 or #2. And among a, b, and c, if the latter. 
> 
> I also acknowledge that an ECDH approach could/would ameliorate the issues in a fundamentally different way. But that would be a distinct protocol. If there's interest in pursuing the ECDH idea, I'm certainly open to it and even willing to work on it. But as a separate effort and not at the expense of derailing DPoP in its general current form. 
> <Slide17.jpeg>
> 
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607592086000000&usg=AOvVaw3hGaihxAdyXVvzFnVTpc6N