Kerberos authentication process

The below steps are cut-and-pasted from Wikipedia’s walk-through, but with language adapted to match the Windows-specific environment Kerberos is most commonly deployed in. (A close reading of these steps will also explain why it’s sometimes said that “a hash is as good as a password” for a Window’s domain.)

Client authentication to the KDC (a.k.a. “pre-authentication”)

1. AS-REQ: The client sends the client/user ID + the current timestamp (the timestamp is used to prevent replay attacks) encrypted with the NT hash of the user’s password + a cleartext message of the user ID to the authentication server to request services on behalf of the user.

2. AS-REP: The authentication server checks to see if the client/user ID is in its database and if it can decrypt the timestamp using the NT hash of the password stored there. If it can, then the authentication server sends back the following two messages to the client:

   • Message A: Client/TGS Session Key encrypted using the NT hash of the client/user.
   • Message B: Ticket Granting Ticket (including the privilege attribute certificate, client network address, ticket validity period, and the Client/TGS Session Key) encrypted using the KDC long term secret key.

3. Once the client receives messages A and B, it attempts to decrypt message A with the NT hash generated from the password entered by the user. If the user entered password does not match the password in the authentication service database then decryption of message A will fail. Once message A is decrypted, the client obtains the Client/TGS Session Key. This session key is used for further communications with the ticket granting service.

IMPORTANT

The client cannot decrypt Message B, as it is encrypted using the KDC long term secret key.)

Client service authorization

1. TGS-REQ: When requesting services, the client sends the following messages to the ticket granting service:

   • Message C: Composed of the ticket granting ticket and the service principal name of the requested service.
   • Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.

2. TGS-REP: Upon receiving messages C and D, the ticket granting service retrieves the ticket granting ticket out of message C and decrypts it using the KDC long term secret key. This gives it the Client/TGS Session Key and the client ID (the client ID is part of the privilege attribute certificate). Using the Client/TGS Session Key, the ticket granting service decrypts message D (Authenticator) and compares the client IDs from the ticket granting ticket and message D; if they match, the server sends the following two messages to the client:

   • Message E: Service ticket (which includes the privilege attribute certificate, client network address, validity period, and Client/Server Session Key) encrypted using the service’s long term secret key.
   • Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client service access

1. AP-REQ: Upon receiving messages E and F from ticket granting service, the client has enough information to authenticate itself to the service server. The client connects to the service server and sends the following two messages:

   • Message E: The service ticket (as provided by the ticket granting service; see above).
   • Message G: A new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.

2. AP-REP: The service server decrypts the service ticket (message E) using its long term secret key to retrieve the Client/Server Session Key. Using the sessions key, it then decrypts the Authenticator and compares client ID from the service ticket and message G. If they match the server sends the following message to the client to confirm its true identity and willingness to serve the client:

   • Message H: The timestamp found in client’s Authenticator (sometimes modified, depending upon the version of Kerberos being used), encrypted using the Client/Server Session Key.

3. The client decrypts the confirmation (message H) using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.

4. The server provides the requested services to the client.