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

From: Daniel Fett <[email-masked]>
Date: Wed, 1 Dec 2021 09:26:39 +0100

+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
> <[email-masked] <mailto:[email-masked]>> 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=[email-masked]
>>     <mailto:Michael.Jones=[email-masked]>> 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
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>     _______________________________________________
>     OAuth mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
https://danielfett.de

---

From: Pieter Kasselman <[email-masked]>
Date: Wed, 1 Dec 2021 15:14:17 +0000

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 <[email-masked]> On Behalf Of Aaron Parecki
Sent: Wednesday 1 December 2021 00:05
To: Neil Madden <[email-masked]>
Cc: Mike Jones <Michael.Jones=[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:Michael.Jones=[email-masked]>> 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%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yymmaey9B%2BkfhDNPCzjyuHdkKMGmzSA3C7dZRAOz4cc%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%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=reAU2tGLoiZcEstAyCjd3TpYHjbC%2FxlvaSOcFdwEcqg%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
[email-masked]<mailto:[email-masked]>
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%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FijJyL4AbGch83O%2B6gxmRN%2FpwXqH5ejIa46pZ0gImy0%3D&reserved=0>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FijJyL4AbGch83O%2B6gxmRN%2FpwXqH5ejIa46pZ0gImy0%3D&reserved=0>

---

From: Warren Parad <[email-masked]>
Date: Wed, 1 Dec 2021 16:28:57 +0100

>
> (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://authress.io/>.

On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman <pieter.kasselman=
[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 1 December 2021 00:05
> *To:* Neil Madden <[email-masked]>
> *Cc:* Mike Jones <Michael.Jones=[email-masked]>;
> [email-masked]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] dpop_jkt Authorization Request
> Parameter
>
>
>
> It seems like the PDF writeup describes two possible reasons an attacker
> could get access to the authorization code and PKCE code verifier.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> On Tue, Nov 30, 2021 at 12:40 PM Neil Madden <[email-masked]>
> 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=[email-masked]> 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%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yymmaey9B%2BkfhDNPCzjyuHdkKMGmzSA3C7dZRAOz4cc%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%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=reAU2tGLoiZcEstAyCjd3TpYHjbC%2FxlvaSOcFdwEcqg%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
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FijJyL4AbGch83O%2B6gxmRN%2FpwXqH5ejIa46pZ0gImy0%3D&reserved=0>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FijJyL4AbGch83O%2B6gxmRN%2FpwXqH5ejIa46pZ0gImy0%3D&reserved=0>
>

---

From: Pieter Kasselman <[email-masked]>
Date: Thu, 2 Dec 2021 15:41:45 +0000

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 <[email-masked]> On Behalf Of Warren Parad
Sent: Wednesday 1 December 2021 15:29
To: Pieter Kasselman <pieter.kasselman=[email-masked]>
Cc: Mike Jones <Michael.Jones=[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

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?

  *   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=[email-masked]<mailto:[email-masked]>> wrote:
Hi Aaron, Neil

Cheers

Pieter

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Aaron Parecki
Sent: Wednesday 1 December 2021 00:05
To: Neil Madden <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

Aaron

- Neil

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.

                                                       -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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>

---

From: Warren Parad <[email-masked]>
Date: Thu, 2 Dec 2021 19:37:31 +0100

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

On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman <pieter.kasselman=
[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of *Warren Parad
> *Sent:* Wednesday 1 December 2021 15:29
> *To:* Pieter Kasselman <pieter.kasselman=[email-masked]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request
> Parameter
>
>
>
> *Warren Parad*
> 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>
> .
>
>
>
>
>
> <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>
> .
>
>
>
> <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>,
> <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>
>
>
>
> <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>
>
> <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>
>
>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 2 Dec 2021 14:58:21 -0800

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=
[email-masked]> wrote:

>>  If this leading security company had been penetrated, it almost
>> certainly took an incredibly sophisticated attack.
>
>
> 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
>> 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
>> 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
>> This is an alternative to
>> https://github.com/danielfett/draft-dpop/pull/86

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Dec 2021 23:21:37 +0000

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 <[email-masked]> On Behalf Of Aaron Parecki
Sent: Thursday, December 2, 2021 2:58 PM
To: Warren Parad <wparad=[email-masked]>
Cc: Pieter Kasselman <pieter.kasselman=[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

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=[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> 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.

Cheers

Pieter

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Warren Parad
Sent: Wednesday 1 December 2021 15:29
To: Pieter Kasselman <pieter.kasselman=[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

- Warren

Warren Parad

Founder, CTO

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

Aaron

On Tue, Nov 30, 2021 at 12:40 PM Neil Madden <[email-masked]<mailto:[email-masked]>> 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

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>.

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

---

From: Warren Parad <[email-masked]>
Date: Fri, 3 Dec 2021 17:01:50 +0100

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

On Fri, Dec 3, 2021 at 12:22 AM Mike Jones <Michael.Jones=
[email-masked]> 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 <[email-masked]> *On Behalf Of * Aaron Parecki
> *Sent:* Thursday, December 2, 2021 2:58 PM
> *To:* Warren Parad <wparad=[email-masked]>
> *Cc:* Pieter Kasselman <pieter.kasselman=[email-masked]>;
> [email-masked]

---

From: Warren Parad <[email-masked]>
Date: Fri, 3 Dec 2021 17:22:14 +0100

I think the allowed keys would have to be pre-registered in the AS.

Warren Parad

Founder, CTO

On Fri, Dec 3, 2021 at 5:01 PM Warren Parad <[email-masked]> 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.
>
>> 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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 3 Dec 2021 15:11:39 -0700

I can't help but wonder if defining this E2E binding allowance as a
composite s256 + dpop_jkt PKCE method might be worth (re)considering here?
As a PCKE method it'd be decoupled from the main flow and could be used in
a more targeted way for situations that call for it while not imposing the
extra cost/complexity on situations that don't need it.

On Fri, Dec 3, 2021 at 9:23 AM Warren Parad <wparad=
[email-masked]> wrote:

>>> 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.
>>>
>>>
>>>
>>> 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:
>>>
>>>
>>>
>>> We agree that ideally authorization codes and PKCE proofs would never
>>> end up in log files and one-time use would be perfectly implemented.
>>>
>>>
>>>
>>> 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

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Warren Parad <[email-masked]>
Date: Sat, 4 Dec 2021 13:45:31 +0100

I'm still struggling to see how this prevents the compromised extension
attack we are considering though. As far as I can tell the only way to
avoid it is to guarantee the auth flow is for a trusted authority to
approve the auth code exchange. We just need the user-agent to get involved
and intercept the authorization response and handle the auth code exchange
before ever passing the auth code through possibly untrusted malicious
executors. This leaves us back with the browser removing dangerous APIs or
explicitly doing the auth code exchange, which would be a larger hurdle to
cross.

For the log file exfiltration of the auth code and PKCE, I would actually
like to understand more about the nature of code reuse in this situation.
Perhaps it is just a matter of better handling in these cases, and
disallowing code reuse explicitly for public clients. Even if we believe
code reuse has to happen for confidential ones, must it also happen for
public clients? If we could prove that there exists a solution for public
clients or a lack of a need, then disallowing multi-use auth codes resolves
the exfiltration attack.

Warren Parad

Founder, CTO

On Fri, Dec 3, 2021 at 11:12 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

>>>> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization
>>>> Request Parameter
>>>>
>>>>
>>>>
>>>> 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
>>>> 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?
>>>>
>>>>
>>>> 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
>>>> sophistication of the attackers Brad Smith: Inside Microsoft during
>>>> the SolarWinds hack (fastcompany.com)
>>>> *To:* Pieter Kasselman <pieter.kasselman=[email-masked]
>>>> >
>>>> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization
>>>> Request Parameter
>>>>
>>>>
>>>>
>>>> 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).
>>>>
>>>>
>>>>
>>>> attacker could get access to the authorization code and PKCE code verifier.
>>>>
>>>>
>>>>
>>>> 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?
>>>>
>>>>
>>>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Will Bartlett <[email-masked]>
Date: Sat, 11 Dec 2021 01:50:49 +0000

Hi folks,
I'm a colleague of Pieter and Mike, working directly on the service code. I wanted to chime in with a few comments on the thread, related to a few of the responses on this thread. In particular, I'll mention a) mobile landscape b) Aaron's proposed threat c) pre-registered keys d) authorization code re-use.

One general comment is a short summary of the mobile authentication landscape. Mobile apps increasingly authenticate in OS-provided web views with shared state, e.g. Apple's WKWebView. Here then:
1. The user opens an application
2. The application uses WKWebView to open a operation system web view with https://oauth.example/authorize?response_type=code&...
3. The user authenticates (or get single-signed on) from the system web view and the web view returns an authorization code to the application
4. The application exchanges the authorization code for access and refresh tokens https://oauth.example/token
With DPoP with the propose dpop_jkt extension, there is another step to generate a key in the OS keychain between 1 and 2, and a DPoP signature added in 4. I think there's something very valuable in being able to say that **all tokens** (AC, RT, AT) that appear in the process's memory space are bound up to the security level of the operation system's keychain. Such a guarantee completely removes entire classes of threats - e.g. what if the crash dumps are sent to a OS-company / phone-manufacturer / IT department web server whenever the application crashes? Not a problem - the tokens are all bound.

Aaron mentioned another threat (manipulating URL creation using a browser extension) focused at the beginning of the flow. This analysis all sounds right to me. However, I'd comment that there are already a few mechanisms for protecting the beginning of the flow from a few different attacks. In addition to the threat Aaron describes, I also want to consider the "rouge CA" threat - e.g. an attacker compromises the corporate CA and modifies requests (substituting the attacker's DPoP key). In standards space, there are two solutions for these types of threats already. OpenID Connect (https://openid.net/specs/openid-connect-core-1_0.html) describes a solution for signed requests (using the "request" parameter) that would protect from either the rouge CA or malicious browser extension - though unfortunately, for DPoP keys, this really only works for confidential clients. And then web standards like the deprecated HPKP (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) would mitigate the rouge CA threat. Outside of standards space, I'm aware of proprietary solutions with similar goals (the Windows PRT protocol, which puts authorization parameters in a signed request on the token endpoint - see https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token for an overview or https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-oapxbc/de22df0b-1b5b-4544-8154-41eb2a4453ea for the specific request message that might contain dpop_jkt). I think of dpop_jkt _not_ as a protection for the beginning of the flow, but rather as "glue" to connect _whatever_ protection at the beginning of the flow with the DPoP protection at the end of the flow. We're still interested in doing more to protect the beginning of the flow - but probably not in the context of DPoP - but we think it makes sense to standardize this connecting piece in DPoP.

A few folks (Warren) mentioned pre-registered keys. That's part of this, of course. For me, one of the underlying assumptions is that keys would be stored in a "strong" context. This could be an OS context, or an priviledged application (like sshagent). For lowest common denominator scenarios, these keys might simply be stored in an anonymous device's OS software keychain. But, for more complex scenarios, like employees of high security businesses (e.g. banks), these keys might be stored e.g. on their smartcard. One of the virtues of DPoP is that it's not concerned with the specifics of keys - as long as it can be represented as a JWK, a software key and a smartcard key are treated the same. The way we've been thinking about keys at Microsoft, users will mostly end up in a few different buckets. At one extreme, users whose employers own their devices and configure maximum management will probably require full pre-registered keys, kept in hardware. But in other case, users will have anonymous keys representing their full devices, and will grant trust to new keys representing applications on that device by signing the new keys with the old keys. These device keys are not really "pre-registered" - they aren't stored in any database - rather, they are stored in the "device token" (a Microsoft device token is a refresh-token-like artifact somewhat akin to the device_secret in https://openid.net/specs/openid-connect-native-sso-1_0.html, but with PoP binding). Given a method of signing authorization requests (as appears in OpenID Connect and Microsoft proprietary protocols), including a representation of the new key in the authorization request (in the form of dpop_jkt) formalizes this "chaining" pattern - signing the new keys with the old keys - which provides security similar to pre-registration without some of the normal concerns associated with registration.

I do also see Warren's comment on authorization code re-use - "disallowing multi-use auth codes resolves the exfiltration attack." I think this is where the theory and the practice disagree a bit. In practice, disallowing multi-use of authorization codes is quite difficult. As a first attempt, OAuth implementations generally time limit the authorization codes (e.g. to 5 minutes). But this still permits some re-use. Next, implementations write a time-bound log of recently redeemed authorization codes, and check the log on each authorization code redemption. This solves the re-use issue, to the next order of magnitude, but produces a reliability drop - clients that retry because the response was lost now see failures, and a global database of recently used authorization codes has been introduced to the service picture, a global database which has to handle the realities of CAP (https://en.wikipedia.org/wiki/CAP_theorem) - in an incident, such a global database either permits multi-use from different geographic locations (inconsistent), or becomes unavailable. Moreover, while the re-use problem is solved to another order of magnitude, it's not actually totally solved - e.g. the service has an L7 router, and when requests fail between the L7 router and the application component, the authorization codes are logged by the L7 router. Or, the user might be using a VPN, and the code gets to the VPN, but not to the OAuth service - is such a code "used" - it's possible sitting in a VPN log somewhere, but it's definitely not sitting in the OAuth provider's log of recently used authorization codes. Or, the SQL implementation has an erratta that says it is only atomic reliable on ext4 filesystems, but due to a misconfiguration, it ended up running on an xyz filesystem. This is all to say - discouraging authorization code re-use is fine. DISALLOWING authorization code re-use is a non-trivial engineering problem, which lends itself first to 98% implementations, then to 99.9% implementations, and then to 99.999% implementations - but it never seems to reach a 100% protection. Removing this enormous "black hole" of implementation details and complexity from the security analysis and being able to sit back and simply say "it doesn't matter for security if these code are one-time use or not" (but they are) is IMHO very valuable. We know that there are motivated attackers out there seeking to exploit short lived tokens, particularly those they can obtain by en-mass live data collection, such as through browser extensions. I'd hasten to add - this is all defense in depth - having already built and operationalized such invalidation databases for its authorization codes, Microsoft is not going to get rid of it. But when security minded individuals ask us questions like "If I send the authorization code to /token, but I don't get a response, or I get an invalid (5xx / server_error) response, should I assume it is used or unused or unknown-state? If unknown-state, should I send it to some /mark-used-code endpoint so that it's definitely marked as used?" I'd like to be able to tell them to just use DPoP and not worry about one time codes so much.

Thanks for reading, and I'll try to respond to any follow ups on these topics,
Will

From: OAuth <[email-masked]> On Behalf Of Warren Parad
Sent: Saturday, December 4, 2021 4:46 AM
To: Brian Campbell <bcampbell=[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

I'm still struggling to see how this prevents the compromised extension attack we are considering though. As far as I can tell the only way to avoid it is to guarantee the auth flow is for a trusted authority to approve the auth code exchange. We just need the user-agent to get involved and intercept the authorization response and handle the auth code exchange before ever passing the auth code through possibly untrusted malicious executors. This leaves us back with the browser removing dangerous APIs or explicitly doing the auth code exchange, which would be a larger hurdle to cross.

For the log file exfiltration of the auth code and PKCE, I would actually like to understand more about the nature of code reuse in this situation. Perhaps it is just a matter of better handling in these cases, and disallowing code reuse explicitly for public clients. Even if we believe code reuse has to happen for confidential ones, must it also happen for public clients? If we could prove that there exists a solution for public clients or a lack of a need, then disallowing multi-use auth codes resolves the exfiltration attack.

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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>.

On Fri, Dec 3, 2021 at 11:12 PM Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>> wrote:
I can't help but wonder if defining this E2E binding allowance as a composite s256 + dpop_jkt PKCE method might be worth (re)considering here? As a PCKE method it'd be decoupled from the main flow and could be used in a more targeted way for situations that call for it while not imposing the extra cost/complexity on situations that don't need it.

On Fri, Dec 3, 2021 at 9:23 AM Warren Parad <wparad=[email-masked]<mailto:[email-masked]>> wrote:
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>.

On Fri, Dec 3, 2021 at 5:01 PM Warren Parad <[email-masked]<mailto:[email-masked]>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>.

On Fri, Dec 3, 2021 at 12:22 AM Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Aaron Parecki
Sent: Thursday, December 2, 2021 2:58 PM
To: Warren Parad <wparad=[email-masked]<mailto:[email-masked]>>
Cc: Pieter Kasselman <pieter.kasselman=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

Aaron

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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>.

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fastcompany.com%2F90672384%2Fmicrosoft-president-brad-smith-solarwinds-exclusive&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1DvRrYin4BYn8EJ%2B41xvabgVPEiJMWyqGngkrU0MwIA%3D&reserved=0>. 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.

Cheers

Pieter

- 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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>.

Cheers

Pieter

Aaron

- Neil

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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FmSQRy9yYzietR%2BExZD3%2BqxZSsY90LXQYm0obJ3GO9s%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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=o0N2Wr%2B7oVRAjWyFq7HHRQQx7nIHq2mtywBDNUB3JSM%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.

                                                       -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Warren Parad <[email-masked]>
Date: Wed, 15 Dec 2021 20:15:23 +0100

Now it seems we have two different conversations:
(1) Is it possible to prevent malicious extensions without preregistration
(or manual intervention)
(2) Is it possible to actually prevent auth code reused in a distributed
system

For (1), it seems like the suggestion is that the *request (uri)* parameter
helps to evade MITM attacks on DPoP, if anything it just delegates the
exact same problem to another vulnerable location, and hopes that it gets
solved. If I'm missing something, I would appreciate a concrete explanation
here, I want to understand that we aren't just pushing the issue somewhere
else. Furthermore, I think we have to assume preregistration is not
possible, not because it isn't doable, but because it would undermine a
core amount of value provided by allowing unregistered jwks, and we should
seek to ensure that AS always work with unregistered jwks, which means
likely never encouraging way to register them out of band.

(2) Is really interesting, when you put it like that, instead of "it is
difficult", but really "it is impossible", then that is the first time we
actually open up the discussion in a productive way. So I want to really
thank you for suggesting the challenge here in a transparent way. Having
thought about it for the last four days, I'm starting to agree with that
sentiment, *there is no way to build a reliable single-use auth code in a
distributed system*. (without of course requiring the auth code to be
returned the AS shard that created it, if the client calls the same shard,
then we have a solution, but I'll grant that ensuring repeat communication
with the same AS shard to be challenging enough to warrant avoiding the
architecture.)

I also really like the idea of binding cryptographic material to every
possible step of the authorization pipeline. But the key word here is
possible. Passing the dpop_jwk isn't possible in every scenario. I want to
point out that scenarios involving only a SPA does this work. For scenarios
involving more than one entity in the exchange, e.g. those with
confidential clients, we must not require passing the dpop_jwk as the
user-agent will not by default nor should not know about the dpop keys that
are associated with the confidential client. Requiring this, circumvents
PARs originating from these clients, and should instead be part of the PAR
and NOT part of the authorization url.

For this reason, dpop security is at the decision of the client not the AS,
and as such (assuming dpop_jwk is the correct parameter) dpop_jwk should be
optional by decision of the client, and the AS must handle situations both
where it is provided and where it isn't. For me the language here is *the
dpop_jwk MUST NOT be required by AS...*, and must handle dpop scenarios
where the DPOP signature is provided during a later code exchange step or
earlier in the PAR. Which means the AS must accept the jwk as optional at
every step, PAR, authorization url, and during the auth code exchange. We
can encourage earlier usage, but we should not require it, let this be a
security consideration for clients. For confidential clients, since the
client secret is already required there should be no vulnerability in the
client sending the dpop_jwk during code exchange.

On to the parameter, I really dislike *dpop_jwk* as an authorization
parameter additionally for the following reasons:
* it's coupled to DPoP
* it's a single string property
* it has coupled semantics about how it must be used (i.e. this is a jwk)
That means it does not support the following:
* need for multiple jwks
* other cryptographic material based signatures that have cnf needs
* consistency with the rest of how DPoP is used, in this case we use a
fingerprint of the JWK rather than the DPoP signature, but every other step
in all of DPoP requires a signature.

At the very least we should call this *cnf_list* allowing for a list of JWK
thumbprints, or any other kind of thumbprint as necessary. I'm not saying
this is a good solution, but it is certainly better than a single property
called *dpop_jwk*.

Here's something: Moving the introduction of the jwk to the authorization
or PAR actually enables us to ignore needing the DPOP signature at any
stage for interactions with the AS. This is awesome. I'll repeat. The AS
never needs to care about DPoP because the tokens generated are bound to
the client's DPoP key jwk thumbprint and so even if you give the access
token to a malicious actor, they can't do anything with it. Removing the
need for the AS to care about DPoP in any way is a huge win.

I'm sure I missed a critical part of this somewhere, so I would appreciate
any insight others have.

- Warren

Warren Parad

Founder, CTO

On Sat, Dec 11, 2021 at 2:51 AM Will Bartlett <wibartle=
[email-masked]> wrote:

> Hi folks,
>
> I'm a colleague of Pieter and Mike, working directly on the service code.
> I wanted to chime in with a few comments on the thread, related to a few of
> the responses on this thread. In particular, I'll mention a) mobile
> landscape b) Aaron's proposed threat c) pre-registered keys d)
> authorization code re-use.
>
>
>
> One general comment is a short summary of the mobile authentication
> landscape. Mobile apps increasingly authenticate in OS-provided web views
> with shared state, e.g. Apple's WKWebView. Here then:
>
> 2. The application uses WKWebView to open a operation system web view with
> https://oauth.example/authorize?response_type=code&...
>
> 3. The user authenticates (or get single-signed on) from the system web
> view and the web view returns an authorization code to the application
>
> With DPoP with the propose dpop_jkt extension, there is another step to
> generate a key in the OS keychain between 1 and 2, and a DPoP signature
> added in 4. I think there's something very valuable in being able to say
> that **all tokens** (AC, RT, AT) that appear in the process’s memory space
> are bound up to the security level of the operation system's keychain. Such
> a guarantee completely removes entire classes of threats - e.g. what if the
> crash dumps are sent to a OS-company / phone-manufacturer / IT department
> web server whenever the application crashes? Not a problem - the tokens are
> all bound.
>
>
>
> Aaron mentioned another threat (manipulating URL creation using a browser
> extension) focused at the beginning of the flow. This analysis all sounds
> right to me. However, I'd comment that there are already a few mechanisms
> for protecting the beginning of the flow from a few different attacks. In
> addition to the threat Aaron describes, I also want to consider the "rouge
> CA" threat - e.g. an attacker compromises the corporate CA and modifies
> requests (substituting the attacker's DPoP key). In standards space, there
> are two solutions for these types of threats already. OpenID Connect (
> https://openid.net/specs/openid-connect-core-1_0.html) describes a
> solution for signed requests (using the "request" parameter) that would
> protect from either the rouge CA or malicious browser extension - though
> unfortunately, for DPoP keys, this really only works for confidential
> clients. And then web standards like the deprecated HPKP (
> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) would mitigate the
> rouge CA threat. Outside of standards space, I'm aware of proprietary
> solutions with similar goals (the Windows PRT protocol, which puts
> authorization parameters in a signed request on the token endpoint - see
> https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token
> for an overview or
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-oapxbc/de22df0b-1b5b-4544-8154-41eb2a4453ea
> for the specific request message that might contain dpop_jkt). I think of
> dpop_jkt _not_ as a protection for the beginning of the flow, but rather as
> "glue" to connect _whatever_ protection at the beginning of the flow with
> the DPoP protection at the end of the flow. We're still interested in doing
> more to protect the beginning of the flow - but probably not in the context
> of DPoP - but we think it makes sense to standardize this connecting piece
> in DPoP.
>
>
>
> A few folks (Warren) mentioned pre-registered keys. That's part of this,
> of course. For me, one of the underlying assumptions is that keys would be
> stored in a "strong" context. This could be an OS context, or an
> priviledged application (like sshagent). For lowest common denominator
> scenarios, these keys might simply be stored in an anonymous device's OS
> software keychain. But, for more complex scenarios, like employees of high
> security businesses (e.g. banks), these keys might be stored e.g. on their
> smartcard. One of the virtues of DPoP is that it's not concerned with the
> specifics of keys - as long as it can be represented as a JWK, a software
> key and a smartcard key are treated the same. The way we've been thinking
> about keys at Microsoft, users will mostly end up in a few different
> buckets. At one extreme, users whose employers own their devices and
> configure maximum management will probably require full pre-registered
> keys, kept in hardware. But in other case, users will have anonymous keys
> representing their full devices, and will grant trust to new keys
> representing applications on that device by signing the new keys with the
> old keys. These device keys are not really "pre-registered" - they aren't
> stored in any database - rather, they are stored in the "device token" (a
> Microsoft device token is a refresh-token-like artifact somewhat akin to
> the device_secret in
> https://openid.net/specs/openid-connect-native-sso-1_0.html, but with PoP
> binding). Given a method of signing authorization requests (as appears in
> OpenID Connect and Microsoft proprietary protocols), including a
> representation of the new key in the authorization request (in the form of
> dpop_jkt) formalizes this "chaining" pattern - signing the new keys with
> the old keys - which provides security similar to pre-registration without
> some of the normal concerns associated with registration.
>
>
>
> I do also see Warren's comment on authorization code re-use - "disallowing
> multi-use auth codes resolves the exfiltration attack." I think this is
> where the theory and the practice disagree a bit. In practice, disallowing
> multi-use of authorization codes is quite difficult. As a first attempt,
> OAuth implementations generally time limit the authorization codes (e.g. to
> 5 minutes). But this still permits some re-use. Next, implementations write
> a time-bound log of recently redeemed authorization codes, and check the
> log on each authorization code redemption. This solves the re-use issue, to
> the next order of magnitude, but produces a reliability drop - clients that
> retry because the response was lost now see failures, and a global database
> of recently used authorization codes has been introduced to the service
> picture, a global database which has to handle the realities of CAP (
> https://en.wikipedia.org/wiki/CAP_theorem) - in an incident, such a
> global database either permits multi-use from different geographic
> locations (inconsistent), or becomes unavailable. Moreover, while the
> re-use problem is solved to another order of magnitude, it's not actually
> totally solved - e.g. the service has an L7 router, and when requests fail
> between the L7 router and the application component, the authorization
> codes are logged by the L7 router. Or, the user might be using a VPN, and
> the code gets to the VPN, but not to the OAuth service – is such a code
> “used” – it’s possible sitting in a VPN log somewhere, but it’s definitely
> not sitting in the OAuth provider’s log of recently used authorization
> codes. Or, the SQL implementation has an erratta that says it is only
> atomic reliable on ext4 filesystems, but due to a misconfiguration, it
> ended up running on an xyz filesystem. This is all to say - discouraging
> authorization code re-use is fine. DISALLOWING authorization code re-use is
> a non-trivial engineering problem, which lends itself first to 98%
> implementations, then to 99.9% implementations, and then to 99.999%
> implementations - but it never seems to reach a 100% protection. Removing
> this enormous "black hole" of implementation details and complexity from
> the security analysis and being able to sit back and simply say "it doesn't
> matter for security if these code are one-time use or not" (but they are)
> is IMHO very valuable. We know that there are motivated attackers out there
> seeking to exploit short lived tokens, particularly those they can obtain
> by en-mass live data collection, such as through browser extensions. I'd
> hasten to add - this is all defense in depth - having already built and
> operationalized such invalidation databases for its authorization codes,
> Microsoft is not going to get rid of it. But when security minded
> individuals ask us questions like "If I send the authorization code to
> /token, but I don't get a response, or I get an invalid (5xx /
> server_error) response, should I assume it is used or unused or
> unknown-state? If unknown-state, should I send it to some /mark-used-code
> endpoint so that it's definitely marked as used?" I'd like to be able to
> tell them to just use DPoP and not worry about one time codes so much.
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of * Warren Parad
> *Sent:* Saturday, December 4, 2021 4:46 AM
> *To:* Brian Campbell <bcampbell=[email-masked]>
> *Cc:* [email-masked]
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fastcompany.com%2F90672384%2Fmicrosoft-president-brad-smith-solarwinds-exclusive&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1DvRrYin4BYn8EJ%2B41xvabgVPEiJMWyqGngkrU0MwIA%3D&reserved=0>.
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hwr1AsVa%2B6T12vx%2BHp1f32aCO7XpyTU4uEOYxbevXU8%3D&reserved=0>
> .
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F89&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769411859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FmSQRy9yYzietR%2BExZD3%2BqxZSsY90LXQYm0obJ3GO9s%3D&reserved=0>
> .
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F86&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=o0N2Wr%2B7oVRAjWyFq7HHRQQx7nIHq2mtywBDNUB3JSM%3D&reserved=0>,
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C475178549c534d9f859c08d9b7240ca8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637742187769461842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhnP5t%2B%2B4fqs0oKHiZWrV%2BUanG3%2F7VXqYXOPYTk4t3w%3D&reserved=0>
>
>