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

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 18 Dec 2004 11:40:30 +0100

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.

---

From: Michael Ströder <[email-masked]>
Date: Sat, 18 Dec 2004 15:37:22 +0100

What exactly is your question?

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 18 Dec 2004 20:05:45 +0100

>What exactly is your question?

Michael,
One question was actually in the subject line.

Another question could be if this should in some way be addressed
by future standardization efforts.

I forgot a major reason for why SSL/TLS client-auth is likely to be
of limited use and that is the absence of a "WebSign" standard.
If certificate selection when authenticating and signing are different,
users get confused.  That's why all these Java-things normalize
this part by not using the native support.

That is, w.r.t. PKI practically every aspect of browser usage is
currently non-standard, including:

- certreq/keygen
- websign
- client-auth

This is a bit surprising as client-side PKI in conjunction with browsers
is at least a magnitude bigger than in conjunction with secure e-mail,
and the gap is widening.

rgds
Anders R

----- Original Message ----- 
From: "Michael Ströder" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 18, 2004 15:37
Subject: Re: SSL/TLS client-auth - Not the way forward?

Ciao, Michael.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Sat, 18 Dec 2004 20:36:50 +0100 (CET)

In message <[email-masked]> on Sat, 18 Dec 2004 15:37:22 +0100, Michael Ströder <[email-masked]> said:

michael> 
michael> Anders Rundgren wrote:
[...]
michael> > Comments?
michael> 
michael> What exactly is your question?

I'm going to boldly assume his question means "Do you have any
comments on this practice, and what are they?".  What motives Anders
has, except taking the risk of getting his head bitten off (:-)),
that's an entirely different question.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"