### Authentication Options

#### Authentication Support

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) operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was augmented by the RSA Message Digest 5 (MD5) 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 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.

#### Private Key Scheme

The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers involved must agree on the key and key identifier to authenticate their messages. Keys and related information are specified in a key file, usually called `ntp.keys`, which should be exchanged and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional ones can be used as passwords for the `ntpq` and `ntpdc` utility programs.

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.

#### Autokey Schemes

The original NTPv3 authentication scheme described in RFC-1305 continues to be supported; however, in NTPv4 an additional authentication scheme called autokey is available. It uses MD5 message digest, RSA public-key signature and Diffie-Hellman key agreement algorithms available from several sources, but not included in the NTPv4 software distribution. In order to be effective, the `rsaref20` package must be installed as described in the `README.rsa` file. Once installed, the configure and build process automatically detects it and compiles the routines required. The scheme has several modes of operation corresponding to the various NTP modes supported. RSA signatures and timestamps are used in all modes to verify the source of cryptographic values. All modes use a special cookie which can be computed independently by the client and server. In symmetric modes the cookie is constructed using the Diffie-Hellman key agreement algorithm. In other modes the cookie is constructed from the IP addresses and a private value known only to the server. Multicast and symmetric modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. These schemes are described along with an executive summary, current status, briefing slides and reading list, on the Autonomous Authentication page.

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.

#### Authentication Commands

`autokey [logsec]`
  Specifies the interval between regenerations of the session key list used with the autokey feature. Note that the size of the key list for each association depends on this interval and the current poll interval. The default value is 12 (4096 s or about 1.1 hours). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.
`controlkey key`
  Specifies the key identifier to use with the `ntpq` program, which uses the standard protocol defined in RFC-1305. This program is useful to diagnose and repair problems that affect `ntpd` operation. The `key` argument to this command is a key identifier for a trusted key, where the value can be in the range 1 to 65534, inclusive.
`crypto [privatekey file] [publickey file] [dhparms file]`
  This command requires the NTP daemon build process be configured with the RSA library. The presence of this command causes the daemon to load the host RSA private key file, public key file and Diffie-Hellman parameter file. If one or more files are left unspecified, the default names are used as described above. Following are the subcommands:

`privatekey file`
  Specifies the directory for the RSA private key file, which otherwise defaults to `/usr/local/etc`.``
`publickey file`
  Specifies the directory for the RSA public key file, which otherwise defaults to `/usr/local/etc`.``
`dhparms file`
  Specifies the directory for the Diffie-Hellman parameters file, which otherwise defaults to `/usr/local/etc`.``

`keys keyfile`
  Specifies the file name containing the private encryption keys and key identifiers used by `ntpd`, `ntpq` and `ntpdc` when operating in authenticated mode.
`keysdir path`
  This command requires the NTP daemon build process be configured with the RSA library. It specifies the default directory path for the private key file, parameters file and one or more public key files. The default when this command does not appear in the configuration file is `/usr/local/etc/`.
`requestkey key`
  Specifies the key identifier to use with the `ntpdc` utility program, which uses a proprietary protocol specific to this implementation of `ntpd`. This program is useful to diagnose and repair problems that affect `ntpd` operation. The `key` argument to this command is a key identifier for a trusted key, where the value can be in the range 1 to 65534, inclusive.
`revoke [logsec]`
  Specifies the interval between re-randomization of certain cryptographic values used by the autokey scheme, as a power of 2 in seconds. These values need to be updated frequently in order to deflect brute-force attacks on the algorithms of the scheme; however, updating some values is a relatively expensive operation. The default interval is 16 (65,536 s or about 18 hours). For poll intervals above the specified interval, the values will be updated for every message sent.
`trustedkey key [...]`
  Specifies the encryption key identifiers which are trusted for the purposes of authenticating peers suitable for synchronization, as well as keys used by the `ntpq` and `ntpdc` programs. The authentication procedures require that both the local and remote servers share the same key and key identifier for this purpose, although different keys can be used with different servers. The `key` arguments are 32-bit unsigned integers with values from 1 to 65,534.

#### Files

`ntp.keys` private MD5 keys
`ntpkey` RSA private key
`ntpkey_host` RSA public key
`ntp_dh` Diffie-Hellman parameters

#### Bugs

The `ntpkey_host` files are really digital certificates. These should be obtained via secure directory services when they become universally available.

Home