SASL analysis, part one

This is a network authentication layer that is still confused by many people with the crypt interface (local authentication methods). It currently provides a few dozen methods, but there is one serious problem. Due to the variety of methods and the development of cryptography, it is challenging to compare the security level of each method. Another annoying fact is the ability to even find a comparison of the security of these methods. This article is intended to offer such a comparison.

What is SASL (Simple Authentication and Security Layer)

The most common question is what the SASL is actually for. It's simple. It's one of the basic mechanisms providing user authentication tools. Originally, it was mainly used for mail server purposes, i.e. it provided POP3, IMAP4 and SMTP authentication. And it continues to be used here. Later, this protocol was implemented for authentication in protocols such as LDAP (directory services), XMPP (communication tools), but it can also be used in other places. One of the many less well-known options is, for example, its support in some implementations of VNC (Virtual Network Computing), a remote desktop access program.
What else can I say? According to Wikipedia, this is a ‘...general method for authentication in client/server protocols. Its main purpose is to authenticate clients on servers. SASL has several authentication mechanisms for exchanging authentication information (usually referred to as login credentials) and a authentication system for storing user information. The SASL authentication mechanism controls the prompts and replies between the client and the server and how they should be encoded during transmission. The authentication system refers to how the server stores and authenticates data.’ The methods used are standardized by IETF (RFC 2222, RFC 4422 and supporting RFC 2245, RFC 2595, RFC 2831, RFC 4505, RFC 4616, RFC 5801, RFC 6631, RFC 7677) have their own IANA algorithm registers and open implementation. For example, they are implemented within Cyrus SASL, GNU SASL, Java SASL and other libraries.

History of SASL

The reason for the creation was the extremely unsatisfactory situation when verifying users of postal systems. Although there were more developed mechanisms at the time, algorithms such as PAP, CHAP, MSCHAP, or other mechanisms such as APOP were generally used to access mail. These mechanisms are part of the introductory article.
The first version of SASL, but not yet under this designation, originated in 1993 at Carnegie Mellon University as the Cyrus Project (Cyrus). This project was named after the Persian king Cyrus the Great, who was historically known for his system of royal routes and postal couriers, which greatly boosted the country's economy (Cyrus was probably later inspired by the Romans). The system of postal couriers can be considered to be a precursor of communication systems to some extent. The aim of this project was to create a universal authentication framework and to separate authentication mechanisms from communication protocols, the authors most often being Rob Siemborski and John Gardiner Myers. The author of the original specification was J. G. Myers, which was later approved by the IETF as RFC 2222. These recommendations were in line with the proposal, minor differences due to the formalization of the algorithms were elaborated in Cyrus SASLv1. After less than a decade, the first major change occurred, the new document was created by Alexey Melnikov and Kurta D. Zeileng (RFC 4422) and SASLv2 was created.

Differences between versions

There are basic differences between the first and second versions of SASL, which can be summed up with a few sentences in the following paragraph. SASLv1 had a monolithic structure that was difficult to expand and several built-in mechanisms (Anonymous, LOGIN, PLAIN and further Digest-MD5, CRAM-MD5). The second version had a modular architecture, there is support for the GSSAPI, EXTERNAL and SCRAM methods. While the first version mainly supported protocols for mail services such as IMAP, POP3, SMTP and later LDAP, the second version tries to be a universal interface. There are other differences, for example the first version did not support integrity assurance, it only supported cryptographic mechanisms due to the time of creation and the like.

Important terms

