NTP Network Time Security (NTS) Deployment Playbook

Date: 2026-03-29
Category: knowledge
Audience: SRE / platform / security teams operating production time sync

1) Why this deserves operational attention

If your NTP path is unauthenticated, a network attacker can spoof or alter time replies and quietly corrupt:

• cert validation windows,
• Kerberos/WireGuard/TLS behavior,
• distributed logs and incident timelines,
• latency and sequencing analytics.

NTS (RFC 8915) closes the biggest integrity gap in classic client/server NTP by adding modern cryptographic authentication with low server-side state cost.

2) Correct threat model (what NTS fixes vs. what it does not)

NTS helps with

• Server identity (PKI-backed cert validation)
• Packet authenticity/integrity (extension-field authentication)
• Replay/request-response consistency improvements
• NTS-stripping awareness (if clients are configured correctly)

NTS does not eliminate

• Delay attacks from on-path MITM adversaries
  • RFC 8915 is explicit: crypto cannot fully prevent asymmetric delay manipulation.
• All availability attacks
  • attackers can still drop packets / induce retries.
• General time architecture mistakes
  • bad source diversity, leap policy mismatch, weak monitoring still hurt.

Treat NTS as authentication hardening, not complete time-security magic.

3) Protocol facts operators should memorize

From RFC 8915:

1. NTS-KE runs over TCP 4460.
2. TLS 1.3+ is required (no negotiation below 1.3).
3. ALPN protocol id is ntske/1.
4. Actual time sync still happens via NTP packets (typically UDP/123) using NTS extension fields.
5. Server implementations for NTS-for-NTPv4 MUST support AEAD_AES_SIV_CMAC_256 (ID 15).
6. Retry behavior should use bounded exponential backoff (guidance provided in RFC 8915 §4.2).
7. Clients SHOULD NOT auto-fallback from NTS to unauthenticated NTP without explicit operator/user action (NTS-stripping risk, RFC 8915 §8.7).

4) Practical deployment topologies

A) Same host does NTS-KE + NTP service

• Simplest lifecycle.
• Lowest coordination overhead.
• Good default for most infra.

B) Split NTS-KE front door + separate NTP servers

Useful for large edge estates, but key caveat (chrony docs):

• NTS cookie encryption keys must be coordinated/shared correctly.
• In chrony, separating NTS-KE and NTP servers typically requires explicit external key-management behavior (ntsrotate 0 with shared key handling).

Do not choose split mode unless you already run disciplined key distribution and rotation controls.

5) Chrony client baseline (production-oriented)

# All listed sources support NTS
server time.cloudflare.com iburst nts maxdelay 0.1
server nts.netnod.se       iburst nts maxdelay 0.1
server nts.example.net     iburst nts maxdelay 0.1
server nts2.example.net    iburst nts maxdelay 0.1

minsources 3
authselectmode require
ntsdumpdir /var/lib/chrony

# Optional guardrails
maxchange 100 0 0
maxdrift 100

Notes:

• nts enables NTS per source.
• authselectmode require avoids silently selecting unauthenticated sources.
• ntsdumpdir persists cookies across restart, reducing post-reboot NTS-KE storms.
• Keep enough independent sources (RFC 8633 recommends at least four diverse sources when possible).

6) Chrony server baseline (NTS-enabled)

# Serve NTP only to intended clients
allow 10.0.0.0/8

# NTS-KE listener (default 4460)
ntsport 4460

# Required to open NTS-KE service
ntsservercert /etc/chrony/fullchain.pem
ntsserverkey  /etc/chrony/privkey.pem

# Preserve cookie keys across restart
ntsdumpdir /var/lib/chrony

# Cookie-key rotation / scale tuning
ntsrotate 604800
ntsprocesses 4
maxntsconnections 200

Operational details from chrony docs that teams often miss:

• NTS-KE service port opens only when both cert and key are configured.
• Renewed cert files usually require chronyd restart/reload planning.
• Without persisted cookie keys, restarts can trigger broad client re-handshakes.

7) Hardening controls that matter most

1. No implicit plaintext fallback
   • Handshake failure should alert, not silently downgrade.
2. Constrain acceptable delay (maxdelay)
   • Helps bound delay-attack leverage and noisy-path corruption.
3. Use authenticated-source-only selection policy
   • authselectmode require (or explicit require/trust policy).
4. Source diversity
   • Different operators/paths/regions; avoid monoculture.
5. Protect key/cert material tightly
   • NTS key files and cookie-key stores are high-impact assets.

8) Observability: minimum signals

Track these at client and server layers:

• NTS-KE success/failure rate
• handshake latency distribution
• certificate validation failures (name, chain, expiry)
• active cookie inventory / refresh cadence
• NTP source reachability and offset/jitter behavior
• sudden increase in KoD/NTSN or re-handshake frequency
• authenticated-source ratio in final source selection

Alert examples:

• NTS-KE failure > 2% for 5m
• authenticated selected sources < configured minimum
• median RTT stable but offset variance spikes (possible delay-path issue)
• synchronized hosts dropping below policy threshold

9) Safe rollout sequence

Phase 0 — inventory

• identify which clients/servers and NTP implementations support RFC 8915-compatible NTS.
• confirm cert issuance/renewal ownership.

Phase 1 — canary

• enable NTS on a subset of non-critical hosts.
• disable plaintext fallback for canaries.
• validate steady-state offset/jitter and restart behavior.

Phase 2 — cohort expansion

• roll by environment/region.
• maintain rollback as “pause rollout,” not “silent downgrade.”

Phase 3 — policy tightening

• enforce authenticated-only source selection.
• document exception paths with explicit expiry.

10) Incident runbook (NTS-specific)

When NTS sync starts failing:

1. Check cert validity chain/name/time first.
2. Verify TCP/4460 reachability and TLS handshake success.
3. Inspect whether failures are global vs. one source/operator.
4. Check recent cert or cookie-key rotation/restart events.
5. If impact is large, shift to alternate authenticated sources.
6. Avoid emergency global downgrade to plaintext NTP unless explicitly approved with incident record + containment window.

11) Common anti-patterns

• Turning on nts for one source but leaving multiple unauthenticated sources selectable.
• Treating NTS as protection against all timing attacks (it is not).
• Restarting NTS servers without cookie-key persistence planning.
• Split NTS-KE/NTP architecture without key-sharing discipline.
• Auto-reverting to plaintext when NTS-KE fails.

References

1. RFC 8915 — Network Time Security for the Network Time Protocol
   https://www.rfc-editor.org/info/rfc8915
2. RFC 5905 — NTPv4 Protocol and Algorithms Specification
   https://www.rfc-editor.org/info/rfc5905
3. RFC 8633 — Network Time Protocol Best Current Practices
   https://www.rfc-editor.org/info/rfc8633
4. chrony 4.5 documentation — chrony.conf (nts, ntsport, ntsservercert, ntsserverkey, ntsdumpdir, ntsrotate, authselectmode)
   https://chrony-project.org/doc/4.5/chrony.conf.html
5. chrony FAQ — operational security guidance and NTS usage examples
   https://chrony-project.org/faq.html
6. Cloudflare Time Services — NTS overview and ecosystem links
   https://developers.cloudflare.com/time-services/nts/