NIST Authenticated NTP Service

Outline

• Motivation for authenticated NTP
• How to request access; terms of service
• Implementation details
• Troubleshooting advice
• Frequently asked questions (FAQ)

Motivation for authenticated NTP

The Network Time Protocol (NTP) is a lightweight, typically stateless protocol for comparing computer clocks over routed networks. NTP's beneficial features include its simplicity and small packet size (ordinarily just 48 bytes within a UDP/IP packet), ability to measure (and compensate for) signaling delay between requester and server, warning of upcoming leap seconds, identification of a server’s source of time and its own estimate of precision and operational health.

In the context of information security, NTP data is generally not considered secret (though clients can use a variant of the protocol which reveals minimal information about the state of their clocks to servers or eavesdroppers) and is therefore not encrypted prior to transmission. Hypothetically, an adversary could fake authorship of NTP replies in order to feed false time data to a target user. Or, a packet transmission error might result in corrupted NTP data that is still well-formatted.

To help mitigate this risk, NIST supports “signed” or authenticated NTP by use of symmetric key cryptography.

As shown above, NIST creates and shares with each user unique random data, called a key value, for use with specialized NIST NTP servers. When these servers issue an NTP reply to the user, they compute and append a Message Authentication Code (MAC) following the procedure within RFC 5905. The MAC contains data identifying the key (a key number) and a (typically 128-bit or 160-bit) message digest, computed by processing the NTP data and the secret key value though a cryptographic hash function (see NIST FIPS 180-4). On receipt, the client software independently computes the message digest. If the computed message digest matches the digest in the reply packet (and the key number matches the assigned key number), the message was almost certainly authored by a counterparty possessing the key value, due to the “irreversible” property of hash functions.

How to request access; terms of service

NIST currently offers this service free of charge. We require written requests to arrive by U.S. mail or fax containing:

1. Your organization’s name, physical address, fax number (if desired as a reply method).
2. One or more point-of-contact personnel or system operators authorized to receive key data and other correspondence: names, phone numbers, email addresses.
3. Up to four static IPv4 network addresses under the user’s control which will be allowed to use the unique key. By special arrangement, additional addresses or address ranges may be requested.
4. Desired hash function (“key type”). NIST currently supports MD5, SHA1, SHA256, and HMAC-SHA256. Please list any limitations your client software places on key values, if known: maximum length, characters used, or whether hexadecimal key representations are required. If you prefer, please share details about your client software or NTP appliance so we can anticipate key format issues.
5. Desired method for NIST’s reply: U.S. mail, fax, or a secure download service operated by Department of Commerce.

A letter requesting access with the above information should be sent to:

Network Time Service
Mailstop 847
National Institute of Standards and Technology
325 Broadway
Boulder, CO 80305
Fax: +1 303-497-6461, or +1 303-497-7750

NIST will not use email for sending key data.

Questions about the service may be sent by email to internet-time-service [at] nist.gov (internet-time-service[at]nist[dot]gov.)

Keys will be expired if found to be unused. Server logs will be surveyed annually near the end of each fiscal year (September 30); keys found to have no logged use over a 14-day period will be marked for deletion. No notice will be given to users about key expiry. Likewise, no action is required by users to keep keys active except regular use of the key.

Implementation details

NIST Authenticated NTP servers will only respond to IPv4 network addresses registered by users. Also, the servers will only respond to authenticated NTP request packets if the key number in the request’s MAC is associated with the request’s source address.

To aid in user troubleshooting, servers will respond to ordinary un-signed NTP requests, but only to registered IPv4 network addresses. User networks that implement Network Address Translation (NAT), traffic proxying, or similar techniques may obscure the publicly routed address from users, making it difficult to preregister with NIST; please consult with your local network professionals.

At present, key numbers assigned by NIST will be between 1 and 32767.

Troubleshooting advice

Before contacting us for assistance, please complete as many of the following tests as possible and include the results in correspondence to NIST. Please refer to the full list of NIST NTP servers when troubleshooting. 

1. Attempt to send ordinary, unsigned NTP requests to any of NIST’s public non-authenticated NTP servers. To aid in troubleshooting, please try one or more server from each of NIST’s campuses, and additional non-NIST NTP servers. If you receive no NTP replies, there is likely a firewall or gateway within your network blocking NTP traffic. Please confer with your local network administrators.
2. Attempt to send ordinary, unsigned NTP requests to any of NIST’s authenticated NTP servers (or set a key number of zero, which also signals non-authenticated NTP). If you do not receive replies, either your publicly routed IPv4 address is different than what you registered with NIST, or your network implements a form of Network Address Translation (NAT) or other traffic proxying. Please confer with local network administrators.
3. If the test above succeeds but sending signed NTP requests fails, please double check that the assigned key number, key value, and hash function (“key type”) (i.e. MD5, SHA1, SHA256, HMAC-SHA256) are correctly communicated to your client software. Consult your client’s user manual to confirm:
   1. Are any hardware or software restarts needed when new key data is entered.
   2. Are additional steps needed to enable use of authenticated NTP generally?
   3. Are additional steps required to command use of the key when communicated with designated NIST servers (“peer associations” in some clients)?
   4. Are key values are limited in length, limited to a certain set of printable ASCII characters, or are required to be entered in a hexadecimal representation?

Some detailed troubleshooting for the popular client software NTPd is also available.

Frequently asked questions