Kerberos part 5 - the principle of Kerberos authentication

This article does not address (an important area) types of encryption. There is a new article on this topic Kerberos deactivation RC4 part 1 - protocol principle and encryption types.

Although the basic principle of authentication is the same, in different situations (e.g., cross-realm Kerberos authentication), parts are added to the overall picture. We will gradually describe many of them later.

Very Simple Description

The description can be divided into three steps. The assumption is that we have logged into Windows at the beginning, where we entered a username and password (or used a certificate and PIN). We then want to access a network service that supports Kerberos and provides us with this information along with the authentication request.

• Obtaining TGT - we check if we have a TGT, if not, we contact the KDC AS service and obtain a TGT, which is stored in the cache (usually obtained only at the beginning when logging into the computer)
• Obtaining Service Ticket - we contact the KDC TGS service and request a Service Ticket for the service we want to log into, authenticating using the TGT
• Authentication with the service - we send the Service Ticket to the application server, which reliably retrieves our username from it

A Little More Detail

• User Authentication - obtaining TGT
  • when logging into the computer, the user enters their credentials on the workstation [1]
  • the workstation creates the user's Secret Key
  • the DC for authentication is found and communicates with the KDC AS (which has access to the AD user database)
  • using encryption with the Secret Key, a Ticket-Granting Ticket (TGT) is obtained [2]
