From: Harlan Stenn Date: Sun, 19 Dec 2010 05:00:18 +0000 (-0500) Subject: Documentation updates from Dave Mills X-Git-Tag: NTP_4_2_7P97~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c96d1fc22733ddf885e2c693365bb2786b0494d7;p=thirdparty%2Fntp.git Documentation updates from Dave Mills bk: 4d0d9162x0Axs9Imboq-p25ZUAqHAw --- diff --git a/ChangeLog b/ChangeLog index 777502dc8..653aec2e1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,6 +1,7 @@ * [Bug 1760] from 4.2.6p3-RC12: ntpd Windows interpolation cannot be disabled. * from 4.2.6p3-RC12: Upgrade to libopts 34.0.9 from AutoGen 5.11.6pre5. +* Documentation updates from Dave Mills. (4.2.7p96) 2010/12/18 Released by Harlan Stenn * [Bug 1758] from 4.2.6p3-RC12: setsockopt IPV6_MULTICAST_IF with wrong ifindex. diff --git a/html/autokey.html b/html/autokey.html index 51cf90eb5..b1996c538 100644 --- a/html/autokey.html +++ b/html/autokey.html @@ -14,7 +14,7 @@

Autokey Public-Key Authentication

Last update: - 18-Dec-2010 4:29 + 19-Dec-2010 4:26 UTC

@@ -37,29 +37,36 @@

There are two timeouts associated with the Autokey scheme. The key list timeout is set by the automax command, which specifies the interval between generating new key lists by the client. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The revoke timeout is set by the revoke command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.

Autokey Subnets

An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or an NTP secure group as described in the next section. Autokey hosts operate as servers, clients or both at the same time.

A certificate trail is a sequence of certificates, each signed by a host nearer the THs and terminating at the self-signed certificate of a TH. As the Autokey protocol proceeds, each client provides its self-signed certificate to a server nearer the THs for signature. In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.

A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. In general, NTP servers operate as certificate authorities (CAs) to sign certificates provided by its clients. The CAs include the THs and those group servers with dependent clients. In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.

The requirement that the NTP subnet be acyclic means that, if peers are configured with each other in symmetric modes, each must be a TH.

The Autokey protocol runs for each association separately. During the protocol the client recursively obtains all the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it.

The certificates derived from each association are combined in the cache with duplicates suppressed. If it happens that two different associations contribute certificates to the cache, a certificate on the trail from one association could expire before any on another trail. In this case the remaining trails will survive until the expired certificate is replaced. Once saved in the cache, a certificate remains valid until it expires or is replaced by a new one.

It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains valid until it is demobilized, even if certificates on the trail to the THs expire.

Example

Figure 1. Example Configuration

Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server; so, for example, TH X has two mobilized associations, one to Alice host C and the other to Carol host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.

Note that host D cetificate trail is D→C→A or D→C→B, depending on the particular order the trails are built. Host Y certificate trail is only Y→X, since X is a TH. Host X has two cetficate trails X→C→A or X→C→B, and X→S→R.

NTP Secure Groups

NTP security groups are an extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the Autokey Identity Schemes page. NTP secure groups are used to define cryptographic compartments and security -hierarchies. The identity scheme insures that the server is authentic and not masqueraded by an intruder acting as a middleman.

As in NTP subnet, NTP secure groups are configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH. In addition, each group host verifies the server has the secret group key using an identity exchange.

+hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.

As in NTP subnet, NTP secure groups are configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. In addition, each group host verifies its server has the secret group key using an identity exchange.

For secure group servers, the string specified by the -i option of the ntp-keygen program is the name of the secure group. For secure group servers this name must match the ident option - of the crypto command. For secure group clients, this name must match the ident option of the server command. This name is also used in the identity keys and parameters file names. The file naming conventions are described on + of the crypto command for the server. For secure group clients, this name must match the ident option of the server command. This name is also used in the identity keys and parameters file names. The file naming conventions are described on the ntp-keygen page.

In the latest Autokey version, the host name and group name are independent of each other and the host option of the crypto command is deprecated. When compatibility with older versions is required, specify the same name for both the -s and -i options.

