The network packets normally exchanged between NTP clients and servers to synchronize time don't contain any secrets, just the current time. So the policy of the NTP project maintainers is not to encrypt the whole NTP packets, but just to append a cryptographic signature to each network packet, so the NTP client can be sure the NTP packet it receives really originates from the NTP server it is expected from, and has not been spoofed modified by a man in the middle.
Similarly, cryptographic signatures are used to authenticate a remote host in case of remote configuration.
The original approach for these signatures was to use symmetric keys, which was introduced in NTP v3 but is still supported by NTP v4.
NTP v4 introduced an autokey feature which uses private/public key pairs for authentication. However, some time ago it has turned out that autokey signatures don't provide a level of protection as high as expected, so currently there's an IETF working group working on a successor for autokey, which is called Network Time Security (NTS). This is currently being implemented.
If encryption is really required for an application then an encrypted tunnel (VPN) between the NTP client and server can be set up, across which the unencrypted NTP packets can be exchanged. However, this also affects the network delay and jitter, and thus reduces the accuracy that can be achieved.
Network Time Security is to replace symmetric keys and autokey
in upcoming versions of time synchronization software like ntpd.
A very good introduction to NTS can be found in these blog articles written by
Martin Langer:
NTS is developed by the NTP working group at IETF:
Current NTS implementation projects:
Associated projects:
A potential problem is required backward compatibility of the extension fields of NTP packets used to append cryptographic hashes for autokey or symmetric keys. See:
In addition to symmetric keys, NTPv4 also supports autokey, which is based on public/private certificate pairs. It turned out that autokey is much less secure than initially expected, and not easy to configure. Here are some hints:
Here's the initial report saying that autokey is weak:
Symmetric key authentication was already introduced in NTP v3, but is still supported in current NTP v4 versions of the NTP reference implementation. The drawback of symmetric keys is that a secret key has to be exchanged in a safe way between servers and clients, while with public key authentication schemes only a public key had to be copied to clients.
Current implementations of ntpd support MD5 and SHA1. In theory it should also support other algorithms provided by openSSL,
but there are compatibility problems with the layout of the packet extension fields.
To configure symmetric keys we basically have to create a keys file, i.e. a text file containing the keys, then in ntp.conf specify:
trustedkey, requestkey, controlkey)server xyz … key n)So first you need to create a text file which contains one or more cryptographic keys, one key per line. For example:
1 M f294fa0 # MD5 key 2 MD5 BtdW/<gj2*2M;!'~qAIN # MD5 key 3 SHA1 094c533b614d9e4bcb6e18a97a7b0e4d459025bd # SHA1 key
The first column is a unique key ID number in the range 1..65535. The second column indicates the key type, which can be “M” or “MD5” for an MD5 key, or “SHA1” for an SHA1 key, and the 3rd column the key string. Optionally a comment can be appended, starting with a '#' character.
The usual name and location of this file is
on Linux: /etc/ntp.keys
on Windows: C:\Program Files\NTP\etc\ntp.keys
The ntp-keygen program shipped with the NTP package can be used to create a number of appropriate keys:
ntp-keygen -M
Unfortunately, some versions of the ntp-keygen program write the generated keys to a text file the name of which is more appropriate for autokey certificates, e.g. something like ntpkey_MD5key_pc-martin.3663577871. So the lines with the keys that shall really be used should be copied to the ntp.keys file.
The path to the keys file as well as the purpose of the key(s) to be used have to be specified in the ntp.conf file.
There are 3 keywords which specify the purpose of specific keys:
trustedkey has to be used to specify any key that should be trusted, including the ones specified by controlkey or requestkey.controlkey specifies the trusted key(s) to be used as password for the ntpq utility to avoid unauthorized configuration changesrequestkey specifies the trusted key(s) to be used as password for the ntpdc utility, which is obsolete nowAssuming the NTP server and client should use the key f294fa0he from the example above, The key ID can be different on the server and client, but the configuration must be such that the same key type and string is used on both.
For example, on a Linux machine server_1:
in ntp.keys:
1 M f294fa0
in ntp.conf:
keys /etc/ntp.keys # path to keys file trustedkey 1 # ID of key to be trusted
On a different Linux machine server_2:
in ntp.keys:
3 MD5 BtdW/<gj2*2M;!'~qAIN
in ntp.conf:
keys /etc/ntp.keys # path to keys file trustedkey 3 # ID of key to be trusted
On a Windows client:
in C:\Program Files\NTP\etc\ntp.keys:
5 MD5 f294fa0 7 M BtdW/<gj2*2M;!'~qAIN
in C:\Program Files\NTP\etc\ntp.conf:
keys “C:\Program Files\NTP\etc\ntp.keys” trustedkey 5 7 server server_1 iburst minpoll 6 maxpoll 6 key 5 server server_2 iburst minpoll 6 maxpoll 6 key 7
In case of the Windows client above please note:
If authentication has been configured correctly then the command ntpq -c as executed on the client should show something like:
ind assid status conf reach auth condition last_event cnt =========================================================== 1 24574 966a yes yes ok sys.peer sys_peer 6 2 24575 966a yes yes ok candidate none 6
The important thing here is that the auth column shows ok.
The ntpq utility can be used to query the status of a running NTP daemon (ntpd), but the program can also be used to change ntpd's configuration at runtime.
However, changing the configuration requires some authentication via Symmetric Key Authentication.
ntpq doesn't read the ntp.keys file but asks for a key ID and password (the key string) if authentication is required.
The key(s) to be used have to be specified by the controlkey keyword as well as by the trustedkey keyword in ntpd's ntp.conf file.
w32time eventually uses authentication extensions which are not compatible with those used by ntpd.
ntpd, but only if ntpd is used with a Samba server. The Windows port can't use this.
— Martin Burnicki martin.burnicki@meinberg.de, last updated 2023-01-25