W3C home > Mailing lists > Public > ietf-tls@w3.org > October to December 1996

Re: Closing on shared-key authentication

From: Eric Murray <ericm@lne.com>
Date: Fri, 11 Oct 1996 14:16:58 -0700 (PDT)
Message-Id: <199610112116.OAA04551@slack.lne.com>
To: marcvh@aventail.com (Marc VanHeyningen)
Cc: ericm@lne.com, tomw@netscape.com, ietf-tls@w3.org
Marc VanHeyningen writes:
> In other words, you're doing password authentication by just sending
> the password encrypted, which Tom and I (and I suspect most other
> people here) agree is not a very good way to do it.

Why not?

> > 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". 
> No, another advantage is being able to use challenge-response
> mechanisms based on passwords (or challenge-response 
> mechanisms based on SecurID tokens or whatever) and not
> requiring encryption at all (might encrypt it anyway, but the
> security of it need not depend on that.)

If you don't require encryption why are you using TLS?
(yea I know about the MAC-only ciphersuites, but they're not used
in practice).

There's other simpler protocols that implement challenge-response
authentication, why not use one of those if that's all you want?

Are we talking about the same things?  "just sending the password encrypted"
to me means doing a complete TLS handshake and then sending the password
as TLSed data, protected by the encryption/MAC negotiated by TLS.  Except for
the problem of having to use 'export'-quality encryption to protect your
authentication (which is an artifact of US government crypto policy and
not a technical problem), I can't see anything wrong with it.
So I must be misunderstanding the point that you're trying to make.

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 17:18:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC