Summary

  • NTS can establish the identity of an NTS-KE endpoint and authenticate an NTP reply against an outstanding request. It cannot certify that the server's clock is correct, remove asymmetric network delay, select among disagreeing sources or authorize a local clock step.
  • A defensible time decision joins four separate records: certificate and key establishment, packet authentication, source fitness and selection, and local clock discipline. If those layers are collapsed into one green “secure” state, a valid signature can be mistaken for authority over the machine.

Two green checks, one unresolved clock

The opening is a controlled thought experiment, not a reported outage. Source A and source B have separately valid certificates. Each NTS-KE exchange succeeds. Each server supplies cookies and key material. The subsequent NTP replies authenticate, echo their respective outstanding identifiers and survive replay checks. One says the local clock is nearly correct; the other implies an 800-millisecond correction.

Nothing in that result requires the cryptography to be broken. One source may have bad upstream time. One path may have asymmetric delay. One reply may have a root distance outside the client's policy. The sources may simply fall outside the intersection required by the selection algorithm. The correct local result can be A, B, a combined estimate, or no synchronization at all.

That last result matters. Refusing to move a clock when evidence does not cohere is not protocol failure. It is an exercise of local authority.

What NTS actually authenticates

RFC 8915 divides the work into two protocols. NTS Key Establishment runs over TLS. The time-transfer phase uses NTS extension fields in NTP client-server packets. The separation lets the expensive identity and key negotiation finish before the lightweight exchanges that carry time.

NTS-KE uses TCP port 4460, TLS 1.3 or later and the ALPN identifier ntske/1. The server can name the NTP endpoint, negotiate an authenticated-encryption algorithm and issue an initial supply of opaque cookies. TLS exporter material produces directional keys: one for client-to-server traffic and another for server-to-client traffic. The TLS connection then closes, and the server need not retain per-client state.

The client returns that state inside a cookie. Its NTP request also carries a unique identifier and an authenticator. A proper reply must authenticate under the server-to-client key and echo an identifier belonging to an outstanding request. Fresh cookies can travel back in the protected extension field so the client can replenish its supply without making successive network appearances easily linkable.

These mechanics establish a precise proposition. An accepted response was produced by the party associated with the NTS keys, was not modified in transit and corresponds to a request the client actually made. The proposition is valuable. It is also smaller than “this is the right time.”

IANA's registry reinforces the boundary. It assigns interoperable type values for the Unique Identifier, NTS Cookie, Cookie Placeholder, and Authenticator and Encrypted Extension Fields. It records the shared grammar. It does not evaluate a server's oscillator, upstream references or operational judgment.

Identity is not accuracy

A certificate answers an identity question about the NTS-KE service. It does not inspect the clock behind that service. A cookie lets a stateless server recover the parameters needed to authenticate an exchange. It is not a certificate of UTC. A matching unique identifier binds response to request. It does not prove that the path was symmetric.

RFC 8915 makes the delay boundary explicit. An on-path adversary can delay traffic asymmetrically without changing or reordering packet contents. The authentication checks can all succeed while the computed offset moves away from reality. Cryptography cannot feasibly remove that attack because the manipulated variable is transit time, not protected content. The client's maximum-distance policy bounds exposure, and multiple sources or paths can improve resilience, but neither measure turns authentication into truth.

The confidentiality boundary is equally narrow. Basic NTP header data remain visible. NTS can encrypt extension fields; it is not blanket encryption for every part of a time packet. Availability also remains separate. An on-path actor can drop traffic, and some Kiss-o'-Death behavior remains outside authentication. Secure time transfer still depends on network reachability and careful failure policy.

For the same reason, an implementation should not silently fall back from NTS to plain NTP when key establishment fails. That convenience would create a stripping path: an attacker could cause the protected mode to fail and obtain an unauthenticated result. A downgrade is a local policy decision and should require explicit action.

The bootstrap clock is already a policy choice

