+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.mad...@forgerock.com <mailto:neil.mad...@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....@dmarc.ietf.org >> <mailto:Michael.Jones=40microsoft....@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 >> <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 >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
