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

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 20 February 2019 22:04 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 24862129C6A for <oauth@ietfa.amsl.com>; Wed, 20 Feb 2019 14:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 Cpek3eTykXFz for <oauth@ietfa.amsl.com>; Wed, 20 Feb 2019 14:04:24 -0800 (PST)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.100]) (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 7A85A12426E for <oauth@ietf.org>; Wed, 20 Feb 2019 14:04:24 -0800 (PST)
Received: from [91.13.151.23] (helo=[192.168.71.126]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gwZyW-0000cV-Cx; Wed, 20 Feb 2019 23:04:20 +0100
Content-Type: multipart/signed; boundary="Apple-Mail-839FC754-E9DF-4E27-9BB8-25041141D2FA"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPad Mail (16C50)
In-Reply-To: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com>
Date: Wed, 20 Feb 2019 23:04:19 +0100
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net>
References: <CA+k3eCSXRMfyXtrvXv4y5-PMHnUQDFNSrhm8re_ogy3BAVf=UQ@mail.gmail.com> <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com>
To: Filip Skokan <panva.ip@gmail.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5f39ymmc1etqMf94Ma1D93ejK4U>
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: Wed, 20 Feb 2019 22:04:29 -0000

+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>:
> 
> +1, great summary
> 
> Odesláno z iPhonu
> 
> 20. 2. 2019 v 16:10, Brian Campbell <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”,
>>> 
>>> “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?
>>> 
>>> The /token endpoint only supports client_secret_basic, and /mtls/token only supports tls_client_auth.
>>> The /token endpoint supports both methods, and /mtls/token only supports tls_client_auth.
>>> 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