Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt

[Rifaat Shekh-Yusef <[e-mail]>]

On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle <richanna=
[e-mail]> 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=
> [e-mail]> wrote:
>
>
>     Annabelle,
>
>     > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle <
> [e-mail]>:
>     >
>     > 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" <
> [e-mail]> wrote:
>     >
>     >
>     >
>     >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle <
> [e-mail]> 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" <
> [e-mail]> wrote:
>     >>>> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle <richanna=
> [e-mail]> 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" <
> [e-mail] on behalf of torsten=
> [e-mail]> wrote:
>     >>>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle <richanna=
> [e-mail]> 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" <
> [e-mail] on behalf of torsten=
> [e-mail]> wrote:
>     >>>> Hi Neil,
>     >>>>> On 22. Nov 2019, at 18:08, Neil Madden <
> [e-mail]> wrote:
>     >>>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt <torsten=
> [e-mail]> wrote:
>     >>>>>>> On 22. Nov 2019, at 15:24, Justin Richer <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>