Security for Network Time Protocol standardised in RFC 8915

Network Time Protocol

NTP is a client-server protocol for retrieving the current time via UDP port 123, usually from a handful of other systems. The client then uses a smart algorithm to arrive at a value that optimises the match with the time providers (servers). The result is a time setting that is typically accurate to within a few milliseconds. Although NTP could in principle be used for peer-to-peer synchronisation, the protocol is normally used in a hierarchy: clients synchronise their system time with superordinate ― more accurate ― NTP servers. However, they often communicate with peers on their own stratum as well.

• Stratum 0: atomic and radio clocks

• Stratum 1: computer systems linked directly to (stratum 0) clocks (at a 'distance' of microseconds)

• Stratum 2: computer systems linked to stratum-1 systems

• Stratum 3: computer systems linked to stratum-2 systems

• Etc

The closer you are to stratum 0, the more accurate your system time will be. However, each successive stratum adds an element of inaccuracy due to the 'unknown' delay/asymmetry associated with network data exchange. The reference implementation ntpd (NTP daemon) is the default on many systems. However, on Linux systems (particularly 'Red Hat'-type systems), ntpd has been displaced by chrony, while on OpenBSD the default has for some time been OpenNTPD. Various other NTP implementations are available or under development.

Aging protocol

Like DNS, NTP is an old protocol. Both date from the early 1980s and rely on UDP, the simplest, fastest and most efficient packet service based on the Internet Protocol. Because NTP and DNS are products of an era when the internet had a small circle of users in the academic and military worlds, neither protocol originally made provision for security by default. Where DNS is concerned, that problem was subsequently addressed by the development of DNSSEC, which assures the authenticity and integrity of DNS records. More recently, DoH/DoT has emerged as a means of additionally assuring transport confidentiality.

No security options

The current version of NTP (version 4, defined in RFC 5905) does include security provisions, but they are rarely used, with good reason. One possibility is to use symmetric encryption. However, that requires the exchange of a private key before time synchronisation takes place. What's more, the encryption is based on the MD5 algorithm, which is known to be insecure and whose use is therefore discouraged. The unofficial alternative to MD5 is SHA-1, which is itself no longer regarded as secure but can nevertheless be used for this type of authentication. Asymmetric authentication on the basis of Autokey, defined in RFC 5906, is also possible. However, Autokey is a problematic and insecure protocol whose use is definitely inadvisable. Until now, therefore, NTP has lacked appropriate security. With NTPv4, the usual workaround has been to link the response to the address of the server that sent the incoming query, together with the timestamp (nonce) of the most recent synchronisation with that server.

Flaws in NTP

Traditional attacks on NTP systems and implementation-related problems have typically involved the abuse of (public) NTP services. Such abuse can be an effective attack strategy if, for example, an IoT device manufacturer (independently) sets up the device to use a particular server, or if an access provider does the same with modems issued to customers. Another known problem is the use of DDoS amplification attacks. In 2015, however, Malhotra's team at Boston University published a paper exposing several vulnerabilities in the NTP itself. The paper explained how, by adjusting a machine's system time, it was possible to interfere with various security protocols that rely on system time. Publication of the Boston University research has triggered the implementation of NTS. Again, parallels can be drawn with DNS and DNSSEC: it was Dan Kaminsky's demonstration of how fake information could be injected into a caching resolver in 2008, that finally got the implementation of DNSSEC moving. SIDN Labs and various Dutch software developers played important pioneering roles in that context. Publication of the 'SAD DNS' attack earlier this month underlined the importance of DNSSEC as a structural solution.

Time setting and DNS/DNSSEC

In the summer of 2019, the same Aanchal Malhotra and the team at NLnet Labs (responsible for the development of NSD, Unbound, OpenDNSSEC, Routinator and various other network tools) published a paper focusing specifically on the importance of correct (secure) system time in the context of the DNS. One of the main challenges with NTP is that the same software is used on internet-connected systems of all sizes, some of which remain in operation for very long periods, with IoT devices in particular often not updated. Where validating resolvers are concerned, the advice is to enable NTP, but ensure that your configuration is correct. The configuration should support client activity only, not server activity. In addition, the NTP clients on validating resolvers are the first systems in line for implementation of the NTS protocol described below. The vulnerabilities in NTP and DNS revealed in recent years by Malhotra and NLnet Labs are considered in this article.

