skip to content

In NTPv4 symmetric-key authentication, what does the per-packet MAC prove, and what does running it across a fleet cost?

level: middleimportance: should knowfreq 18%

answer

  1. a shared secret, configured out of band
  2. key identifier, then digest
  3. MD5 deprecated by RFC 8573
  4. AES-CMAC with an AES-128 key
  5. no key distribution or rotation in NTP

basics

~20 s

The MAC proves a packet came from a holder of the shared key and was not altered; it says nothing about whether the time is right. RFC 8573 replaces MD5 with AES-CMAC, but keys still travel out of band, one per association.

solid answer

~50 s

In NTPv4 (RFC 5905) an authenticated packet ends with a MAC: a 32-bit `Key Identifier` naming a pre-shared key, then a digest computed with that key over every header and extension field. A receiver holding the same key recomputes it; a match proves the packet came from a key holder and was not modified. RFC 5905 specified MD5; RFC 8573 says MD5 is not a secure MAC, deprecates it, and requires AES-CMAC with a 128-bit AES key and a tag of at least 128 bits, so both ends must match on key ID, type and key. The cost is key management: NTP has no mechanism to distribute or rotate keys, RFC 8633 recommends a unique key per association, and a server must hold a key for every client it authenticates. That suits routers, peers and a few internal servers, not a public server with unknown clients.

go deeper

for a junior

Recall that NTP can append a MAC built from a pre-shared key, and that RFC 8573 swapped MD5 for AES-CMAC.

for a middle

Explain the key identifier and digest, what fields the MAC covers, and what a valid MAC does and does not prove about the time.

for a senior

Describe the key-management load on a fleet, why broadcast keys are weak, and how to migrate associations from MD5 to AES-CMAC.

for a principal

Decide where pre-shared keys stay worth their cost and where Network Time Security should replace them.

## What goes on the wire NTPv4's built-in authentication (RFC 5905) appends a **message authentication code (MAC)** after the 48-octet header and any extension fields. The MAC has two parts: | Field | Size | Contents | |---|---|---| | `Key Identifier` | 32 bits | a number both ends map to the same secret key | | `Message Digest` | 128 bits | RFC 5905: MD5 over the key followed by the header and extension fields; RFC 8573: an AES-CMAC tag of at least 128 bits over the header and extension fields | The receiver looks up the key by its identifier, recomputes the digest and compares. If authentication fails, RFC 5905 has the server return a **crypto-NAK**: the normal header with a MAC of four zero octets. The client may accept or reject its data, but it now knows its request was not authenticated. ## What a valid MAC proves, and what it does not A matching MAC establishes two things: - **Origin**: the packet was produced by someone holding that key. - **Integrity**: no header or extension field changed in transit. It does not establish: - **That the time is correct.** RFC 5905 says plainly that authentication in NTP does not necessarily imply the time is correct; an authenticated server can still be wrong, which is why clients compare several sources. - **Confidentiality.** RFC 8633 notes that neither of NTP's internal mechanisms encrypts the payload, because time is not considered secret. - **Protection against delay.** An attacker who holds packets back on one direction of the path changes no byte, so the MAC still verifies; RFC 8633 says none of these measures prevents delay manipulation. - **That the sender is the server.** Anyone holding the key can produce valid packets. In broadcast mode every client holds the key, so RFC 8633 warns that any one of them can forge broadcasts to the rest; broadcast SHOULD run only on a trusted network. ## From MD5 to AES-CMAC RFC 5905 requires that an implementation offering authentication support MD5, while acknowledging MD5's well-known weaknesses. **RFC 8573** (Standards Track, updating RFC 5905) states that keyed MD5 is not a secure MAC and MUST be deprecated. If NTP authentication is implemented, **AES-CMAC** (RFC 4493) MUST be computed over all header and extension fields, the key MUST be a 128-bit AES-128 key, and the tag MUST be at least 128 bits. A key is a triplet of **ID, type and key value**, and all three must match on both hosts. Implementations that do not support AES-CMAC neither send nor accept packets authenticated with such a key, so migrating means upgrading both ends of an association before switching its key type. ## The operating cost: keys RFC 8633 (BCP 223) spells out what running pre-shared keys involves: 1. Keys MUST be exchanged securely **by external means**; NTP has no key-exchange mechanism. 2. Each association SHOULD have **its own unique key**. 3. Keys SHOULD be **refreshed periodically**, but NTP offers nothing to help, so rotation is a manual, coordinated change on both ends. 4. Some implementations store keys in clear text, so the key file MUST be readable only by the NTP process. 5. Binding a key to a particular server is implementation-specific, and a key is trusted until that binding is removed. Run that across a fleet and the burden is plain: every client-server pair needs a key agreed in advance, and the server must hold all of them. That is why symmetric keys appear between routers, between peers and between a handful of internal servers, and almost never on a public server whose clients are unknown in advance. ## Where symmetric keys still fit | NTP mode | Recommended protection | |---|---| | Client-server (modes 3 and 4) | Network Time Security, RFC 8915 | | Symmetric peers (modes 1 and 2) | AES-CMAC keys, each passive association under a different key (RFC 8633) | | Broadcast (mode 5) | AES-CMAC keys, only on a trusted network | RFC 8915 itself names the symmetric MAC of RFC 5905 and RFC 8573 as the best current practice for the modes NTS does not cover. **Autokey** (RFC 5906, Informational) tried to automate keying with public-key cryptography; researchers found vulnerabilities, and RFC 8633 says Autokey SHOULD NOT be used.

  • Why is Autokey not the answer to NTP's key-distribution burden?
    Autokey, RFC 5906, is an Informational document that combined public-key certificates with hash chains so servers could be authenticated without pre-shared keys. Researchers found vulnerabilities in it, and RFC 8633 says Autokey SHOULD NOT be used. Client-server mode now uses Network Time Security (RFC 8915) instead, while peers and broadcast keep pre-shared AES-CMAC keys.
  • What does an NTP server send back when a client's MAC fails to verify?
    RFC 5905 has it answer with a crypto-NAK: the normal NTP header followed by a MAC of four zero octets, meaning a key identifier of zero and no digest. It tells the client its request could not be authenticated; the client may accept or reject the header data. It is not sent when the request arrived on a multicast address.
  • Why is one key shared by all broadcast clients weaker than a key per peer?
    Every broadcast client must hold the key the server uses to authenticate its broadcasts, so any client can produce packets that verify as coming from the server and attack the others. RFC 8633 therefore limits broadcast mode to trusted networks and recommends a separate key for each symmetric passive association.

saying these in an interview costs you the question

  • A valid NTP MAC proves the server's time is accurate.
  • NTP symmetric-key authentication encrypts the timestamps in each packet.
  • MD5-keyed NTP authentication is still the recommended choice.
  • NTP negotiates and rotates its symmetric keys automatically.
  • One key shared by every NTP client is the recommended setup.
  • A MAC on each NTP packet stops attackers from delaying it.