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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 22 November 2019 08:05 UTC

Return-Path: <torsten@lodderstedt.net>
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 0FEB512000F for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 00:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 YbHw48lHcV1y for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 00:05:09 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 5DF0D12003E for <oauth@ietf.org>; Fri, 22 Nov 2019 00:05:09 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id s5so3103622pfh.9 for <oauth@ietf.org>; Fri, 22 Nov 2019 00:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=h+zJf6ENiW2n2fdd+Ymv3NvpVGQpDQpzddocExQVh9g=; b=Z41rhEJMBBTHkLVJY9CztYUonyhKdbC7QJ8JYzqLsptDTnoc3IAgAe06FWop717er6 q3Ml3SRD1JBLf1FxIlUevzsMpq2LO2FcuV4eFDzvE6oXPmeESXs2CHGcgf3lM7kj7Jp9 o4Qx9xRbDdlUpOWDMwrtItWg+GKXTwJFU8LXq2CNSRQcdfQRAYpvtHMxy1jTNxcUf4qN K24XelCYYuuUmNVrQsng1y4Zsv95EtZG9Q+uweQApvjhk938rFzqhphlixz2BKnf/Nk4 /YXsahtiWgNqxV6m2vZUn1kNHmMF3kaewuTR+YXX7q/4TG6H1HQYlJpitkNJF1dbJwQY TDog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=h+zJf6ENiW2n2fdd+Ymv3NvpVGQpDQpzddocExQVh9g=; b=lBBt74ZM/y++0V1noSmFLQbUEsp5PflPA3xvVw5azDjzZnyrZ61f/ovsldlkouCKBk 9cjAy8WPoQjDPRbOKfF+GdSQgoo01Cgv3J4/9PaFRMu1aFe6JMorCboMBfioWd5uOkHb nSFIQnwkqgIsQMDBrXFCl7iGCJWUAz6pzIw4cJ96mKA004QD974SryhGKfVMPFiffELF hfl+shrV2RgoucQSmnLxD08CsrActFxm47z0zoSW45RCp8qsPREgw6N6rJa1talBRxE2 CU6oCarfKEj3MDrzmOqtab6t4T/nsdlru5LjZCjNy1JQsDl4M99PgGSxHawIPsn6YrBw aXUg==
X-Gm-Message-State: APjAAAW2NjyK8nPkj8uyzg0a13DO7rQF5a2HY+4qXaFwFPomI5BpUK6Y FeEZrHhNrSuEUAJOQmlK5TniU7mLEBqKM2tC
X-Google-Smtp-Source: APXvYqx/hJ2avBSNoGUv82pueoLnGA2EMiJ04Ib9KoxDU3FEooTspyWF7MUS7hSzZAwnTuMiVoU97w==
X-Received: by 2002:a63:1f09:: with SMTP id f9mr13882878pgf.89.1574409908540; Fri, 22 Nov 2019 00:05:08 -0800 (PST)
Received: from [10.80.110.155] ([103.137.210.130]) by smtp.gmail.com with ESMTPSA id z10sm6486624pfr.139.2019.11.22.00.05.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Nov 2019 00:05:07 -0800 (PST)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <96F5D42B-9724-49E5-AB18-219FFEF8207E@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_C9B7E9B8-E81B-452E-8566-9DFEF2528EFA"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 22 Nov 2019 16:05:01 +0800
In-Reply-To: <BYAPR00MB05670A1669745F5EFE6C8302F5490@BYAPR00MB0567.namprd00.prod.outlook.com>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
References: <BYAPR00MB05670A1669745F5EFE6C8302F5490@BYAPR00MB0567.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HQY2Ks1XJ23zSsvO0htY7Fe919g>
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:05:12 -0000

Hi Mike, 

> On 22. Nov 2019, at 16:00, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
> 
> TLS on Web Servers is nearly ubiquitous now and works great.  Trying to use mutual TLS on many platforms results in a nearly intractable user experience, where the end-users are asked to install certificates into certificate stores.  Success rates for those UXs are very low.
> 
> And it's even worse than that.  If you use multiple browsers, you'll have to get the person to install the client certificates into multiple certificate stores.  For instance, on Windows, Edge, Firefox, and Chrome all use different certificate stores.
> 
> Server-side TLS works because end-users don't have to do anything difficult to use it.  That can't be said for client-side TLS.

That’s true for the user experience in a browser. That’s why we currently need an alternative for exactly this client type. 

It’s completely different for mobile apps and server-side web applications since mTLS does not have any impact on the user experience at all. 

Instead, the developer just needs to drop the key pair/cert into the HTTP stack and is done with both client authentication and sender constrained tokens. 

best regards,
Torsten. 

> 
> 				-- Mike
> 
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
> Sent: Thursday, November 21, 2019 11:54 PM
> To: Justin Richer <jricher@mit.edu>
> Cc: oauth <oauth@ietf.org>
> Subject: [EXTERNAL] Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
> 
> 
> 
>> 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.
> 
> The general mechanism for sender constrained access token should be TLS-based as recommended by the Security BCP (see https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3.2&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&amp;sdata=tvqS9JnASGHWeVZnxm0x6Rr7sSCaMX5Hd7ImpyoN%2BqE%3D&amp;reserved=0);reserved=0).
> 
> Why: that’s the easiest way from a client developer's perspective. 
> 
> Application level signatures, on the other hand, are inherently more fragile as illustrated by the OAuth 1 experience. They also require additional effort (and state) on the server side to implement replay detection. 
> 
> As kind of an entertaining read I added two posts/threads from 2010, when this WG discussed whether TLS/SSL should be the primary OAuth 2.0 security mechanism.
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FcrVvDNtbdN0E0ccmk5fLdNS66v0&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&amp;sdata=EYJcPaUIPorvsaZtHTcRhztyoc7aT5HvoISpCe%2FJi2w%3D&amp;reserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Foauth%2F%3Fgbt%3D1%26index%3Dxvlxuly1DjQiZgWZpHwgj7q2k0g&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&amp;sdata=EaoRe%2BF2guKYB%2B9exMnl3oeyAEmS3%2FvQXV2BcXgYyOg%3D&amp;reserved=0
> 
> The decision to go with TLS only was, in my opinion, one of the key success factors that made OAuth 2 so incredibly successful.
> 
> To re-state: From my perspective, DPoP is intended to be used by SPA developers only for token replay detection (or better put to provide RSs with the pre-requisites to do so).  
> 
> Why? Because we unfortunately currently lack a TLS-based mechanism for sender-constraining.
> 
> Building it on asymmetrical crypto only makes it easier to implement and to handle than methods based on shared secrets.
> 
> I also think we must look for alternative methods to enable TLS-based methods in the browser. 
> 
> 
>> 
>> 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> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&amp;sdata=hOjycnvqIbTATvSdKNl1%2BwZMcNZcip99Yozys9%2FXy8w%3D&amp;reserved=0
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&amp;sdata=hOjycnvqIbTATvSdKNl1%2BwZMcNZcip99Yozys9%2FXy8w%3D&amp;reserved=0
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth