Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as described in Table 13-3. The default cryptotype uses RSA encryption, MD5 message digest and TC identification. First, configure a NTP subnet including one or more low-stratum trusted hosts from which all other hosts derive synchronization directly or indirectly. Trusted hosts have trusted certificates; all other hosts have nontrusted certificates. These hosts will automatically and dynamically build authoritative certificate trails to one or more trusted hosts. A trusted group is the set of all hosts that have, directly or indirectly, a certificate trail ending at a trusted host. The trail is defined by static configuration file entries or dynamic means described on the Section 13.4 page.

Perform the following on each trusted host. To insure a fresh fileset, remove all tcpip$ntpkey files, then run ntp_keygen -T to generate keys and a trusted certificate. On all other hosts do the same, but leave off the -T flag to generate keys and nontrusted certificates. When complete, start NTP on the systems beginning at the lowest stratum and working up the tree. It may take some time for Autokey to instantiate the certificate trails throughout the subnet, but setting up the environment is completely automatic.

If it is necessary to use a different sign key or different digest/signature scheme than the default, run ntp_keygen with the -S type option, where type is either RSA or DSA . You most often need to do this when a DSA-signed certificate is used. If it is necessary to use a different certificate scheme than the default, run ntp_keygen with the -c scheme option and selected scheme as needed. If ntp_keygen is run again without these options, it generates a new certificate using the same scheme and sign key.

After setting up the environment it is advisable to update certificates from time to time, if only to extend the validity interval. Simply run ntp_keygen with the same flags as before to generate new certificates using existing keys. However, if the host or sign key is changed, the NTP Server should be restarted. When the NTP Server is restarted, it loads any new files and restarts the protocol. Other dependent hosts will continue as usual until signatures are refreshed, when the protocol is restarted.

13.9.5 Identity Schemes

As described in Section 13.7.2.4, the default TC identity scheme is vulnerable to a middleman attack. However, there are more secure identity schemes available, including PC, IFF, GQ and MV. These schemes are based on a TA, one or more trusted hosts and some number of nontrusted hosts. Trusted hosts prove identity using values provided by the TA, while the remaining hosts prove identity using values provided by a trusted host and certificate trails that end on that host. The name of a trusted host is also the name of its subgroup and also the subject and issuer name on its trusted certificate. The TA is not necessarily a trusted host in this sense, but often is.

In some schemes there are separate keys for servers and clients. A server can also be a client of another server, but a client can never be a server for another client. In general, trusted hosts and nontrusted hosts that operate as both server and client have parameter files that contain both server and client keys. Hosts that operate only as clients have key files that contain only client keys.

The PC scheme supports only one trusted host in the group. On trusted host alice run ntp_keygen -"P" -p password to generate the host key file tcpip$ntpkey_RSAkey_alice.filestamp and trusted private certificate file tcpip$ntpkey_RSA-MD5_cert_alice.filestamp . Copy both files to all group hosts; they replace the files that would be generated in other schemes. On each host bob use the -l option to install a symbolic link from the generic name tcpip$ntpkey_host_bob to the host key file and symbolic link tcpip$ntpkey_cert_bob to the private certificate file. Note the generic links are on bob , but point to files generated by trusted host alice . In this scheme it is not possible to refresh either the keys or certificates without copying them to all other hosts in the group.

For the IFF scheme proceed as in the TC scheme to generate keys and certificates for all group hosts, then for every trusted host in the group, generate the IFF parameter file. On trusted host alice run tcpip$ntp_keygen -"T" -"I" -p password to produce her parameter file tcpip$ntpkey_IFFpar_alice.filestamp , which includes both server and client keys. Copy this file to all group hosts that operate as both servers and clients and install a symbolic link using the -l option from the generic tcpip$ntpkey_iff_alice to this file. If there are no hosts restricted to operate only as clients, there is nothing further to do. Because the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.

If a rogue client has the parameter file, it could masquerade as a legitimate server and present a middleman threat. To eliminate this threat, the client keys can be extracted from the parameter file and distributed to all restricted clients. After generating the parameter file, on alice run ntp_keygen -e and pipe the output to a file or mail program. Copy or mail this file to all restricted clients. On these clients install a symbolic link from the generic tcpip$ntpkey_iff_alice to this file by issuing the command ntp_keygen -"I" -l file . To further protect the integrity of the keys, each file can be encrypted with a secret password.

