Eric Murray sed: > > 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? > > Sort of. They're cleartext unless the entire exchange is protected > by TLS. Then they're encrypted in whatever ciphersuite TLS > negotiated. Yes, of course; maybe I should have made that clearer. 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. > 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.) > In any case, I agree with Tom that we should not be designing > the TLS protocol to meet the US crypto policy flavor-of-the-month. I also agree with this, BTW. - MarcReceived on Friday, 11 October 1996 16:32:43 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC