Summary

  • RFC 8915 requires one client-generated, cryptographically secure random Unique Identifier of at least 32 octets in every NTS-protected request; the server echoes the same value.
  • The client processes a response only when that value matches an outstanding request and the packet authenticates under the corresponding server-to-client key.
  • This is strong replay detection and request correlation, not a stable identity, an NTS cookie, proof of a person or device, or evidence that the returned time is correct.

A token made for one unanswered question

Imagine two valid-looking time replies arriving close together. Both carry plausible timestamps. One is the answer to the request the client just sent; the other is an authentic packet recorded earlier and delivered again. Packet authenticity alone does not tell the client which response belongs to the question still on its desk.

RFC 8915 gives the client a separate receipt. For each NTS-protected request it includes exactly one Unique Identifier extension field. The client produces the field body with a cryptographically secure random-number generator, and the value must be at least 32 octets long. When the server answers, it must copy precisely that octet string into exactly one response field. The client then asks two questions together: does the value match an outstanding request, and is the packet authentic under the server-to-client key associated with that request? If either answer is no, the packet is discarded without further processing.

That conjunction matters. A captured value is visible on the wire because the Unique Identifier must not be encrypted. Yet it must be authenticated. In an NTS packet it sits in the integrity-protected portion preceding the authenticator, so an observer may read the token but cannot substitute a different one and still produce a valid response. Confidentiality and integrity are different properties; “not encrypted” does not mean “not protected.”

The result is an exchange identifier. It lets one client distinguish its current outstanding question from old or invented replies. It is not issued by the server, does not survive as an account handle, and does not tell an observer which human or device is behind the request. The scope of its uniqueness is the protocol job it performs, not the biography of its sender.

Why the old timestamp was not enough

NTP already had a correlation mechanism. RFC 5905 defines the 64-bit origin timestamp as the time at the client when the request departed. A server returns that value, and the client can compare it with its transmitted-request state. The NTP processing rules use origin and transmit timestamps to reject bogus, duplicate or replayed packets.

RFC 8915 does not pretend that history never existed. It explains why the origin timestamp is a weak cryptographic challenge: the field is only 64 bits, and implementation choices may make most of those bits predictable. Time is useful evidence about chronology, but a clock value is not automatically an adversary-resistant nonce.

The new field separates those jobs. Its minimum 32-octet body is four times the bit length of the origin timestamp, and its content comes from a cryptographically secure generator rather than from the clock. RFC 4086 supplies the caution behind that requirement: a sequence can look statistically varied while an attacker can still search a small underlying state space. Length is necessary here, but it is not a licence to claim 256 bits of entropy without examining the generator and its seeding.

Used outside NTS, RFC 8915 says the field may help a client detect packets spoofed by an off-path attacker. Inside NTS, the stronger statement depends on the paired test. The random echo shows which live request the response claims to answer; the authentication tag shows that the packet was made with the corresponding S2C key. Neither half should be promoted into the whole proof.

Three receipts that must not be merged

The terminology becomes clearer when the three NTS objects are kept apart. First, NTS-KE uses TLS for initial server authentication, negotiation and key extraction. The TLS connection then closes. That phase establishes who the client connected to and supplies cryptographic material; the later Unique Identifier is not a substitute certificate.

Second, the NTS Cookie carries opaque association state. A client sends a cookie that the server previously supplied; the server uses it to recover the AEAD algorithm and directional keys without retaining per-client state. A prior Sofia Ren article followed that cookie across the closed TLS boundary. The cookie can persist across a succession of requests, subject to the RFC's refresh and unlinkability rules. The Unique Identifier instead belongs to the request being answered. Treating it as the cookie confuses association recovery with replay detection.

Third, the authenticator protects the packet. The response's Unique Identifier is deliberately outside the encrypted extension fields, while returned cookies are inside them. The visible echo and the opaque cookie therefore have different confidentiality roles even though both participate in one protected exchange.

This separation also prevents a privacy category error. A stable identifier invites aggregation across time; this field is supposed to be freshly unpredictable for an individual request. Reuse, collisions or long-lived logging could create operational and privacy concerns, but those would be departures from the intended evidence model, not proof that the standard defines a client identity.

An authentic answer can still carry bad time

Replay protection closes one route to false time: an attacker cannot simply record an old protected response and have it accepted for a new outstanding request. It does not close every route. RFC 7384 treats replay, packet manipulation, spoofing, delay manipulation and attacks on a grandmaster's external source as distinct threats. A packet may be authentic and current while the source feeding the server is faulty, or while path delay has been adversarially distorted.

RFC 8633 therefore puts source selection and monitoring beside protocol security. With only one source, any error at that source reaches the client. Multiple sufficiently independent sources, observation of disagreement and operator investigation remain part of obtaining reliable time. The Unique Identifier says “this protected reply answers this outstanding request.” It does not say “this timestamp is true.”

Sources