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 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.