I think the issue is more about the "principle of least surprise".
The client needs to know whether it offered authentication by client cert and which client cert it offered. Whether the server accepted it, and caches the accepted cert in the session or in a session ticket, is the business of the server (it may help in troubleshooting to know, but should not be necessary for application flow control). Clients asserting multiple identities sounds extremely awkward to me. We do have clients in posession of multiple client certs, but our application must specify _before_ each TLS handshake which client identity to use (and this information is necessary for client-side session caching, and client-side session lookup. There is a significant difference between cached sessions where a specific client cert was used (or at least offered by the client), and cached sessions where no client cert was offered. If a client tries to access a resource through a session that is authenticated with SSL client cert A, and the server-side authorization decision denies access to client cert A, then this will typically result in an access failure, _without_ the server asking for a different cert. When no client cert has been used in a session then access to a resource that requires a (particular) client cert may result in a request of the server for a client cert (renegotiation up to TLSv1.2) after seeing the request--provided that the server supports renegotiation. -Martin Andrei Popov wrote: > > Is it important for the client to know, from the TLS stack itself, > whether client authentication succeeded or not? My assumption > (perhaps incorrect) has been that it is the server that cares about > the client's identity (or identities) in order to make an > authorization decision. > > This thread also seems to consider client authentication a binary state: > the client is either authenticated, or not. In practice, the client may > assert multiple identities, and the server may grant various levels > of access. > > Also, why should the client care whether session ticket X includes client > identity Y? If a client resumes a TLS session with a session ticket that > does not include (or point to) a client authenticator needed to satisfy > the client's request, the server can initiate client auth (or deny the > request). > > Cheers, > > Andrei _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
