Introduction

Strong authentication uses cryptographic techniques to verify the identity of the end points in a network exchange. For sendmail, strong authentication ensures that the connecting host and the receiving host are who they claim to be. In this chapter, we look at how AUTH can be used for authentication.

Authentication is not the same as encryption. Encryption can be used to hide the content of a piece of mail or to hide the entire SMTP protocol exchange, including the mail. (One technique for encrypting the SMTP exchange, and the mail it carries, is covered in Chapter 8.) Authentication does not hide the contents of mail; rather, it ensures that the mail comes from the correct source.

Traditional sendmail authentication systems are based on the hostname or IP address. Examples of this can be found in Chapter 3, which uses hostnames and IP addresses to grant relaying privileges. However, the current IP address of a valid client may not be known. A mobile client that obtains its address from a DHCP server may have an address that constantly changes. Mobile clients need an authentication scheme that is not dependent on a changeable IP address. Additionally, hostnames and addresses are easily spoofed and thus do not provide strong authentication. Of course, it is debatable whether a service such as mail relaying really needs strong authentication, but it is clear that mobile clients need authentication that is independent of the IP address. The AUTH protocol provides some strong authentication techniques that do not rely on the IP address or hostname.

The AUTH Protocol

AUTH is an SMTP protocol extension. It is defined in RFC 2554, SMTP Service Extension for Authentication . RFC 2554 outlines the negotiations that are used to select an authentication mechanism. The RFC describes three functions for the AUTH keyword:

• 250-AUTH is the response of the SMTP EHLO command. The response advertises the supported authentication mechanisms. The configuration that causes sendmail to list AUTH in the EHLO response and to accept incoming AUTH connections is covered in Recipe 7.1. That configuration applies when sendmail runs as an MTA, and it is only applicable when sendmail is run with the -bd command-line option.

• AUTH is the SMTP command used to request authentication and to select the authentication mechanism for the session. The connecting host must select one of the mechanisms advertised by the receiving host, or the authentication attempt is rejected. sendmail will request AUTH authentication when it is configured as described in Recipe 7.2. A laptop or desktop that sends SMTP mail but does not accept inbound SMTP connections could be configured using only Recipe 7.2. A system that accepts incoming AUTH connections and creates outgoing AUTH connections would combine the configurations from both Recipe 7.1 and Recipe 7.2.

• AUTH= is a parameter used on the MAIL From : line to identify the authenticated source address. The AUTH= parameter comes from the connecting host as part of the initial envelope sender address. If the receiving host trusts the AUTH= parameter, it propagates it on to the next mail relay. Recipe 7.6 provides additional information about the AUTH= parameter.