NTS: a relatively complex protocol

NTS assures the authenticity and integrity of NTP messages in client-server mode. Its designers have adhered to the existing NTP as closely as possible, so that it serves as an extension to NTP version 4. The approach means that there is no adverse effect on the speed of the UDP exchange between client and server. That's important, because network delay/asymmetry determines the accuracy of the time that a client obtained from a server. However, the approach also means that NTS is a relatively complex protocol. Interaction is initiated by the client using TCP to open a TLS connection with the NTS server on port 4460. As with other TLS-based internet protocols (e.g. HTTPS), that implies first fetching a PKI certificate or certificate chain and negotiating which of various cryptographic protocols to use. Next, over the secure connection, the client receives one or more cookies and an IP address-UDP port combination for which the cookies are valid, plus a (symmetric) c2s (client-to-server) key and s2c (server-to-client) key. In principle, the exchange (NTS Key Establishment, NTS-KE) is a one-time procedure. The key material thus obtained is used in the NTP packets for what is known in cryptography as 'authenticated encryption with associated data' (AEAD), where unencrypted and encrypted data are combined to form a single authenticated message. That requires extra fields to be added to the NTP packets.

Message exchange

When submitting an NTP query, the client includes one of the cookies in unencrypted form. The cookie serves simply as a session key from which the server can obtain the required status information. The server doesn't therefore have to keep a record of its clients' statuses. The message also includes an unencrypted random identifier of at least 32 bytes. Like the old origin timestamp, the identifier serves to protect against off-path spoofing attacks. The collective authenticity of the various elements is assured using a MAC (a Message Authentication Code, which has some similarities to a digital signature). The MAC is based on the private c2s key. The server's NTP response includes a new cookie (this time encrypted), for use in the next NTP query. These unique cookies protect the client against linkability: if a client is assigned a new IP address, the client can no longer be identified using a known session key. The client can validate the incoming MAC using the s2c key previously provided by the server over the TLS connection. In NTS, the MAC is stated in the existing NTPv4 extension fields defined in RFC 7822. The same 128-bit space – supplemented by the 128-bit AES-CMAC defined in RFC 4493 – is also used for MD5-based symmetric authentication of NTP. For a full explanation, complete with numerous diagrams, see this article by Johannes Weber.

Bootstrapping

However, the use of NTS does give rise to a chicken-and-egg (bootstrapping) problem: During system initialisation, when setting up the first TLS connection before the client's system time has been reliably set, the client has to assume that the certificate provided by the server is valid. That is particularly problematic with small, cheap IoT devices that don't have either an onboard RTC clock chip or any non-volatile memory in which to record the most recently verified time. When first powered up, such devices set the time to a value such as 1 January 1970 (the start of the UNIX epoch). NTS client software can, however, check the consistency of the two channels by ascertaining whether the NTP time it is given is within the validity period of the TLS certificate just received. Also, clients are not allowed to fall back on traditional NTP if the NTS server is unreachable, since that would make a client vulnerable to MITM attacks. System operators are therefore advised to use multiple sources (NTP servers). Hence, the same mechanism can be used to improve the accuracy of the time and increase the reliability of your sources. NTS is currently supported by chrony and NTPsec. Various other implementations are in the pipeline.

Dutch national NTP service

The development of NTS has been spearheaded by Cloudflare, who have had a pilot running since July of last year. The work at Cloudflare has been led by Aanchal Malhotra, whose research papers were mentioned earlier. However, we ourselves are also offering NTS as an experimental feature of our NTP server. The service is described in the introduction to this article. Our ambition is to develop time.nl into the national NTP service for the Netherlands. If (in network terms) you're close to SIDN's home city of Arnhem, you are warmly invited to start using our NTP and NTS server immediately (in combination with a few other NTP servers). Advice on configuring your computer to use our NTP service can be found on the TimeNL website.