Security

It may seem a little weird to bring up the topic of security, but doing secure time synchronization over a public network is as attractive as it is dangerous. Obviously, bad things can happen if a terrorist compromises the time so that trains are dispatched to collide, stocks are sold before they are bought, and the evening news comes on at midnight. There is a more sinister side as well if the time is warped sufficiently to purge domain name caches or invalidate prescriptions, disk quotas, or income tax returns.

The Byzantine select algorithm avoids disruptions that might be provoked by a terrorist cell as long as the number of terrorists are only a minority clique. Just for good measure, the reference implementation includes purpose-engineered access controls and clogging avoidance.

The Kerberos security scheme originally implemented at the Massachusetts Institute of Technology (MIT) might have been the first system to recognize that these defenses are not sufficient to keep out a determined hijacker attempting to masquerade as a legitimate source. The problem anticipated by the designers was security of the timestamped tickets used to validate access controls. If a student prank managed to torque the clock forward by a day or two, even for a short time, all tickets would instantly expire, and nobody could get anything done.

The solution to the Kerberos problem was implemented by NTP in the form of symmetric key cryptography, by which a secret key is shared between the time servers and time clients in the system. This scheme has worked well over the years, but it requires secure distribution and management of the keys themselves. Modern schemes use public key cryptography in which servers create a public/private key pair in which the public key is exposed for anybody who asks, but the private key is never divulged.Using these and a low-overhead protocol, the client can securely authenticate other servers in the group.


But, how do the clients know an evil middleman has not managed to pry between the client and a legitimate server and construct bogus credentials? A server proves identity to its clients using a public certificate containing digital signatures to bind selected identity credentials, such as its host name, to its public key. The binding process continues as a certificate trail beginning with the client via intermediate certificate authorities (CAs) and ending at a root CA, which is independently trusted by other reliable means.

This protocol runs in parallel with the NTP protocol and uses the same packets. It is specifically designed to minimize intrusion and resist clogging attacks while providing strong defense against cryptographic malfeasance. The Autokey protocol provides for mutual overlapping groups using private group keys and crafted identity algorithms, some of which are properly described as zero-knowledge proofs.

In recent experience with the public NTP subnet, the most serious security violations have been accidental or malicious clogging attacks, by which large numbers of clients are configured for the same server or the same few servers. In one incident [5], a router intended for home office use was configured by the manufacturer to send packets at 1-s intervals to a single designated server. Ordinarily, this would not be a severe problem if only a small number of these routers was involved, but there were 750,000 of them sold, all ganging up on the same service providers and victim server. There is nothing in the Internet constitution that forbids this misbehavior, only a set of best practices and volunteer compliance. This kind of problem is not unique to NTP, of course, and the incident could be a warning of what might lie ahead.

Next post:

Previous post: