Subject: [OAUTH-WG] MTLS and SAN

From: Justin Richer <[email-masked]>
Date: Thu, 4 Apr 2019 20:20:28 +0000

We’ve just started implementation of SAN-based certificate authentication, based on the changes in version -13 of the draft. I believe this addition is a bit unclear, due to it being added so late in the document process.

My question is how does an AS determine whether to DN or SAN for certificate checking? Corollary, are these mutually exclusive or can they be used together? Currently, the specification text lists DN and SAN as an “or” with no indication whether this is an inclusive or exclusive “or”, and what to do when there’s overlap.

This has implications both for the implementation of the server processing the request as well as the client metadata model, since the client fields are all in parallel to each other. I can see a few ways of handling this.

1) One of the fields takes precedence over the other. Say for example you choose the DN field: if it’s set, then you do DN matching and ignore the SAN fields entirely, both in the cert and in the client’s registration. Inverse is true if you choose the SAN fields over the DN but the principle is the same. We should be explicit if there’s an intended precedence between these two, and even more explicit if the DN and SAN are at equal level and the AS gets to choose. We also need to be clear if it’s an error condition if both are set simultaneously, like the way that jwks and jwks_uri are mutually exclusive.
2) You set an explicit switch in your client model that says whether to use the DN or the SAN fields in comparison, and your code branches based on that to either DN or SAN processing. This could also be added as an explicit client metadata field, or it could be an internal detail. If an internal detail, we should be explicit about there not being a predefined precedence between the fields.
3) If it’s allowable to use them together, you match everything that’s set in the client, and at least one field MUST be set.

What’s the intended behavior for implementers, and should we be more explicit about this? We are starting our implementation with (1) pending the outcome of this thread, and I’d be curious to know how others are implementing this in their systems.

Thanks,
— Justin

---

From: Filip Skokan <[email-masked]>
Date: Thu, 4 Apr 2019 22:23:21 +0200

Justin, I had the exact same question off list and believe draft 13
clarified this.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2

A client using the "tls_client_auth" authentication method MUST use exactly
one of the below metadata parameters to indicate the certificate subject
value that the authorization server is to expect when authenticating the
respective client.

Then it lists the different dn/san properties.

S pozdravem,
*Filip Skokan*

On Thu, 4 Apr 2019 at 22:20, Justin Richer <[email-masked]> wrote:

> We’ve just started implementation of SAN-based certificate authentication,
> based on the changes in version -13 of the draft. I believe this addition
> is a bit unclear, due to it being added so late in the document process.
>
> My question is how does an AS determine whether to DN or SAN for
> certificate checking? Corollary, are these mutually exclusive or can they
> be used together? Currently, the specification text lists DN and SAN as an
> “or” with no indication whether this is an inclusive or exclusive “or”, and
> what to do when there’s overlap.
>
> This has implications both for the implementation of the server processing
> the request as well as the client metadata model, since the client fields
> are all in parallel to each other. I can see a few ways of handling this.
>
>
> 1) One of the fields takes precedence over the other. Say for example you
> choose the DN field: if it’s set, then you do DN matching and ignore the
> SAN fields entirely, both in the cert and in the client’s registration.
> Inverse is true if you choose the SAN fields over the DN but the principle
> is the same. We should be explicit if there’s an intended precedence
> between these two, and even more explicit if the DN and SAN are at equal
> level and the AS gets to choose. We also need to be clear if it’s an error
> condition if both are set simultaneously, like the way that jwks and
> jwks_uri are mutually exclusive.
> 2) You set an explicit switch in your client model that says whether to
> use the DN or the SAN fields in comparison, and your code branches based on
> that to either DN or SAN processing. This could also be added as an
> explicit client metadata field, or it could be an internal detail. If an
> internal detail, we should be explicit about there not being a predefined
> precedence between the fields.
> 3) If it’s allowable to use them together, you match everything that’s set
> in the client, and at least one field MUST be set.
>
>
> What’s the intended behavior for implementers, and should we be more
> explicit about this? We are starting our implementation with (1) pending
> the outcome of this thread, and I’d be curious to know how others are
> implementing this in their systems.
>
> Thanks,
> — Justin
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Apr 2019 20:36:06 +0000

