Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

From: Evan Gilman <[email-masked]>
Date: Mon, 5 Nov 2018 14:52:28 -0800

Hello everyone.

Very excited to see this draft. It helps tremendously in addressing
use cases around oauth client management in machine-to-machine
scenarios. Particularly, the PKI authentication method.

In reviewing the document, I noticed that the only supported method
for identifying a client using the PKI authentication method is by
referencing its distinguished name. This caught me a bit by surprise -
many newer projects aimed at automating X.509 issuance in the
datacenter utilize SAN extensions rather than distinguished name in
order to encode identity. I am further under the impression that the
community is, in general, moving away from the subject extension
altogether in favor of SAN-based identification.

Full disclosure: I am one of the maintainers on a project called
SPIFFE, which provides identity specifications for datacenter workload
applications. For X.509, SPIFFE encodes identity into a URI SAN
extension. A number of projects using SPIFFE do not configure the
subject with identifying information (SPIRE and Google Istio being
just a couple). I am also hearing of other X.509 automation projects
which are moving away from subject/distinguished name (even if they
are not using SPIFFE).

While I think support for distinguished name is absolutely necessary,
I worry that supporting it solely will render it incompatible with
some of the more modern PKIX systems and not stand the test of time. I
know that I am a little late to this, and for that I apologize... but
I feel this is a significant point.

I would like to open a discussion on supporting the most commonly used
SAN extension types in addition to distinguished name. To accomplish
this, amending section 2.1.2 `Client Registration Metadata` with
additional parameters seems appropriate. In my experience, the most
commonly used SAN extensions are: DNS name, IP address, URI, and email
address.

Are there significant drawbacks to extending the number of client
registration metadata parameters? I would very much like to see this -
without it, many existing projects will be unable to use the spec. I
am happy to contribute time and text to this, assuming people feel
that this is a beneficial addition. Sorry again for the timing

-- 
evan

---

From: Brian Campbell <[email-masked]>
Date: Tue, 6 Nov 2018 08:55:34 +0700

Thanks Evan for bringing this to the WG's attention. More or less the same
question/issue was raised yesterday in the area director's review of the
document as well. I plan to bring this up as a discussion item in the
meeting today. But my sense from some early discussions is that there is
likely to be (rough) consensus to make some change in order to allow a SAN
to be specified as the certificate subject identifier in the PKI client
auth mode. We'll need to figure out the specifics of how that works. I
don't think there are significant drawbacks to extending the number of
client registration metadata parameters per se. I guess I've just been
attracted to the idea of overloading the existing value because that felt
like maybe a less invasive change. But perhaps that's shortsighted. And
there's nothing inherently wrong with additional client metadata
parameters.

I don't know if we could get away with a single new parameter that could
carry the value for any SAN type. Something like, { ...
"tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I
feel like that'd probably be okay but in theory there's the potential for
confusion of the value across different types. So probably there's a need
to indicate the SAN type too. Either with more client metadata parameters
like tls_client_auth_san_uir, tls_client_auth_san_email,
tls_client_auth_san_ip, etc. or maybe with a structured value of some sort
like {... "tls_client_auth_san": {"type":"URI",
"value":"spiffe://trust-domain/path"} ... }. And then deciding which types
to support and if/how to allow for the extensible types.

Anyway, those are just some thoughts on it. And it'll be discussed more
today. Suggested/proposed text is always helpful though (even if it's not
used directly it can help move the conversation forward and/or help
editor(s) to have prospective wording).

On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: Neil Madden <[email-masked]>
Date: Tue, 6 Nov 2018 07:53:11 +0000

Is there an intention that any semantics are attached to the SAN being a URI or DNS name or IP or ...? Or is it still intended to be an opaque identifier?

> On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> Thanks Evan for bringing this to the WG's attention. More or less the same question/issue was raised yesterday in the area director's review of the document as well. I plan to bring this up as a discussion item in the meeting today. But my sense from some early discussions is that there is likely to be (rough) consensus to make some change in order to allow a SAN to be specified as the certificate subject identifier in the PKI client auth mode. We'll need to figure out the specifics of how that works. I don't think there are significant drawbacks to extending the number of client registration metadata parameters per se. I guess I've just been attracted to the idea of overloading the existing value because that felt like maybe a less invasive change. But perhaps that's shortsighted. And there's nothing inherently wrong with additional client metadata parameters. 
> 
> I don't know if we could get away with a single new parameter that could carry the value for any SAN type. Something like, { ... "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I feel like that'd probably be okay but in theory there's the potential for confusion of the value across different types. So probably there's a need to indicate the SAN type too. Either with more client metadata parameters like tls_client_auth_san_uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe with a structured value of some sort like {... "tls_client_auth_san": {"type":"URI", "value":"spiffe://trust-domain/path"} ... }. And then deciding which types to support and if/how to allow for the extensible types. 
> 
> Anyway, those are just some thoughts on it. And it'll be discussed more today. Suggested/proposed text is always helpful though (even if it's not used directly it can help move the conversation forward and/or help editor(s) to have prospective wording). 
> 
> 
> 
> 
> 
>> Hello everyone..
> 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: Evan Gilman <[email-masked]>
Date: Tue, 6 Nov 2018 12:52:45 -0800

