On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle <richanna= 40amazon....@dmarc.ietf.org> wrote:
> > Session cookies serve the same purpose in web apps as access tokens for > APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments of > web apps or the techniques used to secure web apps are ok for APIs as well. > > "Security issues" is a loaded term, but if you mean that there are > practical risks that are not addressed by bearer tokens (whether they be > session cookies or access tokens) then yes, I think we both agree that > there are. Otherwise we wouldn't be discussing PoP, sender-constrained > tokens, etc. TLS-based solutions mitigate some risks, while leaving others > unmitigated. Depending on your use case and threat model, these risks may > or may not present practical threats. For my use cases, they do. > > Ultimately I'd like to mitigate these risks for both service APIs and web > applications. My focus is on service APIs for a couple reasons: > > 1. Interoperability is more important when the sender and recipient aren't > necessarily owned by a single entity. I can do proprietary things in > JavaScript if I want to just as I can in client SDKs, but this breaks down > if my API implements a standard protocol and is expected to work with > off-the-shelf clients and/or implementations from other vendors. > > 2. Web applications are just a special subset of service APIs that happens > to be accessed via a browser. A solution for service APIs ought to be > reusable for web applications, or at least serve as a foundation for their > solution. > > > - Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I’m asking because I > thought the main use case was to intercept employees PC internet traffic. > > I'm working from second-hand knowledge here, but like most things in the > enterprise world, it depends. Separating employee device outbound traffic > from internal service outbound traffic requires some level of > sophistication, be it in network topology, routing rules, or configuration > rules on the TLIS appliance. > > Yeah, many major enterprises have these kinds of inspection services, Take a look at the following example: https://www.zscaler.com/resources/data-sheets/zscaler-internet-access.pdf > > - Are you saying this kind of proxy does not support mutual TLS at > all? > > From what I understand, at the very least mTLS is not universally > supported. There may be some vendors that support it, but it's not > guaranteed. The documentation for Symantec's SSL Visibility product [1] > indicates that sessions using client certificates will be rejected unless > they are exempted based on destination whitelisting Yes, that is my experience too. > (which is problematic when the destination may be a general-purpose cloud > service provider). > Is there a use case that would require you to do that? If I have a service that is hosted on AWS, then the exception would be for my service, not for AWS in general. Regards, Rifaat > > > On the other hand, I would expect these kind of proxy to understand a > lot about the protocols running through it, otherwise they cannot fulfil > their task of inspecting this traffic. > > Maybe, maybe not. In any case there's a difference between understanding > HTTP or SMTP or P2P-protocol-du-jour and understanding the > application-level protocol running on top of HTTP. There hasn't been any > need for these proxies to understand OAuth 2.0 thus far. > > [1]: > https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/Content/Topics/troubleshooting/Support_for_Client_Cert.htm > – > Annabelle Richard Backman > AWS Identity > > > On 12/1/19, 7:41 AM, "Torsten Lodderstedt" <torsten= > 40lodderstedt....@dmarc.ietf.org> wrote: > > > Annabelle, > > > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle < > richa...@amazon.com>: > > > > Torsten, > > > > I'm not tracking how cookies are relevant to the discussion. > > I’m still trying to understand why you and others argue mTLS cannot be > used in public cloud deployments (and thus focus on application level PoP). > > Session cookies serve the same purpose in web apps as access tokens > for APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments of > web apps or the techniques used to secure web apps are ok for APIs as well. > > Here are the two main arguments and my conclusions/questions: > > 1) mTLS it’s not end 2 end: although that’s true from a connection > perspective, there are solutions employed to secure the last hop(s) between > TLS terminating proxy and service (private net, VPN, TLS). That works and > is considered secure enough for (session) cookies, it should be the same > for access tokens. > > 2) TLS terminating proxies do not forward cert data: if the service > itself terminates TLS this is feasible, we do it for our > public-cloud-hosted mTLS-protected APIs. If TLS termination is provided by > a component run by the cloud provider, the question is: is this component > able to forward the client certificate to the service? If not, web apps > using certs for authentication cannot be supported straightway by the cloud > provider. Any insights? > > > I'm guessing that's because we're not on the same page regarding use > cases, so allow me to clearly state mine: > > I think we are, we are just focusing on different ends of the TLS > tunnel. My focus is on the service provider’s side, esp. public cloud > hosting, whereas you are focusing on client side TLS terminating proxies. > > > > > The use case I am concerned with is requests between services where > end-to-end TLS cannot be guaranteed. For example, an enterprise service > running on-premise, communicating with a service in the cloud, where the > enterprise's outbound traffic is routed through a TLS Inspection (TLSI) > appliance. The TLSI appliance sits in the middle of the communication, > terminating the TLS session established by the on-premise service and > establishing a separate TLS connection with the cloud service. > > > > In this kind of environment, there is no end-to-end TLS connection > between on-premise service and cloud service, and it is very unlikely that > the TLSI appliance is configurable enough to support TLS-based > sender-constraint mechanisms without significantly compromising on the > scope of "sender" (e.g., "this service at this enterprise" becomes "this > enterprise”). > > I’m not familiar with these kind of proxies, but happy to learn more > and to discuss potential solutions. > > Here are some questions: > - Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I’m asking because I > thought the main use case was to intercept employees PC internet traffic. > - Are you saying this kind of proxy does not support mutual TLS at > all? At least theoretically, the proxy could combine source and destination > to select a cert/key pair to use for outbound TLS client authentication. > > > Even if it is possible, it is likely to require advanced > configuration that is non-trivial for administrators to deploy. It's no > longer as simple as the developer passing a self-signed certificate to the > HTTP stack. > > I agree. Cert binding is established in OAuth protocol messages, which > would require the appliance to understand the protocol. On the other hand, > I would expect these kind of proxy to understand a lot about the protocols > running through it, otherwise they cannot fulfil their task of inspecting > this traffic. > > best regards, > Torsten. > > > > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > On 11/23/19, 9:50 AM, "Torsten Lodderstedt" < > tors...@lodderstedt.net> wrote: > > > > > > > >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle < > richa...@amazon.com> wrote: > >>>>>>>>> how are cookies protected from leakage, replay, injection in > a setup like this? > >> They aren’t. > > > > Thats very interesting when compared to what we are discussing with > respect to API security. > > > > It effectively means anyone able to capture a session cookie, e.g. > between TLS termination point and application, by way of an HTML injection, > or any other suitable attack is able to impersonate a legitimate user by > injecting the cookie(s) in an arbitrary user agent. The impact of such an > attack might be even worse than abusing an access token given the > (typically) broad scope of a session. > > > > TLS-based methods for sender constrained access tokens, in contrast, > prevent this type of replay, even if the requests are protected between > client and TLS terminating proxy, only. Ensuring the authenticity of the > client certificate when forwarded from TLS terminating proxy to service, > e.g. through another authenticated TLS connection, will even prevent > injection within the data center/cloud environment. > > > > I come to the conclusion that we already have the mechanism at hand > to implement APIs with a considerable higher security level than what is > accepted today for web applications. So what problem do we want to solve? > > > >> But my primary concern here isn't web browser traffic, it's calls > from services/apps running inside a corporate network to services outside a > corporate network (e.g., service-to-service API calls that pass through a > corporate TLS gateway). > > > > Can you please describe the challenges arising in these settings? I > assume those proxies won’t support CONNECT style pass through otherwise we > wouldn’t talk about them. > > > >>> 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. > >> Agreed. It's clear that there are a number of parties coming at > this from a number of different directions, and that's coloring our > perceptions. That's why I think we need to nail down the scope of what > we're trying to solve with DPoP before we can have a productive > conversation how it should work. > > > > We will do so. > > > >> – > >> Annabelle Richard Backman > >> AWS Identity > >> On 11/22/19, 10:51 PM, "Torsten Lodderstedt" < > tors...@lodderstedt.net> wrote: > >>>> 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
