[7499] in Kerberos
Re: implications of clock skew allowance
daemon@ATHENA.MIT.EDU (Dan Geer)
Tue Jun 18 11:33:11 1996
To: P-Pomes@qualcomm.com, sommerfeld@apollo.hp.com
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Mon, 17 Jun 1996 15:16:46 EDT."
<199606171916.AA078279007@relay.hp.com>
Date: Tue, 18 Jun 1996 11:11:18 -0400
From: Dan Geer <geer@OpenMarket.com>
> I requested a short lifetime ticket (kinit -l 5m) and found
> that it was good for twice as long as I thought due to the 5
> minute clock skew allowance. Since everything we use is NTP
> sync'ed, I think I'll cut this to 15 seconds. This has the
> added benefit of letting us know more quickly when NTP goes
> south.
Remember that the 5-minute fuzz has to cover for all other delays
between the calls to krb5_mk_req on the client and krb5_rd_req on the
server.
If you set it as short as 15 seconds, you might have difficulty with
slow networks (e.g., demand-dialed links) and/or overloaded servers.
Bill's points are well taken (as always).
I write only for historical interest: When clock sync issues
first arose in the design of Kerberos, many of the Athena
workstations did not have the ability to slew the system
clock (and so bring system-time gradually into conformance
with global-time). Therefore, only a jump-reset was possible
and these should, of course, never be done when the workstation
is (or just was or is just about to be) in use. Five minutes
seemed a pretty good guess at how much clock drift might occur
between moments when it would be safe to jump-reset time, worst
case (a SWAG, in other words).
For the contrary situation, viz., un-synchronizable clocks, see
http://www.usenix.org/publications/library/proceedings/security95/davis.html
--dan
