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

Filip Skokan <panva.ip@gmail.com> Fri, 22 November 2019 08:19 UTC

Return-Path: <panva.ip@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 6D908120147 for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 00:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.987
X-Spam-Level:
X-Spam-Status: No, score=-0.987 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 DiC_InB57ZPb for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 00:19:17 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 5F66C12003E for <oauth@ietf.org>; Fri, 22 Nov 2019 00:19:17 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id s71so5740812oih.11 for <oauth@ietf.org>; Fri, 22 Nov 2019 00:19:17 -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=nZ1JJSpGtmO+32lnOkDlTExV5HtI2n1dKMe62b8038Q=; b=W0yNmXul8adN+DaUfEtYsWhupJn2DXT5CilvjIoYCNPsTG2ZujUWim8BzfCcUVb5xh anNH+nO9axDKEw86c5eoELByeRc+EvJ+MadsjPrUB3CRGCj2r9P48Qn9c85vaU6aSrac uofNQ+qx6MMhCaOSy1ZOIuIEVZV375oV2wlFLXWICFDmz2H5y0tbMH7aTMCzzaNFohct Z0r8F2P9pBCtR7PIlVaIMdcrxL/p+9ozhxkzHsfp8vtZB+XxRf9bcFnO6j32H3dgJmVw d+H/lynchASTxkg8T32nvAoaINxSI1VzXj/A+1j3Mz0aJdW71JF+hCVa4V0iFdePaL8I +BUQ==
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=nZ1JJSpGtmO+32lnOkDlTExV5HtI2n1dKMe62b8038Q=; b=C2rVbvRgYhR/cNJG4ew4GY49pWgz1iEPTSNbmxbn0uO6U62xEevUWFEJN96JCX4CQ5 NyJR61o2hTldQxBoP6bHMplYyk2SPqHZgGBz2UW/J5Stl9OMUeuJmdgGFEAKMaJYXrv9 piwsbMbYj00L28aAVqs/PL1rZPFKeRnnGzV994phOJrKLGacAjpY0OJ1vr1CmzBU3eVw qKmSb7gaUXaSZpRba6eiHeI/38r9KgiDwdF56uMBA+vWj0rvYaDujItsU15XKS32DLZF m1jB6qxi7xciAYZa/apBkKUoXpqlJsKVSkGFBNXCzjod9npOzpunCEkG1YYZU0ut70Eg gPQw==
X-Gm-Message-State: APjAAAXwiHX4UirgILD6lyTWwgsflcP4C2+a1G9Of9Xre07hM1lJ5e3l yZ7ebkTxIEoX8Wvvq6pZMRT3lQ+UqO97A1DvRA==
X-Google-Smtp-Source: APXvYqyzqtJggC0eYGAQOzhFqglrQFhgQ2KcQ86u1phVkQdU/1Jr0vUoIlvGvLo9zdGPriSGPnnzEsKt1C1M7vc69Uo=
X-Received: by 2002:aca:ddc2:: with SMTP id u185mr11409197oig.174.1574410756493; Fri, 22 Nov 2019 00:19:16 -0800 (PST)
MIME-Version: 1.0
References: <2EF412B8-AF8C-4642-9BE0-1B528B0C63D5@amazon.com> <288343F2-ACF0-43E0-8577-26AF45330E5C@forgerock.com> <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com> <6DECA422-AACC-4DAA-8CD2-FF57CE02DE3E@mit.edu> <CABh6VRHoBqbQAe4U8UxXodCc8oOpOb=GRb_82gT6X9H5rp0n8Q@mail.gmail.com> <1119B3F6-01A0-4885-A352-5C719A7CDE2C@lodderstedt.net> <CABh6VRG7nZ0JhX8u8OM6cxR_2m6ZebbkCDPd_OzRHvBv2EQtkA@mail.gmail.com>
In-Reply-To: <CABh6VRG7nZ0JhX8u8OM6cxR_2m6ZebbkCDPd_OzRHvBv2EQtkA@mail.gmail.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Fri, 22 Nov 2019 09:19:05 +0100
Message-ID: <CALAqi_8j-7n_vJzRGh1DhrnvnDpNAqf_35t++GoUbSCc0DE9KQ@mail.gmail.com>
To: Rob Otto <robotto=40pingidentity.com@dmarc.ietf.org>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df17b60597eb115c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1FPe8-xRfcUXZNKz3mIwx3gD2Bk>
Subject: Re: [OAUTH-WG] 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: Fri, 22 Nov 2019 08:19:20 -0000

Rob, I agree that managing roots of trust, validating/OCSP etc is not
"easy" per se, but the MTLS setup gets really simple with the Self-Signed
Certificate Mutual-TLS Method
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-17#section-2.2> and we
made sure combined traffic is simple to signal by the AS and simple to
detect and use by clients using the mtls_endpoint_aliases discovery
metadata.

S pozdravem,
*Filip Skokan*


On Fri, 22 Nov 2019 at 09:10, Rob Otto <robotto=
40pingidentity.com@dmarc.ietf.org> wrote:

