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

Nat Sakimura <sakimura@gmail.com> Tue, 29 August 2017 00:05 UTC

Return-Path: <sakimura@gmail.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 9403A124207 for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 17:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7KWjbBOJauzM for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 17:05:57 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 791E912008A for <oauth@ietf.org>; Mon, 28 Aug 2017 17:05:57 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id d81so9765614ioj.4 for <oauth@ietf.org>; Mon, 28 Aug 2017 17:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :content-transfer-encoding; bh=k80YvG4MHZoO+CXxrdeq4JHAZv0Xa3md3VMXDxn7kzk=; b=njV99UeRpEuUfOnKpJszJEMrM4cbGydC6VE4KLsIYTcky9lJeX3qD5O1yQhjbK5eL7 ek6GyzTqf6T3TLDeVXxQJfP6k9g6St46zUrLY8ULWqwlh9fiZDyXByxxh6Pl64ICSITs dMAfaM3UMPyv77fZSIIYyBvaOw80XeMibzZvdAEIDcin7NcXm3+UZK8ztqNx50JCVJnI PtuaHENoagasv3orlfl0Gx3/Zfgvm3pankFi1rh2ggjxG5w7m6csCwWe0ZF+pf3J37gU j90M2+rijj+14CRQHlZYT+5vjVYoj/plFqFX6mEet8m0Pa8qLeXAn84UNiPQi9vyZDA+ xtFQ==
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:content-transfer-encoding; bh=k80YvG4MHZoO+CXxrdeq4JHAZv0Xa3md3VMXDxn7kzk=; b=A3DNxxZMbIYYE1Rd8NqYWt+zJt5G73hHOiu8kmlgINsRM/9PBxFKHa3MGzTRAiRrkz UQUHJ9zDQvIULxALhef0tlvMz0IUFxygwV0lrfuGwOORjEtfSfQQg7QGRS1j4CZnfvMo fgMKoFWMPVMMiKzJYtuh4Ae3g82i7lGdfB1qoLb4lqJ67cgQrpBtz2tifbkNKYZA6k2S 0vpmA7scFyU7ERYaOEDrHaVsh4vbTyhRY0UhZa3Ypoyj7XDm7a3qqZIxBYrft0jOXZ36 4zysWf18SzkHpWSiQtMm1BtHIFVi/3KWUonPll+BoMU2JAK/6VD9tB8PfLYY2FiyBB5o 1zuA==
X-Gm-Message-State: AHYfb5i1LH8G1u8KmGckn8puEton4FS/DswuSRkb+4ngzsyYwAX+2sLp j5FvGEXQHvRTgiszvYvVWwdo0MqolA==
X-Received: by 10.107.176.81 with SMTP id z78mr2368665ioe.81.1503965156620; Mon, 28 Aug 2017 17:05:56 -0700 (PDT)
Received: from 661309549932 named unknown by gmailapi.google.com with HTTPREST; Mon, 28 Aug 2017 17:05:54 -0700
Received: from 661309549932 named unknown by gmailapi.google.com with HTTPREST; Mon, 28 Aug 2017 17:05:53 -0700
From: Nat Sakimura <sakimura@gmail.com>
In-Reply-To: <8AF2F7D2-F0A1-4D24-979C-07CC3BEE5B79@lodderstedt.net>
References: <CA+k3eCQ=2HLU_TfGgMZUM4PH+X6dsys8gsieqdXq=HNLut9Y8w@mail.gmail.com> <B8138670-12ED-4CCD-99B9-7DB93CBB014F@ve7jtb.com> <8AF2F7D2-F0A1-4D24-979C-07CC3BEE5B79@lodderstedt.net>
MIME-Version: 1.0
Date: Mon, 28 Aug 2017 17:05:54 -0700
Message-ID: <CABzCy2B81sQuoQCNx48jON=5bH8MY9NMJSVcnb5cVgn4D_Oa0w@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>, John Bradley <ve7jtb@ve7jtb.com>, oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
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: Tue, 29 Aug 2017 00:05:59 -0000

+1 Sent from Astro for Android On 2017-08-29 at 4:33 AM, Torsten
wrote: +1 for removing tls_client_auth_root Am 28.08.2017 um 20:24
schrieb John Bradley <ve7jtb@ve7jtb.com>;: 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
_______________________________________________ OAuth mailing list
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth