From nobody Tue Nov 30 12:39:59 2021 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 DA4F93A1557 for ; Tue, 30 Nov 2021 12:39:56 -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=ham 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 mQwlisr8wZ9F for ; Tue, 30 Nov 2021 12:39:51 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 07C883A1554 for ; Tue, 30 Nov 2021 12:39:49 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id p27-20020a05600c1d9b00b0033bf8532855so15676914wms.3 for ; Tue, 30 Nov 2021 12:39:49 -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=6+TPDj757NG9J0lhUC8G0XTlTfvRoHn45boR/ZwvzTg=; b=KL06KWHw0UrvTl9mpBBiiTUSQsYCKNG5Un9j+KZAzuBk3kheFoAFE+F0NTPaHKVUDp fNMZmGe1HSvnmlC4zKotHCKHTab2HpPfYvU6c5tA6AxG3m8U4NKrWCZGYNcjBV2x8nbt 2DrCS7s6E/eGcVTGmPfxdigsI1BljkuNXupsc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6+TPDj757NG9J0lhUC8G0XTlTfvRoHn45boR/ZwvzTg=; b=WVslaDPVi3ZoofPgO01Irx7wH7L590ulyo/Wc7NxQwGAXLusBy+4sO5shDGdOKmH/A j0YUwoainCl5+bthL6quqcqK+uut9yWgRZFmRee9aqYqbF96xv1dlxglwzscMCSGwyOb GV0ZyY9pZCiK81YCbRnIoSOzqQFXbFPxq1A40HkIu4pRdWQCA/srVmy/XpalN1umabk9 0WpIB3nYvEx8f7wh8qgUIoaK+YuvASnE57cPsAq8Ybhj6FJ2NtlicJ6HRZSQwOD4k7WC FkOQibrjk0WmhhhGMZ9DhM+DliDZu8c24Ebr6ZmkJUz5YaOKyxf0oZfvAGl9w81WCHIz T3tQ== X-Gm-Message-State: AOAM5308DQ5Duce1elmBCftu7l48JWqRvTRFp1kqg72cgzmBYLrwgygX gWhyiW2wP43mbdU6GAJoYSWnxF2tI/cxnA== X-Google-Smtp-Source: ABdhPJxYwK/H4QsGEIuVFLF9Wq1O0OS4lz62qveGTOpZWopQYwbOU0MwbofLvk6Gh2kVcOrp1QK48w== X-Received: by 2002:a05:600c:4f14:: with SMTP id l20mr1253883wmq.164.1638304787462; Tue, 30 Nov 2021 12:39:47 -0800 (PST) Received: from [10.0.0.7] (12.87.75.194.dyn.plus.net. [194.75.87.12]) by smtp.gmail.com with ESMTPSA id w17sm17750333wrp.79.2021.11.30.12.39.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Nov 2021 12:39:47 -0800 (PST) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_53F2B964-C481-4A87-A91F-0A069F4644C5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 30 Nov 2021 20:39:46 +0000 In-Reply-To: Cc: "oauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter 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: Tue, 30 Nov 2021 20:39:57 -0000 --Apple-Mail=_53F2B964-C481-4A87-A91F-0A069F4644C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sadly I couldn=E2=80=99t make the DPoP session, but I=E2=80=99m not = convinced the attack described in the earlier message really needs to be = prevented at all. The attack largely hinges on auth codes not being = one-time use, which is not a good idea, or otherwise on poor network = security on the token endpoint. I=E2=80=99m not convinced DPoP needs to = protect against these things. Is there more to this? The proposed solutions also seem susceptible to the same problems they = attempt to solve - if an attacker is somehow able to interrupt the = client=E2=80=99s (TLS-protected) token request, why are they somehow not = able to interrupt/modify the (far less protected) redirect to the = authorization endpoint? =E2=80=94 Neil > On 30 Nov 2021, at 20:15, Mike Jones = wrote: >=20 > As described during the OAuth Security Workshop session on DPoP, I = created a pull request adding the dpop_jkt authorization request = parameter to use for binding the authorization code to the client=E2=80=99= s DPoP key. Seehttps://github.com/danielfett/draft-dpop/pull/89 = . > =20 > This is an alternative to = https://github.com/danielfett/draft-dpop/pull/86 = , which achieved this = binding using a new DPoP PKCE method. Using this alternative allows = PKCE implementations to be unmodified, while adding DPoP in new code, = which may be an advantage in some deployments. > =20 > Please review and comment. Note that I plan to add more of the attack = description written by Pieter Kasselman to the security considerations = in a future commit. This attack description was sent by Pieter = yesterday in a message with the subject =E2=80=9CAuthorization Code Log = File Attack (was DPoP Interim Meeting Minutes)=E2=80=9D. > =20 > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_53F2B964-C481-4A87-A91F-0A069F4644C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sadly= I couldn=E2=80=99t make the DPoP session, but I=E2=80=99m not convinced = the attack described in the earlier message really needs to be prevented = at all. The attack largely hinges on auth codes not being one-time use, = which is not a good idea, or otherwise on poor network security on the = token endpoint. I=E2=80=99m not convinced DPoP needs to protect against = these things. Is there more to this?

The proposed solutions also seem = susceptible to the same problems they attempt to solve - if an attacker = is somehow able to interrupt the client=E2=80=99s (TLS-protected) token = request, why are they somehow not able to interrupt/modify the (far less = protected) redirect to the authorization endpoint?

=E2=80=94 Neil

On 30 Nov 2021, at 20:15, Mike = Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

As described during the = OAuth Security Workshop session on DPoP, I created a pull request adding = the dpop_jkt authorization request parameter to use for binding the = authorization code to the client=E2=80=99s DPoP key.  Seehttps://github.com/danielfett/draft-dpop/pull/89.
 
This is an alternative = to https://github.com/danielfett/draft-dpop/pull/86, which = achieved this binding using a new DPoP PKCE method.  Using this = alternative allows PKCE implementations to be unmodified, while adding = DPoP in new code, which may be an advantage in some deployments.
 
Please review and = comment.  Note that I plan to add more of the attack description = written by Pieter Kasselman to the security considerations in a future = commit.  This attack description was sent by Pieter yesterday in a = message with the subject =E2=80=9CAuthorization Code Log File Attack = (was DPoP Interim Meeting Minutes)=E2=80=9D.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_53F2B964-C481-4A87-A91F-0A069F4644C5--