Hi Neil, > On 22. Nov 2019, at 18:08, Neil Madden <neil.mad...@forgerock.com> wrote: > > On 22 Nov 2019, at 07:53, Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: >> >> >> >>> On 22. Nov 2019, at 15:24, Justin Richer <jric...@mit.edu> wrote: >>> >>> I’m going to +1 Dick and Annabelle’s question about the scope here. That >>> was the one major thing that struck me during the DPoP discussions in >>> Singapore yesterday: we don’t seem to agree on what DPoP is for. Some >>> (including the authors, it seems) see it as a quick point-solution to a >>> specific use case. Others see it as a general PoP mechanism. >>> >>> If it’s the former, then it should be explicitly tied to one specific set >>> of things. If it’s the latter, then it needs to be expanded. >> >> as a co-author of the DPoP draft I state again what I said yesterday: DPoP >> is a mechanism for sender-constraining access tokens sent from SPAs only. >> The threat to be prevented is token replay. > > I think the phrase "token replay" is ambiguous. Traditionally it refers to an > attacker being able to capture a token (or whole requests) in use and then > replay it against the same RS. This is already protected against by the use > of normal TLS on the connection between the client and the RS. I think > instead you are referring to a malicious/compromised RS replaying the token > to a different RS - which has more of the flavour of a man in the middle > attack (of the phishing kind).
I would argue TLS basically prevents leakage and not replay. The threats we try to cope with can be found in the Security BCP. There are multiple ways access tokens can leak, including referrer headers, mix-up, open redirection, browser history, and all sorts of access token leakage at the resource server Please have a look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8 also has an extensive discussion of potential counter measures, including audience restricted access tokens and a conclusion to recommend sender constrained access tokens over other mechanisms. > > But if that's the case then there are much simpler defences than those > proposed in the current draft: > > 1. Get separate access tokens for each RS with correct audience and scopes. > The consensus appears to be that this is hard to do in some cases, hence the > draft. How many deployments do you know that today are able to issue RS-specific access tokens? BTW: how would you identify the RS? I agree that would be an alternative and I’m a great fan of such tokens (and used them a lot at Deutsche Telekom) but in my perception this pattern needs still to be established in the market. Moreover, they basically protect from a rough RS (if the URL is used as audience) replaying the token someplace else, but they do not protect from all other kinds of leakage/replay (e.g. log files). > 2. Make the DPoP token be a simple JWT with an "iat" and the origin of the > RS. This stops the token being reused elsewhere but the client can reuse it > (replay it) for many requests. > 3. Issue a macaroon-based access token and the client can add a correct > audience and scope restrictions at the point of use. Why is this needed if the access token is already audience restricted? Or do you propose this as alternative? > > Protecting against the first kind of replay attacks only becomes an issue if > we assume the protections in TLS have failed. But if DPoP is only intended > for cases where mTLS can't be used, it shouldn't have to protect against a > stronger threat model in which we assume that TLS security has been lost. I agree. best regards, Torsten. > > -- Neil
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
