Let’s continue our journey into the Magic Kingdom as a way to explore Kerberos. Sure the comparison doesn’t completely track, but it’s close and easy enough to grasp that I think you won’t mind missing—trust me on this—the standard Kerberos protocol diagrams.
Back to Disney World: you’re now in the park with your passport booklet and you’re ready to try a ride. For argument’s sake, let’s say you don’t find a ticket for Space Mountain in the passport. You bring your booklet to a park attendant, who reviews it, and then after paying her, she gives you the reward, the Space Mountain ticket.
Get the Free Pen Testing Active Directory Environments EBook
You head over to the ride, hand the tickets over while showing the passport, and then wait in line with the other Mountaineers.
So You Want to Ride a Server?
In the Disney World model, you don’t just go directly to the ride and pay your money. Instead, their ticketing system effectively introduce a separate step, which involves proving you’re a valid Disney customer (and not someone who has hopped the fence) before getting a ride ticket.
Similar to Disney (but unlike NTLM), Kerberos also has a special interaction in which the client app shows its ticket granting ticket or TGT—it’s version of the Disney passport–to a Ticket Granting Server or TGS. The TGS, please note this, is not the actual server you’re trying to access: think of it as that highly efficient park attendant who examines the paperwork.
To interact with the TGS, the client app first takes the user’s password hash to decrypt the session ID that was returned during logon—see the last post. The client then sends its identity information (IP address, user name) encrypted with the session ID , the name of the service it wants to use, and of course the TGT to the Ticket Granting Server.
The encryption-decryption mechanics—take a deep breath, eat something first—work as follows. The TGS uses the special secret key maintained by Kerberos to decrypt the TGT. From the TGT, it retrieves the session ID, which it then uses to decrypt the user identity data. The information in the TGT has to be consistent the client identity data; otherwise, the TGS rejects the request as not authenticated.
So at this point, the TGS knows who’s requesting access to a server. This is also a good place for organizations to add their own authorization checks. After all, not everyone who wants to access a server (Sharepoint, CRM, etc.) is authorized to do so. And Kerberos is flexible enough to allow for this enhancement.
Printing the Server Ride Ticket
The TGS now responds with yet another encrypted ticket, this time specifically for the server that the client requested. You can think of it as the actual ticket for a Disney ride.
The TGS generates yet another random number, let’s call it the server session ID, and returns an encrypted server ticket to the client, which contains this server session ID along with a time stamp and other identity data. As with the TGT, the server ticket or ST is encrypted with yet another secret key maintained by Kerberos.
The TGS also passes back the server session ID, but encrypted with the initial session ID from the first interaction. If my explanation is successful, the use of random session IDs and special secret keys should remind you of the logon interaction in my first post—under the hood, it’s the same protocol.
Getting on the Server Ride
After all this work, it would be nice if the interaction with the actual service—the Disney ride—is relatively simple. Kerberos delivers on this.
The client app first decrypts the server session ID that the TGS returned by using the saved session ID. Again it sends identifying data, this time encrypted with the server session ID it just obtained, and also sends the TGS generated server ticket.
The actual server interacts with Kerberos to obtain the secret key, and therefore can decrypt and validate the client’s request and the server ticket.
And that’s it! If you find my tour de force explanation unsatisfying, then try this one, which explains Kerberos as if you were a (smart) five-year old.
Recap: Kerberos Differentiators and Advantages
Summarizing Kerberos in a few words, you can say it’s a system that supports strong authentication. The authentication checks happen at every step and the use of crypto secure time-stamped tickets are a powerful idea—it makes it very difficult to pull off replay attacks.
It’s also worthwhile to point out that both TGT and ST are encrypted with secret keys known only by Kerberos. So the client app can never decrypt the tickets. They only pass it along, but they can still prove it’s their ticket because they have knowledge of the session keys.
It’s a very clever idea: the virtual equivalent of a validated passport or document that proves your identity and is very, very hard to forge.
When it was originally developed in the pre-Internet era, Kerberos was thought to be overkill. In large insecure distributed environments, Kerboros is a particularly robust way to handle trust, especially now that hackers are a constant threat. The MIT geniuses behind Kerberos had anticipated something like an Internet with lots of servers communicating behind the scenes– not that different from what we have today.
Finally, the exchange with the server is only a one-step process, versus three for NTLM. A client can gather its server tickets in one swoop, and then each time it needs to make a server request, it’s just a single message.
What does Microsoft think of Kerberos? They came up with their own extended version of it and made it the default authentication protocol starting with Windows 2000.
Image credit: FriedC