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

[John Bradley <[e-mail]>]

+1 for “tls_client_auth_root_dn"

On making it an array, I think that adds complexity for little gain, and perhaps introduces new trust issues.

I think it should be one trusted root or all the trusted roots.  If you only trust 5 then configure that in the AS.

An array seems only useful where the client has a cert from x but may want to get the next one from y and not re-register. 
I think if the client or federation operator is locking itself down to specific issuers one per client should be fine.
I expect that in most cases the issuer will need to be in the trust store of the AS anyway so this is just pinning the cert to one of a limited set.

John B.

> On May 15, 2017, at 2:42 PM, Brian Campbell <[e-mail]> wrote:
> 
> I'll add text/clarification that the DN metadata fields being RFC4514 string representations of DNs in the next draft.
> 
> Given that this is a profile of use and the metadata fields are just one way to express the binding of certificate and client, and after thinking about it some more and not wanting to introduce too many variations, I feel that keeping tls_client_auth_subject_dn as the subject distinguished name of the client certificate is more straightforward and sufficient for this case.
> 
> Is there rough consensus to change "tls_client_auth_issuer_dn" to "tls_client_auth_root_dn" as was suggested? The latter name makes sense to me but I don't want to make that change without a little more input or buy-in from the WG. So please respond one way or the other, if you've got an opinion.  
> 
> Similarly I'm looking for some rough consensus around if a single root/issuer is sufficient in the metadata before potentially making any changes. Should "tls_client_auth_issuer/root_dn" remain a single DN string value or should it be an array allowing for more than one? 
> 
> 
> 
> On Fri, Apr 21, 2017 at 6:18 PM, John Bradley <[e-mail] <mailto:[e-mail]>> wrote:
> 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] <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>