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