Network Time Security for the Network Time Protocol
Extracted elements (31)
NTS is split into two loosely coupled sub-protocols so the NTP server can be fully stateless: all per-client session state is carried by the client inside encrypted cookies. This enables servers to scale to large numbers of clients without maintaining any per-client storage.
The suggested cookie format (Section 6) uses the server's own AEAD key to encrypt the C2S key, S2C key, and negotiated AEAD algorithm, analogous to TLS session tickets (RFC 5077). Periodic key rotation with a deterministic HKDF ratchet allows key synchronization across NTS-KE/NTP clusters without central key-management infrastructure.
A retry mechanism is REQUIRED when retrying NTS-KE due to errors. Clients SHOULD use exponential backoff with initial interval 10 seconds, maximum 5 days, base 1.5. Clients MUST NOT reset the retry interval until a successful NTS-KE followed by successful Next Protocol use.
Client NTS-protected requests SHALL include exactly one Unique Identifier EF (authenticated, not encrypted), exactly one NTS Cookie EF (authenticated, not encrypted), and exactly one NTS Authenticator and Encrypted Extension Fields EF.
For AEAD computation the associated data SHALL be the NTP header plus all extension fields preceding the Authenticator EF; the C2S key SHALL be used for client-to-server packets; the S2C key SHALL be used for server-to-client packets.
If the server cannot validate the cookie or authenticate the request, it SHOULD send a KoD packet with kiss code 'NTSN' (NTS NAK) and MUST NOT include any NTS Cookie or NTS Authenticator extension fields in that response.
Implementations MUST follow RFC 5280 and RFC 6125 for representation and verification of application service identity. Use of DNS-ID identifier type is RECOMMENDED when NTS-KE service discovery produces hostnames.
Implementations receiving a record with an unrecognized Record Type MUST ignore it if the Critical Bit is 0, and MUST treat it as an error if the Critical Bit is 1. Servers MUST respond with error code 0 ('Unrecognized Critical Record') in the latter case.
Key material SHALL be extracted using HKDF per RFC 8446 Section 7.5. The disambiguating label MUST be 'EXPORTER-network-time-security' and the per-association context MUST begin with the two-octet negotiated Protocol ID.
NTS Cookie extension fields MUST NOT be encrypted when sent from client to server (enabling the server to recover keys from the cookie), but MUST be encrypted when sent from server to client (required for unlinkability).
NTS implementations MUST NOT negotiate TLS versions earlier than 1.3 and MUST conform to RFC 7525 (BCP 195) or a later revision. Use of ALPN is REQUIRED for interoperability.
Server implementations of NTS Extension Fields for NTPv4 MUST support AEAD_AES_SIV_CMAC_256 (Numeric Identifier 15). If the client offers this algorithm and the server accepts Protocol ID 0, the AEAD Algorithm Negotiation response record MUST NOT be empty.
The client SHOULD keep at least one unused but recent cookie, AEAD keys, negotiated AEAD algorithm, and other necessary parameters in persistent storage to allow NTP session resumption without a fresh NTS-KE handshake when the NTS-KE server is unavailable.
Upon receiving an NTS-protected response, the client MUST verify that the Unique Identifier matches an outstanding request and that the packet authenticates under the S2C key. If either check fails, or if the response is unprotected, the packet MUST be discarded.
When Protocol ID 0 (NTPv4) is negotiated, the server MUST send at least one New Cookie for NTPv4 record (type 5) and SHOULD send eight of them. Clients MUST NOT attempt to interpret the opaque cookie body.
NTS achieves unlinkability by supplying fresh cookies on every exchange so that no persistent identifier leaks across network address changes. Clients SHOULD avoid reusing cookies; cookie reuse is permissible only to prioritize resilience over unlinkability.
Following NTS-KE with Protocol ID 0 (NTPv4), two AEAD keys are derived: C2S (context = 0x0000 || AEAD_ID || 0x00) and S2C (context = 0x0000 || AEAD_ID || 0x01), each using the TLS exporter label 'EXPORTER-network-time-security'.
The NTPv4 Server Negotiation record (type 6) carries an ASCII string that is either an IPv4 address in dotted decimal, an RFC 4291 IPv6 address (no zone identifiers), or a FQDN. If absent, the client SHALL associate with an NTP server at the same IP as the NTS-KE server.
The NTS-KE protocol is conducted over TCP port 4460 using TLS with ALPN 'ntske/1'. After a successful handshake, the client sends one request and the server sends one response, then both parties send TLS close_notify. The server discards all state after the exchange.
Four NTP Extension Field Types are registered: 0x0104 (Unique Identifier), 0x0204 (NTS Cookie), 0x0304 (NTS Cookie Placeholder), and 0x0404 (NTS Authenticator and Encrypted Extension Fields).
IANA created 'Network Time Security Error Codes' (initial entries: 0=Unrecognized Critical Record, 1=Bad Request, 2=Internal Server Error) and 'Network Time Security Warning Codes' (initially empty) registries. The NTP Kiss-o'-Death code 'NTSN' is registered to mean NTS negative-acknowledgment.
IANA created the 'Network Time Security Key Establishment Record Types' registry with initial entries 0–7 (End of Message through NTPv4 Port Negotiation). Registration policy: 0–1023 IETF Review, 1024–16383 Specification Required, 16384–32767 Private/Experimental.
IANA created the 'Network Time Security Next Protocols' registry. Protocol ID 0 is assigned to NTPv4. Registration policy: 0–1023 IETF Review, 1024–32767 Specification Required, 32768–65535 Private/Experimental. Also registered service 'ntske' on TCP port 4460 and ALPN ID 'ntske/1'.
A client without a synchronized clock cannot reliably verify TLS certificate validity periods. Mitigations include checking ntp_adjtime() return codes, persisting the last-known time, requiring that NTP time replies fall within the certificate validity period, and using multiple time sources.
Implementations SHOULD NOT revert from NTS-protected to unprotected NTP without explicit user action. A man-in-the-middle can force NTS-KE failures or send faked NTS NAK KoD replies to trigger renegotiation, potentially as the first step of a more advanced attack.
NTS avoids DDoS amplification by requiring one NTS Cookie Placeholder extension field per desired return cookie, each padded to the same size as a real cookie. This ensures NTS-related response fields are never larger than the corresponding request fields.
NTS introduces asymmetric cryptography into NTP's key establishment phase, making NTS-KE servers susceptible to DDoS. Because NTS-KE and NTP server functions can be separated, a successful DDoS on the NTS-KE server will not affect clients already holding valid cookies and AEAD keys.
Packet delay attacks cannot be mitigated cryptographically because NTS authenticates content but not timing. An on-path adversary can introduce error up to MAXDIST/2 (typically 0.5 seconds). Using multiple time sources or multiple network paths reduces exposure.
An NTS-KE record consists of a 1-bit Critical flag, a 15-bit Record Type Number, a 16-bit Body Length (body only, not including type/length fields), and a variable-length Record Body. All integers are in network byte order.
The NTS Authenticator and Encrypted Extension Fields extension field (Field Type 0x0404) contains: Nonce Length (2 octets), Ciphertext Length (2 octets), Nonce (padded to 4-octet boundary), Ciphertext (padded to 4-octet boundary), and optional Additional Padding.
The Unique Identifier extension field (Field Type 0x0104) carries a cryptographically random octet string in client packets; the body MUST be at least 32 octets. Servers echo the identical octet string in their response to enable replay detection.