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

[John Bradley <[e-mail]>]

I agree with Brian.

Trying to do anything with PKIX opens up cans of worms.  One of the reasons we have resisted to this point.

However there are server to server use cases that legitimately need this.

I agree that in general DN is a mess, I suspect that telling people to directly use the DER encoded version wont fly, so my thought was to use the RFC 4514 string representation that most tools produce.

We did talk about subject alt DNS Names, however those may not be present in eIDAS certificates that some people may need to use for legal reasons, or if it is present it might be an email.

I suspect that users of this will fall into two camps.  One that has a small set of trusted CA that are configured out of band and any certificate from those roots with the correct DN is OK.

The other group will be trying to do something more dynamic with SSL server certs (May or may not be EV)   I could see those people preferring DNS Name subject alt, or using JWKS to publish there certs.

The problem is finding the right balance of flexibility without too many options to confuse people.

I am inclined towards DN for those that are willing to suffer the pain, and JWKS_uri for everyone else.   One advantage of the JWKS_URI approach is that self signed certs should work just fine, that is something that the R&E people will want if they use this.  

For most proof of possession we should be promoting token binding as the most flexible approach as it also works with mobile without per instance registration.

John B.


> On Apr 21, 2017, at 7:41 PM, Brian Campbell <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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/ <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.
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth