Authentication Lessons from the Magic Kingdom: A Closer Look at Kerberos, Part I

The flaws in NTLM I’ve been writing about might lead you to believe that highly-secure authentication in a distributed environment is beyond the reach of mankind. Thankfully, resistance against hackers is not futile. An advanced civilization, MIT researchers in the 1980s to be exact, developed open-source Kerberos authentication software, which has stood the test of time and provides a highly-secure solution.   

How good is Kerberos? Even Microsoft recognizes it as superior and openly recommends and supports it—albeit through their own version. The Kerberos protocol is more complicated than NTLM and harder to implement but worth the effort.

It’s also quite difficult to explain in a blog post. Kerberos involves complex interactions in which “tickets” or tokens are handed over by clients to various guardian servers. Faced with having to discuss Kerberos using all the usual protocol diagrams (see Wikipedia if you must), I decided to look for a better approach.

While I’ve no proof of this, it’s possible that the Kerberos authors may have been inspired by a real-world authentication systems used in theme parks—perhaps even looking at Disney World.

The General Admission Ticket (Kerberos’s Ticket Granting Ticket)

I haven’t been to the Magic Kingdom in a good long time, but I do remember an overall admission “passport” that allowed one to enter the park but also included tickets for individual rides—by the way, you can read more about Disney ticketing here.

Kerberos has a similar general admission concept. Unlike NTLM, user and client apps have to interact with what’s called a key distribution center (KDC), and initially the logon component, before they can even authenticate with and use individual services.

You can think of the front gate at Disney World, where you purchase the passport and the first round of authentication checks are made, as the Kerberos KDC logon service, and the Disney passport as what Kerberos refers to as the Ticket Granting Ticket or TGT.

As I recall, the passport lets you gain access to some of the rides, but then for the really good ones—say Pirates of the Caribbean—you’d have to pull out the individual tickets. So once in the park, the passport booklet always authenticates you as someone who has paid the fee to get in, thereby allowing Disney customers to use the individual ride tickets or purchase additional ones as well.

It Takes Three to Authenticate

NTLM authentication provides a binary relationship between a user and a server with no central authentication authority.  Perhaps more like a carnival where you show generic tickets—typically easy to forge!—directly to the ride attendant.

Kerberos, though, introduces a third component, the KDC. By the way, Kerberos refers to a mythological three-headed hound that guards the entrance to the underworld—we’re talking one tough guard doggy.

In the physical world, a complex administrative process is required to validate a document—theme part ticket, passport, driver’s license, etc.—as belonging to the holder and also making the paperwork difficult to duplicate. Perhaps not surprisingly, there’s similar complexity in issuing Kerberos’s TGT.

Here’s how it works.

Like NTLM, Kerberos also uses passwords and other IDs indirectly as keys to encrypt certain information. To start the authentication process, the Kerberos client sends basic identity data—user name and IP address—to the KDC. The KDC logon component than validates this against its internal database of users, and prepares the TGT—the digital version of the Disney passport.

The KDC first generates a random session ID.  It take the identifying information sent by the client along with the session ID and some time stamp data  to form the TGT. To say it another way, the TGT contains some unique data about the user along with another encryption key that is then used later on.

For this whole thing to work, the client needs the session ID.  But, of course, you can’t pass this as plain text, so the session ID is itself encrypted with, what else, but the user’s password or more precisely the hash of the password.  And then the two encrypted chunks of data are sent back to the user: the encrypted session ID and the encrypted TGT. And to make things even more confusing, the TGT was actually encrypted with yet another special key maintained by the KDC.

It’s a Small Authenticated World 

For all this to work, Kerberos makes the traditional assumption that only the user and the KDC have the password—a secret shared between the two of them. The client software asks the user for a password and then applies the hash to decrypt the session ID sent back by the KDC, which it will use in its next interaction.

At this point, the Kerberos client has access to the overall IT theme park, but just as in Disney, needs to go through another process to, so to speak, ride the server.

Just stepping back a bit, we can see the beauty of the first interaction to gain the TGT. The client is authenticated since it has the hash of the user’s secret password that decrypts the session ID. The server is authenticated since it has the private key used to encrypt the TGT.

Of course, the server side of mutual authentication generally is not an issue in theme parks—unless somehow fake Disney Worlds started popping up that were taking advantage of paying customers!

But as I pointed out last time, rogue servers are a problem with NTLM’s challenge-response protocol. Kerberos completely solves this both at initial authentication and, as we’ll see next time, in gaining access to individual IT rides.

There’s a lot to digest here. I’ll continue with the rest of the Kerberos process in the next post.

Image Credit: CyberxRef