From nobody Thu Dec 3 03:00:23 2020 Return-Path: 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 3EA843A0EA4 for ; Thu, 3 Dec 2020 03:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=forgerock.com 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 Tm50o7YUCRVX for ; Thu, 3 Dec 2020 03:00:19 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 9898A3A0E96 for ; Thu, 3 Dec 2020 03:00:18 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id q16so1596758edv.10 for ; Thu, 03 Dec 2020 03:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q6SBf8yyX3qOtL6vgp51qdInILXkrTqs0pAJkl3jXts=; b=JMVHdD8IgoR+v5ixsYqflnfnBXma0/Ze79/0dtNhCtmWXN7I85SyJ75lyju6eVLBXC kuXiYupqXEJM26qGAkwXWt24pOj6fycaFk1pwr9YdB7R/g8374TcxAIeV2FpR0V5s6y9 bq6vgHvIpoqgA6p0G4tNpDEIWOxbbEjY+YpN8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q6SBf8yyX3qOtL6vgp51qdInILXkrTqs0pAJkl3jXts=; b=gW7iWJFTqgCIudt0pDDsHAJCfRkYqMSz5tTq0ptkYUpbq+D3AdwKe2kBc534vDLBbJ FKIFLt42o0TQVaJ7cqPtzuun1fcBh8QfgN61RSdoYcifsub8hgxv2C9A1IY9zeXQOgav c/BA5qdvWp9kGCsN76KsOkoLJYyVm7YTEEwPnenDMl7nfYhxuvRDnqyZ7pxz4b9zQpk/ kL419+7ME9eGcU6nmSpibVSPrGY4ydPOxNzaS8wwICCXJqQVtE0ZbtLnnNkpQQgmyjAt iNaQ+BAVgNLdVtRLNAZcpEoVvrMDJ4FmD/UZq1qBcMCXsF8NP8KrigvppMktLuDqmGa/ 9gmA== X-Gm-Message-State: AOAM532izKoAdujyiHnmoJWKXHtHWlZzyLkTG5tv4EdtT4uPwjKoaqon kBnhsG0qYZkvhqPJwxi2NYLgjDDIxhWlmvdd+gFMkLcKDcbpZiNBNiY8wFZZHLNs0hF+B2e1Qg= = X-Google-Smtp-Source: ABdhPJydxm6v0HAfPY/kjPaMsSeLaq1zYUj5qhn44F3a5ZB7LfbtxtZH+K6R8GZTYxwyf5p1RQOqhA== X-Received: by 2002:a05:6402:31a5:: with SMTP id dj5mr2224009edb.325.1606993216451; Thu, 03 Dec 2020 03:00:16 -0800 (PST) Received: from [10.0.0.4] ([213.31.218.193]) by smtp.gmail.com with ESMTPSA id l19sm895968edq.14.2020.12.03.03.00.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 03:00:15 -0800 (PST) From: Neil Madden Message-Id: <2A107633-F0AC-439C-9783-57DA38E1B04F@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 3 Dec 2020 11:00:14 +0000 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_5CEB17FB-DE90-4C8F-8C19-3F6E1385683C" Archived-At: Subject: Re: [OAUTH-WG] DPoP followup II: confirmation style X-BeenThere: oauth@ietf.org 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 11:00:22 -0000 --Apple-Mail=_5CEB17FB-DE90-4C8F-8C19-3F6E1385683C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Strongly in favour of 2. I think history shows that successful standards make security checks hard t= o get wrong rather than merely easy to get right. =E2=80=94 Neil > On 2 Dec 2020, at 22:28, Brian Campbell wrote: >=20 > 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 w= ith some typos and omitted words as slide #18 from the interim presentation= ) is the second one. To summariz= e (by basically repeating the content of the slide): It=E2=80=99s been sugg= ested that, for resource access, having the JWK in the header of the DPoP p= roof JWT makes it too easy to just use that key to validate the signature a= nd miss checking the binding to the AT=E2=80=99s cnf/jkt hash, which underm= ines the value of doing the binding in the first place. As I see it, there = are two options here and I'd like to gauge WG consensus on which to move fo= rward with.=20 > It=E2=80=99s fine as is (AS/RS symmetry is nice, it's the same way confir= mation works in MTLS/TB, and the binding check is kinda fundamental to the = whole thing so it's not unreasonable to expect implementers to do it) > For resource access, put the full JWK in the AT=E2=80=99s confirmation an= d omit it from the proof (less error prone, no hash function needed for con= firmation, somewhat less data overall between the two artifacts) >=20 >=20 > >=20 >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y 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 --=20 ForgeRock values your Privacy --Apple-Mail=_5CEB17FB-DE90-4C8F-8C19-3F6E1385683C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Strongly in favour of 2.
I think history shows th= at successful standards make security checks hard to get wrong rather than = merely easy to get right.

=E2=80=94 Neil

On= 2 Dec 2020, at 22:28, Brian Campbell <bcampbell=3D40pingidentity.com@d= marc.ietf.org> wrote:

<= div class=3D"">
There were a few= items discussed somewhat during the recent interim that I committed to bringing back to the list. The slid= e below (also available with some typos and omitted words as slide #18 from= the interim presentation) is the second one. To summarize (by b= asically repeating the content of the slide): It=E2=80=99s been suggested t= hat, for resource access, having the JWK in the header of the DPoP proof JW= T makes it too easy to just use that key to validate the signature and miss= checking the binding to the AT=E2=80=99s cnf/jkt hash, which undermines th= e value of doing the binding in the first place. As I see it, there are two= options here and I'd like to gauge WG consensus on which to move forward w= ith.
  1. It= =E2=80=99s fine as is (AS/RS symmetry is nice, it's the same way confirmati= on works in MTLS/TB, and the binding check is kinda fundamental to the whol= e thing so it's not unreasonable to expect implementers to do it)
  2. For resource access, put the full JWK in the AT=E2=80=99s confirm= ation and omit it from the proof (less error prone, no hash function needed= for confirmation, somewhat less data overall between the two artifacts)


<Slide18.jpg>




CONFIDENTIALITY NOTICE: = This email may contain confidential and privileged material for the sole us= e of the intended recipient(s). Any review, use, distribution or disclosure= by others is strictly prohibited.  If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
OAut= h mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


ForgeRock values your Privacy --Apple-Mail=_5CEB17FB-DE90-4C8F-8C19-3F6E1385683C--