Meta Opens Authenticated Time Service to Fix 40-Year-Old NTP Security Flaw

Meta has enabled Network Time Security on its public NTS service and published the server, client, and protocol code in a source repository. NTS, standardized in RFC 8915, uses TLS-based key establishment and authenticated NTP extension fields. A configured client can verify that accepted packets belong to its session and arrived unchanged. Server accuracy remains a separate trust decision.

NTP was first standardized in 1985, and many deployments still accept unsigned UDP responses from any system able to impersonate the configured server. A forged or delayed response can alter the local clock, which feeds several security mechanisms:

• Certificate validation: TLS clients compare certificate notBefore and notAfter values with local time.
• Credential expiry: Access tokens, signed URLs, and temporary cloud credentials depend on timestamps.
• Replay protection: Many protocols accept messages only within a defined time window.
• Incident analysis: Clock disagreement makes logs from different hosts difficult to correlate.
• Automated renewal: Certificate issuance and rotation jobs can start early, run late, or fail when the host clock drifts.

Certificate validation exposes a circular dependency because an NTS key exchange uses TLS, while TLS certificate checks require a plausible local clock. Shorter certificate lifetimes increase the frequency of those checks and renewals. The approved SC-081v3 schedule reduces maximum public TLS certificate validity to 200 days on March 15, 2026, 100 days on March 15, 2027, and 47 days on March 15, 2029.

TLS keys amortize across UDP requests

NTS confines the expensive public-key work to a key-establishment phase, then uses symmetric authentication for ordinary time requests:

1. Establish keys with NTS-KE. The client connects over TCP port 4460 using TLS 1.3 and the ntske/1 ALPN identifier. Client and server negotiate an authenticated-encryption algorithm and derive separate client-to-server and server-to-client keys through the TLS exporter. Meta’s implementation returns eight opaque cookies and identifies the UDP time server through an NTP server negotiation record.
2. Exchange authenticated NTP packets. A request carries a unique identifier, a cookie, and an authenticator; the authenticator covers everything before it, but encrypts nothing. The responder opens the cookie, recovers the session material, verifies the request, and returns a response whose authenticator covers the matching identifier. Replacement cookies travel inside encrypted extension fields and are used one at a time in later requests.

A client accepts a response only when its unique identifier matches an outstanding request, preventing a recorded response from being reused as fresh time. Meta’s responder also suppresses NTS NAK messages when authentication fails. Invalid requests therefore resemble packet loss and cannot provide a forged signal that pushes the client into another key exchange.

Cookies remove the session database

Meta’s implementation stores the session keys and related parameters inside each cookie, sealed with AES-SIV. Participating servers receive a shared master secret and derive the daily sealing key when needed:

key = HKDF-SHA256(master, salt = BE32(day), info = "fbnts-cookie-seal-v1")

The day number since the Unix epoch serves as the cookie’s key ID and remains visible so a responder can derive the correct sealing key. Meta accepts IDs from the previous two days and the following day, covering clock skew around daily rotation boundaries.

This design removes per-client session storage and daily key distribution. The NTS-KE machines and UDP responders can operate without request-time communication after administrators provision the shared master secret. Adding a responder requires that secret, network routing, and service configuration rather than a replicated session table.

Chrony needs one line and two ports

A chrony build with NTS support can use Meta’s service through a single configuration entry:

pool nts.meta.com nts iburst maxsources 5

The pool directive allows chrony to create several associations. Meta’s NTS-KE endpoint directs each association to a time.meta.com responder, with a separate TLS exchange and distinct session keys. The maxsources 5 setting requests up to five associations; Meta reports that all five may take about 20 minutes to appear.

Deployments must permit outbound TCP port 4460 for key establishment and UDP port 123 for time traffic. Operators can inspect authentication and source state with:

chronyc -N authdata
chronyc sources -v

Five Meta associations improve resilience to an individual responder failure. Protection against a common configuration error or operator compromise requires time sources run by separate organizations.

Delay survives packet authentication

NTS provides packet integrity and session provenance within a defined threat model. Several operational risks remain outside those guarantees:

Mobile clocks still lack NTS

Public server support has advanced faster than endpoint adoption. Cloudflare launched NTS in June 2019, while chrony and ntpsec now support the standard. Mainstream mobile platform clients still provide no documented path for enabling it through configuration alone.

Mobile devices may also consult cellular time signals, GNSS, stored estimates, or vendor-specific services, but those sources do not add NTS authentication to the platform’s NTP path. Meta’s release gives client maintainers a public interoperability target and reusable protocol code. Platform adoption still requires NTS-KE, NTP extension-field processing, cookie storage, cold-start handling, source selection, and monitoring.