skip to content

In Network Time Security, how does NTS-KE give a client its keys and cookies, and why can the NTP server keep no per-client state?

level: middleimportance: must knowfreq 22%

answer

  1. two sub-protocols, two transports
  2. TLS 1.3 on TCP 4460
  3. keys exported from the TLS session
  4. the cookie carries the keys, sealed
  5. fresh cookies in every reply

basics

~20 s

NTS-KE runs TLS 1.3 on TCP 4460, exports two AEAD keys and hands the client cookies: those keys sealed under a server secret. Each NTP request carries one cookie, so the server recovers the keys from it and stores no per-client state.

solid answer

~50 s

Network Time Security (RFC 8915) has two parts. In **NTS-KE** the client opens TLS on TCP 4460, offering ALPN `ntske/1`; nothing older than TLS 1.3 may be negotiated. One request and one response of records follow: next protocol (NTPv4), AEAD algorithm (servers must support `AEAD_AES_SIV_CMAC_256`), optionally another NTP server and port, and `New Cookie for NTPv4` records, eight by recommendation. Both sides derive a client-to-server and a server-to-client key with the TLS exporter, then close the connection. Each NTP request over UDP then carries a Unique Identifier, one cookie and an Authenticator field computed with the C2S key. The cookie is the server's own encrypted record of the algorithm and both keys, so the NTP server decrypts it, verifies the request and answers under the S2C key with fresh encrypted cookies, keeping no per-client state.

go deeper

for a junior

Recall that NTS has a TLS phase on TCP 4460 and an NTP phase on UDP, and that cookies carry the keys.

for a middle

Explain the exported C2S and S2C keys, the four extension fields, and how a cookie lets the server verify a request without stored state.

for a senior

Discuss master-key rotation across separate NTS-KE and NTP servers, persisted cookies, and why placeholders keep responses no larger than requests.

for a principal

Weigh running NTS-KE separately from NTP service, and the tradeoff between reusing cookies for resilience and keeping them fresh for unlinkability.

