What SASL is

SASL, the Simple Authentication and Security Layer, is a method for adding authentication support to connection-based protocols. SASL is defined in RFC-2222. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer between the protocol and the connection. SASL is a means for authenticating yourself to the server without providing your password in the clear. This can also be used to provide extended capabilities based on your authorization. In plainer words, a SASL mechanism can provide authentication only, or it can also provide integrity checking, and possibly encryption as well.

During authentication , the mechanism performs authentication, transmits an authorization identity or userid, from the client to server, and negotiates the use of a mechanism-specific security layer, possibly encryption.

If use of a security layer is negotiated, it is applied to all subsequent data sent over the connection. The security layer takes effect immediately following the last response of the authentication exchange for data sent by the client and the completion indication for data sent by the server. Once the security layer is in effect, all further data transfers use this encryption.

In order to implement SASL authentication, you need support on the client and on the server

The various implementations of SASL provide the following mechanisms for authentication:

• ANONYMOUS - used to "authenticate" clients to anonymous services; or rather just indicate that the client wishes to use the service anonymously. The client sends a token, usually her email address fast simple, not secure
• CRAM-MD5 - uses username (authorization identity only) and password to authenticate users. Only a hashed password is transfered, which means that you cannot use normal policy deciding authentication systems such as PAM which do not support extraction of passwords, simple, good security
• KERBEROS_V4 - trusted third party authentication, fast, somewhat difficult, strong security
• PLAIN - uses username (authentication identity and authorization identity) and password to authenticate users, fastest, simplest, weak security
• SCRAM-MD5 (deprecated)
• GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5) - uses a framework similar to SASL for authenticating the user, fast difficult to implement, strong security
• DIGEST-MD5 - based on the same cryptographic operation as CRAM-MD5 but supports more features, such as an authorization identity (proxy authentication) and cryptographic protection of data. Like CRAM-MD5, only a hashed password is transfered, which means that you cannot use e.g. PAM as a backend since it does not support extraction of passwords, simple, good security
• LOGIN - uses username (authorization identity only) and password to authenticate users, fast, simple, not secure
• SRP (unsupported, may not work)
• OTP
• SECURID - uses authentication and authorization identity and a passcode from a hardware token to authenticate users, good speed, hard to implement, good security

Developers can write their own mechanisms to SASL to provide authentication.

It's relatively easy to define a protocol that uses SASL- it has to support a couple of simple functions, and it doesn't need to know anything about any particular mechanism. The first requirement is that servers must be able to tell the client what mechanisms are available. Typically this is done when the server sends a greeting to the client, telling it what options it supports. The second requirement is that clients must be able to tell the server to start a particular mechanism, and then both must be able to exchange "blobs" of information to initialize the mechanism, possibly indicating success or failure. The final requirement is that on success both the client and the server call a routine to filter traffic to/from the network. If the mechanism is doing any kind of cryptography, this routine will transparently handle it for the application.