Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

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.

...

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.

No Format
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.

...

Note that not all applications servers will handle this situation identically. Most application servers should still have a consistent correct value for UTC. However, there 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. However, there may be some operating systems which will assert an incorrect UTC value if they have not been updated with the new DST rules. This scenario should have very similar results to scenario 3 above. Please refer to the caveats in senario 3, above.