Kerberos uses timestamps so that the authenticator is unique. Authenticators are valid for only one use to minimize the possibility of someone attempting to use someone else’s identity. Replay, which is an attempt to reuse the authenticator, cannot be accomplished in Kerberos v5. However, mutual authentication can occur when the recipient of the authenticator extracts a portion of the original authenticator, encrypts it in a new authenticator, and sends it to the originator of the first authenticator. A portion of the original authenticator is extracted to prove that the original authenticator was successfully decrypted. If the entire original authenticator were sent back unchanged, then the originator would not know whether the intended recipient or an impersonator sent it.
Table 3.1 shows the contents of the authenticator fields.
Table 3.1 Authenticator Field Contents
Name of Field
Contents of Field
Authenticator Version Number 5
Client Realm
The name of the client’s realm
Client Name
The name of the client
Checksum
The checksum of data in message authenticator
http://corpitk.earthweb.com/reference/pro/1928994024/ch03/03-02.html (1 of 3) [8/3/2000 6:51:42 AM]
Configuring Windows 2000 Server Security:Kerberos Server Authentication CUSEC
The millisecond portion of the client’s time
Client time
The time on the client
Subkey
Key that specifies an alternate key to use instead of the session key
Sequence Number
Optional and application–specific number
Authorization data
Optional field used to include authorization data for specific applications
Key Distribution Center
Just as the Kerberos in Greek mythology had three heads, in technology Kerberos also has three parts. The Kerberos authentication protocol has a client, a server, and a trusted authority. The Key Distribution Server (KDC), the trusted authority used in Kerberos, maintains a database with all account information for principals in the Kerberos realm. A principal is a uniquely named entity that participates in network communication, and a realm is an organization that has a Kerberos server. Since the system running the KDC
service contains the database with security account information, it needs to be physically secure. A portion of this security information is the secret key that is shared between a principal and the KDC. Each principal has its own secret key, and it has a long lifetime, which is why this key is also known as the long-term key.
When the long-term key is based upon a human user’s principal, it is derived from the user’s password. This long-term key is symmetric in nature.
Another key used with the KDC is the session key, which is issued by the KDC when one principal wants to communicate with another principal. For example, if a client wants to communicate with a server, the client sends the request to the KDC, and the KDC in turn issues a session key so that the client and server can authenticate with each other. Each portion of the session key is encrypted in the respective portion of the long-term key for both the client and server. In other words, the client’s long-term key includes the client’s copy of the session key, and the server’s long-term key includes the server’s copy of the session key. The session key has a limited lifetime that is good for a single login session. After the login session is terminated, the session key is no longer valid. The next time the same client needs to contact the same server, it will have to go to the KDC for a new session key.
Session Tickets
The client receives an encrypted message from the KDC that contains both the client and server copies of the session key, as shown in Figure 3.1. The server’s copy of the session key is contained in a session ticket, which also contains information about the client and is encrypted with the shared secret of the server and KDC. The client cannot access the session ticket because it does not know the shared secret key the server and KDC share.
Figure 3.1 The client requests a ticket to communicate with the server.