- From: Eric Murray <ericm@lne.com>
- Date: Fri, 11 Oct 1996 18:43:19 -0700 (PDT)
- To: marcvh@aventail.com (Marc VanHeyningen)
- Cc: ietf-tls@w3.org
Marc VanHeyningen writes: > > Eric Murray sed: > > 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? > > Lots of reasons; I'll mention a few. [..] Thanks. > I trust HMAC-composed SHA-1 more than I trust 40-bit RC4, > or even 128-bit RC4. Don't you? Yep. But I think 128-bit RC4 is "good enough" for passwords that change oftener than every 40 years. (see schneier 2nd ed. pp 167). 40-bit, of course, is not. > > 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. > > It means the password can be decrypted. I prefer to only send my password > out in a fashion that cannot be decrypted, ever, by anyone. So, to sum up the arguments for password auth in TLS, the reasons are: 1. 40-bit export ciphers are too weak to protect passwords. With password auth, TLS could use stronger authentication-only crypto to protect password material. 2. it's "unhygenic" to send passwords themselves, so apps should send hashes of them, possibly including a challenge. Since someone would have to re-write existing password-based protocols to do this, it should be placed in TLS, to make it easier to do. Any more? -- 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 21:43:31 UTC