Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

I am not aware of anywhere this is documented, primarily because it's so
application-specifiic.

-Ekr

On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gondrom@gondrom.org>
wrote:

> Hi dear TLS experts,
>
>
>
> Apologies for my stupid question for advise:
>
> I am currently working on some design requirements for mutual
> authentication and have a question regarding verification of client
> certificate.
>
>
>
> In many web scenarios the simple use is server authentication by
> certificate and verification of client id by username & password or by a
> simple verification of client certificate.
>
>
>
> Are there any RFCs that speak (beyond the general verification of the
> certificate in mutual TLS authentication) to the need to also verify the CN
> inside the client certificate against an additional whitelist _*before*_
> establishing a TLS connection.
>
>
>
> For example in this scenario:
>
> A client with a valid certificate may be allowed to connect to application
> 1, but would not be allowed to connect to application 2. (for sake of
> separation application 1 and 2 are on separate servers (application 1 on
> server 1 and application 2 on server 2).)
>
>
>
> From my current understanding, I would establish the TLS connection in
> both cases, do mutual authentication and then let application 2 reject
> access based on that the user is not allowed to access it. There is a
> question whether this would expose to a risk that server resources could be
> exhausted by allowing to establish the TLS connection before failing, but
> this does not seem too bad to me. But maybe I am missing something…
>
>
>
> *Are there any informational (or standard) RFCs for TLS that speak about
> this risk and best practices to address it?  *
>
> *(e.g. using additional whitelist checks of parameters inside the client
> certificate for access control checks already during phase of establishing
> the TLS connection)*
>
>
>
> Thank you and sorry for bothering, Tobias
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>