Stig Nygaard - Nighttime

Setting up NTS-Secured NTP with NTPsec

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 the previous posts, I already introduced the Network Time Security (NTS) protocol and described the most important features. Although the specification process has not been completed, there are already some independent NTS implementations and public time servers (IETF106). NTPsec is one of the important representatives of this series and already offers an advanced NTS solution. In this post, I’ll give you a short guide to setting up an NTS-secured NTP client/server with NTPsec.


NTPsec  is a fork of the NTP reference implementation NTPD that has removed inherited burdens to provide a smaller codebase. In addition, the relevance of NTPsec in the Linux environment is increasing and it is one of the first NTS-capable NTP implementations.

Due to the missing Windows support, this guide is only intended for Linux systems. Therefore I’m using a Raspberry Pi 3B with the recent Debian-based operating system Raspbian. The procedure described here also works with other Linux distributions in the same or similar form.

Software Components Used

In order to use NTS, we need the following software components. You can find detailed instructions for installation and setup below:

Important: All NTS implementations that use OpenSSL with TLS 1.3 support require OpenSSL 1.1.1b or higher. OpenSSL 1.1.1a contained a bug  which caused the TLS key export to fail during the NTS Key Establishment (NTS-KE) phase.

NTS Properties of NTPsec

Currently (Q4/2019), NTPsec has implemented the NTS draft 17. The following adjustments of the specification up to the latest draft version 20 do not contain any significant changes so that NTPsec is representative. The following NTS features are included in the implementation:

  • TLS support for the NTS Key Establishment (NTS-KE) phase
  • Default NTS-KE port
    • 123 (TCP)
  • Default NTP port
    • 123 (UDP)
  • Error handling (server-side)
    • Discard request packets without response*

*The server only discards invalid request packets and does not send an NTSN (NTS NAK) back to the client. This is okay, but a client then doesn’t know whether a request has been lost or if an error occurred during verification.


Okay, now we can finally get started. First, we log into our Raspberry Pi (RPi) and make sure that we have an Internet connection. This device can be accessed directly with a connected screen and keyboard or headless via SSH. Then we update the system and the installed packages:

Next, we check the OpenSSL version, which must be 1.1.1b or higher:

To ensure the correct functioning of NTPsec, we should also disable the local time synchronization service. This also applies to other services (such as OpenNTPD, Chrony, …).

If an NTP service (e.g. NTPD) is used instead, we can remove it as follows:

This is necessary since NTPD and NTPsec use the same files and names for the application.

Installation of NTPsec

The installation of NTPsec can be done via the package manager as well as by manually building the source code.

Method 1: Using the Package Manager

The easiest way to install NTPsec is through the use of a package manager. For NTS support, we need the version 1.1.8 or higher. To check which package version is available, we use the command apt show:

If version 1.1.8 is available, we can simply install it as follows:

That’s it! You can skip the following steps and go directly to the configuration (see below).

Method 2: Build the Source Code Manually

The manual setup consists of building and installing NTPsec as well as its registering as a system service (systemd).

Part 1: Building and Installing

This installation guide is based on the NTPsec instructions and can be carried out without much effort. We begin with the installation of some basic tools and compilers. Then we create a temporary working directory in which we copy and build the NTPsec source code.

Next, there are two ways to build the code. Either we clone the current git repository (variant 1) or we download the recent NTPsec version (variant 2).

Variant 1: Using The Git Repository

Variant 2: Downloading Binaries

The following script now installs all tools or packages (bison, libssl-dev, libcap-dev, libseccomp-dev) that are needed for building. These can also be installed manually. But in our case we use the script:

Now we can make initial configurations. We can display the available options with ./waf configure --help. If no parameters are specified, the NTPsec installation is done in the /usr/local/ directory by default. The application (ntsd) is then located in /usr/local/sbin. With the parameter –prefix=<dest/path> we can change the path arbitrarily. If NTPsec is to be configured as a server, the parameter –refclock=all is necessary, since it allows the use of any local reference clock (GPS, PTP, SHM, etc.).

Finally, we build the source code and install the binaries:

Let’s check the NTPsec version number:

The output should look like ntpd ntpsec-1.1.8 2019-11-20T04:44:12Z and must be 1.1.8 or higher.

Part 2: Setting up the NTP Service (Systemd)

Perfect. Next, we set up NTPsec as a system service. For this, we create an ‘ntp’ user and an ‘ntp’ group with restricted rights. We also create folders for log files and certificates.

Now NTPsec is executed automatically when rebooting the system. At the moment the service is not running yet, because we have to configure it first.

Configuration of NTPsec

After the installation of NTPsec the configuration has to be created. The NTP service uses ntp.conf, which is located in the /etc/ directory by default. If this file is not yet available, it must be created:

The following examples are based on the NTPsec instructions (General, NTS-QuickStart) and differ between client and server.

Client Configuration

Let’s have a look to the client configuration. In this ntp.conf I have listed 4 examples for a possible client configuration. These can be changed or commented out if necessary:

In the first example, the Raspberry Pi synchronizes its clock with a public NTPsec time server using a classical unsecured NTP connection.

