Whole document tree
Cyrus SASL for System AdministratorsThis document covers configuring SASL for system administrators, specifically those administrators who are installing a server that uses the Cyrus SASL library. Sendmail (versions 8.10.0 and higher) and Cyrus imapd (versions 1.6.0 and higher).
Applications use the SASL library to tell them how to accomplish the SASL protocol exchange, and what the results were.
SASL is only a framework: specific SASL mechanisms govern the exact protocol exchange. If there are n protocols and m different ways of authenticating, SASL attempts to make it so only n plus m different specifications need be written instead of n times m different specifications. With the Cyrus SASL library, the mechanisms need only be written once, and they'll work with all servers that use it.
Applications can set their own proxy policies; by default, the SASL library will only allow the same user to act for another (that is, userid must equal authid).
In the simplest case, a single server on a single machine, the realm might be the fully-qualified domain name of the server. If the applications don't specify a realm to SASL, most mechanisms will default to this.
If a site wishes to share passwords between multiple machines, it might choose it's authentication realm as a domain name, such as "CMU.EDU". On the other hand, in order to prevent the entire site's security from being compromised when one machine is compromised, each server could have it's own realm. Certain mechanisms force the user (client side) to manually configure what realm they're in, making it harder for users to authenticate.
A single site might support multiple different realms. This can confuse applications that weren't written in anticipation of this; make sure your application can support it before adding users from different realms into sasldb with saslpasswd.
The Kerberos mechanisms treat the SASL realm as the Kerberos realm. Thus, the realm for Kerberos mechanisms defaults to the default Kerberos realm on the server. They may support cross-realm authentication; check your application on how it deals with this.
The PLAIN mechanism, sasl_checkpass(), and plaintext passwordsThe PLAIN mechanism is not a secure method of authentication by itself. It is intended for connections that are being encrypted by another level. (For example, the IMAP command "STARTTLS" creates an encrypted connection over which PLAIN might be used.) The PLAIN mechanism works by transmitting a userid, an authentication id, and a password to the server, and the server then determines whether that is an allowable triple.
The principal concern for system administrators is how the authentication and password are verified. The Cyrus SASL library is flexible in this regard:
The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does.
Shared secrets mechanismsThe Cyrus SASL library also supports some "shared secret" authentication methods: CRAM-MD5 and its successor DIGEST-MD5. These methods rely on the client and the server sharing a "secret", usually a password. The server generates a challenge and the client a response proving that it knows the shared secret. This is much more secure than simply sending the secret over the wire proving that the client knows it.
There's a downside: in order to verify such responses, the server must keep password equivalents in a database; if this database is compromised, it is the same as if all the passwords for the realm are compromised.
The Cyrus SASL library stores these secrets in the /etc/sasldb database. Depending on the exact database method used (gdbm, ndbm, or db) the file may have different suffixes or may even have two different files ("sasldb.dir" and "sasldb.pag"). It is also possible for a server to define it's own way of storing authentication secrets. Currently, no application is known to do this.
The principle problem for a system administrator is to make sure that sasldb is properly protected; only the servers that need to read it to verify passwords should be able to. If there are any normal shell users on the system, they must not be able to read it.
Managing password changes is outside the scope of the library. However, system administrators should probably make a way of letting user's change their passwords available to users. The "saslpasswd" utility is provided to change the secrets in sasldb. It does not affect PAM, /etc/passwd, or any other standard system library; it only affects secrets stored in sasldb.
Finally, system administrators should think if they want to enable "auto_transition". If set, the library will automatically create secrets in sasldb when a user uses PLAIN to successfully authenticate. However, this means that the individual servers, such as imapd, need read/write access to sasldb, not just read access. By default, "auto_transition" is set to false; set it to true to enable. (There's no point in enabling this option if "pwcheck_method" is "sasldb".)
Kerberos mechanismsThe Cyrus SASL library also comes with two mechanisms that make use of Kerberos: KERBEROS_V4, which should be able to use any Kerberos v4 implementation, and GSSAPI (tested against MIT Kerberos 5 and Heimdal Kerberos 5). These mechanisms make use of the kerberos infrastructure and thus have no password database.
Applications that wish to use a kerberos mechanism will need access to a service key, stored either in a "srvtab" file (Kerberos 4) or a "keytab" file (Kerberos 5). Currently, the keytab file location is not configurable and defaults to the system default (probably /etc/krb5.keytab).
The Kerberos 4 srvtab file location is configurable; by default it is /etc/srvtab, but this is modifiable by the "srvtab" option. Different SASL applications can use different srvtab files.
A SASL application must be able to read its srvtab or keytab file.
You may want to consult the GSSAPI Tutorial.
How to set configuration optionsThe Cyrus SASL library comes with a built-in configuration file reader. However, it is also possible for applications to redefine where the library gets it's configuration options from.
By default, the Cyrus SASL library reads it's options from /usr/lib/sasl/App.conf (where "App" is the application defined name of the application). For instance, Sendmail reads it's configuration from "/usr/lib/sasl/Sendmail.conf" and the sample server application included with the library looks in "/usr/lib/sasl/sample.conf".
A standard Cyrus SASL configuration file looks like:
srvtab: /var/app/srvtab pwcheck_method: kerberos_v4
Application configurationApplications can redefine how the SASL library looks for configuration information. Check your application's documentation for specifics.
For instance, Cyrus imapd reads its sasl options from it's own configuration file, /etc/imapd.conf, by prepending all SASL options with "sasl_": the SASL option "pwcheck_method" is set by changing "sasl_pwcheck_method" in /etc/imapd.conf. Check your application's documentation for more information.
Compiling and installing the library
what configure options to use?
don't install a mechanism you aren't going to use.
use --disable-krb4 and --disable-gssapi if you aren't a kerberos site.
use --disable-cram and --disable-digest if you can't use shared secret mechanisms.
need pwcheck? use --enable-pwcheck
what can go wrong with shared libraries?
make sure to make the /usr/lib/sasl symbolic link.
Unfortunately, since SASL is very flexible (allowing administrators to upgrade and install new authentication plugins without recompiling any applications) its flexibility can also make it a chore to compile.
I'll have some sage advice here when I find some.