This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.
The Network Time Security protocol (NTS) is close to completion as an Internet standard and will replace the existing security mechanisms in NTP. The introductory article on NTS describes the basic communication process as well as the most important features. Despite high-security efforts, NTS also has its limitations. In this blogpost, I list the strengths and weaknesses of the new authentication mechanism and describe them briefly.
Overview of the NTS Properties
To start off, Table 1 summarizes the main properties of NTS, which I will describe in more detail below. Since I was involved in the standardization process from the beginning, I have a good overview of NTS. Nevertheless, I cannot guarantee the completeness of the following content.
The Strengths of NTS
In general, NTS contains many design decisions to ensure the best and most efficient protection of the time protocol to be secured. At this point, I would like to emphasize the features of NTS that provide the most important advantages.
Defense Against Known Attacks
There are a lot of known attacks against NTP, ranging from time shifting to the complete deactivation of the NTP client (e.g. using Kiss-o’-Death (KoD) packets). Furthermore, NTP servers have been abused repeatedly in the past to perform DDoS attacks.
NTS aims to counteract these attacks with cryptographic measures. Authenticated packets prevent spoofing and the manipulation of time data. Cryptographically generated identifiers (UID) provide replay protection and identical sizes of request and response packets prevent DDoS amplification attacks.
Design of the Key Establishment (KE)
The decoupling of the initial key establishment (phase 1) from the NTS-secured NTP connection (phase 2) offers several advantages. One of them is the optional physical separation of the two phases on different machines. This method shifts the entire overhead from the time server to the KE server and allows load balancing. Phase 1 also uses the well-established TLS 1.2/1.3 and guarantees the source authentication of the time server. Moreover, crypto algorithms and connection information to the time server can be negotiated dynamically.
The KE phase also realizes another fundamental property: scalability. A network with NTS-capable clients and servers can grow flexibly so that the manual configuration of new clients is no longer necessary. In addition, both the client and server can manage several connections simultaneously. Furthermore, NTP implementations can support a hybrid mode to allow unsecured and NTS-secured connections at the same time. Of course, unsecured connections only make sense in a trusted local network.
The AEAD Algorithm (AES-SIV)
Another central element in NTS is certainly the AEAD algorithm SIV-AES, which is used for the construction of cookies and ensures the integrity of the NTP packets. The algorithm uses symmetric cryptography, benefits from AES-based hardware acceleration (AES-NI), enables the optional encryption of NTP extension fields, and is robust against the reuse of a nonce. Key lengths of 256, 384 and 512 bits are currently used in NTS. However, extending it with additional AEAD algorithms is easily possible.
Dynamic Key Rotation / Key Freshness
A preventive measure against brute-force attacks on generated cookies is the dynamic key rotation. Time servers renew the master key required for cookie creation at regular intervals. However, older keys remain valid for a few rotation periods to verify request packages with older cookies. This also allows a smooth key exchange between server and clients without the need to re-execute the KE phase.
If KE server and time server are separated, the same master key can be deterministically derived on both machines using an HKDF algorithm, without the necessity of communicating with each other. However, the generation of a new key based on a cryptographically secure random number (CSPRNG) always offers higher security.
Unlinkability / Privacy Protection
NTP implementations such as NTPsec use Transmit Timestamp Randomization to ensure this protection at the NTP level too. For this purpose, the client doesn’t write the transmission time into the NTP packet, but random data.
NTS servers always operate statelessly and can serve any number of clients without generating an overhead. The necessary status information is stored in the cookies and is always transmitted back to the client.
Robust Against Packet Loss
An NTS-secured NTP client always tries to hold a set of eight cookies. This allows the client to send further NTP requests with unused cookies in case of packet loss. Missing cookies are then refilled by the server, which means that the KE phase does not need to be executed again.
However, if all cookies are lost due to packet loss, the client can decide whether to send the last cookie repeatedly. This avoids the execution of the KE phase but allows the client to be tracked through different networks (loss of privacy protection).
Independent of this, the client can store the cookies locally when the time service is stopped in order to re-establish the server connection without a KE phase at a restart.
Disadvantages and Weaknesses
Although NTS offers many advantages, some limitations need to be considered:
One of the biggest problems is delay attacks, as they cannot be solved even with the best cryptography. NTP packets delayed by an attacker are still valid and difficult to detect. This usually leads to asymmetric packet runtimes, which results in a systematic time offset of the client. Therefore, an attacker can always delay the time of a client. An effective countermeasure is a limitation of the packet round-trip time (RTT). The maximum possible time offset of the clients corresponds to about half of the RTT. If the maximum permitted runtime is set to 300 milliseconds, the possible time offset of the client is limited to approximately +/-150 milliseconds. A further measure is the usage of several time servers and different communication paths (see also RFC 8633, RFC 7384).
Reduction of the Synchronization Accuracy
Another disadvantage is the reduction of synchronization accuracy by NTS. This can be minimized, but not completely prevented. Securing of the NTP packets is only possible after writing the timestamp. This means that the NTS protection time (the latency) flows completely into the calculated packet runtime. The fact that these times vary slightly between the client and server leads to a small RTT asymmetry and therefore to a systematic error. According to initial tests, this error is typically between 20 and 100 µs, depending on the implementation and platform. Since the fluctuations are dominated by the Internet, these deviations are usually not relevant for most applications.
Only for NTP in Unicast Mode
The NTS protocol is currently designed for unicast only. Support for broadcast connections is not possible with this concept since a connected slave cannot send cookies to its master. A TESLA-based procedure (see RFC 4082), which has not yet been pursued further, may be suitable for this. Since broadcast connections are rarely used and are frequently filtered over the Internet, this is less urgent.
The Chicken-or-Egg Problem
The NTS-KE phase requires valid server certificates for a successful TLS handshake. However, if the client’s time is not within the validity range of the certificate, the verification fails (even if the server certificate is valid). This completely cancels the current KE phase and an NTS-secured time synchronization never takes place. However, deviations of a few months are normally not a problem. Only in the case of very large time deviations (e.g. when setting up a device for the first time), it is necessary to set the date manually or to perform a one-time unsecured NTP synchronization.
For computer systems without an RTC (e.g. IoT devices or developer boards) this problem goes deeper. Such devices often lose their time after shutdown and reset it to a default value after a restart (e.g. 1970/01/01). As a result, an NTS-secured NTP connection would no longer work because the date is out of the certificate’s validity range. To counteract this, NTS implementations can store time information at regular intervals (e.g. every hour) and restore it after a system start. Storing a trusted date would be sufficient to ensure the verification of the certificates.
No End-to-End Security
NTS guarantees the integrity of transmitted time information between two devices. These are usually a client and a server. If the server synchronizes itself with other lower strata servers (higher accuracy), it can of course also use NTS. However, there is no guarantee that the clock on the server cannot be manipulated.
Higher Network Traffic / Larger NTP Packets
NTS-secured NTP packets cause a significantly higher network load compared to unsecured NTP communication. While unsecured NTP packets have a size of 48 bytes, NTS-secured NTP packets typically have a size of between 228 and 1468 bytes.
This is not a problem for the client since the transmission intervals are typically between 16 and 128 seconds. On the other hand, for large time servers that answer thousands of requests per second, this can be a greater burden.
Impl. dependent: Cookie Construction / KE Separation
The structure of the cookie described in the NTS specification is not normative. Implementations could follow a completely different structure. Furthermore, the communication between the time server and the KE server depends on the implementation, as long as they are physically separated. A bad software design could allow attacks and compromise security.
Impl. dependent: NTS Stripping Attack / Downgrade Attack
This is not a direct disadvantage of NTS but should be considered. A DoS attack on the client, such as intercepting and discarding NTP packets, can force the execution of the KE phase. In this case, good implementations should not react by lowering the protection mechanisms (e.g. TLS 1.2 instead of TLS 1.3) or switch entirely to unsecured NTP communication.
Well, you did it. ;)
2 thoughts on “Network Time Security – Strengths & Weaknesses”
I was missing the part that NTS is also hard to implement in environments such as the NTP pool. Unless anyone knows a straightforward and practically feasible way to do so.
Hey Marco. :)
Unfortunately, NTP pools do not work with NTS. …at least not now. The problem is that the time server must have a certificate issued by a trusted authority. If any time server (even malicious ones) can join the pool e.g. with a self-issued Let’s Encrypt certificate, then it is problematic. In such a case, a consensus of many trusted time servers is needed to detect single false going servers. …but there would be no guarantee that a time server does what it is supposed to do. …but at least a manipulation during the transmission in the network would be ruled out. Depending on the use case it could be sufficient.
…it is a complicated topic.