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.
In many areas, the use of authentication mechanisms in NTP is important to prevent the manipulation of time information by an attacker. For many years, NTP has been offering solutions such as a Symmetric Key based method and the Autokey approach. However, both have serious disadvantages, for which reason they are rarely used to secure NTP connections. After years of development, a new standard is to be adopted in 2020 that solves the problems of the current mechanisms and offers a real alternative. First implementations of the so-called Network Time Security protocol (NTS) are already available and interoperate with each other …
NTP – An important protocol with
insufficient security
The introductory article on NTP makes it very clear: Time is important to ensure the functionality of devices and processes. But what is the use of time synchronization if the time can be arbitrarily changed by attackers? Nothing at all! To protect this time information, NTP already offers two authentication modes in its current version 4. One of them is the older and still secure symmetric key approach, which unfortunately has a significant disadvantage: it does not scale. The usage of pre-shared keys always requires the manual configuration of the client depending on the server. Simple adding of new clients is therefore not possible and changes of the server-side keys result in adjustments to all clients. These problems were solved by the Autokey method, which showed other serious design flaws after an analysis in 2012. With this method, attackers can break a secured connection in a few seconds and modify the time data in the NTP packets. Therefore, the built-in solutions in NTP do not provide a satisfactory protection mechanism.
But what about alternatives like NTP over TLS or tlsdate? Unfortunately, TCP-based connections and tunneling concepts increase the latency and NTP packet runtimes. Even if these solutions offer higher security, this is only accompanied by the loss of synchronization accuracy and greater time fluctuations. The same applies to the alternative time service tlsdate, which also no longer works with the current TLS version 1.3.
Network Time Security (NTS), a new
solution for NTP (overview)
The lack of security mechanisms in NTP already led to the development of the Autokey v2 specification in 2012. Due to the bad reputation of the previous version and the fundamentally different communication structure, Autokey v2 was renamed to Network Time Security a short time later. After years of development and a second revision of the NTS protocol [draft-06, draft-20], it is now nearing its completion.
The NTS protocol is a security extension for time protocols and currently focuses on NTP in unicast mode. It provides strong cryptographic protection against packet manipulation, prevents tracking, scales, is robust against packet loss and minimizes the loss of accuracy due to the securing process. To protect the time information, NTS uses the NTP Extension Fields (EF), in which parameter and status information are also transferred between client and time server. The secured time protocol remains untouched so that the usage of NTS in other protocols (e.g. the Precision Time Protocol (PTP)) is possible as well. This also means that the time data is not encrypted by NTS – but authenticated.
NTS consists of sub-protocols, which currently form two phases of communication (see figure 1). The first phase takes place once at the beginning of the communication and serves the negotiation of parameters as well as the exchange of key material in the form of cookies. In the second phase, the NTS-secured NTP connection takes place. For this purpose, the client uses the cookies provided by the server, which it attaches to the NTP requests. The client remains in this phase until the connection is terminated or if cookies are no longer available due to repeated packet loss. In this case, the first phase is executed again.
How does NTS work?
At this point, I will go into a little more detail by using a communication run.
Phase 1 – NTS Key Establishment (NTS-KE)
The first phase takes place via a TLS1.2/TLS1.3 connection on a separate TCP channel to protect the initial data exchange from manipulation (see figure 2). Thus NTP shifts the entire overhead of the parameter negotiation to the well-established TLS communication and prevents possible design mistakes when implementing an own handshake solution via NTP. Potential fragmentation of IP packets, e.g. during the transmission of large certificates, is therefore excluded. This procedure also allows the easy use of the PKI structure and the reliable checking of the time server, as long as the certificate issuer is trustworthy.
After completion of the TLS handshake and verification of the certificates, the negotiation of the NTS parameters takes place. This is done with so-called NTS Records (or rather TLS records) via the TLS Application Data Protocol. Among other things, the records contain connection information, crypto algorithms and a set of cookies (see figure 3a, 3b).
The connection information allows the optional negotiation of the destination server address (IPv4/IPv6; UDP port). In this case, the NTS-KE can also assign another time server independently of the desired target server of the client. This concept makes a separation of the NTS-KE from the time server possible and enables load balancing. Moreover, this can be done logically on the same machine as well as physically on separated machines (as in Figure 4). In this way, several time servers can share one NTS-KE server. If no connection information is negotiated, the NTP time server can be reached on the same IP address as the NTS-KE with the standard UDP port 123.
The crypto algorithms used are AEAD methods, which are applied for the later protection of the NTP packets. These algorithms use symmetric cryptography to protect the integrity of NTP packets and enable the optional encryption of data. Currently, the AEAD algorithm AES-SIV [RFC 5297] is defined in NTS, which is insensitive to the reuse of an already used nonce.
To ensure that the time server can work statelessly, so-called cookies are used. These contain key material from the TLS connection, the negotiated crypto algorithm, and some further parameters. Both the NTS-KE server and the time server can generate the cookies and encrypt them with a secret master key. The structure as well as the content of the cookies are not transparent for a client and depend on the server implementation. The encrypted cookies differ from each other, preventing the tracking of mobile devices (e.g. smartphones) across multiple networks at the NTS level. In addition, cookies have a lifetime determined by the server. To do this, the server generates a new master key at regular intervals but accepts older cookies for another 1 to 2 rotation periods, which can take place daily. This allows a smooth key refresh without the need for a new NTS-KE.
If the client has received the cookies and parameters from the NTS-KE server, it also extracts the key material from the TLS connection and disconnects it afterward. The negotiation is now complete and phase 2 begins.
Phase 2 – NTS-secured NTP
In the second phase, the client communicates to the assigned time server via NTP. The client generates NTP requests, which are extended by the NTS content in the form of NTP Extension Fields (EF). An NTS-secured NTP request typically contains 3 to 10 extension fields, while a response packet contains two EFs (see figure 5). Currently, four NTS-EFs are defined and follow a TLV-like (Type-Length-Value) data format.
The first NTS-EF is the Unique Identifier EF. It contains random data and implements replay protection at the NTS level.
This is followed by the NTS cookie EF, which contains the oldest cookie from the client’s pool. Similar to a nonce, cookies are only used once in a request to prevent tracking. If an NTS request is sent, the cookie contained in the request is considered to be consumed.
A client always tries to hold a set of 8 cookies. This is achieved by the server returning a fresh cookie in its response and thus keeping the balance. However, if a packet loss occurs or an invalid message is discarded, cookies are missing in the pool afterward. In this case, the client inserts one or more NTS Cookie Placeholder EF in the following request. For each placeholder EF, the client receives an additional cookie from the server response. The size of the placeholder EF is identical to the size of the NTS cookie EF, but does not contain any data. This guarantees that the size of the request and response messages is always the same and that amplification attacks are not possible.
The last extension field is the NTS Authenticator and Encrypted EF. This implements the integrity protection (so-called authentication tag) over the NTP header and all previous extension fields. In addition to the authentication tag, it can also contain encrypted extension fields that are usually not contained in request packages. A finished NTS-secured NTP packet is much larger than an unsecured NTP packet with 48 bytes (NTP header only). An NTS secured packet typically varies from 228 bytes to 1468 bytes (NTP header + NTS EFs). If a possible IP fragmentation threatens, clients can request fewer cookies in case of packet loss.
If the server receives an NTS-secured request, it first decrypts the cookie with the master key and extracts the negotiated AEAD algorithm therein, as well as the keys contained. With this, the server now checks the integrity of the NTP packet to ensure that it is not manipulated. On success, the server generates one or more new cookies and creates the NTP response packet afterward. This always contains two NTS-EFs: The first is the Unique Identifier EF, which is taken unchanged from the request packet. The second is the NTS Authenticator and Encrypted EF, which secures the NTP packet and the previous EFs using the extracted keys, in the same way as the request. However, unlike the client, the server encrypts the cookies that are now included in this Extension Field. This procedure also protects the client from tracking because an attacker cannot extract the cookies from a response message. If the packet is finalized, it is sent back to the client.
After receiving the NTP packet, the client checks the Unique Identifier EF first. If a replay attack is excluded, the integrity check of the packet takes place. The client already knows the required key and the AEAD algorithm. If the check is successful, the encrypted cookies are automatically decrypted and exported. The client adds the new cookies to its pool and releases the time information for synchronization with NTP.
This communication process is repeated with the next request. In order to reduce the execution of the first phase, clients can also store whole sessions or cookies locally on the hard disk when the time service is stopped. This enables a reestablishment of the connection at a later time. It is also possible to send the same cookie repeatedly in case of connection problems, as these do not lose their validity after use. However, this is at the expense of data privacy, as it enables the tracking of a client.
NTS implementations and interoperability
Currently (Q4/2019), there are seven known implementations of NTS, which are in different stages of development. These include NTPsec, Ostfalia, Cloudflare, and Chrony (Red Hat). The first proof-of-concept implementation was already developed by the Ostfalia University in cooperation with PTB in Germany in 2015. Test servers and test implementations have been publicly accessible since 2018 and the software is open source [ntp, nts]. NTPsec offers a further NTS implementation that is fully executable. However, it should be noted that the NTS specification and thus the implementations have not yet been completed. The use is therefore at your own risk.
Since 2018, the Internet Engineering Task Force (IETF) has carried out several hackathons [IETF 101, 102, 104, 105] to test the interoperability. Four independent implementations have already passed these tests and problems in the current NTS specification were no longer found. The merged results can be viewed in Table 1 below:
