Huston: Revisiting time

Geoff Huston looks at the networktime protocol, and efforts to secure it, in detail.

NTP operates in the clear, and it is often the case that theservers used by a client are not local. This provides anopportunity for an adversary to disrupt an NTP session, bymasquerading as a NTP server, or altering NTP payloads in an effortto disrupt a client's time-of-day clock. Many application-levelprotocols are time sensitive, including TLS, HTTPS, DNSSEC andNFS. Most Cloud applications rely on a coordinated time todetermine the most recent version of a data object. Disrupting timecan cause significant chaos in distributed network environments.

While it can be relatively straightforward to secure a TCP-basedprotocol by adding an initial TLS handshake and operating a TLSshim between TCP and the application traffic, it's not sostraightforward to use TLS in place of a UDP-based protocol forNTP. TLS can add significant jitter to the packet exchange. Wherethe privacy of the UDP payload is essential, then DTLS mightconceivably be considered, but in the case of NTP the privacy ofthe timestamps is not essential, but the veracity and authenticityof the server is important.

NTS, a secured version of NTP, is designed to address thisrequirement relating to the veracity and authenticity of packetspassed from a NTS server to an NTS client. The protocol adds a NTSKey Establishment protocol (NTS-KE) in additional to a conventionalNTPv4 UDP packet exchange (RFC 8915).