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.gond...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
