Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)
Dominick Baier <dbaier@leastprivilege.com> Thu, 21 February 2019 09:09 UTC
Return-Path: <dbaier@leastprivilege.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 E2AC6129524 for <oauth@ietfa.amsl.com>; Thu, 21 Feb 2019 01:09:55 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.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 IiDCJ2zjd3OW for <oauth@ietfa.amsl.com>; Thu, 21 Feb 2019 01:09:52 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 27609130E69 for <oauth@ietf.org>; Thu, 21 Feb 2019 01:09:52 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id i5so3801042qkd.13 for <oauth@ietf.org>; Thu, 21 Feb 2019 01:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=qpu0xL/BnvkPJEJdj6lra0WxMLidB8D5g17PrGUHEZY=; b=EdujJT5uKK+GFXUHWA7JsWnKmbpq4e+KsS4JSPHpHnKebj1tdl8GSyW3LYBOHstVt5 wU3PltP9BuwPZ12wGYAG+8JSNiQpR9R8mdZLIyIycT/OmvgqOGNYIyQYiGMWdhjF1xFw 4lpa/BMOrcCwhSSceq9QF3KdwxMJOiFuMJ5mreUHwLTBXns9XD8Z0vHjdltY1QRaRzRb BxeXDHxhDpgX7CZG5Tlj3AtG7oAlvzoWUbU2042lQ0hfUuYbpQkvrN2UhCpgYcULIKNi DgV+EH4iE1EHOu40rqtuJxPc0tu1OK4DG1VRqEUu5GVbFgnCQllGHdZ1r3oTzImmkt9m Qgig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=qpu0xL/BnvkPJEJdj6lra0WxMLidB8D5g17PrGUHEZY=; b=eo3BndK6tU0tp+zOsj+ZipvDrA1fN63hunF8X9s1NZq4pbcis1/bzr6cFKFo79ZUaT eREg6zSeso/s1BZG/Bi5vtShpYyyV5fHnfLjV9EloNP3nnlZXDlqRxBYV7A11skfPR9b r2t2xrN8K0fCi2Dq7/Z+GISxoYtjC5vCjxuNb5VTAuj+1wQumfi9lfvftFJ2Cx/qQG7F aCrWzHtemdYXhgwwho5LcYwll4mbco99dtwC2he41xnis9bc59n5LjJRTvymFwzq7+1g 34XKvvAp9Xp/ZavO/LStKO3vO6LTmKDREsop7xpnXuTG4BeRfS7Y6008fKH2Dh3DoqNU ug/Q==
X-Gm-Message-State: AHQUAuZQ0offHWYLE/J6ClEsoC+cWvrW+65773XcbyuYMQ76VHvnpnvR 8cOulbcdyCII5BTpuvpxq/emlAc/PVaY29+HYDbr
X-Google-Smtp-Source: AHgI3Ib/sSHL2JYGI9ynE4rtFCIw39UeEBqqTEgJ2c0seIzTVBr+SVp7FZdvdHwl7RENJXoOf4IWRs0983MGxQauumM=
X-Received: by 2002:a37:a407:: with SMTP id n7mr26450205qke.46.1550740190962; Thu, 21 Feb 2019 01:09:50 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Feb 2019 04:09:49 -0500
From: Dominick Baier <dbaier@leastprivilege.com>
In-Reply-To: <CAP-T6TSVXEOoQ6e=mYGcqAF7Q6p1Wto_zcOO_o1T-UNHRQ8VYQ@mail.gmail.com>
References: <CA+k3eCSXRMfyXtrvXv4y5-PMHnUQDFNSrhm8re_ogy3BAVf=UQ@mail.gmail.com> <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> <d257c821-4bab-2c8c-e65e-f5e30577fd1b@ve7jtb.com> <CAP-T6TSVXEOoQ6e=mYGcqAF7Q6p1Wto_zcOO_o1T-UNHRQ8VYQ@mail.gmail.com>
MIME-Version: 1.0
Date: Thu, 21 Feb 2019 04:09:49 -0500
Message-ID: <CAO7Ng+snPmj7WOhzoj-i2jVHJnv0BQtKd-u+0z6OA=xGFqjZYQ@mail.gmail.com>
To: Dave Tonge <dave.tonge@momentumft.co.uk>, John Bradley <ve7jtb@ve7jtb.com>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000038baea058263d663"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JxauIv2H29tjfXOs3SkOS6uVkUs>
Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)
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: Thu, 21 Feb 2019 09:09:56 -0000
+1 ——— Dominick On 21. February 2019 at 09:35:35, Dave Tonge (dave.tonge@momentumft.co.uk) wrote: +1 for mtls_endpoints optional metadata Dave Tonge On Thu, 21 Feb 2019 at 00:09, John Bradley <ve7jtb@ve7jtb.com> wrote: > I agree. > > If someone really wants separate meta-data nothing stops them from having > a separate AS with its own meta-data. > > John B. > On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: > > +1 for defining an optional mtls endpoints section > > I first leaned towards a second metadata file, mainly due to the potential > token endpoint authentication method issue. But adding a secondary metadata > configuration just for this purpose seems a bit over engineered and would > take a lot of normative language to get it right. Just as an example: does > the second configuration overload or replace the primary one? On the other > hand, any client using looking for mtls based token endpoint authentication > methods must be aware of the potential mtls endpoints section. So I think > their is no real issue. > > Am 20.02.2019 um 17:59 schrieb Filip Skokan <panva..ip@gmail.com > <panva.ip@gmail.com>>: > > +1, great summary > > Odesláno z iPhonu > > 20. 2. 2019 v 16:10, Brian Campbell < > bcampbell=40pingidentity.com@dmarc.ietf..org > <bcampbell=40pingidentity.com@dmarc.ietf.org>>: > > The objective is to allow the AS to provide MTLS negotiating endpoints on > a different host and/or port so that any non-desirable side effects of > requesting client certificates during the TLS handshake can be avoided for > 'regular' clients that are not doing any MTLS. > > In all likelihood, I'd expect that any pair of MTLS and regular endpoints > have the same application logic behind them. And that just the TLS setup > that differs to accommodate the aforementioned objective. That means that > they'd support the same client authentication methods but the MTLS endpoint > would just be set up so as to get MTLS to work. When first considering it, > that seemed a bit overreaching for the spec to come out and say and more of > a deployment thing for the AS. But maybe being more prescriptive would > reduce some of the professed problematic ambiguity. As mentioned in a > previous message, referring to the mtls endpoints as aliases might be > useful in indicating that they are the same endpoint that is just known and > accessed differently based on the context of use. > > I'll grant that some of the wording in RFC 8414 can be awkward with > respect to this kind of extension. Calling it a violation is a bit over the > top though. And as much as we might try to write specs that are the final > word, there's the realities of how usage and understanding unfold in > practice. As one example, there's some discussion of the treatment of some > of the metadata in this section of a blog post about a different spec > being developed > https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. > Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being > pragmatic in the given circumstances. I suppose opinions will differ. > > It turns out that writing these specifications is kinda hard. Even when > people share the same objective (and that's often not even the case), > opinions can differ about what actually constitutes simplicity. It seems > that's where we are now. > > My stance as an individual is that the mtls_endpoints (or > mtls_endpoint_aliases) approach is reasonable and pragmatic and the most > straightforward and simple of the options put forth (i.e.. vs a metadata > parameter linking to or well-known locations to completely separate > metadata documents). As an editor, I acknowledge that there's been > disagreement about it while also noting again that the dissenting voices > come from a vocal minority of a few individuals. > > > > > On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna= > 40amazon.com@dmarc.ietf.org> wrote: > >> Neil’s example demonstrates how the mtls_endpoints approach leads to >> confusion. Consider the following metadata fragment: >> >> >> >> { >> >> “token_endpoint”: “https://as.example..com/token >> <https://as.example.com/token>”, >> >> “token_endpoint_auth_methods_supported”: [ “client_secret_basic”, >> “tls_client_auth” ], >> >> “mtls_endpoints”: { >> >> “token_endpoint”: “https://as.example.com/mtls/token” >> >> } >> >> } >> >> >> >> Which of these statements about endpoints on https://as.example.com/ are >> true? >> >> 1. The /token endpoint only supports client_secret_basic, and >> /mtls/token only supports tls_client_auth. >> 2. The /token endpoint supports both methods, and /mtls/token only >> supports tls_client_auth. >> 3. Both /token and /mtls/token support both methods. >> >> >> >> All of these could be reasonable interpretations of this metadata. When >> properties mean different things in different contexts, ambiguity abounds. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> > *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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > 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
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Brian Campbell
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Phil Hunt
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Filip Skokan
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Torsten Lodderstedt
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… John Bradley
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Dave Tonge
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Dominick Baier
- Re: [OAUTH-WG] MTLS endpoints & discovery (was so… Neil Madden