Re: [TLS] Straw poll on TLS SRP status

[Martin Rex <Martin.Rex at sap.com>]

Peter Gutmann wrote:
> "Chris Newman" <Chris.Newman at Sun.COM> writes:
> > Client certificate authentication has been there long enough that it's a 
> > known quantity how to dig the necessary details out of the TLS layer for an 
> > application to consume
> 
> And we all know how well client certs haved worked out in practice.
> The abject failure of TLS client-cert authentication is probably the
> strongest argument in favour of providing new authentication mechanisms
> that do actually work.

We are happily using SSL with client certs for 30k+ users with a number
of different servers and we've been using it productively for 6 years
now (started using it 1999).

Initially there were a few bugs in MSIE, but they've been fixed
a few years ago.  Right now, the largest remaining issue for the
most commonly used platform is a Hotfix for WinHTTP that IIRC
is not yet available for public download.

One observation about SSL client certificate verification: you absolutely
do NOT want revocation checking or any kind of fancy path validation
(policy constraints and other bullshit) be done within the TLS stack.
Everything that involves communication to third parties or additional
computational processing will have to be done at a point where it
scales (i.e. in the backend server farm) or it will kill throughput
in a large server and ambitions for high availability.


>
> > I'd much rather keep user-level authentication as a separate subsystem and
> > promote channel bindings on the standards track instead.
> 
> From a very abstract protocol point of view that sounds good.  From a UI point
> of view it's terrible: You need to integrate mutual authentication directly
> into the crypto handshake, not have it as a separate layer.  If you don't, you
> fall into the "connect to anything listening on the appropriate port, then
> hand over your credentials" trap that makes HTTP-over-TLS the phisher's best
> friend.  A TLS handshake can have only two possibile outcomes, "connected with
> both sides authenticated" or "not connected".  Anything else and you're just
> providing substrate for phishing attacks.

I agree that for User-level (or more precisely app-level) authentication is
the preferable approach for pretty much all scenarios that are not
(or not yet) native SSL/TLS, including passwords and GSS-API authentication
(e.g. rfc-4559).  It scales much better and it is much easier to adapt
to custom requirements (of legacy authentication systems).

Having to mess with the _entire_ middleware (SSL/TLS and backend
communication layers directly above it) each time an additional
authentication scheme (or additional attribute of an existing scheme)
needs to be supported is the nightmare scenario for software maintenance,
especially if there are thrid-party components (like SSL Accellerators
or reverse proxies) are involved.


-Martin

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls