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:
- Raspbian Buster Lite (2019-09-26)
- NTPsec 1.1.8
- OpenSSL 1.1.1d
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:
- AEAD algorithms
- 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:
|
1 2 3 |
# update system sudo apt update sudo apt upgrade |
Next, we check the OpenSSL version, which must be 1.1.1b or higher:
|
1 2 |
# check openssl version openssl version |
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, …).
|
1 2 3 |
# disable the local time service sudo systemctl stop systemd-timesyncd.service sudo systemctl disable systemd-timesyncd.service |
If an NTP service (e.g. NTPD) is used instead, we can remove it as follows:
|
1 2 |
# remove NTP sudo apt remove --auto-remove ntp |
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:
|
1 |
apt show ntpsec | grep Version |
If version 1.1.8 is available, we can simply install it as follows:
|
1 |
sudo apt install ntpsec |
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.
|
1 2 3 4 5 6 7 |
# install basic tools and compilers (g++, gcc, make, ...) sudo apt install build-essential # create a temporary directory cd /home/pi mkdir ntpsec_source cd ntpsec_source |
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
|
1 2 3 4 5 6 |
# install git sudo apt install git # clone the NTPsec git repository (recent version) git clone https://gitlab.com/NTPsec/ntpsec.git cd ntpsec |
Variant 2: Downloading Binaries
|
1 2 3 4 5 6 |
# download the current NTPsec version as tarball wget https://gitlab.com/NTPsec/ntpsec/-/archive/NTPsec_1_1_8/ntpsec-NTPsec_1_1_8.tar.gz # extract the source code tar xfz ntpsec-NTPsec_1_1_8.tar.gz cd ntpsec-NTPsec_1_1_8 |
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:
|
1 2 |
# install necessary packages sudo ./buildprep |
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.).
|
1 2 |
# configure NTPsec: default path (/usr/local) and reference clock support ./waf configure --refclock=all |
Finally, we build the source code and install the binaries:
|
1 2 3 4 5 6 7 8 9 |
# build NTPsec ./waf build # install NTPsec sudo ./waf install # delete the temporary working directory (NTPsec source code) cd ../.. rm -r -f ntpsec_source |
Let’s check the NTPsec version number:
|
1 2 |
# check NTPsec version sudo /usr/local/sbin/ntpd -V |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# create ntp directories sudo mkdir -p /var/lib/ntp/certs sudo mkdir -p /var/log/ntpstats # add system user 'ntp' sudo adduser --system --no-create-home --disabled-login --gecos '' ntp # add group 'ntp' sudo addgroup --system ntp # add user 'ntp' to group 'ntp' sudo adduser ntp ntp # set folder permissions (recursive) sudo chown -R ntp:ntp /var/lib/ntp /var/log/ntpstats # enable the NTPsec service sudo systemctl enable ntpd |
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:
|
1 2 3 |
# create NTP config file sudo touch /etc/ntp.conf sudo nano /etc/ntp.conf |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# 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 # 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 # optional: allows a fast frequency error correction on startup driftfile /var/lib/ntp/ntp.drift # optional: collect statistics statsdir /var/log/ntpstats statistics loopstats peerstats clockstats rawstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable filegen rawstats file rawstats type day enable # optional: logging logfile /var/log/ntp.log logconfig =syncall +clockall +peerall +sysall |
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:
|
1 |
sudo wget http://nts3-e.ostfalia.de/homePi/CLIENT/rootCaBundle.pem -P /var/lib/ntp/certs/ |
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:
|
1 2 3 4 5 6 7 |
server <name>: The destination NTP time server (DNS name or IP address) iburst: Sends 8 NTP requests directly after startup minpoll <val>: Minimal request interval (power of two) maxpoll <val>: Maximal request interval (e.g: '6' means 2^6 = 64 sec) nts: [NTS] Enables NTS support ca <file>: [NTS] The trusted root CA certificate for the server noval: [NTS] Skips the DNS verification |
Server Configuration
The configuration of the server is a little easier:
|
1 2 3 |
server 127.127.1.0 prefer fudge 127.127.1.0 stratum 10 nts enable cert /var/lib/ntp/certs/serverCert.pem key /var/lib/ntp/certs/serverKey.pem |
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:
|
1 |
sudo systemctl start ntpd |
After this, the service should run, which we can easily check:
|
1 2 |
# check NTPsec service systemctl status ntpd |
The whole thing should look like this:
|
1 2 3 4 5 6 7 8 9 10 |
● ntpd.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntpd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-11-25 09:48:25 CET; 27min ago Docs: man:ntpd(8) Process: 498 ExecStart=/usr/local/sbin/ntpd -g -N -u ntp:ntp (code=exited, status=0/SUCCESS) Main PID: 504 (ntpd) Tasks: 3 (limit: 2200) Memory: 26.9M CGroup: /system.slice/ntpd.service └─504 /usr/local/sbin/ntpd -g -N -u ntp:ntp |
Manual Start of NTPsec:
Of course, you can also start NTPsec manually:
|
1 |
sudo /usr/local/sbin/ntpd |
If you also want to see the log output live, then you need to specify some parameters:
|
1 |
sudo /usr/local/sbin/ntpd -n -d |
For an NTS-secured NTP client (here from example 3 of the configuration) we see the following:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
2019-11-20T05:22:15 ntpd[6847]: INIT: ntpd ntpsec-1.1.8+ 2019-11-20T03:55:12Z (git rev 905721870): Starting 2019-11-20T05:22:15 ntpd[6847]: INIT: Command line: /usr/local/sbin/ntpd -n -d 2019-11-20T05:22:15 ntpd[6847]: INIT: precision = 2.031 usec (-19) 2019-11-20T05:22:15 ntpd[6847]: INIT: successfully locked into RAM 2019-11-20T05:22:15 ntpd[6847]: CONFIG: readconfig: parsing file: /etc/ntp.conf 2019-11-20T05:22:15 ntpd[6847]: LOG: switching logging to file /home/pi/ntpsec/ntp.log 2019-11-20T05:22:15 ntpd[6847]: INIT: Using SO_TIMESTAMPNS 2019-11-20T05:22:15 ntpd[6847]: IO: Listen and drop on 0 v6wildcard [::]:123 2019-11-20T05:22:15 ntpd[6847]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123 2019-11-20T05:22:15 ntpd[6847]: IO: Listen normally on 2 lo 127.0.0.1:123 2019-11-20T05:22:15 ntpd[6847]: IO: Listen normally on 3 wlan0 192.168.2.102:123 2019-11-20T05:22:15 ntpd[6847]: IO: Listen normally on 4 lo [::1]:123 2019-11-20T05:22:15 ntpd[6847]: IO: Listen normally on 5 wlan0 [fe80::63dc:3600:6bad:c768%3]:123 2019-11-20T05:22:15 ntpd[6847]: IO: Listening on routing socket on fd #22 for interface updates 2019-11-20T05:22:15 ntpd[6847]: PROTO: 0.0.0.0 c011 81 mobilize assoc 59451 2019-11-20T05:22:15 ntpd[6847]: INIT: This system has a 32-bit time_t. 2019-11-20T05:22:15 ntpd[6847]: INIT: This ntpd will fail on 2038-01-19T03:14:07Z. 2019-11-20T05:22:15 ntpd[6847]: PROTO: 0.0.0.0 c01d 0d kern kernel time sync enabled 2019-11-20T05:22:15 ntpd[6847]: PROTO: 0.0.0.0 c012 02 freq_set kernel 0.000000 PPM 2019-11-20T05:22:15 ntpd[6847]: PROTO: 0.0.0.0 c011 01 freq_not_set 2019-11-20T05:22:15 ntpd[6847]: PROTO: 0.0.0.0 c016 06 restart 2019-11-20T05:22:15 ntpd[6847]: INIT: OpenSSL 1.1.1d 10 Sep 2019, 1010104f 2019-11-20T05:22:15 ntpd[6847]: NTSc: Using system default root certificates. 2019-11-20T05:22:16 ntpd[6847]: DNS: dns_probe: nts3-e.ostfalia.de:443, cast_flags:1, flags:21901 2019-11-20T05:22:16 ntpd[6847]: NTSc: DNS lookup of nts3-e.ostfalia.de:443 took 0.009 sec 2019-11-20T05:22:16 ntpd[6847]: NTSc: nts_probe connecting to nts3-e.ostfalia.de:443 => 141.41.241.70:123 2019-11-20T05:22:17 ntpd[6847]: NTSc: Using file /home/pi/CLIENT/rootCaBundle.pem for root certificates. 2019-11-20T05:22:17 ntpd[6847]: NTSc: set cert host: nts3-e.ostfalia.de 2019-11-20T05:22:17 ntpd[6847]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256) 2019-11-20T05:22:17 ntpd[6847]: NTSc: certificate subject name: /C=DE/ST=NDS/L=Wolfenbuettel/O=Ostfalia/CN=nts3-e.ostfalia.de 2019-11-20T05:22:17 ntpd[6847]: NTSc: certificate issuer name: /C=DE/ST=NDS/L=Wolfenbuettel/O=Ostfalia/CN=OstfaliaRootCA 2019-11-20T05:22:17 ntpd[6847]: NTSc: certificate is valid. 2019-11-20T05:22:17 ntpd[6847]: NTSc: Good ALPN from: nts3-e.ostfalia.de:443 2019-11-20T05:22:17 ntpd[6847]: NTSc: read 848 bytes 2019-11-20T05:22:17 ntpd[6847]: NTSc: Got 8 cookies, length 100, aead=15. 2019-11-20T05:22:17 ntpd[6847]: NTSc: NTS-KE req to nts3-e.ostfalia.de:443 took 0.056 sec, OK 2019-11-20T05:22:17 ntpd[6847]: DNS: dns_check: processing nts3-e.ostfalia.de:443, 1, 21901 2019-11-20T05:22:17 ntpd[6847]: DNS: Server taking: 141.41.241.70 2019-11-20T05:22:17 ntpd[6847]: DNS: dns_take_status: nts3-e.ostfalia.de:443=>good, 0 2019-11-20T05:22:17 ntpd[6847]: PROTO: 141.41.241.70 e014 84 reachable 2019-11-20T05:22:22 ntpd[6847]: PROTO: 141.41.241.70 f01a 8a sys_peer 2019-11-20T05:22:22 ntpd[6847]: PROTO: 0.0.0.0 c014 04 freq_mode |
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:
|
1 |
/usr/local/bin/ntpq -p |
The NTS-Secured NTP Client:
|
1 2 3 |
remote refid st t when poll reach delay offset jitter =============================================================================== *nts3-e.ostfalia 192.53.103.104 2 8 3 8 377 6.0908 0.9518 1.3586 |
As you can see, the synchronization works fine. No packet loss and a small time offset.
The NTS-Secured NTP Server:
|
1 2 3 |
remote refid st t when poll reach delay offset jitter =============================================================================== *LOCAL(0) .LOCL. 10 l 31 64 77 0.0000 0.0000 0.0000 |
The server side also works, but gives less information.
NTS Status:
The following command allows us to view the NTS statistics:
|
1 |
/usr/local/bin/ntpq -c nts |
If we use both NTS client and NTS server at the same time, then we get these values:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
NTS client sends: 63 NTS client recvs good: 63 NTS client recvs w error: 0 NTS server recvs good: 24 NTS server recvs w error: 7 NTS server sends: 24 NTS make cookies: 48 NTS decode cookies: 31 NTS decode cookies old: 0 NTS decode cookies too old: 0 NTS decode cookies error: 0 NTS KE probes good: 1 NTS KE probes_bad: 0 NTS KE serves good: 3 NTS KE serves_bad: 0 |
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.
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.
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.
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.
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.
good stuff, thx
I setup all my NTP servers with NTS, one of them is public. Not sure if not having a fixed IP can be an issue, does the DNS been checked from time to time?
Here the small quide I did for just the use of NTS as a client
https://www.signorini.ch/content/nts-with-ntpsec
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
Hello Martin,
thanks a ton for your answer! And for the good news, looking forward to have Chrony with NTS on a stable release :)
Cheers
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 :)
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 ;)
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!
Hey Attilio,
unfortunately I have not received any further feedback so far. I’ll try again and probably get back to you tomorrow ;)
ok :)
Support for NTS is planned for next year. I send you a mail :)
Very helpful, thank you so much!
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!
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
Perfect, that did the trick, thank you for your help, Martin!
And I’m from Germany, no NTS filtering by my provider here…
Hi Martin,
Is there a list being maintained somewhere which NTP servers are NTS-capable?
Best regards,
Marco
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-
Thanks for the quick reply and the effort you’ve put in NTS.
I hope we can extend NTS for PTP soon (https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/)
let me know if you have any questions :)
-martin-
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
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
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.
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!
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
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-
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?
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
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. 「(⌒_⌒;)
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
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
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
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
Hi Matin.
I’ve follow this instructions:
https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309
Is it ok ?
Thanks
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
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
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
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
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.
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
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?
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 ;)
Thanks Martin for your response.
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?
…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.
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
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
All is OK woth NTPsec 1.2.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 ;)
Hello
time.cloudflare.com:4460 is OK
Thanks Martin
Just a small update:
As described on https://nts.time.nl/, our NTS servers are now ntppool1.time.nl and ntppool2.time.nl.
thank you.
this is pretty neat :)
Hello Marco,
thanks for sharing, I tested these server yesterday and It was good! Perfect!
Have a nice day
@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
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
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 :)
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
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).
As a ‘one time’ quick check you could do:
chronyd -Q -t 3 ‘server nts1.time.nl iburst nts maxsamples 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).
@Hubert,
Thank you for the feedback – sounds like everything is working nicely. Really appreciate you taking the time to send back the results.
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
Uh yeah, thanks for this. I corrected it!
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.
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
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
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 :)