Kerberos - named after the three-headed guard dog of Greek mythology - is a third-party network authentication protocol created by MIT. Kerberos uses secret-key cryptography to ensure secure authentication with client/server applications even on non-secure networks. To establish a user’s authenticity, the client and server pass encrypted keys called ‘tickets’ back and forth, instead of the usual user ID and password combination.
Kerberos is designed to completely avoid storing any passwords locally or having to send any passwords through the internet and provides mutual authentication, meaning both the user and the server’s authenticity are verified.
How Kerberos Authentication Works
Every user within a system - referred to as a “principal” - begins with a unique ticket. These tickets are issued by the authentication server also known as the Kerberos Key Distribution Center - commonly referred to as the KDC - and are used to identify specific principals. The ticket is encrypted with a secret key and stores various pieces of information about a principal’s credentials.
This secret key is a shared secret only between the authentication server and the server that the client is trying to access, therefore the client that requested the ticket can’t know or change any of the contents of the issued ticket. Kerberos also uses symmetrical key encryption, meaning the same key is used for encrypting and decrypting.
The ticket generally contains information about the principal, including:
- The session key
- The identification of the the requesting user - this is commonly a username
- The server / service that the request is for
- The client-side IP address of the device which is authorized to use the specific ticket
- The ticket's time until expiration (commonly 10 hours)
- The time of the ticket’s generation
The administrator of the Kerberos realm (the collection of machines and principals) can prevent the issuing of tickets to certain users, but is not able to revoke a ticket once it has been issued. Therefore, it’s important that each ticket has an expiration time associated with it.
To receive a ticket, the client sends a request to the authentication server that includes information about the server they want to connect to. The authentication server then checks if the client’s username is in the KDC database. If the username is valid, the authenticating server creates and issues a ticket with a session key attached. With this process, the user’s password never needs to be stored in an unencrypted form, even in the database of the authentication server.
Any time information is sent back and forth through the internet, that information has increased exposure to outside sources, including potential malicious attackers. Hackers will often use tools to try to lift passwords out of networks as the passwords are sent back and forth. It’s because of this vulnerability that it’s much safer to always guarantee that when a password is sent through a network it is encrypted. The Kerberos password authentication makes sure this is true and also verifies the identity of the client sending the request.
Firewalls are a good form of defense from outside intrusions or malicious hackers, but they usually operate under the assumption that attacks are coming from outside a network. This leaves the door wide open for attacks carried out by people who already have access to the network. The Kerberos authentication process, on the other hand, works regardless of the location of the potential intrusion.
Implementing Kerberos-based authentication within your network will allow Barracuda CloudGen Firewalls to associate outgoing web requests with Active Directory users, to log user activity, and to apply user-specific or group-specific policies to outgoing connections.
The Barracuda Web Security Gateway includes Kerberos integration to allow for requests from clients behind a NAT-enabled router, Windows Terminal Services, and Citrix Presentation Services.
Do you have more questions about Kerberos Authentication? Contact us now.