7.6 The Simple Authentication and Security Layer (SASL)

The Cyrus SASL project forms the basis for several other products' authentication and session encryption support, most notably the Cyrus IMAP mail server and the OpenLDAP directory server. The Cyrus Simple Authentication and Security Layer (SASL) project provides an extensible framework for network protocol authentication. It is more generic than PAM in that SASL supports more complex authentication exchanges, such as Kerberos mutual authentication, and also supports the negotiation of a security layer (encryption) for later protocol exchanges once authentication is complete. SASL is documented as Internet RFC 2222.

SASL supports native Kerberos 5 authentication through the GSSAPI interface. Other authentication methods that SASL provides to applications include Kerberos 4 and standard /etc/password or /etc/shadow authentication (optionally through a privileged daemon process for services that don't have the necessary privileges to read the system password database). In addition, SASL supports several database-backed authentication methods, including the sasldb, which uses a lightweight database such as Berkeley DB or GDBM to store username/password pairs, and a mysql driver that uses the MySQL database to store authentication secrets.

SASL also includes a daemon process, saslauthd, which can provide password-based Kerberos 5 support to SASL-based applications similar to that of PAM. We'll cover how to build and enable this password verification method as well.

The Cyrus SASL home page is located at http://asg.web.cmu.edu/sasl, and the latest version of the Cyrus SASL distribution available at the time this was written is 2.1.10. We'll step through the process of building the Cyrus SASL library with Kerberos 5 support through the GSSAPI.

The first step, of course, is to acquire the distribution and unpack it. The latest version of Cyrus SASL is available from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail. Download the distribution file (cyrus-sasl-2.1.12.tar.gz at the time of this writing), uncompress, and untar it.

7.6.1 Building the Distribution

Once the distribution is unpacked, we're ready to configure it for GSSAPI support. The only option required to the configure script to enable GSSAPI support is the enable-gssapi option, which takes one argument: the root directory of your installed Kerberos 5 installation. Of course, additional configure options can be appended for other authentication services that SASL supports.

Note that Cyrus SASL has several external dependencies, notably a recent vintage database library such as the Berkeley DB or GNU DBM. During build testing of Cyrus SASL on a FreeBSD host, the configure process claimed to find a compatible DB engine, yet the build failed until GDBM was installed. If you encounter build failures, ensure that you have a compatible DB library installed and have provided the appropriate configure flags so that the build system is aware of it.

For our purposes, we'll configure with only GSSAPI support, assuming that our Kerberos 5 distribution and GSSAPI libraries have been installed in /usr/local:

% ./configure  --enable-gssapi=/usr/local

Next, we're ready to make the source distribution:

% make

Cyrus SASL is notoriously difficult to compile. Even if the configure script runs to completion, the make step may fail because of various db library mismatches or strange interactions with the Kerberos 5 distribution. Hopefully, everything compiles well, and if it does, proceed to installation and configuration:

# make install

7.6.2 SASL Configuration

Cyrus SASL configuration, like PAM, is handled on a per-service basis. Every application that employs SASL for its authentication needs has its own configuration file. These configuration files are located in /usr/lib/sasl2 (or the directory where the plugins are installed) by default, and have the name of Service.conf, om which Service is the name of the application or service. For example, the configuration file for Sendmail's SASL settings is /usr/lib/sasl2/Sendmail.conf, and the sample SASL application's configuration file is located at /usr/lib/sasl2/sample.conf. The service name is defined by the application itself, so the exact name used by a particular application can be gleamed from the source code or the documentation of the application. Other applications mix in SASL configuration directives with the application's own configuration file. In short, the location of the SASL configuration directives for a given application is highly application-dependent, so check the software documentation.

The SASL libraries recognize the following configuration directives. Additional authentication method-specific directives are supported, and documented on the SASL home page. Table 7-2 lists the options that are pertinent to a SASL library configured with GSSAPI support.

Table 7-2. SASL configuration directives

Option	Description	Default
keytab	Location of the Kerberos 5 keytab file for the service's principal.	/etc/krb5.keytab
mech_list	List of the authentication mechanisms this service will use to verify user credentials.	By default, all mechanisms are enabled.
pwcheck_method	The method used to verify plaintext passwords if the PLAIN mechanism is enabled.	auxprop

The SASL libraries can be tested through a sample client and server application located in the sample subdirectory of the source distribution. Before testing, ensure that the machine your sample server resides on has a host principal in the Kerberos database, and the key associated with that principal has been extracted into the system's keytab. When running the server program, ensure that you run it as a user who has access to the system keytab (this usually means root). If you don't feel comfortable running it as root, create a new principal in the Kerberos database, say, sample/hostname@REALM, and extract that to another keytab. Set the KRB5_KTNAME environment variable to point to this new keytab.

The sample server takes several flags. The pertinent flags are -m to define the mechanisms that SASL should use to authenticate the user, and -s to define the service principal that the sample server represents. The service principal should be set to the name portion of the service principal you're using to test (for example sample/hostname@REALM would simply be sample). Run the sample server:

# ./server -s host

Before starting the client, ensure that you have already acquired a TGT for a principal in your realm. When testing the client, the mechanism can be forced to GSSAPI by using the -m command-line option. The client takes the same two arguments above plus another—the hostname of the server to connect to:

% ./client -s host -m GSSAPI freebsd
receiving capability list... recv: {46}
ANONYMOUS PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5
ANONYMOUS PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5
please enter an authorization id: jgarman

The client and server both dump the raw byte contents of the SASL packets to the screen, which while I'm sure is useful to the developers, isn't entirely helpful for anyone else. Either way, don't get too frightened by the sight of this rather verbose debugging information. The client will ask for the authorization id—this is the username that SASL will use to authorize the connection—typically the username portion of the principal that you have a TGT for (see the sidebar Name Canonicalization and SASL for more information). If everything works correctly, the last few lines of your client's output will look like this:

successful authentication
closing connection

If you still have trouble, ensure that the sample server can read the specified keytab, and a key for the service name specified on the command line exists in the keytab.

Name Canonicalization and SASL Kerberos principal names consist of three major parts: the username, instance, and realm. With these three components, a globally unique name can be constructed. Most applications that use SASL use a traditional single username mechanism for authorization purposes. Therefore, a method is needed to map the three-component Kerberos principal name into a single username for authorization. By default, SASL will strip off the realm and use the username and instance part together as a username. However, this can cause problems if there is a cross-realm relationship in which users from a foreign realm can acquire tickets for a SASL-protected service; name collisions can result from usernames that exist in both the local and foreign realms. While SASL does have some support for passing realm information along to the calling application, most applications perform a simple username check. In this case, SASL will only authorize accesses from the local realm, and users coming in through a Kerberos cross-realm trust will be denied access.

7.6.3 Configuring saslauthd

At this point, SASL-enabled applications will be able to use the SASL GSSAPI support to perform native Kerberos 5 authentication. However, there is still a dearth of client applications that are able to perform GSSAPI authentication. Therefore, for backward compatibility with these clients, the saslauthd daemon can be configured to provide password verification services to services that use SASL for authentication services.

The saslauthd program is a daemon that runs continuously in the background, listening on a local domain socket for connections from services. When a service receives a connection that wishes to authenticate with a plain text login and password, it sends a message to saslauthd over the local socket, containing the username and password that the user presented for verification. Upon receipt of this information, saslauthd verifies the credentials against the configured authentication source. Through this mechanism, the security-sensitive process of verifying user passwords can be separated out into a small process that can run as root, and free the service itself from requiring superuser privileges just to verify passwords.

One of saslauthd's supported authentication mechanisms is Kerberos 5. When verifying Kerberos passwords, saslauthd takes the username and password passed to it from the requesting service, appends the local realm to the username to form the client principal, and attempts to acquire a TGT for the principal from the local realm's KDC. If the supplied password successfully decrypts the TGT, saslauthd then requests the host principal to ensure that the KDC reply is genuine. Because of this check, saslauthd will have to be run with root privileges and the system keytab will have to contain a key for the host principal.

If the host key does not exist in the system keytab, or is not readable by saslauthd, saslauthd will refuse all authentication attempts with a generic error, so this should be one of the first steps taken when troubleshooting saslauthd problems.

To enable saslauthd, simply execute it as part of the startup scripts of any host that runs services that use SASL for authentication. You will have to start saslauthd as root to read the system keytab, and add a command-line flag to enable the Kerberos 5 mechanism:

# saslauthd -a kerberos5