For the GQ scheme proceed as in the TC scheme to generate keys and certificates for all group hosts, then for every trusted host in the group, generate the IFF parameter file. On trusted host alice run ntp_keygen -"T" -"G" -p password to produce her parameter file tcpip$ntpkey_GQpar_alice.filestamp , which includes both server and client keys. Copy this file to all group hosts and install a symbolic link from the generic tcpip$ntpkey_gq_alice to this file by issuing the command ntp_keygen -"G" -l file . In addition, on each host bob install a symbolic link from generic tcpip$ntpkey_gq_bob to this file. As the GQ scheme updates the GQ parameters file and certificate at the same time, keys and certificates can be regenerated as needed.

For the MV scheme, proceed as in the TC scheme to generate keys and certificates for all group hosts. For illustration assume trish is the TA, alice one of several trusted hosts and bob one of her clients. On TA trish run ntp_keygen -"V" (n) -p password , where n is the number of revokable keys (typically 5) to produce the parameter file tcpip$ntpkey_MVpar_trish.filestamp and client key files tcpip$ntpkey_MVkeyd_trish.filestamp where d is the key number (0 < d < n). Copy the parameter file to alice and install a symbolic link from the generic tcpip$ntpkey_mv_alice to this file by issuing the command ntp_keygen -"V" -l file . Copy one of the client key files to alice for later distribution to her clients. Which client key file goes to alice does not matter, because they all work the same way. alice copies the client key file to all of her clients. On client bob install a symbolic link from generic tcpip$ntpkey_mv_bob to the client key file. As the MV scheme is independent of keys and certificates, these files can be refreshed as needed.

Table 13-9 describes the command line options.

Table 13-9 Command Line Options

Option	Description
-c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]	Select certificate message digest/signature encryption scheme. Note that RSA schemes must be used with a RSA sign key and DSA schemes must be used with a DSA sign key. The default without this option is RSA-MD5 .
-d	Enable debugging. This option displays the cryptographic data produced in eye-friendly billboards.
-e	Write the IFF client keys to the standard output. This is intended for automatic key distribution by copy or mail.
-G	Generate parameters and keys for the GQ identification scheme, obsoleting any that may exist.
-g	Generate keys for the GQ identification scheme using the existing GQ parameters. If the GQ parameters do not yet exist, create them first.
-H	Generate new host keys, obsoleting any that may exist.
-I	Generate parameters for the IFF identification scheme, obsoleting any that may exist.
-i name	Set the suject name to name. This is used as the subject field in certificates and in the file name for host and sign keys.
-l	Create a symbolic link from the generic scheme file to host, certificate, or paramater file specified. Requires specification of identity scheme option first on command line.
-M	Generate MD5 keys, obsoleting any that may exist.
-m modulus	The modulus size in bits used to generate keys and parameters. Default is 512 bits.
-P	Generate a private certificate. By default, the program generates public certificates.
-p password	Encrypt generated files containing private data with password and the DES-CBC algorithm.
-q password	Set the password for reading files to password.
-r hostname	Set the name of the trusted host to hostname.
-S [ RSA | DSA ]	Generate a new sign key of the designated type, obsoleting any that may exist. By default, the program uses the host key as the sign key.
-s name	Set the issuer name to name. This is used for the issuer field in certificates and in the file name for identity files.
-T	Generate a trusted certificate. By default, the program generates a non-trusted certificate.
-V nkeys	Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
-v nkeys	Generate keys for the MV identification scheme using the existing VM parameters. If the MV parameters do not yet exist, create them.

13.9.6 Cryptographic Data Files

13.9.7 Generating Symmetric Keys

The NTP service reads keys from a keys file that is specified using the keys command in the configuration file. You can supply one or more keys from 1 to 15 in the keys file.

Key entries use the following format:

key-ID key-type key-value

Each entry contains the following:

• key-ID, which is an arbitrary, unsigned 32-bit number (in decimal). The range of possible values is 1 to 15. Key IDs are specified by the requestkey and controlkey statements in the configuration file. The key ID number 0 (56 zero bits) is reserved; it is used to indicate an invalid key ID or key value.
• key-type, which identifies the type of key value. Only one key format, M, is currently supported. This indicates that the MD5 authentication scheme is being used.
• key-value, which is an ASCII string up to 8 characters long. The following characters are not allowed:

  space
  pound sign (#)
  \t
  \n
  \0

Because this file contains authorization data, HP recommends that you limit read access to this file. In particular, you should disable world read access.

The following is a sample keys file:

# # 4 M DonTTelL 6 M hElloWrl 12 M ImASecrt

13.10 Solving NTP Problems

Some common NTP problems include:

• System clock not synchronized.
  NTP cannot synchronize a clock that is off by more than 1000 seconds. To solve this problem, set the clock using NTPDATE, then restart NTP.
• NTPDATE fails to set the clock.
  This occurs if NTP is already running.
• More than one service is actively setting the system clock.
  NTP can run with other time services but must be explicitly instructed not to set the system clock. NTP can still provide synchronization to other clients even if it is not updating the system clock.
• NTP appears to be running without error, but the system clock is off by a one-, two-, three-, or four-hour interval.
  You might need to adjust the time zone differential. For more information, please consult the OpenVMS documentation set.

Once the configuration file has been created and edited, the next step is to verify correct operation and then fix any resulting problems.

13.10.1.1 Initial Startup

The best way to verify correct operation is by using the NTPQ and NTPDC programs, either on the server itself or from another machine elsewhere in the network. The NTPQ program implements the management functions specified in the NTP specification RFC 1305, Appendix A. The NTPDC program implements additional functions not provided in the standard. Both programs can be used to inspect the state variables defined in the specification and, in the case of NTPDC, additional ones of interest. In addition, the NTPDC program can be used to selectively reconfigure and enable or disable some functions while the server is running. Problems are apparent in the server's log file. The log file should show the startup banner, some brief initialization data, and the computed precision value.

Another common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the ping command. When the server is first started it normally polls the servers listed in the configuration file at 64-second intervals. To allow a sufficient number of samples for the NTP algorithms to discriminate reliably between correctly operating servers and possible intruders, at least four valid messages from the majority of servers and peers listed in the configuration file are required before the server can set the local clock. However, if the difference between the client time and server time is greater than the panic threshold (which defaults to 1000 seconds), the server sends a message to the server log and shuts down without setting the clock. It is necessary to set the local clock to within the panic threshold first, either manually by wristwatch and the SET TIME command, or by using the NTPDATE command. The panic threshold can be changed by the tinker panic statement.

13.10.1.2 Verifying Correct Operation

After starting the server, run the NTPQ program with the -n switch to avoid distractions because of name resolution problems. Use the peer command to display a list showing the status of configured peers and other clients trying to access the server. After operating for a few minutes, the display should look similar to the following:

NTPQ> peer remote refid st t when poll reach delay offset jitter ===================================================================== -isipc6.cairn.ne .GPS1. 1 u 18 64 377 65.592 -5.891 0.044 +saicpc-isiepc2. pogo.udel.edu 2 u 241 128 370 10.477 -0.117 0.067 +uclpc.cairn.net pogo.udel.edu 2 u 37 64 177 212.111 -0.551 0.187 *pogo.udel.edu .GPS1. 1 u 95 128 377 0.607 0.123 0.027

The host names or addresses shown in the remote column correspond to the server and peer entries listed in the configuration file; however, the DNS names might not agree if the names listed are not the canonical DNS names. The refid column shows the current source of synchronization; the st column shows the stratum; the t column shows the type ( u = unicast, m = multicast, l = local, - = don't know); and the poll column shows the poll interval in seconds. The when column shows the time (in seconds) since the peer was last heard, and the reach column shows the status of the reachability register (in octal) (see RFC 1305). The remaining entries show the latest delay, offset, and jitter (in milliseconds). Note that, in NTP Version 4, what used to be the dispersion column is replaced by the jitter column.

The symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked with an asterisk (*), while additional peers that are not currently selected but are designated acceptable for synchronization are marked with a plus sign (+). Peers marked with * and + are included in the weighted average computation to set the local clock; the data produced by peers marked with other symbols are discarded. See Table 13-7 for the meaning of these symbols.

Additional details for each peer can be determined by the following procedure. First, use the associations command to display an index of association identifiers, as shown in the following example:

NTPQ> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 50252 f314 yes yes ok outlyer reachable 1 2 50253 f414 yes yes ok candidat reachable 1 3 50254 f414 yes yes ok candidat reachable 1 4 50255 f614 yes yes ok sys.peer reachable 1

Each line in this display is associated with the corresponding line in the preceding peer display. The assID column shows the unique identifier for each mobilized association, and the status column shows the peer status word (in hexadecimal), as defined in the NTP specification.

Next, use the readvar command and the respective assID identifier to display a detailed synopsis for the selected peer, as shown in the following example:

NTPQ> readvar 50253 status=f414 reach, conf, auth, sel_candidat, 1 event, event_reach, srcadr=saicpc-isiepc2.cairn.net, srcport=123, dstadr=140.173.1.46, dstport=123, keyid=3816249004, stratum=2, precision=-27, rootdelay=10.925, rootdispersion=12.848, refid=pogo.udel.edu, reftime=bd11b225.133e1437 Sat, Jul 8 2000 13:59:01.075, delay=10.550, offset=-1.357, jitter=0.074, dispersion=1.444, reach=377, valid=7, hmode=1, pmode=1, hpoll=6, ppoll=7, leap=00, flash=00 ok, org=bd11b23c.01385836 Sat, Jul 8 2000 13:59:24.004, rec=bd11b23c.02dc8fb8 Sat, Jul 8 2000 13:59:24.011, xmt=bd11b21a.ac34c1a8 Sat, Jul 8 2000 13:58:50.672, filtdelay= 10.45 10.50 10.63 10.40 10.48 10.43 10.49 11.26, filtoffset= -1.18 -1.26 -1.26 -1.35 -1.35 -1.42 -1.54 -1.81, filtdisp= 0.51 1.47 2.46 3.45 4.40 5.34 6.33 7.28,

This example was chosen to illustrate one of the most complex configurations involving symmetric modes. As the result of debugging experience, the names and values of these variables might change from time to time. The fields in this display include most variables defined in the NTP Version 3 specification, as well as those defined for NTP Version 4.

A useful indicator of miscellaneous problems is the flash value, which reveals the state of the various sanity tests on incoming packets. There are currently eleven bits, one for each test, numbered from right to left. If the test fails, the corresponding bits are set to 1 and 0. If any bit is set following each processing step, the packet is discarded.

The three lines identified as filtdelay , filtoffset , and filtdisp reveal the round-trip delay, clock offset and dispersion for each of the last eight measurement rounds (all in milliseconds). Note that the dispersion, which is an estimate of the error, increases as the age of the sample increases. From these data, it is usually possible to determine the incidence of severe packet loss, network congestion, and unstable local clock oscillators. Every case is unique; however, if one or more of the rounds show large values or change radically from one round to another, the network is probably congested or experiencing loss.

Once the server has set the local clock, it continuously tracks the discrepancy between local time and NTP time and adjusts the local clock accordingly. This adjustment consists of two components: time and frequency. Adjustments to time and frequency are determined automatically by the clock discipline algorithm, which functions as a hybrid phase/frequency feedback loop. The behavior of this algorithm is controlled carefully to minimize residual errors resulting from normal network jitter and frequency variations of the local clock hardware oscillator. However, when started for the first time, the algorithm may take some time to converge on the intrinsic frequency error of the host machine.

The state of the local clock itself can be determined using the readvar statement (without the argument), as shown in the following example:

NTPQ> readvar status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version="ntpd 4.0.99j4-r Fri Jul 7 23:38:17 GMT 2002 (1)", processor="i386", system="FreeBSD3.4-RELEASE", leap=00, stratum=2, precision=-27, rootdelay=0.552, rootdispersion=12.532, peer=50255, refid=pogo.udel.edu, reftime=bd11b220.ac89f40a Sat, Jul 8 2002 13:58:56.673, poll=6, clock=bd11b225.ee201472 Sat, Jul 8 2002 13:59:01.930, state=4, phase=0.179, frequency=44.298, jitter=0.022, stability=0.001, hostname="barnstable.udel.edu", publickey=3171372095, params=3171372095, refresh=3172016539

An explanation of most of these variables is in the RFC 1305 specification. The most useful variables are clock , which shows when the clock was last adjusted, and reftime , which shows when the server clock of refid was last adjusted. The mean millisecond time offset ( phase ) and deviation ( jitter ) monitor the clock quality, and the mean Ppm frequency offset ( frequency ) and deviation ( stability ) monitor the clock stability and serve as useful diagnostic tools. NTP operators have found that these data represent useful environment and hardware alarms. If the motherboard fan or some hardware bit malfunctions, the system clock is usually the first to reflect these problems.