Response(s) inline

> Is there an intention that any semantics are attached to the SAN being a URI or DNS name or IP or ...? Or is it still intended to be an opaque identifier?

There are some extra things we could do if we attached type-specific
semantics to the matching (e.g. DNS wildcarding etc), however I think
that continuing to use the values as opaque identifiers would get us
most of what we need while keeping things simple.

> I don't know if we could get away with a single new parameter that could carry the value for any SAN type. Something like, { ... "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practic…

I am far from an authority here, but it is my understanding that one
of the primary drivers in supporting SAN over Subject is that the
values are strongly typed. While some of the advantages gained from
this may be less useful in our own context, I feel that it make sense
to keep the values separate and not overload a single value. Whether
that means dedicated metadata parameters or a structured parameter
value, I am not sure what the tradeoffs would be, but both options
sound suitable to me.

> Anyway, those are just some thoughts on it. And it'll be discussed more today. Suggested/proposed text is always helpful though (even if it's not used directly it can help move the conversation for…

Great. I will work on some sample text since it sounds like that would
be generally helpful

-- 
evan

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 6 Nov 2018 16:03:09 -0500

You might want to look at RFC6125 which covers this topic and provides
recommendations for representing application in certificates:
https://tools.ietf.org/html/rfc6125

Regards,
 Rifaat

On Tue, Nov 6, 2018 at 3:53 PM Evan Gilman <[email-masked]> wrote:

> > Is there an intention that any semantics are attached to the SAN being a
> URI or DNS name or IP or ...? Or is it still intended to be an opaque
> identifier?
>
> > On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=
> [email-masked]> wrote:
> >
> > Thanks Evan for bringing this to the WG's attention. More or less the
> same question/issue was raised yesterday in the area director's review of
> the document as well. I plan to bring this up as a discussion item in the
> there's nothing inherently wrong with additional client metadata parameters.
> >
> > 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 P Richer <[email-masked]>
Date: Wed, 7 Nov 2018 01:10:59 +0000

Would it make sense for these to be a different client_auth_method entirely? Much the same way that we have private_key_jwt and client_secret_jwt today, both of which use the JWT assertion framework but have very different keying and security assumptions. In the same way, here you’re still validating the cert but the means by which it’s validated is different, so the auth method is arguably not going to benefit from being overloaded. Caveat, I’ve not built out a system using SANs in any meaningful way.

If we were to do that, this draft could go forward as-is (since it’s fairly done in my opinion) and a new document could better define the semantics for the various SAN types, but while building on the framework and concepts listed in here.

— Justin

On Nov 6, 2018, at 3:52 PM, Evan Gilman <[email-masked]<mailto:[email-masked]>> wrote:

Response(s) inline

On Mon, Nov 5, 2018 at 11:53 PM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:

On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=[email-masked]<mailto:bcampbell=[email-masked]>> wrote:

On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <[email-masked]<mailto:[email-masked]>> wrote:

Hello everyone..

--
evan

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

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

--
evan

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 7 Nov 2018 09:50:04 +0700

Thanks for referring us to this spec. How I read it, every way to represent an application identity may require specific verification rules (including typ specific syntactical rules). 

In my interpretation this means we must explicitly manage expected type and value of the identifier used to match the client identity. It could also require the AS to apply type specific matching rules.  

Comments?

