Re: Closing on shared-key authentication

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
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