Why can NTP's majority-based source selection not protect a client whose servers are mostly attacker-controlled, and what does Khronos (RFC 9523) change?
answer
- selection assumes an honest majority
- authentic is not the same as correct
- random sample from a large pool
- trim thirds, check the spread
- a watchdog, not a wire change
basics
~20 sNTP's selection outvotes a minority of bad servers but follows a majority, so an attacker controlling most of a client's few servers can shift its time. Khronos, an Informational watchdog, samples random servers from a large pool and trims outliers.
solid answer
~50 sRFC 5905's intersection step trusts whatever interval a majority of candidates share, and RFC 8633 states the assumption: a majority of the servers used must be honest. A client usually has a handful of servers, so control of most of them shifts its time with no falseticker detected. Authentication such as NTS (RFC 8915) stops an on-path attacker forging replies, but RFC 9523 notes it does little if the servers themselves are compromised. **Khronos** (RFC 9523, Informational) runs beside the NTPv4 client and changes only the client's system process, not the wire: each Khronos poll it picks `m` servers (tens) at random from a pool of `n` (hundreds), drops the lowest and highest thirds of the offsets, and accepts the average only if the rest agree within bounds; otherwise it resamples and, after `K` failed attempts, queries the whole pool. It claims protection below two-thirds compromised samples, against half for NTPv4.
go deeper
Recall that NTP's voting only works if most of a client's servers tell the truth; if most of them lie together, the client follows them.
Explain why majority selection fails against a compromised majority, and why authentication proves who sent the time, not that it is right.
Show a defender's judgment: separate on-path forgery from compromised servers, match each to NTS, source diversity or Khronos, and know Khronos is Informational and aimed at public-server clients.
Weigh the approaches: Khronos spreads trust across hundreds of public servers beside the client, while an owned internal time estate trades that breadth for control and monitoring.
## The assumption under NTP's selection RFC 5905's selection algorithm separates truechimers from falsetickers by agreement: it finds the interval shared by a majority of candidate servers and discards the rest. That works when wrong servers are a **minority**. RFC 8633 is explicit that its four-source advice "assumes that a majority of the servers used in the solution are honest", and warns that an attacker in control of the network could compromise the time from all of them. The consequence for a defender: if three of a client's four servers report the same shifted time, selection does exactly what it was designed to do and treats those three as the truechimers. The one honest server is outvoted. Nothing in the protocol flags this as an attack. ## Two different threats | Threat | What the attacker controls | NTS (RFC 8915) | Majority selection | |---|---|---|---| | On-path forgery or replay | Packets between client and server | Detects forged, altered and replayed replies | Helps only if a minority of paths are affected | | Compromised or malicious servers | The servers' own clocks or software | No help: the server's own replies authenticate | Helps only if those servers are a minority | Authentication proves **who** sent a reply and that it was not altered; it says nothing about whether the time inside is right. RFC 9523 notes that NTS "could make it more challenging for attackers to perform MITM attacks, but is of little impact if the servers themselves are compromised". ## What Khronos does Khronos is described in RFC 9523, an **Informational** RFC, as a "watchdog" that runs alongside an NTPv4 client and changes only the client's system process; packets on the wire are unchanged. In each Khronos poll interval: 1. Choose `m` servers (tens) **uniformly at random** from a local pool of `n` servers (hundreds), using a secure random source. The pool is gathered at calibration, repeated every two weeks, from servers scattered across regions. 2. Query them; drop non-responders. If fewer than a third of the `m` remain, resample at once. 3. Discard the **lowest third and the highest third** of the offsets received. 4. Check two conditions on what remains: no two offsets differ by more than `2w`, and their average is within `ERR + 2w` of how far NTPv4 itself has moved the clock since the last Khronos poll. 5. If both hold, the average becomes the Khronos time offset. If not, resample; after `K` resamplings, enter **panic mode**, query every server in the pool, trim thirds again and average. 6. If the Khronos time offset exceeds the threshold `H`, pass it to the clock discipline and notify the administrator that a time-shifting attack has been detected. Otherwise NTPv4 keeps steering the clock as usual, with its normal precision. ## Recommended parameters | Parameter | Meaning | RFC 9523's guidance | |---|---|---| | `n` | servers in the Khronos pool | hundreds; 500 in its evaluation | | `m` | servers sampled per Khronos poll | tens; 15 recommended | | `w` | bound on a truechimer's distance from UTC | about 25 ms; 1 s on congested links | | `H` | offset that triggers a Khronos update | between `w` and `2w`; default 30 ms | | `K` | resamplings before panic mode | 3 | The Khronos poll interval is around ten times the NTPv4 poll interval, which keeps the extra load on servers small. ## Why random sampling from a large pool helps An attacker who controls a few specific servers controls a client that always uses those same few. Khronos makes the attacker need a large share of a big, geographically spread pool, and the trimming step removes up to a third of extreme answers on each side before averaging. RFC 9523 claims Khronos prevents a clock shift while the ratio of compromised samples is below **two-thirds**, whereas NTPv4, even with hundreds of servers, is bounded at **half**. ## Operating it - RFC 9523 says Khronos is designed for clients using **public** servers and is not applicable to data centres or enterprises that synchronise to local atomic clocks, GPS receivers or dedicated servers; there, defence rests on source diversity, authentication and monitoring. - Its only DNS traffic is at calibration, to gather the pool. - Status matters: it is Informational, not part of the NTPv4 standard, and the NTPv5 Internet-Draft mentions it as a proposed enhancement to source selection.
- Why does deploying NTS not make a selection safeguard like Khronos unnecessary?NTS (RFC 8915) proves that a reply came from the server the client established keys with, unaltered and not replayed. It says nothing about whether that server's clock is right: a compromised or malicious server authenticates wrong time perfectly well. Khronos addresses the other failure, too many servers lying, by sampling widely and trimming outliers, so the two protect against different threats.
- When would an operator not use Khronos?RFC 9523 §4 says it is designed for clients of public NTP servers and is not applicable to data centres or enterprises that synchronise to local atomic clocks, GPS receivers or dedicated servers, for example because of regulation. Those estates own their sources, so they rely on diverse references, authentication and monitoring instead of random sampling across hundreds of strangers' servers.
saying these in an interview costs you the question
- Authenticating NTP replies guarantees that the time inside them is correct.
- NTP's selection detects a lying server however many of the servers lie.
- Khronos is a new wire protocol that replaces NTPv4.
- Khronos is a Standards Track part of the NTPv4 specification.
- Giving NTPv4 hundreds of servers lets it withstand two-thirds of them lying.