> Am 07.11.2018 um 04:03 schrieb Rifaat Shekh-Yusef <[email-masked]>:
> 
> You might want to look at RFC6125 which covers this topic and provides recommendations for representing application in certificates:

---

From: Brian Campbell <[email-masked]>
Date: Wed, 7 Nov 2018 00:46:07 -0800

inline below

> most of what we need while keeping things simple.

Agreed.

> to keep the values separate and not overload a single value.

I'm likewise no authority but have a similar understanding. Because the
advantages of a typed name are less clear in this context is why I've been
wanting to simplify with an overloaded parameter. But that's probably
ultimately a bad idea. So yeah, I'm agreeing that separating the types is
the way to go.

Whether
> value, I am not sure what the tradeoffs would be, but both options

Seems like it's largely an esthetic thing but perhaps the benefits or
drawbacks of one over the other will become more apparent as we dig into it
more.

> be generally helpful

I think it would, yes. Thank you!

---

From: Brian Campbell <[email-masked]>
Date: Wed, 7 Nov 2018 00:50:59 -0800

Sure, I think they could be treated as different different
client_auth_methods. But there is a lot more commonality than differences
to the point where I think it makes sense to keep it all in a single
document and under a single client auth method with just the variation on
which name is being used.

On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer <[email-masked]> wrote:

> Would it make sense for these to be a different client_auth_method
> entirely? Much the same way that we have private_key_jwt and
> client_secret_jwt today, both of which use the JWT assertion framework but
> have very different keying and security assumptions. In the same way, here
> you’re still validating the cert but the means by which it’s validated is
> different, so the auth method is arguably not going to benefit from being
> overloaded. Caveat, I’ve not built out a system using SANs in any
> meaningful way.
>
> If we were to do that, this draft could go forward as-is (since it’s
> fairly done in my opinion) and a new document could better define the
> semantics for the various SAN types, but while building on the framework
> and concepts listed in here.
>
> — Justin
>
> On Nov 6, 2018, at 3:52 PM, Evan Gilman <[email-masked]> wrote:
>
> Response(s) inline
>
> On 6 Nov 2018, at 01:55, Brian Campbell <
> bcampbell=[email-masked]> wrote:
>
> like {... "tls_client_auth_san": {"type":"URI", "value":"
> spiffe://trust-domain/path"} ... }. And then deciding which types to
> support and if/how to allow for the extensible types.
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> distribution or disclosure by others is strictly prohibited..  If you have
> computer. Thank you.

---

From: Evan Gilman <[email-masked]>
Date: Mon, 12 Nov 2018 15:59:20 -0800

Thank you everyone for the feedback.

I am currently working on the sample text, and should be complete in
the next couple days. Apologies for the delay.
On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell
<[email-masked]> wrote:
>
> Sure, I think they could be treated as different different client_auth_methods. But there is a lot more commonality than differences to the point where I think it makes sense to keep it all in a single document and under a single client auth method with just the variation on which name is being used.
>
> 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.

-- 
evan

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 13 Nov 2018 15:24:50 +0100

Hi Evan, 

I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just plain X.509). What’s your plan for introducing OAuth and mtls?

kind regards,
Torsten. 

> Am 13.11.2018 um 00:59 schrieb Evan Gilman <[email-masked]>:
>

---

From: Evan Gilman <[email-masked]>
Date: Thu, 15 Nov 2018 16:41:28 -0800

I have taken a stab at some text that will open the door for SAN-based
subject identity support. Some minor modifications in section 2.1, and
additional metadata parameters in section 2.1.2. Please find that text
below.

> I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just plain X.509). What’s your plan for introducing OAuth and mtls?

That is correct - SPIFFE does not currently involve any OAuth works...
the use case for this change was brought to my attention a couple of
weeks ago: use SPIFFE identities in "cloud native" environments to
authenticate to an OAuth server in order to receive an access token
for authentication with on-prem infrastructure which is OAuth-enabled.
Doing so relieves a good deal of pressure around OAuth client (and
secret) management. That said, I think the proposed change here is
beneficial on all counts, and not just an accommodation for SPIFFE
authentication. As I mentioned previously, there are several other
projects that are relying on SAN rather than DN for subject identity
and the number is growing.

