On Thu, 20 Sep 2007 14:41:16 -0500 "Brandon Galbraith" <[EMAIL PROTECTED]> wrote:
> On 9/20/07, James R. Cutler <[EMAIL PROTECTED]> wrote: > > > > Kerberos does not assume clock synchronization. > > Kerberos requires reasonable clock synchronization. > > And, as near as I can tell, clock synchronization is not part of the > > Kerberos protocol. > > > > Kick me if I err in this. > > > > Cutler > > > > http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Kerberos_drawbacks<http://en.wikipedia.org/wiki/Kerberos_%2528protocol%2529#Kerberos_drawbacks> > > "Kerberos requires the clocks of the involved hosts to be > synchronized. The tickets have time availability period and, if the > host clock is not synchronized with the clock of Kerberos server, the > authentication will fail. The default configuration requires that > clock times are no more than 10 minutes apart. In practice, > NTP<http://en.wikipedia.org/wiki/Network_Time_Protocol>daemons are > usually employed to keep the host clocks synchronized." That's correct, though I believe some versions use an offset hack. The initial exchange with the Kerberos server is strongly authenticated. It's used to issue a ticket-granting ticket; replay of TGTs (and service tickets obtained via TGTs) partially relies on synchronized clocks. The offset hack has the Kerberos server -- a universally trusted party -- note and seal in the tickets -- the client's time offset from KDC reality. Any services that accept the tickets can use this value to correct for clock skew. --Steve Bellovin, http://www.cs.columbia.edu/~smb