Re: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication

John Bradley <ve7jtb@ve7jtb.com> Mon, 28 August 2017 18:24 UTC

Return-Path: <ve7jtb@ve7jtb.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 89EB313291B for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 11:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 flMaK7LO9VAf for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 11:24:51 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 B28A3132195 for <oauth@ietf.org>; Mon, 28 Aug 2017 11:24:51 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id 63so3700666pgc.2 for <oauth@ietf.org>; Mon, 28 Aug 2017 11:24:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Tg/6lNXLhSn5zNKZMCd0l9zZG28I+R8pou5vQm0ZtO8=; b=O5Gl3+TGGP4Kn7r7OFSZqpPIpWRue+t7fEZJVPeXEOtrzbcoVDgsBr/8R6hp3DIBIj ZzKP9L1PEjpG6e+IDtqB69Br5y2WBLz6kmKZkZDmt64MMQLxLPfM9TtIYx4ADr/xI48g xB7IiGAh3awnheqzWaMF79BASgP8ni8VMHYhoCfNR9WMdbiUZppBYe2xE22LDZ03gzH4 5yQvSayOs4kxOTq7Wzo+nDjMEw1ZLRG5AWNLXrZfy47XwrDuA3PU+IdcaM6GO6p3IBKc S6/XkyKJwDH/Dv5Zs4EJjmYBH4QJ/lqGTRiu/p+XqCYkdeO9I+YNNJwmLWclXEkg0QvJ 5ZAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Tg/6lNXLhSn5zNKZMCd0l9zZG28I+R8pou5vQm0ZtO8=; b=VYy+bP/gbRVSm2Ul+4CEtBedpeavn+9ZHaNvD1dGr/hIpz2XxNqxSG3acD3WJ7m8Cw qT1m8FlQVhUeTSZj6UTCbr1Zhk2FSPjRJ1hEncH1NwfkWPbsIamxH08Cev6XEGmI4yrJ nddxxAOOfS03+x7HPjc1MriZ6Jj7hkeLAXNCqfyZ1rMYcp6AIkzLBqYZ/Nu7XQdLdCmX BFPp/27XoTdcjU55LCjJ66zOyW90t99I3au4Egy8BDcF07ZJ/tRRDGllhY+Lh714D9YC XVhTLwyYCoDTDjlWQGETVDF01BQKFtXxu463nrvAFE3O2KTCvotqsNRlO466Q2lwlsk/ WssA==
X-Gm-Message-State: AHYfb5hvhoCkx+Up93c0HhF4HlAXtEaOpOkRGTJDwyV5zx+KlRBV4ZbO SUDr7tNiWGZHgn0b
X-Received: by 10.84.253.2 with SMTP id z2mr1851344pll.234.1503944690505; Mon, 28 Aug 2017 11:24:50 -0700 (PDT)
Received: from [10.10.14.168] (wsip-24-120-53-90.lv.lv.cox.net. [24.120.53.90]) by smtp.gmail.com with ESMTPSA id x26sm3079235pgc.77.2017.08.28.11.24.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 11:24:49 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <B8138670-12ED-4CCD-99B9-7DB93CBB014F@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 28 Aug 2017 11:24:47 -0700
In-Reply-To: <CA+k3eCQ=2HLU_TfGgMZUM4PH+X6dsys8gsieqdXq=HNLut9Y8w@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <CA+k3eCQ=2HLU_TfGgMZUM4PH+X6dsys8gsieqdXq=HNLut9Y8w@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f4030436034a15ba010557d469e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Nso0gJPqqgmkEHANVGl1FyQ7neo>
Subject: Re: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 28 Aug 2017 18:24:55 -0000

Having discussed it with Brian, I agree that removing “tls_client_auth_root” is the way to go.  
It would be hard to implement in some cases, and it is up to the AS to configure the roots it trusts for client authentication.

In reality every TLS client auth deployment is likely to have custom rules about trust.  I think this parameter adds confusion rather than reducing it.

John B.


On Aug 28, 2017, at 10:05 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> Some feedback was received recently off-list that pointed out difficulties with implementation around the "tls_client_auth_root_dn" constraint in the PKI method of OAuth MTLS client authentication from draft-ietf-oauth-mtls-03. Basically the feedback was that popular web servers such as Nginx and Apache don't expose sufficient information (easily or in some cases at all) from the client certificate chain to the application to enable proper checking of "tls_client_auth_root_dn". 
> 
> Following from that and some additional reasoning below, I'm proposing that "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls draft. 
> 
> The original idea behind the "tls_client_auth_root_dn" client metadata parameter came from an MTLS client authentication feature we added to our AS product years ago. The feature provided a way to allow the AS to more tightly constrain trust in a particular context (from an otherwise global list of trust anchors). It was fine as a specific product feature but should have stayed at that. When I added metadata to the OAuth MTLS draft, I added the "tls_client_auth_root_dn" parameter with that AS product feature in mind as something an AS *might* want to be able to do (without thinking thorough it all sufficiently). But having it as a client metadata parameter has wider implications including shifting trust control to the client and requiring ASs to support it. So, after thinking about it some more and also seeing the potential implementation difficulties, I don't believe it's appropriate to have in the specification. The AS should be at liberty to do chain validation with the PKI method however is most appropriate for it. And not be required to support one specific way of doing things implied by "tls_client_auth_root_dn" (which is even infeasible to implement in some environments).  
> 
> 
> 
> 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