Subject: clock sync in draft-ietf-krb-wg-kerberos-clarifications-03.txt

From: "Joel N. Weber II" <[email-masked]>
Date: Sat, 17 May 2003 18:08:31 -0400

One of the things I noticed doing a search for the word ``clock'' in
draft-ietf-krb-wg-kerberos-clarifications-03.txt is that it seems like
there is some text which is roughly the same in both the security
considerations section and in earlier portions of the document.  That
sort of duplication strikes me as non-ideal.

For example, section 1.5 and section 10 both contain the identical
sentence ``If the clocks are synchronized over the network, the clock
synchronization protocol MUST itself be secured from network
attackers.'', except that section 1.5 capitalizes the MUST, and
section 10 does not.  Is there a good reason for the inconsistent
capitalization, or does this imply someone did some editing without
checking whether the same issue was also discussed elsewhere in the
document?

A discussion of the sorts of attacks that would be possible with
insecure NTP would be useful.  There are limits on how much drift the
standard unix NTP software will accept before it simply shuts down,
and I would like to see a description of an attack that could be
carried out within the limits of what the NTP software allows if
insecure NTP were used for clock sync.  I would also like to see an
analysis of whether configuring the NTP software to reduce the
tolerable amount of skew between the hardware clock and the network
time would tighten things up to a point where the use of insecure NTP
would be acceptable.  I would also hope that the description would
make it obvious why insecure NTP is a bigger problem than cheap PC
clocks that run at the wrong rate (possibly off by only .1% from the
correct rate) and occasionally reset to correct time; without seeing a
clear example of what problem is being solved, I find it a bit
difficult to judge that.

It bothers me that the document does not make any comments about the
vulnerabilities present in syncronizing a clock from a radio source,
such as GPS or WWV.  These systems do not use any cryptographic
authentication (and given their one way nature, there's probably
little that can be done to prevent the replay of transmissions after a
delay), and due to the large distance between the transmitter and
reciever, it is probably not difficult for a nearby transmitter to
provide a signal which appears stronger at the reciever than the
official government-run time source, especially if the rouge
transmitter uses a high-gain antenna.

While it is probably much easier to launch an attack against network
time than against a radio reciever from the other side of the planet,
someone who can get reasonable physical proximity to a radio reciever
can induce clock skew, and it is probably worthwhile to include a
warning about the problems that can occur if different hosts in a
realm synchronize to different radio recievers, or if different realms
synchronize to different radio recievers and cross-realm Kerberos is
used.

Also, a discussion of the implications of a denial of service attack
shutting down network time synchronization might be valuable.  For a
while I was running a kdc which kept correct time only as a result of
running NTP, and eventually its hardware clock drifted to a point
where its rate was off by a factor of two, at which point the NTP
software refused to correct for the error in the clock, and I replaced
the clock chip.  Would I have had a significant security hole on this
machine if I'd been running secure NTP and suddenly I lost external
clock sync and the clock started advancing at a rate that was 33%
faster or slower than real time while it continued to process kdc
requests?