Request (AS-REQ)

First, the user makes a TGT (or identity card) request. This request is called AS-REQ. But to receive the TGT, they must be able to prove their identity. This request is made to the KDC (which is the Domain Controller in an Active Directory environment). The KDC holds all user keys.


To prove their identity, the user will send an authenticator. It’s the current timestamp that the user will encrypt with their key. The username is also sent in cleartext so the KDC can know whom it is dealing with.



Upon receiving this request, the KDC will retrieve the username, look for the associated key in its directory, and attempt to decrypt the authenticator. If it succeeds, it means that the user has used the same key as the one registered in its database, so they are authenticated. Otherwise, authentication fails.


This step, called pre-authentication, is not mandatory, but all accounts must do it by default. However, it should be noted that an administrator can disable pre-authentication. In this case, the client no longer needs to send an authenticator. The KDC will send the TGT no matter what happens.


Response (AS-REP)

The KDC, therefore, received the client's request for a TGT. If the KDC successfully decrypts the authenticator (or if pre-authentication is disabled for the client), it sends a response called AS-REP to the user.


To protect the rest of the exchanges, the KDC will generate a temporary session key before replying to the user. The client will use this key for further exchanges. The KDC avoids encrypting all information with the user's key. We stated earlier that Kerberos is a state-less protocol, so the KDC will not store this session key anywhere.


There are two elements that we will find in the AS-REP response:

  1. First, we are waiting for the TGT that the user requested. It contains all the user's information and is protected with the KDC's key, so the user can't tamper with it. It also contains a copy of the generated session key.
  2. Second is the session key, but this time protected with the user's key.



Therefore, this session key is duplicated in the response—one version is protected with the KDC's key, and another is protected with the user's key.