Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

[Daniel Fett <[e-mail]>]

+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
> <[e-mail] <mailto:[e-mail]>> 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=[e-mail]
>>     <mailto:Michael.Jones=[e-mail]>> 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
>>     <https://github.com/danielfett/draft-dpop/pull/89>.
>>      
>>     This is an alternative
>>     to https://github.com/danielfett/draft-dpop/pull/86
>>     <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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de