NTS uses X.509 certificates, whose validity periods are evaluated against time. A machine that needs network time because its clock is wrong may therefore need enough approximate time to validate the service that will help correct it. This circularity cannot be solved by a slogan.

RFC 8915 discusses several imperfect anchors: a battery-backed clock, a manually supplied estimate, persistent last-known time and comparison across multiple sources. A reply received immediately after key establishment should also be consistent with the certificate's validity interval. None of these means the certificate supplies exact time. They establish a plausibility window within which identity verification can begin.

The operator is choosing the bootstrap authority even before the first authenticated measurement arrives. Which trust anchors are accepted? How stale may persisted time be? Can certificate-time checks be relaxed, and for how long? How many independent sources must agree before the system clock changes? A deployment that cannot answer these questions has not eliminated trust; it has hidden it in defaults.

Packet acceptance precedes source selection

RFC 5905 describes a chain that remains local to the client. Packet processing produces measurements. A clock filter reduces noise for each association. The selection algorithm seeks an intersection supported by a majority of credible candidates. Clustering removes outliers. Combining produces a final offset. Clock discipline then decides how to steer time and frequency.

NTS strengthens the first part of that chain. It helps the client reject forged or replayed responses before treating them as measurements. It does not replace the later algorithms. An authenticated source can still be a falseticker. A measurement can still be rejected for excessive delay or root distance. If too few candidates survive, the system can remain unsynchronized.

Current chrony documentation exposes these layers separately. The authdata report shows whether a source uses NTS, how often key establishment succeeded, how many attempts or negative acknowledgements occurred and how many cookies remain. Source reports separately show reachability, selection state and disagreement. maxdelay and related tests can reject suspiciously delayed measurements. minsources can require more than one selectable source before the local clock is updated. Trust and requirement flags can control how authenticated and unauthenticated sources participate in selection.

NTPsec exposes another operational surface for NTS certificates, clients, servers and cookie-key persistence. The differences between implementations are not a defect in the standard. They show where interoperability ends and operator policy begins.

Four proofs, not one badge

A useful audit should preserve four linked but independent proofs.

First is the identity proof: which NTS-KE name was configured, which certificate chain and service identity were accepted, which trust set was used, and when key establishment completed.

Second is the packet proof: which key generation, unique identifier, cookie state and authenticator accepted the response; whether the response matched an outstanding request; and whether replay or NTS negative-acknowledgement handling changed the state.

Third is the measurement proof: observed offset, delay, dispersion, root distance, reachability, source history, intersection and outlier status. This is where an authentic response may become an unusable measurement.

Fourth is the actuation proof: which source or combination was selected, which threshold permitted a slew or step, which process made the change and what the previous clock state was. This is the record of authority over the machine.

A dashboard that keeps only “NTS: yes” preserves the first two layers incompletely and erases the other two. It can demonstrate use of a security mechanism without explaining why the clock moved.

The minimum common rule and the local decision

Heng Lu's Minimum Initial Specification provides a useful reading of the boundary. The common layer should carry the deterministic rules necessary for interoperability, shared safety and security. Later operational choices remain with participants running code. Publication of a rule is not the same as adoption, and shared syntax is not a permanent grant of decision power.

NTS fits that architecture when read narrowly. The IETF specifies how endpoints negotiate, derive keys, carry state and validate protected fields. IANA records shared numbers. A certificate authority participates in endpoint identity. None of those actors selects the client's source set, sets its maximum distance, chooses whether a bootstrap estimate is adequate or authorizes settimeofday on the host.

Running-Code Primacy adds the operational test. A security document matters because independently operated systems can implement and verify it. Its legitimacy comes from a check the client can perform, not from a remote institution's ability to command the clock. The client may accept a packet and still reject the measurement. It may trust an endpoint and still refuse a step. That is not disobedience; it is the intended separation of layers.

Evidence and scope

The 800-millisecond disagreement is illustrative. It names no provider, product defect, incident or attacker. The protocol claims are drawn from the following frozen sources: