Re: [OAUTH-WG] MTLS and SAN

Yes.

S pozdravem,
*Filip Skokan*

On Thu, 4 Apr 2019 at 22:36, Justin Richer <jricher@mit.edu> 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 <panva.ip@gmail.com> wrote:
>
> 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 <jricher@mit.edu> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>