The KDC is further divided into an Authentication Server (AS) and a Ticket Granting Server (TGS). The responsibility of the AS is to authenticate the identity of entities in the network. Secure dialogues in a network are accomplished when the communicating parties share at least one secret that can be used to encrypt and decrypt the information they exchange. The Kerberos TGS is responsible for generating a unique session key to be shared between two parties. The parties then use this session key to encrypt their messages or to guarantee the integrity of messages sent. Both the TGS and the AS are combined into a single server in Kerberos. The distinction between the AS and the TGS is conceptual and based on the role being played by the Kerberos KDC server at any given time. Therefore, the term KDC sometimes will be used to jointly refer to both the AS and the TGS.

Third-Party Authentication Steps

Consider the high-level steps and requirements for authenticated and secure communications between two entities using Kerberos. Assume that X wants to communicate with Y in a network. X and Y could be users, software processes, or workstations. X contacts the KDC with a request for a secure session with Y. Because the KDC knows the secrets for both X and Y, and neither X nor Y knows the other’s secret, the KDC can rely on cryptography to fulfill the request.

1.  A random session key SK_x,y to be shared by X and Y is generated by the KDC.

2.  Several values are combined to form a ticket that is needed to prove X’s identity to Y and to deliver the shared secret securely to Y. The ticket includes SK_x,y, the principal name for X, and some other fields. Finally, the ticket is encrypted by the KDC with K_y, the secret key of Y, so that only Y can decrypt the result.

3.  SK_x,y and the ticket are encrypted by the KDC with K_x, the secret key of X, so that only X can decrypt the result. The encrypted ticket and session key are sent from the KDC back to X. Let the notation { SK_x,y}K_x represent the encryption of the session key with the secret key of X and the converse for Y.

4.  The KDC has sent SK_x,y and { SK_x,y}K_y encrypted with K_x to X, who decrypts the message to obtain the session key SK_x,y. Using the preceding notation, the message received by X is { SK_x,y and { SK_x,y}K_y}K_x.

5.  X sends { SK_x,y}K_y and the rest of the ticket encrypted with K_y to Y, who likewise decrypts this message to obtain the session key. In looking at the contents of the ticket, Y also deduces that this message could have been created only by the KDC, and that X is indeed legitimate. For example, part of the ticket, encrypted with K_y, contains the principal name X. When X sends the ticket to Y, the principal name X also is included as part of the message header. Y compares the value in the header with the decrypted value from the ticket to help verify the identify of X. Again, because the ticket was encrypted by the KDC using K_y, and only the KDC could have known this secret, Y can trust that the identity of X is authenticated by the KDC.

X and Y now share a secret SK_x,y which can be used for secure communications. Y knows that the session key received in the message from X must be valid because only the KDC, which shares K_y with Y, could have appropriately encrypted the ticket containing the session key. Notice how both X and Y must trust the KDC to authenticate each other. How did the KDC verify the identity of X in the first place?

Kerberos Login

Because the Kerberos KDC acts as an authentication server, it controls its own security domain or model. A user or entity that wants to communicate in the domain of Kerberos must first establish an identity with the Kerberos server. The Kerberos administrator adds names, passwords, and other information for each of the principals in the realm. Only the system administrator of the secure Kerberos server should be allowed to modify these entries. After a user is added as a principal in the database, login to the Kerberos environment is possible.

Assume that X is a user. The login process begins in the familiar fashion when the user sits down in front of a terminal displaying a login prompt. X enters a username that the login program captures. The login program klogin, in the role of Kerberos client, sends an authentication request containing the username and current timestamp to the KDC. The KDC and the login workstation could be the same system, but it’s more interesting to think of them as different nodes in the network. If the user enters an incorrect username, the KDC responds to klogin with an error.

If the user enters a correct username, the KDC sends to klogin a response message encrypted with K_x, the secret key of X. As you might suspect, K_x is a DES key derived from the user’s password and stored in the KDC database. At this point, the AS component of the KDC has fulfilled its role. That is, the KDC is not involved from this point forward in completing the authentication process. The program klogin assumes responsibility for completing authentication by asking X for a password and then converting the password into a DES key. The result will be equivalent to K_x if X entered the correct password. An attempt is made by klogin to decrypt the message received from the KDC using the hashed value computed from the password. If the decryption is successful, X has been authenticated and can proceed to use the system. Note that the password itself is never sent in the clear over the network to the KDC.