The authenticator within Kerberos provides a requested service to the client after validating which of the following?

The authenticator within Kerberos provides a requested service to the client after validating which of the following?
A .  timestamp
B .  client public key
C .  client private key
D .  server public key

View Answer

Answer: A

Explanation:

The server also checks the authenticator and, if that timestamp is valid, it provides the requested service to the client.

Even if the user principal is present in a ticket and only the application server can extract and possibly manage such information (since the ticket is encrypted with the secret key of the service), this is not enough to guarantee the authenticity of the client.

An impostor could capture (remember the hypothesis of an open and insecure network) the ticket when it is sent by a legitimate client to the application server, and at an opportune time, send it to illegitimately obtain the service.

On the other hand, including the IP addresses of the machine from where it is possible to use it is not very useful: it is known that in an open and insecure network addresses are easily falsified. To solve the problem, one has to exploit the fact that the client and server, at least during a session have the session key in common that only they know (also the KDC knows it since it generated it, but it is trusted by definition!!!).

Thus the following strategy is applied: along with the request containing the ticket, the client adds another packet (the authenticator) where the user principal and time stamp (its at that time) are included and encrypts it with the session key; the server which must offer the service, upon receiving this request, unpacks the first ticket, extracts the session key and, if the user is actually who he/she says, the server is able to unencrypt the authenticator extracting the timestamp.

If the latter differs from the server time by less than 2 minutes (but the tolerance can be configured) then the authentication is successful. This underlines the criticality of synchronization between machines belonging to the same realm.

The Replay Attack A replay attack occurs when an intruder steals the packet and presents it to the service as if the intruder were the user. The user’s credentials are there — everything needed to access a resource.

This is mitigated by the features of the "Authenticator," which is illustrated in the picture below.

The Authenticator is created for the AS_REQ or the TGS_REQ and sends additional data, such as an encrypted IP list, the client’s timestamp and the ticket lifetime. If a packet is replayed, the timestamp is checked. If the timestamp is earlier or the same as a previous authenticator, the packet is rejected because it’s a replay. In addition, the time stamp in the Authenticator is compared to the server time. It must be within five minutes (by default in Windows). Kerberos Authenticator to prevent replay attacks

The Authenticator mitigates the Possibility of a replay attack.

If the time skew is greater than five minutes the packet is rejected. This limits the number of possible replay attacks. While it is technically possible to steal the packet and present it to the server before the valid packet gets there, it is very difficult to do.

It’s fairly well known that all computers in a Windows domain must have system times within five minutes of each other. This is due to the Kerberos requirement.

Reference(s) used for this question: Redmond Magazine and http://kerberos.org/software/tutorial.html and KRUTZ, Ronald L. & VINES, Russel D., The CISSP Prep Guide: Mastering the Ten Domains of Computer Security, 2001, John Wiley & Sons, Page 42