1.1.6 - AS (Authentication Server)

One of the two server components of a Kerberos server is the Authentication Server, which authenticates clients, and issues tickets (TGT, or Ticket Granting Ticket) that the user can send to the TGS to get a service ticket.

The TGT, or Ticket Granting Ticket, is a ticket that a client can use to get a service ticket. In fact, the authentication server considers the TGS as just another service, and generates a ticket for the user to access this service.

The beauty of the AS is that it does not verify that the client issuing a request is a valid client : it just returns a tickat that an attacker won’t be able to process if he does not have the client’s password.

Exhanges between the client and the AS

As we can see, for the client to get a TGT, it’s just a matter of sending a simple request, which is sent without any encryption whatsoever (some might consider that a BER encoded message is already cryptic enough, though ;-).

Here is the standard exchange :

Kerberos Authentication with no pre-auth

There is still a potential security breach in this scenario : as the server issues a TGT to the client, containing the secret key built using the user’s password, it is possible to decrypt the ticket using a brute force attack (and this is more likely to happen if the password is weak…)

Of course, as each ticket has a limited life time, the ticket won’t be valid when the attaker successfully cracked the ticket, but that doesn’t matter : the user’s password is now known, and a new ticket can be requested safely, giving access to the services.

Kerberos 5 introduced a mechanism to workaround this issue : the user has to provide a proof that he is who he pretends to be. As we can see, it defeats the premise we made : the Kerberos still wants to check the users…

Note that it’s an option, so if you trust your users’ password strength, then you don’t need to send the server this proof.

Pre-Authentication

Now, let’s see how does a client ‘proves’ that he is who he pretends to be. The protocol allows the server to ask for some proof, by the means of asking the client to send the server a timestamp encrypted with the user’s secret key : if the server can decrypt the timestamp using the client’s secret key, then that proves the client’s identity, and now the server can send the TGT. This exchange is called PreAuthentication.

Here is the exchange, when :

Kerberos Authentication with pre-auth