NTPv4 retains the NTPv3 schemes and, in addition, provides a new autokey scheme based on reverse hashing and public key cryptography. Authentication can be configured separately for each association using the key or autokey subcommands on the peer, server, broadcast and manycastclient commands as described in the Configuration Options page.
The authentication options specify the suite of keys, select the key for each configured association and manage the configuration operations, as described below. The auth flag which controls these functions can be set or reset by the enable and disable configuration commands and also by remote configuration commands sent by a ntpdc program running in another machine. If this flag is set, persistent peer associations and remote configuration commands are effective only if cryptographically authenticated. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating in the latter mode invites a significant vulnerability where a rogue hacker can seriously disrupt client timekeeping.
The auth flag affects all authentication procedures described below; however, it operates differently if cryptographic support (AUTOKEY) is compiled in the distribution, which is normally the case. If this support is available and the flag is enabled, then persistent associations are mobilized in multicast client and symmetric passive modes and remote configuration commands are effective only if successfully authenticated. If the support is unavailable and the flag is enabled, then it is not possible under any conditions to mobilize persistent associations or respond to remote configuration commands. The auth flag normally defaults to set if cryptographic support is available and to reset otherwise.
With the above vulnerabilities in mind, it is desirable to set the auth flag in all cases. One aspect which is often confusing is the name resolution process which maps server names in the configuration file to IP addresses. In order to protect against bogus name server messages, this process is authenticated using an internally generated key which is normally invisible to the user. However, if cryptographic support is unavailable and the auth flag is enabled, the name resolution process will fail. This can be avoided either by specifying IP addresses instead of host names, which is generally inadvisable, or by leaving the flag disabled and enabling it once the name resolution process is complete.
When ntpd is first started, it reads the key file and installs the keys in the key cache. However, the keys must be activated before they can be used with the trusted command. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using ntpdc. This also provides a revocation capability that can be used if a key becomes compromised. The requestkey command selects the key used as the password for the ntpdc utility, while the controlkey command selects the key used as the password for the ntpq utility.
The cryptographic values used by the autokey scheme are incorporated as a set of files generated by the ntp_genkeys program, including the DES/MD5 private keys, RSA public/private key pair, and the Diffie-Hellman parameters. See the ntp_genkeys page for a description of the format and use of these files. They contain cryptographic values generated by the algorithms of the rsaref20 package and are in printable ASCII format. Since the algorithms are seeded by the system clock, each run of this program will produce a different outcome.
The ntp.keys file contains the private DES/MD5 keys. It must be distributed by secure means to other servers and clients sharing the same security compartment and made visible only to root. The ntpkey file contains the RSA private key. It is useful only to the machine that generated it and never shared with any other daemon or application program, so must be made visible only to root. The ntp_dh file contains the Diffie-Hellman parameters. It is necessary that all servers and clients of a security compartment share a single ntp_dh file, but it does not matter which one. This file can be distributed using insecure means, since the data are public values.
The ntpkey_host file contains the RSA public key, where host is the name of the host. Each configured server or peer association requires the public key file associated with the particular server or peer to be installed at a default location or as specified by the commands below. In addition, public key files are required for associations that might be mobilized by multicast or symmetric servers. These files can be widely distributed and stored using insecure means, since the data are public values.
Due to the widespread use of interface-specific naming, the host names used in configured and mobilized associations are determined by different rules. The ntp_genkeys program uses the name returned by the Unix gethostname() library routine and this is the name normally used when installing the file on some other host. However, the default name used when configuring an association at run time is the canonical name returned by the DNS resolver, and this might not be the same name. The preferred workaround on the host installing the file is to use the Unix nslookup command to determined the canonical name and install a link from that name to the actual name. Alternatively, the default can be overriden with by the publickey subcommand of the server or peer configuration command.
For other than configured associations that might be mobilized by multicast servers or symmetric peers, the name is determined directly from the server or peer as part of the protocol dance that authenticates the source. The server or peer uses the same gethostname() library routine as the ntp_genkeys program, so there is no confusion.
All key files are installed by default in /usr/local/etc, which is normally in a shared filesystem in NFS-mounted networks and avoids installing them in each machine separately. The default can be overriden by the keysdir configuration file command. However, this is not a good place to install the private key file, since each machine needs its own file. A suitable place to install it is /etc, which is normally not in a shared filesystem. The default can be overriden by the subcommand of the crypto configuration command.
David L. Mills <mills@udel.edu>