Subject: [Imap-uw] sasl authentication

From: Mark Brand <[email-masked]>
Date: Fri, 17 Jun 2005 15:35:47 +0200

If I understand correctly, the only way to use SASL authenication when
connecting to the uw-imap server is use a built in facility that reads
usernames and passwords from the plain text file /etc/cram-md5.pwd.
Presumably the administrator has to maintain this file by hand to keep
it synchronized with whatever the primary user authentication system is
on the machine.

I saw Jim Rigg's 2005-07-23 post on the c-client list about introducing
support for SASL authenication via the Cyrus SASL which authenticates
using mechanisms like PAM or LDAP (I think), and this made me curious. 
Is there existing or planned support for Cyrus SASL or something
similiar? Are there other techniques for using SASL to protect the imap
login in such a way that password management is well-intergrated with
the standard mechanisms?

Mark

-- 
Mark Brand
Technology Director
N200
-------------------
[email-masked]
tel +31 20 448 9700
fax +31 20 448 9701

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

---

From: Mark Crispin <[email-masked]>
Date: Fri, 17 Jun 2005 08:10:52 -0700 (PDT)

> login in such a way that password management is well-intergrated with

You understand incorrectly.

Unfortunately, it's a long explanation.  Get some coffee, and sit back.

First, some definitions:

(1) SASL is an Internet challenge/response protocol that can use various 
mechanisms to authenticate and negotiate a security layer.  The challenges 
and responses are *not* protected in any way; only the mechanism called by 
SASL can do that.

(2) CRAM-MD5 is one of many SASL authentication mechanisms.  It uses a 
one-way HMAC-MD5 hash.  The server issues a one-time text that the client 
must hash along with the password; the client then reports the result of 
that hash.  The server compares it with its own calculation of that hash. 
This mechanism has some flaws, but for the most part it does protect the 
authentication from snoops.

(3) PAM is an API on some UNIX and Linux systems to validate 
authentication credentials the application having to know what the 
underlying authentication mechanism is.  What's particularly useful about 
PAM is that the site can configure how authentication works per 
application without having to change the application.  PAM is largely used 
with userid/password type authentication.

(4) LDAP is a protocol to distribute directory data to multiple system. 
Bizzarely, it is also used to distribute passwords.  Some people seem to 
think that this is a good thing.

Now, as for what UW imapd can do:

UW imapd supports for multiple SASL mechanisms: CRAM-MD5, GSSAPI, PLAIN, 
LOGIN, ANONYMOUS, and (as of imap-2005) EXTERNAL.  Of these, CRAM-MD5 and 
GSSAPI implement a means of authentication that can be spied upon without 
giving the spy useful information.

For what it's worth, the Cyrus servers at Carnegie-Mellon University 
(authors of Cyrus) support these SASL mechanisms: KERBEROS_V4, GSSAPI, 
ANONYMOUS, PLAIN.  KERBEROS_V4 is an older version of Kerberos; GSSAPI is 
the Kerberos v5 is the modern version.

The /etc/cram-md5.pwd file is the database for CRAM-MD5 authentication in 
UW imapd.  UW imapd can't use the password file, PAM, or an LDAP database 
because the server needs to know the plaintext of the password in order to 
calculate the HMAC-MD5 hash.  This is one of the flaws of CRAM-MD5, and is 
why that SASL mechanism has never been particularly popular.

UW imapd can be built to use PAM to validate passwords.  In fact, PAM is 
the default on many Linux builds.  Using PAM, UW imapd can also validate 
with LDAP; this is not a feature of UW imapd but rather of PAM.

It needs to be emphasized that the use of PAM and/or LDAP to validate 
username/password doesn't make the authentication secure; it's still the 
insecure username/password.  PAM and LDAP are simply conveniences for the 
server's internal use (and the server system manager).

UW imapd can also be built to validate passwords from the password file 
(/etc/passwd or shadow password), from a OS-specific mechanism (e.g. 
SecureWare), or via Kerberos.  On many systems, the default is to use the 
password file.

Although Kerberos was mentioned in the previous password, that is *not* 
"Kerberos authentication".  Rather, that is password authentication in the 
Kerberos database (just like PAM or LDAP password authentication).  That 
can be done directly by UW imapd, or through PAM.

Kerberos authentication, on the other hand, is the GSSAPI SASL mechanism. 
The GSSAPI SASL mechanism *is* supported by UW imapd.

Now, let's consider your last two questions:

> similiar?

The answer is "yes, there is existing support for something similar."

UW imapd has a full implementation of SASL.

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.

> Are there other techniques for using SASL to protect the imap

The answer is the same with both UW imapd's native SASL and Cyrus SASL:

The technique is Kerberos.

Kerberos, using the GSSAPI SASL mechanism (*not* passwords!) is the 
preferred protected means of authentication for everybody.

If you must use passwords, then you need to protect the session using 
SSL/TLS encryption.  This is not a feature of Cyrus SASL; this is a 
feature of the server.  Both UW imapd and Cyrus imapd (as do all other 
modern IMAP servers) have full implementations of SSL/TLS.

If you want to access passwords via PAM (many modern sites do!), then this 
is not a feature of SASL.  It is simply a feature of whatever mechanism 
authenticates the password.  UW imapd fully supports PAM, and I imagine 
that Cyrus SASL's password authenticator does too.

If you want to access passwords via LDAP, you can do that using PAM.

