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

Phil Hunt <phil.hunt@oracle.com> Wed, 20 February 2019 15:53 UTC

Return-Path: <phil.hunt@oracle.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 5DD65130DD3 for <oauth@ietfa.amsl.com>; Wed, 20 Feb 2019 07:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 Rzhj6wbF4Zjy for <oauth@ietfa.amsl.com>; Wed, 20 Feb 2019 07:53:04 -0800 (PST)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 E24BB127AC2 for <oauth@ietf.org>; Wed, 20 Feb 2019 07:53:03 -0800 (PST)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1KFiIgw046244; Wed, 20 Feb 2019 15:53:01 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=L4MfEG58Lij/Nynl9EdNy52C5B9kclUDdqLEzJ4I5C4=; b=g1sw2OHm9qTJRQyTBrFdv63JYaWh1SUCIoGwmXprSKetkh3aF27R23fxeOlX9SDq3xII Lvtid0VE0ZSiv1iWTflfUnBN3DEiba2Js5FuIfN1UFwFRdvFvLK8v1E90+WpKkBd8w1p hyhm2w0p9BgBzSWab4IlOWyMfdpCNMcNO87liQ9/4h5cuxVuwdiegJg4R96EHhB2Y2LE 2oAobtIrvEW3udRSq60oQL7Qo2Z8+W8E+Nf849TdgGNm1AG1Y7AgTKdq4kgJmBNi3FZa yEVGnmB+XAULIr4fGD/IVsfFBMRep7/jKybna1Fiev32DazcIbVSONGkllsmtFTw8QKL Wg==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2qp81eakp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Feb 2019 15:53:01 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1KFr1hs013150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Feb 2019 15:53:01 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1KFr1FI009073; Wed, 20 Feb 2019 15:53:01 GMT
Received: from [10.228.234.234] (/24.244.23.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2019 07:53:00 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail-B9F8CDCD-61EF-495A-8F0B-39467106C4E5"
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (16C101)
In-Reply-To: <CA+k3eCSXRMfyXtrvXv4y5-PMHnUQDFNSrhm8re_ogy3BAVf=UQ@mail.gmail.com>
Date: Wed, 20 Feb 2019 07:52:59 -0800
Cc: oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <978D1C5E-7303-46EA-B66B-A2E33B1B7B28@oracle.com>
References: <CA+k3eCSXRMfyXtrvXv4y5-PMHnUQDFNSrhm8re_ogy3BAVf=UQ@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9173 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902200113
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/W5tI3HTn5o6HviK1D_2KfMR8uBY>
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 15:53:06 -0000

+1 to Brian’s recommendations. 

The recommendations provide practical help especially to facilitate real world migration where bearer and non-bearer must co-exist without confusing end users.

Phil

> On Feb 20, 2019, at 7:10 AM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=QSgiEfkL8zIrq58HrPnZs-RWmE0KhOwmKb5vMcx3a_w&s=8TDp70QLsXKRqdjOL2tp_BMuebnBYHFisPg7H6XYJ8A&e=