Kerberos part 4 - key terms of the Kerberos protocol -> SAMURAJ-cz.com

Cryptography (kryptografie - šifrování)

The Kerberos protocol is based on encryption, so we will briefly mention the main terms at the beginning. Cryptography is used to achieve various goals. These include Confidentiality (protection against data reading), Data integrity (protection against data alteration), Authentication (verification that the data comes from the given party), and Non-repudiation (non-repudiation).

Encryption - transformation of data (plaintext) for the purpose of securing it (ciphertext), so that only those who know the key can decrypt it. There is encryption with a symmetric key, where the same key is used for encryption and decryption, and encryption with a public key, where the encryption key is publicly known, so anyone can encrypt the data, but only the owner of the private key can decrypt it. Examples of ciphers include SSL, PGP, AES, DES, 3DES
Hashing - a function that creates a shorter fixed-length output (hash) from input data of varying lengths. The same input always has the same hash, different inputs have different outputs, the input data cannot be obtained from the output, and if the input changes, the hash changes significantly (used to ensure data integrity by creating a checksum for the data). Examples of hash functions include MD5, SHA, SHA2
Encoding - transformation of data into another format (to make it easier to process). The process is publicly known and can be reversed

Key Distribution Center (KDC)

The KDC is a server that authenticates the client and issues tickets. It is a centralized trusted third party in Kerberos communication. In MS, it is part of every domain controller (DC) and contains two independent services (both located on the DC):

Authentication Service (AS) - authenticates the user and sends them a TGT
Ticket-Granting Service (TGS) - based on the TGT, it verifies the user and sends a Service Ticket for the requested service

The KDC accesses Active Directory account information, including passwords. The user's password is only used to obtain the TGT, and even at this stage, it is not sent over the network; the TGT is used instead.

Secret Key

The secret key is used to authenticate the user by encrypting/decrypting communication. It is shared between the Principal (client or service) and the KDC. Several terms are used, the most common being Secret Key, another is Shared Secret Key, or generally Encryption Key. The Secret Key is derived from a text password to which salt (Salt) is added, which is the Principal Name including the Realm (this ensures that even users with the same password do not have the same key). This string is processed by the string-to-key function (string2Key), which performs a one-way hash function (the password cannot be retrieved), resulting in a key.

The principle of authentication is that the secret is known only to the two parties (user and KDC). Each party can verify the other by knowing the same secret. To verify that the other party knows the secret, Kerberos uses Secret Key Cryptography. One party encrypts a message with the key, and if the other can decrypt it, they must know the key (secret). Symmetric encryption is used (the same key can encrypt and decrypt data).

The term Secret Key is most commonly used for the user's key, but several encryption keys are used:

Long-Term Symmetric Keys

These are created from a password. The text password is transformed into a key using an encryption function (e.g., DES-CBC-MD5). These include:

User key - for the user's account, the password is entered in AD and on the workstation during login
System key - for the computer's account, when the computer is joined to the domain, it receives a password, from which a key is created
Service key - services obtain the key from the password of the account they use for login
Inter-realm keys - for authentication between domains (cross-realm authentication), where a trust relationship is established

Long-Term Asymmetric Keys

MS uses these only in the case of a public key for authentication with a smart card certificate.

Short-Term Symmetric Keys

Session Key for encrypting communication between the KDC and the client or the service and the client. The KDC does not store it because the client always sends it in an encrypted ticket.

Ticket

The ticket represents Kerberos credentials. It is a record (stored in memory or in a file on disk) that can be used to verify identity. Tickets are the basis of authentication in Kerberos, where passwords are not sent over the network, only encrypted tickets. It contains the client's identity, Session Key, timestamp, and other information. It is encrypted with the server's Secret Key.

Kerberos messages (packets) are used to request and deliver tickets. The request sends the desired (supported) encryption method and requested properties (flags). On the client, tickets are stored in volatile memory space (not on disk), so they can be reused. They have a certain validity period. We use two types of tickets:

Ticket-Granting Ticket (TGT)

TGT is a special Service Ticket for the KDC service (krbtgt). It ensures the secure transfer of the user's credentials from the AS to the TGS. We can say that it serves to authenticate the user. It is encrypted with the KDC Secret Key (the client cannot decrypt it). It contains client information, flags, timestamp, and possibly other data, and a Session Key (when using the TGT, the KDC does not need to look for the client's Secret Key but decrypts the Session Key and uses it). The default validity is 10 hours, but renewal can be performed without the need to enter a password. Microsoft has extended the standard ticket with authorization data, so it also includes the user's SID and security group SIDs to which the user belongs.

Service Ticket

It ensures that the user's credentials are securely transferred from the TGS to the service. It serves to authenticate the user to the service. It contains the service's SPN unencrypted and, encrypted with the service's Secret Key (so the client cannot decrypt it), client information (which may include an address), validity period, and a Session Key for communication between the client and the service. Microsoft has extended the standard ticket (like the TGT) with authorization data, so it also includes the user's SID and security group SIDs to which the user belongs.

Below is an example of a Service Ticket as it can be displayed on the client.

C:\\>klist
Current LogonId is 0:0x4c2b5
Cached Tickets: (10)

