From nobody Wed Dec 1 00:26:50 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 3116C3A07E6 for ; Wed, 1 Dec 2021 00:26:48 -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_PASS=-0.001, UNPARSEABLE_RELAY=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=danielfett.de 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 35qDwjVHqfJX for ; Wed, 1 Dec 2021 00:26:43 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1373A07E4 for ; Wed, 1 Dec 2021 00:26:42 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id DB53B6586 for ; Wed, 1 Dec 2021 08:26:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1638347199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SIuzP5IiHsV0bsjiFG3ksRGtBzXhSoNxJ/nqMj4cYSk=; b=mnvOR6QvirSc10mJIBEvjScMXsq/XQ1x88Q8InaTrRJmCC0w2NZo+zX8fxwPjfc4i23KNW GGk8U6bBaTfjW7lOoZYfX5XxliuohSEaALqQrEcz6XLjOnGAqD03lKlRwwW/dwoqiBISL4 KJFydKp7UquKbFxZM7qJQJTeKAj+wRs= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <8feecdf1-ec94-7f5b-7a6d-443b10841dcc@danielfett.de> Date: Wed, 1 Dec 2021 09:26:39 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A6845E914B1E4C7788BE95A0" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1638347200; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SIuzP5IiHsV0bsjiFG3ksRGtBzXhSoNxJ/nqMj4cYSk=; b=iV1w7ckWd4cxm2Hei2MSGPh7nIngKdiFODZT08dk9dZvxLtdaz9/5PJCsKCoHkPqV4STfV cu9e5COD5ie1YFATKjVbHxVTzB13hnZqsRGeo/Vh3vewOKudBk1L4wYVFYHW9mAmiqgwt2 SjelS5RJh54dQG6x8usk/RV9BDsx6Mc= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1638347200; a=rsa-sha256; cv=none; b=jR1R/SioBOH4tcJb0rSjsqNlR0wwcYHsa65yRIayd4Ri/+ysiwtCEIUWS5fmo7/lg5Vm9k PRauae6qNTIWdLJk4SK3IgQIbtW519cUp1X23nR0ZNorI0rwPaRVGIpHJ/mjNVJUG4RGCE 8qwz8IosjuNU8KiJqwfMLiwvJiJYKMA= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: --- 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: Wed, 01 Dec 2021 08:26:48 -0000 This is a multi-part message in MIME format. --------------A6845E914B1E4C7788BE95A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit +1 to what Neil and Aaron said. dpop_jkt effectively creates a client authentication mechanism with an ad-hoc identifier for the client. I'm wondering if dynamic registration plus an asymmetric client authentication scheme doesn't already solve the problem. -Daniel Am 01.12.21 um 01:05 schrieb Aaron Parecki: > I tend to agree with Neil here. I'm struggling to see the relevance of > this attack.  > > It seems like the PDF writeup describes two possible reasons an > attacker could get access to the authorization code and PKCE code > verifier. > > 1. The attacker has access to the logs of the token endpoint. > 2. The attacker can intercept HTTPS connections between the client and > AS (VPN, corporate network proxy, etc) > > For 1, the solution is to stop logging the contents of the POST body, > and secure your infrastructure. I don't think making the client jump > through extra hoops is a good solution if you are already logging more > than you should be or you don't trust the people who have access to > the infrastructure. If this really is a concern, I suspect there are a > lot more places in the flow that would need to be patched up if you > don't trust your own token endpoint. > > For 2, if the attacker can intercept the HTTPS connection, then the > proposed solution doesn't add anything because the attacker could > modify the requests before it hits the authorization server anyway, > and change which DPoP key the token gets bound to in the first place. > Plus, the attacker would also have access to anything else the client > is sending to the AS, such as the user's password when they > authenticate at the AS. > > Are there other attack vectors I'm missing that might actually be > solved by this mechanism? > > Aaron > > > On Tue, Nov 30, 2021 at 12:40 PM Neil Madden > > wrote: > > Sadly I couldn’t make the DPoP session, but I’m 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’m 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’s (TLS-protected) token request, why are they > somehow not able to interrupt/modify the (far less protected) > redirect to the authorization endpoint? > > — Neil > >> On 30 Nov 2021, at 20:15, Mike Jones >> > > 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’s 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 >> “Authorization Code Log File Attack (was DPoP Interim Meeting >> Minutes)”. >>   >>                                                        -- Mike >>   >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de --------------A6845E914B1E4C7788BE95A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
+1 to what Neil and Aaron said.

dpop_jkt effectively creates a client authentication mechanism with an ad-hoc identifier for the client.

I'm wondering if dynamic registration plus an asymmetric client authentication scheme doesn't already solve the problem.

-Daniel

Am 01.12.21 um 01:05 schrieb Aaron Parecki:
I tend to agree with Neil here. I'm struggling to see the relevance of this attack. 

It seems like the PDF writeup describes two possible reasons an attacker could get access to the authorization code and PKCE code verifier.

1. The attacker has access to the logs of the token endpoint.
2. The attacker can intercept HTTPS connections between the client and AS (VPN, corporate network proxy, etc)

For 1, the solution is to stop logging the contents of the POST body, and secure your infrastructure. I don't think making the client jump through extra hoops is a good solution if you are already logging more than you should be or you don't trust the people who have access to the infrastructure. If this really is a concern, I suspect there are a lot more places in the flow that would need to be patched up if you don't trust your own token endpoint.

For 2, if the attacker can intercept the HTTPS connection, then the proposed solution doesn't add anything because the attacker could modify the requests before it hits the authorization server anyway, and change which DPoP key the token gets bound to in the first place. Plus, the attacker would also have access to anything else the client is sending to the AS, such as the user's password when they authenticate at the AS.

Are there other attack vectors I'm missing that might actually be solved by this mechanism?

Aaron


On Tue, Nov 30, 2021 at 12:40 PM Neil Madden <neil.madden@forgerock.com> wrote:
Sadly I couldn’t make the DPoP session, but I’m 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’m 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’s (TLS-protected) token request, why are they somehow not able to interrupt/modify the (far less protected) redirect to the authorization endpoint?

— Neil

On 30 Nov 2021, at 20:15, Mike Jones <Michael.Jones=40microsoft.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’s 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 “Authorization Code Log File Attack (was DPoP Interim Meeting Minutes)”.
 
                                                       -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



-- 
https://danielfett.de
--------------A6845E914B1E4C7788BE95A0--