> Hi Torsten - thanks for the reply..
>
> Responses in line.
>
> Grüsse
> Rob
>
> On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt <torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> Hi Rob,
>>
>> > On 22. Nov 2019, at 15:52, Rob Otto <robotto=
>> 40pingidentity.com@dmarc..ietf.org <40pingidentity.com@dmarc.ietf.org>>
>> wrote:
>> >
>> > Hi everyone
>> >
>> > I'd agree with this. I'm looking at DPOP as an alternative and
>> ultimately simpler way to accomplish what we can already do with MTLS-bound
>> Access Tokens, for use cases such as the ones we address in Open Banking;
>> these are API transactions that demand a high level of assurance and as
>> such we absolutely must have a mechanism to constrain those tokens to the
>> intended bearer. Requiring MTLS across the ecosystem, however, adds
>> significant overhead in terms of infrastructural complexity and is always
>> going to limit the extent to which such a model can scale.
>>
>> I would like to unterstand why mTLS adds “significant overhead in terms
>> of infrastructural complexity”. Can you please dig into details?
>>
>
> I guess it's mostly that every RS-endpoint (or what sits in front of it)
> has to have a mechanism for accepting/terminating mTLS, managing roots of
> trust, validating/OCSP, etc and then passing the certificates downstream as
> headers. None of it is necessarily difficult or impossible to do in
> isolation, but I meet many many people every week who simply don't know how
> to do any of this stuff. And these are typically "network people", for want
> of a better word. There are quite a few SaaS API management and edge
> solutions out there that don't even support mTLS at all. You also have the
> difficulty in handling a combination of MTLS and non-MTLS traffic to the
> same endpoints. Again, it's possible to do, but far from straightforward.
>
>
>
>>
>> Our experience so far: It can be a headache to set up in a microservice
>> architecture with TLS terminating proxies but once it runs it’s ok. On the
>> other side, it’s easy to use for client developers and it combines client
>> authentication and sender constraining nicely.
>>
>
> I do think its an elegant solution, don't get me wrong. It's just that
> there are plenty of moving parts that you need to get right and that can be
> a challenge, particularly in large, complex environments.
>
>
>
>>
>> >
>> > DPOP, to me, appears to be a rather more elegant way of solving the
>> same problem, with the benefit of significantly reducing the complexity of
>> (and dependency on) the transport layer. I would not argue, however, that
>> it is meant to be a solution intended for ubiquitous adoption across all
>> OAuth-protected API traffic. Clients still need to manage private keys
>> under this model and my experience is that there is typically a steep
>> learning curve for developers to negotiate any time you introduce a
>> requirement to hold and use keys within  an application.
>>
>> My experience is most developer don’t even get the URL right (in the
>> signature and the value used on the receiving end). So the total cost of
>> ownership is increased by numerous support inquiries.
>>
> I'll not comment, at the risk of offending developers :)
>
>>
>> best regards,
>> Torsten.
>>
>> >
>> > I guess I'm with Justin - let's look at DPOP as an alternative to
>> MTLS-bound tokens for high-assurance use cases, at least initially, without
>> trying to make it solve every problem.
>> >
>> > Best regards
>> > Rob
>> >
>> >
>> > On Fri, 22 Nov 2019 at 07: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.
>> >
>> > I’ll repeat what I said at the mic line: My take is that we should
>> explicitly narrow down DPoP so that it does exactly one thing and solves
>> one narrow use case. And for a general solution? Let’s move that discussion
>> into the next major revision of the protocol where we’ll have a bit more
>> running room to figure things out..
>> >
>> >  — Justin
>> >
>> >> On Nov 22, 2019, at 3:13 PM, Dick Hardt <dick.hardt@gmail.com
>> <dick..hardt@gmail.com>> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <neil.madden@forgerock.com>
>> wrote:
>> >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <
>> richanna@amazon.com> wrote:
>> >>> There are key distribution challenges with that if you are doing
>> validation at the RS, but validation at the RS using either approach means
>> you’ve lost protection against replay by the RS. This brings us back to a
>> core question: what threats are in scope for DPoP, and in what contexts?
>> >>
>> >> Agreed, but validation at the RS is premature optimisation in many
>> cases. And if you do need protection against that the client can even
>> append a confirmation key as a caveat and retrospectively upgrade a bearer
>> token to a pop token. They can even do transfer of ownership by creating
>> copies of the original token bound to other certificates/public keys.
>> >>
>> >> While validation at the RS may be an optimization in many cases, it is
>> still a requirement for deployments.
>> >>
>> >> I echo Annabelle's last question: what threats are in scope (and out
>> of scope) for DPoP?
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> >
>> > --
>> >
>> > Rob Otto
>> > EMEA Field CTO/Solutions Architect
>> > robertotto@pingidentity.com
>> >
>> > c: +44 (0) 777 135 6092
>> > Connect with us:
>>
>>
>> >
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited..
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you._______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> --
> <https://www.pingidentity.com>[image: Ping Identity]
> <https://www.pingidentity.com>
> Rob Otto
> EMEA Field CTO/Solutions Architect
> robertotto@pingidentity.com
>
> c: +44 (0) 777 135 6092
> Connect with us: [image: Glassdoor logo]
> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
> LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
> logo] <https://twitter.com/pingidentity> [image: facebook logo]
> <https://www.facebook.com/pingidentitypage> [image: youtube logo]
> <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo]
> <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo]
> <https://www.pingidentity.com/en/blog.html>
> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
> <https://www.pingidentity.com/en/events/d/identify-2019.html>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>