Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt

Brian Campbell <> Tue, 01 August 2017 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24EE0131C84 for <>; Tue, 1 Aug 2017 12:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cpsHPLBI9zmk for <>; Tue, 1 Aug 2017 12:57:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DECD132309 for <>; Tue, 1 Aug 2017 12:57:41 -0700 (PDT)
Received: by with SMTP id o86so8466703pfj.1 for <>; Tue, 01 Aug 2017 12:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uRGh2Joj4Su/WiC6NzxIzc9przoED8D1SXa28Jdyirw=; b=PBzAYyeszXxLH0DFfaR6XeITvLNgp3axwANLsJuaecPvK/U3jYIQfIbVhElM8oJt6e 6k4amj+DiHpuUr0RKkcCOVe1vBqPtriit+ZKbclpfkcklvGOfWCqt+LxlE2H3EHTrn85 7sAwEEEUIdgmM76Oy7UnIsuJ1yICJMpW+uNrQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uRGh2Joj4Su/WiC6NzxIzc9przoED8D1SXa28Jdyirw=; b=OYS4wzU0k9UO8tsvMp7gapRLPXAmB4G7pEvEU+NnTUHfGWEWfJ9xVE/vLqSIW6apuZ gAtuLu7ubjmCeVj8h2sd2jQAakCIZ/T+111J0BQcbkXBnsE5KVb1xyps3JrOLVrAm6Iy 93pr8CZtWgsl58q0PcNvG7e8h+Lnta9/rEbuA47QN+fiCTTVVAOIks/kT1TLNoKz+rWk LuE+UdJyuOrpSScFbe1pjsw/xUusCVvX+Hebem2dcF1oeEQwNKa7jI/9TUKnlSlFeBWB demvIFEwLXiCW63FRW8eSMuVfRuXBL0e3wW9uKK87sJ7QTowR+CCdiOH30Nr5G8YwDBb 2W1g==
X-Gm-Message-State: AIVw110AXS5WlQKlBzeHtZ2p5m+hY5E2tHQJhHWpKKZ/T6o0WsOjSX54 JTY1v1wAW0DecM5+Ac0rXMT/oB0BRoqps8iEu9FVL6KD7H2/HIOZqM+9E7HrDtxpKRjpdwlwzJv Bi/S3i4M=
X-Received: by with SMTP id q4mr22194473plk.423.1501617460566; Tue, 01 Aug 2017 12:57:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Aug 2017 12:57:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Brian Campbell <>
Date: Tue, 1 Aug 2017 13:57:10 -0600
Message-ID: <>
To: Justin Richer <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="f403045fe2d453783c0555b68ff7"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Aug 2017 19:57:46 -0000

Thanks Justin.

In my original announcement email, I should have given credit to Torsten as
he made many of the updates in -03. So complements on improvements as well
as blame for issues can be pointed to him as well!

Your point about document structure is taken and we will look to make the
separation of the client authentication and resource access more clear in
future revisions. The document was aiming for something conceptually along
those same lines already. But it could be made more clear.

This could define a new “token_type” but other than having different token
type names in messages, I don't know that a new token_type or HTTP auth
scheme that would probably have to come along with it adds value to the use
cases here. However, they would very likely make deployment of this stuff
much 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.

Fair point about breaking out all the registered parameters into their own
hanging list items. It is somewhat inconsistent in that regard now. Will
look to address that in a future revision.

Using just a certificate hash for mTLS sender constrained access tokens was
intentional to allow mTLS at the resource to be used as a
proof-of-possession method only. It's part of the authorization check at
resource access and deliberately not about authentication with the RS.
Using the hash simplifies the check at the RS to one consistent way of
doing things while allowing for different modes of doing client
authentication at the AS. So the lack of parallelism with the client
authentication at the token endpoint was very much intentional. Following
from that, the need to do mTLS at the token endpoint in order to get
mTLS-bound access tokens for an RS was also kind of intentional. Though, as
§4.3 <>
attempts to describe, a public client could do mTLS at the token endpoint
with a generated self-singed cert to have an access token bound but not
actually authenticate to the token endpoint. You are certainly right that
there are other ways an AS could decide on the certificate to bind the
access token to. And other ways a cnf claim member could provide for such a
binding. But we were aiming to not provide too many options in the doc. So
my thinking here was that this draft is about mTLS and so saying how to use
mTLS for the AS to do the access token binding seemed like the most
appropriate and straightforward approach. It's not so much that mTLS
authentication is needed for the client at the token endpoint to allow for
bound access tokens. But rather that having mTLS at the token endpoint
provides a strong signal of the certificate to which to bind the issued
access token.

