Of special importance in Kerberos Version 4 is the protocol requesting the user’s password. This step is not initiated until after klogin receives the first response from the KDC. When the user enters an invalid username, the KDC responds with an error to klogin. When the user enters a correct username, the KDC responds with a message encrypted with the secret key of the user. Only after this response is received will klogin prompt for the password. Kerberos V4 introduces this delay in retrieving the password in an attempt to limit the amount of time the password string is kept in memory. This approach is laudable because storing a password in memory even for a short time might enable a concurrently running rogue program an opportunity for password theft. However, as you will see, this protocol also opens Kerberos V4 to password guessing attacks.

A More Detailed Analysis of klogin

The login scenario described previously is actually more complex than the overview indicates. In this section, you learn additional details about the messages exchanged in Kerberos.

Recall that the TGS is the part of the Kerberos server responsible for generating shared session keys. The TGS is itself a secure Kerberos server, named krbtgt, which shares a secret with the KDC. Anytime X wants to initiate a secure conversation with another entity in the network, X must contact the TGS and ask for a new session key and ticket. In order to communicate with the TGS, X must establish trust with the TGS by completing the login process. The TGS is the only place where a principal can obtain a session key, and the only way to gain the right to request a session key from the TGS is by logging in to the KDC. Remember, too, that the TGS is just a special part of the KDC. So, when you read that a message is exchanged with the TGS, it is really the KDC that receives all of the messages for the Kerberos server. Here are the login steps assuming again that X is the user attempting to authenticate to Kerberos.

1.  X enters the username X in response to the login prompt. For simplicity, assume that the Kerberos principal name for X is the string X.

2.  klogin sends an authentication request to the KDC. The message is not encrypted. Fields in the message include the current timestamp on the login workstation, the principal’s username X, and the name of the principal service with which klogin wants to communicate. The service name is krbtgt, and this string value is included in the message. This process will be important later when you learn about one attack against Kerberos.

3.  The KDC verifies that X exists in the database and obtains K_x, the secret key for X. A reply message is encrypted with K_x and returned to klogin. The encrypted message contains the principal name X, the server name krbtgt, the original timestamp sent in the request from klogin, and some other fields that enable X to verify that the response came from the KDC. The encrypted message sent by the KDC also contains a session key SK_x,tgs and a ticket granting ticket (TGT). The session key SK_x,tgs is used by X to securely communicate with the TGS.

The klogin program obtains the password from X as before and attempts to decrypt the message received from the KDC. One of the indicators for successful decryption is when the name of the requested service sent back by the KDC matches the string krbtgt. If decryption is accomplished, login is complete, and the user X now starts communicating with other principals.

A More Detailed Look at a Session

At some point in the future, X will want to talk to another principal such as Y. The TGT plays an important role in this process. Normally, when two principals exchange a ticket, the lifetime of the ticket is very short to prevent replay attacks. If the ticket’s lifetime is too long, an attacker might be able to use the ticket at a future time, impersonate one of the principals, and trick the other principal into divulging information. Therefore, tickets normally expire within a few seconds, although the limit is configurable by the Kerberos administrator. On the other hand, the TGT has a longer lifetime because a principal needs to reuse it each time a new session key is needed. When a TGT is renewed or when a new TGT is obtained , the user must complete the I&A process again with the Kerberos server. This process requires reentry of the password. Most sites limit the TGT lifetime to eight hours or less for a login user.

When login is complete, a principal has both SK_x,tgs and the TGT. At a minimum, the TGT contains the value {SK_x,tgs}K_tgs, or the session key for use between the TGS and X encrypted with the secret key of the TGS. All of this information was obtained from the KDC. What happens when X wants to communicate with Y?

1.  X sends a request to the TGS asking for a session key to communicate with the principal Y. The message that X sends contains several fields. First, it contains the TGT that can be decrypted by the TGS using K_tgs to obtain the shared session key SK_x,tgs. The message also includes information, such as the principal name of Y, encrypted with SK_x,tgs. When the TGS gets the shared session from the TGT, it can decrypt this additional information.

2.  The TGS generates a new random session key, SK_x,y, to be shared between X and Y for their session. The TGS asks the KDC to use K_y to encrypt this new session key SK_x,y and some other values into a ticket T_y. The TGS then returns to X the new session key and the ticket T_y encrypted with SK_x,tgs. To be clear, SK_x,tgs is the session key for secure exchanges between X and the TGS. SK_x,y is the session key to be used for secure exchanges between X and Y.