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.
The Internet Engineering Task Force (IETF) published the Network Time Security protocol (NTS) as RFC 8915 on October 1, 2020. This new standard offers security mechanisms for the widely used Network Time Protocol v4 (NTPv4), which has been operated mostly unsecured until now. After almost eight years of development, global collaboration, and many interoperability tests of leading NTP software developers, NTS represents a mature security protocol. In this post, I’ll give you a short overview of the development progress of NTS and provide a list of public implementations and NTS secured time servers…
Network Time Security in a Nutshell
NTS generally is a cryptographic security extension for time protocols. It offers the necessary authenticity and integrity of the transmitted time messages without significant loss of synchronization accuracy. This enables the detection of manipulated time information before it can cause damage.
NTS consists in principle of two loosely coupled sub-protocols. The first phase employs the NTS Key Establishment (NTS-KE) protocol in which the NTP client verifies the authenticity of the time server via a TLSv1.3 connection. Furthermore, client and server also transfer the security parameters (e.g. AEAD algorithms) using this secured TLS channel and generate the key material. In the second phase, the specific time protocol follows, which is extended by the NTS content. With NTPv4 these are so-called “NTS extension fields for NTP” that transport the integrity checksum of the time message as well as cookies. These cookies allow the time server to operate statelessly and to generate secure NTP messages. In addition to authenticity and integrity, NTS offers further advantages such as good scalability, tracking protection, and key freshness. Well-known attacks such as replay, spoofing, amplification DDoS and downgrade/stripping are fended off by the NTS protocol as well.
A detailed description of how NTS works can be found in my first post.
Recent Changes to the NTS Specification
In the last 1-2 years, only a few changes have been made to the NTS specification, mainly due to the results of interoperability testing of different NTS implementations. At the time of my first post, NTS was in draft version 20. Up to the publication of the RFC standard, the protocol structure had not changed, but the use of TLSv1.2 as phase one protocol is now prohibited.
The following table shows the main changes to the NTS specification that have been made since draft version 20:
| Version | Major changes to the previous version |
| draft-21 | – New error code added in NTS-KE (error 2: “Internal Server Error”) |
| draft-22 | – Clarification of some definitions |
| draft-23 | – Definition of the NTP Extension Field identifiers for NTS content |
| draft-24 | – The content of the NTS Cookie Placeholder should be zero instead of undefined |
| draft-25 | – Now both server and client must send a “close notify” when closing the TLS channel |
| draft-26 | – The maximum retry interval for connection problems (NTS-KE) was defined to 7 days – The TLS Exporter Label has been changed to “EXPORTER-network-time-security” – TLSv1.2 is no longer permitted. TLSv1.3 must be used! |
| draft-27 | – The max. retry interval for connection problems (NTS-KE) has been changed to 5 days |
| draft-28 | – Clarification of some definitions |
| RFC 8915 | – NTS Extensions for NTPv4 renamed to NTS Extension Fields for NTPv4 – Specification of the NTS-KE service: – Service Name: ntske – Transport Protocol: TCP – Port Number: 4460 |
Origin and Development History of NTS
The development of the NTS protocol followed shortly after the release of NTPv4 in 2010. Since NTP is one of the oldest Internet protocols at all, security was not a priority for a long time. Although the previous version of NTPv3 already contained a protection mechanism in which client and server use fixed symmetric keys, this solution scaled poorly. The approach is not practical for today’s use of NTP, where the time of thousands of devices is synchronized over the Internet. Luckily, this problem was solved by the Autokey method, which the IETF published together with NTPv4 and extended the security mechanisms of NTP.
At about the same time, the development of intelligent electricity meters (“smart meters“) took place in Germany as part of the Energiewende (transition to renewable energy sources). These should gradually replace the old electricity meters and are also installed in charging stations for electric vehicles. Such devices require reliable tariff and time information for the price determination, which must fulfill the calibration laws. For the time synchronization of these devices, an Autokey-secured NTPv4 connection was considered. The Physikalisch-Technische Bundesanstalt (PTB), which distributes the legal time in Germany, analyzed the Autokey protocol in cooperation with the Technische Universität Braunschweig. The results showed serious flaws in the security mechanisms that a computer could break within a few seconds. This marked the start of the development of a new protocol in the IETF NTP Working Group, from which NTS eventually emerged. In cooperation with PTB, which was the main author of the NTS draft at the beginning, I developed the first Proof-of-Concept (PoC) implementation of NTS within the scope of my master’s thesis (at Ostfalia University of Applied Sciences). The result proved the functionality but showed some disadvantages of the NTS message structures as well. After a complete redesign of the NTS protocol, further PoC implementations followed and provided many new test possibilities. After exhaustive testing and due to the collaboration of many people, the Network Time Security protocol has been finally released this year.
The following table shows significant events that have occurred since the release of NTPv4:
| Date | Event |
| 06/2010 | – NTPv4 has been published as RFC standard – Autokey was released as a security enhancement for NTPv4 (Informational RFC) |
| 09/2011 | – Analysis of the AutoKey procedure revealed fatal flaws [report: german/english] |
| 03/2012 | – Presentation of the analysis results at the IETF 83 |
| 07/2012 | – Plan for Autokey update – A new draft has been created: Autokey v2 |
| 06/2013 | – Autokey’s bad reputation led to the renaming of the design to Network Time Security (NTS) – The generic NTS draft covers unicast and broadcast connections as well as NTP and PTP |
| 10/2014 | – The specification of NTS messages was outsourced in a new draft: CMS4NTS |
| 05/2015 | – The Ostfalia University starts working on NTS – Plans for the first PoC-implementation |
| 06/2015 | – For NTPv4 a separate NTS draft was published: NTS4NTP – NTS4NTP considers broadcast and unicast connections of the Network Time Protocol |
| 11/2015 | – The Ostfalia University starts implementing the NTS protocol |
| 01/2016 | – The Ostfalia University starts implementing an NTP service with NTS support (NTP-O) |
| 03/2016 | – Finalization of the NTS implementation |
| 08/2016 | – Completion of the NTP-O implementation with NTS support – First measurements in practical tests |
| 09/2016 | – Last update of the NTS4NTP draft (version 06) with the first NTS protocol design – NTS is about to be completed as RFC standard |
| 10/2016 | – The NTS protocol design has been completely discarded – In NTS4NTP-draft-07 all protocol structures were revised and optimized – The NTS key exchange via NTP was replaced with a TLS-based solution – Broadcast connections are no longer supported, as they require other security methods |
| 02/2017 | – The CMS4NTS draft-06 has been discarded – The generic NTS draft-15 was rejected as well |
| 12/2017 | – The Ostfalia University develops a new NTS library and performs first measurements – The new NTS version operates with much better performance |
| 01/2018 | – The world’s first NTS-secured NTP time server goes online (nts3-e.ostfalia.de) |
| 03/2018 | – First NTS hackathon at the IETF 101 with a second PoC implementation – Both NTS implementations are based on nts4ntp-draft-11 |
| 07/2020 | – Sixth and last NTS Hackathon on IETF 108 based on nts4ntp-draft-28 – Currently, there are five NTS implementations or NTP services with NTS support – Several NTS-secured NTP time servers are online – Interoperability successfully tested |
| 10/2020 | – NTS4NTP is published as RFC 8915 – Full title: Network Time Security for the Network Time Protocol |
NTS Implementations
At this point, I would like to introduce the NTS implementations that are currently known and available. The respective developers have participated in the many IETF Hackathons and have thus decisively influenced the progress of the NTS standard. The best known representatives are NTPsec and Chrony that have been providing NTP services for a long time. Please note that some NTS implementations (e.g. NTP-O) have a PoC character and may need to be updated. You can find instructions for setting up NTPsec in conjunction with NTS here.
| NTP/NTS-Implementation | Project Pages / Sources |
| Chrony | chrony.tuxfamily.org Git Repository |
| Cloudflare (cfnts) | Git Repository |
| Netnod | Git Repository 1: Python Language Git Repository 2: Go Language |
| NTPsec | Git Repository |
| NTS-PoC (D. Franke) | Git Repository |
| Ostfalia (NTP-O) | Git Repository 1: NTS library (PoC) Git Repository 2: NTP-O |
| [NTS-KE Test Tool] | Git Repository |
Public NTS-Secured NTPv4-Servers
Of course, an NTS-secured NTP only makes sense if corresponding NTP servers are available that support the new security standard. The following table shows the first public NTP servers you can use. Most time servers use certificates signed by Let’s Encrypt, so there is nothing else to consider when setting up the NTP clients. For the remaining entries, I have linked the necessary certificates.
The NTS standard provides TCP port 4460 for the NTS KE service. Since this port has only been known for a short time, some of the servers may still use different ports.
| Provider | Address of the NTS-KE server (normally corresponds to the NTP time server too) |
| Cloudflare | time.cloudflare.com:1234 |
| Netnod | nts.ntp.se:4460 (for users anywhere in the world) nts.sth1.ntp.se:4460 (for users close to Stockholm) nts.sth2.ntp.se:4460 (for users close to Stockholm) |
| NTPsec | nts1.time.nl:123 ntp1.glypnod.com:4460 ntp2.glypnod.com:4460 |
| Ostfalia | nts3-e.ostfalia.de:4460 (stratum 2, using NTP-O) |
| PTB | ptbnts1.ptb.de:4460 (192.53.103.98, stratum 1, using NTPsec) CA certificate chain: dfn-ca-global-g2 |
More test servers can be found here.
What Happens Next?
The future is still quite uncertain, but there have already been initial discussions about NTPv5. Meanwhile, I’m concentrating on extending NTS for the Precision Time Protocol (PTP), although there is no concrete specification yet. As soon as there is something worth mentioning, I will let you know.
Thanks for reading and thanks to the members of the NTP working group and the successful completion of the NTS specification. ;)
Featured image “accessoire, antik” by Giallo is licensed under CC0.