The overall design of the Kerberos authentication and authorization system relies on the fact that the system clocks are loosely synchronized (within a few minutes) on all machines that run Kerberos authenticated services. This "global time" is also available to all of the workstations that use Kerberos. A requirement by the Kerberos system is that each workstation maintains its clock within some allowable margin.

One major advantage of keeping loosely synchronized clocks lies within the details of the Kerberos mechanism. When the client obtains a ticket from Kerberos, it includes in its message the current time of day. One of the three parts of the response from Kerberos is a timestamp issued by the Kerberos server. If these timestamps weren't implemented, then another mechanism for checking replays of a message needs to be used, such as nonces. However, if the design was to enforce the use of nonces, then it would have to send more messages back and forth from the user and the server. This new mechanism would require many more connections on the network and imply that Kerberos keep a connection state. The use of the synchronized clocks keeps the property of statelessness within the design of the Kerberos protocol. Another advantage of having clocks as opposed to having another mechanism is that the clocks give security for the tickets issued by the Kerberos server. The tickets use a timestamp and expire after a certain amount of time has expired.

A glaring disadvantage of using the loosely synchronized clocks is the potential for replays of an authenticator to be sent to a service. The case may occur where somebody "sniffing" the net for valid authenticators finds one and re-sends the enciphered message, causing havoc for the client and the server. In the Kerberos paper, it claims that if an authenticator, when received by the service, contains a timestamp that is within the last few minutes, then "the authenticator is probably not a replay." (Section E.2.1, pg 8) However, if somebody gets a hold of the authenticator quickly after it is issued (which is not impossible), then with the correct timing, the message can be replayed. This is a highly undesirable property that can cause major problems. Another weakness in using clocks is the fact that the whole Kerberos system relies on one central time server. If this time server fails for any reason, then the entire Kerberos system will feel the effects of the failure.

Srikant Sarda