Within the analysis, the following terms and methods of evaluation are used, which describe advantages and disadvantages of each algorithm.
- Channel Binding is a technology that provides a link between the authentication mechanism and the communication protocol. The aim is to protect the connection from hijacking, or at least to provide basic authentication at the beginning of the connection.
- Realms means an area, in the IT world for example DNS denotes a domain or a domain of services in which a certain service is provided.
- Crypto-primitives provide an overview of the algorithms used. The mechanisms mentioned are outdated from today's perspective, which are acceptable at the current level and which will be prospectively secure.
- The number of participants specifies how many of them are involved in user authentication. For common mechanisms, authentication takes place on the target server (i.e. client and server), but there are mechanisms where the authentication is provided by a third party (client, authentication server and server of the service). In this case, either the authenticated user identification is provided to the target server (usually a token), or the token may also contain authorization information (where everywhere the user has access).
- PQC/QRC inform whether the mechanism is resistant to quantum computers (Post Quantum Cryptography or Quantum Resistant Cryptography)
- ZKP. This term refers to the Zero Knowledge Protocols. In short, it refers to a protocol that allows password authentication during the information process without providing information that could lead to its discovery.
- crypt support is more or less additional information and more on this topic is in a separate paragraph.
- Tokenization is closely related to the number of communicating parties, but is not a condition.
- Uniqueness describes the authentication information transmitted. This should be unique (unrepeatable), random and unpredictable. Ensuring that all three parameters are met is difficult.
- Credentials protection (Account information, password, key material etc.) is an important part of authentication. The vast majority of password protection occurs, but algorithms capable of protecting the user's name or realms (realms)
- Replay protection is now more or less an essential part of authentication. Every time you log in, authentication must be used in such a way that the information cannot be re-used. Otherwise, the attacker may intercept the information and log in.
- Relay protection is a much more challenging discipline. To ensure protection against the transfer of information (for example, an attacker's server posing as the provider's server) the control to which the user connects must be ensured, so mutual authentication must take place. Unfortunately, this technology is very little used.
- Hijack protection consists of linking authentication information to a communication channel. The aim is to protect against the possibility of hijacking the connection to the attacker's machine. Again, these methods are not often used to the detriment of the owners. Very closely related to Channel Binding, unfortunately, these are not synonyms.
- The Forge protection to some extent includes previous terms. This is protection against an attacker who aims to falsify the user's login.
- MFA support is now part of a mantra to ensure higher security. This is true when using different communication channels (OOB - Out of band), but debatable when using a single one.
- Integrity protection consists in implementing one of the MAC technologies (Message Authenticity Code), i.e. a cryptographic checksum. Outside of the MAC term, the term MIC (Message Integrity Check), ICV (Integrity Code Verification)
- Channel protection used - the authentization channel uses internal encryption, optional transport encryption, uses mandatory transport encryption, or uses end-to-end encryption (E2EE, usually above transport encryption as protection against SSL inspection)

Relationship between SASL and crypt interface

At first glance, there is a simple relationship between SASL and crypt, the outputs of some functions may look similar. But why can't they be interchanged? They may have a similar output, i.e. identifier, number of rounds, salt, output hash … but all form ends there. There is no relationship between these two methods, but for some algorithms it is possible to use server-side authentication against the local password database in the form provided by the crypt method (more on this topic in "Storing password with Crypt interface"). These are the methods PLAIN, LOGIN, CRAM-MD5 and under certain conditions e.g. GS2/GSS-API/SPNEGO/Kerberos, or EXTERNAL or OTP. Other algorithms do not support this procedure and even with these methods it is necessary to understand how exactly they work and whether these mechanisms can be used. Alternatively, whether their deployment will be implementation and architecturally dependent. For this reason it is often much secure to let the SASL mechanism use its own database, which is not connected to the system in any way.

Overview of SASL methods that are part of the analysis

When the connection is initialized, a specific method is selected, further user authentication is performed based on this choice. The choice is made by sending the following information:
AUTHENTICATE SASL [Method]

Explanation of the relationship between GS2, GSSAPI, SPNEGO and Kerberos