Thank you, I did miss that text. This should be called out more explicitly in §2.1, perhaps by specifying that it is only one field. This still doesn’t set precedence, but it implies that it’s an error for a client to have more than one field set of the available options. Is that your read on this as well?

— Justin

On Apr 4, 2019, at 4:23 PM, Filip Skokan <[email-masked]<mailto:[email-masked]>> wrote:

Justin, I had the exact same question off list and believe draft 13 clarified this.

A client using the "tls_client_auth" authentication method MUST use exactly one of the below metadata parameters to indicate the certificate subject value that the authorization server is to expect when authenticating the respective client.

S pozdravem,
Filip Skokan

On Thu, 4 Apr 2019 at 22:20, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
We’ve just started implementation of SAN-based certificate authentication, based on the changes in version -13 of the draft. I believe this addition is a bit unclear, due to it being added so late in the document process.

Thanks,
— Justin

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Thu, 4 Apr 2019 22:54:42 +0200

Yes.

S pozdravem,
*Filip Skokan*

On Thu, 4 Apr 2019 at 22:36, Justin Richer <[email-masked]> wrote:

> Thank you, I did miss that text. This should be called out more explicitly
> in §2.1, perhaps by specifying that it is only one field. This still
> doesn’t set precedence, but it implies that it’s an error for a client to
> have more than one field set of the available options. Is that your read on
> this as well?
>
> — Justin
>
> On Apr 4, 2019, at 4:23 PM, Filip Skokan <[email-masked]> wrote:
>
> A client using the "tls_client_auth" authentication method MUST use
> exactly one of the below metadata parameters to indicate the certificate
> subject value that the authorization server is to expect when
> authenticating the respective client.
>
>> We’ve just started implementation of SAN-based certificate
>> authentication, based on the changes in version -13 of the draft. I believe
>> this addition is a bit unclear, due to it being added so late in the
>> document process.
>>
>> This has implications both for the implementation of the server
>> processing the request as well as the client metadata model, since the
>> client fields are all in parallel to each other. I can see a few ways of
>> handling this.
>>
>>
>> 3) If it’s allowable to use them together, you match everything that’s
>> set in the client, and at least one field MUST be set.
>>
>>

---

From: Jim Willeke <[email-masked]>
Date: Fri, 5 Apr 2019 03:17:45 -0400

I may not be completely up to date in this discussion,  However, RFC 6125
<https://tools.ietf.org/html/rfc6125#section-6>
"In general, *this specification recommends and prefers* use of
   subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the
   subject field (CN-ID) where possible, as more completely described in
   the following sections.  However, specifications that reuse this one
   can legitimately encourage continued support for the CN-ID identifier
   type if they have good reasons to do so, such as backward
   compatibility with deployed infrastructure (see, for example,
   [EV-CERTS])."

And I believe this is the more common practice.
https://security.stackexchange.com/questions/175786/is-it-required-to-have-the-same-domain-name-and-common-name-for-ssl-certificate/175788#175788

--
-jim
Jim Willeke

On Thu, Apr 4, 2019 at 4:55 PM Filip Skokan <[email-masked]> wrote:

>> Thank you, I did miss that text. This should be called out more
>> explicitly in §2.1, perhaps by specifying that it is only one field. This
>> still doesn’t set precedence, but it implies that it’s an error for a
>> client to have more than one field set of the available options. Is that
>> your read on this as well?
>>
>> — Justin
>>
>>> 1) One of the fields takes precedence over the other. Say for example
>>> you choose the DN field: if it’s set, then you do DN matching and ignore
>>> the SAN fields entirely, both in the cert and in the client’s registration.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 Apr 2019 11:54:09 -0600

Yes, the intent is that the client be configured (dynamically or statically
or however that comes to be) with one and only one expected subject, which
also includes the location in the certificate that subject will be. And
that is checked against at authentication time.

