Audience:
System administrators responsible for KDCs and and application servers which are secured using Kerberos.
End users should not need to take any actions specific to Kerberos for this issue.
MIT users may also be interested in IS&T's summary page regarding 2007 Daylight Saving Time Changes.
Kerberos and the 2007 changes to Daylight Saving Time (DST) rules:
The year 2007 brings with it a change in Daylight Saving Time (DST) rules. A provision of the Energy Policy Act of 2005 changed DST to begin three weeks earlier and end one week later, effective in 2007. Starting this year, DST will begin the second week of March and end the first week in November (March 11 and November 4 in 2007). This is the first modification to the DST rules in the United States in 20 years. Other areas that follow US DST rules, including Canada and Bermuda but not Mexico, are similarly affected.
This document outlines the impact of the DST change on computer systems using Kerberos authentication.
The MIT Kerberos distribution is only one of several Kerberos implementations, although the Kerberos implementations that come with many operating systems are derived from the MIT distribution.
There are no Kerberos specific patches that are needed as a result of the new DST rules.
The Kerberos protocol does use time stamps and requires some level of time synchronization between the client, applications servers, and KDC. All time stamps used by the protocol are expressed in UTC.
Under what circumstances will the client computer use the KDC's clock value or the application server's clock value?
On current Windows operating systems the default configuration will correct for an out of sync clock on the client by default as described in step 3 of the KRB_AP_REQ and KRB_AP_REP Kerberos exchanges below.
On current implementations derived from the MIT or Heimdal implementations the krb5.conf file can be used to control the behavior. This is described in the Kerberos FAQ at http://www.faqs.org/faqs/kerberos-faq/general/section-38.html. However, please note that the kdc_timesync option will not affect the current shipping versions of Kerberos for Macintosh (KFM) nor Kerberos for Windows (KFW) when using the CCAPI caches. Nor is it support on KFW when using the MSLSA cache type.
[libdefaults] kdc_timesync
Setting this variable to 1 enables Kerberos clients to automatically correct for a difference between the local clock and the clock used by the KDC. Note that you will need to set ccache_type to a value of 4 to use this feature.
An Explanation of how the Kerberos time stamps are generated when the clocks of the client computers are not well synchronized with that of the KDC:
Let's look at what really happens during a KRB_AP_REQ and KRB_AP_REP Kerberos exchange:
1. A client uses the session key it received from the KDC to encrypt its authenticator. The authenticator is sent out to an application server together with the ticket.
2. The application server compares the timestamp in the authenticator with its local time. If the time difference is within the allowed time skew, it goes to step (4). By default, the maximum allowed time skew is 5 minutes---this setting can be typically be configured by a variety of mechanisms in the various Kerberos implementations. In Windows AD environments a domain wide GPO is typically used.
3. If step (2) failed, and the systems are configured to enable this option, the application server sends its local current time to the client. The client then sends a new authenticator using the new timestamp it received from the application server.
4. The application server compares the timestamp it received from the client with the entries in its "replay cache" (this is a list of recently received timestamps). If it finds a match, the client's authentication request will fail. If no match is found, client authentication has succeeded, and the application server will add the timestamp to its replay cache.
Please note that the KDC's clock and the application servers' clocks still need to be synchronized within the limits imposed by the allowable clock skew. It is strongly recommended that the KDC and application servers use NTP to ensure their clocks are synchronized.
How to increase to allowable time skew from 5 min to 1 hr and 5 min
In order to prevent intruders from resetting their system clocks in order to continue to use expired tickets, Kerberos V5 is set up to reject ticket requests from any host whose clock is not within the specified maximum clock skew of the KDC (as specified in the kdc.conf file). Similarly, hosts are configured to reject responses from any KDC whose clock is not within the specified maximum clock skew of the host (as specified in the krb5.conf file). The default value for maximum clock skew is 300 seconds, or five minutes. One possible way of avoiding any Kerberos related problems as a result of the DST rule changes is to change the allowable clock skew from 5 minutes to 1 hour and 5 minutes. It is important to understand that this does have security implications. This document is not recommending that any site necessarily use this approach.
krb5.conf and kdc.conf
[libdefaults]
clockskew = 3900
Sets the maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid. The default value is 300 seconds, or five minutes.
On a Windows Domain Controller a similar change in behvaior can be made by changing the policy setting labeled "Maximum tolerance for computer clock synchronization".
The following deployment scenarios describe the expected effect of the DST rules changes on environments using Kerberos.
Scenario 1: All of the computer operating systems using Kerberos have been patched with updates to the DST rules.
In this scenario Kerberos authentication will be unaffected and authentication operations should work as expected.
Scenario 2: None of the computer operating systems using Kerberos have been patched with updates to the DST rules.
In this scenario Kerberos authentication will be unaffected and authentication operations should work as expected. However, timestamps in system logs files may not be correct and applications which parse or display the logs may yield inconsistent results.
Scenario 3: The Kerberos KDCs have been patched with updates to the DST rules but the client computers and application servers have been inconsistently patched.
Assuming that all clients are configured to use the kdc_timesync option or its equivalent, Kerberos authentication should be largely unaffected and authentication operations should work as expected. Timestamps in system logs files may not be correct and applications which parse or display the logs may yield inconsistent results.
Note that not all applications servers will handle this situation identically. Most application servers should still have a consistent correct value for UTC. There may be some operating systems which will assert an incorrect UTC value if they have not been updated with the new DST rules. Note that this will include platforms where the hardware clock references local time, in other words many Windows and Linux systems are likely to be affected.
Scenario 3: Many of the client computers and application servers operating systems have been patched with updates to the DST rules but the Kerberos KDCs have not been updated.
Most operating systems which are likely to host a KDC should still have a consistent, correct value for UTC. This scenario should have very similar results to scenario 3 above. Please refer to the caveats in senario 3, above.