Hey Mike, thanks for writing up the PR. Generally speaking, I think it nicely and fairly unobtrusively introduces the ability for servers to choose whether/when to use server-contributed nonces to further constrain lifetimes of DPoP proof. I've been reluctant to add something like this out of concern for introducing a lot of complexity. But this seems to do a pretty good job of it without a ton of baggage.
There is one problematic technical aspect of it, however, that I think needs to be addressed before it can be incorporated into the document. Kind of a protocol compile error, if you will. The Authorization Server-Provided Nonce section uses the 'WWW-Authenticate: DPoP ... ' header in a 401 response to a token request to ask that a nonce be included in the DPoP proof in the subsequent request(s), which is sent as the value of the DPoP header. But based on the definition in this document and the underlying RFC7235, a 'WWW-Authenticate: DPoP' header is requesting that a 'Authorization: DPoP <access-token>' header be sent in the subsequent requests. The 'Authorization: DPoP <access-token>' header is only sent to protected resources. The way Authorization header is defined (can only have one in a request) and sometimes used for client secret basic auth are some of the reasons the DPoP proof is defined as separate header and not part of the Authorization header. Unfortunately, the result is that the error/challenge mechanics need to be slightly different between the AS and RS. I think the Authorization Server-Provided Nonce needs to be provided to the client in some other way. Perhaps as a parameter in the JSON of a token endpoint error response. Or in a header somehow. Or something else that I'm not thinking of. But the way it is in the PR right now doesn't semantically work. On Fri, Sep 17, 2021 at 11:04 AM Mike Jones <Michael.Jones= 40microsoft....@dmarc.ietf.org> wrote: > We all know that using proof-of-possession with issued tokens is a means > of rendering exfiltrated tokens useless to attackers. The DPoP was created > as one of the tools to prevent this. There’s a huge amount of evidence of > successful token exfiltration attacks in the wild, some of which is > referenced at the end of this message. For instance, sometimes the > legitimate user of a client is the attacker. Once instance of this is that > some banks have cited employees stealing legitimate tokens issued on bank > computers and taking them to non-bank computers, thereby bypassing audit > controls. > > > > When reviewing DPoP with Microsoft’s identity architects, they pointed out > that DPoP as written today can still enable exfiltrated DPoP tokens to be > used by some kinds of attackers; doing so also requires that the attackers > exfiltrate DPoP proofs. This is possible when the legitimate user of a > client is the attacker. > > > > Preventing exfiltrated pre-generated DPoP proofs from being used in the > future requires the server being able to limit their lifetime. An > effective means of doing this is to include a server-provided nonce in the > DPoP proof. That puts the lifetime of DPoP proofs in control of the > server, because when a new nonce value is provided, older, possibly > pre-generated DPoP proofs become invalid at the server. > > > > The Microsoft identity server team is already internally using this > technique with the stale OAuth HTTP Signing draft. They want to be able to > use it with DPoP for the same reasons. DPoP without this won’t mitigate > the real security attacks that our systems are encountering. Note that > unless a server-provided nonce is used, what is actually being proved is > possession of a DPoP proof – not possession of the proof-of-possession key. > > > > Having discussed this with some of the editors, I have created a pull > request adding the optional use of server-provided nonces to DPoP. This > will break no existing deployments. But it will enable new deployments to > choose to use server-contributed nonces to limit DPoP proof lifetimes, both > for authorization servers and resource servers. The pull request is at > https://github.com/danielfett/draft-dpop/pull/81/. Reviews of the PR are > welcomed. I propose that we merge it and publish draft -04 sometime next > week, pending review feedback. > > > > ==== > > > > My colleague Pieter Kasselman assembled some examples of successful token > exfiltration attacks in the public domain (and helped review the PR). > Those follow, for your reading pleasure. > > 1. Introducing a new phishing technique for compromising Office 365 > accounts (o365blog.com) > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517021183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nwnf6O67xIXO2u0cYFkZBnJrnOl0P6JR1MrXdNLgrr8%3D&reserved=0> > 1. It describes a phishing attack that allows the attacker to > obtain an Access Token and a Refresh Token (which is then used to obtain > additional Access Tokens). > 2. Operationalised with the AADInternals Tool > 2. The Art of the Device Code Phish - Boku (0xboku.com) > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517021183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wlEfBuS%2FnIl9qIf51hpQcU2UmFCsnuC0ksSVE%2FXdEKw%3D&reserved=0> > > > 1. It extends the above attack and shows step-by-step how to > exfiltrate a Access Token and a Refresh Token with a similar phishing > attack and then obtain additional tokens. > 2. Operationalised with AADInternals and TokenTactics > 1. DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth > Authentication Flows - YouTube > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517031142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9rMI1ay6eJ4RmTRTmHglAunMiQuLfxzZUpdk%2F012Z9Q%3D&reserved=0> > > > 1. It shows another attack to exfiltrate tokens using phishing > techniques that exploit Device Code Flow. > 2. It includes a demo of the attack that shows how it bypasses MFA > and anti-Phishing controls and then uses the PRT to get tokens and > pivot to > other services. > 3. Tools available as open source. > 1. Requesting Azure AD Request Tokens on Azure-AD-joined Machines for > Browser SSO | by Lee Christensen | Posts By SpecterOps Team Members > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fposts.specterops.io%2Frequesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517031142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OLHm5HkOAQZs0uE95OtlvUxRQlk06ylecU09%2B2hacOw%3D&reserved=0> > > > 1. Outlines how a Refresh Token can be exfiltrated from a Chrome > browser > 2. Operationalised with a tool called RequestAADRefreshToken > 1. Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkjanm.io%2Fabusing-azure-ad-sso-with-the-primary-refresh-token%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517031142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J8rcX59vjyaVlvhdzDBM%2FUELF38LEykzo84an9opNc4%3D&reserved=0> > > > 1. Extracts the Primary Refresh Token through Chrome > 2. Requires executing code on the users device to interact with the > Chrome browser, executed in the user context, no elevated privileges > needed > 3. Operationalised through ROADtoken and ROADtools. > 1. Digging further into the Primary Refresh Token - dirkjanm.io > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkjanm.io%2Fdigging-further-into-the-primary-refresh-token%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517041097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zfgTacWTD38btnIwrPWEStjIIYNfw9tRzjjP95S8gwI%3D&reserved=0> > > > 1. Describes how the PRT and session keys can be extracted from a > device (requires local admin) > 2. Operationalised through ROADtools > > -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
