SASL Analysis, part three

After previous episodes, mainly focused on client-to-server authentication, the aim of this episode is to focus on individual technologies used to choose the authentication method and on methods providing authentication to a third party. For each protocol, its properties and structure of protection mechanisms will be mentioned again. The aim is to provide material on which to base the analysis of the technologies used. To return to the previous episode, you can use the link SASL Analysis, Part Two.

Introductory terminology for GS2-*, GSSAPI, GSS-SPNEGO, SPNEGO, NEGOEXT

As mentioned in the first episode, these protocols provide selections or calls for other mechanisms through internal mechanisms. To illuminate how exactly they work, it is necessary to explain the history of the development of the SASL mechanism and the development of user authentication in operating systems.
GSSAPI: The success and security of the Kerberos protocol triggered the need for a universal interface. Because the implementations sometimes differed significantly from one another, it was created to standardize the GSSAPI interface, but it was not standardized until 1993 (RFC 1508). Thus, the GSSAPI interface serves primarily for the Kerberos protocol, although over time the ability to call other authentication mechanisms has been added. Its equivalent in the Microsoft operating system environment is the SSPI interface, which is not fully compatible with GSSAPI. If a call from the SSPI environment against GSSAPI is combined, it is necessary to explicitly specify the missing information within the communication, otherwise the authentication may not happen at all. This is a kind of gray area, which falls on differences in implementation. GSSAPI was already incorporated in the basic SASL standard, today unofficially called SASL1. It is therefore an interface that for historical reasons can be offered as a method, leading to chaos and confusion.
SPNEGO: In the Microsoft operating system environment, a request was made for the possibility of using the Kerberos or NTLM mechanism based on system capabilities and requirements. This request led to the SPNEGO interface, which allowed the user to request the use of the available service when authenticating. This service was selected by the server based on the information provided by the client and the available methods on its side. This mechanism allows calling methods such as the Kerberos Network Authentication Service (RFC 4120, for both SASL and Microsoft Windows), User to User Kerberos Authentication (Microsoft Windows only), the Extended GSSAPI Negotiating mechanism NEGOEXT (OID 1.3.6.1.4.1.311.2.2.30, Microsoft Windows only), the NT LanMager authentication protocol, known as NTLM (for both SASL and Microsoft Windows) and DIGEST-MD5 (SASL only). Standardization took place in 1998 (RFC 2478), support for this mechanism also appeared in later versions of SASL. For this reason, there was also further confusion in the naming and calling capabilities of these methods.
GSS-SPNEGO: Generic SPNEGO interface available through GSS-API.
GS2: The GS2 interface, more specifically GS2-[method] came into existence a few years later, as part of the SASL mechanism. The primary purpose was a standardized method for accessing GSSAPI, which was subsequently expanded to include the ability to call other supported methods integrated in SASL. More specifically, it was a version with the unofficial name SASL2, which had a significantly changed architecture to make it more extensible. Despite support for other mechanisms, the main supported method in GS2 remains Kerberos (GS2-KRB5). Thus, in the case of GS2, it is a method designed to use GSSAPI to call specific authentication mechanisms.
NEGOEXT: It is one of Microsoft's proprietary mechanisms within the GSSAPI interface. The mechanism is based on SPNEGO, but is not standardized. It also extends the ability to call authentication procedures outside of regular NTLM and Kerberos5 to include mechanisms such as OAUTH, OpenID, and others designed for federated identities. Examples include authentication against cloud systems such as Azure. NEGOEXT can be identified by (OID 1.3.6.1.4.1.311.2.2.30). NEGOEXT is thus an extension of SPNEGO mechanisms.
GSS-SPNEGO: The general SPNEGO interface available through the GSS-API.
GS2: The GS2 interface, more specifically the GS2-[method] was created a few years later, as part of the SASL mechanism. The primary purpose was a standardized method for accessing GSSAPI, which was subsequently expanded to include the ability to call other supported methods integrated in SASL. More specifically, it was a version with the unofficial name of SASL2, which had a significantly changed architecture to make it more extensible. Despite the support for other mechanisms, the main supported Kerberos method (GS2-KRB5) remains in GS2. Thus, in the case of GS2, it is a method designed to use GSSAPI to call specific authentication mechanisms.
NEGOEXT: It is one of Microsoft's proprietary mechanisms within the GSSAPI interface. The mechanism is based on SPNEGO, but is not standardized. It also extends the ability to call authentication procedures outside of normal NTLM and Kerberos5 to include mechanisms such as OAUTH, OpenID, and others, designed for federated identities. Examples include authentication against cloud systems such as Azure. NEGOEXT can be identified by (OID 1.3.6.1.4.1.311.2.2.30). NEGOEXT is therefore an extension of SPNEGO mechanisms.

