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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Tue, 03 December 2019 13:20 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD30C12004F for <oauth@ietfa.amsl.com>; Tue, 3 Dec 2019 05:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuFSCl8oGXjm for <oauth@ietfa.amsl.com>; Tue, 3 Dec 2019 05:20:54 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38C3120019 for <oauth@ietf.org>; Tue, 3 Dec 2019 05:20:53 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id b15so3145796iln.3 for <oauth@ietf.org>; Tue, 03 Dec 2019 05:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7BHwHuyXqzzejnFsOGvNFROuK/3aUeSo8t5KRvuY3I0=; b=ONj4fa4j5VFb+Ape9jC8FlFaqrWFGPz2zXKPrKdH3IcLC1t9E1xq7HIw+UQeKe22az fs3y7GsAxeFkduc0jlEqIoBlRWxvKin/NP7Mkl7kpVehIazwmY9s6f8rX+90K6SUPFXS lD0LAWSfvX/4S5M6Rffs4c6NIPRTfq3H3Mf8mpDXYVUDF2jS74bNBQzW6AxJ82FIGsoT BWdaD9yvp89+CQlWA1oBdjvRYG+aNbX+441WFkgvF2qCH9mVDosLKCOEEtHeOL/KLL6b /vGU9N2GykLRck7Vllnn1B3xLCt2GWxZ7kWxUiu0R5mMKnMItuhFCy0Kc57VewAALof1 fghQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7BHwHuyXqzzejnFsOGvNFROuK/3aUeSo8t5KRvuY3I0=; b=eq2d9dKZ+aVeqLyJ37hl4H5OQ97yYU2OuehVir0pgHVAHY/BbzVChD4/FeKarhv7Z0 ulI8lTZlJGoQx1o2iDEGq5zgtcKur444Ng/SkGnqZjCBH1C+3SXi5DmaY5eYBjQ5+3N6 BBVrWtcEUqUCpIblM2EOdqTIKRuib6LhoUc42Uti79KdhzDjID5JU5n/nFBPlGAFhwux yTv9QZu+RSbcMD15CZfslxUKJoF+LqnfjiyqF8UXWptHQ3aX93EbQgXHKGIMTHzhw9zy L1JW7yJWXd2WXcQx83UFVuukOB7GG9Lfhr8bs7vhDbOGXrggZN35tO12/J9Ccffy0+ri x5fA==
X-Gm-Message-State: APjAAAXBaBremyAcgup82VpdSafAXMtluyplqdMQnrNbCdXveUFOCnBN obOKJcg6o8xsHzvI5UkBHWlSniKPbVNoG+BGiC4=
X-Google-Smtp-Source: APXvYqxRmg0a67GmmctGjAglChKh1/aF6NZbN1SvrGMmzi66fst4Rtwyd2qj+N1FuuVIdvex0w0wq6LaR1D3hYCOoYE=
X-Received: by 2002:a92:3a8e:: with SMTP id i14mr4774506ilf.255.1575379252533; Tue, 03 Dec 2019 05:20:52 -0800 (PST)
MIME-Version: 1.0
References: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com>
In-Reply-To: <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Tue, 03 Dec 2019 08:20:37 -0500
Message-ID: <CAGL6epKY7CX=7x7Dx=qfDjCzZ70+d6hcver6bFagF2RjUR-iCg@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bbdeaa0598cc9008"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/N5fGnVXqTbu0-y2HUmEqr86HcpQ>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2019 13:20:58 -0000

On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle <richanna=
40amazon.com@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.net@dmarc.ietf.org> wrote:
>
>
>     Annabelle,
>
>     > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle <
> richanna@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" <
> torsten@lodderstedt.net> wrote:
>     >
>     >
>     >
>     >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle <
> richanna@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" <
> torsten@lodderstedt.net> wrote:
>     >>>> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle <richanna=
> 40amazon.com@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-bounces@ietf.org on behalf of torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>     >>>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle <richanna=
> 40amazon.com@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-bounces@ietf.org on behalf of torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>     >>>> Hi Neil,
>     >>>>> On 22. Nov 2019, at 18:08, Neil Madden <
> neil.madden@forgerock.com> wrote:
>     >>>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt <torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>     >>>>>>> On 22. Nov 2019, at 15:24, Justin Richer <jricher@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
>