#2>  Client: bouska @ FIRMA.LOCAL
     Server: HTTP/www.firma.local @ FIRMA.LOCAL
     KrbTicket Encryption Type: RSADSI RC4-HMAC(NT)
     Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
     Start Time: 4/25/2014 12:53:44 (local)
     End Time:   4/25/2014 22:18:52 (local)
     Renew Time: 5/2/2014 12:18:52 (local)
     Session Key Type: RSADSI RC4-HMAC(NT)
     Cache Flags: 0
     Kdc Called: dc.firma.local

Authenticator

Along with the ticket, the client sends a freshly generated Authenticator encrypted with the Session Key (which is contained in the ticket). The service can trust that the ticket is not forged because it is encrypted with its key (known only to the KDC and the service). However, it does not have a verified sender (since the ticket itself could be stolen), so an Authenticator is used.

The Authenticator is encrypted with the key (Session Key) known only to the correct client and server. It contains a timestamp that is checked to ensure it is not equal to or less than the last received timestamp from the client (this ensures that the authenticator cannot be reused). The timestamp is also checked against the server's time and must not differ by more than 5 minutes (the client and server must have synchronized time). It also contains the client's name and Realm, a checksum of the application data, and may include an encryption key (which would be used instead of the Session Key).

Pre-authentication

The use of pre-authentication increases the security of the login process. Normally, the client requests a TGT and in the request (KRG-AS-REQ) sends only its name and domain. The KDC finds the user and encrypts the Session Key with the user's Secret Key, which it sends back (along with the TGT). If the client does not know the password (Secret Key), it cannot decrypt the Session Key and thus cannot continue communicating with the KDC. However, an attacker could send a request on behalf of another user and then attempt brute-force attacks on the encrypted Session Key to discover the user's password.

Therefore, with Pre-authentication, a KRB-ERROR with the value KRB5KDC_ERR_PREAUTH_REQUIRED is sent in response to the KRG-AS-REQ request. The client then responds with a new KRG-AS-REQ packet, adding a timestamp encrypted with the user's Secret Key to the PADATA field. The KDC decrypts the timestamp (thus verifying the user) and checks if the time is correct (as with the Authenticator). It then continues in the usual manner.

Note: In Kerberos v5, Pre-authentication is optional, but it is required by default in Active Directory.

Realm - Domain

Each organization that wants to operate Kerberos defines its own Realm. The name of the Realm in which the user is registered is part of the username. Relationships can be established between Realms, they can be hierarchically organized, and DNS notation is most commonly used. In the Microsoft environment, the Kerberos Realm is equivalent to the Active Directory domain. The Kerberos Realm is case-sensitive and uppercase letters are used by default. The KDC can issue tickets only for its own Realm. An example of a Realm is FIRMA.LOCAL.

Principal Name

A Principal is a unique identity (a named entity of a client or server) to which Kerberos can assign a ticket. Kerberos serves to prove that the communicating entity was registered with the KDC under the identity it claims. A Principal can have several components separated by slashes (/), but the most common form is primary@REALM or primary/instance@REALM. This relates to the previously described UPN and SPN in Active Directory. An example of a user Principal is bouska@FIRMA.LOCAL and a service Principal is HTTP/www.firma.local@FIRMA.LOCAL.

Note: The Principal is usually used with the Realm, but it is not a requirement.

Secure Channel

In Windows, a Secure Channel is used when transferring a Secret Key (e.g., when creating a user and setting their password), so the transfer is secured by another Secret Key.

Kerberos Messages (Packets)

The Kerberos protocol typically communicates on TCP port 88. It uses several message types, some of which may be encapsulated in another protocol. Detailed information about messages, tickets, their content, and data types can be found in the specification RFC 4120 - 5. Message Specifications.

Client Communication with KDC

The most common messages involve the exchange of a request and a reply. The first communication is between the client and the Kerberos server (i.e., the KDC). To obtain a TGT, the client communicates with the Authentication Service (AS) and sends a KRB-AS-REQ (10) and receives a KRB-AS-REP (11). To obtain a Service Ticket, the client communicates with the Ticket-Granting Service (TGS) and sends a KRB-TGS-REQ (12) and receives a KRB-TGS-REP (13).

The following image shows the entire communication captured using Wireshark. It involves authentication to a web application and requires pre-authentication. Details will be covered in subsequent parts of the series.

Wireshark - packety procesu Kerberos SSO

When we look at the content of the messages, the requests have two main parts. padata, which stands for pre-authentication data, may contain information needed for processing or decryption. For example, in KRB-TGS-REQ, it includes the Authentication Header (Ticket-Granting Ticket and Authenticator). And KDC-REQ-BODY, which contains the actual request data, such as Client Name, Realm, Server Name (SPN). The reply may have several parts, including Client Name, Client Realm, and Ticket, which is the issued Ticket, showing the Server Name (SPN), Realm, and the encrypted part.

KRB-AS-REQ - Request for TGT

KRB-AS-REP - Returning TGT

KRB-TGS-REQ - Request for Service Ticket

KRB-TGS-REP - Response with Ticket

Client Communication with Service

For user authentication to an application server, the client and server communicate. A KRB-AP-REQ (14) is sent, containing mainly the ticket (Service Ticket) and authenticator. The ap-options may include the mutual-required flag, requiring the server to respond with a KRB-AP-REP (15), thus authenticating itself to the client. A KRB-ERROR (30) message with some error information may also appear. There are several other message types used for special cases.

Petr Bouška

SAMURAJ-cz.com
IT Manager OKsystem

Kerberos part 4 - key terms of the Kerberos protocol

Cryptography (kryptografie - šifrování)

Key Distribution Center (KDC)