IBM z17 NTS Enhancements: Securing Time Synchronization

Background

Until 2010, there was relatively little concern given to the subject of the security of time synchronization protocols.  Even after 2010, until the mid-2010s, the majority of the technical discussions and innovations for time synchronization still focused on accuracy enhancements.  

For the longest time, NTP relied on pre-shared symmetric keys to ensure the integrity and authenticity of NTP messages. Truth be told, and with hindsight being 20/20, this relatively simplistic approach proved insufficient security against a determined attacker due to its lack of scalability.  

The Autokey protocol, described in IETF RFC 5906, was introduced in 2010 for NTPv4 to address security concerns. However, in 2012, a post-incident attack analysis revealed serious design flaws in Autokey, and it is no longer recommended for use.  

In 2014, the landmark RFC 7384 “Security Requirements of Time Protocols in Packet Switched Networks” was ratified and published. This, in turn, motivated the development of the Network Time Security (NTS) protocol, which was published as RFC 8915 in October 2020.  

NTS was originally intended for both NTP and for the Precision Time Protocol (PTP).  However, some additional work was needed for a PTP version, and RFC 8915 is solely for NTP.  NTS4NTP supports the NTPv4 client-server mode. Work on NTS4PTP is ongoing as of this writing and is expected to be completed soon. 

What Exactly is NTS?

Simply stated, NTS is a security extension and authentication mechanism for NTP and is designed to scale substantial clients. It is a security protocol for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide a cryptographic security mechanism for the NTPv4’s client-server mode. NTS provides strong cryptographic protection against packet manipulation, robustness against packet loss, minimal loss of accuracy due to the security process, and tracking prevention. Unlike pre-shared symmetric keys, NTS scales well.  

With NTS4NTP, the secured NTP data traffic is untouched, and the time data is not encrypted; instead, it is authenticated. So, with NTS, we have a robust, scalable protocol for securing NTP with minimal loss of accuracy to a reference time source due to the NTS protocol itself, verifies that the packets received from NTP server machines are unaltered while moving to the client machine. 

NTS includes its own key establishment protocol (NTS-KE) that automatically creates the encryption keys used between the NTP server and its clients. 

NTS Objectives

RFC 8915 lists and explains nine objectives for NTS.  They are as follows:

1. Authentication: NTS implementations can cryptographically verify that any (all) time synchronization packets were produced by an identified party, and they have not been modified in transit.  
2. Performance: NTS must not degrade (significantly) the quality of the time transfer.  In other words, the encryption used when transferring time synchronization data traffic should be “lightweight”.
3. Identity: NTS implementations can cryptographically establish the identity of the party(ies) they are communicating with through the use of a X.509 public key infrastructure.  (For more information on X.509 public key infrastructures, please refer to this article that appeared in the 21 June 2019 Linux Journal).  
4. Scalability: An NTS server implementation can serve large numbers of clients without having to retain any client-specific state information.
5. Replay prevention: NTS client implementations can detect when a received (time synchronization) packet is a replay of a previously transmitted packet.
6. Unlinkability: NTS will not leak any information additional to NTP information which would permit an adversary to determine that two packets which were sent over different networks came from the same NTP client. 
7. Confidentiality: Basic time synchronization data traffic is considered non-confidential and sent in the clear.  However, NTS does include support for encrypting NTP extension fields.
8. Non-amplification: NTP server implementations can avoid acting as a distributed denial-of-service (DDoS) amplifier by never responding to a request with a packet larger than the request packet.
9. Request-response consistency:  NTP client implementations can verify that a time synchronization packet received from an NTP server was sent in response to a particular request from an NTP client.

Overview of the NTS Protocol

While it has been previously stated, it is important enough to repeat here: NTS is exclusively for the client-server mode of NTP.  

The client-server mode of NTP places more stringent requirements on resource utilization than the other modes of NTP. This is because NTP servers typically have a vast number of clients and cannot afford to maintain per-client state.  

However, since only the NTP client in client-server mode requires replay protection (it is harmless for a stateless server to process replayed packets), the NTP client-server mode has more relaxed security needs. 

Some of the other NTP modes include symmetric peers, broadcast mode, and a control mode intended for monitoring and administering the NTP protocol itself. These other modes have differing and often contradictory security requirements. The remainder of this section will summarize the NTS protocol.  

For a full treatment of the NTS protocol, please refer to RFC 8915 sections 3-9.

NTS secured communications

The  NTS secured communications consists of three parts:

1. A Transport Layer Security v1.3 (TLSv1.3) handshake.  (NTS requires TLS v1.3 and does not support earlier versions of TLS).
2. Parameters negotiation
3. The secured time transmission

When taken together, the TLS handshake connection and the parameters negotiation form what was formally known as “the NTS key establishment protocol (NTS-KE).”  NTS-KE is a mechanism for establishing key material for use with the NTS Extension Fields for NTPv4.

NTS-KE uses TLSv1.3 to establish the keys, provide the client with an initial supply of cookies, and negotiate additional protocol options. TLSv1.3 enables peer authentication by certificates and provides authentication, message integrity, and confidentiality for the data transmitted over the TLS channel.

The second of the two protocols comprising the NTS protocol suite are the NTS Extension Fields for NTPv4. These extension fields are defined for cryptographically securing NTPv4 using the previously established key material (from the NTS-KE protocol).

Phase One

In phase one of the NTS protocol flow, an NTP client connects to an NTS-KE server on the NTS TCP port (port 4460), and the two parties perform a TLS handshake.  As part of this flow, the server will send the client a supply of cookies along with the address and port of an NTP server for which the cookies are valid (this NTP server can be the same server as the NTS-KE server, or it may be a different server).  

TLS Key Export (RFC 5705) is used to extract the key material, which is used in the next phase of the NTS protocol (see below). All this negotiation work is done during a single round trip, after which the NTP server closes the TLS connection and discards any associated state information. This concludes the NTS-KE phase of the protocol, and ideally, the client never needs to reconnect to the NTS-KE server.

Phase Two

In phase two of the NTS protocol flow, time synchronization proceeds with the indicated NTP server. NTP uses the aforementioned NTP extension fields to transfer encrypted security parameters in the form of cookies sent between the NTP client and NTP time server.  

The NTP client sends the NTP server a client packet that includes several extension fields, including a cookie previously provided by the key establishment server. Also included is an authentication tag, which is computed using key material extracted from the NTS-KE handshake.  

Phase Three

In phase three of the NTS protocol flow, the NTP server uses the cookie to recover the key material and send back an authenticated response. This response includes a fresh, encrypted cookie that the client subsequently sends back in the clear. It is this constant refreshing of cookies that enables the achievement of NTS’s unlinkability goal.

Summary and Conclusion

IBM z17 introduced multiple significant enhancements to its NTP implementation that, when correctly implemented, should enhance IBM z17 end users’ time synchronization security.  

These enhancements make for a more secure NTP implementation on IBM z than was attainable prior to IBM z17.

For more details, please refer to the references listed below.  You may also contact me via email: steve.guendert[at]ibm.com