How Authentication Works

Kerberos performs authentication as a trusted third-party authentication service using shared secret key cryptography.

The authentication process proceeds as follows:

1. A client sends a request to the authentication server, requesting “credentials” for a given application server. These credentials can be directly for an application server or for a Ticket Granting Server.

2. The authentication server responds with these credentials, encrypted in the client’s key.

The credentials consist of the following:

• A “ticket” for the server.
• A temporary encryption key (called a session key).

3. If the ticket is for a Ticket Granting Server, the client then requests a ticket for the application server from the Ticket Granting Server.

4. The Ticket Granting Server replies with a ticket for the application server.

5. The client transmits the ticket (which contains the client’s identity and a copy of the session key, all encrypted in the server’s key) to the application server.

6. The session key, now shared by the client and application server, is used to authenticate the client, and can be used to authenticate the server.

It also can be used to encrypt further communication between the two parties or to exchange a separate sub session key to encrypt further communication.

An implementation consists of one or more authentication servers running on physically secure hosts. Each authentication server maintains a database of principals (that is, users and servers) and their secret keys. Code libraries on the server provide encryption and implement the Kerberos protocol. Before a typical network can add authentication to its transactions, it adds calls to the Kerberos library, which results in the transmission of the necessary messages to achieve authentication.

A client can use two methods for asking a Kerberos server for credentials.

Client sends a cleartext request for a ticket for the desired function server to the function server. The reply is sent encrypted in the client’s secret key. Usually, this request is for a Ticket Granting Ticket that can be used later with the Ticket Granting Server.

Client sends a request to the Ticket Granting Server in the same manner as when contacting any other application server that requires Kerberos credentials. The reply is encrypted in the session key from the Ticket Granting Ticket.

After credentials are obtained, they can be used to establish the level of security the application requests:

• Verify the identity of the principals in a transaction
• Ensure the integrity of messages exchanged between them
• Preserve privacy of the messages
• The application can choose whatever level of protection it deems necessary. The level of security chosen for a particular transaction depends upon the security policy being implemented by the application.

To verify the identities of the principals in a transaction, the client transmits the ticket to the function server. The ticket is sent in cleartext (cleartext is readable by anyone who chooses to look at the message). Parts of it are encrypted, but this encryption doesn’t thwart replay. An attacker could intercept it and reuse it. So, additional information accompanies the message to prove it originated at the principal to whom the ticket was issued. This information, called an authenticator, is encrypted in the session key, and includes a timestamp. The timestamp proves that the message was generated recently and is not a replay. Encrypting the authenticator in the session key proves that a party possessing the session key generated it. Because no one except the requesting principal and the server know the session key (it never travels over the network in the clear), this guarantees the identity of the client.

The integrity of the messages exchanged between principals can be guaranteed using the session key. This approach provides detection both of replay attacks and message stream modification attacks, by generating and transmitting a collision-proof checksum called a hash or digest of the client’s message, keyed with the session key.

Privacy and integrity of the messages exchanged between principals can be secured by using the session key passed in the ticket and contained in the credentials to encrypt the data to be passed.

Authentication exchanges require read-only access to the Kerberos database. Sometimes the entries in the database must be modified, however, such as when adding new principals or changing a principal’s key. Modification of entries is done using a protocol between a client and a third Kerberos server, the Kerberos Administration Server. The administration protocol is not described here. Another protocol concerns maintaining multiple copies of the Kerberos database, but it’s an implementation detail and can vary to support different database technologies.