Re: [TLS] the use cases for GSS-based TLS and the plea for integrating

[Kyle Hamilton <aerowolf at gmail.com>]

On Jul 27, 2007, at 7:07 AM, pgut001 at cs.auckland.ac.nz wrote:

> "Kemp, David P." <DPKemp at missi.ncsc.mil> writes:
> > Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all  
> > have the
> > property of requiring communication with an identity provider in  
> > real-time to
> > authenticate a user (except for pre-placed keys, a non-scalable  
> > technique that
> > is not under consideration for TLS even though it is supported in  
> > IPSec).

...ummm... the process of creating a key, sending a CSR, and then  
putting the returned certificate and certificate chain in place is a  
key pre-placement mechanism.

Then again, it would also theoretically be possible to generate  
session IDs that you distribute to the clients, and then the clients  
use those pre-generated sessions to share the keys that way.  (That  
path is fraught with so much peril that it's not worth considering  
for a general-purpose implementation, but I can envision a couple of  
specialized environments that it would be useful within.)

> > Asymmetric (certificate-based) mechanisms can authenticate a user  
> > without
> > communicating with an identity provider and without giving one  
> > party the
> > ability to masquerade as the other.

...so OCSP was designed for a purpose that really didn't need to be  
filled.

> > One certainly would not want to remove asymmetric authentication  
> > from TLS
> > (i.e., it should remain mandatory to implement).

I'm inclined to agree.  It is too useful.  However, the issue of  
enforcing X.509/PKIX is... questionable.

> I realise this has the potential to open up a huge can of worms  
> here, but I
> can't let this one pass by: "shared keys/passwords/whatever don't  
> scale" is
> one of the most persistent myths on computer security.  99.99% of all
> authentication is done via pre-shared keys/passwords, including  
> pretty much
> arbitrarily large infrastructures like eBay, Amazon, Gmail, any ISP  
> using
> RADIUS, and <insert-name-here>.  The ones that we know definitely  
> don't scale
> well in comparison are all the others: PKI, Kerberos, yadda yadda  
> yadda, and
> in particular the asymmetric-auth ones.

Why wouldn't the SSH paradigm work here?  You have the public key  
associated with the address you're talking to.  (and if the  
fingerprint popped up when you first connected to it, then a bank  
[for example] would be able to give you the fingerprint to verify  
against when you opened your account.

Personally, I'd like to see the banks that open merchant accounts do  
the certifications of merchant identity.  It would provide for a MUCH  
greater mechanism of knowing who to go after -- because if nothing  
else, the merchant account information could be used in a civil suit  
for garnishment.

> For how many more years do we have to keep flogging the PKI  
> corpse?  If it
> worked as intended, the multibillion-dollar phishing industry  
> wouldn't exist.
> Why keep it mandatory to implement something that very demonstrably  
> doesn't
> work?

There are circumstances for which it would work.  It just doesn't  
work very well in the current implementation.  That's the most  
important thing to consider: just because something doesn't work in  
the current implementation doesn't mean it doesn't work period.

To be honest, X.500 (and the entire X.5** suite) is horribly unsuited  
for the purposes for which it was designed -- but LDAP (lightweight  
access to X.500-style directories) has been shown to be useful, which  
means that not all of the work that went into it was wasted.

-Kyle H

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