hi, On Mon, Feb 06, 2006 at 07:43:42PM -0800, Mark Crispin wrote: > On Mon, 6 Feb 2006, Mark Sirota wrote: > >I don't buy into the argument that server administrators should be forced > >to accept the worst case. We can begrudgingly accept the worst case, and > >work to minimize its occurrence. > > I'd like to hear a convincing argument why it's important to bundle > session integrity with authentication, and why this is better than using > SSL/TLS for session integrity and Kerberos etc. for authentication. Note > that SSL/TLS has client certificates (& the EXTERNAL SASL authenticator), > but that doesn't seem to have progressed very far either.
A problem with SSL/TLS is that the user gets a question wheter to accept an unknown certificate. Today these questions are that common that an average user does not even look at it. The point is: when using gssapi/kerberos for authentication and encryption, the user does not have to care. Login either succeeds or fails, but in the case of an MitM attack there is no way to login anyway. In the case where administrators have control over both server and clients computers, an average user will probably not even notice that there is an IMAP connection. > Why do you feel that SSL/TLS for session integrity, and Kerberos for > authentication, is a "worst case"? In this case SSL/TLS is what authenticates the server. Meaning: the user must check the certificate. Or: have a CA-Cert (verified!) and an uptodate CRL. If the user is clicks to accept an bogus-certifacte then there is no security. An attacker can setup a proxy-server with an self-signed certificate, do the SSL setup, pass-through Kerberos authentication, and take over the session afterwards. For this reason, I do not like SSL/TLS with Certifactes. An alternative would be SSL with Kerberos instead of Certs as documented in RFC 2712. But support for this is even worse then SASL with GSSAPI and Security layers (afaik. All I could get working so far, without patching, is openssl s_client to s_server and s_client to apache. But apache won't get a client cert and thus, the authentication ssl has done can not be used.) > . limited client implementation (chicken & egg problem) this is a good reason to start implementing it (-: > . limited overall deployment. DIGEST-MD5 has real problems, and Kerberos > remains uncommon. Very few people use the Kerberos code now. Using Kerberos as serverl benefits: - The Server does not need access to the clear-text password of an user. It is neither stored local (as with digest-md5) nor send to the server. In the case of cross-realm trusts, this can extend to a campus-central mail-server able to authenticate all users, but only the department KDC knows the long-term secret. cu maurice _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
