NIST Authenticated NTP Service

In addition to its Internet Time Service (ITS), NIST operates NTP servers that support authentication. The messages from these servers will be available only to registered users. The additional authentication will allow users to verify that the responses they receive actually originated from a NIST server and that they were not modified in transit either by a malicious third party or by a network error.

Except for the additional support required for authenticated NTP, the servers that will be used for this service are identical to the other NIST servers. However, these servers will support authenticated NTP only - not the other time formats and services supported by the other NIST servers. The clocks on these systems will be synchronized using direct, hardwired connections to the NIST ensemble of atomic clocks that are co-located with the servers.

The authentication overlay does not improve the accuracy or the traceability of the NTP message exchange using this server, which are limited primarily by the stability and inbound-outbound symmetry of the delay in the network connection between the client system and the NIST time server. Although network conditions vary widely, our tests suggest that most users should realize a timing accuracy of 50 milliseconds (0.050 seconds) or better when using this (or any other) NIST server. Users whose applications require millisecond-level timing accuracies or stabilities should consult NIST for more details and advice on realizing these requirements using the NIST digital services.

The time messages will be authenticated using symmetric-key encryption in a manner that is fully compatible with the published NTP documentation. (Autokey and asymmetric key modes will not be used.) Each registered user will be assigned a unique encryption key, which will be linked to the IP address(es) of the user's system(s). The encryption key comprises two parts: a key number, which is an integer from 1 to 32767 and a key value, which is a string of characters chosen at random from the 62 characters: A-Z, a-z, and 0-9. The authenticated client computes a hash value based on a combination of the key characters and the NTP message and appends the key number and the hash value to the outgoing  request. The time servers compute a hash code in the same way – the key number in the received message is used to recover a private copy of the key string, which is then combined with the incoming NTP message, and the hash value of the combination is computed. This computed value is compared with the value appended to the message by the sender. If the comparison agrees, and if the source address of the request agrees with the value associated with the key number, the server constructs a reply message, adds the key value and computes the hash of the combination. The computed hash code is appended to the NTP message and the combination is sent back to the client. The structure of the reply from the server to the client is the same as the query from the client to the server.

The servers support both the MD5 and the SHA-1 hash methods. Support for the SHA-256 algorithm will be added to all of the servers starting on 1 February 2021. A user may request a key in any of the supported formats. The keys are not interchangeable, and each user can have only one key format at any time. The details of the hash algorithms are described in the literature. See, for example, the NIST publication FIPS 180-4 and FIPS 180-2 (the previous version of the document).

The hash algorithms do not have an inverse – the message cannot be constructed from the hash value. The authentication process on both the client and the server use the hash algorithm in the forward direction (compute hash from text input) only are therefore not limited because of this.

The weakness of a hash algorithm is the possibility of finding a “collision” – two different texts that have the same hash value. Although this is certainly possible in principle, the NTP packet is highly structured, and finding a collision that preserves the structure and expected values of the contents of the packet is more challenging that the general problem of finding a collision with an arbitrary text.

To assist users in troubleshooting the encryption process, a registered user will be able to communicate with the authenticated server using this assigned encryption key or using a default key of 0, which is equivalent to disabling the encryption algorithm. Users who are not registered will not be able to connect to this server, but can use any of the other NIST servers, which will not be modified.

See the list of NIST time servers.

The service will be provided at no charge, and user keys may be used to connect to any of the servers whose addresses are listed below. Additional hardware will be added in the future if the demand for the service is sufficiently great to warrant it.

Users who wish to use this service should send a letter to NIST using the US mail or FAX machine (e-mail is not acceptable). The request should contain the following information:

• Name and postal street address of the organization or individual
• Name and contact information for the system operator and an alternate name if possible. These should include the e-mail addresses and the preferred contact method.
• Network IP address of the client system that will be used to query the NIST server. A network name is desirable but not required, since the system will authenticate the request using IP addresses only. Users may request up to 4 contiguous IP addresses that will share the same key.

This information should be sent to:

Network Time Service
Mail stop 847
National Institute of Standards and Technology
325 Broadway
Boulder, Colorado 80305
FAX: 303 497 6461

NIST will reply with a key number and a key value. The reply will be by US mail only, e-mail will never be used.

The office that normally receives US mail and FAX messages currently has limited access, which may result in significant delays in processing requests. Prospective users of the service should contact internet-time-service [at] nist.gov (internet-time-service[at]nist[dot]gov) for assistance.

We will also provide instructions for how to add authentication to an existing generic NTP process. These instructions will explain how to add authentication to the daemon process ntpd and the single-query process ntpdate. The instructions found here should be adequate for most users. Users who have special requirements or who are using a custom version of NTP should contact NIST. We will provide as much assistance as possible. Users who wish to add authentication to the NTP process of a network appliance (such as a gateway, firewall or router) should contact the supplier to verify that the embedded NTP algorithm supports the symmetric key encryption algorithm.

User keys will expire at the end of each fiscal year (30 September) and can be renewed for an additional year. Each registered user will be sent a reminder early in September about the need for renewal.

Send questions or comments to jlevine [at] boulder.nist.gov (Judah Levine).