Re: Closing on shared-key authentication

Tom Weinstein wrote:
> 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?

  Also note that these protocols (HTTP, POP, etc.) have to solve this
problem anyway, since they will generally not be used with TLS any
time soon.  Since they are already solving the problem, why do we
need to do it again?


Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation -
Any opinions expressed above are mine.

Received on Monday, 14 October 1996 03:54:18 UTC