Kerberos, is a network authentication protocol that uses tickets to allow entities to prove their identity over potentially insecure channels to provide mutual authentication. It also uses symmetric encryption to protect protocol messages from eavesdropping and replay attacks. The name Kerberos is taken from the greek mythical character of the same name, a three headed guard dog protecting the gates to Hades the underworld. Seems like an appropriate choice for an authentication protocol, don't you think. Kerberos was originally developed at the Massachusetts Institute of Technology in the US. And was published in the 1980s as version four. Years later in 1993 Version 5 was published. Today, Kerberos supports AES encryption and implements check sums to ensure data integrity and confidentiality. When joined to a Windows Domain, Windows 2000 and newer versions will use Kerberos as the default authentication protocol. Microsoft also implemented their own Kerberos service, with some modifications to the open protocol. Like the addition of the RC4 stream cipher, we mentioned tickets earlier, which is a sort of token that proves your identity. They can be used for authenticating to services, protected using Kerberos or in other words are within the Kerberos realm. The authentication tickets let users authenticate two services without requiring user name and password authentication, for every service individually. A ticket will expire after some time, but has provisions for automatic transparent renewal of the ticket. Let's run down the details of how the Kerberos protocol operates. First, a user that wants to authenticate, enters their user name and password on their client machine. Their Kerberos client software, will then take the password and generate a symmetric encryption key from it. Next, the client sends a plain text message to the Kerberos AS or authentication server which includes the user ID of the authenticating user. The password or secret key derived from the password aren't transmitted. The AS uses the user ID to check if there's an account in the authentication database, like an active directory server. If so the AS will generate the secret key using the hashed passwords stored in the key distribution center server. The AS will then use the secret key to encrypt and send a message containing the client TGS session key. This is a secret key used for encrypting communications, with the ticket granting service or TGS, which is already known by the authentication server. The AS also sends a second message, with a ticket granting ticket or a TGT, which is encrypted using the TGS secret key. The ticket granting ticket has information like the client ID, Ticket validity period and the client ticket granting service session key. So the first message can be decrypted using the shared secret key derived from the user password. It then provides the secret key, that can decrypt the second message giving the client a valid ticket granting ticket. Now, the client has enough information to authenticate with the ticket granting server. Since the client has authenticated and received a valid ticket granting ticket, it can use the ticket granting ticket, to request access to services from within the Kerberos realm. This is done by sending a message to the ticket granting service, with the encrypted ticket granting ticket received from the AS earlier, along with the service name or ID the client is requesting access to. The client also sends a message, containing an authenticator which has the client ID and a time stamp, that's encrypted with the client ticket granting ticket session key from the AS. The ticket granting service decrypt the ticket granting ticket, using the ticket granting service secret key. Which provides the ticket granting service, with the client ticket granting service session key. It then uses the key, to decrypt the authenticator message. Next it checks the client ID of these two messages to ensure they match. If they do, it sends two messages back to the client. The first one, contains the client to server ticket which is comprised of the client ID, client address, validity period and the client server session key, encrypted using the services Secret key. The second message, contains the client server session key itself and is encrypted using the client ticket granted service session key. Finally, the client has enough information to authenticate itself to the service server or SS. The client sends two messages to the SS, the first message is the encrypted client to server ticket, received from the ticket granting service. The second, is a new authenticator with the client ID and timestamp encrypted using the client server session key. The SS decrypt the first message, using its secret key which provides it with the client server session key. The key is then used to decrypt the second message and it compares the client ID in the authenticator to the one included in the client to server ticket. If these ideas match, then the ss sends a message containing the timestamp from the client supplied authenticator, encrypted using the client server session key. The client then decrypt this message and checks at the timestamp is correct authenticating the server. If this all succeeds, then the server grants access to the requested service on the client. Wow, okay are you with me, I know that was a lot. Kerberos has received some criticism because it's a single monolithic service. This creates a single point of failure danger, if the Kerberos service goes down, new users won't be able to authenticate and log in. Aside from availability issues, if the central Kerberos servers compromised, the attacker would be able to impersonate any user by generating valid Kerberos tickets for their user account. Kerberos enforces strict time requirements, requiring the client and server clocks to be relatively closely synchronized, otherwise authentication will fail. This is usually accomplished by using NTP to keep both parties synchronized using an NTP server. The trust model of Kerberos is also problematic, since it requires clients and services to have an established trust and the Kerberos server in order to authenticate using Kerberos. This means it's not possible for users to authenticate using Kerberos, from unknown or untrusted clients. So, things like BYOD or bring your own device and cloud computing, are incompatible. Or at least very challenging to implement securely with Kerberos authentication. Now, as an IT support specialist, you're likely to encounter Kerberos authentication, especially in environments running Microsoft Active directory. Understanding how the underlying protocol functions will help when troubleshooting issues that may come with it.
