The Network Time Protocol (NTP) is a venerable Internet protocol for synchronising time. It has been with us since at least 1985 as the most commonly used protocol for synchronising the time on computer systems. It enables devices connected to the Internet to maintain clock synchronisation with reliable time sources, such as the atomic clocks used to provide Netnod's NTP service.
Unfortunately, NTP is vulnerable to Man-in-the-Middle (MITM) attacks. This is where a malicious actor sits between you and the NTP server, and listens in on the conversation, forges messages and lies to you about time.
How serious is this? As a lot of processes are dependent on accurate time, the consequences can be very serious indeed. They can include:
- Problems establishing encrypted sessions such as Transport Layer Security (TLS)
- Incorrect timestamps on logs and transactions which can support fraudulent activities or help disguise other criminal action
- Authentication problems, attacks and issues with authentication security measures
- Issues with cryptographic signatures
NTP version 3 introduced support for symmetric authentication using pre-shared keys but this looks remarkably old-fashioned to modern eyes. It means you have to distribute a new secret key to every peer you want to talk to. This is not very realistic today, especially when operating a large, public NTP service like Netnod's.
Left: The rack at Netnod hosting the clocks; Right: Cables indicating delays in nanoseconds
Network Time Security
Network Time Security (NTS) is an attempt in the NTP working group of the Internet Engineering Task Force (IETF) to change the NTP authentication to something more useful. Netnod has participated in this standardisation effort and has sponsored the development of several implementations.
On 25 March 2020, the Internet Engineering Steering Group (IESG) of the IETF approved the NTS Internet Draft as an RFC in the Standards Track. It's currently in RFC editor queue awaiting publication as an RFC proper.
How NTS works
NTS is really two protocols: a key exchange and NTP with some new Extension Fields. The reason it’s two protocols is separation of concerns:
- The seldom used key exchange on top of standard TLS, and
- The low latency UDP-based time synchronisation path.
It works like this: First, a client initiates a key exchange using the NTS-KE protocol embedded in TLS. In this exchange it gets some secret keys (one for client-to-server communication, one for server-to-client) and some cookies to be used later. The cookies contain, in a form known only to the servers, both of the secret keys. The client also gets information about what server to query for time.
Next, the client queries a server about time using the extended NTP. It signs its query with one of the secret keys (the c2s key) and includes one of the cookies it got from the key exchange.
The server knows how to unpack the cookie and then uses the keys inside to validate the signature of the query and to sign the response. It may also generate and send a new cookie along with the time response.
The client validates the signature on the incoming packet and can then set the time knowing that it was sent from the correct server. It stores the new cookie for later use.
The key exchange server is typically running on an ordinary computer, but the slim NTS-enabled NTP is UDP-based and stateless. It can easily be served from anycast addresses and might even be implemented in hardware! The NTP server's state about each client is kept in the cookie provided by the client itself with each request. Since in Netnod's case there can potentially be hundreds of millions of clients, this is crucial for the smooth operation of a large-scale NTP service.
Since the cryptographic operations in the NTP path are symmetric it's both easier to implement them in hardware and to make them use constant time. This increases the accuracy of the time synchronisation and keeps the slower key exchange outside of the time synchronisation path.
Netnod launched one of the first NTS-enabled NTP services in the world on 28 October 2019. It's available to the public at:
- nts.ntp.se (for users anywhere in the world)
- nts.sth1.ntp.se & nts.sth2.ntp.se (for users close to Stockholm)
Use port 3443 for the NTS-KE key exchange.
Some current NTP clients supporting NTS (two of which were written by Netnod staff) include:
- ntpsec (written by Eric Raymond)
- A Python implementation (written by Christer Weinigel)
- A Go implementation (written by Michael Cardell Widerkrantz, Daniel Lublin and Martin Samuelsson)
Joachim Strömbergson and Peter Magnusson from Assured have been asked by Netnod to work on a Verilog implementation of the extended NTP.
Why take time from Netnod?
On behalf of the Swedish Post and Telecom Authority (PTS) Netnod keeps a Verilog implementation of NTP with attached atomic clocks running in locations across Sweden. This means you speak NTP directly to the FPGA chip! As there is no software involved, you get the most accurate time possible. The service is available to the general public worldwide for free on ntp.se, which resolves to anycast IPv4 and IPv6 addresses.
A Xilinx FPGA development board similar to the one used in Netnod's FPGA NTP server
On our website you can find more information about Netnod’s NTS enabled time service. You can also find information about how to set up an NTS client.
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Li H •
unknown ipv6, isp ran many years. it is showing location and name server. lladd gateway with name isp unknown appearing recent months , all using on-track.org => location in .se stoholm ... if older, replaced new ipv6 fetching to be identified on sntp which set at sg3xx own device, what is your advice for? please have your returning on it? Sincerely Li HUANG
Marco Davids •
Interesting read! Other interested readers may also be interested in: https://time.nl (in English and Dutch)