On Fri, 17 Jun 2005, Mark Brand wrote:
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.
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?
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:
Is there existing or planned support for Cyrus SASL or something
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
login in such a way that password management is well-intergrated with
the standard mechanisms?
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
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
