IETF Logo Mail Archive

Re: [OAUTH-WG] MTLS vs. DPOP

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 07 May 2019 18:17 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 9DA08120203 for <oauth@ietfa.amsl.com>; Tue, 7 May 2019 11:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NylEz24MCWtW for <oauth@ietfa.amsl.com>; Tue, 7 May 2019 11:17:29 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D831201C9 for <oauth@ietf.org>; Tue, 7 May 2019 11:17:29 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.116]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1hO4ec-0003SU-EB; Tue, 07 May 2019 20:17:26 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-2A5A0743-8103-4BA7-B9D2-6172A64ADD6F"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPad Mail (16E227)
In-Reply-To: <CA58E903-D591-443A-87AF-B7F5287216D7@okta.com>
Date: Tue, 07 May 2019 20:17:25 +0200
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <132A5A1F-FF8C-4EBE-BF53-66564FB7C7A7@lodderstedt.net>
References: <DBBPR08MB4539BA4621AC8029AEF4F8C8FA310@DBBPR08MB4539.eurprd08.prod.outlook.com> <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> <CA58E903-D591-443A-87AF-B7F5287216D7@okta.com>
To: Karl McGuinness <kmcguinness@okta.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hSQ61bsF0OzQAuvoXCW3lvAMGK4>
Subject: Re: [OAUTH-WG] MTLS vs. DPOP
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, 07 May 2019 18:17:32 -0000


> Am 07.05.2019 um 20:09 schrieb Karl McGuinness <kmcguinness@okta.com>:
> 
> mTLS has significant challenges at scale in a multi-tenant SaaS deployment on public clouds using modern edge technologies/services.  Applications are increasingly being built using Function-as-a-Service/ephemeral workloads as well.  Additional complexity increases if you also want to support "bring your own CA”.

Can you please share the details of those challenges with us?

> 
> DPoP enables application level deployment model independent of how one’s edge or runtime is deployed/managed.  This is very valuable for SaaS providers.  We expect to eventually deploy a DPoP like solution for all client models and not just SPA. 
> 
> -Karl
> 
>> On May 7, 2019, at 10:43 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> Hi, 
>> 
>> mTLS is dead simple to use, secure, is used and can be used on a broad basis (in contrast to the token binding stuff). I also like the fact it provides both client authentication and sender-constraining.
>> 
>> We started the work on DPoP for the simple reason that SPAs don’t work well with mTLS and we want to provide a solution with somehow limited capabilities, e.g. regarding replay protection (see DPoP introduction). 
>> 
>> If someone asks me for the default solution, it’s simple: use mTLS. And if you build a SPA and want to do really security sensitive things, implement your OAuth stuff and the RS interactions in the backend of your application. 
>> 
>> DPoP is in a really early stage, let’s see where it will go.
>> 
>> best regards,
>> Torsten. 
>> 
>>> On 7. May 2019, at 10:25, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two.
>>> 
>>> I was wondering whether others in the group have a few about this aspect?
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
>>> 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
>

v2.23.0 | Report a Bug | By Email