The Autokey identity schemes involve a challenge-response exchange where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash. Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secure group key to persist long after the longest period of certificate validity. In the Schnorr IFF scheme considered later on this page, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.

As described on the Autokey Identity Schemes page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted keys file and a nonencrypted parameters file, which usually contains a subset of the keys file. In general, NTP servers operating as certificate authorities (CAs) use the keys file and clients use the parameters file. The CAs include the THs and those group servers with dependent clients.

Hosts with no dependent clients can retrieve client parameter files from an - archive or web page. The ntp-keygen program can export these data using the -e option. + archive or web page. The ntp-keygen program can export parameter files using the -e option. Hosts with dependent clients other than the CA must retrieve copies of the server - key files using secure means. The ntp-keygen program can export these data + key file using secure means. The ntp-keygen program can export these data using the -q option and chosen remote password. In either case the data are installed as a file and then renamed using the name given as the first line in the file, but without the filestamp.

Example

Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefor, both C and S are configured as Autokey servers with, for example, the IFF identity scheme, and X as a client of both of them. For this purpose, both C and S export their IFF parameter files to X as described above.

Configuration - Authentication Schemes

Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. time.nist.gov, as root:

# cd /usr/local/etc @@ -80,11 +87,6 @@ the filestamp.

# driftfile /etc/ntp.drift

It is possible to configure clients of server grundoon.udel.edu in the same way with the server line pointing to grundoon.udel.edu. Dependent clients authenticate to time.nistg.gov through grundoon.udel.edu.

In the above configuration examples, the default Autokey host name is the string returned by the Unix gethostname() library routine. However, this name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys files. The Autokey host name can be changed using the -s option of the ntp-keygen program. The default password can be changed using the -p option of the ntp-keygen program and the pw option of the crypto command.

Example

Figure 1. Example Configuration

Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. For the moment, assume that all associations are client/server; so, for example, TH X has two mobilized associations, one to Alice host C, the other to Carol host S. While not shown in the figure, Alice hosts A and B could configure symmetric active mode between them for redundancy and backup.

Configuration - Identity Schemes

For the simplest identity scheme TC, the server generates host keys, trusted certificate and identity files using an ntp-keygen program commadn with options specified in this section, while the clients use the same command with no options. The server uses the crypto command in the comnfiguration file with options specified in this section, while the clients use the same command with no options. Additonia client options are specified in the server command for each association.

It's best to start with a functioning TC configuation and add commands as necessary. For example, the CA generates an encrypted server keys file using the command

@@ -98,20 +100,6 @@ the filestamp.

In special circumstances the Autokey message digest algorithm can be changed using the digest option of the crypto command. The digest algorithm is separate and distinct from the symmetric key message digest algorithm. If compliance with FIPS 140-2 is required, the algorithm must be ether SHA or SHA1. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.

Example

Returnign to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, Carols' TH X is vulnerale to masquerade on the links between X and C and S. Therefor, X runs an identity scheme with C and S For example, C uses the command

ntp-keygen -I -i YELLOW -e>ntpkey_iffpar_C

and includes the command

crypto ident YELLOW

in its configuraiton file. S runs a similar configuration

ntp-keygen -G -i ORANGE -e >orange

crypto ident ORANGE

in her configuration file. X needs only

ntp-keygen

to generate RSA keys and cetificate, but moblizes assoctions

server C autokey ident YELLOW

server S autiokey ident ORANGE

X needs in install files yellow and orange under the names biven as the files like in the ifle, but without the filestamp.

Examples

Consider a scenario involving three secure groups RED, GREEN and BLUE. RED and BLUE are typical of national laboratories providing certified time to the Internet at large. As shown ion the figure, RED TH mort and BLUE TH macabre run NTP symmetric mode with each other for monitoring or backup. For the purpose of illustration, assume both THs are primary servers. GREEN is typical of a large university providing certified time to the campus community. GREEN TH howland is a broadcast client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys. YELLOW is a client of GREEN and for purposes of illustration a TH for YELLOW.

Autokey Public-Key Authentication

Table of Contents

Autokey Subnets

NTP Secure Groups

Configuration - Authentication Schemes

Configuration - Identity Schemes

Examples