SASL Analysis, Part Two

The continuation of the previous article discusses other individual algorithms and their properties. The aim is to provide a material that can be used in case of analysis of used technologies.

EAP-AES128 and EAP-AES128-PLUS

EAP (Extensive Authentication Protocol) is a framework, containing a set of authentication mechanisms. It was originally designed for PPP connections (Point to Point Protocol). Today, however, it is also used within Ethernet and WiFi networks (IEEE 802.1x), for authentication within VPN networks, mobile networks (most often EAP-SIM), it can also be used on DSL/ADSL and HDSL connections and can be continued. Its deployment is linked to the RADIUS and DIAMETER protocols (EAP in EAPOL protocol). Standardization is covered by IANA, currently about 50 algorithms are registered.
SASL can use authentication mechanisms provided within EAP, the actual transmitted framework is then encrypted using the AES algorithm. In the vast majority it is probably encryption using CBC or CTR mode, but I did not find any documentation that formalizes the procedure. Nor did I find information about formalization of integrity protection. From the security point of view it would be better to use e.g. GCM or CCM mode (AEAD, i.e. authenticated encryption with associated data) either at the level of SASL EAP-AES128, or at least to use encryption within EAP ensuring both confidentiality and integrity protection. At present it is definitely possible to use EAP-TLS, or EAP-PSK, theoretically it should be possible to use any other EAP mechanisms. The basic version transfers information between client and server, the extended version (EAP-AES128-PLUS) links the communication to another channel.
The actual EAP-AES128 uses a simple way of protecting the communication, where the key material and authentication information are processed in the following way.

Client - Server: Agree on a shared secret or provide the key K_Server using asymmetric algorithms outside EAP
Key: k=PBKDF2(K_Server, salt, iteration, 128b)

Client→ Server: AES128(k,EAP message)
Server→ Client: AES128(k,EAP message)

In the case of a channel, some form of channel authentication should occur, i.e. either ensuring integrity or inserting information inside the channel in a way that will be accepted within EAP. I have not been able to simulate the above, but perhaps the idea of such evaluation can be realized e.g. by the following procedure, where CCC represents a cryptographic checksum and CSD represents Channel Specific Data (certificates, MAC addresses of both parties and others).

