regarding clock skew difference between client and KDC

[Jeffrey Altman]

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.

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.

Jeffrey Altman
Secure Endpoints Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20070904/7ca263ad/attachment.bin