Network Time Security – New NTP Authentication Mechanism

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 …

This article is one of many blogposts within this NTP series. Please have a look!
TL;DR: In a nutshell: NTS is a new authentication scheme for NTP and fixes many issues of the previous security methods. It uses a separate TLS connection for the initial parameter and key exchange. The subsequent NTP connection is then secured by NTS extension fields. The functionality of NTP remains untouched and the time data is not encrypted by NTS – but authenticated.

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.

Figure 1: Phases of the NTS secured communication

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 TLS 1.2/1.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.

Figure 2: Separate communication channels between client and server

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).

Figure 3a: NTS-KE phase: initial parameter and key negotiation (request message)
Figure 3b: NTS-KE phase: initial parameter and key negotiation (response message)

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.

Figure 4: Separation of NTS-KE server and NTP time server

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.

Figure 5: NTS Extension Fields for NTP

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:

Table 1: Summary of IETF Hackathon results (NTS interoperability test)

 

Featured image “Gold Lock” by Mark Fischer is licensed under CC BY-SA 2.0.

4 thoughts on “Network Time Security – New NTP Authentication Mechanism

  1. I’m trying to understand if NTS could ever work well in the NTP pool, where a client might end up at any participating NTP-server on some sort of round robin basis. It seems to me that this doesn’t work well with the cookie mechanism, but I might be wrong. So any insights on this are welcome.

    1. Pools are unfortunately not supported. I am currently working on a solution for public NTS-KE servers to enable a better NTS secured NTP server negotiation. But is still in the beginning. Maybe we can provide a solution in 1-2 years.

  2. Hello Martin,

    First of all, thank you for this article, it was very helpful for me !
    I just have a question on the NTS Authenticator and Encrypted EF inside the request. How do you know that its size is typically 40 bytes? For me, the composition is as follows:
    – Field Type: 0x0404
    – Length (of the entire EF): 0x0018
    – Value:
    * Nonce length: 0x0010
    * Ciphertext length: 0x0000 (no encryption in request)
    * Nonce: 16 bytes nonce generated by the AEAD_AES_SIV_CMAC_256 (all servers should include this algorithm)
    * Ciphertext: empty
    – Padding: no padding

    And with this composition I only have 24 bytes, I do not have 40 bytes. Do you add padding values (if yes, what is the reason)?
    Have a good day!

    1. Hello Marie,

      I am happy to help you. For the AEAD algorithms used in the NTS specification (RFC 8915), this NTP extension field is typically 40 bytes (octets) in size. Here is an overview:

      NTPv4 Extension Field (RFC 7822, Sec. 3):
      ———————————————————-
      Field Type ( 2 octets): 0x0404
      Length ( 2 octets): 0x0028
      Value: (36 octets): {‘NTS Authenticator and Encrypted Extension Fields’ structure}
      ———————————————————-

      NTS Authenticator and Encrypted Extension Fields (RFC 8915, Sec. 5.6):
      ———————————————————-
      Nonce Length ( 2 octets): 0x0010
      Ciphertext Length ( 2 octets): 0x0010
      Nonce (16 octets): {random data}
      Ciphertext (16 octets): {AEAD output}
      Additional Padding ( 0 octets): {typically empty}
      ———————————————————-

      NTPv4 Extension Field header size: 4 octets
      NTS Auth-and-Enc-EF size: 36 octets
      ——————————————————-
      –> size of the whole NTPv4 extension field: 40 octets

      Except for Nonce, Ciphertext and Additional Padding, all other fields have a fixed length of 2 octets each. The three dynamic fields depend on the AEAD algorithm used. NTS currently defines one AEAD algorithm (AEAD_AES_SIV_CMAC_256) that must be supported. This algorithm is also available in 384- and 512-bit variants.

      The Nonce is a cryptographic random number which, according to the AEAD used (RFC 5297, Sec. 6.1), can be of any size, but must be greater than zero (>= 1 octet). The size of 16 octets is due to the fact that the AEAD is based on AES and has a block size of 128 bits (16 octets). For an 8-octet nonce, the AEAD would internally pad the rest with zeros until 16 octets is reached. For 20 octets, the AEAD would then pad up to 32 octets…. and so on.

      Additional Padding is used to make sure that the NTP response is exactly the same size as the NTP request. This field is typically empty (0 octets).

      Ciphertext is the output of the AEAD and consists internally of: {authentication tag || encrypted data (optional)}. The Authentication Tag (AuthTag) is always 16 octets in size, regardless of the size of the NTP packet or whether data is encrypted. The AuthTag is therefore the Message Authentication Code (MAC) that protects the NTP message. The encrypted data is only included if a plaintext is passed to the AEAD (which is the case for the NTP response). So the length of the ciphertext field is always: length of AuthTag (= 16 octets) + length of plaintext. Since the client does not encrypt anything in the NTP request, we therefore only have the AuthTag (16 octets). The server, on the other hand, encrypts a cookie (e.g. 104 octets). Then the Ciphertext field would be 16 + 104 = 120 octets.

      The NTS Authenticator and Encrypted Extension Fields EF is therefore 40 octets in size for an NTP request and 144 octets in size for an NTP response.

      I hope I could help you. Otherwise please let me know :)

      best regards,
      Martin

Leave a Reply

Your email address will not be published. Required fields are marked *