I think the allowed keys would have to be pre-registered in the AS. Warren Parad
Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Fri, Dec 3, 2021 at 5:01 PM Warren Parad <wpa...@rhosys.ch> wrote: > While I agree this is a problem, adding the thumbprint to the > authorization request only increases the difficulty for the malicious MITM > attack to need to also intercept the authorization request in addition to > the token request to swap out the dpop_jkt as well. If I'm right, then it > doesn't make sense to implement this as the solution. > > While I agree, we could move the dpop_jwk determination to the > authorization request, instead of the token, it doesn't solve the problem. > What it does say is that the authorization request user-agent is the one > that has the key, and not the one doing the code exchange. Well this is > actually weird in the case of non-public clients, because it doesn't make > sense from that client perspective, as the "front-end" would need to now > have the constructed dpop_jkt even though it doesn't have the dpop key. > > Warren Parad > > Founder, CTO > Secure your user data with IAM authorization as a service. Implement > Authress <https://authress.io/>. > > > On Fri, Dec 3, 2021 at 12:22 AM Mike Jones <Michael.Jones= > 40microsoft....@dmarc.ietf.org> wrote: > >> Thanks for this thoughtful analysis, Aaron. I believe you’re spot on >> that these attacks can occur “when the attacker has access to both the >> authorization code as well as the PKCE code verifier.” >> >> >> >> -- Mike >> >> >> >> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Aaron Parecki >> *Sent:* Thursday, December 2, 2021 2:58 PM >> *To:* Warren Parad <wparad=40rhosys...@dmarc.ietf.org> >> *Cc:* Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org>; >> oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request >> Parameter >> >> >> >> Hi all, I've been giving this some more thought. >> >> >> >> The problem occurs when the attacker has access to both the authorization >> code as well as the PKCE code verifier. The assumption being made with PKCE >> is that the first time the PKCE code verifier and authorization code are >> seen together is in the POST request to the token endpoint. That means if >> there is a way to observe this request, the attacker can complete the >> exchange and get an access token. >> >> >> >> Pieter's writeup in the PDF describes one way that can happen, by >> exfiltrating log files. While I still agree with the sentiment in this >> thread that this is a relatively obscure condition, I also agree that it is >> actually something that can happen in the wild, especially since there are >> entire companies built around the idea of real-time log file analysis. >> >> >> >> That said, there are other ways an attacker could get access to these two >> pieces of information. What are the different points in a request lifecycle >> that could be attacked? The beginning, the middle and the end. We've talked >> about attacking the end, which is the log file example. Attacking the >> middle involves being in the middle of the TLS connection, which we also >> know is possible with corporate network proxies and such. We haven't yet >> talked about the beginning of the request. What can observe the beginning >> of a request? Here's a concrete example: >> >> >> >> Assume the OAuth client is a single-page app in a browser. The user is >> using an ad blocker installed as a browser extension. The ad blocker can be >> configured to observe and block network requests before they are made. If >> the extension is configured to attack a particular OAuth server, the JS >> client would make the token request containing the authorization code and >> PKCE code verifier, then the extension would be able to observe that >> request, block it, and ship the two values to the attacker's server where >> they can be redeemed and associated with the attacker's own DPoP key. Even >> perfectly single-use authorization codes don't help here either, because >> the original request was completely blocked. >> >> >> >> (Sidenote: To get ahead of any counterarguments here, yes, Chrome is >> eventually migrating to their new "manifest v3" which deprecates the >> webRequest API that allows this observation in favor of a different API >> that lets the browser block requests without making the actual request data >> available to the extension, which I am assuming they are doing in no small >> part because of the possibility of what I just described. It sounds like >> Mozilla is going to follow suit, but I haven't found concrete confirmation >> of that. That said, it will be a while before these changes are rolled out >> and support for the (dangerous) webRequest API is fully dropped, so this is >> likely going to continue to be a potential attack vector for a few years at >> least.) >> >> >> >> Because of the ease of deployment of a malicious browser extension, I do >> believe this is an important attack vector to consider and is worth >> solving. I am going to save any judgment on the particular dpop_jwk >> parameter proposal for a different thread, but I wanted to at least get on >> the same page about the fact that this is something worth solving first. >> >> >> >> Aaron >> >> >> >> >> >> On Thu, Dec 2, 2021 at 10:38 AM Warren Parad <wparad= >> 40rhosys...@dmarc.ietf.org> wrote: >> >> The only mention of sophistication is this logical fallacy: >> >> If this leading security company had been penetrated, it almost >> certainly took an incredibly sophisticated attack. >> >> >> >> But it leaves out exactly what that was. And it doesn't give any insight >> into how this attack at MS would have been prevented despite the supply >> chain vulnerability based on the second point that Aaron made. If they are >> able to get the auth code, why aren't they able to get the DPoP signature? >> And then send both of these? >> >> >> Further in this case, it doesn't even matter if the attacker gets the >> access token if that access token is bound to the client, because it's >> worthless without the DPoP key. That's a much more secure solution than >> issuing non-bound Bearer tokens as a response to the bound authorization >> code. And if Bearer tokens are being used instead of bound tokens, then >> those could still end up in the logs, and be exfiltrated. >> >> >> >> In OAuth, the client already needs to authenticate with the AS, the spec >> is SHOULD, and options the client_secret already. Adding in the DPoP >> signature into the request is duplicating auth. If we don't like the client >> auth mechanisms to the AS, we should directly provide an auth RFC >> recommending better alternatives than sending a symmetric client_secret >> back to the AS. >> >> >> >> *Warren Parad* >> >> Founder, CTO >> >> Secure your user data with IAM authorization as a service. Implement >> Authress <https://authress.io/>. >> >> >> >> >> >> On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman <pieter.kasselman= >> 40microsoft....@dmarc.ietf.org> wrote: >> >> 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 >> >> >> >> *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> 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> *On Behalf Of *Aaron Parecki >> *Sent:* Wednesday 1 December 2021 00:05 >> *To:* Neil Madden <neil.mad...@forgerock.com> >> *Cc:* Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org>; >> 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> >> 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> 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. See >> https://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 >> 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 >> <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 >> <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 >> >> _______________________________________________ >> 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
