SASL (Simple Authentication and Security Layer) is a framework for adding and implementing authentication and authorization support to network-based or communication protocols. The SASL design and architecture permit negotiation against various authentication mechanisms.

Notably, you can use SASL alongside other protocols such as HTTP, SMTP, IMAP, LDAP, XMPP, and BEEP. This framework features a range of commands, callback procedures, options, and mechanisms.

Although this article will focus on the various SASL commands that every user should know, we will go a little further to discuss the rest of the other SASL packages.

The SASL Synopsis

Below is a summary of the SASL synopsis:

Common SASL Commands

Like most authentication frameworks and protocols, SASL has an array of commands, including:

This SASL command helps with constructing new context tokens. As you will find out during your interaction with SASL, you need a new token for most SASL procedures.

This command modifies and inspects each SASL context option. You will find more details in the SASL Options section.

This command is arguably the most vital one in the SASL framework. You can make calls to this procedure until it reads 0. When using this command, you will realize that each step takes a challenge string from the server. Also, the context will calculate and store the response. For actions that do not require any server challenge, ensure that you provide empty strings for the parameter. Finally, ensure that all mechanisms accept an empty challenge from the onset.

The response command is responsible for returning the following response string that should go to the server.

If you are looking to discard the internal state of the context, the reset command will help. It reinitializes the SASL context and allows you to reuse the token.

This command cleans up the context by releasing any resources associated with the context. But unlike you will find with the reset command, the token may not be reusable after calling this procedure.

The mechanisms command will provide you with a list of available mechanisms. The list will come in the order of the preferable mechanism. So, the most preferred mechanism will always be at the top. The minimum preference value of mechanisms defaults at 0. Any mechanism with a value less than the minimum will not appear on your returned list.

This requirement helps boost security since any mechanisms with preference values that fall under 25 are susceptible to leakage or eavesdropping and should not appear unless you are using TLS or any other secure channels.

This command allows you to add new mechanisms to the package by specifying the name of the mechanism and the implementation channels. After initiating the mechanisms command, you can opt for the server procedure and choose the topmost mechanism from the list.

SASL Options

An array of options specifies procedures on the SASL framework. They include:

-callback

The –callback option specifies the command due for evaluation whenever a mechanism requires information about users. To call the utility, you need to use the current SASL context alongside the specific details of the information you need.

-mechanism

This option sets the SASL mechanism for use in a given procedure. You can check the mechanisms sections for a comprehensive list of SASL-supported mechanisms.

-service

The –service option sets the service type for the context. If the mechanism parameter is not set, this option will reset to an empty string. When the –type option is set to server, this option will automatically set to valid service identity.

-server

The –server option sets the server name used in SASL procedures whenever you choose to operate as a SASL server.

-type

This option specifies the context type, which can only be of ‘client’ or ‘server.’ Notably, the –type context is by default set on the client application and will respond automatically to server challenges. However, you can sometimes write it supports server-side.

SASL Callback Procedures

The SASL framework is designed to call any procedures provided during context creation whenever it requires any user credentials. When creating the contexts, you will need to also make an argument with the details of the information you need from the system.

Ideally, you should always expect a single response string in each case.

• login- This callback procedure should bring back the user’s authorization identity.
• username- The username callback procedure returns the user’s authentication identity.
• password- Normally, this callback procedure produces a password similar to the authentication identity used in the present realm. You should first call authentication identity and the realm before calling the password callback procedure if you are using the server-side mechanisms.
• realm- Realm strings are protocol dependent and fall within the current DNS domain. Many mechanisms use realms when partitioning authentication identities.
• hostname- This should return the hostname of the client.

Example

The below example summarizes most of the points raised in this article. It should give you an idea of using this framework and its commands. Every time you call the step command, the command argument will be the last response to allow the mechanism to take the desired action.

Conclusion

SASL provides application and program developers with reliable authentication, encryption, and data integrity-checking mechanisms. But for system administrators, this is a framework that you will find handy when securing your systems. Understanding and correctly using Linux SASL begins with understanding the ASASL commands, SASL callback procedures, SASL mechanisms, SASL options, and the framework’s synopsis.

Sources:

• http://www.ieft.org/rfc/rfc2289.txt
• https://tools.ietf.org/doc/tcllib/html/sasl.html#section6
• http://davenport.sourceforge.net/ntlm.html
• http://www.ietf.org/rfc/rfc2831.txt
• http://www.ietf.org/rfc/rfc2222.txt
• http://www.ietf.org/rfc/rfc2245.txt
• https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml