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