Authentication Options

Authentication Support

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) algorithm, commonly called DES-CBC. Subsequently, this was augmented by the RSA Message Digest 5 (MD5) using a private key, commonly called keyed-MD5 algorithm. Either algorithm computes a digital signature, or message digest, which can be used by the receiver to verify the sender has the correct private key. NTPv4 retains this scheme and, in addition, provides a new autokey scheme based on reverse hashing and public keys. Authentication can be configured separately for each association and is enabled using the key or autokey subcommands on the peer, server, broadcast and manycastclient commands as described in the  Configuration Options page.

The most important authentication function is to verify that a server can be trusted to mobilize a persistent association at a client. If this function is not available, the client is vulnerable to any rogue server in the Internet to destabilize the client clock. For this reason, and by default, an association will not be mobilized unless the server has the correct key and key identifier. In some cases, it may be desirable to allow an association to be mobilized in other cases. If so, the disable auth command can be included in the configuration file as described in the Configuration Options page.

Private Key Scheme

The original RFC-1305 specification allows any one of possibly 65,536 keys, each distinguished 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 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.

Autokey Scheme

The original NTPv3 authentication scheme described in RFC-1305 continues to be supported. In NTPv4, an additional authentication scheme called autokey is available. It operates much like the S-KEY scheme, in that a session key list is constructed and the entries used in reverse order. A description of the scheme, along with a comprehensive security analysis, is contained in a technical report available from the IETF web page .

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.

Authentication Commands

keys keyfile
Specifies the file name containing the encryption keys and key identifiers used by ntpd, ntpq and ntpdc when operating in authenticated mode. The format of this file is described later in this document.
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 less than 65,536. Note that NTP key 0 is used to indicate an invalid key and/or key identifier, so should not be used for any other purpose.
requestkey key
Specifies the key identifier to use with the ntpdc 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 32-bit key identifier for a previously defined trusted key.  If no requestkey command is included in the configuration file, or if the keys don't match, any request to change a server variable with be denied.
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 32-bit key identifier for a trusted key in the key cache. If no controlkey command is included in the configuration file, or if the keys don't match, any request to change a server variable with be denied.

Authentication Key File Format

In the case of DES, the keys are 56 bits long with, depending on type, a parity check on each byte. In the case of MD5, the keys are 64 bits (8 bytes). ntpd reads its keys from a file specified using the -k command line option or the keys statement in the configuration file. While key number 0 is fixed by the NTP standard (as 56 zero bits) and may not be changed, one or more of the keys numbered 1 through 15 may be arbitrarily set in the keys file.

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.

The key is a 64-bit hexadecimal number in the format specified in the DES specification; that is, the high order seven bits of each octet are used to form the 56-bit key while the low order bit of each octet is given a value such that odd parity is maintained for the octet. Leading zeroes must be specified (i.e., the key must be exactly 16 hex digits long) and odd parity must be maintained. Hence a zero key, in standard format, would be given as 0101010101010101.
The key is a 64-bit hexadecimal number in the format specified in the NTP standard. This is the same as the DES format, except the bits in each octet have been rotated one bit right so that the parity bit is now the high order bit of the octet. Leading zeroes must be specified and odd parity must be maintained. A zero key in NTP format would be specified as 8080808080808080.
The key is a 1-to-8 character ASCII string. A key is formed from this by using the low order 7 bits of each ASCII character in the string, with zeroes added on the right when necessary to form a full width 56-bit key, in the same way that encryption keys are formed from Unix passwords.
The key is a 1-to-8 character ASCII string, using the MD5 authentication scheme. Note that both the keys and the authentication schemes (DES or MD5) must be identical between a set of peers sharing the same key number.
Note that the keys used by the ntpq and ntpdc programs are checked against passwords requested by the programs and entered by hand, so it is generally appropriate to specify these keys in ASCII format. 
David L. Mills (