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

Filip Skokan <> Thu, 03 December 2020 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E54BA3A0D6E for <>; Thu, 3 Dec 2020 01:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zotKdbU6b2eV for <>; Thu, 3 Dec 2020 01:20:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 217453A0DEA for <>; Thu, 3 Dec 2020 01:20:58 -0800 (PST)
Received: by with SMTP id t33so1430389ybd.0 for <>; Thu, 03 Dec 2020 01:20:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=umAgptDz+npAaIZj2oNCyPLf0HzXQwVZ0uGBpe9QdfU=; b=tYJzDKCDc0Z5wgYXQ7rjtMq64zOZB4eFCI/FpoH5ACUpy5puhQ/yNm9CJ6YnmGhNOi HafSQRbOth8HK0O0Y2jpYtVIs2tF7bp7ecadgydXytiloWEOxf/UaxHzzuBxkHctm/e6 5dsKBurGkFCyPxtga7relsvvH7PAM8nnwHqi6Ygmox8J2bZp21Ry9OWBev5Nsn8JQa5O Xug0lL6Us2m44/ghv6D3hF6DL7uxYWvzyZAH6CGdV2OrBM+NOtXU7+bJ/JYsr9b+QNhQ YzoFW3FIokI3rMC3ieKzHdMwi2dBoYzSMKgZ8SEVVQUpkfF/vIbZrMQEx5Osxummr1Ki Bf9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=umAgptDz+npAaIZj2oNCyPLf0HzXQwVZ0uGBpe9QdfU=; b=cu0zPuiZdpd9fqiwiNtyWlw9EMdldzbVp2e244UGBTEdm4rFlD/SN62zLYY2caRQjz 57MBO4F4CNQwluST8eIoNYqgHJJNZSNrL9LE6kc+fPaSFHZR0O2Lf6RjAF5aDZt7ZXsM xcqLDzdOFkCRWQVJ4vSbDgVixypyo3+uePyvQEAaLvGTKPa6rsMwy5JThyl2slRVxaky vS1EAaNMwZvx2V4qSo9nguAd/bitUoII6BnEW+TuBithpcRC3Um+OE1wBjdwLfuPUmkJ xqKYcwClZ7A//I1LOqdpBu9qv66ZvJuP1KoHoSFoToIoFrE9q9HEXweTSCHv5HCpA8IJ kStw==
X-Gm-Message-State: AOAM5320TZt4cy6xZ712Ei+047NpurJtgiCLqOMQPOJ3IxSQKaKIrUuq aGSpzcOujTolW/FYcpL+23lsdtPzbbzCPBzekA==
X-Google-Smtp-Source: ABdhPJxdj7leQRdKFd4TpEdJ0rAQzE5glRvxGHsGnIhRuI9etVIrgOuZlHuG6aNYRlmRImH8uaFhg/Mx27eEjxz6zKU=
X-Received: by 2002:a25:f623:: with SMTP id t35mr3324042ybd.399.1606987256809; Thu, 03 Dec 2020 01:20:56 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Filip Skokan <>
Date: Thu, 03 Dec 2020 10:20:20 +0100
Message-ID: <>
To: Brian Campbell <>
Cc: oauth <>
Content-Type: multipart/related; boundary="0000000000009a16c205b58be0bf"
Archived-At: <>
Subject: Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2020 09:21:09 -0000

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


On Wed, 2 Dec 2020 at 21:50, Brian Campbell <bcampbell=> 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:
>    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
>    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
>    - 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