The AUTH protocol relies on SASL (the Simple Authentication and Security Layer (SASL) for the actual authentication. RFC 2222, Simple Authentication and Security Layer (SASL) , describes the SASL framework and defines how protocols negotiate an authentication method. RFC 2222 identifies four authentication techniques:

KERBEROS_V4

Authentication is performed by a Kerberos 4 server.

GSSAPI

The GSS-API is used for authentication. This type of authentication can be performed by a Kerberos 5 server.

S/KEY

The one-time password system S/Key is used for authentication.

EXTERNAL

Authentication depends on an external security system, such as Transport Layer Security (TLS).

Subsequently, several more authentication techniques have been added to the SASL framework. Some examples are:

ANONYMOUS

This technique, which is defined in RFC 2245, permits unauthenticated access.

PLAIN

Authentication is based on clear text passwords.

LOGIN

This is an undocumented authentication technique, included for compatibility with outdated SMTP clients, that also uses clear text passwords.

CRAM-MD5

This is a shared secret authentication method that uses Message Digest 5 (MD5) for security. Challenge Response Authentication Mode MD5 (CRAM-MD5) is an older authentication method that has been superceded by DIGEST-MD5.

DIGEST-MD5

This is the preferred MD5 authentication method. Like CRAM-MD5, it is a shared secret authentication method that uses Message Digest 5 (MD5) for security. However, DIGEST-MD5 is more resistant to security attacks, and it supports encryption of the SMTP conversation.

sendmail does not contain implementations of the various authentication techniques. Instead, sendmail uses the techniques that are implemented and configured in SASL. For this to work, Cyrus SASL must be installed and properly configured on the sendmail system.

Cyrus SASL

Cyrus SASL is implemented as a library. The SASL library standardizes the way in which applications interface with the authentication methods . Many Unix systems come with the SASL libraries preinstalled . Our sample Red Hat Linux system is a good example. Red Hat includes SASL as one of the standard RPMs. An rpm command can check whether it is installed, as in this example:

 # rpm -qa cyrus-sasl cyrus-sasl-1.5.24-25 

If SASL is not installed on your system, check to see if it was delivered as part of your Unix software. If it was, install the copy of SASL provided by your Unix vendor. If it is not available from your vendor, go to http://asg.web.cmu.edu/cyrus/download/ or ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/ to download the latest version of SASL. Information on SASL is available at http://asg.web.cmu.edu/sasl/.

After Cyrus SASL is installed, the specific authentication techniques must be configured before they can be used. To understand SASL configuration, you must understand SASL terminology. The Cyrus SASL documentation defines four special terms: ^[1]

^[1] In addition to these four special items, SASL uses a password when one is required by the authentication technique.

userid

The username that determines the permissions granted to the client. The client is given the permissions normally granted to the specified user . userid is also called the authorization id .

authid

The account name used to authenticate the connection. authid is also called the authentication id .

realm

A group of users, systems, and services that share a common authentication environment. All members of a given group use the same realm value. It is common to use a domain name or hostname for the realm value.

mechanism

Identifies the type of authentication used. For example, DIGEST-MD5 is a valid mechanism value.

The userid and authid values cause the most confusion. To understand how SASL uses these two values, think of an /etc/passwd file with one entry for craig and another for kathy . In a normal login, when Kathy logs in to the kathy account, she is granted the permissions given to that account. With SASL, it is possible to set authid to kathy and userid to craig , which means that the kathy account password is required for authentication, but the permissions granted to the user are the permissions granted to the craig account.

Several of the strong authentication techniques available through SASL require the configuration of separate authentication services ”KERBEROS_V4 and GSSAPI are good examples. This chapter focuses on the strong authentication techniques that can be implemented on a sendmail system without installing any software other than SASL. Two strong authentication techniques, DIGEST-MD5 and CRAM-MD5, are provided with the Cyrus SASL libraries. Both of these techniques can be easily configured for sendmail authentication.

DIGEST-MD5 and CRAM-MD5 are configured through the /etc/sasldb database. This is done using the saslpasswd commands. Use saslpasswd to enter the SASL authid and realm and the password that the connecting host will use during authentication. Recipe 7.1 provides an example of how this is done.

Because these are shared-secret authentication mechanisms, the connecting host must be configured with values that match those entered in the sasldb file on the receiving host. On sendmail 8.12 systems, these values are defined in an AuthInfo : entry. Normally this entry is placed in the access database, as described in Recipe Recipe 7.2. Optionally , an authinfo file can be used to hold the AUTH credentials, as described in Recipe 7.3.

The SASL Sendmail.conf file

DIGEST-MD5 and CRAM-MD5 are very secure and easily configured, making them excellent choices for sendmail authentication. There are, however, other authentication techniques available through SASL that can be used with sendmail. While DIGEST-MD5 and CRAM-MD5 do not require it, some of the other mechanisms require configuration through the Sendmail.conf SASL application file. Three configuration commands can be used in the Sendmail.conf file. They are:

srvtab

The srvtab command points to the file that contains the Kerberos 4 service key. The argument provided with this command is the full pathname of the service key file.

auto_transition

The auto_transition command causes SASL to automatically create a sasldb entry for every user that authenticates using the PLAIN authentication method.

pwcheck_method

The pwcheck_method command defines the technique that SASL should use to validate the clear text password received during PLAIN method authentication. The possible values for the pwcheck_method are:

passwd

Tells SASL to look up passwords in the /etc/passwd file.

shadow

Tells SASL to look up passwords on the /etc/shadow file. Because of the file permissions associated with the /etc/shadow file, the application must be running as root .

pam

Tells SASL to use Pluggable Authentication Modules (PAM). PAM must, of course, be properly configured to authenticate the password.

sasldb

Tells SASL that the passwords for the PLAIN authentication method are stored in the sasldb file. Normally, sasldb is only used for DIGEST-MD5 and CRAM-MD5 authentication.

kerberos_v4

Tells SASL to authenticate clear text passwords through the Kerberos 4 server. Kerberos 4 must be installed, configured, and running, and the Kerberos 4 server must be configured to accept clear text passwords.

sia

Tells SASL to use Digital's Security Integration Architecture (SIA) to validate passwords.

pwcheck

Tells SASL to pass the data to an external program for password checking.

A sendmail system that advertised the PLAIN authentication method might have a Sendmail.conf file similar to the one shown below:

 # cat /usr/lib/sasl/Sendmail.conf pwcheck_method:pam 

The recipes in this chapter do not require the /usr/lib/sasl/Sendmail.conf file because they each use the DIGEST-MD5 authentication mechanism, which does not require the Sendmail.conf file. DIGEST-MD5 is secure, easy to configure, and available as part of Cyrus SASL. If you must use another SASL authentication mechanism, see the SASL documentation for more information on how they are configured.

Passing Flags to SASL

sendmail can be configured to request optional processing from SASL for the AUTH protocol. The confAUTH_OPTIONS define can set several flags that affect the way that sendmail and SASL interact. These flag are listed in Table 7-1.

Table 7-1. SASL flags

Flag	Purpose
A	Use the AUTH= parameter only when successfully authenticated.
a	Request optional protection against active attacks during the authentication exchange.
c	Require client credentials if the authentication mechanism supports them.
d	Reject authentication techniques that are susceptible to dictionary attacks.
f	Don't use the same static shared-secret for each session.
p	Reject authentication techniques that are susceptible to simple passive attacks.
y	Don't allow the ANONYMOUS authentication mechanism.

The A option controls when the AUTH= parameter is added to the envelope sender information on the SMTP Mail From : command line. The A option is used in Recipe 7.6, which demonstrates how the confAUTH_OPTIONS flag define is used.

The a option increases the checks SASL performs to detect active authentication attacks. SASL is used in a variety of situations. In some applications, higher security is worth the cost in increased processing and authentication delays. Normally, that is not the case for email. Mail hosts are authenticating to prevent spammers from relaying through your server. Spammers do not spend the time and money to launch active authentication attacks against servers that use strong authentication. When increased security is needed for an email connection, it is probably better to use transport layer security, as described in Chapter 8.

The c flag tells SASL to require client credentials when an authentication mechanism is used that supports client credentials. (Although it is not used inside of a SASL session, the TLS protocol, described in Chapter 8, is an example of a protocol that optionally permits the use of client credentials.) Don't confuse client credentials with AUTH credentials. The AUTH credentials discussed in this chapter are the shared-secret and other AUTH values used for authentication. The DIGEST-MD5 and CRAM-MD5 authentication techniques used by sendmail require AUTH credentials without the c option.

The f option tells SASL to use forward security between sessions. This means that the shared-secret used for one session is not used in the next session. Some technique must be used to negotiate a new secret for each session. Of course this requires an authentication mechanism that can handle forward security. The authentication techniques commonly used by sendmail do not implement forward security; therefore, this flag is not normally used in sendmail configuration.

The three remaining options, d , p , and y , all limit the techniques that can be used for authentication. For example, specifying the p option blocks the use of the PLAIN and LOGIN techniques over an unsecured connection.

These flags pass information to SASL, changing the way that SASL serves sendmail. Values passed from SASL are also used inside sendmail.

Authentication Macros and Rulesets

sendmail uses the information provided by authentication. sendmail stores authentication data in several macros. The authentication macros are:

${auth_author}

This macro holds the sendmail authorization id, which is the address assigned to the AUTH= parameter on the MAIL From : line.

${auth_authen}

This macro holds the sendmail authentication id, which is either the userid or the userid and the realm , written as userid @ realm .

${auth_type}

This macro holds the name of the authentication method used to authenticate the client. For example, DIGEST-MD5 would be a possible ${auth_type} value.

${auth_ssf}

This macro holds the number of bits used for optional SASL encryption. If no SASL link encryption is used, this macro is unassigned .

In addition to the authentication macros, the hostname and the IP address of the system at the other end of the mail transport connection are stored in macros, which can be useful information for authentication checks. The following values are stored in the macros:

${server_addr}

The IP address of the remote server, as determined from the TCP connection. This macro is used on the client.

${server_name}

The hostname of the remote server, as determined from a hostname lookup of the ${server_addr} value. This macro is used on the client.

${client_addr}

The IP address of the client, as determined from the TCP connection. This macro is used on the server.

${client_name}

The hostname of the client, as determined from a hostname lookup of the ${client_addr} value. This macro is used on the server.

sendmail also provides ruleset hooks that simplify the process of adding authentication checks. The primary hooks used with AUTH are:

Local_check_mail

This ruleset adds checks to the check_mail ruleset, which is used to process the envelope sender address from the MAIL From : line. The check_mail ruleset is not specific to AUTH, but the overlap between the ${auth_author} value and the envelope sender address means that Local_check_mail is occasionally used for custom AUTH processing.

Local_check_rcpt

This ruleset adds checks to the check_rcpt ruleset, which processes the envelope recipient address from the RCPT To : line. The check_rcpt ruleset is not specific to AUTH, but because it is used to authorize delivery to a recipient, Local_check_rcpt is occasionally used to modify it for AUTH processing.

Local_trust_auth

This ruleset adds checks to the trust_auth ruleset, which is used by the server to determine whether the AUTH= parameter on the MAIL From : line should be trusted. The trust_auth ruleset is specific to the AUTH protocol because the AUTH= parameter is only used when AUTH is running on the client. Use Local_trust_auth to customize the processing of the AUTH= parameter.

Local_Relay_Auth

This ruleset is called by the Rcpt_ok ruleset. By default, sendmail grants relaying privileges to an authenticated client only if the client authenticated is using a mechanism listed in the $={TrustAuthMech} class. Use Local_Relay_Auth to modify the process of granting relaying privileges to authenticated clients.