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

Discussion:

Brian Campbell

2017-04-21 22:41:47 UTC

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 <

I support adoption of draft-campbell-oauth-mtls.
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/].

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.

John Bradley

2017-04-22 00:18:40 UTC

Permalink

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.

Thanks, James, for the adoption support as well as the review and comments. I've tried to respond to the comments inline below.
I support adoption of draft-campbell-oauth-mtls.
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
https://www.ietf.org/mailman/listinfo/oauth

Brian Campbell

2017-05-15 18:42:35 UTC

Permalink

Post by John Bradley
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.
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 <

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/].

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.

Vladimir Dzhuvinov

2017-05-20 08:23:31 UTC

Permalink

+1 for tls_client_auth_root_dn, I find this name to be more exact.
People may find issuer_dn ambiguous.

+1 to also make it an array

Thanks!

Vladimir

Post by Brian Campbell
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?