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.

Overview

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.

Preparation

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.

66 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: https://docs.google.com/spreadsheets/d/1QjLjgVcvOdEnAS0sHWt8ZZSrbmvrQA2gaSBF3fLuCLM/edit#gid=749801262

      public NTS time server (stratum 1, using NTPsec): ptbtime1.ptb.de:4460 (192.53.103.98); certificates: https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt

      best regards,
      Martin

        1. We have the need to change our old Symmetricom appliances (2 S100 TCXO and 2 S200 Rb) where I work.

          Requirments are GPS/GLONASS/Galileo + Rubidium option + 10Gb possibly, and of course NTS.

          I am not able to find any appliance which is NTS ready, and of course I cannot propose a raspberry lol. We need professional hardware and support and shit.

          Do you have any recommendation or hint?

          Thanks :)

          1. yeah… it not so easy right now. NTS is an RFC for almost 2 months and many producer need time to develop the standard and upgrade their firmware. Furthermore, the hardware must be able to provide the additional performance, since many appliances need to serve the full network bandwidth.

            I have a loose cooperation with Meinberg and I know that you are very interested in equipping your devices with it. I think they will roll out new firmware or provide new devices as soon as possible.

            I will ask tomorrow, maybe I will get an info about it. I will report again in 1-3 days ;)

            1. that would be great, at least to have some info, like the already available devices that will be capable of NTS just by firmware update :)

              thank you so much!

              1. Hey Attilio,

                unfortunately I have not received any further feedback so far. I’ll try again and probably get back to you tomorrow ;)

  1. Pingback: NTS – Blog
  2. I’ve a problem in connecting with the NTS-KE server of PTB @ ptbnts1.ptb.de:4460, particularly with the CE certificate chain dfn-ca-global-g2 you linked above (I’m running NTPsec on Debian 10); what to put into ntpsec.conf and how/where to import the certificates to? – Thanks for your help!

    1. hey :)

      you can put the certificates in ‘etc/ssl’ or ‘etc/ssl/certs’. Also see the examples above (for custom directories):

      # Example 1: unsecured NTP
      server ntp1.glypnod.com iburst minpoll 3 maxpoll 6

      # Example 2: NTS-secured NTP (default NTS-KE port (123); using certificate pool of the operating system)
      server ntp1.glypnod.com iburst minpoll 3 maxpoll 6 nts

      # Example 3: NTS-secured NTP (custom certificate and NTS-KE port)
      server nts3-e.ostfalia.de:443 iburst minpoll 3 maxpoll 6 nts ca /var/lib/ntp/certs/rootCaBundle.pem (–> is the dfn-ca-global-g2 cert)

      # Example 4: NTS-secured NTP (skip DNS check)
      server nts3-e.ostfalia.de:443 iburst minpoll 3 maxpoll 6 nts ca /var/lib/ntp/certs/rootCaBundle.pem noval

      short question… where are you from? I know about problems in London and Canada (due to filtering of NTS packets). Do you get error messages?

      best regards,
      martin

      1. Perfect, that did the trick, thank you for your help, Martin!
        And I’m from Germany, no NTS filtering by my provider here…

  3. Hi Martin,

    Is there a list being maintained somewhere which NTP servers are NTS-capable?

    Best regards,
    Marco

    1. hey Marco,
      good question..

      I don’t think there is a public list. Maybe this helps:

      ptbnts1.ptb.de (https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt)
      ptbnts2.ptb.de
      ptbnts3.ptb.de
      nts.ntp.se:3443
      nts.sth1.ntp.se:4460
      nts.sth2.ntp.se:4460
      time.cloudflare.com:1234
      timemaster.evangineer.net:4460
      nts1.time.nl:123
      ntp1.glypnod.com:4460
      ntp2.glypnod.com:4460
      ntpmon.dcs1.biz:4460
      ntpmon.dcs1.biz:123
      netmon2.dcs1.biz:123

      —————————————–
      the standardized NTS port is now 4460/tcp. So maybe the ports above are now 4460.

      ptbnts1.ptb.de is now the official NTS-secured time server of germany and central europe.

      have a nice day (⊙ヮ⊙)
      -martin-

          1. Hi Martin, I noticed several servers time out or refuse connection, and I also noticed you provided a public certificate. I wonder whether these two are related: is chrony unable to connect because I don’t have the proper certificate? My knowledge is limited on this subject, so I wonder if you could help me out. Tried to find my way throught the manpages, but I don’t get it. Chrone is running on my (Asuswrt-Merlin) router and I did see there has been directory created for keys. But how to proceed? Can you help me out? Thanks in advance.
            Best regards,
            Marco
            The Netherlands

            1. Hey Marco,

              this is not difficult ;)
              The certificate is no longer necessary. For the individual servers, it may be that they are no longer connected to the network. I have tested this list a few months ago. The time servers of PTP and Cloudflare should be available.

              You only have to do the following:
              1. open the configuration file. For a NTPsec client it is “/etc/ntp.conf” and for a Chrony client it is “/etc/chrony.conf”.

              2. Then enter the following:
              server ptbtime1.ptb.de nts
              server time.cloudflare.com nts

              soon available:
              server ptbtime2.ptb.de nts
              server ptbtime3.ptb.de nts

              also available:
              server nts.time.nl nts

              see if it works :)
              many greetings,
              Martin

              1. Oh, thanks for your guidance, but that was already clear, I have chrony-nts up and running and it performs great. I was just wondering why several servers keep timing out (see below) and others keep refusing connection, and wondered whether that had something to with the certificate you posted earlier. It works like a charm, it’s just that the list of servers is still somewhat limited.

          2. Hello Martin,thanks for the effort in extending NTS for PTP. Do you have a public repo where we can find your progress regarding to this implementation? Thanks!

            1. sorry for the late reply. I was very busy the last few days. Do you mean the NTSsec repository? Otherwise here are the most important links:

              Implementations:
              NTPsec: https://gitlab.com/NTPsec/ntpsec
              Chrony: https://github.com/mlichvar/chrony
              NTPO (only PoC): https://gitlab.com/MLanger/ntp

              Specs:
              NTS-for-NTP: https://datatracker.ietf.org/doc/html/rfc8915
              NTS-for-PTP (in progress): https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/

              best regards,
              martin

      1. oh… for germany the new server is: ptbtime1.ptb.de and it uses Lets Encrypt vertificates ;)
        ptbtime2.ptb.de and ptbtime3.ptb.de should be online in 1-2 weeks.
        time.cloudflare.com is also fine ;)

        -martin-

        1. ptbtime2.ptb.de and ptbtime3.ptb.de are apparently online as of this weekend. However, ptbnts[1|2|3].ptb.de are constantly timing out. Any idea why they can’t be reached?

          1. Martin,

            I have already found my answer by the reply of the ntp-admin @ PTB:

            “The servers ptbnts1/2/3.ptb.de were announced as test servers on https://www.ptb.de/cms/en/ptb/fachabteilungen/abtq/gruppe-q4/ref-q42/time-synchronization-of-computers-using-the-network-time-protocol-ntp.html. It wasn’t clear from the beginning whether they would turn productive or stay in test status but it was decided to extend the official timeservers ptbtime1/2/3.ptb.de. So with our atomic clocks as primary source they disseminate the official time information for Germany, in the past via NTP and now via NTP and NTS.”

            In short: the ptbntns server are taken offline, the ptbtime servers are now the main servers for Germany and Europe.

            Best regards,
            Marco

            1. sorry for the late reply, I was very busy. You are right… it is currently also difficult to find out which time servers are already NTS capable. 「(⌒_⌒;)

  4. Hi Martin,
    I built an NTS server in my labs.
    I created certs self-signed.
    but when I start , i got logs err:
    2021-06-18T14:42:15 ntpd[5338]: NTSc: certificate invalid: 18=>self signed certificate
    2021-06-18T14:42:15 ntpd[5338]: NTSc: NTS-KE req to nts-service.lab.vn took 0.003 sec, fail
    2021-06-18T14:42:15 ntpd[5338]: DNS: dns_check: processing nts-service.lab.vn, 1, 21901
    2021-06-18T14:42:15 ntpd[5338]: DNS: dns_take_status: nts-service.lab.vn=>error, 12

    Could you please help me to fix it.
    Thanks

    1. hey :)

      looks to me like an OpenSSL error due to invalid certificates. I guess that the NTS server certificate is a self-signed certificate without root CA. This means that the identity of a server cannot be verified unless the client also uses the server certificate as root CA.

      Another point is that the DNS check fails because the common name (CN) in the certificate probably differs from the domain name of the NTS server.

      I see 2 possible solutions:
      A: Create your own root CA certificate (self-signed). Then create a server certificate signed by the root CA certificate. But if you use it locally you have to disable the DNS check in NTPsec.

      B: Create a server certificate with LetsEncrypt (e.g.: with certbot). Goes quite easy and always works ;)

      I hope I could help.

      many greetings,
      Martin

      1. Hi Martin,
        thanks for your advice.
        but i really want to try the test on local labs, i don’t have domain name, then i cannot using LetsEncrypt.
        Do you have any instructions for creating root CA certificate (self-signed) locally?
        My labs have 2 servers.
        – NTS Server (also Root CA )
        – And NTS Client
        All is Ubuntu server 16.04.
        Thanks

        1. Hey Tri,

          If it is local only for certain tests, then you could disable certificate checking if necessary. This can be done in the client config with the “noval” tag (see: https://docs.ntpsec.org/latest/ntp_conf.html).

          If you want to generate certificates, then you can do that e.g. with OpenSSL in the terminal. There are many tutorials available. If you want to use a GUI, then I recommend the tool ‘XCA’ (https://hohnstaedt.de/xca/). This is free for Windows/Linux/Mac. I used this tool for a long time to build certificate chains and to test my NTS implementation.

          Small hint: NTS uses TLSv1.3, so you should not use RSA keys with <=2048 bit. These are considered invalid during certificate validation. It is best to use a key based on elliptic curves (EC) …or ED25519.

          many greetings,
          Martin

    1. looks ok for me.

      maybe this line must be changed:
      openssl genrsa -out mydomain.com.key 2048

      in:
      openssl genrsa -out mydomain.com.key 4096

  5. Hi Martin,
    Could you plz add my skype: nguyenvantri712
    I really want to learn and know more in the details how to implement NTS.
    Thanks

    1. I try it on sunday. I’m not really a skype user, but I guess Windows provide a skype app or something.

      best regards,
      martin

      1. Thanks,
        When i try to test follow you recommend:
        I got logs: 2021-06-19T09:51:47 ntpd[1941]: IO: Listen and drop on 0 v6wildcard [::]:123
        2021-06-19T09:51:47 ntpd[1941]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123
        2021-06-19T09:51:47 ntpd[1941]: IO: Listen normally on 2 lo 127.0.0.1:123
        2021-06-19T09:51:47 ntpd[1941]: IO: Listen normally on 3 ens33 192.168.112.134:123
        2021-06-19T09:51:47 ntpd[1941]: IO: Listen normally on 4 lo [::1]:123
        2021-06-19T09:51:47 ntpd[1941]: IO: Listen normally on 5 ens33 [fe80::20c:29ff:feba:8000%2]:123
        2021-06-19T09:51:47 ntpd[1941]: IO: Listening on routing socket on fd #22 for interface updates
        2021-06-19T09:51:47 ntpd[1941]: PROTO: 0.0.0.0 c011 81 mobilize assoc 13299
        2021-06-19T09:51:47 ntpd[1941]: PROTO: 0.0.0.0 c01d 0d kern kernel time sync enabled
        2021-06-19T09:51:47 ntpd[1941]: PROTO: 0.0.0.0 c012 02 freq_set kernel 0.035583 PPM
        2021-06-19T09:51:47 ntpd[1941]: PROTO: 0.0.0.0 c016 06 restart
        2021-06-19T09:51:47 ntpd[1941]: INIT: OpenSSL 1.1.1d 10 Sep 2019, 1010104f
        2021-06-19T09:51:47 ntpd[1941]: NTSc: Using system default root certificates.
        2021-06-19T09:51:48 ntpd[1941]: DNS: dns_probe: nts-service.lab.vn, cast_flags:1, flags:29901
        2021-06-19T09:51:48 ntpd[1941]: NTSc: DNS lookup of nts-service.lab.vn took 0.001 sec
        2021-06-19T09:51:48 ntpd[1941]: NTSc: nts_probe connecting to nts-service.lab.vn:123 => 192.168.112.133:123
        2021-06-19T09:51:48 ntpd[1941]: NTSc: Using file /var/lib/ntp/certs/rootCA.crt for root certificates.
        2021-06-19T09:51:48 ntpd[1941]: NTSc: set cert host: nts-service.lab.vn
        2021-06-19T09:51:48 ntpd[1941]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256)
        2021-06-19T09:51:48 ntpd[1941]: NTSc: certificate subject name: /C=VN/ST=Da Nnag/L=Da Nang/O=VNNIC/OU=VNNIC/CN=nts-service.lab.vn./emailAddress=trinv@vnnic.vn
        2021-06-19T09:51:48 ntpd[1941]: NTSc: certificate issuer name: /C=VN/ST=Da Nang/L=Da Nang/O=VNNIC/OU=VNNIC/CN=localhost/emailAddress=trinv@vnnic.vn
        2021-06-19T09:51:48 ntpd[1941]: NTSc: certificate invalid: 62=>Hostname mismatch
        2021-06-19T09:51:48 ntpd[1941]: NTSc: Good ALPN from: nts-service.lab.vn
        2021-06-19T09:51:48 ntpd[1941]: NTSc: read 880 bytes
        2021-06-19T09:51:48 ntpd[1941]: NTSc: Got 8 cookies, length 104, aead=15.
        2021-06-19T09:51:48 ntpd[1941]: NTSc: NTS-KE req to nts-service.lab.vn took 0.007 sec, OK
        2021-06-19T09:51:48 ntpd[1941]: DNS: dns_check: processing nts-service.lab.vn, 1, 29901
        2021-06-19T09:51:48 ntpd[1941]: DNS: Server taking: 192.168.112.133
        2021-06-19T09:51:48 ntpd[1941]: DNS: Server poking hole in restrictions for: 192.168.112.133
        2021-06-19T09:51:48 ntpd[1941]: DNS: dns_take_status: nts-service.lab.vn=>good, 0
        2021-06-19T09:51:48 ntpd[1941]: PROTO: 192.168.112.133 e014 84 reachable
        2021-06-19T09:51:54 ntpd[1941]: PROTO: 192.168.112.133 f01a 8a sys_peer
        2021-06-19T09:51:54 ntpd[1941]: PROTO: 0.0.0.0 c015 05 clock_sync

        And when i reconfig in ntp.conf: server nts-service.lab.vn:443 iburst minpoll 3 maxpoll 6 nts ca /var/lib/ntp/certs/rootCA.crt noval.
        I got logs:
        2021-06-19T09:53:54 ntpd[1965]: PROTO: 0.0.0.0 c016 06 restart
        2021-06-19T09:53:54 ntpd[1965]: INIT: OpenSSL 1.1.1d 10 Sep 2019, 1010104f
        2021-06-19T09:53:54 ntpd[1965]: NTSc: Using system default root certificates.
        2021-06-19T09:53:55 ntpd[1965]: DNS: dns_probe: nts-service.lab.vn:443, cast_flags:1, flags:29901
        2021-06-19T09:53:55 ntpd[1965]: NTSc: DNS lookup of nts-service.lab.vn:443 took 0.001 sec
        2021-06-19T09:53:55 ntpd[1965]: NTSc: nts_probe connecting to nts-service.lab.vn:443 => 192.168.112.133:123
        2021-06-19T09:53:55 ntpd[1965]: NTSc: nts_probe: connect failed: Connection refused
        2021-06-19T09:53:55 ntpd[1965]: DNS: dns_check: processing nts-service.lab.vn:443, 1, 29901
        2021-06-19T09:53:55 ntpd[1965]: DNS: dns_take_status: nts-service.lab.vn:443=>error, 12

        Do you have email? could you please send to my email: trinv@vnnic.vn or any OTT App such as: what’saap, viber, telegram ??
        Many thanks

  6. Today I discovered that Ubuntu 20.04 (focal) ntpsec_1.1.8+dfsg1-4build1 (as a client) doesn’t seem compatible with current RFC8915-compliant NTS-servers.

    The ‘ntsinfo’-command showed an increasing ‘NTS server recvs w error’-counter on the server side.

    I was able to install 1.2.0+dfsg1-4 (Ubuntu Imish 21.10) on the client side and that seemed to have done the trick.

    1. Hey Marco,

      sorry for the late response. As far as I remember there was/is a problem with the byte order in NTPsec. Possibly it is an implementation problem. Do you somehow have raw data from an NTS-secured NTPv4 request and response? Then I can probably tell you exactly ;)

      I can also read it on-the-fly in hex form :D

  7. Hi Martin,
    1. What is the plan for horizontal scaling of NTS servers with NTPSec?
    2. If my NTS server goes down for some reason and is replaced by a new NTS server with the same public IP behind my NTS FQDN, will the client be able to use the same set of cookies it has from the previous server?

    1. Hey Saurabh,

      nice to see that some people are interested in a secured time transfer ;)

      About your questions:
      1: Nothing at the moment. If I understand you correctly, you mean multiple NTS capable NTP servers of the same stratum. For such a synchronization the symmetric mode is provided in NTP, but this is not supported by NTS. The solution here would be to use the client-server mode in both directions between two servers. Maybe NTPsec will offer a solution one day, but I’m not a developer with them ;)

      2: Usually no, but it depends on the client and server implementation. The server would have to store the current master key and load it after a reboot (instead of regenerating it). The clients would need to save at least one cookie as well and try again with it later. But the clients will probably contact the NTS-KE server after several failed attempts to get new cookies. Only then would clients realize that the NTP server is really down. ….but yes theoretically this would work.

      I hope I could help you ;)

  8. Hi Martin,

    I have been trying to load test NTS-KE(Phase 1). In NTS Server logs we see below line for successful transaction.

    2021-09-21T14:07:31 ntpd[21078]: NTSs: NTS-KE from xx.xxx.xxx.xx:59476, Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256), took 0.003 sec, CPU: 1.766+0.000 ms

    Average time taken in NTS-KE transaction is 0.003 seconds(as per logs), so does that mean NTS server can not handle more than 333 parallel requests in a single second or it can not handle more than ~333 TPS load for NTS-KE requests? Is this statement correct? Also is there any load tool available to load test NTS at this moment?

    1. …ah…
      to make it short… 333 TPS is only the case, if the TLS server operates in synchronous mode instead ansynchronous mode. But this is not a NTP/NTS setting, it is the realization of the implementation itself.

  9. Hello Saurabh,

    it depends a lot on the implementation. An NTS-KE server (=TLS-server) should run asynchronously in a good implementation to be able to process requests in parallel. Professional time servers usually distribute the requests internally to different CPU cores. With applications like NTPsec it is probably not the case, because here most people use client applications or small private time servers.

    Test tools do not exist as far as I know. But you could have several clients on one server, each spamming only TLS requests. Maybe that would be a possibility.

    best regards,
    martin

  10. Hello,
    I Have Ubuntu 20.04 (focal) with ntpsec_1.1.8+dfsg1-4build1 (as a client) and it doesn’t seem compatible with current RFC8915-compliant NTS-servers. I’ve configured ntp.conf with time.cloudflare.com:1234, I’ve tested with port 4460 but it fails too. Debug with journalctl command show me that the TLS connection is OK, but I’m still stuck with Stratum 16.
    Do you please tell how to install nts 1.2.0 package and also do you confirm that even cloudflare use the nts port 4460.
    Thanks a lot.
    Best Regards.
    Mozart

    1. Hello Mozart,

      Looks like you are faster than me :)
      I’m not sure right now if Cloudflare still uses port 1234. According to the NTS standard it must be 4460. Do not have the opportunity to test this right now.

      have a nice day ;)

    1. Hello Marco,

      thanks for sharing, I tested these server yesterday and It was good! Perfect!
      Have a nice day

  11. @Martin Langer

    I’m working with a Meinberg Lantime M300, which apparently does not yet support the certificate exchange. I need to upload the correct certificate for each NTS server i want to use as peer.

    How do i get these standalone .pem certificates? Is there a global pem certificate repository where i can get those?

    (Please keep in mind im using windows and most of the NTS servers do not have a http webend to download these certificates from).

    Danke,
    Arnout

    1. Hello Arnout,

      I’m quiet not sure if I understand you correctly. Do you want to create your own certificates for these devices or do you want extract existing certificates? It has been several years since I have had contact with a Meinberg Lantime. Therefore I’m not sure if they have certificates and how you can get them (especially in Windows).

      If you want to create keys/certificates in Winows, I can recommend the open-source program xca (X Certificate). But I don’t know how to integrate these certificates into the devices. I accessed the Meinberg units via SSH at that time. They are running a customized Linux system. But I don’t have much memory of that anymore.

      …maybe you can use the Meinberg Device Manager. It is available on their website, it works on Windows and it is free.

      best regards,
      Martin

  12. Martin,
    Sorry i wasnt clear before.
    I want to add a certificate of a remote NTS server i need my Lantime to sync with.
    However, i need to manually add/load all the relevant certificates through the user interface, since it does not support the certificate-exchange through port KE server.

    How do i get the certificates (.pem) for the servers i want to use?

    Hope this is more clear :)

    1. Hello Arnout,

      theoretically you could extend existing PEM certificates and add more, because it is a Base64 format. However, I don’t really know how to get or set the certificates on these devices. It’s just been too long since I worked with these and meanwhile there were several firmware updates.

      Today I talked to a Meinberg employee. He said that the certificate exchange in NTS generally works. However, with self-signed certificates, they must be set manually, just as you described. He then referred to the ticket system (https://www.meinbergglobal.com/english/support/tech-support.htm). Since I haven’t worked with Meinberg’s NTS implementation yet and don’t know the current user interface, I probably can’t help you much. I think the Meinberg support would be the best place for you to go. I know the people and I think they can help you much better. German and English is no problem for them.

      If you take this step, then you can give a short report. Maybe it can help others as well.

      Sorry that I can barely help you.

      Many greetings,
      Martin

  13. I’ve recently upgraded my tiny stratum 1 time server (running on a Raspberry Pi) to NTPsec and added the necessary SSL certificate to enable NTS on it (this blog post has been very helpful in that respect).
    And I’ve added a couple of peers that support NTS, so I now know that the client-side NTS configuration is correct and working, but I have no way to test the server-side NTS configuration (other than a low-level TLS test to port 4460, which succeeded).
    Would anyone who is operating a time server with NTS capabilities be interested in adding mine to their list of peers, so that I can see if the NTS server side is working correctly, too? If you are interested, the server is available at time.falk.us and supports NTP (123) and NTS (4460).

    1. @ Alexander,
      for your information, I added your NTS time.falk.us to my ntp.conf file and it seems to work well:

      some logs about your server from my ntpd:

      ntpd[64070]: DNS: dns_probe: time.falk.us:4460, cast_flags:1, flags:21901
      ntpd[64070]: NTSc: DNS lookup of time.falk.us:4460 took 0.249 sec
      ntpd[64070]: NTSc: connecting to time.falk.us:4460 => 74.104.167.114:4460
      ntpd[64070]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256)
      ntpd[64070]: NTSc: certificate subject name: /CN=*.falk.us
      ntpd[64070]: NTSc: certificate issuer name: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo ECC Domain Validation Secure Server CA
      ntpd[64070]: NTSc: SAN:DNS *.falk.us, falk.us
      ntpd[64070]: NTSc: certificate is valid.
      ntpd[64070]: NTSc: read 880 bytes
      ntpd[64070]: NTSc: Got 8 cookies, length 104, aead=15.
      ntpd[64070]: NTSc: NTS-KE req to time.falk.us:4460 took 0.740 sec, OK
      ntpd[64070]: DNS: dns_check: processing time.falk.us:4460, 1, 21901
      ntpd[64070]: DNS: Server taking: 74.104.167.114
      ntpd[64070]: DNS: dns_take_status: time.falk.us:4460=>good, 0

      and the output of ntpq -p from my server (I guess your server is the last line):

      remote refid st t when poll reach delay offset jitter
      =======================================================================================================
      -syrte8.obspm.fr 145.238.203.14 2 u – 128 377 6.2580 1.0559 1.0028
      -orfeo.duckcorp.org 210.65.119.71 2 u 128 128 377 18.3048 6.6828 0.2150
      -gw1.rbx.ip4.servme.fr 51.15.191.239 3 u 5 128 377 9.1487 -0.2324 0.0779
      -ks312903.kimsufi.com 82.64.45.50 2 u 74 128 377 9.4491 0.6894 0.0764
      +ptbtime2.ptb.de .PTB. 1 u 117 128 377 20.3761 0.9705 0.1780
      +82-64-45-50.subs.proxad.net .GPS. 1 u 50 128 277 15.5189 0.5837 0.2048
      *85.199.214.102 .GPS. 1 u 56 128 377 14.8802 0.7335 1.6050
      -time.cloudflare.com 10.21.8.4 3 5 502 128 210 6.0114 1.3979 0.1456
      +ptbtime1.ptb.de .PTB. 1 6 303 128 104 20.5964 1.0539 0.4387
      ntppool1.time.nl .NTS4. 1 1 60m 1024 0 21.8965 0.5511 0.0000
      static-74-104-167-114.bstnma.fios.veriz .PPS. 1 3 758 128 40 96.8499 0.2332 0.0910

      My NTPsec server is a VPS test server ntp.viarouge.net located in France, it should support NTP (123) and NTS (4460).

      1. @Hubert,
        Thank you for the feedback – sounds like everything is working nicely. Really appreciate you taking the time to send back the results.

  14. TY for the guide. minor correction when adding ntp to group ntp:

    # add user ‘ntp’ to group ‘ntp’
    sudo addgroup ntp ntp

    i get an error. i think code is meant to be:

    sudo adduser ntp ntp

  15. Hi Martin Langer,

    Sorry for bothering you. I’ve set up a Linux NTS server, but I want the Windows machines to be able to connect to NTS on this server, and I don’t know how to do it. Can you suggest a tool to connect NTS from Windows to the NTP/NTS server? Currently, I can only connect directly using the SNTP protocol on port 123.

    Thank you.

    1. Hi Duc,

      No problem. I’m not sure if you’re using Chrony or NTPsec, but the NTS port is 4460 TCP, while NTP runs on 123 UDP. NTS on Windows is difficult because there is currently no implementation for it. The reason for this is that Windows does not come with a PLL/FLL to discipline the clock, which NTP would require. You have to implement this manually.

      There is an NTS/NTP version for Windows/Linux on my Git repository (https://gitlab.com/MLanger), but it is out of date. …the implementation will be overhauled in the coming months.

      kind regards,
      Martin

  16. Hi Martin Langer,

    Sorry for bothering you. I build two hosts(Ubuntu 22.04) in VMware, one is a client and another is a server. Both install ntpsec. Server uses local time and client uses server’s time. I configured well and I can find the TLS connection and NTS packets using wireshark. I am curious about why all the NTS packets contain only one cookie.

    Thank you!
    Ethan

    1. Hi Ethan,

      oh you’re not bothering me and I’m happy to help :)

      Some details about the cookies.
      ————————————–
      During the TLS phase, the NTP client gets a total of 8 cookies, all containing the same payload (core information), which I’ll get to in a moment. There is no particular reason why 8 was agreed upon rather than 6 or 10. During the NTS specification work, 8 seemed simply sufficient.

      After the TLS phase, the NTP communication between NTP client and NTP server starts. If possible, the client always inserts the oldest cookie from its cookie pool into the NTP message and cryptographically secures the NTP packet with NTS. The client then sends the message to the NTP server and deletes the cookie from its pool. Now there are only 7 left. If the server successfully verifies the NTP request, it also sends back an NTS-secured NTP message with a freshly generated cookie. Unlike the client, the server does not store any cookies and discards everything it received from the client after sending the message (the server is stateless). If the client successfully verifies the server response, it stores the cookie in its pool and uses the time data from the NTP packet for clock synchronization.

      But why do this with 8 cookies?
      —————————————–
      Simple: If a message does not arrive or is corrupt, the client can simply generate a new NTS secured NTP request. It then informs the NTP server with ‘cookie placeholders’ that it now wants 2 cookies in the response, so it has 8 cookies again. If several requests are lost in a row, the number of cookies in the client’s pool will decrease and the client will request more and more cookies from the time server. Only if 8 messages are lost in a row and the pool is empty, the NTP client has to request new cookies via TLS.

      Why not just use 1 cookie over and over again if all cookies contain the same payload anyway?
      ——————————————————————————————————
      This is not a technical issue. Theoretically, the client could use only one cookie and the server would not even have to send one back. The payload is identical, but all cookies look “different”. This fulfills the NTS objective of unlinkability. If you used only 1 cookie over and over again, your device could be tracked by the NTP client. Even if your device (PC, mobile phone) changes the IP or the network several times, you could be identified by the NTS cookie if it always looks the same. For this reason, all cookies look different and are only used once per message.

      What is in the cookies?
      ———————————-
      The cookies contain the identifier for the AEAD algorithm and the keys that can be used to verify or cryptographically secure the NTP packet. However, this information is encrypted with a master key known only to the NTS server (= also the NTS-KE server …typically). Only the NTP server can decrypt and encrypt the cookies. An attacker intercepting the cookies cannot read or modify them. The NTP client cannot do this either, although it knows this information anyway.

      I hope I could help you.
      If not, let me know :)

Leave a Reply

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