Network Time Security (NTS) RFC 8915



Version 4 of the Network Time Protocol Version 4 (RFC 5905) is the most commonly used protocol for transferring time over networks and is employed in essentially every IP network. NTP messages are often sent over direct connections or the "public internet", which is why it is especially important for NTP clients to reliably confirm that the NTP server is what it claims to be and that nobody can tamper with the messages in transit. Thankfully, NTPv4 features integrated security mechanisms, specifically Symmetric Key Authentication and Autokey. Unfortunately, however, Symmetric Key Authentication scales poorly due to the need to distribute keys manually, while Autokey suffers from documented vulnerabilities and can be compromised by a brute-force attack.

The Internet Engineering Task Force (IETF) has published a more up-to-date security mechanism referred to as NTS, or Network Time Security (RFC 8915), which does not have these problems. As of LTOS Version 7.08, all Meinberg NTP time servers provide full support for NTS (Network Time Security) in Unicast Client/Server Mode.

How Does NTS Work?

NTS only works in NTP's "Unicast Client/Server Mode". When using other, less commonly used NTP communication methods, the only options currently available are Symmetric Key Authentication, Autokey, or to forego extra security entirely.

Network Requirements

NTS involves the use of an NTS-KE server (KE stands for Key Establishment) alongside the NTP server and client. This NTS-KE server exists to negotiate cryptographic algorithms between the NTP client and server and distribute keys. The NTS-KE server and NTP server are two separate programs that can run on the same server, or can run individually on separate servers.

Before a client can 'speak' to the KE server over NTS, it must establish a secure connection over Transport Layer Security (TLS), which the client uses to authenticate the NTS-KE server based on its public key certificate. As soon as the TLS session is established, the client sends a list of the AEAD (Authenticated Encryption with Associated Data) security algorithms it supports and also optionally a preferred NTP server and port number in the network stack. The KE server responds with a selected algorithm, the IP address of the NTP server, the port number, and one or more initial cookies.

Because the NTP and NTS-KE server are often implemented jointly by a single time server manufacturer and are distributed together, the NTS standard makes no stipulations as to how the two servers are to interact with one another. The NTS server notifies the KE server in their own unique way which security algorithms it wishes to use and which key should be used to encrypt the cookies.

As soon as the NTP client has received the initial cookies from the KE server, it can send a secure NTP request to the NTP server. The NTP server uses the information in the NTP extension fields to acquire the cookie and authenticate the NTP request. The NTP server then generates the next cookie and sends it together with the NTP response, as illustrated in Figure 3 below.

So what's the deal with all the cookies being sent back and forth? These are necessary because NTP servers are 'stateless' instances—because there can be a very large number of individual clients, they don't want to have to remember each and every one. It is important to note here that a client might receive multiple cookies from the KE server so that it doesn't have to log in to the KE server again each time the NTP client is restarted.

NTS uses the extension fields of NTP packets. The "Unique Identifier" is like a sequential ID, but is generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). This makes the data appended to NTP messages rather more entropic than with ordinary sequential IDs, impeding potential efforts to break the security with brute-force attacks. Matching NTP request and response messages use the same "Unique Identifier". In conjunction with the cookie, a pointer to the key selected by the NTS server is used to decrypt the cookie. The extension field used for authentication contains a Message Authentication Code (MAC)—a kind of cryptographic checksum that is compared against the value generated by the client and server when the message is received. If they match, it can be safely assumed that the message has not been manipulated in the network.

How is a Cookie Generated for NTS?

A cookie contains the components shown in Figure 5 and is encrypted by the server before being sent to the client. Note that while the client does send encrypted cookies to the server, it cannot read them— the client only saves information for the server to allow the server to remain stateless. A nonce is a field containing random bits that is appended to the message in order to make the encrypted cookies even more entropic. NTS uses two different keys: one for the NTP request sent by the client to the server (C2S), and another for the response sent by the server to the client (S2C).