SPNEGO and SPNEGO-PLUS

In this particular case, it is debatable whether to rate the algorithm as an authentication algorithm or a mechanism allowing a choice between Kerberos Network Authentication Service (RFC 4120), User to User Kerberos Authentication (Microsoft Windows only), Extended GSSAPI Negotiating mechanism NEGOEXT (OID 1.3.6.1.4.1.311.2.2.30), NT LanMager authentication protocol, known as NTLM and DIGEST-MD5 (SASL only). GSSAPI is usually used for the call, in the case of Microsoft Windows, it is possible to use the SSPI interface (API for SPNEGO and other mechanisms, differences and relationships already mentioned in the first part) with reservations.
During the authentication process, the client sends a list of supported mechanisms to the server and the server chooses the login method. All exchanges of information take place through the SPNEGO mechanism until the selection is finished, then communication continues directly with the selected authentication mechanism. For the extended SPNEGO-PLUS method, the rule is again that the algorithm is cryptoprimitively bound to a specific communication channel (that is, SPNEGO-PLUS requires information about the communication channel and provides a link of the communication channel to the given login). Of interest is the SSPI property, which is not fully compatible with GSSAPI and in this case it is necessary to inform the mechanisms accordingly in order to complete the authentication at all. Only the SPNEGO method can be used through this interface, not the SPNEGO-PLUS method. Furthermore, although SPNEGO supports SSO (Single-Sing On) technology, it is necessary to avoid NTLM or DIGEST-MD5 authentication and to support only secure methods (Kerberos). The above login method is intended mainly for systems using the SMB (Samba) protocol and for web server access authentication, it corresponds to the specification within RFC 4178.

Channel Binding: Only for the PLUS version.
Realms: Yes
Crypto-primitives: Obsolete (NTLM and Kerberos), current (Kerberos)
Number of pages on authentication: 2 for NTLM, 3 for Kerberos
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: N
Uniqueness: N/A
Credentials protection: 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

GS2-*, GSSAPI, GSS-*

The GSSAPI interface allows access to a large number of different authentication mechanisms, GS2 being a mechanism capable of calling those APIs within SASL. GSS-* mechanisms are then custom mechanisms that can be called directly via API.

Channel Binding: For the PLUS version only.
Realms: Yes
Crypto-primitives: Obsolete (NTLM and Kerberos), current (Kerberos)
Number of pages in authentication: 2 for NTLM, 3 for Kerberos
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Maybe
Uniqueness: N/A
Credentials protection: 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

GS2-KRB5, GS2-KRB5-PLUS

This is a GS2-group method (GSS SASL), provided through GSS-APIs. More about GS2-KRB5 in KERBEROS_V5, GS2-KRB5-PLUS method contains an extra link to the channel that transmits information. An example is SSL/TLS. More about this method again in the KERBEROS_V5 section.

KERBEROS_V4

In 1983, the Athena project was created at MIT (Massachusetts Institute of Technology) in collaboration with DEC and IBM. Its goal was to create a tool for networks at this university. Kerberos was an authentication tool and was one of the tools within this project. Due to the nature of the protocol, which allowed users to authenticate themselves using central systems, it was necessary to approach this process differently than with normal systems, thus protecting user secrets from eavesdropping and misuse. The first version of the Kerberos protocol dates back to before the Athena project, neither the first nor the second version was ever publicly available. The third version was created in 1988, and only the fourth version gained attention. Since then, the flow of communication messages has not changed, so the data flows are the same for both Kerberos v4 and Kerberos v5. The main authors were Steve Miller and Clifford Neumann, but other collaborators from that project worked with them on the protocol.
Kerberos v4 uses a fixed message structure, the service ticket is 256B in size and therefore cannot be expanded at will. Of course, this structure significantly reduces usability, it is not possible to transport user-related expanded data with the above protocol. Similarly, it used a single time zone and was not able to work between time zones, only the DES algorithm was used for encryption. In addition, the first versions of the Kerberos protocol were burdened with export restrictions, i.e. DES with a 40b key was used. For this reason, there were two other implementations created outside the U.S. that did not have these restrictions.
The description of the protocol is in the next paragraph for Kerberos v5. For encryption, the DES algorithm was generally used in CBC mode, which could not be changed. For some information, encryption using DES-ECB, or DES-PCBC, was used, for checking cryptograms, a simple cryptographic checksum based on DES-CBC was used. All messages were provided with a checksum using CRC-32.