-- 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 Crispin <[email-masked]>
Date: Fri, 17 Jun 2005 08:20:55 -0700 (PDT)

I guess that your next question will be: "then how do I do this using UW 
imapd's existing facilities?"

What you need to do is specify what "this" means:
  . use the same database for passwords for all systems?
  . negotiate passwords securely?
  . negotiate authentication without letting snoops steal passwords?
  . etc.

There is a way to do "this" in UW imapd, but you need to know what "this" 
is because doing some "this" prevents you from doing other "this".

It's like "The Hitchhiker's Guide to the Galaxy", where it is revealed 
that the answer to the ultimate question of life, the universe, and 
everything is 42.  The problem is, nobody knew the question...

-- Mark --

---

From: Mark Brand <[email-masked]>
Date: Fri, 17 Jun 2005 19:45:26 +0200

> I guess that your next question will be: "then how do I do this using
> UW imapd's existing facilities?"
>
> There is a way to do "this" in UW imapd, but you need to know what
> "this" is because doing some "this" prevents you from doing other "this".
>

Thanks for the explanation. Maybe I can formulate a sensible question
now. I would like advice about how to do the following:

-use PAM to check usernames and passwords
-negotiate passwords securely
-negotiate authentication without letting snoops steal passwords (Isn't
this the same as the last point?
-avoid having to encrypt the the whole session (imaps)

Cyrus SASL with SSL/TLS is widely used for client authentication by
postfix. I think I'm looking for how to do this with imapd.

Mark

---

From: Mark Crispin <[email-masked]>
Date: Fri, 17 Jun 2005 14:25:34 -0700 (Pacific Daylight Time)

On Fri, 17 Jun 2005, Mark Brand wrote:
> I would like advice about how to do the following:

PAM is already set as the authentication mechanism on some of the Linux 
based builds (lnp, ldb, lmd, lrh, lsu) and the oxp build in Mac OS X.

For other systems, add either:
 	PASSWDTYPE=pam
or, if you have the misfortune of using Solaris or other systems with a 
defective PAM implementation:
 	PASSWDTYPE=pmb
to the make command line.  For example:
 	make bsf PASSWDTYPE=pam
 	make soc PASSWDTYPE=pmb

Note that you have to set up imap and pop rules for PAM in /etc/pam.d.  On 
my system, I just copied /etc/pam.d/ftpd to /etc/pam.d/imap and 
/etc/pam.d/pop.  If you want to use some other database (e.g. LDAP) you 
will need to modify these files.

Of course, you do have to have PAM installed on your system before you can 
use it.  PAM is not part of UW imapd; it is a separate and completely 
independent package.

> -avoid having to encrypt the the whole session (imaps)

The first two are the same, and the answer contradicts with the third. 
That is, you either uses SSL (connect on the imaps port) or use you TLS 
(connect on the imap port, and then negotiate STARTTLS).

By default, UW imapd is set up that a client must do one or the other; it 
is not permitted to do a password authentication unless SSL/TLS encryption 
has been negotiated first.  This is set by the default setting of SSLTYPE 
as:
 	SSLTYPE=nopwd

The non-default setting:
 	SSLTYPE=unix
builds with SSL/TLS support, but allows passwords without encryption 
(which is, of course, unsafe).  The non-default setting:
 	SSLTYPE=none
builds without SSL/TLS support.

> postfix. I think I'm looking for how to do this with imapd.

Hopefully, you're realizing that the equivalent is essentially already 
done for you; the capabilities already exist in UW imapd.  It may, in 
fact, be done and installed on your system without you knowing it; since 
you would have had to build UW imapd in a non-standard way to prevent it 
from happening.

-- Mark --

---

From: David B Funk <[email-masked]>
Date: Fri, 17 Jun 2005 16:40:44 -0500 (CDT)

[snip..]
> -avoid having to encrypt the the whole session (imaps)

secure authentication negotiation and secure password negotiation are
NOT necessarily the same thing. For example, a system using GSSAPI
(with Kerberos-V) does not have to deal with passwords at all.

There is a security server (Kerberos-KDC) who is the 'keeper of the keys'
and your mail server is just an authentication "customer" of that
security server. IE your mail server says "hey this user claims to
be 'bill' and has provided me credentials to back up that claim.
Mr security server, please help me validate these creds so I can
know if that claim is believable"
(details are a bit more involved, but you get the picture).

Authentication is the process of validating somebody's identity
claim, passwords are just one possible way to do it.

If the authentication method is secure then you don't have to encrypt
the whole session (unless you care about protecting the privacy of
your client's e-mail reading from eavesdroppers ;).
CRAM-MD5, GSSAPI, & SRP are examples of secure authentication methods.

> postfix. I think I'm looking for how to do this with imapd.

"SSL/TLS" is a mechanism to provide a secure communications channel,
it has nothing to do with authentication. However it does make it possible
to use an insecure authentication method (such as clear text passwords)
safely. (which is why you often hear "SSL/TLS" mentioned when talking
about authentication).

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Fri, 17 Jun 2005 14:46:06 -0700 (Pacific Daylight Time)

> (with Kerberos-V) does not have to deal with passwords at all.

Correct.

> your client's e-mail reading from eavesdroppers ;).

Not quite correct.  There is another risk to not encrypting; the session 
can be seized and taken over ("hijacked") as well as being eavesdropped. 
There are hacker tools to do this.

-- Mark --