SASL, or Simple Authentication and Security Layer, is an authentication framework that specifies and describes the process of plugging authentication mechanisms into application protocols. It is an internet standards framework or track method for authenticating remote computers.
The SASL framework enables the implementation of authentication mechanisms on servers and applications that use IMAP, XMPP, ACAP, LDAP, and SMTP protocols. It provides shared libraries and application developers with the right and reliable data-integrity checking, encryption, and authentication mechanisms.
This article provides you with an introduction to SASL. It will discuss the features and characteristics of SASL and how this framework operates. Besides, this article will highlight the SASL architecture and end by describing the various mechanisms involved.
Features of SASL
This authentication layer intuitively allows developers to code applications and programs to a generic API. It does not specify the technology for performing any authentication, as that responsibility lies with each SASL mechanism. Thus, the approach is handy in avoiding dependencies on specific authentication or encryption mechanisms.
Of course, the protocols mentioned earlier support SASL. The SASL library is popularly referred to as libsasl, a framework that vets and allows the right SASL programs and applications to use the SASL plug-ins available in your system.
SASL is a framework that relies on various mechanisms to govern the protocol exchange. These security mechanism plug-ins allow SASL to provide the following functions:
- Authenticate on the server-side
- Authenticate on the client-side
- Check the integrity of the transmitted data
- Ensures confidentiality by encrypting and decrypting the transmitted data
Authorization and Authentication Identifiers in SASL
First, it is important to know the difference between an authorization identifier in SASL and an authentication identifier. Usually, the user id, userid, or authorization id for SASL is an identifier that any Linux application uses to check the options it can allow access to and use.
On the other hand, the authentication id or auth id represents the authentication identifier. This identity is the identifier that is bound for checking by the system. The system only authenticates users whose identities and passwords match the details stored.
How SASL Works
Just like its name, SASL works in a pretty simple way. The negotiation begins with the client requesting authentication from the server by establishing a connection. The server and the client will make copies of their respective local copies of the library (libsasl) through the SAL API. libsasl will establish a connection with the required SASL mechanisms via the service provider interface (SPI).
The server will respond with a list of all the supported mechanisms. On the other hand, the client will respond by choosing a single mechanism. The server and client will then exchange data until the requested authentication process fails or succeeds. Notably, the client and server will know whoever is on the other side of the channel.
The illustration of the architecture is in the figure below:
An illustration of an SMTP authentication is in the figure below:
The first 3 lines in the illustration contain a list of all the supported mechanisms, including CRAM-MD5, DIGEST-MD5, and Plain, among others; they are from the server. The following line is from the client and indicates that it chose the CRAM-MD5 as the preferred mechanism. The server replies with a message generated by SASL functions. Finally, the server accepts the authentication.
Like most frameworks, SASL supports the “realms” concept. And by definition, realms are abstracts of users. You will also discover that specific mechanisms can only authenticate users within certain realms.
Common SASL Mechanisms
We have already noted in the previous sections that SASL works when the server lists the available mechanisms and the client chooses one of the mechanisms for a particular authentication. So, some of the SASL mechanisms that you will most likely interact with include:
Shared Secret Mechanisms
The two primary share secret mechanisms supported by SASL are the CRAM-MD5 and the DIGEST-MD5 that came after. They rely on the success of the client and server sharing a secret, and this secret will often be a password. The server will question the client about this secret. On the other hand, the client should always provide the answer to this secret to prove that it knows the secret.
While this method is more secure than sending passwords across networks, its feasibility relies on the ability of the server to keep secrets in its database. A security breach on the server database will also compromise the security of the stored passwords.
PLAIN Mechanisms
Solely, this method is pretty less secure. It is therefore ideal for connections that already have other levels of encryptions. It works by transmitting an authentication id, a user id, and a password to the server so that the server can determine if the combination is correct and allowable or not.
Notably, the biggest concern with this mechanism is how the authentication credentials and passwords are checked and verified.
Kerberos Mechanisms
Finally, the SASL library has mechanisms that can use Kerberos 4 and Kerberos 5 authentication systems. The KERBEROS_V4 mechanism can use the Kerberos 4, while the GSSAPI can use Kerberos 5. Since they use the Kerberos interface, they do not need any passwords.
Conclusion
This authentication layer is helpful in an array of Linux applications and programs. From this article, you should now have an idea of what the authentication layer entails. This article specifically discusses the features, architecture, and how SASL works in a Linux environment. The article also briefly explains some of the common SASL mechanisms you will meet.
