SASL is an Internet Standard method for adding authentication support to connection-based protocols. Along with the pages on TLS (Transport Layer Security) and Strong Authentication, this page describes the infrastructure of the Isode products that use cryptography.

The Internet family of protocols usually has one protocol for each distinct piece of functionality (e.g., SMTP (Simple Message Transfer Protocol) is used for transferring messages between servers). Authentication is different - there are many approaches. There are a two reasons for this. The first is that there is no ideal authentication mechanism: there is generally a trade-off between factors such as user convenience; network security; overall security; ease of management; and efficiency. This leads to there being a choice of mechanisms with different characteristics. The second factor is that the choice of secure authentication mechanisms evolves with increasing availability of computing power (e.g., DES was being replaced with AES) and new technologies (e.g., biometrics). We need to recognize that there will continue to be many approaches to authentication, and should not expect convergence on a single approach.

SASL gives a framework that enables application protocols to negotiate an agreed authentication mechanism. SASL can enable (dependent on the agreed mechanisms)

  • Server authentication of the client.
  • Client authentication of the server.

SASL's authentication ID approach also provides an elegant mechanism to enable application logins using simple “ids” to be efficiently mapped onto directory based configuration, and to hide directory naming from the end user.

How SASL works

SASL is not a protocol, but is a framework that can be used with protocols such as SMTP. For each protocol that uses SASL, there will be a specification (an Internet Standard in cases where the base protocol is an Internet Standard) as to how the protocol uses SASL. This means that SASL can be used with a wide range of protocols, and can be adapted to the details of how any specific protocols works.

The basic operation of SASL is straightforward. The server provides a list of supported authentication mechanisms, and then the client says which one will be used (based on the client’s capabilities and security requirements).

Protocols that contain SASL support include:

  • LDAP (Internet Standard Lightweight Directory Access Protocol)
  • SMTP (Internet Standard Simple Message Transfer Protocol)
  • POP3 (Internet Standard Post Office Protocol v3)
  • IMAP (Internet Standard Internet Mail Access Protocol)
  • XMPP: Extensible Messaging and Presence Protocol
  • Isode's SOM (Switch Operations and Management) Protocol

To be used with SASL, a new authentication mechanism needs to be registered, and any authentication mechanism specific capabilities set out in an Internet standard. Selected SASL authentication mechanisms are listed below:

Mechanism Standardization What it Does
CRAM-MD5 RFC 2195 Use MD5 hash for client authentication
DIGEST-MD5 RFC 2831 Adds server authentication and confidentiality to CRAM-MD5
GSSAPI RFC 4752 For supporting Kerberos authentication
EXTERNAL RFC 4422 For use with SSL/TLS and X.509 Digital Signatures
PLAIN RFC 4616 Clear text password
LOGIN de facto Alternative to PLAIN
NTLM Microsoft Proprietary Similar to CRAM-MD5
SCRAM-SHA-1 RFC 5802 Salted Challenge Response Mechanism (SCRAM)

Information on Isode’s use of SASL EXTERNAL is covered under strong authentication and X.509 support.

SCRAM is a secure password authentication mechanism that Isode expects to gain widespread use. For further information see [SCRAM: A New Protocol for Password Authentication].

Isode’s Kerberos support used the GSSAPI SASL mechanism. On Windows, this is provided as an integrated capability using Microsoft libraries. On other platforms, a third party GSS_API libary is needed. Further description of Isode's Kerberos support is given in the whitepaper [Isode Support for Kerberos, Active Directory and Single Sign On].

SASL Name Mapping

SASL will authenticate using an authentication identifier, which is typically a simple username. This SASL name may be different to the name required by the application using SASL. Isode’s SASL implementation provides a flexible approach for mapping between these names.

For the password based SASL mechanism (CRAM-MD5, DIGEST-MD5, PLAIN, LOGIN, NTLM and SCRAM-SHA-1) the SASL name is a simple username. For many protocols, this string will be the same as the application name. For example for XMPP the SASL name will be the JID and for IMAP the SASL name will be the email address.

However, for directory, the name used by the application is the structured Directory Name (DN). Isode makes use of the directory, which may be Isode’s M-Vault or another LDAP directory to map from the SASL name to the DN. Isode’s SASL gives three options for this mapping:

  1. Searching the directory for an attribute holding the id.
  2. A two level search, for “user” and “domain” in a user@domain structured id.
  3. An Active Directory style algorithmic mapping of email address onto directory name.

These options allow organizations to choose a mapping suitable for operational requirements. Isode generally recommends use of the first option.

It is often desirable to use directory based authentication for a wide range of applications including Web applications. The directory DN is generally inconvenient for users, and SASL enables a more familiar username/password approach to be taken and SASL authentication to the directory hides the directory name from the user, as shown below.

Proxy Authentication

This model is also used by Isode’s own applications. Authorization can be based on attributes stored in the directory (e.g., Security Clearance). The LDAP client can use the LDAP Whoami operation in order to find its own name and to read information from the directory.

When Kerberos Authentication (SASL GSSAPI mechanism) is used, SASL authentication is based on the Kerberos Principal Name. A directory based mapping, with the same three mapping options described above is available to identify an entry in the directory associated with the Kerberos Principal Name. Other names can then be read from the directory entry (e.g.,XMPP jid).

When SASL EXTERNAL is used, the SubjectName of the X.509 certificate will identify an appropriate entry in the directory and SubjectAltName will be used to hold values for other protocols (email address and JID).

Isode's SASL Support

Isode uses SASL in the following protocols and products:

  • LDAP (in M-Vault)
  • SMTP (in M-Switch)
  • SOM Isode protocol (in M-Switch)
  • IMAP (in M-Box)
  • POP3 (in M-Box)
  • ManageSieve (in M-Box)
  • XMPP (in M-Link and the Swiften XMPP Client Library)

Details on SASL support and configuration is given in the product manual.