Software: Apache/2.2.3 (CentOS). PHP/5.1.6 

uname -a: Linux mx-ll-110-164-51-230.static.3bb.co.th 2.6.18-194.el5PAE #1 SMP Fri Apr 2 15:37:44
EDT 2010 i686 

uid=48(apache) gid=48(apache) groups=48(apache) 

Safe-mode: OFF (not secure)

/usr/share/doc/ntp-4.2.2p1/   drwxr-xr-x
Free 51 GB of 127.8 GB (39.9%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     groups.html (9.39 KB)      -rw-r--r--

Trusted Hosts and Groups

Alice holds the key.

Last update: 00:12 UTC Tuesday, November 08, 2005

Related Links

Table of Contents

• Identity Schemes
• Example
• Command Line Options
• Random Seed File
• Cryptographic Data Files
• Bugs

Trusted Hosts and Groups

Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as explained in the Authentication Options page. 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 Automatic NTP Configuration Options page.

On each trusted host as root, change to the keys directory. To insure a fresh fileset, remove all 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 the NTP daemons 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. The most often need to do this is 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, ntpd should be restarted. When ntpd is restarted, it loads any new files and restarts the protocol. Other dependent hosts will continue as usual until signatures are refreshed, at which time the protocol is restarted.

Identity Schemes

As mentioned on the Autonomous Authentication page, 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 described on the Identification Schemes page. 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 sugroup 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 ntpkey_RSAkey_alice.filestamp and trusted private certificate file ntpkey_RSA-MD5_cert_alice.filestamp. Copy both files to all group hosts; they replace the files which would be generated in other schemes. On each host bob install a soft link from the generic name ntpkey_host_bob to the host key file and soft link 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 ntp-keygen -T -I -p password to produce her parameter file 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 soft link from the generic ntpkey_iff_alice to this file. If there are no hosts restricted to operate only as clients, there is nothing further to do. As 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 soft link from the generic ntpkey_iff_alice to this 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 ntpkey_GQpar_alice.filestamp, which includes both server and client keys. Copy this file to all group hosts and install a soft link from the generic ntpkey_gq_alice to this file. In addition, on each host bob install a soft link from generic 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 ntpkeys_MVpar_trish.filestamp and client key files ntpkeys_MVkeyd_trish.filestamp where d is the key number (0 < d < n). Copy the parameter file to alice and install a soft link from the generic ntpkey_mv_alice to this file. Copy one of the client key files to alice for later distribution to her clients. It doesn't matter which client key file goes to alice, since they all work the same way. Alice copies the client key file to all of her cliens. On client bob install a soft link from generic ntpkey_mvkey_bob to the client key file. As the MV scheme is independent of keys and certificates, these files can be refreshed as needed.