Channel Binding: No
Realms: Yes
Crypto-primitives: Obsolete (DES)
Number of pages on authentication: 3 for Kerberos
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: Yes
Uniqueness: N/A
Credentials protection: Yes
Replay protection: Yes
Relay protection: N/A
Hijack protection: N/A
Forge protection: N/A
MFA support: N/A
Integrity protection: N/A
Encryption type: Internal

KERBEROS_V5

In 1993, the development of the Kerberos project continued with another version. The protocol was reworked, the dynamic structure started to be used. The new version started to support time zones, which solved the original logging problems. Furthermore, the previous version had a precisely defined protocol structure, but the new version started to use a dynamic structure for the data based on the ASN.1 structure and the DER format. These abbreviations can also be found on certificates. ASN.1 is a symbolic language describing the data structure, DER is an encoding format ensuring the unambiguously shortest possible length of the data. This is advantageous in case of any digital signature, because the data is unambiguously arranged. In addition, the actual structure thanks to the ASN.1 structure allows the transfer of data that was not part of the design. An example is the authorization information in the Microsoft Active Directory, where the service ticket contains a list of affiliations to PACs (Priviledge Attribute Certificate). This of course also has its limitations, for the Kerberos protocol they are rather technical. In the Microsoft Windows network environment, the limitations are tied to the maximum size of the PAC record, which for each version is as follows:
- Windows 2000 and others - 8KB
- Windows 2003 and others - 12KB
- Windows 2008 and others - 48KB
- Windows 2012 and others - 64KB, the value can be changed by configuration
More about the Kerberos protocol and especially about implementation in Microsoft Windows can be found in the Authentication to shared folders using the SMB

Breakdown of exchanged messages:

• S1: AS REQUEST, part of the client's query for AS.
         IDClient||TimestampClient||NonceClient
• R2: AS REPLY, part of AS response.
         KKTS=Enc(KClient,KKTS)
• R3: AS REPLY, part of AS response.
         TGT=Enc(KTGS,IDClient||KClient||Lifetime||..)
• S4: TGS REQUEST, part of message for TGS.
         Enc(KTGS, TGT) - copy of encrypted TGT ticket from previous step
• S5: TGS REQUEST, part of message for TGS.
         Enc(KTS, IDClient||Timestamp||..)||IDServer||NonceClient
• R6: TGS REPLY, part of the message on TGS.
         Enc(KAP, KSS)
• R7: TGS REPLY, part of the message on TGS.
         Enc(KTS, IDClient||KSS||Lifetime||..)
• S8: AP REQUEST, part of the message to the application server.
         Enc(KAP, KSS) - copy of Session key from previous step
• S9: AP REQUEST, part of the message to the application server.
         Enc(KSS, IDClient||Timestamp)
• R10: AP REPLY, part of the application server response. This response occurs only in the case of mutual authentication
         Enc(KSS, TimestapmServer)
• S10: PAC VALIDATION REQUEST, part of optional client authentication by application server on TGS. It is generally not used.
         Enc(KAP, PAC Signature||PAC Info||TGT||Timestamp)
• R11: PAC VALIDATION RESPONSE, part of optional client authentication by application server on TGS. It is generally not used.
         Enc(KAP, Validated PAC Signature||Validated PAC Attributes||Timestamp)

Channel Binding: No
Realms: Yes
Crypto-primitives: Obsolete (DES)
Number of pages on authentication: 3 for Kerberos
PQC/QRC: No
ZKP: No
Crypt interface support: No
Tokenization: Yes
Uniqueness: N/A
Credentials protection: Yes
Replay protection: Yes
Relay protection: N/A
Hijack protection: N/A
Forge protection: N/A
MFA support: N/A
Integrity protection: N/A
Encryption type: Internal

OAUTH10A

