[Imap-uw] sasl secuity-layer support
massar at unix-ag.uni-kl.de
Tue Feb 7 02:00:14 PST 2006
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
> . 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.
More information about the Imap-uw