Hi Tobias, If you use search terms that include pkix, authorization, access control, and attribute certificate profile, you’ll find a few documents. This one should be helpful based on your description:
https://tools.ietf.org/html/rfc5755 Best regards, Kathleen Sent from my mobile device > On Apr 16, 2018, at 4:55 AM, Eric Rescorla <e...@rtfm.com> wrote: > > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
