How Kerberos Authentication Works

You may not know it, but your network is probably unsecured right now. Anyone with the right tools could capture, manipulate, and add data between the connections you maintain with the internet. The security cat and mouse game isn’t one sided, however. Network administrators are currently taking advantage of Kerberos to help combat security concerns.

Project Athena

Project Athena was initiated in 1983, when it was decided by the Massachusetts Institute of Technology that security in the TCP/IP model just wasn’t good enough. A total of 8 long years of research passed before Kerberos, named after the three-headed Greek mythological dog known as Cerberus, was officially complete.

The result of MIT’s famous research became widely used as default authentication methods in popular operating systems. If you are running Windows 2000 or later, you are indeed running Kerberos by default. Other operating systems such as the Mac OS X also carry the Kerberos protocol. Kerberos isn’t just limited to operating systems, however, since it is employed by many of Cisco’s routers and switches.

What Does It Protect Against, Anyways?

If you have ever used an FTP program over a network, you are at risk. If you have ever used a Telnet program over a network, you are again at risk. These are just two examples of how little security some applications allow. FTP and Telnet use what are called plaintext passwords, or otherwise known as cleartext passwords. These passwords are ridiculously easy to intercept with the right tools.

Anyone with a simple packet sniffer and packet analyzer can obtain an FTP or telnet logon with ease. With that kind of sensitive information being transmitted, the need for Kerberos is obvious. This need doesn’t stop there, however. Sure FTP and Telnet related logons are easy to intercept, but then again so is every other connection any of your applications has to the internet.

Through a process of man in the middle attacks, any hacker can get most logon information for just about anything. From online bank passwords to private passwords on your computer, they are all generally vulnerable to this attack. A man in the middle attack generally occurs when the hacker acts as the “man in the middle” between two computers. The hacker attempts to pretend to each computer that it is in fact, the computer they have connected to. In reality, all the data is being routed to the hacker, who can then modify or add instructions to the data.

Okay, This Sounds Useful…But How Does It Work?

Kerberos operates by encrypting data with a symmetric key. A symmetric key is a type of authentication where both the client and server agree to use a single encryption/decryption key for sending or receiving data. When working with the encryption key, the details are actually sent to a key distribution center, or KDC, instead of sending the details directly between each computer. The entire process takes a total of eight steps, as shown below.

1. – The authentication service, or AS, receives the request by the client and verifies that the client is indeed the computer it claims to be. This is usually just a simple database lookup of the user’s ID.

2. – Upon verification, a timestamp is created. This puts the current time in a user session, along with an expiration date. The default expiration date of a timestamp is 8 hours. The encryption key is then created. The timestamp ensures that when 8 hours is up, the encryption key is useless. (This is used to make sure a hacker doesn’t intercept the data, and try to crack the key. Almost all keys are able to be cracked, but it will take a lot longer than 8 hours to do so)

3. – The key is sent back to the client in the form of a ticket-granting ticket, or TGT. This is a simple ticket that is issued by the authentication service. It is used for authenticating the client for future reference.

4. – The client submits the ticket-granting ticket to the ticket-granting server, or TGS, to get authenticated.

5. – The TGS creates an encrypted key with a timestamp, and grants the client a service ticket.

6. – The client decrypts the ticket, tells the TGS it has done so, and then sends its own encrypted key to the service.

7. – The service decrypts the key, and makes sure the timestamp is still valid. If it is, the service contacts the key distribution center to receive a session that is returned to the client.

8. – The client decrypts the ticket. If the keys are still valid, communication is initiated between client and server.

Is all that back-and-forth communication really necessary? When concerning speed and reliability, it is entirely necessary. After the communication is made between the client and server, no further need of transmitting logon information is needed. The client is authenticated until the session expires.

Yet More Authentication

The authentication method described above seems a little one-sided. Kerberos provides support for mutual authentication, for a more secure protection against man in the middle attacks. Remember how the client no longer needs to send logon information after the authentication takes place? Well it sure would ruin everything if a hacker just intercepted our communication to the server and pretended to be us!

This type of authentication is fairly easy to understand, since it only involves two systems.

The Mutual Authentication Process

---

• 1. The first system creates a challenge code made up of random numbers.
• 2. This code is sent to the second system, which generates a response to the received code. This response and a challenge code of its own are then sent back to the first system.
• 3. The first system verifies the response of the second system, and then sends a response to the challenge code it received.
• 4. When the second system receives the response, it is verified. If all is well, it notifies the first system that they are indeed mutually authenticated.

---

This type of authentication uses challenge codes to ensure that both computers are who they claim to be. If someone tries to intercept the data, they obviously will fail because they can’t pretend to be one of the computers after they have been authenticated with challenge codes.

Sounds Great! Any Drawbacks I Should Know About?

Of course, nothing is perfect. Kerberos has a couple of main flaws that system administrators need to take into account.

First and foremost is the need of the Kerberos server. This server will handle all the functions required for authentication. If this server goes down, no one can get authenticated, and thus- the network is down. A total network crash can be prevented by using more than one Kerberos server, but that is more costly than some people would like to think.

Next, we have the issue of clock synchronization. Since Kerberos uses timestamps to handle all activity, the clocks on all host machines must be within 10 minutes of the Kerberos server’s clock. Since not all clocks are perfect, the host clock and server clock will eventually be misaligned enough to cause a failure. This can usually be remedied by keep clocks up to date, or use a Network Time Protocol, or NTP.

Closing Comments

Kerberos isn’t the only encryption protocol available. There are multiple ways to encrypt data, and this holds true for many types of different applications. Email encryption protocols, for example, are a breed all of their own.

With a product that has been researched and developed for over 8 years, it is generally expected that the product should be well polished. Kerberos doesn’t fail to deliver, and this can be seen by looking at all the vendors who use it. Cisco, Microsoft, Apple, and many others rely on this faithful three-headed dog for network security.

As Greek mythology goes, you could get around Cerberus by gently lulling him to sleep with honey cakes. Rest assured it will take a lot more than that to get past the famous Kerberos security.