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

Brian Campbell <bcampbell@pingidentity.com> Mon, 28 August 2017 17:06 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D5C5413234B for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 10:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id reObSJCttw2T for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 10:06:14 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 76E2D13218E for <oauth@ietf.org>; Mon, 28 Aug 2017 10:06:14 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id s101so3971517ioe.0 for <oauth@ietf.org>; Mon, 28 Aug 2017 10:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=WGB95LZO2p6C82cKMflFV/3tJW/6eVViUoh3x53fzyc=; b=cdVfKETr+JyKrF/aBIsM8Il2WyTSSvQHcl0ZoTKSh1A2IRf5+xkctKi+xrQme3CkRF KVp05euYxTYZHw9DMmReFxZx9SLFBC4WfzMACIm8/22QtUFtQitM9Tn5I7YhXChJbaUv wd2L9Is4H4znWhePLamLfVtO+YlzkniGXeSns=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WGB95LZO2p6C82cKMflFV/3tJW/6eVViUoh3x53fzyc=; b=E/G19IseAUR1Brf9pxxEnrD/SGOzpeyiJpwqI8LySq+OPPmKEe2q5o3rRW4uP5sxct 7me/OlEceDrQnXIat6V8jovEQ/xFD/qDf7vspyoRaFfdeISucCUXtx3eLvYpDM086FE3 ExO1Qsp1xpAmMOcmxFHb4hwyDeZECz2G2kgykaJZpWG2zPXjTpNVfhbVl7iPOBWEyQYv 9bacCqoXlDoXr/RUps0pAxuVwdmfw9AooY5Fe7zM+ddaiqsKZ4WsEm3I4Hn/+z/X+msi MA+FZX+tcZ1BiuQzTQcYnP9/9B/IhVe7cCba0K1kcp3lWtwegMkIZ+m5v9pH+DZtwRK8 VwZw==
X-Gm-Message-State: AHYfb5isurrht+6TRIRImkR1Gqllmhei6KdGOAAXJRfv7CLedTQfOwUj dc4xKbdAlc4Y5z5ZJ2ciZ4JgAFJ+xIIVpwggaOSjGznjS2ZK0hyXk5R06ulRuyjVwe9eDHR40kY 4p9th5do=
X-Received: by with SMTP id w8mr1228948ioe.6.1503939973436; Mon, 28 Aug 2017 10:06:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 28 Aug 2017 10:05:42 -0700 (PDT)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 28 Aug 2017 11:05:42 -0600
Message-ID: <CA+k3eCQ=2HLU_TfGgMZUM4PH+X6dsys8gsieqdXq=HNLut9Y8w@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144a0d8e188b80557d34f69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Lv7dCLDh-2PwKMT2fGPVAMYP21A>
Subject: [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 17:06:19 -0000

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.*