[OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)

Brian Campbell <bcampbell@pingidentity.com> Fri, 21 April 2017 22:42 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 4C17812940B for <oauth@ietfa.amsl.com>; Fri, 21 Apr 2017 15:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 viPZ8aeXMtet for <oauth@ietfa.amsl.com>; Fri, 21 Apr 2017 15:42:19 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 044CF120726 for <oauth@ietf.org>; Fri, 21 Apr 2017 15:42:19 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id g66so2747217ite.1 for <oauth@ietf.org>; Fri, 21 Apr 2017 15:42:18 -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:cc; bh=9MfHoq/HJx3WaSWp/4cf1xACZBsjK8L76zQwmswMA0Y=; b=KYqPDYpe1cqK3vzSmEZRYo5Cdz3uwlNePUvj3cyOC2Ad+Kj8S5I1xpI93AfcuCcB95 b2RVvnzVml9l+MeGYNOP21AMtZSXJ+/JWRqHO/0bCm6/8tT28vKXrsaj32ca9qyw2Gi5 3+HLfJWiYmJm29fyzmzEDORtJ9v6ZTRDFXqZM=
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:cc; bh=9MfHoq/HJx3WaSWp/4cf1xACZBsjK8L76zQwmswMA0Y=; b=d3UGRl0OuSDySpF97iWyxIyX/O/SfVAh2HskysiQ10BBO7KYs5JfmdEZQLUzoyQvd+ eANW+WnFD05Pu2tYBsgNQt5aUrLv7a4ptjYKbQfNhcqimxr9/yb5VD9hvaI+5iMTZtZq esn1njh5A74fv1QdwTqedz6HpHDPTRRgxoEDCk3+eU4J6712m+yzNz6ne6eTf/XkLhIi PZdk8uLS6E16qKAuEdWHWsYRtAeGZTUD2O2qIY1w4/o+Rb3gviStMAeMPbQZEqd1AjPv qwzxvxRxjnAjLM4FBdemEh062QZicubiTYimmin6I3cCGURLbtgBcPDFBl8CQqCVpKj7 rNUw==
X-Gm-Message-State: AN3rC/6I29dVbvhyw/7rMgevQIaQczN+5WpxrAp/mdv9c/F5HgN72Lbu fm5UTnLzY3QvLQ/57SXvrc2QYIG7J86075A=
X-Received: by with SMTP id y18mr14539327pgc.32.1492814538173; Fri, 21 Apr 2017 15:42:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Apr 2017 15:41:47 -0700 (PDT)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 21 Apr 2017 16:41:47 -0600
Message-ID: <CA+k3eCSqVmevpN_Rc5mcVborRk3hh0H6T_o8SAsJ=cJ6uw16xg@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1b65e2438cc4054db4f8a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/My6QHaADFsHLvHX08iZBaCbOLf0>
Subject: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)
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: Fri, 21 Apr 2017 22:42:21 -0000

Thanks, James, for the adoption support as well as the review and comments.
I've tried to respond to the comments inline below.

On Thu, Apr 20, 2017 at 11:33 PM, Manger, James <
James.H.Manger@team.telstra.com> wrote:

> I support adoption of draft-campbell-oauth-mtls.
> Now some comments on the doc:
> 1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified.
> Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]?
> Perhaps a base64url-encoding of a DER-encoded DN? It would actually be
> better to allow any subjectAltName to be specified, instead of a DN.

How about calling it tls_client_auth_subject and defining it as a string
and allowing it to represent the expected subject which could be in the
cert as the subject DN or a subjectAltName? For Subject DN and DN
subjectAltNames it would be the "String Representation of Distinguished
Names" and an appropriate string for the other subjectAltName types (I'll
have to look at what's there 'cause I don't know off hand and guidance or
suggested text is always more than welcome).

> 2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe
> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too
> easy to assume this pair refer to the issuer and subject fields of the cert.

The accompanying text tries to make it clear that it's the root issuer but
the tls_client_auth_issuer_dn name can certainly be changed to
tls_client_auth_root_dn or something along those lines, if folks think the
name in -01 is liable to cause confusion?

PKI chains can be complex so the expected root might not be such a stable
> concept. For example, the Let's Encrypt CA chains to an ISRG Root and an
> IdenTrust DST Root [https://letsencrypt.org/certificates/]

The goal was to provide a metadata field to express some constraint for
what is kind of expected to be a common deployment of a number of entities
participating in some OAuth API thing and are being issued certificates
from a common issuer for the group of participants.

Perhaps it should be an array of strings rather than a single value?

Or do you have suggestions for some alternative?

> 3. [§2.3] If a client dynamically registers a "jwks_uri" does this mean
> the authz server MUST automatically cope when the client updates the key(s)
> it publishes there?

If the authz server supports that kind of trust model as well as
dynamically registration, then I would expect so, yes.

> 4. [§3] An access token is bound to a specific client certificate. That is
> probably ok, but does mean all access tokens die when the client updates
> their certificate (which could be every 2 months if using Let's Encrypt).
> This at least warrants a paragraph in the Security Considerations.

In my own mind that was implied and okay because it's likely that access
tokens will have a shorter lifespan than certificates and refreshing or
getting a new access token is typically easy anyhow.

Anyway, it doesn't hurt to be explicit about it, can you propose some such
text for the Security Considerations?

> 5. [§3.1] "exp" and "nbf" values in the example need to be numbers, not
> strings (drop the quotes).

Silly mistake on my part. Thanks for catching that. Will fix.

> 6. An access token linked to a client TLS cert isn't a bearer token. The
> spec should really define a new token_type for responses from the token
> endpoint. That might not necessarily mean we needs a new HTTP
> authentication scheme as well (it might just hint that "Bearer" wasn't
> quite the right name).

Indeed "Bearer" isn't quite right and very likely a name that would be
different with the benefit of hindsight. But other than having names on the
wire that are more true to the nature of the tokens, I don't know that a
new token_type or HTTP auth scheme adds value to the use cases here.
However, they would likely make deployment of this stuff more cumbersome
and take longer.  Whereas many systems can likely plug in mutual TLS on top
of the existing token_type and HTTP auth scheme without major changes. I'm
strongly inclined to not introduce a new token_type and more inclined to
not do a new HTTP auth scheme.