With the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I think we might have a good avenue for this ECDH-with-KDF flavor of message signature in that arena instead of trying to twist it into DPoP. I think that this signing mechanism will be a better base for a general PoP effort in OAuth, and I still believe that this could live alongside DPoP’s more specific focus and intentional limitations.
— Justin [1] https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html <https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html> [2] https://github.com/httpwg/http-extensions/ <https://github.com/httpwg/http-extensions/> > On Nov 24, 2020, at 4:18 PM, Brian Campbell > <[email protected]> wrote: > > It took me some time to warm to the ECDH based idea but I do think it has a > lot of merit. For whatever it's worth, I put the idea forth as one potential > path forward during the general PoP interim meeting back in March > (https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf > > <https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf> > slide 8) but the WG consensus was to pursue a signature style PoP for the > current efforts, which was followed not long after by WG adoption of DPoP. I > could potentially see an ECDH-style-POP effort making a resurgence in the > future. But it's fundamentally pretty different. > > > > > On Tue, Nov 24, 2020 at 4:03 AM Neil Madden <[email protected] > <mailto:[email protected]>> wrote: > I agree with Daniel that I’d be a bit wary of assuming that this could never > be exploited. For example, a server-side web app that signs DPoP proofs on > behalf of client-side Javascript (to keep the key safe on the server) and > reuses the key for different users could be a risk. > > IMO this is another symptom of the general issue of using signatures for > authentication - they are too strong for the job. The fact that a signature > is equally valid to all parties and at all times means you have to be very > careful to include enough context in the signature calculation to ensure all > these kinds of attacks are eliminated. And you have to ensure that all RSes > check the context. > > Contrast that to my suggestion to use ECDH [1], which was already immune to > such attacks by including the access token in the key derivation step. (And > in such a way that requires no additional data on the wire and is almost > impossible for the RS not to verify). Even without including the access token > in the KDF, the attack could only happen if the client reused its key and the > RS reused a challenge key pair. > > Macaroon access tokens [2] are also immune to this attack, as in that case > the constraints that go in the DPoP proof are directly attached to the access > token itself so there is no way to reuse them separately. (Interestingly, > macaroons have a more direct analogue of DPoP in the form of discharge > macaroons. Such discharge macaroons are required to be “prepared” before use, > which cryptographically binds them to the equivalent of the access token - so > this kind of attack was also considered and addressed there). > > [1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/ > <https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/> > [2]: > https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/ > > <https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/> > > — Neil > >> On 24 Nov 2020, at 09:38, Daniel Fett <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Thanks Justin for bringing this to our attention. >> >> Right now, I don't think that this is a big problem and I wasn't able to >> come up with a way to improve the attack. I hope that it doesn't come back >> to haunt us when somebody does a more in-depth analysis... >> >> That said, the lack of binding to the access token makes it easier to >> precompute proofs if somebody has a limited code execution opportunity in >> the client. We have this paragraph in the spec: >> >> Malicious XSS code executed in the context of the browser-based >> client application is also in a position to create DPoP proofs with >> timestamp values in the future and exfiltrate them in conjunction >> with a token. These stolen artifacts can later be used together >> independent of the client application to access protected resources. >> The impact of such precomputed DPoP proofs can be limited somewhat by >> a browser-based client generating and using a new DPoP key for each >> new authorization code grant. >> >> The recommendation could be to use a fresh key pair for each token request. >> >> -Daniel >> >> >> Am 20.11.20 um 20:26 schrieb Justin Richer: >>> While working on an implementation of DPoP recently, I realized that the >>> value of the access token itself is not covered by the DPoP signature at >>> all. What I’m wondering is whether or not this constitutes an attack >>> surface that we care about here. Here’s how it works: >>> >>> >>> Let’s say that a client creates a DPoP key and uses that key to request two >>> tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice >>> is malicious and wants to get Bob’s stuff. Alice manages to get a hold of >>> Bob’s token value, T2, through some means. Normally DPoP wouldn’t let Alice >>> create a new request using T2 since Alice doesn’t have the client’s key. >>> However, if Alice gets the client to create a request for her using T1, she >>> can copy the signature from that request onto a new request using T2. Since >>> the signature doesn’t cover the token value and the key is the same, the RS >>> should accept both requests, right? >>> >>> An important aspect is that the parts needed to make this attack work are a >>> little weird: you’d need access to a valid signed request from the client >>> with T1 as well as access to a valid T2 attached to the same key in order >>> to make this substitution. However, this is effectively the same attack >>> area that bearer tokens have in a lot of ways, since it doesn’t require the >>> attacker gaining access to the singing key to generate or modify a >>> signature, nor does it require the attacker to generate or modify an access >>> token (merely obtain one). >>> >>> >>> I’d like to understand if this is an actual attack against DPoP. If it >>> isn’t, how is it countered by DPoP today? If it is, do we discuss in the >>> DPoP draft? I didn’t see a mention of it there. If it’s not, should we >>> discuss it there? >>> >>> >>> The old OAuth PoP draft mitigates this attack by putting the access token >>> itself inside the signature body instead of a second header. Another option >>> would be to include a hash of the token value (such as OIDC’s “at_hash” >>> method used in ID Tokens) in the DPoP payload. With either of these >>> approaches, Alice having access to T1, T2, and a signed message for T1 does >>> not allow her to use T2 effectively. >>> >>> — Justin >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> -- >> https://danielfett.de >> <https://danielfett.de/>_______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > ForgeRock values your Privacy > <https://www.forgerock.com/your-privacy>_______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
