Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt
On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle 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" 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
Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt
> 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. >- 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 (which is problematic when the destination may be a general-purpose cloud service provider). > 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" wrote: Annabelle, > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle : > > 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.