On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer <> wrote:

> Brian, thanks for the update. This is really coming along!
> I think the spec would benefit from a more clear separation of the client
> authentication and resource access sections. They’re really almost two
> different but related specs, but there’s enough overlap that I think that
> keeping them in the same document is fine with some structural changes
> applied. I think the content is by and large all here, it’s just jumbled
> together.
> To that end, I think there might be three major sections to this document
> (not counting the IANA, security, privacy, and other boilerplate bits). A
> suggested breakdown:
> 1) Types of mTLS client auth under consideration. This is where the
> definition of public key vs. pki comes in, and where the two authentication
> methods are defined for both registration and discovery. Some implementor’s
> notes on what kinds of things you need to store here, including the
> tls_client_auth_ client metadata extensions. For better or worse, 7591
> defines OAuth’s client model, and not just for dynamic registration.
> 2) How to use mTLS to authenticate a client. This can be a relatively
> short section that says use (1) in the context of getting an access token
> at the token endpoint. Here is where you point out that you still need to
> send client_id and that the association with the cert’s DN and the
> client_id is done at the AS (there’s existing text for this).
> 3) How to use mTLS to bind an access token. This is a bit more complicated
> because it’s the RS that needs to know the binding between the token and
> the cert’s DN, so that’s where you’d define the “cnf” stuff. An unfortunate
> side effect of spec history means that the “cnf” claim for 7662 also gets
> defined here. This is also where you’d put the bits about
> mutual_tls_sender_constrained_access_tokens for discovery and
> registration. Should this be a new “token_type”?
> A few more comments:
> §2.3 really should break out all registered parameters into their own
> hanging list items (even if you break them up into different sections like
> suggested above)
> §3 seems to say that you can only do mTLS-bound access tokens at an RS if
> you do mTLS authentication at the token endpoint. Is that an intentional
> restriction? To me these two functions seem to be more orthogonal than the
> spec is hinting at. Like, I could use private_key_jwt or PKCE or magic to
> authenticate at the RS but use mTLS at the RS, for whatever esoteric
> reason, like the AS and RS being in different security domains. Still,
> functionally, if the client’s registered parameters are enough to trust for
> token issuance, they should be enough to trust for token usage. In other
> words, have the RS depend on tls_client_auth_subject_dn etc. instead of
> "the same certificate that was used for mutual TLS at the token endpoint".
> Along those lines, §3 also depends entirely on matching a specific
> certificate hash instead of validating a certificate (and possibly it’s
> chain) and associated DN. This isn’t in parallel with the client
> authentication at the token endpoint, and I’d like to see these come
> together. Should we have a third certificate validation method in §2 for
> “certificate hash”? Or maybe we should have a separate list for
> “resource_server_auth_method” for the client?
> In any event, it still feels like there are two things that are fighting
> for attention in this spec: cert-based authentication of the client at the
> token endpoint, and cert-based PoP of the token at the resource.
>  — Justin
> On Jul 28, 2017, at 2:33 PM, Brian Campbell <>
> wrote:
> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
> the changes listed below based on comments and dissuasion in Prague.
>    draft-ietf-oauth-mtls-03 <>
>    o  Introduced metadata and client registration parameter to publish
>       and request support for mutual TLS sender constrained access
>       tokens
>    o  Added description of two methods of binding the cert and client,
>       PKI and Public Key.
>    o  Indicated that the "tls_client_auth" authentication method is for
>       the PKI method and introduced "pub_key_tls_client_auth" for the
>       Public Key method
>    o  Added implementation considerations, mainly regarding TLS stack
>       configuration and trust chain validation, as well as how to to do
>       binding of access tokens to a TLS client certificate for public
>       clients, and considerations around certificate bound access tokens
>    o  Added new section to security considerations on cert spoofing
>    o  Add text suggesting that a new cnf member be defined in the
>       future, if hash function(s) other than SHA-256 need to be used for
>       certificate thumbprints
> ---------- Forwarded message ----------
> From: <>
> Date: Fri, Jul 28, 2017 at 12:25 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
> To:
> Cc:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>         Title           : Mutual TLS Profile for OAuth 2.0
>         Authors         : Brian Campbell
>                           John Bradley
>                           Nat Sakimura
>                           Torsten Lodderstedt
>         Filename        : draft-ietf-oauth-mtls-03.txt
>         Pages           : 17
>         Date            : 2017-07-28
> Abstract:
>    This document describes Transport Layer Security (TLS) mutual
>    authentication using X.509 certificates as a mechanism for OAuth
>    client authentication to the token endpoint as well as for
>    certificate bound sender constrained access tokens.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> OAuth mailing list
> *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

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