The above methods have quite complicated links, given their design and general function.
Kerberos. Probably the simplest method is Kerberos, which can be taken as a separate authentication mechanism.
GSSAPI (Generic Security Services Application Programming Interface) is actually nothing else than an interface for authentication, where the most common protocol is Kerberos. The reason was quite prosaic, there is still no standardized interface for Kerberos and the interface is provided by GSSAPI. Eventually the API started to support the SPNEGO method as well. The use in SASL is interesting because SASL is an API, which uses another API here.
SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a mechanism from the Microsoft operating system environment, which used NTLM (more commonly NTLMv1 and NTLMv2) and Kerberos for authentication against Active Directory. In the Microsoft environment, SPNEGO is part of SSPI (API for SPNEGO and other mechanisms), SPNEGO can use GSSAPI as one of the mechanisms. At the same time, GSSAPI can use SPNEGO as one of its mechanisms. It's a little tangled, but that's how it was designed.
GS2 (Generic Security Service Mechanism for SASL) uses GSSAPI as an interface for authentication, Kerberos is one of the possible authentication mechanisms here.

Incomplete method overview (predecessors of SASL)

In addition to the methods below, other methods of verification were used. Typically, it depended on the method of communication, i.e. whether serial lines (UUCP, SLIP, PPP …) or a clean network connection over TCP/IP were used. The methods listed are outdated and difficult to use, they are listed only for documentary reasons.

PAP (Password Authentication Protocol)
This is practically a BASIC method (see below), where the client sends a request for authentication to the server in an unencrypted way.

CHAP (Challenge Autentication Protocol)
This is a slight improvement of the method where the client sends a request for user login, the server provides a prompt for the reply and the client responds with hashes to the message ID, password and prompt.
Server → Client: C_S
Client → Server: MD5(ID||Password||C_S)

APOP (Auhtentization before POP)
It is a protocol specific to POP3 only, i.e. a protocol designed for downloading mail.
Server → Client: C_S
Client → Server: MD5(Password||C_S)

Analysis of Methods

The actual SASL methods that are part of the overview always contain a section dealing with algorithm description, cryptographic writing and evaluation. At present, most of these algorithms are of rather historical importance, so it is necessary to consider the importance of their deployment in the production environment.

9798-U-DSA-SHA1, 9798-U-ECDSA-SHA1, 9798-U-RSA-SHA1-ENC

9798-U-algorithm is an algorithm for unidirectional (Unilateral) certificate authentication, where the client authenticates against the server, but the server does not authenticate. The authentication algorithm allows the use of DSA, ECDSA and RSA algorithms.

Server → Client: Challenge S_A
Client → Server: TokenC(C_A||Client Certificate||DSA-(S_A||C_A))

S_A, C_A – Random prompt from server and client, must be a unique value.

Channel Binding: No
Realms: Yes
Cryptoprimitives: Obsolete (SHA1, DSA), rundown (RSA)
Number of participans: 2
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protected: No
Replay protection: Yes
Protection against Relay: No
Hijack protection: No
Protection against Forge: Yes
MFA support: No
Integrity protection: No
Encryption type: Internal

9798-M-DSA-SHA1, 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC

9798-M-algorithm is an algorithm for two-way (Mutual) certificate authentication, where both client to server and server to client are authenticated. The authentication algorithm allows the use of DSA, ECDSA and RSA algorithms.

Server → Client: Challenge S_A
Client → Server: TokenC(C_A||Client Certificate||DSA-(S_A||C_A)||Optional I_C)
Server → Client: TokenS(S_B||Server Certificate||DSA-(S_A||C_A||S_B)||Optional I_S)

S_A, S_B, C_A - Random prompt from server and client, must be a unique value.
I_S, I_C - Server identifier and client identifier

Channel Binding: No
Realms: Yes
Cryptoprimitives: Obsolete (SHA1, DSA), rundown (RSA)
Number of participans: 2
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protected: No
Replay protection: Yes
Protection against Relay: Yes
Hijack protection: Yes
Protection against Forge: Yes
MFA support: No
Integrity protection: No
Encryption type: Internal

Anonymous

Anonymous connection without password, anonymous name is required.

Channel Binding: No
Realms: No
Cryptoprimitives: No
Number of participans: ?
PQC/QRC: No
ZKP: Ne
Crypt interface support: Ne
Tokenization: Ne
Uniqueness: No
Credentials protected: No
Replay protection: No
Protection against Relay: No
Hijack protection: No
Protection against Forge: No
MFA support: No
Integrity protection: No
Encryption type: None

