Authentication Options

giffrom Alice's Adventures in Wonderland, Lewis Carroll

Our resident cryptographer; now you see him, now you don't.

Last update: 02:46 UTC Monday, September 03, 2007


Related Links

Table of Contents


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 a legitimate server. The NTPv3 specification RFC-1305 defines a 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 replaced 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 scheme, 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 private values which are generated by each participant and never revealed. With the exception of the group parameters described later, all key distribution and management functions involve only public values, which considerably simplifies key distribution and storage. Public key management is based on X.509 certificates, which can be provided by commercial services or produced by utility programs in the OpenSSL software library or the NTPv4 distribution.

While the algorithms for symmetric key cryptography are included in the NTPv4 distribution, public key cryptography requires the OpenSSL software library to be installed before building the NTP distribution. This library is available from http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the library routines required.

Authentication is configured separately for each association using the key or autokey subcommand on the peer, server, broadcast and manycastclient configuration commands as described in the Configuration Options page. The authentication options described below specify the locations of the key files, if other than default, which symmetric keys are trusted and other details needed by the optional Autokey protocol. The ntp-keygen program is used to generate the various key files, certificate files and identity parameters files described below.

Authentication is always enabled, although ineffective if not configured as described below. If an NTP packet includes a message authentication code (MAC), consisting of a key ID;and message digest, it is accepted only if the key ID matches a trusted key and and the message digest is verified with this key. Furthermore, the Autokey scheme requires a preliminary protocol exchange to obtain the server certificate, verify its credentials and initialize the protocol

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 commands and also by remote configuration commands sent by a ntpdc program running on another machine. If this flag is enabled, which is the default, new broadcast/manycast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric key or public key cryptography. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating with the auth flag disabled invites a significant vulnerability where a rogue hacker can masquerade as a legitimate server and seriously disrupt system timekeeping. It is important to note that this flag has no purpose other than to allow or disallow a new association in response to new broadcast and symmetric active messages and remote configuration commands and, in particular, the flag has no effect on the authentication process itself.

The security model and protocol schemes for both symmetric key and public key cryptography are summarized below; further details are in the briefings, papers and reports at the NTP project page linked from www.ntp.org.

Symmetric Key Cryptography

The original RFC-1305 specification allows any one of possibly 65,534 keys (excluding zero), each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key file, usually called ntp.keys, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the ntpq and ntpdc utility programs. Ordinarily, the ntp.keys file is generated by the ntp-keygen program.

When ntpd is first started, it reads the key file specified in the keys configuration command and installs the keys in the key cache. However, individual keys must be activated with the trustedkey 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.

Public Key Cryptography

NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the Autokey Protocol page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the Identity Schemes page are based on cryptographic challenge/response exchanges. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the Autonomous Authentication page.

The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links generated by the ntp-keygen program. These define the required host key, required host certificate and optional sign key and identity parameters. The certificate defines the Autokey host name and the selected cryptographic algorithms.

NTP Secure Groups

NTP secure groups are used to define cryptographic compartments and security hierarchies. All hosts belonging to a named secure group share a secret group key which can be encrypted with individual passwords. Each group includes one or more trusted hosts operating at the root, or lowest stratum in the group. The other hosts in the group are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts, to one or more trusted hosts. When the protocol first starts, each host recursively retrieves the certificates along the trail in order to verify the host identity and avoid masquerade and middleman attacks. The trail concludes at a trusted host, the name of which defines the identity parameters used to confirm group membership.

Secure groups can be configured as hierarchies where the trusted hosts of one group can be clients of one or more other groups operating at a lower stratum. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.

Naming Conventions

It is important to note that Autokey does not use DNS to resolve names or addresses, since DNS can't be completely trusted until the name servers have synchronized clocks. The Autokey names for hosts and groups are used only to verify group membership and create group hierarchies.

By convention the Autokey name of a group host other than the trusted hosts is the name returned by the Unix gethostname() system call or equivalent in other systems. Also by convention the host name for all trusted hosts is the same name, called the group name. However, it is possible to use other names as long as the certificate trails remain acyclic. The group name is also the name of the identity parameters resident in every group host.

Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers are operated outside firewall perimeters.

Configuration

Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. The simplest scenario consists of a secure group with one or more trusted hosts at the same low stratum and with dependent clients at higher strata, all sharing the same group identity parameters.

On behalf of the group, a trusted host generates a host key, trusted certificate and identity parameters, all encrypted with a private password. Other hosts generate a host key encrypted with a private password and public nontrusted certificate. In the intended model, a host sends a mail message to a trusted host and requests the group identity parameters encrypted with a specified password. Note that, at least in the IFF scheme, the client parameters is a subset of the identity parameters, so hosts other than trusted hosts cannot masquerated as trusted.

The remaining group hosts are configured to provide an acyclic certificate trail ending at a trusted host. There is some art to this process, which may depend on anticipated failure scenarios where the trail might become discontinuous. In general, the trail should follow the expected stratum trail and provide redundancy.

Operation

A specific combination of authentication scheme (none, symmetric key, public key) and identity scheme is called a cryptotype, although not all combinations are compatible. There may be management configurations where the clients, servers and peers may not all support the same cryptotypes. A secure NTPv4 subnet can be configured in many ways while keeping in mind the principles explained above and in this section. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice.

The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when an NTP packet of appropriate cryptotype arrives. When mobilized by a server or peer configuration command and no key or autokey subcommands are present, the association is not authenticated. If the key subcommand is present, the association is authenticated using the symmetric key ID specified. If the autokey subcommand is present, the association is authenticated using Autokey.

