In plain NTP, why can an on-path attacker who shifts a client's clock make expired certificates and replayed tokens valid again?
answer
- validity checks read the local clock
- backwards revives, forwards denies
- plain NTP is unauthenticated by default
- origin timestamp only stops off-path forgers
- authenticate the server, not just the packet
basics
~20 sCertificate lifetimes, time-based one-time codes and replay windows all compare against the local clock. Plain NTP replies are unauthenticated UDP, so an attacker on the path can rewrite them and move the clock back until expired credentials pass again.
solid answer
~50 sNearly every security check that involves time compares a value with the local clock: a certificate's `notBefore` and `notAfter`, a time-based one-time code, a signed token's expiry, a replay window. RFC 7384 makes the point for NTP: certificate validation for TLS and IKEv2 needs roughly synchronised clocks, and a clock pushed back may let a node use a key that has already expired. In its standard configuration NTP runs over UDP with no authentication (RFC 8633). The client's origin-timestamp check discards forged replies from an off-path attacker who never saw the request, but an attacker on the path sees the request, copies that value and writes any time it likes; if it sits on the path to every server, the client's majority vote cannot help. The fix is to authenticate the server: Network Time Security (RFC 8915) for client-server mode, AES-CMAC symmetric keys (RFC 8573) for peers, plus several sources.
go deeper
Recall that certificates, one-time codes and token expiry all read the local clock, and that plain NTP over UDP is unauthenticated by default.
Explain why the origin-timestamp check stops an off-path forger but not an on-path one, and why moving the clock back and forward hurt in different ways.
Show where several sources help and where they do not, and why a panic threshold ignored on every restart offers no protection.
Weigh which systems need authenticated time at all, and what the organisation loses if every host trusts an unauthenticated path.
## Time is a security input Many controls that look unrelated to NTP quietly ask one question: *what time is it now?* The answer comes from the local system clock, and NTP is what sets that clock. RFC 7384 (Informational), the IETF's threat analysis for time protocols, says so directly: certificate validation requires sender and receiver to be roughly time synchronised, so protocols such as **TLS** and **IKEv2** depend on it, and if a time protocol is compromised a node may use a key that was already used in the past and has expired. | Control | What it compares with the clock | Clock moved **back** | Clock moved **forward** | |---|---|---|---| | Certificate validity | `notBefore` / `notAfter` | an expired certificate passes again | valid certificates look expired; connections fail | | Time-based one-time code | the current time step | codes captured earlier are accepted again | current codes are rejected | | Signed token or session expiry | the expiry claim | expired tokens are honoured | fresh tokens are refused | | Replay window keyed on timestamps | message timestamp against "now" | old captured messages fall back inside the window | legitimate messages fall outside it | Moving the clock back is the dangerous direction for **authentication**; moving it forward is a **denial of service**. Either way, whoever controls the clock controls these checks. ## What plain NTP gives an attacker on the path In its standard configuration NTP packets are exchanged unprotected; RFC 8633 (BCP 223) notes that an adversary able to become a man in the middle can drop, replay or modify them. NTP does have built-in sanity checks, and it is worth knowing exactly how far they reach: - **The origin-timestamp check.** RFC 5905 calls a reply *bogus* when its origin timestamp does not match the transmit timestamp the client sent, and discards it. That stops an **off-path** attacker, who never sees the request and must guess the value. RFC 8915 adds that the 64-bit origin timestamp is a weak nonce, since depending on the implementation most of its bits may be predictable; RFC 9109 makes off-path guessing harder still by recommending a randomised client source port. - **An on-path attacker sees the request.** It copies the transmit timestamp into its reply's origin field, so the forged reply passes the bogus check, and it can write any receive and transmit timestamps it likes. - **Several servers help only against bad servers.** The client's selection outvotes a minority of wrong sources, but RFC 8633 warns that if an attacker controls the network, the time from all servers could be compromised. An attacker on the client's own uplink is on the path to every server at once. - **Authentication is not correctness.** RFC 5905 itself notes that authentication in NTP does not necessarily imply the time is correct; it proves who sent the packet. ## The thresholds are not a defence by themselves RFC 5905 gives a **step threshold** (125 ms) and a **panic threshold** (1000 s): an offset beyond the panic threshold should make the client exit with a diagnostic rather than set the clock. That caps the size of one jump, not the direction of travel. RFC 8633 describes how it fails in practice: if a process supervisor restarts the client automatically and the client is configured to ignore the panic threshold on every restart, a large forged offset is simply accepted on the second start. Operators SHOULD NOT ignore the panic threshold on all cold starts. ## What closes the gap 1. **Authenticate the server.** For client-server mode use **Network Time Security** (RFC 8915): TLS-based key establishment, then authenticated NTP packets. For symmetric peers and broadcast, use pre-shared keys with **AES-CMAC** (RFC 8573), which deprecates MD5. 2. **Use at least four independent, diverse sources** (RFC 8633), so one wrong or compromised server is outvoted. 3. **Keep the panic threshold**, and require manual intervention for very large steps instead of accepting them silently after a restart. 4. **Monitor** for the signatures RFC 8633 lists: replies whose origin timestamp does not match, zero origin timestamps, and packets with invalid MACs. Even authenticated NTP leaves one gap: an on-path attacker can delay packets in one direction without changing a byte, and the error that adds is bounded by half the round-trip delay. Measuring durations inside an application with a monotonic clock rather than the wall clock is a separate, application-level concern.
- Why doesn't NTP's origin-timestamp check stop an attacker who sits on the path?The check discards a reply whose origin timestamp differs from the transmit timestamp the client sent. An off-path attacker must guess that value, so its forgeries fail. An on-path attacker reads the request, copies the value into its reply and passes the check. Only a reply authenticated with a key the attacker lacks, as with NTS or a symmetric-key MAC, stops on-path forgery.
- Does pointing a client at four public NTP servers protect it against this attack?Partly. Selection outvotes a minority of bad sources, so one compromised server is ignored. An attacker on the client's own uplink sits on the path to all four and can shift every reply together, and then the majority agrees on the wrong time. Diverse sources defend against bad servers; authentication defends against a bad path.
saying these in an interview costs you the question
- NTP time cannot be tampered with because it comes from trusted stratum 1 servers.
- Pushing a clock forward is harmless; only moving it backwards matters.
- The origin-timestamp check already stops forged NTP replies from any attacker.
- Using four unauthenticated NTP servers makes authentication unnecessary.
- TLS certificate validation does not depend on the client's clock.