I understand. Thanks! I think RT rotation + RT hash in the proof would also stop the attack.
> Am 03.12.2020 um 13:19 schrieb Filip Skokan <panva...@gmail.com>: > > I'm failing to understand why binding the proof to the access token ensures > freshness of the proof. > > Because when access tokens issued to public browser based clients have a > short duration you need continued access to the private key to issue new > proofs. When I exfiltrate the RT and pre-generate tons of proofs while the > user is active on the page through XSS I can then use the RT and my prepared > proofs to talk to the AS to keep on refreshing the AT and use it against the > RS. When the value of the token is part of the proof, i cannot pre-generate > them for future issued access tokens. Short `iat` based windows don't help > here. > > S pozdravem, > Filip Skokan > > > On Thu, 3 Dec 2020 at 12:59, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > 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 <panva...@gmail.com>: > > > > 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=40pingidentity....@dmarc.ietf.org> 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607592086000000&usg=AOvVaw3hGaihxAdyXVvzFnVTpc6N > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
