Kerberos is an authentication protocol, which means it is a prescribed method for a user to prove their identity to a particular application service over a network.
The set of players in the protocol can be seen as:
- a client program acting on behalf of a user
- a centralized service, called the Authentication Server (AS)
- one or more application servers.
Kerberos works by using the Authentication Server as a middle-man between clients and applications. The Authentication Server must have a priori knowledge of:
- all users in the system
- all application services in the system
to allow a user known by the Authentication Server to prove their identity to an application service known by the Authentication Server.
During the system's set-up, the Authentication Server must be informed about all users in the system.
This means for each user, an account is created on the Authentication Server and given a password chosen by the user. The username, password, and the Kerberos version number are encrypted using an agreed-upon encryption scheme to produce a secret key for the user.
Now, the user can use their username and password under the same encryption scheme to re-create their secret key from anywhere.
The user can therefore send confidential messages to the Authentication Server over a network by encrypting the message with their secret key.
Similarly, each application service must be issued a secret key that it can use to communicate with the Authentication Server over a network.
Note: in the diagrams below, colors are used to help clarify which segments are encrypted by which keys, since there are three keys involved, and it can get confusing.
When a client wants to prove its identity to an application, it sends a message containing the user's username (in cleartext) and a request to authenticate to a particular application service (encrypted by the user's secret key) to the Authentication Server.
The Authentication Server looks up the username to find the user's secret key and uses it to decrypt the request.
The Authentication Server then creates a Kerberos ticket containing:
- a session key
- the session key expiration time
- the user's identity.
The Authentication Server creates a response containing a cleartext version of the ticket AND a version of the ticket encrypted using the desired application service's secret key.
The Authentication Server then encrypts the entire response using the user's shared key and sends it to the client.
Now the client sends the application server a request containing:
- the Kerberos ticket encrypted by the application service's secret key (received from the Authentication Server)
- an "authenticator" encrypted by the session key containing
- the current time
- a checksum
- the user's identity
and sends it to the application server.
Finally, the application server decrypts the Kerberos ticket using its own secret key, and decrypts the authenticator using the session key from the ticket.
The application server calculates the checksum for the request and checks if it matches the checksum in the authenticator.
If it does, then the application server knows the same session key was used to encrypt the authenticator as to decrypt it, so the sender must have known the session key in the ticket.
The application server then verifies the identity of the sender by checking that the identity in the ticket matches the identity in the authenticator.
The client can optionally include a request that the application server also prove its identity. In this case, the application server sends a response encrypted by the session key (thereby proving that the application server was able to decrypt the ticket using its secret key).
If the system contains a set of application services which a user should be able to access, it is desirable for the user to be able to authenticate just once rather than once for each service.
A simple way to do this is to cache the user's password in memory, but a safer way is to use an extended version of the Kerberos protocol which caches only tickets and encryption keys for a limited time.
When the user logs in, an authentication request for the ticket granting service is issued to the Authentication Server. The ticket that is returned is called the ticket granting ticket.
The version of the ticket granting ticket encrypted by the ticket granting service's secret key is cached on the client, along with the session key from the ticket granting ticket.
Now when the user accesses a new service (and therefore needs to authenticate to that service), a ticket for that service is requested from the Authentication Server via the ticket granting service.
As a by-product of the authentication protocol, the client and application server end up with a shared key that they can use to further exchange private encrypted messages.
- Draws heavily from USC/ISI Technical Report number ISI/RS-94-399
- Redmond Magazine
- Blog post by Lynn Root