SSL/TLS client-auth - Not the way forward?

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Dear List;

Quite a few large-scale PKI implementations rely on Java applets
for digital signatures.  Due to the limited integration between pure Java
and browser crypto/keystores, specific applets are used also for authentication,
rather than using the browser´s SSL/TLS client-authentication capability.  By
using a challenge-response mechanism on top of an SSL/TLS channel, secure
client authentication is achieved using a non-browser-based key.

Usually the server's public key is also a part of the response to thwart
possible man-in-the-middle attacks during the initial SSL/TLS setup.
That is, the auth server must check that the response contains its own key.

>From another mailing list I took the following lines that indicate that
there may be other reasons than Java/browser limitations to not
use SSL/TLS client-authentication.

==================
It is not using 2way SSL, if it were, there was really no need for it.

fact is, 2way SSL only works in very simple scenarios, accessing only
one host with no need to handle "logoff". In more often (larger scale)
solutions, 2way SSL in reality works bad (because browsers will
renegotiate SSL connections with host changes - also when changing
subdomains within a domain). 2way SSL breaks SSO when switching
between different subdomains within the same domain.

because of the problems with 2way SSL, openlogon is designed to use
1way ssl, doing the "client side auth" as part of the applet.

Also, 2way SSL is end-to-end between the browser and the server that
terminates the SSL session. But in most larger setups, this tends to
be SSL accelerators which sends on (only) the client public
certificate to the application server. End-to-end is then only over
the internet, where OpenLogon really is end-to-end since the SSL
accelerators only takes care of the resource consuming keyexchange.
Auth is handled by the logon service in the application server.
====================

Comments?

Anders Rundgren
PKI Architect etc.