Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)

Dave Tonge <dave.tonge@momentumft.co.uk> Thu, 21 February 2019 08:35 UTC

Return-Path: <dave.tonge@moneyhub.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 C5386130DC8 for <oauth@ietfa.amsl.com>; Thu, 21 Feb 2019 00:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
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 h6P_LyVL3dr5 for <oauth@ietfa.amsl.com>; Thu, 21 Feb 2019 00:35:14 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 5EADD12D4F3 for <oauth@ietf.org>; Thu, 21 Feb 2019 00:35:13 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id j13-v6so23284166ljc.2 for <oauth@ietf.org>; Thu, 21 Feb 2019 00:35:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vx5vip28Pk+DhgbghRnDcHJwksf20dWJ6cIBUdhb6+A=; b=CJRdhvpgFI6oW96cXHMtZsm+xtHYDF6r5qCVUUZ/eZEllShFebG5f8ujYXqLKZ4dL9 QcwyZLB2gqXmQtHyVu2UigNtKyasd8EL5ASGhgAvkw/kCeufmczsxKd7OVOyt6NKOlLO jcuV5KGVBRQcKOJN7bmVmLbLgoqkLDulPlhLw=
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=Vx5vip28Pk+DhgbghRnDcHJwksf20dWJ6cIBUdhb6+A=; b=c8oAXRvtCzLP/sFMaLoG50t9Jd7Dc9m42Sc1vjKcRIAKAMbLP3cQT3b+FGTGvfGSi0 ToWWUY6m8lVpA++D0UHFMSyFwBQyNnOhlqCcGjs7m2+CoGKGW61WCCtJg8BqyIGthP1B JEeRHpiGekda85/bHd6ybgQMtTc1DY/Rng/uoGbv6vlelrci4Ga1lz/kl+YWyG3QSTb5 fxBSPcDy3pvUcQLV4xDTtTC3ZEtgi1/nqxUi3Wh0l6HG7l4pAgWr/JO8nNkGTwHOQXLy fWzytn8kndxTGqia94JBudPqCIVVeqmtN/sv46qRYTrE3QkISJHIlvcm9gCzh4ZlhOM3 KWbg==
X-Gm-Message-State: AHQUAuaG4nI0nDWZmtSvwh0LRgyuFNnzmYsB0otAGOwdfVsgeelJYEgZ IOue9hWXrZ1FRCbLsBPSbCgxdnKLirA/ixa2t8WvtA==
X-Google-Smtp-Source: AHgI3IZbcS8+hysMpKJHogry8eKMOjWUOndee/x2/Nb5xaTIvSp2bQg3ERYhCrXqt+xQUDffiGBFnXae3FAoNyB7iQ0=
X-Received: by 2002:a2e:99c9:: with SMTP id l9mr22891966ljj.60.1550738111253; Thu, 21 Feb 2019 00:35:11 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <d257c821-4bab-2c8c-e65e-f5e30577fd1b@ve7jtb.com>
From: Dave Tonge <dave.tonge@momentumft.co.uk>
Date: Thu, 21 Feb 2019 09:34:59 +0100
Message-ID: <CAP-T6TSVXEOoQ6e=mYGcqAF7Q6p1Wto_zcOO_o1T-UNHRQ8VYQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Filip Skokan <panva.ip@gmail.com>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000042eae80582635afa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DsfM0lxg6l3at0uC_lZOGRGAQsE>
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 08:35:17 -0000

+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
>


--