I’d be interested in hearing why people think digital signatures are a good choice for PoP. As far as I can tell that choice has not been clearly motivated.
I have no interest in canonicalised HTTP message signing. I don’t think it’s a good idea. — Neil > On 24 Nov 2020, at 23:32, Justin Richer <jric...@mit.edu> wrote: > > 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 > > [2] https://github.com/httpwg/http-extensions/ > > >> On Nov 24, 2020, at 4:18 PM, Brian Campbell >> <bcampbell=40pingidentity....@dmarc.ietf.org> 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 >> 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 <neil.mad...@forgerock.com> >> 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/ >>> [2]: >>> 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 <f...@danielfett.de> 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 >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> -- >>>> https://danielfett.de >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> ForgeRock values your Privacy_______________________________________________ >>> 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 > -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
