Network Time Security adds cryptographic authentication to NTP client-server mode. A client sets up keys over TLS, then every time packet carries an authenticator. NTS stops forged time responses from off-path and on-path attackers, but it cannot stop an attacker from delaying packets.
The two parts
RFC 8915 defines two sub-protocols.
NTS Key Establishment (NTS-KE) runs over TLS. The client connects to TCP port 4460, TLS must be version 1.3 or later, and the ALPN identifier is ntske/1. Keys are derived from the TLS exporter. The server then closes the connection and keeps no per-client state, so the whole step takes one round trip.
NTS extension fields for NTPv4 protect the actual time exchange. Each request carries a cookie, a unique identifier and an authenticator. The server recovers session keys from the cookie, so it stores nothing per client. Each response brings fresh encrypted cookies, and the client uses a new one in each later request, which supports unlinkability.
What is authenticated
- The 48 octet NTP header is authenticated but not encrypted.
- Extension fields are authenticated, including the unique identifier and cookie.
- An AEAD authenticator covers the header and preceding extensions.
The stated goals include identity through X.509 certificates, authentication of time packets, replay prevention, request and response consistency, non-amplification so it cannot be used for DDoS reflection, and scalability.
What NTS does not protect
The RFC is clear about the limits:
- Header confidentiality. Header fields stay visible.
- Delay attacks. An on-path attacker can delay packets asymmetrically. Cryptography cannot prevent it, but the RFC bounds the error at half the round trip delay.
- Legacy tracking. NTS does not fix existing NTP linkability, and servers can still track clients.
- NTS-KE traffic. Unlinkability covers time synchronization, not key establishment.
- Spoofed Kiss-o'-Death packets. On-path attackers can send unauthenticated KoD replies.
- Clock dependent certificate checks. A client with a badly wrong clock may fail to validate the server certificate dates.
- Downgrade. Clients should not silently fall back to plain NTP without user action.
The chicken and egg problem
NTS validates a certificate, which needs roughly correct time, to get correct time. The RFC suggests mitigations but offers no complete fix. In practice, rely on a reasonable hardware clock, and bootstrap carefully on devices that lose power. Basics of the protocol are in NTP stratum, offset and delay.
Adoption checklist
- Check whether your time servers and client software support NTS.
- Allow TCP 4460 outbound for NTS-KE, in addition to UDP 123.
- Alert on silent fallback to unauthenticated NTP.
- Keep several sources and compare them.
- Log time offset so a large step is visible.
Where Safeguard fits
This topic sits below where Safeguard works. Safeguard helps with the application side: scanning dependencies for known vulnerabilities, including in the networking, TLS and HTTP libraries you pull in, and gating pull requests with policies. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Does NTS encrypt the NTP header?
No. The header is authenticated but not encrypted.
Can NTS stop an attacker delaying packets?
No. The RFC says it cannot prevent delay attacks, only bound the error to half the round trip delay.
Sources
Last reviewed: 19 October 2026.
