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.
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
