Re: Closing on shared-key authentication

Marc VanHeyningen wrote:
> 
>> 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?

Well, for example, HTTP has digest authentication.  POP3 and IMAP are
adding similar mechanisms.  Yes, the telnet password mechanism is
completely horrible, but there are protocols for which that is not true.

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

Yes, a lot of existing protocols have lousy password mechanisms.  But
to integrate any sort of TLS password mechanism, you're going to have
to change the protocol if for no other reason than to STOP sending the
password in the clear.  If you're going to do that, why not just fix
the protocol?

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com

Received on Friday, 11 October 1996 17:41:20 UTC