New Security Mechanisms for Network Time Synchronization Protocols Karen O’Donoghue Dieter Sibold Steffen Fries Internet Society PTB Siemens AG, CT RDA ITS Reston, Virgina, USA Braunschweig, Germany Munich, Germany [email protected] [email protected] [email protected] Abstract— As evolving security concerns have prevailed, the Task Force (IETF), to provide updated security mechanisms network time synchronization protocol community has been for NTP. actively engaged in the development of improved security mechanisms for both the IEEE 1588 Precision Time Protocol The Precision Time Protocol (PTP, IEEE 1588) was (PTP) and the IETF Network Time Protocol (NTP). These originally published in 2002 with a focus on precision activities have matured to the point where this year should see synchronization for instrumentation, industrial automation, and the finalization of the first new security mechanisms for time military applications. The second version was finalized in 2008 protocols in ten years. This paper provides an overview of the [6] including more application use cases, such as telecom and two solutions being developed, compares and contrasts those enterprise environments. While the first version of PTP solutions, and discusses relevant use cases and deployment contained no security mechanisms, the second version was scenarios. published with an Experimental Annex (Annex K). Annex K specified a security solution that provided group source Keywords—time synchronization protocols; PTP; IEEE 1588; authentication, message integrity, and replay attack protection. NTP; NTS; security; authentication; integrity. 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 I. INTRODUCTION AND BACKGROUND includes a plan to provide updated security mechanisms for Network time synchronization protocols have been PTP. evolving for over thirty years. At the beginning, security was There has been growing recognition by the network time not a priority because the security of timestamps was not seen synchronization community that the operational environment as an immediate need based on the requirements and use cases and the application use cases have changed significantly, and under consideration at the time. The protocols were lightweight security must now be addressed in a thorough and systematic and not deemed to put a burden onto the infrastructure. The manner. This evolution of time synchronization protocol perceived risk of attacks targeting clocks was quite low. This security requirements and motivations is discussed in some environment resulted in time synchronization protocols that did detail in [7]. This paper goes on to discuss the resulting work in not include security functionality in the initial designs. In the the IETF TICTOC working group and the IEEE PTP security intervening years synchronized time has become an important subcommittee to identify time synchronization security requirement not only in applications but also in security requirements. RFC 7384 [8] documents the results of that mechanisms themselves. Hence, as for other protocols and analysis. applications, security functionality has been identified as a necessary and integral part of network time synchronization The security approaches discussed in this paper provide approaches. security counter measures addressing these requirements. It connects to the previous work and provides an overview about The Network Time Protocol (NTP) was published as RFC the current state of standardization of the two emerging time 958 [1] initially in 1985 with the current version being synchronization approaches, IEEE 1588 (PTP) with integrated published as a standards track RFC (RFC 5905 [2]) in 2010. security and the IETF Network Time Security (NTS). As of These early versions of NTP provided a basic pre-shared key July 2017, the effort to address security in both the NTP and scheme for authentication of time servers by clients. However, the PTP technical communities is still in progress; however, it the pre-shared key approach did not scale enough for large has reached significant technical consensus over the past year. scale network deployments or the global Internet. Therefore, This paper is intended to provide the community with the the Autokey Authentication Protocol (RFC 5906 [3]) was technical highlights of both of the security approaches. published in 2010 to address the scaling issue. With Autokey, clients authenticate time servers using public key infrastructure II. PTP SECURITY (PKI) mechanisms. Security analysis, however, has The IEEE 1588 revision defines four solution classes demonstrated a number of security issues with Autokey. [4] (called prongs) to address the diversity of application [5]. Because of the shortcomings of pre-shared key and requirements and considerations identified in [8]. These Autokey, there is an ongoing effort in the Internet Engineering solution classes can be used individually or in combination. Instant key sharing is typically achieved by group based These classes of solutions include: A) integrated PTP security key management protocols like the Group Domain Of mechanisms; B) external transport security mechanisms; C) Interpretation (GDOI) and specified in RFC 6407 [9]. The architectural mechanisms; and D) monitoring and availability of the group key enables immediate security management. These classes are explained with more detail in processing of the received PTP messages. An example for the corresponding subsections. In addition to the four prongs, delayed key sharing is based on TESLA as specified in RFC the IEEE 1588 revision provides some additional information 4082 [10]. Here, the key is shared after its active usage time on security practices and considerations that can be used to and enables the security processing on the receiver side. The improve the security posture of the overall system. latter option requires the storage of the messages for later security checks but also enables source authentication directly. A. Integrated Security Mechanism The first approach utilizes a group key and enables immediate The first solution class being defined by the IEEE 1588 actions, but only ensures that a member of the group has Security Subcommittee is a security mechanism integrated into provided the message and not which member exactly. PTP itself. This solution class is intended to be deployable by any PTP system regardless of the underlying transport being The support of these various options stems from the nature used. It provides both authentication of the PTP entity and of multicast communication. Here, source authentication is integrity protection of the PTP message. It does not aim to viewed in two different ways: protect the confidentiality of the PTP message itself because of - The authentication source is a key distribution server the non-secret nature of the included timestamps. resulting in a distributed group key or The foundation of the PTP integrated security mechanism - The authentication source is the receiver of a PTP is a Security TLV (Tag Length Value) that is added as an packet directly resulting in a delayed key disclosure. extension to the PTP message being secured. The content of the securityTLV depends on the PTP entity communicating and the key management protocol being utilized. The format of the newly defined securityTLV is shown in Figure 1 below. As shown, the securityTLV is added at the end of the PTP message and contains, beyond other information, an Integrity Check Value (ICV), which ensures the authenticity of the PTP information. The ICV is built using a hash function (HMAC- SHA-256-128) or AES in MAC mode (AES-GMAC-128). The secret key is provided by the associated key management. The current draft of the IEEE 1588 revision does not require a FIGURE 2: SECURITY TLV CONTENT specific key management scheme, choosing instead to allow Figure 2 shows the general structure of the securityTLV. different key management approaches. There is an informative The detailed content is as follows: annex that suggests two specific approaches for different scenarios. These approaches are discussed in more detail - Security Parameter Pointer (SPP): Together with below. information from the PTP header like the source port identity, the SPP is used to find the right security association containing necessary key management parameter - secParamIndicator: indicates which of the optional fields are used - keyID: identifies the currently used key - disclosedKey: contains the disclosed key in the case of a delayed key sharing approach. This field is only used after a defined time period and is optional. - sequenceNumber: is an optional field to extend the sequence number field as part of the original PTP header FIGURE 1: SECURITY TLV EMBEDDED IN PTP MESSAGE - RES: is an optional reserved field for potential future use With the current definition of the securityTLV, both unicast - ICV: carries the integrity check value of the PTP and multicast PTP communication can be secured. This degree packet for the packet content as marked in Figure 1 of freedom was achieved by requiring an out-of-band key management mechanism. One of the primary challenges for the As stated above, PTP itself does not mandate any specific definition of the securityTLV in conjunction with key key management approach, but recommends two schemes, management was the need to provide the utilized key instantly which are outlined in the following