I tried to think through what the text would look like to support a
structured value for a parameter named `tls_client_auth_san`, but ran
into a couple sticking points... the first is that it is certainly
more complex and would require more text, and feels more error prone
than simply introducing additional metadata parameters. Second, we
would need to strictly define supported values for `type`, and it
wasn't immediately clear if this is something that would need to be
centrally registered. I am curious to hear thoughts on the structured
value approach versus that which I took below.

2.1.  PKI Mutual TLS OAuth Client Authentication Method

   The PKI (public key infrastructure) method of mutual TLS OAuth client
   authentication uses a subject name (DN or SAN) and validated
   certificate chain to identify the 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 expected subject configured or registered for that particular
   client (note that a predictable treatment of DN values, such as the
   distinguishedNameMatch rule from [RFC4517], is needed in comparing
   the certificate's subject DN to the client's registered DN).  If and
   how to check a certificate's revocation status is a deployment
   decision at the discretion of the authorization server.  The PKI
   method facilitates the way X.509 certificates are traditionally being
   used for authentication.  It also allows the client to rotate its
   X.509 certificates without the need to modify its respective
   authentication data at the authorization server by obtaining a new
   certificate with the same subject from a trusted certificate
   authority (CA).

and

2.1.2.  Client Registration Metadata

   The following metadata parameters are introduced for the OAuth 2.0
   Dynamic Client Registration Protocol [RFC7591] in support of the PKI
   method of binding a certificate to a client:

   tls_client_auth_subject_dn
      An [RFC4514] string representation of the expected subject
      distinguished name of the certificate, which the OAuth client will
      use in mutual TLS authentication.

   tls_client_auth_san_dns
      A string containing the value of an expected dNSName SAN entry
      in the certificate, which the OAuth client will use in mutual TLS
      authentication.

   tls_client_auth_san_uri
      A string containing the value of an expected
      uniformResourceIdentifier SAN entry in the certificate, which
      the OAuth client will use in mutual TLS authentication.

   tls_client_auth_san_ip
      A string representation of an IP address in either dotted decimal
      notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
      defined in [RFC4291] section 2.2) that is expected to be present
      as an iPAddress SAN entry in the certificate, which the OAuth
      client will use in mutual TLS authentication.

   tls_client_auth_san_email
      A string containing the value of an expected rfc822Name SAN
      entry in the certificate, which the OAuth client will use in
      mutual TLS authentication.

-- 
evan

---

From: Brian Campbell <[email-masked]>
Date: Fri, 16 Nov 2018 15:43:52 -0700

Thanks Evan.

This seems like a good start and I'll plan to work to incorporate the
proposal in some/similar form into the next revision of the document.
Comments, clarifications, etc. from the WG are also always welcome too in
the meantime. Or from the AD, who also suggested allowing for the use of
SAN. But this seems to generally fit the bill to allow for SAN-based
subject identification of the client in the certificate.

Having thought a bit more about the structured vs. flat metadata, I think
I've come to a similar conclusion as you have.

On Thu, Nov 15, 2018 at 5:41 PM Evan Gilman <[email-masked]> wrote:

> > I scanned through the SPIFFE docs but didn’t any mentioning of OAuth
> (just plain X.509). What’s your plan for introducing OAuth and mtls?
>
> > I scanned through the SPIFFE docs but didn’t any mentioning of OAuth
> (just plain X.509). What’s your plan for introducing OAuth and mtls?
> >
> > kind regards,
> > Torsten.
> >
> > >>> Is there an intention that any semantics are attached to the SAN
> being a URI or DNS name or IP or ...? Or is it still intended to be an
> opaque identifier?
> > >>>
> > >>>
> > >>> Thanks Evan for bringing this to the WG's attention. More or less
> the same question/issue was raised yesterday in the area director's review
> of the document as well. I plan to bring this up as a discussion item in
> the meeting today. But my sense from some early discussions is that there
> is likely to be (rough) consensus to make some change in order to allow a
> SAN to be specified as the certificate subject identifier in the PKI client
> > >>> I don't know if we could get away with a single new parameter that
> could carry the value for any SAN type. Something like, { ...
> > >>> Anyway, those are just some thoughts on it. And it'll be discussed
> more today. Suggested/proposed text is always helpful though (even if it's
> not used directly it can help move the conversation forward and/or help
> review, use, distribution or disclosure by others is strictly prohibited.