Kerberos is often called a third party trusted authentication service, which means all its clients trust Kerberos's judgment of another client's identity. Kerberos keeps a database of all its users and their private keys.
To ensure Kerberos is worth all the trust put in it, run both the authentication and ticket-granting server on a dedicated machine. Make sure that only the administrator can access this machine physically and over the network. Reduce the (networking) services run on it to the absolute minimum—do not even run sshd.
Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your username. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If the authentication server knows about your existence, it generates a random session key for further use between your client and the ticket-granting server. Now the authentication server prepares a ticket for the ticket-granting server. The ticket contains the following information—all encrypted with a session key only the authentication server and the ticket-granting server know:
The names both of the client and the ticket-granting server
The current time
A lifetime assigned to this ticket
The client's IP address
The newly-generated session key
This ticket is then sent back to the client together with the session
key, again in encrypted form, but this time the private key of the client
is used. This private key is only known to Kerberos and the client, because
it is derived from your user password. Now that the client has received
this response, you are prompted for your password. This password is
converted into the key that can decrypt the package sent by the
authentication server. The package is unwrapped
and password
and key are erased from the workstation's memory. As long as the lifetime
given to the ticket used to obtain other tickets does not expire, your
workstation can prove your identity.
To request a service from any server in the network, the client application needs to prove its identity to the server. Therefore, the application generates an authenticator. An authenticator consists of the following components:
The client's principal
The client's IP address
The current time
A checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for this special server. The authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the authenticator, which gives it all information needed about the client requesting its service to compare it to that contained in the ticket. The server checks if the ticket and the authenticator originate from the same client.
Without any security measures implemented on the server side, this stage of the process would be an ideal target for replay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server does not accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too much from the time the request is received is ignored.
Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends some kind of authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key, which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start cooperating.
Tickets are designed to be used for one server at a time. This
implies that you have to get a new ticket each time you request another
service. Kerberos implements a mechanism to obtain tickets for individual
servers. This service is called the ticket-granting service
.
The ticket-granting service is a service just like any other service
mentioned before, so uses the same access protocols that have already been
outlined. Any time an application needs a ticket that has not already been
requested, it contacts the ticket-granting server. This request consists of
the following components:
The requested principal
The ticket-granting ticket
An authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they are considered valid, the ticket-granting server builds a new session key to be used between the original client and the new server. Then the ticket for the new server is built, containing the following information:
The client's principal
The server's principal
The current time
The client's IP address
The newly-generated session key
The new ticket is assigned a lifetime, which is the lesser of the remaining lifetime of the ticket-granting ticket and the default for the service. The client receives this ticket and the session key, which are sent by the ticket-granting service, but this time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket for the client without bothering the user more than once at login time.
Windows 2000 contains a Microsoft implementation of Kerberos 5. Because openSUSE® uses the MIT implementation of Kerberos 5, find useful information and guidance in the MIT documentation. See Section 38.4, For More Information.