In the second example, the client communicates with the same time server via an NTS-secured NTP connection. The initial channel to the NTS-KE server uses the default port 123 TCP (currently implementation-specific). Since the NTPsec time server uses certificates issued by Let’s Encrypt, we do not need to set any additional parameters. To check the certificates, the client uses the local root CA pool (/etc/ssl/certs/ca-certificates.crt), which also allows the verification of certificates issued by Let’s Encrypt.

In the third example, we connect to the time server of the Ostfalia University, which is also NTS-capable. This uses TCP port 443 for the NTS-KE connection and uses self-signed test certificates. To check the server certificate we have to specify the root CA manually. The corresponding certificate can be downloaded by the following command:

Caution: The time server of the Ostfalia University also publishes its private key, as it is a public test server. This time server should not be used for clock synchronization of productive systems.

The fourth example differs from the third one only from the deactivated domain validation. This can be useful when we running a local NTS server with certificates without a registered domain.

The other entries in the configuration file are optional and are used to record statistics and log files. The descriptions as well as the complete parameter list (incl. NTS) can be found in ntp_conf.adoc. Here only very briefly described:

Server Configuration

The configuration of the server is a little easier:

In this example, we use the local clock as the reference time source, which we distribute to all connected clients. When activating NTS, we have to specify a server certificate and the private key. This may have been created manually or issued by an external CA instance (e.g. Let’s Encrypt again).

By the way, the client and server configurations can be combined to run both simultaneously. For example, a client could fetch the time NTS-secured from external time servers and distribute it as a server in the local network without NTS.

Debug and Advanced Information

Starting the Daemon:

Now we can start our NTPsec service:

After this, the service should run, which we can easily check:

The whole thing should look like this:

Manual Start of NTPsec:

Of course, you can also start NTPsec manually:

If you also want to see the log output live, then you need to specify some parameters:

For an NTS-secured NTP client (here from example 3 of the configuration) we see the following:

Everything works well. The certificate is valid and the client has received 8 cookies. The AEAD algorithm 15 (AEAD_AES_SIV_CMAC_256) is used to secure packets.

Peer Status:

To check the current status of the connection(s), we must enter the following command:

The NTS-Secured NTP Client:

As you can see, the synchronization works fine. No packet loss and a small time offset.

The NTS-Secured NTP Server:

The server side also works, but gives less information.

NTS Status:

The following command allows us to view the NTS statistics:

If we use both NTS client and NTS server at the same time, then we get these values:

Manipulated or invalid packets are detected and discarded. The number is listed accordingly (NTS server recvs w error).

Wireshark Examples and Pcap Files

At this point, I would like to show a few examples, how the whole thing looks like in Wireshark. Since NTS is not yet supported in Wireshark, there are still incorrect interpretations of the binary data. But that shouldn’t bother us at all.

Example 1: NTS with TLS 1.2 and 512-Bit AEAD Algorithm:

In this figure we see an NTS-secured NTP connection. This starts with the NTS-KE over TLS 1.2. Due to the strong AEAD algorithm and the resulting large cookies, the NTP packets have a size of 296 bytes (or 338 bytes including all headers). The yellow markings in Wireshark are due to misinterpretations of the content.

NTS with TLS 1.2 and 512 bit AEAD algorithm
Example 2: Possible NTS Behavior with Packet Loss or Manipulation:

Here we see the behavior of manipulated NTP packets. The server simply discards them. The client then sends another packet and wants an additional cookie because one is missing. Therefore, the size of the following request increases by the size of a cookie. This is repeated until the client has no cookies left and repeats the NTS-KE. This behavior also occurs if the client does not receive the response due to packet loss.

Possible NTS behavior with multiple packet loss
Exampe 3: NTPsec with Default Settings and NTS

Like example 1, but with TLS 1.3 and a 256 bit AEAD algorithm. The NTP messages are therefore smaller.

NTPsec with default settings and NTS
Example 4: Multiple Unsecured NTP and NTS-Secured NTP Connections

In this example, we see unsecured and NTS-secured NTP connections of the Ostfalia time server. The NTS connections use different configurations (AEAD algorithms), so that the packet sizes vary.

Multiple unsecured NTP and NTS-secured NTP connections

The current connections of the Ostfalia time server are recorded and can be freely downloaded. This allows better diagnosis and live tracking when testing with NTS. The current pcap files can be found here and here.  The pcap files of the Wireshark examples above are here.:

Thanks for reading ;)

Featured image “Nightlight” by Stig Nygaard is licensed under CC BY 2.0.

5 thoughts on “Setting up NTS-Secured NTP with NTPsec

    1. Hello Attilio,

      “does the DNS been checked from time to time?”

      ehm… no, not directly. Only during the TLS handshake, but not when the NTS-secured NTP phase is running. But this should not be a problem. If the address is no longer accessible, then the cookies also slowly decay and the client will attempt to re-establish a TLS connection after a few minutes to check the certificate and the associated DNS.

      by the way… your guide looks good :)

      Also some good news: NTS will be released very soon. Our tests on the last IETF Hackathon (July 2020) were successful and we have multiple working Implementations (NTPsec, Chrony, Cloudflare and more) and public time servers:

      here are the results:

      public NTS time server (stratum 1, using NTPsec): (; certificates:

      best regards,

  1. Pingback: NTS – Blog

Leave a Reply

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