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

Justin Richer <> Mon, 31 July 2017 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D81A4127735 for <>; Mon, 31 Jul 2017 13:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OXtYABkIIGVw for <>; Mon, 31 Jul 2017 13:18:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 002AC131CB2 for <>; Mon, 31 Jul 2017 13:18:08 -0700 (PDT)
X-AuditID: 1209190e-00fff70000000aae-68-597f907f65f1
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F6.8B.02734.F709F795; Mon, 31 Jul 2017 16:18:07 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v6VKI6mG025517; Mon, 31 Jul 2017 16:18:07 -0400
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v6VKI45D010343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Jul 2017 16:18:06 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F487960C-52DD-462F-A4AF-A26C49260FEA"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 31 Jul 2017 16:18:04 -0400
In-Reply-To: <>
Cc: "<>" <>
To: Brian Campbell <>
References: <> <>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nols/oT7S4Ps1HYvV/28yWpx8+4rN gcljyZKfTB53j15kCWCK4rJJSc3JLEst0rdL4Mpomj+NueDXYsaKhwdnszcw/upk7GLk4JAQ MJFon+XSxcjFISSwmElidt9pVghnI6PE879H2SGch0wSG7/fAMpwcrAJqEpMX9PCBGLzClhJ bPrcyAZiMwskSfx+/4IZZCqvgL5E73NGkLCwgKPE594DYDYLUOu1u79ZQGxOgUCJnw0NrCDl zALqEu0nXUDCIkCdt5/OgVrbxSjxauoJsF4JAVmJW7MvMU9g5J+FZNsshG0QYW2JZQtfM0PY mhL7u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRlBg c0ry7WCc1OB9iFGAg1GJh7fDtD5SiDWxrLgy9xCjJAeTkiivYg9QiC8pP6UyI7E4I76oNCe1 +BCjBAezkgivfS9QjjclsbIqtSgfJiXNwaIkziuu0RghJJCeWJKanZpakFoEk5Xh4FCS4LXv B2oULEpNT61Iy8wpQUgzcXCCDOcBGj4ZpIa3uCAxtzgzHSJ/itGS49WE/9+YOA79PvGdieMY iBRiycvPS5US570Pco0ASENGaR7cTFCiSnh72PQVozjQi8K8wSBjeYBJDm7qK6CFTEALJUtr QRaWJCKkpBoYDRsexm/MjeF96Nsafb3CMkd+6ZfFZQF5VkkKMjvviBw6syXG/8w1fQMHQX6l AsWipYzSC/icytmFObf+2Oj5qfGImPvFC7t+OxYfmFy/55DtS/FNDxL+Pb3BIFAnoL5mh+ap gMIHKeWr0i4ePnjx0aE1IhufKO1SepymMs9iwpbo/+JpfOHLlViKMxINtZiLihMBNkICSi8D AAA=
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: Mon, 31 Jul 2017 20:18:12 -0000

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