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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 03 December 2020 12:55 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445173A091B for <oauth@ietfa.amsl.com>; Thu, 3 Dec 2020 04:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCfQWcPdMfCs for <oauth@ietfa.amsl.com>; Thu, 3 Dec 2020 04:55:36 -0800 (PST)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEF73A0911 for <oauth@ietf.org>; Thu, 3 Dec 2020 04:55:36 -0800 (PST)
Received: by mail-ej1-x62d.google.com with SMTP id d17so3270751ejy.9 for <oauth@ietf.org>; Thu, 03 Dec 2020 04:55:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fhZrIegnU5PbYb9S3EaNbBdprCbxAAC34ahqYmlMhc0=; b=t1Lwh8p1XW/D/wef/NqPJVjTEqzXc4/IdIBwM/LxSMkixtfC3sUmgLdyG1iCmInbm+ fDbeHFZKo62A85JLbxYr80bSeh6ESFhnyUS1A2SPUqUelx9LUljC7F6XdxxOJZ5ZVM8H RIbPve2sNj+2DzLmXGsY/2Qajj+zWeLxZInNCB3iRWI4ZRgkMOJdLXlI5UPdWxWxwZJO oHth/A+A+B3YzkzEIx1gtfmQIbQA3rdIvihHPt/4HChX42qTSuZLC/oGLR0krymHzra3 SFAAQQXpEBB9Gjm2gqKh94aRCl4Ns0Bfhtzp61U+F7qAXXxV69UVIGtD+SOhZUqA+WxP eKxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fhZrIegnU5PbYb9S3EaNbBdprCbxAAC34ahqYmlMhc0=; b=NI4F/BwImE6BZWayjZX/vMx6o48UAVb0ZdkC9+QBN6KCM5ltyHySoHPm6SP0vLAoog v0rJvAHSOEkjA4OlcXhNw2CR8g7l4cVcx96SObbqZyyG+dBGjSj8ljPcE31RWAN9oBu3 wqjvMtvNELLI+vUATyiRLtVEwgXaXBKlQTs1hWdX3KtdQ2b5zjdXctErr/tA/wTnhDEo +gDj+vMXiUdr5Rk4QRZEAy0Jz/d3r/yiq6kS2jplSJgr2f4AN9bvkJSB3JLejpfOnJ/k n/mMzr7RBdD3utLM/NzANLHU++96vfb/H1RlCbI2Y0yn70raVKey4ztyFJnzAJB3jomJ 1bOA==
X-Gm-Message-State: AOAM53149AHpouECjeT2Kcgzdc8C3nLWCXJ0nzO+QzltbCdmw9cc3XrL PsS72GNjMd0wA3d60LDNIZIdwQ==
X-Google-Smtp-Source: ABdhPJwuKYihLtJ+Lzsp6kcWn0QlgXKbzDGi1ZKOocQtZnSqUp/fvJegCL+sIRAwjMk6gw8z34fTLw==
X-Received: by 2002:a17:906:ce51:: with SMTP id se17mr2341629ejb.314.1607000134474; Thu, 03 Dec 2020 04:55:34 -0800 (PST)
Received: from [192.168.71.123] (p4fc08d1c.dip0.t-ipconnect.de. [79.192.141.28]) by smtp.gmail.com with ESMTPSA id p22sm781030ejx.59.2020.12.03.04.55.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 04:55:33 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CALAqi_9AH5O6d2W+0UDz83=Csm9BbcU8j6qiRxz5rzLfzm6AQA@mail.gmail.com>
Date: Thu, 3 Dec 2020 13:55:32 +0100
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <353E4494-2F80-44BC-9267-6FB8B37AA0FE@lodderstedt.net>
References: <CA+k3eCSyMWyLYorWH7KY+XR1syAQUi4tQXdUuevKz4Y6xNMheA@mail.gmail.com> <CALAqi_8zWGAG8p5OnrTB=4q_jL00dJi5oYQrWXmzvqKGhfL28w@mail.gmail.com> <30D5F7BA-EA54-4E40-A2FC-222AA0C9AF8D@lodderstedt.net> <CALAqi_9AH5O6d2W+0UDz83=Csm9BbcU8j6qiRxz5rzLfzm6AQA@mail.gmail.com>
To: Filip Skokan <panva.ip@gmail.com>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Frxh80s5iWoBXcu3zCAklNNc7ec>
Subject: Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 12:55:38 -0000

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.ip@gmail.com>om>:
> 
> 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 <torsten@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.ip@gmail.com>om>:
> > 
> > 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.com@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
>