Kerberos White Paper

Figure 1: The Kerberos Authentication Protocol
Step 1. The user begins to use a Kerberized application by entering the user name and password.
Optionally, the user can request for specific ticket flags and specify the key type to be used for
constructing the secret key. The user can also accept the default, configured for the client.
The user sends the following information to the Authentication Service (AS) to obtain credentials:
• Client, Server, T, N; where
• Client indicates the user name, also referred to as the principal name
• Server indicates the Application Server
• T indicates the time stamp and
• N indicates nonce
Step 2. If the AS can decrypt the message successfully, it issues a temporary session key, which is
encrypted with the user’s secret key (a key derived from the user password, which is stored in the
KDC), and a TGT encrypted with the TGS’s secret key. The TGT contains the name of the user and a
copy of the session key (a randomly generated temporary encryption key) to be used by the user and
the Server for any subsequent communication.
Step 3. The user decrypts the session key. The TGT and the session key are stashed in the user’s
credential cache. The credentials are used to obtain tickets for each network service the principal
wants to access.
This protocol exchange has two important features:
• The authentication scheme does not require that the password be sent across the network,
either in encrypted form or in clear text.
• The client (or any other user) cannot view or modify the contents of the TGT.