## The problem NTS was designed around A public time server may have a vast number of clients and cannot afford per-client state, yet it must authenticate every reply. RFC 8915 resolves this by securing **only client-server mode** (NTP modes 3 and 4), where only the client needs replay protection, and by splitting the work into two loosely coupled sub-protocols: **NTS Key Establishment (NTS-KE)**, which uses TLS and public-key cryptography once, and **NTS extension fields for NTPv4**, which use fast symmetric AEAD on every time packet. ## Phase 1: NTS Key Establishment over TLS 1. The client connects to TCP port **4460** and runs a TLS handshake offering the ALPN protocol `ntske/1`. RFC 8915 forbids negotiating any TLS version earlier than 1.3 (it cites RFC 8446, which RFC 9846 now obsoletes). The client validates the server's certificate as for any TLS service. 2. Inside the TLS channel the client sends a **single request** made of records, and the server sends a **single response**; then both send `close_notify` and the server discards everything about the session. 3. Both sides derive two AEAD keys with the **TLS exporter**, using the label `EXPORTER-network-time-security` and a five-octet context: Protocol ID 0 (NTPv4), the AEAD algorithm number, then `0x00` for the client-to-server (**C2S**) key or `0x01` for the server-to-client (**S2C**) key. | Record type | Name | Role | |---|---|---| | 0 | End of Message | ends every request and response | | 1 | NTS Next Protocol Negotiation | Protocol ID 0 means NTPv4 | | 2 / 3 | Error / Warning | server-only failure signals | | 4 | AEAD Algorithm Negotiation | servers MUST support `AEAD_AES_SIV_CMAC_256` (identifier 15) | | 5 | New Cookie for NTPv4 | at least one; eight recommended | | 6 / 7 | NTPv4 Server / Port Negotiation | which NTP server and UDP port accept the cookies; port 123 if absent | ## Phase 2: authenticated NTP on UDP Each protected request is a normal 48-octet NTP header, authenticated but not encrypted, followed by NTS extension fields: - **Unique Identifier** (`0x0104`): at least 32 random octets that the server echoes, so the client can match replies and reject replays. - **NTS Cookie** (`0x0204`): one cookie, authenticated but sent unencrypted, because the server must read it before it has any key. - **NTS Cookie Placeholder** (`0x0304`): optional, one per extra cookie wanted, each as long as a cookie. - **NTS Authenticator and Encrypted Extension Fields** (`0x0404`): the AEAD output over everything before it, computed with the C2S key. The server answers with the echoed Unique Identifier and an Authenticator field under the S2C key, and inside it, **encrypted**, one fresh cookie plus one per valid placeholder. ## How a cookie keeps the server stateless RFC 8915 compares cookies to TLS session tickets. Its suggested, non-normative format: the server keeps a secret master key `K` with a public identifier `I`, encrypts a plaintext holding the negotiated AEAD algorithm, the S2C key and the C2S key under `K` with a random nonce `N`, and hands out `(I, N, C)`. On each request the NTP server looks up `K` by `I`, decrypts the cookie, gets the keys and verifies the packet. All session state rides with the client. Servers should rotate `K`, for example daily, keep a few old keys so issued cookies still work, and may derive each new key from its predecessor with HKDF, so separate NTS-KE and NTP servers stay in step without central key management. ## Cookie bookkeeping - The client SHOULD NOT reuse a cookie, so traffic on a new network cannot be linked to the old one; fresh cookies arrive encrypted in every reply. - It sends enough placeholders to get back to **eight** unused cookies, and no more than seven in one request. - Each placeholder is as long as a cookie, so the response is never larger than the request (bar up to three padding octets): an NTS server cannot be used as an amplifier. - The client SHOULD persist an unused cookie and its keys, so after a restart it can resume without NTS-KE. - If the server cannot validate a cookie, it SHOULD answer with a kiss-o'-death carrying the code `NTSN`, and the client eventually runs NTS-KE again, with backoff. Because public-key work happens only in NTS-KE, the two services can run on different machines, and a flood against NTS-KE does not disturb clients that already hold cookies.

  • Why must an NTS client send a placeholder for each extra cookie instead of just asking for a number?
    So the request is as large as the response. Each placeholder's body is as long as a cookie, and the server returns at most one more cookie than placeholders, so the reply never exceeds the request apart from up to three padding octets. A request with a forged source address therefore cannot turn an NTS server into a traffic amplifier.
  • Why do the server's new cookies travel encrypted when the client's cookie travels in the clear?
    The server must read the incoming cookie before it holds any key, so that cookie is only authenticated; its body is already sealed under the server's own key. Outgoing cookies sit inside the encrypted Authenticator field so an observer cannot link the cookie a device presents later, on another network, to this exchange. That is NTS's unlinkability goal.
  • What happens when an NTP server cannot decrypt a client's NTS cookie, for example after its master keys were erased?
    It SHOULD reply with a kiss-o'-death whose code is NTSN, carrying no cookies. The client waits until the next poll for a valid protected reply; if none arrives, it runs NTS-KE again, retrying with exponential backoff, and keeps polling with its existing cookies until a new handshake succeeds.

A cloakroom that keeps no ledger: instead of filing your details, it seals them in an envelope only the cloakroom can open and hands you a stack. Each visit you hand one back; the attendant opens it, serves you, and gives you a new sealed envelope.

saying these in an interview costs you the question

  • Every NTS-protected time packet travels inside a TLS session.
  • NTS encrypts the NTP header so observers cannot read the timestamps.
  • The NTP server keeps a table of each NTS client's keys.
  • An NTS client should reuse one cookie for every request.
  • NTS-KE accepts TLS 1.2 so that older clients can connect.
  • NTS also secures symmetric peer and broadcast NTP modes.