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

[Justin Richer <[e-mail]>]

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 <[e-mail]> 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 <https://datatracker.ietf.org/doc/html/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: <[e-mail] <mailto:[e-mail]>>
> Date: Fri, Jul 28, 2017 at 12:25 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> 
> 
> 
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth