Kerberos Authentication|| A Detailed Simplification

hrishidevdarsan
May 3, 2024 Posted by 701 Views

Welcome, fellow digital explorers! Today, we’re diving headfirst into the fascinating world of Kerberos authentication—a bit like unlocking the secrets of a mythical three-headed dog guarding our digital gates. You see, Kerberos isn’t just your run-of-the-mill network protocol; it’s more like your tech-savvy best friend, ensuring only the right folks get access to the good stuff in our online playground.

Think of it this way: Kerberos is the bouncer at the coolest club in town, making sure only VIPs (Very Important Persons) get past the velvet rope. Developed back in the ’80s at MIT, it’s been polished up over the years, kind of like a timeless classic that never goes out of style.

So, grab your favorite beverage, cozy up, and let’s embark on this journey together. We’ll unravel the mysteries of Kerberos, chat about its inner workings, and why it’s the go-to guardian for our digital domains. Ready? Let’s roll! 🚀

Essential Kerberos Terminologies: Understanding the ABCs of Authentication

  1. KDC (Key Distribution Center): Central component in Kerberos authentication responsible for issuing and managing cryptographic keys.
  2. AS (Authentication Server): Initial authentication service in Kerberos that verifies user identities and issues TGTs.
  3. TGT (Ticket Granting Ticket): Ticket issued by the AS upon successful authentication, allowing users to request service tickets.
  4. krbtgt (Kerberos Service Account): Special account used by the KDC to encrypt TGTs for secure transmission.
  5. TGS (Ticket Granting Service): Component in Kerberos responsible for validating TGTs and issuing service tickets.
  6. ST (Service Ticket): Ticket issued by the TGS, granting authenticated users access to specific network services.
  7. PAC (Privilege Attribute Certificate): Data structure containing user attributes and permissions, included in the user’s TGT for authorization purposes.
  8. Timestamp: A timestamp is a piece of data that represents the time at which a particular event occurred.
  9. User’s secret key: NTLM hash of the user.
  10. Service’s secret key: NTLM hash of the service.

Short Version

  1. User initiates access to a service within the Active Directory by sending an encrypted message to the authentication server, requesting access and verification.
  2. Authentication server verifies the request’s legitimacy and generates a Ticket Granting Ticket (TGT).
  3. TGT is sent to the user.
  4. User crafts a new message and sends it, along with the TGT, to the Ticket Granting Server (TGS).
  5. TGS decrypts the TGT and conducts validation.
  6. TGS generates a Service Ticket (ST).
  7. ST is sent back to the user, along with another message.
  8. User decrypts the message.
  9. User creates an Authenticator message, including the ST, and sends it to the service.
  10. The service conducts validation and grants the user access to the service.

Diving into Detailed Explanation

STEP-1

The user starts by sending a request to the Authentication Server (AS) located within the Key Distribution Center (KDC). This request, encrypted with the user’s secret key, which is the user’s NTLM hash, contains the user’s username, their IP address, and a timestamp.

When the Authentication Server (AS) gets the request, it simply decrypts the message using the user’s secret key.

STEP-2

Next, the Authentication Server (AS) crafts two messages. The first one is the Ticket Granting Ticket (TGT), packed with the user’s username, IP address, Ticket Granting Service (TGS) name, timestamp, and TGS session key. It’s encrypted with the KRGTGT secret key. The second message from the AS includes the TGS name, timestamp, and TGS session key, encrypted with the user’s secret key. Both messages are then sent over to the user.

Upon receiving the message from the AS, the user decrypts the message encrypted with their secret key, retrieving the “TGS session key.” However, the user cannot decrypt the TGT because it’s encrypted with the KRBTGT secret key.

STEP-3

Now, the user crafts a user authenticator message, packing in the username, timestamp, service name, and desired ticket lifetime. This message is then encrypted with the TGS session key. Afterward, the user sends this message, along with the previously received TGT, over to the TGS (Ticket Granting Server).

Upon receiving the message, the TGS decrypts the TGT using the KRBTGT secret key to retrieve the TGS session key. With this key, it decrypts the user authenticator message, which was encrypted using the TGS session key.

STEP-4

The TGS generates a Service Ticket to grant access to the specific service that the user intends to access. This ticket includes the username, user IP, service ID, timestamp, and service session key. It’s then encrypted with the specific secret key of the service. Additionally, the TGS crafts another message containing the service name, timestamp, ticket lifetime, and service session key which is encrypted with TGS session key. Both the message and the Service Ticket are sent to the user.

Upon receiving the message, the user decrypts it using the TGS session key, thereby obtaining the service session key. However, the user is unable to decrypt the Service Ticket as it’s encrypted with the service’s secret key.

STEP-5

Then the user creates another “user authenticator” message which includes username, timestamp, and service name which is encrypted with service session key. This message is sent directly to the service along with the Service Ticket which is obtained from the TGS.

When the service receives the message from the user, it decrypts the service ticket using its secret key, thus obtaining the service session key. Using this key, it decrypts the user authenticator message. Afterward, the service verifies the information provided in both the Service Ticket and the user authenticator message to ensure integrity.

STEP-6

Then, the service promptly sends a PAC (Privilege Attribute Certificate) request message to the KDC to verify the user’s access privileges for the service. Subsequently, the KDC responds by sending back the PAC verification request to the service, detailing the specific user’s privileges.

STEP-7

Then, the service dispatches a service authenticator message containing the service name and timestamp, encrypted with the service’s session key.

Upon receiving the service authenticator message, the user decrypts it using the service’s session key. The user then verifies that it’s indeed the intended service, and consequently gains access to the service.

In conclusion, our journey through Kerberos authentication has illuminated the intricate process of securing access to network services. From the initial request to the final verification, each step plays a crucial role in ensuring the confidentiality and integrity of our interactions. We hope this exploration has provided valuable insights into the workings of Kerberos and its importance in safeguarding digital environments. As we wrap up, I invite you to reflect on the significance of authentication protocols like Kerberos in maintaining the security of our interconnected world. Thank you for joining me on this journey, and I hope you found it both enlightening and enjoyable. Stay secure, and happy exploring!