Kerberos - How Does It Work?
What Is Kerberos?
Kerberos is a network authentication protocol designed at MIT. MIT also offers open source software implementing this protocol. Kerberos is intended to provide secure authentication over insecure networks such as the Internet. Further, Kerberos provides for mutual authentication, each party can be assured of the identity of the other. It is also resistant to replay and man-in-the-middle attacks.
Kerberos in Action
Let’s look at the Kerberos authentication process. Kerberos relies on trusted third parties to work. It leverages strong encryption and the granting of “tickets” for service sessions between clients and servers to provide secure authentication. The Kerberos server components are the Authentication Server and the Ticket-Granting Server. A Kerberos-enabled server providing a desired network service and of course a Kerberos client are of course required as well.
First, the client contacts the Authentication Server with a request for access to service(s). The Authentication Server verifies the client’s presence in its database, and if so, sends two messages to the client. The first message is a Client/Ticket-Granting Server session key that is encrypted with the client’s secret key. Note that the Authentication Server has the client’s secret key it its database; the secret key is not sent over the network. The second message is a Ticket-Granting Ticket, encrypted with the Ticket-Granting Server’s secret key. The Ticket-Granting Ticket includes the client’s ID, network address, the ticket’s validity period, and a copy of the Client/Ticket-Granting Server session key.
Next, the client sends two messages to the Ticket-Granting Server. The first of these is the Ticket-Granting Ticket plus the ID of the desired service. The second is called the Authenticator. It is composed of the Client ID and a timestamp, and is encrypted using the session key. The Ticket-Granting Server uses its secret key to decrypt the Ticket-Granting Ticket. It then uses the session key to decrypt the Client ID and timestamp from the Authenticator. At this point the Ticket-Granting Server has verified that the client is who they claim to be, and that the request is valid. The server then sends back to the client a new ticket (Client/Server Ticket) for the requested service, encrypted with the service’s secret key, including the client ID, network address, valid time period, and a Client/Server session key. Along with this is a copy of the Client/Server session key encrypted with the Client/Ticket-Granting Server session key so that the client will have it.
The client then contacts a server providing the desired service and sends two messages. The first one, as you might guess, is the Client/Server Ticket. Along with this the client sends an Authenticator containing the client ID and a timestamp, encrypted with the Client/Server session key.
The server providing the service decrypts the Client/Server Ticket using its secret key. It then uses the Client/Server session key to decrypt the Authenticator. The server then increments the timestamp, and sends the client a message encrypted with the session key containing the incremented timestamp. On receipt, the client and server are authenticated with each other and the client begins normal client-server service requests and the server provides services.
Where Is It?
From Windows 2000 onward Kerberos is the primary authentication protocol. Other operating systems that have Kerberos capable or enabled as the default authentication protocol include: Mac OS X, Red Hat Enterprise Linux 4 (and later), Sun Solaris, and FreeBSD. As a user you usually don’t know, or have to know, that Kerberos is in place and in use. It’s transparent and behind the scenes. Importantly, it may not be in use, as there are usually fall-back means of authentication in place or other authentication protocols may have been configured if one or more services available were not Kerberos capable or “Kerberized”. Don’t make assumptions–ask your administrator if you’re interested. If you’re the administrator, verify that the service in question is Kerberos capable and configure it for use if you can.