• Obtaining Service Ticket - when the client wants to access a network service (e.g., an application on a web server) that supports Kerberos and requires authentication, the SSO principle is used
  • the client contacts their DC at the KDC TGS service
  • requests a Service Ticket, the request includes (among other things) the type of service (e.g., HTTP, KRBTGT, LDAP, CIFS) and the server address (e.g., www.firma.local), which together form the Service Principal Name (SPN), a unique identifier for the service running on the server
  • if the TGS finds the SPN in Active Directory (and other authentication conditions are met), it sends a Service Ticket in response (encrypted with the service's Secret Key) [3]
• Authentication with the service - verifying the client on the network service (server)
  • using the protocol with which the application server communicates, the client sends data to the server, including the Service Ticket
  • the server decrypts the ticket with its key and retrieves the user information (their name)
  • in the authentication process itself, the server does not communicate with the KDC (i.e., DC), but only with the client
  • if mutual authentication is enabled, the server sends the client an encrypted timestamp, and the server is also verified by the client [4]

Detailed Description

We consider a common situation in a domain environment where Pre-authentication and Mutual Authentication are required.

• User authentication and obtaining Ticket-Granting Ticket
  • when logging into the computer, the user enters their credentials (we will consider username and password) [1]
  • the client adds the username with domain to the password and performs a one-way hash function, resulting in a Secret Key
  • the client composes a KRB-AS-REQ request and sends it to the Authentication Server (AS), which is part of the Key Distribution Center (KDC). The request includes the KDC_REQ_BODY section, containing the username and Realm (domain), SPN of the service (krbtgt), client address, supported ciphers, all in plain text (never includes password or Secret Key) [2]
  • the AS requires pre-authentication, which was not in the request, so it responds with an error message KRB-ERROR with the code KRB5KDC_ERR_PREAUTH_REQUIRED (25) [3]
  • the client composes a new KRB-AS-REQ request, which additionally includes a timestamp encrypted with the client's Secret Key in the padata section [4]
  • the AS finds the user in AD and creates their Secret Key, decrypts the timestamp with it (thus verifying the user), checks its validity (whether it is not shifted by more than 5 minutes against the server time and whether the same or newer timestamp has not already been received from the client)
  • If everything was in order, the AS generates a Session Key (for encrypting further communication with the client) and a Ticket-Granting Ticket (TGT) for the client, prepares a response for the client KRB-AS-REP, which includes the username, the Session Key encrypted with the Client's Secret Key (part enc-part), and the Ticket-Granting Ticket (TGT) encrypted with its own key (KDC Secret Key) [5]
  • The client decrypts the Session Key (confirming their identity) and stores it for further communication with the KDC. The client cannot decrypt the TGT, so it cannot be modified
  • The TGT has a limited lifespan (default 10 hours), but automatic reauthentication can occur, and a new TGT is created with each login
  • The TGT is used for further communication with the KDC, so the Secret Key (and thus the password) does not need to be used. It contains the client's name, address, validity period, and Session Key
  • With each request to the KDC, the client sends the TGT, which can only be decrypted by the KDC, so it trusts the information contained within. It also includes the Session Key, so the KDC does not need to maintain any information in memory (resulting in high scalability)
• Obtaining Service Ticket
  • When the client wants to log into a network service (e.g., a web page or file sharing) using the Kerberos protocol (and thus SSO), they compose a KRB-TGS-REQ request and send it to the Ticket Granting Service (TGS), another part of the KDC [6]
  • The request includes the KDC_REQ_BODY section, which contains request details, mainly the service name and Realm (together forming the SPN), supported ciphers, requested ticket validity period, and a randomly generated number
  • The second part, padata, contains authentication data, mainly our TGT ticket (still encrypted with the KDC key) and the Authenticator (encrypted with the Session Key, containing client identification and timestamp). These form the user's temporary credentials
  • The TGS takes the TGT from the request and decrypts it with its key, retrieves the Session Key from it, and uses it to decrypt the Authenticator and verify its data
  • If the request data is valid, the TGS prepares a KRB-TGS-REP response and sends it to the client [7]
  • The response includes the username, the Service Ticket for the requested service, which contains its SPN and, in the part encrypted with the Service's Secret Key, the username and Session Key for communication between the client and the service. In the enc-part section, the Session Key for communication with the service (client-service) is encrypted with the Session Key from the TGT (client-KDC). The key from the Authenticator could also be used for encryption (if the client included it)
  • The client receives the encrypted Service Ticket and decrypts the Session Key for communication with the service, storing both in the cache
• Verification with the service (server)
  • The client now has all the necessary data to authenticate to the server using Kerberos. When they started communicating with the service, they learned through its protocol (e.g., HTTP) that it requires authentication and supports Kerberos
  • The client now prepares a response within the same protocol (e.g., HTTP), wrapping another negotiation protocol (e.g., SPNEGO GSS-API) and including the Kerberos message KRB-AP-REQ, which is sent to the server [8]
  • The authentication request mainly includes the Service Ticket for the service and the Authenticator (encrypted with the Session Key for communication with the service, containing client information, checksum, and timestamp)
  • The server decrypts the Service Ticket, retrieves the Session Key from it, and decrypts the Authenticator, verifying the received data
  • If everything is in order (and mutual authentication is required), the server prepares a KRB-AP-REP response, which is sent back to the client, again wrapped in application protocols [9]
  • The response is encrypted with the Session Key (client-service) and includes the timestamp sent by the client as part of the Authenticator
• Establishing a session
  • The client decrypts the confirmation and compares the timestamp. If everything is in order, mutual authentication has been successfully achieved

Note: For an even more detailed description, I recommend studying the RFC 4120 specification.

Additional Information

We have described the authentication process in detail above, but there may still be many questions about certain practical details that this procedure does not answer. Most things can be inferred from the general information provided earlier. However, we will show a practical case here to describe certain details.

We will consider a client connection using a web browser to an application on a web server, where Single Sign-On login using Kerberos occurs. The use of a web application (http protocol) is only to speak specifically; generally, the situation is similar for most other protocols.

To make the situation more complex and to describe special situations, we will consider the following scenario. The web server is Apache on Linux and physically runs in a different network than the user workstations (it cannot communicate with the DC). The address is www.firma.cz and it is network accessible to the client. Within the local domain firma.local, we created an account, registered the SPN HTTP/www.firma.cz@FIRMA.LOCAL (this can contain any address - from any domain, after the @ is our domain where we will register the record) and created a keytab file, which we uploaded and set on Apache.

The user Petr Bouška has an account in the domain with UPN petr.bouska@jina-firma.local and sAMAccountName firma\\bouska. He is logged into a workstation that is part of the domain and correctly authenticated using Kerberos.

• open the page www.firma.cz
• receive a response that the page requires authentication and supports Negotiate, so the client chooses Kerberos
• the client needs to obtain a Service Ticket, it does not matter that the server address is in a different domain than the client, it simply contacts its KDC (which it found during login according to the procedure we described earlier)
• prepares a KRB-TGS-REQ request, where it inserts authentication data and request data, i.e., the Realm (KDC server domain) FIRMA.LOCAL and the Server Name (service Principal Name) HTTP/www.firma.cz
• the domain controller searches within its domain for the SPN HTTP/www.firma.cz, finds the account that has it assigned (the SPN could also be within another trusted domain, which we will describe later)
• the DC has all the information to create a Service Ticket (it inserts the user's name into it) and sends it to the client
• the client sends the Service Ticket (as part of the HTTP header) to the web server, which uses the keytab file to decrypt the sent data
• the server retrieves the username, which is Client Name: bouska and Client Realm: FIRMA.LOCAL

From the above, several conclusions can be drawn that are important for the practical deployment of Kerberos SSO.

• the server does not need to communicate with the DC, it is sufficient to have a keytab file
• the client must communicate with the DC during authentication (this is not entirely true, it must communicate the first time, then it stores tickets and keys in the cache for a certain period and can reuse them)
• the DNS name of the service can be from a different domain than the client, and either the SPN is registered in the client's domain, or Cross Realm authentication can be applied (verification within another trusted domain)
• the username is always taken as sAMAccountName and the DNS domain name, it can be written in the form bouska@FIRMA.LOCAL