PLAIN

This is text information about the username and password. The information is sent in open text (PLAIN), without any protection. The use of transport encryption is a necessary, but not sufficient method of protection, because in the case of SSL inspection, this authentication information is obtained.

Client → Server: (username||0x00h||password||0x00h)

Channel Binding: No
Realms: No
Cryptoprimitives: No
Number of participans: 2
PQC/QRC: No
ZKP: Ne
Crypt interface support: Yes
Tokenization: No
Uniqueness: No
Credentials protected: No
Replay protection: No
Protection against Relay: No
Hijack protection: No
Protection against Forge: No
MFA support: No
Integrity protection: No
Encryption Type: No, Necessary

LOGIN

This is again a text information about the username and password. In this case there are two exchanges between the server and the client, the client sends the encoded data. The above information is only encoded using BASE64 (4B to 6B encoding so that the result is always printable characters from the 7-bit ASCII range), but otherwise without any protection. The use of transport encryption is a necessary, but again insufficient method of protection, because in the case of SSL inspection it is also possible to obtain authentication information.
A similar method of logging is the BASIC method for web servers, where the string "username:password" is encoded using BASE64 and sent in response to the server authentication request.

Server → Client: Username:
Client → Server: Base64(username)
Server → Client: Password:
Client → Server: Base64(password)

Channel Binding: No
Realms: No
Cryptoprimitives: No
Number of participans: 2
PQC/QRC: No
ZKP: Ne
Crypt interface support: Yes
Tokenization: Ne
Uniqueness: No
Credentials protected: No
Replay protection: No
Protection against Relay: No
Hijack protection: No
Protection against Forge: No
MFA support: No
Integrity protection: No
Encryption Type: No, Necessary

CRAM-MD5

Simple protection of login information based on random prompting and MD5 hash. The client and server share a password or password hash, in which case the password is considered.

Server → Client: C_S
Client → Server: HMAC-MD5(Password, C_S)

Channel Binding: No
Realms: No
Cryptoprimitives: Obsolete (MD5)
Number of participans: 2
PQC/QRC: No
ZKP: No
Crypt interface support: Can be used
Tokenization: No
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Protection against Relay: No
Hijack protection: No
Protection against Forge: No
MFA support: No
Integrity protection: No
Encryption type: Internal

DIGEST-MD5

Simple protection of login information based on random prompting and MD5 hash. The client and server share a password or password hash, in which case the password is considered.

Server → Client: C_S
Client → Server: MD5(MD5(username||realm||password)||C_S||C_C)||C_S||Auth)||C_C

Where to login: Auth=method||URI
For integrity : Auth=MD5(message)

Channel Binding: No
Realms: Yes
Crypto-primitives: Obsolete (MD5)
Number of pages on authentication: 2
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Relay protection: No
Hijack protection: No
Forge protection: No
MFA support: No
Integrity protection: No
Encryption type: Internal

PASSDSS

Password-based Secure Device Authentication is a user authentication mechanism created using a DES algorithm. It exists in both PASSDSS-DES-1 and PASSDSS-3DES-1 versions and was used for authentication using SSH keys based on the DSA algorithm. At the beginning, there was an exchange of information, which was signed by DSA keys to ensure trustworthiness. The transmitted information was used to derive key material that was encrypted with a user password. While creating the authentication information, the message created an incomplete open text checksum, the entire result including the MAC is encrypted. The structure of the algorithm is complicated from today's perspective.

