The Network Time Protocol is getting a facelift that improves security and accuracy
by Rik Farrow <rik@spirit.com>
It seems that while every computer has a clock, none of them appear
to be synchronized. That is, unless the computer in question is
running NTP, the Network Time Protocol. With NTP, you can synchronize
against truly accurate time sources,
such as the atomic clocks run by NIST (the US National Institute of
Standards), the US Naval Observatory, or counterparts in other countries
around the world. And what does accurate timekeeping have to do with
security? It turns out that keeping a consistant sense of time is
critical for many security-related activities.
Financial organizations rely on accurate timekeeping for their transactions. Many authentication systems, with Kerberos being the most prominent example, use dated tickets to control access to systems and resources. And investigating incidents involving multiple computers is made much easier when the timestamps on files and in logs all were made using the same exact time.
NTP started out as a tool that permitted researchers to synchronize the workstation clocks to within milleseconds or better. As the Internet grew, the mechanisms that allowed NTP clients and servers to exchange time data securely has gone from sufficiently secure to not quite nearly good enough. A new version, NTP v4, seeks to fix all that while providing a model for automatic configuration and key exhange. Let's take a look at time synchronization systems and how they can securely be used to set all your clocks accurately.
First off, why bother having really accurate clocks? Isn't the one that comes in your desktop PC or your Sun Enterprise server good enough? Sun servers certainly cost enough to have an accurate clock. The answer is that accurate timekeeping is an advanced science, an avocation practiced by hundreds of scientists around the world, and the paltry clock chip you have in your PC or even the expensive server winds up being a bit less accurate than your Nike Swatch for several reasons.
Computer clocks, like most electronic clocks, detect the oscillations of a quartz crystal, and calculate the passing time based on these oscillations. The quartz crystals are not all the same to start with, but put one inside of a nice, hot computer that is also cool whenever it is turned off, and you have a crystal whose frequency tends to wander. Also, UNIX systems base their notion of time on interrupts generated by the hardware clock. Delays in processing these interrupts cause UNIX systems clocks to lose time--slowly but erratically. These small changes in timekeeping is what the time scientist call jitter.
Over time, scientists and programmers have developed different techniques for synchronizing clocks over TCP/IP or other network protocols. The Time protocol provided a server's notion of time in a machine readable format, and there is also an ICMP Timestamp message. The UNIX 'r' commands included <code>rdate</code>, which permitted the setting of a local clock based on a remote server. There are modem-based programs that contact NIST timeservers and fetch a time message (along with an estimate of roundtrip time to account for latency), that you can still use today (see Resources).
But the king of timesetting software has been NTP. David Mills of the University of Delaware has been working with the problems surrounding accurate timekeeping in laboratories. He wrote the first RFC (958) about NTP in 1985, and has authored all subsequent versions of RFCs relating to NTP. The most recent version, three, is detailed in RFC 1305, and is the version most UNIX systems use today. Mills has written a draft document for version 4 that includes important improvements in self-configuration of clients and security, as well as RFC 2030 for Simple Network Time Protocol (SNTP), an NTP workalike without all the features required to act as a peer.
A peer? No, not Brittish nobility, but an NTP server that functions at the same level as another server. NTP servers are arranged in hierarchies, with the top of the hierarchy called stratum one. Stratum one servers always act as the absolute source of time for the hierarchy below them. You could certainly choose to use an old Sparcstation IPC as your stratum one server, and it would work quite well with a simple addition--a device designed to collect a time signal from an authoritative source. The NTP software includes drivers for a large number of devices--radios that listen to time signals, such as WWV, GPS receivers, and even atomic clocks--that serve as references for stratum one servers. The University of Delaware site includes lists of stratum one servers in the US, and you can find stratum one servers for many other countries by using Web search engines.
Below stratum one servers, there will be many stratum two servers, and stratum three below that, and so on. NTP supports up to fifteen different stratums, but being nearer to the top implies being closer to the msot accurate source of time. In order to improve each server's notion of time, servers in the same stratum may peer, that is, act as equals, and perform the same timestamp exchanges done by NTP clients. NTP servers and clients do not blindly accept another system's notion of time, even if it comes from a higher stratum. And that was for a while NTP's only security provision.
Just accepting another system's statement about the current time can be harmful. Suppose the timekeeping system has been taken over by an attacker who needs to "turn back the clock" so that a replay attack can function. NTP guards against this in several ways.
First, NTP assumes that time move forward, not backward, although small backward changes are acceptable. Also, if a system has been using NTP, the NTP software assumes that changes in local clock will be small, generally less than a second. This makes controlling a local clock and making large changes literally a time consuming process, as even a one second change is a big deal.
NTP goes much further than this by collecting timestamps from many different servers (and peers if appropriate). NTP maintains a queue of generally eight samples, and uses carefully crafted alogrithms to compute what is the best approximation of exact time. For example, the outlyers in the sample (the timestamps with the largest divergence) are discarded. The rest of the set of samples is then used to calculate what the local clock should read. On UNIX systems, a special system call, </code>adjtime()</code>, is used to make small adjustments to system time. By using multiple sources, the influence of a single, compromised timeserver (a falseticker in NTP jargon) is completely avoided. You can modify the configuration of <code>ntpd</code> on the fly to label a timeserver as untrusted. You can also use configuration to list trusted timeservers and peers.
By the late 80's, version two had been released. NTP v2 included digital signatures based on a shared secret key, so that servers and peers could sign NTP data, preventing an attacker from spoofing packets. NTP uses UDP packets (on port 123), and UDP packets are very easy to spoof because of their stateless nature (no connection setup as in TCP).
But, Matt Bishop, then an assistant professor at Dartmouth (now at UC Davis) wrote an assessment of NTPv2 resistance to attacks. Among other things, Bishop noticed that the digital signature scheme in version two could easily be thwarted because a critical component, the keyid, was not itself signed, and replacing that value with zero disabled the signature checking. Version 3 of NTP continues to use the old, broken, signature mechanism for backward compatibility.
In April of this year, Przemyslaw Frasunek published an exploit for BSD and Linux systems of a buffer overflow in NTP v3. If you are using a version of ntpd that predates April 2001 on a UNIX system, you should replace it now.
Version four of NTP is (most likely) still an Internet Draft. Working verions of NTP v4 are under test, and version 4 may have entered the IETF standards track by the time you get to read this article. Mills, with the help and feedback of many others, has worked to create a version of NTP more suitable for modern networks, which include too many client systems to easily manage, as well as mobile devices.
From my perspective, the most interesting aspects of version four have to do with improvements to security. Mills has created a system he calls autokey, that uses public key algorithms combined with a list of one-way hashes. When a client contacts an NTP server, the client can collect a certificate containing the server's public key, and independently verify the certificate. Then, using the enclosed public key, the client can check the signature sent by the server that contains a list of keyids. The keyids are used with session keys to perform a quick digital signature check based on MD5, and solves the problem pointed out by Bishop.
In his recent papers, Mills points out the using public key cryptography for signing timestamps is just too slow. Public key encryption algorithms are not only slow (compared to private key algorithms like RC4), they are also inconsistent, in that the amount of time used to encrypt may vary by a factor of two, something very unpleasant for those obsessed with keeping accurate time. The use of the list of keyids reduces the need to use public key encryption to once an hour on the average.
Version four also supports Diffie-Hellman key exchange for peers, so that peers can exchange private session keys. And multicast updates of clients is also supported, and uses the client/server autokey for setting up security.
Should you be using NTP for security reasons? Really, the better question is why aren't you using NTP now? SNTP clients are easy to set up and install. And you can set up your own stratum one servers, slaving them to accurate time sources.
For example, WWV broadcasts time signals over short wave, so this
information is available worldwide. You can buy special radios that
interpret these signals and
send them out on serial (and even parallel) cables to the computers
that will serve as your top stratum. The Canadian Bureau of
Standards uses a Pentium system with a 90 MHz processor as one of
its servers, as running NTP and providing timestamps really does
not require a fast processor or loads of memory, and just a tiny hard
drive to hold the software and OS.
You can also use GPS devices. GPS relies on accurate timekeeping for calculating position and movement, and GPS devices are actually pretty inexpensive, although you will want to buy ones that already have drivers written for them. And remember to have multiple sources. Note that most Cisco routers and switches come with NTP software, and are ready to be used as NTP servers (you should disable this service if you are not using it).
Keeping all your systems sync'd to accurate time is not a luxury. Good timekeeping is important to many security functions, such as electronic transactions, certain authentication systems, and, in particular, any forensics activity you might ever be required to do. If you find yourself comparing logs from disparate systems, you will be exceedingly grateful that you decided to implement NTP.
Network time clients and servers for many operating systems: http://www.ntp.org/
NTP online documentation with links for further info: http://www.ntp.org/ and http://www.eecis.udel.edu/~mills/ntp/html/index.html
Also, US Naval Observatory site with similar docs: http://tycho.usno.navy.mil/NTP/Version4/
CIAC bulletin about the April 2001 vulnerability in NTPD for certain UNIX systems: http://www.ciac.org/ciac/bulletins/l-071.shtml
Przemyslaw Frasunek's buffer overflow in the ntpd package: http://www.securityfocus.com/archive/1/174011
The RFC for Simple Network Time Protocol v4: http://www.faqs.org/rfcs/rfc2030.html
The RFC for Network Time Protocol v3:
http://www.faqs.org/rfcs/rfc1305.html
The IETF Working group on secure time, with link to the Internet Draft: http://www.ietf.org/html.charters/stime-charter.html