Authentication Protocols – Kerberos
Kerberos Concepts
Kerberos authentication protocol operates primarily at the Application Layer(Layer 7) of the OSI. Kerberos aims to enable two parties to exchange private information securely over an insecure network.
It was developed in the mid-1980s as part of MIT’s Project Athena. The protocol is named after the mythological three-headed dog Kerberos (or Cerberus), the guardian of the Greek underworld.
Microsoft introduced their version of Kerberos in Windows 2000. It has also become a standard for websites and Single-Sign-On implementations across platforms.
Kerberos vs. NTLM
Before adopting Kerberos, Microsoft used a protocol known as NTLM (NT Lan Manager) for authentication. NTLM, which is a challenge-response authentication protocol, involves the target computer or domain controller verifying a password and then storing password hashes for future use.
The key difference between NTLM and Kerberos lies in Kerberos’ use of third-party verification and its stronger encryption capabilities. This added step in Kerberos significantly enhances security compared to NTLM.
In today’s security landscape, NTLM is considered outdated and vulnerable. It can be compromised within hours, making it unsuitable for protecting sensitive data. Hence, relying on NTLM for security purposes is not recommended due to its vulnerabilities and the superior security offered by newer technologies like Kerberos.
Authenticaiton Flow
Kerberos uses a trusted third party, known as the Key Distribution Center (KDC), to authenticate users and services.
1. KRB_AS_REQ:
The client requests a TGT from the Key Distribution Center (KDC)’s Authentication Server (AS).
The client encrypts the timestamp ① with its password-derived key (let’s call it ClientKey, someone will also call that NTLM Hash). This is used for pre-authentication.
In the following example, in the frame 196 the client machine with the IP address “192.168.2.55” initiates an Authentication Service (AS) Request to the Domain Controller named “Ruian-ADDS-01.ruianding.com.” However, the DC returns an KRB_ERROR – KDC_ERR_PREAUTH_REQUIRED (25)
1.1 Why there’s a KDC_ERR_PREAUTH_REQUIRED Error?
The KDC_ERR_PREAUTH_REQUIRED error in Kerberos authentication is a standard and expected part of the protocol, signifying the need for pre-authentication. It occurs when a client initially requests a TGT from the KDC. The KDC responds with this message to prompt the client to prove its identity, enhancing security by preventing replay attacks. This is done by having the client encrypt the current timestamp with a key derived from the user’s password, which the KDC then verifies. Once the client successfully completes this step, the KDC proceeds with the standard Kerberos authentication process. This response is commonly seen in Kerberos authentication traces and is a routine component of the protocol, not an indication of an error.
① So if we compare the frame 196 and the frame 204 after the Preauth challenge. We can see the frame 204 has extra content which is the encyrted timestamp.
2. KRB_AS_REP:
The KDC, after validating the pre-authentication, sends back the TGT (Golden Ticket) and a session key (let’s call it TGTSessionKey). The TGT is encrypted with the KDC’s secret key (KDCSecretKey/someone will also call it KDC account NTLM hash), which the client cannot decrypt. The TGTSessionKey is encrypted with ClientKey.
Domain Controller “Ruian-ADDS-01.ruianding.com” respond the with the TGT to the client machine 192.168.2.55″.
3. KRB_TGS_REQ:
The client requests a service ticket for a specific server (let’s call this server “Service”). It sends the TGT (which it can’t decrypt) and an authenticator (which includes the client’s ID and a timestamp), encrypted with the TGTSessionKey.
The client machine with the IP address “192.168.2.55” initiates an TGS Request to the Domain Controller named “Ruian-ADDS-01.ruianding.com.”
4. KRB_TGS_REP:
The KDC decrypts the TGT with its KDCSecretKey and the authenticator with the TGTSessionKey. It sends back a service ticket (encrypted with the Service’s secret key, ServiceKey) and a service session key (ServiceSessionKey), encrypted with the TGTSessionKey.
Domain Controller “Ruian-ADDS-01.ruianding.com” respond the with the TGS Response to the client machine “192.168.2.55”.
5. KRB_AP_REQ:
The client sends the service ticket (which it cannot decrypt) and a new authenticator, which includes the client’s ID and timestamp, encrypted with the ServiceSessionKey, to the Service.
6. KRB_AP_REP:
The Service decrypts the ticket with ServiceKey to obtain the ServiceSessionKey, then uses this key to decrypt the authenticator. If the information matches and is timely, the Service grants access.
References:
https://www.varonis.com/blog/kerberos-authentication-explained