Client: SharedSecret=DHPublicKey_Client=g^{PrivKey_Client}
Server: SharedSecret=DHPublicKey_Server=g^{PrivKey_Client}
Client → Server: Request
Server → Client: DSA Public Key_Server||DSASignature(Key_Server,C_Server)
Client → Server: DSA Public Key_Client||DSASignature(Key_Client,C_Client)
Client:
- K=Public Key_Server^{PrivKey_Client}
- cs-encryption-iv = SHA1( K || "A" || H )
- sc-encryption-iv = SHA1( K || "B" || H )
- cs-encryption-key-1 = SHA1( K || "C" || H )
- cs-encryption-key-2 = SHA1( K || cs-encryption-key-1 )
- cs-encryption-key = cs-encryption-key-1 || cs-encryption-key-2
- sc-encryption-key-1 = SHA1( K || "D" || H )
- sc-encryption-key-2 = SHA1( K || sc-encryption-key-1 )
- sc-encryption-key = sc-encryption-key-1 || sc-encryption-key-2
- cs-integrity-key = SHA1( K || "E" || H )
- sc-integrity-key = SHA1( K || "F" || H )
- data=AuthID||DSA Public Key_Client||DSA Public Key_Server||mask||buffer)
- MAC=HMAC-SHA-1(cs-integrity-key, data)
Client → Server: Enc-3DES-CBC(cs-encryption-key, mask||buffer||passphrase, IV=cs-encryption-iv)||MAC

Channel Binding: No
Realms: No
Cryptoprimitives: Obsolete (DES, 3DES, SHA-1, DSA, DH)
Partner sides: 2
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Protection against Relay: No
Hijack protection: No
Protection against Forge: No
MFA support: No
Integrity protection: No
Encryption type: Internal

Compuserve RPA (non-standard)

Compuserve Remote Passphrase Authentication is a proprietary mechanism from the mid-1980s. Originally used to authenticate users to the CompuServe network, thanks to this mechanism and a wide spread, it was later included in the SASL library. It is currently in decline, its safety properties are insufficient from the current perspective.

Client → Server: Request||Username
Server → Client: List of identities
Client → Server: ID||Username||Service
Server → Client: C_Server||Timestamp
Client → Server: C_Client
Client → Server: Response_Client=MD5(Password 128b||Padding 48B||Username||Service||ID||C_Client||C_Server||Timestamp||Password 128b)
Server → Client: Response_Server=MD5(Service Password 128b||Padding 48B||Username||Service||ID||C_Client||C_Server||Timestamp||Response_Server||Service Password 128b)

Channel Binding: No
Realms: Yes
Cryptoprimitives: Obsolete (MD5)
Partner sides: 2
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Protection against Relay: No
Hijack protection: No
Protection against Forge: No
MFA support: No
Integrity protection: No
Encryption type: Internal

SRP

Secure Remote Password is an older but high-quality authentication mechanism within the design of the original SASL. It uses modular arithmetic to encrypt one-time password output. This mechanism can still be available on some platforms as SRP or PAKE and despite its age it excels in quality. From today's point of view it is possible to reproach some details, currently I would recommend replacing it with the algorithm OPAQUE, SESPAKE (RFC 8133), SPAKE2+ (RFC 9383). Unfortunately, these algorithms are not available within SASL.

Client:
- Random R
- A=g^R mod p
Client → Server: Username||A
Server:
- Random R
- Salt S from file with saved passwords
- Validator V is the result of one-way password saving
- B=(V+g^Q) mod p
Server → Client: B||S
Client:
- Password
- H=SHA-1(S||SHA-1(Username|":"|Password))
- T=(B-g^H)^{(R+Username*H)} mod p
- W=SHA-1_Interleave(T)
- M=SHA-1(SHA-1(p) xor SHA-1(g)||SHA-1(Username)||S||A||B||W)
Client → Server: M||K
Server: Z=H(A||M||K)

Channel Binding: No
Realms: No
Cryptoprimitive: Obsolete (SHA-1)
Partner sides: 2
PQC/QRC: No
ZKP: Yes
Crypt interface support: Maybe
Tokenization: No
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Relay protection: No
Hijack protection: Yes
Forge protection: Yes
MFA support: No
Integrity protection: Yes
Encryption type: Internal

Overview

This part dealt mainly with the history and basic mechanisms that are associated with the history of authentication mechanisms. This history included mechanisms that use asymmetric cryptography from the top of the list. The other mechanisms that use the client-server architecture will be discussed in the next parts. The other mechanisms that use multiple parties will be discussed in the next parts. Continuing in SASL, part two.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.