The original OAUTH protocol was created as a combination of existing protocols and practices for authorization delegation. This is not an authentication, but authorization protocol. A working group was established within the IETF in 2007 to standardize this protocol, and the first standard was published in 2007. Based on a session fixation published in 2009, a revision was created, referred to as OAUTH10A. This protocol supports permission delegation, but only within one provider identity. It does not support token sharing and centralized multi-domain administration.
This is a mechanism that allows client authentication and delegation of permissions (e.g. to a third-party application) with minimal cryptography. The actual protocol uses either a digital signature based on RSA or only HMAC for checksum creation, this form of "signature" must be included in all API calls. No other form of cryptographic protection is used. The following components are part of the communication:
- user, i.e. data owner
- authentication server for login, in this case also authorization server for authorization delegation
- application or application server, requesting authorization. In this version it is considered owner of resources

S1: Before any requests, the client must login to the authentication server. In this case, the authentication and authorization server is identical, after login it provides authorization data allowing authorization delegation. The actual login method is not specified in the OAUTH10A protocol, most often the login data is protected only by transport encryption (HTTPS, i.e. HTTP with SSL/TLS support). When logging in for registration, the consumer key, which is public and serves for further identification for the duration of the connection, is used. When logging on again, the consumer key is only used.
At the beginning of the connection, the client asks for a temporary request token using a query where it uses the HTTPS protocol. This is chosen to protect against eavesdropping. As the transferred account information is not otherwise protected, it is advisable to use any algorithm other than PLAIN or LOGIN to connect to the authentication server. The content of the HTTP request looks something like this, all other exchanges of information use similar records:
- oauth_consumer_key="consumer key",
- oauth_signature_method="PLAINTEXT|HMAC-SHA1|RSASSA-PKCS1-v1_5",
- oauth_signature="signature based on oauth_signature_method algorithm",
- oauth_timestamp="timestamp",
- oauth_nonce="nonce",
- oauth_callback="https address to receive token"
Where:
- Signature=HMAC-SHA1(Consumer||Token||&,HTTPREQ)
- HTTPREQ contains HTTP parameters, method and URI for connection.

R2: The server returns a temporary token or a temporary login and authorization address (URI).
S3: The client forwards the information to the application or application server for authorization (URI).
S4: The application server uses the authorization address (URI) to login using a temporary token.
R5: The server authorises or denies the application or application server authorization. In case of authorization, it sends a verification key and redirects the server to a specific address (callback URI).
R6: The application server passes a verification key and a new address (callback URI).
S7: The client sends a verification key, a temporary token and a temporary server login. Requests a token for the application server in exchange.
R8: The client receives a token for the application server.
S9: The client forwards the token to the application server.

Channel Binding: Yes
Realms: No
Cryptoprimitives: Obsolete (SHA-1) or rundown (RSA)
Number of pages when authenticating: 3
PQC/QRC: No
ZKP: No
Crypt interface support: Maybe
Tokenization: Yes
Uniqueness: N/A
Credentials Protection: Subject
Replay protection: Yes
Protection against Relay: N/A
Hijack protection: N/A
Protection against Forge: N/A
MFA support: Yes
Integrity protection: Yes (HMAC-SHA1)
Encryption type: TLS (required)

XOAUTH

The XOAUTH protocol was developed as an implementation of the authorization protocol OAUTH by Google (OAUTH → XOAUTH) to support applications and services such as GMail, where the user's username and password need to be passed to authenticate the user. This specific implementation is intended only to secure logins to mail servers (protocols SMTP, IMAP4, POP3). Except for minor details, it is identical to OAUTH10A.

Channel Binding: Yes
Realms: No
Crypto-primitives: Obsolete (SHA-1) or rundown (RSA)
Number of pages on authentication: 3
PQC/QRC: No
ZKP: No
Crypt interface support: Maybe
Tokenization: Yes
Uniqueness: N/A
Credentials protection: Reservation
Replay protection: Yes
Relay protection: N/A
Hijack protection: N/A
Forge protection: N/A
MFA support: Yes
Integrity protection: Yes (HMAC-SHA1)
Encryption type: TLS (required)

Conclusion

This overview describes the basic structure of protocols used to authenticate users using basic interfaces and protocols. Only OAUTH2, XOAUTH2, OAUTHBEARER, OPENID20 and SAML remain from the whole list. These protocols will be discussed in the next episode SASL part fourth. The last episode will then cover implementations in individual libraries and algorithms that can be considered safe from the current perspective.

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.