from Alice's
Adventures in Wonderland, Lewis Carroll
Our resident cryptographer; now you see him, now you don't.
Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder intending accidentally or on purpose to masquerade as that server. The NTPv3 specification RFC-1305 defines an scheme which provides cryptographic authentication of received NTP packets. Originally, this was done using the Data Encryption Standard (DES) algorithm operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was augmented by the RSA Message Digest 5 (MD5) algorithm using a private key, commonly called keyed-MD5. Either algorithm computes a message digest, or one-way hash, which can be used to verify the server has the correct private key and key identifier.
NTPv4 retains the NTPv3 schemes, properly described as symmetric-key cryptography and, in addition, provides a new Autokey scheme based on public-key cryptography. Public-key cryptography is generally considered more secure than symmetric-key cryptography, since the security is based on a private value which is generated by each server and never revealed. With Autokey all key distribution and management functions involve only public values, which considerably simplifies key distribution and storage.
Authentication is 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 described below specify the suite of keys, select the key for each configured association and manage the configuration operations.
The auth flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag 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 enabled, which is the default case, new broadcast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric-key or public-key schemes. 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.
In networks with firewalls and large numbers of broadcast clients it may be acceptable to disable authentication, since that avoids key distribution and simplifies network maintenance. However, when the configuration file contains host names, or when a server or client is configured remotely, host names are resolved using the DNS and a separate name resolution process. In order to protect against bogus name server messages, name resolution messages are authenticated using an internally generated key which is normally invisible to the user. However, if cryptographic support is disabled, 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 enabling the flag for name resolution and disabled it once the name resolution process is complete.
An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers. Cryptographic authentication in this mode uses public-key schemes as described below. The principle advantage of this manycast mode is that potential servers need not be configured in advance, since the client finds them during regular operation, and the configuration files for all clients can be identical.
In addition to the default symmetric-key cryptographic support, support for public-key cryptography is available if the requisite rsaref20 software distribution has been installed before building the distribution. Public-key cryptography provides secure authentication of servers without compromising accuracy and stability. The security model and protocol schemes for both symmetric-key and public-key cryptography are described below.
When ntpd is first started, it reads the key file specified int he keys command and installs the keys in the key cache. However, the keys must be activated with the trusted command before use. 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 symmetric private keys, public/private key pair, and the agreement parameters. See the ntp-genkeys page for a description of the formats of these files. They contain cryptographic values generated by the algorithms of the rsaref20 package and are in printable ASCII format. All file names include the timestamp, in NTP seconds, following the default names given below. Since the file data are derived from random values seeded by the system clock and the file name includes the timestamp, every generation produces a different file and different file name.
The ntp.keys file contains the DES/MD5 private keys. It must be distributed by secure means to other servers and clients sharing the same security compartment and made visible only to root. While this file is not used with the Autokey scheme, it is needed to authenticate some remote configuration commands used by the ntpq and ntpdc utilities. 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 agreement parameters, which are used only in symmetric (active and passive) modes. It is necessary that both peers beginning a symmetric-mode association share the same parameters, but it does not matter which ntp_dh file generates them. If one of the peers contains the parameters, the other peer obtains them using the Autokey protocol. If both peers contain the parameters, the most recent copy is used by both peers. If a peer does not have the parameters, they will be requested by all associations, either configured or not; but, none of the associations can proceed until one of them has received the parameters. Once loaded, the parameters can be provided on request to other clients and servers. The ntp_dh file can be also 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 host must have its own ntpkey_host file, which is normally provided to other hosts using the Autokey protocol Each server or peer association requires the public key associated with the particular server or peer to be loaded either directly from a local file or indirectly from the server using the Autokey protocol. These files can be widely distributed and stored using insecure means, since the data are public values.
The optional ntpkey_certif_host file contains the PKI certificate for the host. This provides a binding between the host hame and RSA public key. In the current implementation the certificate is obtained by a client, if present, but the contents are ignored.
Due to the widespread use of interface-specific naming, the host names used in configured and mobilized associations are determined by the Unix gethostname() library routine. Both the ntp-genkeys program and the Autokey protocol derive the name of the public key file using the name returned by this routine. While every server and client is required to load their own public and private keys, the public keys for each client or peer association can be obtained from the server or peer using the Autokey protocol. Note however, that at the current stage of development the authenticity of the server or peer and the cryptographic binding of the server name, address and public key is not yet established by a certificate authority or web of trust.
The NIST provides a table showing the epoch for all historic occasions of leap second insertion since 1972. The leapsecond table shows each epoch of insertion along with the offset of International Atomic Time (TAI) with respect to Coordinated Universtal Time (UTC), as disseminated by NTP. The table can be obtained directly from NIST national time servers using ftp as the ASCII file pub/leap-seconds.
While not strictly a security function, the Autokey scheme provides means to securely retrieve the leapsecond table from a server or peer. Servers load the leapsecond table directly from the file specified in the crypto command, while clients can load the table indirectly from the servers using the Autokey protocol. Once loaded, the table can be provided on request to other clients and servers.
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 overridden by the keysdir configuration 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 in /etc, which is normally not in a shared filesystem.
The recommended practice is to keep the timestamp extensions when installing a file and to install a link from the default name (without the timestamp extension) to the actual file. This allows new file generations to be activated simply by changing the link. However, ntpd parses the link name when present to extract the extension value and sends it along with the public key and host name when requested. This allows clients to verify that the file and generation time are always current. However, the actual location of each file can be overridden by the crypto configuration command.
All cryptographic keys and related parameters should be regenerated on a periodic and automatic basis, like once per month. The ntp-genkeys program uses the same timestamp extension for all files generated at one time, so each generation is distinct and can be readily recognized in monitoring data. While a public/private key pair must be generated by every server and client, the public keys and agreement parameters do not need to be explicitly copied to all machines in the same security compartment, since they can be obtained automatically using the Autokey protocol. However, it is necessary that all primary servers have the same agreement parameter file. The recommended way to do this is for one of the primary servers to generate that file and then copy it to the other primary servers in the same compartment using the Unix rdist command. Future versions of the Autokey protocol are to contain provisions for an agreement protocol to do this automatically.
Servers and clients can make a new generation in the following way. All machines have loaded the old generation at startup and are operating normally. At designated intervals, each machine generates a new public/private key pair and makes links from the default file names to the new file names. The ntpd is then restarted and loads the new generation, with result clients no longer can authenticate correctly. The Autokey protocol is designed so that after a few minutes the clients time out and restart the protocol from the beginning, with result the new generation is loaded and operation continues as before. A similar procedure can be used for the agreement parameter file, but in this case precautions must be take to be sure that all machines with this file have the same copy.
David L. Mills
<mills@udel.edu>