Re: Closing on shared-key authentication

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.

- Marc