Subject: [Imap-uw] sasl secuity-layer support

From: Maurice Massar <[email-masked]>
Date: Sat, 4 Feb 2006 02:47:06 +0100

hi,

Are there plans to add support for the security-layer part of SASL?
This would allow people using kerberos for authentication to have
encrypted pop3/imap sessions without worring about SSL-certs,
fingerprints etc.

Searching the archives I found:
http://mailman1.u.washington.edu/pipermail/imap-uw/2005-June/000080.html
> It is not Cyrus SASL, but there is little (if anything) to be gained by 
> ripping out UW imapd's native SASL support to install Cyrus SASL.

currently Cyrus-SASL does support Security Layer, so if it is less work
to do the switch, you could consider this?

cu
Maurice Massar
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Fri, 3 Feb 2006 18:42:03 -0800 (Pacific Standard Time)

> encrypted pop3/imap sessions without worring about SSL-certs,

There are plans, however, they aren't particularly high priority. 
Relatively few IMAP clients support SASL security layers, whereas just 
about every IMAP client supports TLS and/or SSL.  I could count the number 
of times I've been asked about supporting SASL security layers in UW imapd 
on one hand...and still have some fingers left!

For that matter, relatively few IMAP clients support Kerberos.  I use 
Kerberos with IMAP extensively, and have always just used TLS for 
security.

> to do the switch, you could consider this?

It would *far* more work to convert UW imapd to use Cyrus-SASL than it 
would to implement the security layer in the existing UW SASL Kerberos 
code.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Sirota <[email-masked]>
Date: Fri, 03 Feb 2006 22:16:36 -0500

--On Friday, February 3, 2006 6:42 PM -0800 Mark Crispin 
<[email-masked]> wrote:
> I could count the number of times I've been asked about supporting SASL
> security layers in UW imapd on one hand...and still have some fingers
> left!

Penn will happy take another finger. :-)

> Kerberos with IMAP extensively, and have always just used TLS for

Penn is doing everything we can to increase the number of Kerberized IMAP
clients, like contributing the funds to Kerberize Eudora and contributing
the SASL/GSSAPI/Kerberos implementation recently introduced in
Thunderbird (we'll have LDAP done by the next release).

We have also kinda-sorta Kerberized Horde/IMP webmail and have
implemented SASL/GSSAPI/Kerberos for authentication with the webmail
"imapproxy" program.  However, because the HTTP connection from the user
to the webmail host is not Kerberized, the implementation requires some
trust on the part of the IMAP server that the webmail service has
properly authorized the user.  Someday, when we have a proper Kerberos
over HTTP solution, we'll be all the way there.

Sadly, the loss of Mulberry in October makes it a two step forward, one
step back sort of process.

Mark

---

From: Mark Crispin <[email-masked]>
Date: Mon, 6 Feb 2006 17:02:11 -0800 (Pacific Standard Time)

> Penn will happy take another finger. :-)

Could you explain why SASL security layers are so important to Penn?

Don't you have to offer SSL/TLS anyway, due to all the clients that don't 
have Kerberos?  Don't your Kerberos clients now do SSL/TLS, and then 
authenticate using Kerberos?

As far as I can tell, the main benefit to using SASL security layers 
(instead of SSL/TLS) is to eliminate the overhead of SSL/TLS key 
generations, and possibly also an RTT, in the initial session connection. 
Otherwise, far more sites are going to have SSL/TLS than Kerberos (or 
DIGEST-MD5, the other SASL mechanism which IIRC has security layers).

Am I missing something?

I agree that, conceptually, SASL security layers is the cleanest way to do 
things, but SSL/TLS seems to be the direction most people choose.

-- Mark --

---

From: Mark Sirota <[email-masked]>
Date: Mon, 06 Feb 2006 22:25:31 -0500

--On Monday, February 6, 2006 5:02 PM -0800 Mark Crispin 
<[email-masked]> wrote:
> Don't you have to offer SSL/TLS anyway, due to all the clients that
> don't have Kerberos?  Don't your Kerberos clients now do SSL/TLS, and
> then authenticate using Kerberos?
>
> generations, and possibly also an RTT, in the initial session
> connection. Otherwise, far more sites are going to have SSL/TLS than
> Kerberos (or DIGEST-MD5, the other SASL mechanism which IIRC has
> security layers).
>
> Am I missing something?
>
> I agree that, conceptually, SASL security layers is the cleanest way to
> do things, but SSL/TLS seems to be the direction most people choose.

