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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 03 December 2020 11:59 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 5166A3A07B3 for <oauth@ietfa.amsl.com>; Thu, 3 Dec 2020 03:59:29 -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=unavailable 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 yLL-0HSF7bXY for <oauth@ietfa.amsl.com>; Thu, 3 Dec 2020 03:59:26 -0800 (PST)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 960D53A0779 for <oauth@ietf.org>; Thu, 3 Dec 2020 03:59:26 -0800 (PST)
Received: by mail-ej1-x633.google.com with SMTP id g20so3103890ejb.1 for <oauth@ietf.org>; Thu, 03 Dec 2020 03:59:26 -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=WpMvMQ6fR82mAT9cK3ebvQcsoAFkzwqkQA9JJkDQY1I=; b=GCVgLWu2lR+2ot5SgK1sH6p02K9/E+k+8biBlK7UzAaL/MlTlV/fK+8vqlTMqMXRbF Fhz9bf43h8HSbzYJcdw3XovFj7ZFhOUHY1j7zl5fUCgVYRnQe4XTYBUjWFpQ5qRhKbyu z5gstwHyRzWi0jLcmc7NAL65Ryby3Z4YzIPtz0Nv0JTVuAWa7ZgM5uSY8hQEsQO3MOl2 4HLP/1VhVW+mqzpujN23ihAeMu/EHGw60uwepLbsPt5yvQDKvxwm2ueklxYA7jebF3Xb 5uKv4eeDWXDBLxHbQndBcIbkGhLY/PTeMxmf/zBpMcWTdAA31ng5mepWjjgJ56RLTpEa cG1A==
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=WpMvMQ6fR82mAT9cK3ebvQcsoAFkzwqkQA9JJkDQY1I=; b=XBCHVVPFrPfHYHWEeqZ7pzEU48DdQehPflalPTu8sRbRj4Pt+v1CxcZZzflCk1hyTy +DyJQDjheRayOmC7se+KbGnPNYSXhfDZtYQ6DayI19L+I8EjsHzVZZovBal2s5qu1/5w 0nPy4P3D6VLFMSbpVhQI3ofweDHQaHSLMvWKf1sIm4PqugRY8G9p5+Cj6pRP4s0HwLQU 3jL2e1zYJbmS5X8RxjiVJG/+kLfc6DB/BZDNLt99U8WtJh/9wURdl7GHSIoknXPdmgzr U2AuBeXRwcSppjALIRi/xxFZyBg8trt/t7XVtCPfgoIglf8DA17APUJ45UEOQAgzI+2i ObsQ==
X-Gm-Message-State: AOAM531Loon9n9Iofwqqu9iXvFk0qahZryeoDAXSgYpeUxp7i9P5hmze DGgyvFEH79ozADxeIBHvI29cSA==
X-Google-Smtp-Source: ABdhPJyk4v+4SNvl8Lgk2J5OYvQlw2GH3zeX2nmvwVmUFPK9Ay/AoJd+x0w++bBklQqAn8Umiw33tg==
X-Received: by 2002:a17:906:bcf9:: with SMTP id op25mr2204258ejb.223.1606996764647; Thu, 03 Dec 2020 03:59:24 -0800 (PST)
Received: from [192.168.71.123] (p4fc08d1c.dip0.t-ipconnect.de. [79.192.141.28]) by smtp.gmail.com with ESMTPSA id o3sm1039970edj.41.2020.12.03.03.59.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 03:59:24 -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_8zWGAG8p5OnrTB=4q_jL00dJi5oYQrWXmzvqKGhfL28w@mail.gmail.com>
Date: Thu, 3 Dec 2020 12:59:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <30D5F7BA-EA54-4E40-A2FC-222AA0C9AF8D@lodderstedt.net>
References: <CA+k3eCSyMWyLYorWH7KY+XR1syAQUi4tQXdUuevKz4Y6xNMheA@mail.gmail.com> <CALAqi_8zWGAG8p5OnrTB=4q_jL00dJi5oYQrWXmzvqKGhfL28w@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/h8Y1iDxDMEj693_hc2vpcK5dqfk>
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 11:59:29 -0000

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