As the writer of the questionable text in question, it does seem pretty
clear to me as it is now. But as the writer, I'm also probably not well
positioned to see how it could be made more clearer. So if either of you
gentlemen have concrete text suggestions to help there, please send em for
consideration.

-- 
_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._

---

From: Justin Richer <[email-masked]>
Date: Mon, 8 Apr 2019 23:49:36 +0000

Thanks for the clarifications everyone. Since I didn’t catch the one-and-only-one sentiment when reading the updates, I would recommend altering the text as follows in §2.1:

   The PKI (public key infrastructure) method of mutual TLS OAuth client
   authentication adheres to the way in which X.509 certificates are
   traditionally used for authentication.  It relies on a single subject
   distinguished name (DN) or a single subject alternative name (SAN) <deleted text> to authenticate the client. The client’s certificate chain is validated [RFC5280] and only one name value of any type is used for each client.
   The TLS handshake is utilized to validate the client's possession of
   the private key corresponding to the public key in the certificate
   and to validate the corresponding certificate chain.  The client is
   successfully authenticated if the subject information in the
   certificate matches the single expected subject configured or registered for
   that particular client (note that a predictable treatment of DN
   values, such as the distinguishedNameMatch rule from [RFC4517<https://tools.ietf.org/html/rfc4517>], is
   needed in comparing the certificate's subject DN to the client's
   registered DN).  Revocation checking is possible with the PKI method
   but if and how to check a certificate's revocation status is a
   deployment decision at the discretion of the authorization server.
   Clients can rotate their X.509 certificates without the need to
   modify the respective authentication data at the authorization server
   by obtaining a new certificate with the same subject from a trusted
   certificate authority (CA).

I think the listing of methods is clear enough as it is — but my problem was that I read the above paragraph, then jumped right into the list below for the exact fields without reading its own introductory paragraph as well.

— Justin

On Apr 8, 2019, at 1:54 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Yes, the intent is that the client be configured (dynamically or statically or however that comes to be) with one and only one expected subject, which also includes the location in the certificate that subject will be. And that is checked against at authentication time.

As the writer of the questionable text in question, it does seem pretty clear to me as it is now. But as the writer, I'm also probably not well positioned to see how it could be made more clearer. So if either of you gentlemen have concrete text suggestions to help there, please send em for consideration.

On Thu, Apr 4, 2019 at 2:55 PM Filip Skokan <[email-masked]<mailto:[email-masked]>> wrote:
Yes.

S pozdravem,
Filip Skokan

On Thu, 4 Apr 2019 at 22:36, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Thank you, I did miss that text. This should be called out more explicitly in §2.1, perhaps by specifying that it is only one field. This still doesn’t set precedence, but it implies that it’s an error for a client to have more than one field set of the available options. Is that your read on this as well?

— Justin

S pozdravem,
Filip Skokan

Thanks,
— Justin

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.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Apr 2019 17:05:42 -0600

Thanks Justin.

On Mon, Apr 8, 2019 at 5:49 PM Justin Richer <[email-masked]> wrote:

> Thanks for the clarifications everyone. Since I didn’t catch the
> one-and-only-one sentiment when reading the updates, I would recommend
> altering the text as follows in §2.1:
>
>    traditionally used for authentication.  It relies on a *single *subject
>    distinguished name (DN) or a *single* subject alternative name (SAN) *<deleted text>* to authenticate the client. *The client’s certificate chain is validated [RFC5280] and only one name value of any type is used for each client.*
>    certificate matches the *single *expected subject configured or registered for
>    values, such as the distinguishedNameMatch rule from [RFC4517 <https://tools.ietf.org/html/rfc4517>], is
> I think the listing of methods is clear enough as it is — but my problem
> was that I read the above paragraph, then jumped right into the list below
> for the exact fields without reading its own introductory paragraph as well.
>
> — Justin
>
> On Apr 8, 2019, at 1:54 PM, Brian Campbell <[email-masked]>
> wrote:
>
> Yes, the intent is that the client be configured (dynamically or
> statically or however that comes to be) with one and only one expected
> subject, which also includes the location in the certificate that subject
> will be. And that is checked against at authentication time.
>
> *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.*
>
>
>