BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News CloudFlare Releases Open Source Implementation of Network Time Security Protocol

CloudFlare Releases Open Source Implementation of Network Time Security Protocol

This item in japanese

CloudFlare announced the first major release of their implementation of the Network Time Security (NTS) protocol. This builds on their previous release of time.cloudflare.com, their free time service that supports both Network Time Protocol (NTP) and NTS.

CloudFlare's free time service, time.cloudflare.com, supports both NTP and the emerging NTS protocols. However, at the time of its release there were not many NTS clients available. With the release of their new CFNTS project, CloudFlare is hoping to encourage adoption of the NTS protocol. NTPSec has also recently released support for NTS.

CloudFlare recommends enabling NTS if you use either NTPsec or their new CFNTS project with time.cloudflare.com. They do note that your daemon will need TLS 1.3 support.

NTS is a suite of two sub-protocols. The first is the Network Time Security Key Exchange (NTS-KE). This protocol is responsible for handling creation of the key material and parameter negotiation for the second protocol, NTPv4. NTPv4, the current version of the NTP protocol, allows the client to synchronize the time from the remote server.

As Watson Ladd, cryptography engineer at CloudFlare, and Pop Chunhapanya, software engineer at CloudFlare, note:

In order to maintain the scalability of NTPv4, it was important that the server not maintain per-client state. A very small server can serve millions of NTP clients. Maintaining this property while providing security is achieved with cookies that the server provides to the client that contain the server state.

To accomplish this in the first stage the client will send a request to the NTS-KE server and get a response over TLS. Within this stage there are a number of functions:

  • Negotiating the AEAD algorithm to be used in the second stage
  • Negotiating the second protocol (currently the standard only defines how NTS works with NTPv4)
  • Negotiating the NTP server IP address and port
  • Creating cookies for use in the second stage
  • Creating two symmetric keys (C2S and S2C) from the TLS session

First stage of the NTS process

First stage of the NTS process (credit: CloudFlare)

 

In the second stage, the client can now securely synchronize their clock with the negotiated NTP server. To ensure this is done securely, the client sends NTPv4 packets with four extensions. The first extension, the unique identifier extension, contains a random nonce used to prevent replay attacks. The next extension, NTS cookie extensions, provides the client with one of the two cookies. As only the client remembers the two AEAD keys (C2S and S2C), the server needs this cookie in order to extract the keys. Each cookie contains the keys encrypted under a secret key held by the server.

In the third extension, NTS cookie placeholder extension, a signal is sent from the client to request additional cookies from the server. This is needed to ensure the response is not significantly longer than the request to prevent amplification attacks. The final extension, NTS authenticator and encrypted extension fields extension, contains a ciphertext from the AEAD algorithm with C2S as the key and the NTP header, timestamps, and all previous extensions as associated data. This header is required to prevent the timestamp from being spoofed.

As noted by Ladd and Chunhapanya:

The second handshake can be repeated many times without going back to the first stage since each request and response gives the client a new cookie. The expensive public key operations in TLS are thus amortized over a large number of requests.

The team decided to implement their service in Rust, which was a deviation from their usual language of choice, Go. As the authors note, they decided on Rust since a "garbage collection pause in the middle of responding to an NTP packet would negatively impact accuracy". They also noted Rust's memory safety, non-nullability, thread safety, immutability, and error handling features as key considerations in the choice.

Along with this release, CloudFlare has added their time service to the public NTP pool. The NTP pool is a volunteer-maintained service that provides NTP servers across the world. However, they note that NTS doesn't work well within the pool model. For the best security, CloudFlare recommends enabling NTS and using time.cloudflare.com or other NTS supporting servers.

The CFNTS service has been open-sourced under the 2-Clause BSD license. CloudFlare is hopeful that their solution will enable more clients to support NTS in the future. They are actively seeking contributions to the codebase.

Rate this Article

Adoption
Style

BT