Message Authentication Code for the Network Time Protocol
updated by
- rfc-9748 — Updating the NTP Registries
updates
- rfc-5905 — Network Time Protocol Version 4: Protocol and Algorithms Specification
Extracted elements (8)
AES-CMAC was chosen over alternatives because it is immune to nonce-reuse vulnerabilities (it does not use a nonce), has good performance in latency and throughput, benefits from native hardware support (e.g., Intel AES-NI), and is widely supported in open source implementations.
Old NTP implementations that do not support AES-CMAC will not accept and will not send packets authenticated with an AES-CMAC key, meaning migration requires coordinated key updates.
Hosts wishing to use NTP authentication MUST implement AES-CMAC and share the corresponding symmetric key out of band.
If NTP authentication is implemented, AES-CMAC as specified in RFC 4493 MUST be computed over all fields in the NTP header and any extension fields present in the NTP packet.
MD5-based MAC for NTP authentication, as defined in RFC 5905, MUST be deprecated because it is not a secure MAC.
The MAC key for NTP MUST be an AES-128 key that is 128 bits in length, and the resulting MAC tag MUST be at least 128 bits in length.
A symmetric key for NTP authentication is a triplet of ID, type (e.g., MD5 or AES-CMAC), and the key itself; all three must match for successful packet authentication between two hosts.
The document refers to NIST SP 800-38B for CMAC mode authentication recommendations and to RFC 4493 Security Considerations for security guarantees of AES-CMAC. MD5-based authentication is deprecated as it is not a secure MAC per analysis in [BCK] and RFC 6151.