Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

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 <wparad@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.com@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-bounces@ietf.org> *On Behalf Of * Aaron Parecki
>> *Sent:* Thursday, December 2, 2021 2:58 PM
>> *To:* Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
>> *Cc:* Pieter Kasselman <pieter.kasselman=40microsoft.com@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.ch@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.com@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-bounces@ietf.org> *On Behalf Of *Warren Parad
>> *Sent:* Wednesday 1 December 2021 15:29
>> *To:* Pieter Kasselman <pieter.kasselman=40microsoft.com@dmarc.ietf.org>
>> *Cc:* Mike Jones <Michael.Jones=40microsoft.com@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.com@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-bounces@ietf.org> *On Behalf Of *Aaron Parecki
>> *Sent:* Wednesday 1 December 2021 00:05
>> *To:* Neil Madden <neil.madden@forgerock.com>
>> *Cc:* Mike Jones <Michael.Jones=40microsoft.com@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.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.  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
>>
>