Thanks for the comments and engagement Warren. The attacks we described and the ideas on mitigations are born out of attack vectors we are observing in the wild. They are not negligible. We are seeing a new class of very sophisticated attackers, and if you're interested, this article provides good context on capability and sophistication of the attackers Brad Smith: Inside Microsoft during the SolarWinds hack (fastcompany.com)<https://www.fastcompany.com/90672384/microsoft-president-brad-smith-solarwinds-exclusive>. We are sharing this with the hope that the industry will benefit from our experiences and incorporate it into standards and products. Attacks that seemed impossibly complex are not only possible, but have become probable.
The proposed changes for DPoP are not meant to replace the need for one-time use tokens (single use tokens are preferable and we should continue to expect them), but instead address the limitations around implementing one-time use, especially at scale. The 60s window you mention below is sufficiently long to be exploited by these sophisticated attackers. Cheers Pieter From: OAuth <oauth-boun...@ietf.org> On Behalf Of Warren Parad Sent: Wednesday 1 December 2021 15:29 To: Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org> Cc: Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org>; oauth@ietf.org Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter (e.g. one-time use in a certain timeframe etc). Sure but couldn't we just reduce the lifetime? Even if the token isn't one time use, surely the reuse time is trivially short which would prevent against exfiltration of the necessary security tokens to issue the attack? I feel like the simpler solution will always win, which in this case is one-time use tokens, then the problem is moot, right? So this only comes into play if you want to allow token reuse in a time window. The previously suggested max allowed time window from OAuth 2.1 was 60s for auth codes. So we are saying that the attack surface is still too large, for the .01% of implementations that have multi-use tokens, and the .01% of implementations that use the maximum 60s reuse, and then the subset of those that aren't correctly scrubing their logs, and then the subset of those that have a vulnerability which allows for exfiltration of both those logged tokens and the logged PKCE verifier? Why are we making this more complicated for a majority of cases, which: * Only have single use tokens * Or Only have a very short lifetime * Or Are already correctly sanitizing their logs * Or Have defense in depth for their deployments. If the implementation is so insecure that none of those are happening, wouldn't the implementation for this functionality also be suspect for an opportunity for attack? I feel like we are justifying here that multi-use tokens are wrong, but still want a solution to use them. Once we've proven that an deployment is not okay with using multi-use tokens, then the conclusion should be "don't have multi-use tokens", not: "let's still have multi-use tokens, but come up with a complex way to prevent their multi-use from accidentally being abused". Or am I missing something that would actually make this a non-negligible attack vector? - Warren [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA] Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FBkvuWZ3FVTcdTtfe%2FoLurIGxcsJHCz6zXmW1PROTSc%3D&reserved=0>. On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> wrote: Hi Aaron, Neil Thanks for the questions. We agree that ideally authorization codes and PKCE proofs would never end up in log files and one-time use would be perfectly implemented. However, in practice these artefacts do find their way into log files in various places and one-time use may not always be practical (e.g. one-time use in a certain timeframe etc). The addition of these mitigations is not meant to replace the need for one-time use or good logging hygiene. Instead they provide pragmatic defence in depth against real attacks rather than assuming perfect implementations. We are deploying these mitigations and are sharing them for inclusion in DPoP to enable others to do the same. Regarding the question about interrupting/intercepting the HTTPS connection, the attacker don't need to intercept the HTTPS connection or modify the content in the TLS tunnel, rather they just need to prevent the authorization code from being presented to the Authorization Server. It may even happen due to a poor network connection. The poor connection may be engineered by an attacker, or they may opportunistically benefit from it. The networks are not perfect either. Cheers Pieter From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf Of Aaron Parecki Sent: Wednesday 1 December 2021 00:05 To: Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>> Cc: Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>; oauth@ietf.org<mailto:oauth@ietf.org> Subject: [EXTERNAL] Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F89&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ASCRFFPMA7qIItkxpVTrVaJtC53R2niWOzB0l0GQKrw%3D&reserved=0>. This is an alternative to https://github.com/danielfett/draft-dpop/pull/86<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F86&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lgb9WmnOwWVtNIFsZ1mQG4jSBQYLZv%2BETe6HIKFeerg%3D&reserved=0>, 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vuBY0pdcSiMXQF213ZVLm4yNMFhRqM1jWlrWSzn%2FS%2FE%3D&reserved=0> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vuBY0pdcSiMXQF213ZVLm4yNMFhRqM1jWlrWSzn%2FS%2FE%3D&reserved=0> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vuBY0pdcSiMXQF213ZVLm4yNMFhRqM1jWlrWSzn%2FS%2FE%3D&reserved=0>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