With Autokey, the cryptotype of the association is determined by the set of files generated by the ntp-keygen utility program. All configurations include a public/private host key and matching certificate. Absent identity parameters, this is a Trusted Certificate (TC) scheme. There are three identity schemse, IFF, GQ and MV destcribed on the Identity Schemes page. Each is characterized by a set of private parameters that are distributed to each group host by secure means.

A group can operate where the cryptotype can be different for each client. One client can elect to use no authentication at all, another with the TC scheme and others with IFF, GQ and/or MV. However, a host cannot prove identity to a downstream client unless it has the corresponding identity parameters.

Examples

The figure shows what might be a typical scenario involving three secure groups called Alice, Helen and Carol. Alice has trusted hosts A and B and nontrusted hosts C and D. Helen has trusted host R and nontrusted host S. Carol has trusted host X and nontrusted hosts Y and Z. Trusted host X in Carol is a client of nontrusted host C in Alice and nontrusted host S in Helen. Assume the IFF identity scheme is used in Alice, the GQ identity scheme in Helen and the TC scheme in Carol. For clarity, assume the passwords for all hosts in a group is the group name.

gif

Run the ntp-keygen program on the Alice hosts:

A: ntp-keygen -q alice -s alice -T -I
B: ntp-keygen -q alice -s alice -T
C and D: ntp-keygen -q alice -i alice

Copy the ntp_IFFpar_alice.fstamp file and ntp_iff_alice link from A to all group hosts B, C and D. Since the paswords are the same, it is not necessary to use the -p option.

In the NTP configuration files for Alice hosts:

A and B: crypto pw alice host alice
C and D: crypto pw alice ident alice

Run the ntp-keygen program on Helen hosts:

R: ntp-keygen -q helen -s helen -T -G
S: ntp-keygen -q helen -i helen

Copy the C

In the NTP configuration files for Alice hosts:

R: server (radio clock)
crypto pw helen host helen
S: server R
crypto pw helen ident helen

Run the ntp-keygen on Carol hosts:

X: ntp-keygen pw carol host carol
Y, Z: ntp-keygen -q carol -i carol

Since X is a client of both Alice and Helen, copy the ntp_IFFpar_alice.fstamp file and ntp_iff_alice link from A to X and the ntp_IFFpar_alice.fstamp file and ntp_iff_alice link from R to X. When X follows the certificate trail to either A or B, it will find the Alice self-signed certificate for Alice load the GQ identity scheme for Alice. A similar operation will occur for Helen.

Authentication Commands

autokey [logsec]
Specifies the interval between regenerations of the session key list used with the Autokey protocol. 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 utility, which uses the standard protocol defined in RFC-1305. The key argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
crypto [cert file] [randfile file] [host file] [sign file] [ident groupname] [pw password]
This command requires the OpenSSL library. It activates public key cryptography and loads the required public/private encryption and sign kyes and public certificat. If one or more files are left unspecified, the default names are used as described below. Unless the complete path and name of the file are specified, the location of a file is relative to the keys directory specified in the keysdir command or default /usr/local/etc. Following are the subcommands:
cert file
Specifies the location of the required host public certificate file. This overrides the link ntpkey_cert_hostname in the keys directory.
host file
Specifies the location of the required host key file. This overrides the link ntpkey_host_hostname in the keys directory.
pw password
Specifies the password to decrypt files containing private keys and identity parameters.
randfile file
Specifies the location of the random seed file used by the OpenSSL library. The defaults are described on the ntp-keygen page.
sign file
Specifies the location of the optional sign key file. This overrides the link ntpkey_sign_hostname in the keys directory. If this file is not found, the host key is also the sign key.
keys keyfile
Specifies the complete path and location of the MD5 key file containing the keys and key identifiers used by ntpd, ntpq and ntpdc when operating with symmetric key cryptography. This is the same operation as the -k command line option.
keysdir path
This command specifies the default directory path for cryptographic keys, parameters and certificates. The default 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. The key argument is a key identifier for the trusted key, where the value can be in the range 1 to 65,534, 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 key identifiers which are trusted for the purposes of authenticating peers with symmetric key cryptography, 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.

Error Codes

Errors can occur due to mismatched configurations, unexpected restarts, expired certificates and unfriendly people. In most cases the protocol state machine recovers automatically by retransmission, timeout and restart, where necessary. Some errors are due to mismatched keys, digest schemes or identity schemes and must be corrected by installing the correct media and/or correcting the configuration file. One of the most common errors is expired certificates, which must be regenerated and signed at least once per year using the ntp-keygen program.

The following error codes are reported via the NTP control and monitoring protocol trap mechanism.

101 (bad field format or length)
The packet has invalid version, length or format.
102 (bad timestamp)
The packet timestamp is the same or older than the most recent received. This could be due to a replay or a server clock time step.
103 (bad filestamp)
The packet filestamp is the same or older than the most recent received. This could be due to a replay or a key file generation error.
104 (bad or missing public key)
The public key is missing, has incorrect format or is an unsupported type.
105 (unsupported digest type)
The server requires an unsupported digest/signature scheme.
106 (unsupported identity type)
The client or server has requested an identity scheme the other does not support.
107 (bad signature length)
The signature length does not match the current public key.
108 (signature not verified)
The message fails the signature check. It could be bogus or signed by a different private key.
109 (certificate not verified)
The certificate is invalid or signed with the wrong key.
110 (host certificate expired)
The old server certificate has expired.
111 (bad or missing cookie)
The cookie is missing, corrupted or bogus.
112 (bad or missing leapseconds table)
The leapseconds table is missing, corrupted or bogus.
113 (bad or missing certificate)
The certificate is missing, corrupted or bogus.
114 (bad or missing group key)
The identity key is missing, corrupt or bogus.
115 (protocol error)
The protocol state machine has wedged due to unexpected restart
116 (server certificate expired)
The old server certificate has expired.

Files

See the ntp-keygen page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.