CCC = HMAC(PBKDF2(k, salt, iteration),AES128(k(EAP message)||CSD)

Channel Binding: No for the base version, yes for the PLUS version
Realms: according to EAP algorithm
Crypto: Obsolete (MD4, MD5, SHA-1), rundown (RSA), current ECDH
Partner sides: 2
PQC/QRC: No, current asymmetric cryptography is insufficient.
ZKP: No
Crypt interface support: according to EAP algorithm
Tokenization: according to EAP algorithm
Uniqueness: Yes
Credentials protected: Yes, password, under certain conditions even username
Replay protection: Yes
Protection against Relay: Yes
Hijack protection: Not for the basic version, yes for the PLUS version
Protection against Forge: Yes
MFA support: according to EAP algorithm
Integrity protection: No (not found)
Encryption type: Internal, optionally according to EAP could be used TLS

ECDH-X25519-CHALLENGE

Authentication by this algorithm requires registration of the public key to the user name on the authenticating server side. Within the SASL, he arranges for a shared secret using Montgormery's representation of Curve25519 (x25519). The agreement on the shared secret proceeds as follows. Curve parameters, private keys and value derivation functions are defined. Based on the inputs, they find a shared secret that allows the client to decrypt the masked value of the connection prompt. If at the end of the calculation the corresponding server connection challenge is proven, the authentication is successful.

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

Server → Client: C_Server(PubKey_Server||salt|| (Challenge_Session ⊕ ECDH-X25519-KDF)

Client → Server: C_Client(PubKey_Server||salt|| (Masked Challenge_Session ⊕ ECDH-X25519-KDF)

ECDH-X25519-KDF
 {
    IKM = Hash(SharedSecret || PubKey_Client || PubKey_Server)
    PRK = HKDF-Extract(salt, IKM)
    OKM = HKDF-Expand(PRK, "ECDH-X25519-CHALLENGE", Lenght=32)
 }

Channel Binding: Ne
Realms: No
Cryptoprimitives: current
Partner sides: 2
PQC/QRC: No, current asymmetric cryptography is insufficient.
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protected: No, creation of a shared secret
Replay protection: Yes
Relay protection: Yes
Hijack protection: No
Forge protection: Yes
MFA support: No
Integrity protection: Yes
Encryption type: Internal

ECDSA-NIST256P-CHALLENGE

The above mechanism requires the generation of a private and public key pair. The public key must be registered on the requested service in relation to the given user. In this case, the private key possession is verified based on the result of the signature prompt provided by the server.

Client → Server: Base64(username)
Server → Client: C
Client: Signature=ECDSA_Signature(x,C)
Client → Server: Signature

Channel Binding: No
Realms: No
Cryptoprimitives: current
Partner sides: 2
PQC/QRC: No, current asymmetric cryptography is insufficient.
ZKP: No
Crypt interface support: Ne
Tokenization: No
Uniqueness: Yes
Credentials protected: No, Creating Shared Secrets
Replay protection: Yes
Protection against Relay: Yes
Hijack protection: No
Protection against Forge: Yes
MFA support: No
Integrity protection: Yes
Encryption type: Internal

EXTERNAL

These are methods that use external authentication. Examples are SSL/TLS authentication or other methods. These methods must be specified and require checking of the corresponding architecture.

Channel Binding: N/A
Realms: N/A
Crypto-primitives: N/A
Number of pages on authentication: N/A
PQC/QRC: N/A
ZKP: N/A
Crypt interface support: N/A
Tokenization: N/A
Uniqueness: N/A
Credentials protected: N/A
Replay protection: N/A
Relay protection: N/A
Hijack protection: N/A
Forge protection: N/A
MFA support: N/A
Integrity protection: N/A
Encryption type: N/A

NMAS_AUTHEN

The original Novell Modular Authentication Services were available since 1999 together with the Novell NetWare 5 version. These mechanisms were designed for authentication against NDS (NetWare Directory Services), were security-oriented and supported by wide support for authentication methods. In parallel with the introduction of Novell NetWare 6.x and the further development of eDirectory (the original NDS), the SASL interface was supported after 2000. Currently, NMAS technology has transitioned to OpenText with intermediate steps via NetIQ and Microfocus.
NMAs support a wide range of authentication methods, from classical methods based on password authentication, to biometric authentication support and token usage. In the case of password processing, the pre-processing is based on a PBKDF2 algorithm to ensure higher protection of the data. The NMAS_AUTHEN authentication mechanism itself is designed for user authentication within eDirectory and works as follows:

Client → Server: InitMessage_Client=MechanismID||ClientData
Server → Client: Challenge_Server= AuthRequestID||Nonce_Server||AdditionalData
Client → Server: RespMessage_Client = AutheRequestID||HMAC(KeyMaterial,Nonce_Server||AdditionalData)||SessionContext

If the received value of HMAC(KeyMaterial,Nonce_Server||AdditionalData) matches the calculated value on the server side, LogonStatus=Success, otherwise Failure.

Server → Client: LogonStatus||HMAC(ServerKey,AuthRequestID||HMAC(KeyMaterial,Nonce_Server||AdditionalData)

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

NMAS_LOGIN

This method is a follow-up to user authentication (NMAS_AUTHN) and is used to log the user to resources such as network drives, printers, etc.Unlike NMAS_AUTHN, it cannot use multi-factor authentication, but it is able to use basic authentication provided by the previous method. As with NMAS_AUTHN, passwords are pre-processed using PBKDF2.

Server → Client: Challenge_Server= Method||Nonce_Server
Client → Server: RespMessage_Client = Hash(Password||Nonce_Server)

If the received value of the output corresponds to the unidirectional function on the server side, it is LogonStatus=OK, otherwise Fail.

Server → Client: LogonStatus

Channel Binding: No
Realms: No
Cryptoprimitives: Obsolete(MD5, SHA-1), current (SHA2)
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: Yes
Hijack protection: No
Protection against Forge: Yes
MFA support: No
Integrity protection: Yes
Encryption type: Internal

NMAS-SAMBA-AUTH

This is a way to enable logging on to SMB servers (Samba, Windows) for NMAS clients. Unlike common systems on the Microsoft Windows platform, a single password (OTP) is also supported here, which can be useful under certain conditions.

Server → Client: Challenge_Server=Method||Nonce_Server
At the moment it depends on the choice of method. For Kerberos and NTLM the procedure differs, more details can be found in the analysis of these specific methods.
After authentication is completed, the outputs are compared. If the received value of the output corresponds to the unidirectional function on the server side, it is LogonStatus=OK, otherwise Fail.

Server → Client: LogonStatus

Channel Binding: No
Realms: No
Cryptoprimitives: According to the chosen method, in the case of Kerberos also according to the chosen algorithm. Number of pages during authentication: 2, in case of Kerberos 5 three pages, in case of dedicated SMB server even four pages.
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: No, the exception is the use of Kerberos 5
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Protection against Relay: No, only when using the Kerberos protocol
Hijack protection: No, only when using the Kerberos protocol
Protection against Forge: Yes
MFA support: No
Integrity protection: Yes
Encryption type: Internal

NTLM

The NTLM protocol is used for authentication on networks providing services using the SMB protocol. This is an old protocol, more on this topic can be found in a separate article on the topic (Authentication to SMB shared folders). To some extent it describes the problems encountered by the NMAS-SAMBA-AUTH protocol.
The C_ServerClient> prompt is a random 8B value.

Client –> Server: Send U=Username
Server –> Client: Send C_Server

Tag_Client = (version, time, C_Client, domain name)
LMv2 = HMAC-MD5(HMAC-MD5(MD4(Pass), User Name||Domain Name), C_Server, C_Client)
NTv2 = HMAC-MD5(HMAC-MD5(MD4(Pass), User Name||Domain Name), C_Server, Tag_Client)

Client –> Server): LMv2 || C_Client || NTv2 || Tag_Client

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

OTP

The OTP (One Time Password) method consists of generating a one-time password based on the current time or counter change. Generally, the generation is done by a token (e.g. RSA SecureID), but is not a condition. Similar apps for mobile phones currently exist and can be used as an additional factor for logging in. Generally, these methods should not be used alone, the reason may be the leakage of initialization data (seed, otherwise also user secret) and their subsequent misuse.
This algorithm uses two basic methods, either HOTP (RFC 4226) or TOTP (RFC 6238). While HOTP uses the general hash(seed, counter) approach, TOTP uses the hash(seed, the time interval from January 1, 1970). Both of these methods are covered by the OATH. In both cases, it is imperative to synchronize the time of the token and the server verifying this information.

OTP = HMAC(seed, step)

HOTP = RIGHT(HMAC(Seed,Counter),6) TOTP = RIGHT(HMAC(Seed,Second since 1 Jan 1970/Time Interval,6)
Channel Binding: No
Realms: No
Cryptoprimitives: Obsolete (MD4, MD5, SHA-1), current (SHA2-256, SHA2-512)
Partner sides: 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, it serves as 2FA and should not be used otherwise
Integrity protection: No
Encryption type: No

SKEY

The SKEY or S/KEY (Secure Key) algorithm is a method for authenticating identity using a one-time password. It uses recursive compound functions and is usually used as a second factor.

SKEY=HMAC(seed, HMAC(seed, HMAC(seed, ...))

Channel Binding: No
Realms: No
Cryptoprimitives: Obsolete (MD5, SHA-1), current (SHA2-256)
Partner sides: 2
PQC/QRC: No
ZKP: Ne
Crypt interface support: Ne
Tokenization: Ne
Uniqueness: Yes
Credentials protected: No
Replay protection: Yes
Relay protection: No
Hijack protection: No
Forge protection: Yes
MFA support: No, it serves as 2FA and should not be used otherwise
Integrity protection: No
Encryption type: No

SECUREID

This is the original RSA SecureID technology. Originally, these were physical tokens, and over time, software versions were also available. The token or its emulation software based on a secret key (seed) generated a new, usually six-digit password every 30s using simple or compound hash functions.
Over time, several vulnerabilities were found that were caused by synchronization problems, leaks of seeds (generating information) and MITM vulnerabilities. The general working principle is similar to other OTPs:

OTP=Hash(Seed,Counter)

Channel Binding: No
Realms: No
Crypto-primitives: Obsolete (MD5, SHA-1), current (SHA2-256)
Number of pages on authentication: 2
PQC/QRC: No
ZKP: No
Interface support: No
Tokenization: No
Uniqueness: Yes
Replay protection: Yes
Protection against Relay: No
Hijack protection: No
Protection against Forge: Yes
MFA support: No, it serves as 2FA and should not be used otherwise
Integrity protection: No
Encryption type: No

SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA2-256, SCRAM-SHA2-256-PLUS

The SCRAM algorithm is designed to provide a secure alternative for password exchange versus pure compound hash functions. In this case
client and server share client password, for hash functions they can use both SHA-1 and SHA2-256, SHA2-384 or SHA2-512. It exists in SCRAM and SCRAM-PLUS versions, where the latter supports Channel Binding technology. This is applied e.g. with GS2 or TLS, where it allows linking authentication with an external method or protocol. In the case of TLS, the corresponding authentication string is encoded using Base64 and the method is added to the authentication message. Possible options for choosing the authentication method are:
tls-server-end-point: uses a certificate hash for authentication (fingerprint, usually based on SHA2-256).
tls-unique: Uses TLS identifier based on messages confirming agreement on keys.
tls-exporter: Based on export mechanism of TLS keys according to RFC 5705.

Key1 = Hash(HMAC_algorithm(PBKDF2_algorithm(Password, salt, iterations),Password)
Key2 = HMAC_algorithm(PBKDF2_algorithm(Password, salt, iterations)
Client → Server: Signature=HMAC_algorithm(Key1,AuthMessage)
Client → Server: Proof=Key2 ⊕ Signature

Verification on server against received message:
Verify=HMAC(HMAC(PBKDF2(Hash,Password, salt, iterations),Auth Message)

Channel Binding: Not for the basic version, yes for the PLUS version
Realms: No
Cryptoprimitives: Obsolete (SHA-1), current (SHA2)
Partner sides: 2
PQC/QRC: For SHA2-384 and SHA2-512
ZKP: No
Crypt interface support:
Tokenization: No
Uniqueness: Yes
Credentials protected: Password
Replay protection: Yes
Relay protection: No, yes for PLUS version
Hijack protection: No, yes for PLUS version
Forge protection: Yes
MFA support: No
Integrity protection: N/A
Encryption type: Internal

SXOVER-PLUS

The XOVER algorithm has been in the original designs for SASL since early versions. Although it was also described in the SASLv1 standard to ensure the ability to interact between systems (DIAMETER, EAP, Kerberos, ...), there is no further mention of it. The exception is information about low security, due to the lack of cryptographic support. The algorithm relied on protection on the transport layer and was equivalent to the PLAIN algorithm. The author was probably J. G. Myers, which is also behind the original standard. SXOVER evolved from this algorithm and its extended version with Channel Binding support SXOVER-PLUS was subsequently adopted into the SASLv2 standard.
The current SXOVER-PLUS algorithm is still not standardized, therefore all the information provided describes how it should work. Based on the available information, it should use asymmetric cryptography.
Key exchange using asymmetric cryptography (RSA, DH, ECDH) allows to create a shared symmetric Key.
Server → Client: Message_Server = ("r=" || C_Server ||",cb="|| hash(Channel) |",sk="|| PublicKey_Server ||",sid="|| ServerID )
Client → Server: Message_Client = ("c="||hash(Channel) |",r="|| C_Client ||",ck="|| PublicKey_Client ||",sig="|| Signature_Client )

Where in the exchange of the above information stands ECDH (Diffie Hellman agreement over elliptic curves NIST P-256 or Curve25519). The following functions are used for generating individual data:
KeyMaterial = HMAC(SharedKey, "SXOVER Key Derivation")
KeyENC = KDF(KeyMaterial, "enc")
KeyMAC = KDF(KeyMaterial, "mac")
Signature_Client = DSA(PrivateKey_Client, ServerID || PublicKey_Client || PublicKey_Server )
Normal equations are used for the actual calculation of the key pair:

PublicKey_Server=g^{PrivateKey_Server} mod p
PublicKey_Client=g^{PrivateKey_Client} mod p
which subsequently allows an agreement over a shared secret:
SharedKey_Server=PublicKey_Client^{PrivateKey_Server} mod p
SharedKey_Client=PublicKey_Server^{PrivateKey_Client} mod p

Channel Binding: Yes
Realms: Yes
Cryptoprimitives: Current
Partner sides: 2 or more
PQC/QRC: No
ZKP: No
Crypt interface support: Ne
Tokenization: Possible, by default not
Uniqueness: Yes
Credentials protected: Yes
Replay protection: Yes
Protection against Relay: Yes
Hijack protection: Yes
Protection against Forge: Yes
MFA support: Not by default, but possible by configuration
Integrity protection: Yes
Encryption type: Internal

Conclusion

This effectively concludes the overview of mechanisms used for authentication between client and server, i.e. for two parties (although some mechanisms support multiple parties). It can be seen that, despite all the developments, some mechanisms today deserve to be further developed or replaced. Their implementation can currently bring serious impacts, so it is necessary to consider their advantages and disadvantages when choosing authentication mechanisms. Further parts will be devoted to mechanisms based on Kerberos protocols, OAUTH protocols and related protocols. The last part will then compare individual libraries, supported algorithms and other interesting software products, usable in authentication.

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.