> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org> wrote: > > The service provider doesn't own the entire connection. They have no control > over corporate or government TLS gateways, or other terminators that might > exist on the client's side. In larger organizations, or when cloud hosting is > involved, the service team may not even own all the hops on their side.
how are cookies protected from leakage, replay, injection in a setup like this? > While presumably they have some trust in them, protection against leaked > bearer tokens is an attractive defense-in-depth measure. That’s a totally valid point. But again, such a solution makes the life of client developers harder. I personally think, we as a community need to understand the pros and cons of both approaches. I also think we have not even come close to this point, which, in my option, is the prerequisite for making informed decisions. > > – > Annabelle Richard Backman > AWS Identity > > > On 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodderstedt" > <oauth-boun...@ietf.org on behalf of > torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > > >> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle >> <richanna=40amazon....@dmarc.ietf.org> wrote: >> >> The dichotomy of "TLS working" and "TLS failed" only applies to a single TLS >> connection. In non-end-to-end TLS environments, each TLS terminator between >> client and RS introduces additional token leakage/exfiltration risk, >> irrespective of the quality of the TLS connections themselves. Each >> terminator also introduces complexity for implementing mTLS, Token Binding, >> or any other TLS-based sender constraint solution, which means developers >> with non-end-to-end TLS use cases will be more likely to turn to DPoP. > > The point is we are talking about different developers here. The client > developer does not need to care about the connection between proxy and > service. She relies on the service provider to get it right. So the > developers (or DevOps or admins) of the service provider need to ensure end > to end security. And if the path is secured once, it will work for all > clients. > >> If DPoP is intended to address "cases where neither mTLS nor OAuth Token >> Binding are available" [1], then it should address this risk of token >> leakage between client and RS. If on the other hand DPoP is only intended to >> support the SPA use case and assumes the use of end-to-end TLS, then the >> document should be updated to reflect that. > > I agree. > >> >> [1]: https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1 >> >> – >> Annabelle Richard Backman >> AWS Identity >> >> >> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt" >> <oauth-boun...@ietf.org on behalf of >> torsten=40lodderstedt....@dmarc.ietf.org> wrote: >> >> 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
