skip to content

After a company moves its laptops to Network Time Security, which attacks on their clocks still work, and how should the clients limit each?

level: seniorimportance: should knowfreq 12%

answer

  1. authenticity is not timing
  2. half the round trip
  3. kiss-o'-death is unauthenticated
  4. no silent fallback to plain NTP
  5. certificate checked before the clock is set

basics

~20 s

NTS stops forged replies, not delay: an on-path attacker can still hold packets in one direction (error up to half the round trip), drop them, forge NTSN kiss-o'-death replies, or push a naive client back to plain NTP. Clients should never downgrade silently.

solid answer

~50 s

NTS authenticates every reply, so forged, modified and replayed replies are rejected, but several attacks remain. A **delay attack** holds packets in one direction; no byte changes, so no cryptography detects it, and the offset error is bounded by half the round trip, at most `MAXDIST/2`, 0.5 s with RFC 5905's 1 s value. **Dropping** packets simply denies time. **Kiss-o'-death replies are not authenticated**: an on-path attacker who sees the Unique Identifier can forge an `NTSN` and drive clients back to NTS-KE, loading that server. **NTS stripping**: a client that falls back to plain NTP when NTS-KE fails gives the attacker everything, so RFC 8915 says not to revert without explicit user action. There is also a boot problem: the NTS-KE certificate must be validated before the clock is trustworthy. Limits: several sources over different paths, no silent downgrade, persisted cookies and last-known time, and backoff on NTS-KE retries.

go deeper

for a junior

Recall that NTS proves who sent a time reply but cannot stop an attacker from delaying or dropping it.

for a middle

Explain why a one-way delay skews the offset without breaking any tag, and why the error is bounded by half the round trip.

for a senior

Show how forged NTSN replies, NTS stripping and boot-time certificate checks are handled in a fleet policy, and which client settings enforce it.

for a principal

Decide how much residual time error the business tolerates, and whether diverse sources and paths are worth their cost to bound it.

## What NTS does close Network Time Security (RFC 8915) protects client-server NTP with keys from a TLS 1.3 handshake on TCP 4460 and AEAD on every packet. Against an attacker on the path, that removes a lot: - **Forged or modified replies** fail the AEAD check under the server-to-client key. - **Replayed replies** fail because each reply must echo the random Unique Identifier of an outstanding request. - **Linking a laptop across networks** through its cookies is prevented by fresh, encrypted cookies in each reply. What is left is everything that does not involve changing a protected byte. ## Delay attacks: authentic but late NTP computes the clock offset assuming the path is roughly symmetric. An on-path attacker can hold packets in one direction only. RFC 8915 notes that this attack neither reorders nor modifies the packets, so cryptography offers no feasible defence; RFC 8633 says the same of IPsec or any other tunnel. The error it can introduce is bounded by half the round-trip delay, and since RFC 5905's `MAXDIST` (1 s) caps the distance a client accepts, the worst case is `MAXDIST/2`, or 0.5 s. A worked example, with a client whose clock is actually correct: | Step | Without attack | With 80 ms added to the server-to-client leg | |---|---|---| | Client sends, `T1` | 0 ms | 0 ms | | Server receives `T2` and replies `T3` | 10 ms | 10 ms | | Client receives, `T4` | 20 ms | 100 ms | | Delay `(T4-T1)-(T3-T2)` | 20 ms | 100 ms | | Offset `((T2-T1)+(T3-T4))/2` | 0 ms | -40 ms | The client is told it is 40 ms fast, within the 50 ms bound of half the 100 ms round trip. The limit is diversity: several sources, or several paths to a source, so an attacker on some paths is outvoted. ## Denial of service and forged kiss-o'-death - **Dropping packets** cannot be prevented cryptographically; the client coasts on its own oscillator until replies return. - **Kiss-o'-death (KoD) packets are not authenticated.** Once a server has sent authentic NTS replies, the client must check that any KoD echoes the Unique Identifier of an outstanding request, which defeats off-path forgers. An on-path attacker can read that identifier, since it is authenticated but not encrypted, and forge an `NTSN` (NTS negative acknowledgement). RFC 8915 notes this can significantly increase load on the NTS-KE server. Clients limit this by waiting until the next poll for a valid protected reply before reacting to `NTSN`, retrying NTS-KE with exponential backoff (RFC 8915 suggests starting at 10 s, a base of 1.5 and a ceiling of 5 days, 432,000 s), and continuing to poll with the cookies they hold until a new handshake succeeds. ## NTS stripping A naive client that reverts to plain NTP when NTS-KE fails can be stripped by anyone able to block TCP 4460 or forge `NTSN`. RFC 8915 says implementations SHOULD NOT revert from NTS-protected to unprotected NTP with any server without explicit user action. For a laptop fleet that means configuring NTS servers as NTS-only, alerting when a client cannot complete NTS-KE, and letting the clock free-run briefly rather than trusting the hotel network's time. ## The boot problem: a certificate before a clock The NTS-KE server's certificate has a validity period, but a laptop whose battery died may not know the date. RFC 8915 lists mitigations: 1. Validate strictly when the system time is already known to be set by trusted software. 2. Let administrators require strict validation always, on devices with a battery-backed clock. 3. Periodically save the synchronised time and reject any certificate whose `notAfter` is earlier than the last saved time. 4. Check that the first NTP replies fall inside the certificate's validity period. 5. Use several time sources, so one compromised server key cannot move the clock alone. ## Summary for the fleet | Threat | Stopped by NTS? | Client-side limit | |---|---|---| | Forged or altered reply | yes | none needed | | Asymmetric delay | no | several sources and paths; error at most half the round trip | | Dropped packets | no | free-run on the local clock, alert | | Forged `NTSN` kiss-o'-death | no, on-path | wait a poll, backoff, keep current cookies | | Downgrade to plain NTP | only if the client refuses | no fallback without explicit action | | Expired-certificate replay at boot | partly | saved last time, strict validation, several sources |

  • Why can't the AEAD tag on an NTS reply detect a delay attack?
    The tag proves the bytes are unchanged and came from the key holder. A delay attack changes no bytes; it only holds packets in one direction, so the server's timestamps are genuine while the client's assumption of a symmetric path is false. Only the half-round-trip bound and independent paths or sources limit it.
  • Should a laptop that cannot reach NTS-KE on a hotel network fall back to plain NTP?
    Not silently. RFC 8915 says clients SHOULD NOT revert to unprotected NTP without explicit user action, because a man in the middle can make NTS-KE fail on purpose. A client that persisted an unused cookie and its keys can still run NTS against the NTP server without NTS-KE; otherwise it should free-run on its clock and raise an alert.

saying these in an interview costs you the question

  • With NTS in place, an on-path attacker can no longer shift the client's clock at all.
  • NTS kiss-o'-death packets are authenticated, so they can always be trusted.
  • If NTS-KE fails, falling back to plain NTP is the safe default.
  • Wrapping NTP in an encrypted tunnel stops packet-delay attacks.
  • NTS-KE certificate checks need no special care while the clock is unset.