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 operations.
The auth flag affects all authentication procedures described below; however, it operates differently if cryptographic support is compiled in the distribution. If this support is available and the flag is enabled, then persistent associations are mobilized 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 inactivating 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 the ntpq utility.
The autokey scheme is specifically designed for multicast modes, where clients normally do not send messages to the server. In these modes, the server uses the scheme to generate a key list by repeated hashing of a secret value. The list is used in reverse order to generate a unique session key for each message sent. The client regenerates the session key and verifies the hash matches the previous session key. Each message contains the public values binding the session key to the secret value, but these values need to be verified only when the server generates a new key list or more than four server messages have been lost.
The scheme is appropriate for client/server and symmetric-peer modes as well. In these modes, the client generates a session key as in multicast modes. The server regenerates the session key and uses it to formulates a reply using its own public values. The client verifies the key identifier of the reply matches the request, verifies the public values and validates the message. In peer mode, each peer independently generates a key list and operates as in the multicast mode.
The autokey scheme requires no change to the NTP packet header format or message authentication code (MAC), which is appended to the header; however, if autokey is in use, an extensions field is inserted between the header and MAC. The extensions field contains a random public value which is updated at intervals specified by the revoke command, together with related cryptographic values used in the signing algorithm. The format of the extensions field is defined in Internet Draft draft-NTP- auth-coexist-00.txt. The MAC itself is constructed in the same way as NTPv3, but using the original NTP header and the extensions field padded to a 64-bit boundary. Each new public value is encrypted by the host private value. It is the intent of the design, not yet finalized, that the public value, encrypted public value, public key and certificate be embedded in the extensions field where the client can decrypt as needed. However, the relatively expensive encryption and decryption operations are necessary only when the public value is changed.
Note that both the original NTPv3 authentication scheme and the new NTPv4 autokey scheme operate separately for each configured association, so there may be several session key lists operating independently at the same time. Since all keys, including session keys, occupy the same key cache, provisions have been made to avoid collisions, where some random roll happens to collide with another already generated. Since something like four billion different session key identifiers are available, the chances are small that this might happen. If it happens during generation, the generator terminates the current session key list. By the time the next list is generated, the collided key will probably have been expired or revoked.
While permanent keys have lifetimes that expire only when manually revoked, random session keys have a lifetime specified at the time of generation. When generating a key list for an association, the lifetime of each key is set to expire one poll interval later than it is scheduled to be used. The maximum lifetime of any key in the list is specified by the autokey command. Lifetime enforcement is a backup to the normal procedure that revokes the last-used key at the time the next key on the key list is used.
The key file uses the same comment conventions as the configuration file. Key entries use a fixed format of the form
keyno type key
where keyno is a positive integer, type is a single character which defines the key format, and key is the key itself.
The key may be given in one of three different formats, controlled by the type character. The three key types, and corresponding formats, are listed following.