You're right, of course, Penn would also have to continue to support
TLS/SSL in addition to SASL/GSS/Kerberos, because we have almost no
control over the choice of IMAP client, and there are a great many that
people like that don't support SASL at all (never mind security layers).
Those are not our recommended clients or configurations, but that doesn't
stop people from using them.  We hope for a future where that's not true,
of course.

However, the majority (rapidly becoming the vast majority) of our users
choose to use our webmail service, which is an IMAP client over which we
have complete control.  So while incomplete in the near term, we'd still
get a pretty big win.

As for "the direction people choose", yes, client vendors seem to choose
this, and sometimes users choose clients from those vendors.  However, I
think most server administrators would choose SASL security layers over
TLS/SSL, if given the choice  -- no certificates to manage (including
things like the revocation problem), and better performance at scale.

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.

In addition, we try to take a long-term view and stay on the high road
when it comes to doing things The Right Way.  Call me old school (I've
been doing this Internet e-mail thing for 21 years), but for me and my
organization this has actual value.  If we can help facilitate better
solutions for all, by contributing code, pressuring vendors, etc. to do
the right thing, the world will be a better place.

Mark
-- 
Mark Sirota, Associate Director, Network Engineering and Services
University of Pennsylvania, Information Systems and Computing
[email-masked], 215/573-7214

---

From: Mark Crispin <[email-masked]>
Date: Mon, 6 Feb 2006 19:43:42 -0800

Hi Mark, comments interspersed below.

On Mon, 6 Feb 2006, Mark Sirota wrote:
> However, I

I don't understand how this can be an either/or.  TLS/SSL seems to be a 
given for the foreseeable future.  Thus, the question is whether or not 
SASL security layers should also exist as an "and".

The benefits to SASL security layers (at least that I am aware of) are:
  . possible savings of an RTT
  . savings of SSL/TLS key generation overhead on the server.

The disadvantages that I see are:
  . greater complexity -- more security-critical code (and worse, code that
    is not often tested/exercised)
  . limited client implementation (chicken & egg problem)
  . limited overall deployment.  DIGEST-MD5 has real problems, and Kerberos
    remains uncommon.  Very few people use the Kerberos code now.

> work to minimize its occurrence.

Why do you feel that SSL/TLS for session integrity, and Kerberos for 
authentication, is a "worst case"?

My intent isn't to be argumentative; I'd really like to be convinced 
because my own arguments in favor of doing SASL security layers failed to 
convince me.

> organization this has actual value.

I've been doing this Internet e-mail thing from back when it was ARPAnet 
(before Internet).  32 years, as I calculate it.  So I guess that I'm old 
school.

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.

-- Mark --

---

From: Maurice Massar <[email-masked]>
Date: Tue, 7 Feb 2006 11:00:14 +0100

hi,

> 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.

> 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.)

>    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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 8 Feb 2006 18:15:20 -0800 (Pacific Standard Time)

On Tue, 7 Feb 2006, Maurice Massar wrote:
> [snip]

Thank you for your comments.  Since I always take certificate warnings 
seriously, I tend to forget that many users just ignore these warnings.

I wish that Kerberos was better deployed (and much easier to configure on 
Windows!).  Sadly, many systems are set up with a fallback to plaintext 
passwords, which IMHO largely defeats the benefit of Kerberos.

Here's another issue that comes up with the UW IMAP client code.  Unless 
explicitly told not to, it negotiates TLS automatically on all non-SSL 
links before it even thinks about authentication.

The story gets worse.  Suppose, as site policy, all sessions must have 
both integrity and privacy protection; and both clients and servers must 
enforce this policy.  This means that the server must refuse to 
authenticate a session that does not set the security layer to 4 (I'm 
assuming that privacy protection implies integrity protection); but only 
if SSL/TLS is not in effect.  Since the client also insists upon both 
integrity and privacy protection, it must abort a GSSAPI negotiation that 
does not offer it.

This makes for a very complex initial authentication.

Also, isn't Kerberos vulnerable to a MITM attack on the client->KDC path? 
Although Windows insists upon a negotiated client password (which has 
other problems), MIT Kerberos does not.

-- Mark --