Network time synchronization protocols have been evolving for more than 30 years. Initially, security was not a priority because the security of timestamps was not seen as a critical need. After all, the time of day is not a secret, and any attempts to hide or authenticate the source of timestamps add additional latency. This additional latency had a negative impact on the overall objective of time synchronization between two devices. The protocols were lightweight and not deemed to put a burden onto the infrastructure. The perceived risk of attacks targeting clocks was quite low. This environment resulted in time synchronization protocols that did not include robust security functionality in the initial designs. Since then, synchronized time has become an important requirement in applications, as well as in general security mechanisms. As a result, as with other protocols and applications, security functionality is now identified as a necessary and integral part of network time synchronization.
The Network Time Protocol (NTP) was initially published as RFC 958 (https://www.rfc-editor.org/info/rfc0958) in 1985. The current version, RFC 5905 (https://www.rfc-editor.org/info/rfc5905), was published as a standards track in 2010. These versions of NTP provided a basic preshared key scheme for authentication of time servers by clients. However, the preshared key approach does not scale sufficiently for large-scale network deployments or the global Internet. As a result, the Autokey Authentication Protocol, RFC 5906 (https://www.rfc-editor.org/info/rfc5906) was published as an Informational RFC in 2010 to address the scaling issue. With Autokey, clients authenticate time servers using Public Key Infrastructure (PKI) mechanisms. Security analysis, however, has demonstrated a number of security issues with Autokey. Because of the shortcomings of preshared key and Autokey mechanisms, there has been an ongoing effort in the IETF to provide updated security mechanisms for NTP.
Deployment Examples
Security for time synchronization is increasingly important, as several applications in the critical infrastructure domain depend on timing information. Possible examples for domain specific applications include:
- Synchronization of Phasor Measurement Units in the energy transmission and/or distribution network. These devices provide information about voltage, current, and phase angle used to derive the current state of the electricity network. Security for the synchronization between these units is a cornerstone in the reliable operation of the transmission/distribution networks.
- Synchronization in substation automation networks to ensure the correct operation of protection devices (in conjunction with protocols like GOOSE (Generic Object Oriented Substation Event) or SV (Sampled Values).
- Synchronization of machine parts in motion control in the process industry, for instance in a rolling mill or for printing presses.
- Synchronization of logging information in distributed systems to enable error tracking and thereby contribute to system stability and system integrity.
- New regulations of the finance sector raise high demands on the time synchronization of business clocks in trading systems. This is especially true in high-frequency trading, where a new EU legislation called Markets in Financial Instruments Directive (MiFID II) requires a timestamping granularity of 1 ms and a maximal divergence to UTC from 100 m Similar requirements are formulated by the US Securities and Exchange Commission (SEC Rule 613).
- Many national metrology institutes in Europe and in the US apply NTP for the dissemination of UTC.
- Security management, specifically the increasing usage of X.509 certificates, relies on time for validity checks. As this builds the base for many applications, security is a necessary prerequisite.
Requirements Analysis
In advance of the IETF NTP security efforts, the IETF TICTOC Working Group assessed the security requirements for network time synchronization protocols. RFC 7384 (http://www.rfc-editor.org/info/rfc7384) documents the results of that analysis. It distinguishes the threat model in terms of an internal versus an external attacker, and in terms of man-in-the-midde (MITM) versus packet injection types of attacks. RFC 7384 then identifies several potential threats to network time synchronization protocols including:
- Manipulation of time synchronization packets,
- Masquerading as a legitimate participant in the time synchronization protocol,
- Replay of legitimate packets,
- Tricking nodes into believing time from the wrong master,
- Intercepting and removing valid synchronization packets,
- Delaying legitimate time synchronization packets on the network,
- Denial of service attacks on the network at layer 2 and layer 3,
- Denial of service by overloading the cryptographic processing components,
- Denial of service by overloading the time synchronization protocol,
- Corruption of the time source used by the grand master,
- Protocol design and implementation vulnerabilities, and
- Using the time synchronization protocol for broader network surveillance and fingerprinting types of activities.
RFC 7384 analyzes these threats in the context of the threat model above to determine the likelihood of occurrence and the potential impact. Based on this analysis, a set of requirements were identified for time synchronization protocols and mapped to the threats that they address. These requirements include:
- Authentication and authorization of a clock’s identity,
- Integrity of the time synchronization protocol messages,
- Prevention of various spoofing techniques,
- Protection against Denial of Service (availability),
- Protection against packet replay,
- Timely refreshing of cryptographic keys,
- Support for both unicast and multicast security associations,
- Minimal impact on synchronization performance,
- Confidentiality of the data in the time synchronization messages,
- Protection against packet delay and interception, and
- Operation in a mixed secure and non-secure environment.
The requirements are analyzed in terms of being required and being recommended/optional depending on the needs of the application. This analysis informed the objectives of the NTP Working Group effort on Network Time Security (NTS).
NTP Security
The IETF NTP Working Group is focused on the development of a set of security mechanisms for NTP that are specified in the Internet Draft “Network Time Security for the Network Time Protocol” (https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp). The main objectives of the NTS measures are to enable NTP entities to cryptographically identify their communication partner, to ensure authenticity and integrity of exchanged time synchronization packets, and to provide replay protection. A relatively new goal of NTS is to provide unlinkability, which ensures that NTS does not leak any data that would allow an attacker to track mobile NTP clients, when they move between different networks. Although NTS can provide confidentiality for specific NTP extension fields, the NTP header itself will not be encrypted.
NTP provides different modes of operation. Besides the most utilized client-server mode, it also provides a mode for synchronization of symmetric peers, a mode for exchanging control messages, and a broadcast mode. These modes have different security and performance requirements. The symmetric and control modes have more-rigorous security requirements when compared to the client-server mode. However, the client-server mode requires more attention to resource utilization, since NTP servers may be contacted by a high number of clients and may not able to maintain state information for each client. NTS provides different mechanisms to meet these different requirements.
Symmetric and Control Mode
NTP’s symmetric and control modes are protected by encapsulating the corresponding packets as DTLS Applications Data, respectively. This provides mutual authentication and replay protection. It also provides confidentiality, which is required by certain NTP control messages. This solution is somewhat controversial and is being considered for publication as an Experimental RFC.
Client-Server Mode
There are two security related phases for client-server mode. In the first phase, an NTP client verifies the authenticity of its time server and performs the key exchange. In the second phase, the client and server exchange NTP messages. The first phase is performed once during the establishment of an NTP association. The second phase is repeated for as long as the NTP association is active.
First Phase: Authentication and Key Exchange
The current draft defines an NTS key exchange protocol that uses the TLS protocol to provide a secure and robust means for the initial authentication of the server and the subsequent exchange of the keying material. Since TLS requires a TCP connection between client and server, an NTS enabled NTP server must not only listen to port 123/UDP, but also to a TCP port that will be assigned by IANA.
Note that earlier versions of this draft (up to version 6) defined a custom key exchange protocol in which the authentication and key exchange messages were encapsulated into NTP extension fields that were piggy-backed onto NTP packets. This key exchange protocol has been discarded because of potential security issues related to IP fragmentation.
Second Phase: Protection of the Time Synchronization
During the second phase, NTS introduces four new Extension Fields (EF) to satisfy the security objectives. The latencies introduced by cryptographic algorithms may impede the time synchronization performance. It is therefore imperative that the applied cryptographic primitives be fast to calculate. This requirement is met by applying only symmetric cryptography. The four new extension fields are:
- The NTS Unique-Identifier extension. This EF contains a 32-octet random value that serves as nonce and protects the client against replay attacks.
- The NTS Cookie extension. This EF contains information that enables the server to recalculate keys upon receipt. The server does not have to keep per-client state. This EF is opaque to the client.
- The NTS Cookie Placeholder extension. This EF is sent whenever the client wishes to receive a new cookie. The server sends an NTS Cookie extension for each received NTS Cookie Placeholder extension. This EF enables NTS to fulfill the unlinkability requirement.
- The NTS Authenticator and Encrypted Extensions extension. This EF contains the ICV, which is computed over the NTP header and any preceding EF. It is calculated by applying the Authenticated Encryption with Associated Data approach.
Broadcast Mode
The current draft does not provide any cryptographic security measures to protect NTP’s broadcast mode. This is due to the difficulty of specifying an appropriate mechanism that is resistant to packet-delay attacks. A TESLA-like mechanism is being considered, but because NTP does not provide periodical two-way packet delay measurements, it is especially vulnerable against tailored delay attacks. Further countermeasures have been discussed, but additional study is required in order to specify additional security measures for NTP’s broadcast mode.
Best Current Practice
Beyond the specification of NTS, the NTP community is addressing security concerns via corrections to the specification, improvements to the implementation, and the issuance of an NTP BCP (https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp).
Related Activity
In addition to the NTP security work, there is work on time synchronization security for the Precision Time Protocol (PTP, IEEE 1588). PTP was originally published in 2002 with a focus on precision synchronization for instrumentation, industrial automation, and military applications. The second version was finalized in 2008, and includes more application use cases, such as telecom and enterprise environments. While the first version of PTP contained no security mechanisms, the second version was published with an Experimental Annex (Annex K). Annex K specified a security solution that provided group source authentication, message integrity, and replay attack protection. However, Annex K was not well adopted and implemented, and a number of studies were published regarding its weaknesses. Therefore, the ongoing effort to revise IEEE 1588 includes a plan to provide updated security mechanisms for PTP. These efforts are being coordinated.
Next Steps
As of the completion of this article, the work in the IETF NTP Working Group has not been finalized. However, while it is true that the efforts are still evolving, they do appear to be converging towards some consensus. As of this date, it appears that the NTS mechanism for client/server described here is progressing towards a standards track RFC, and the DTLS mapping suggested for symmetric and control modes may be published as an Experimental RFC. It is hoped that there will be new stable, published security mechanisms for NTP in 2018.
A preliminary implementation of NTS is underway, and additional implementations have been indicated. Interoperability testing, vulnerability research and analysis, and operational testing will be needed to ensure that the proposed solutions are robust and secure. While there is still much work to do, significant progress has been made.
Acknowledgement
K. O’Donoghue, D. Sibold, S. Fries, “New Security Mechanisms for Network Time Synchronization Protocols”, presented at International IEEE Symposium on Precision Clock Synchronization for Measurement, Control, and Communication (ISPCS 2017), IEEE, Monterey, California, USA, 2017, https://www.internetsociety.org/wp-content/uploads/2017/10/ispcs-2017-time-security-final-copyright.pdf.