Re: Closing on shared-key authentication

Marc VanHeyningen writes:
> 
> > No, you should certainly do something more than just send the password
> > encrypted.  You should avoid sending the password at all, encrypted or
> > otherwise.  Some sort of challenge/response mechanism would be
> > appropriate, but you are protected from eavesdroppers if you encrypt
> > the data.
> 
> True.  I'm clearly misunderstanding you then.  You said previously:
> 
> >There is no need to add a mechanism
> >to TLS when all existing protocols already have a password mechanims.
> 
> I assumed the password mechanisms that you meant there were
> cleartext ones, not more sophisticated ones based on challenge-response
> or keyed hashes or anything else.  Was I wrong?

Sort of.  They're cleartext unless the entire exchange is protected
by TLS.  Then they're encrypted in whatever ciphersuite TLS
negotiated.  Obviously when you are negotiating use/non-use
of TLS in an existing protocol, you must start TLS before
sending the username/password.

> I believe there is a need to add a mechanism to TLS because, while all
> existing protocols have password mechanisms, they're lousy ones.

The only advantage to embedding passwords is being able to
use "non-export" encryption on the password, _IF_ the protocol
is designed so that no one can use the password field to
exchange "random data".  If I can write an app to use
TLS/password auth to send words (say as "login attempts")
of my own choosing under strong encryption, the NSA will not
allow export of the scheme.  I have not reviewed the latest
TLS password proposal, so I do not know if it will meet
the NSA's requirements.  Has anyone asked them yet?

In any case, I agree with Tom that we should not be designing
the TLS protocol to meet the US crypto policy flavor-of-the-month.
Besides the fact that they can change it on any political
whim, rendering our work invalid, TLS is an international
standard.


-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Friday, 11 October 1996 15:45:49 UTC