regarding clock skew difference between client and KDC

[Danny Mayer]

Jeffrey Altman wrote:
> Danny Mayer wrote:
>>
>> Please understand the answer that I gave you above. You cannot
>> authenticate a client who's UTC time is different by more than 5 minutes
>> from the KDC's UTC time. Anything else would be a protocol and a
>> security violation.
> Danny:
> 
> This is incorrect.   RFCs dictate implementation requirements, not
> deployment requirements. 
> It is perfectly reasonable for clock skew to be tolerated with a greater
> time period provided
> that the administrators of the systems know to maintain a replay cache
> for the longer time
> period.  During the recent daylight savings time adjustment period, it
> was advised that
> organizations increase the permitted clock skew by an extra 60 minutes
> in order to prevent
> clients that did not have updated DST tables from failing to be able to
> authenticate.
> 

That is a risky strategy and I wouldn't recommend this to anyone though
I understand the realities of this having been bombarded with questions
about time zones back in March and April. There are ways of updating the
zone tables even for Windows 2000 and NT 4.0 even without Microsoft's
support.

> It is crucial is that the KDC and Kerberized services have their clock
> synchronized.  However,
> it is possible for clients to have their clocks off by a period greater
> than the permitted clock
> skew.  The clients can determine from the ticket issued by the KDC what
> the skew is and
> use that information to perform clock adjustments for future protocol
> exchanges. 
> 
> This approach is implemented in MIT Kerberos on MacOS X.  It is not
> implemented on
> Windows because the credential cache implementations on Windows do not
> support
> it.
> 

It's better to change the skew so this is not an issue.

Danny
> Jeffrey Altman
> Secure Endpoints Inc.
>