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

[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
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
> that I committed to bringing back to the list. The slide below (also
> available as slide #17 from the interim presentation
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
> 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:
>
>    1.  It's sufficiently okay as it is
>    2.  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.
> [image: 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
>