From: Harlan Stenn Date: Sat, 13 May 2000 17:06:26 +0000 (-0000) Subject: ChangeLog, authopt.htm, genkeys.htm, ntp_intres.c: X-Git-Tag: NTP_4_0_99_J~14 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a81fb7f5338cbf50952bf23656af3cbe7cb690f2;p=thirdparty%2Fntp.git ChangeLog, authopt.htm, genkeys.htm, ntp_intres.c: * ntpd/ntp_intres.c (ntp_intres): Quiet some debug messages Reported by: Brian Bergstrand Resync documentation. bk: 391d8b92At76t0mbaSseJkN6sCemdg --- diff --git a/ChangeLog b/ChangeLog index 044a610ad..20ab0c57c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2000-05-12 Harlan Stenn + + * ntpd/ntp_intres.c (ntp_intres): Quiet some debug messages + Reported by: Brian Bergstrand + 2000-05-11 Harlan Stenn * scripts/mkver.in (ConfStr): Use -r if we're using RSAREF, diff --git a/html/authopt.htm b/html/authopt.htm index 926bb1aa0..36f896a9f 100644 --- a/html/authopt.htm +++ b/html/authopt.htm @@ -4,124 +4,133 @@ Authentication Options Authentication Options
-

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 that server. 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) mode, -commonly called DES-CBC. Subsequently, this was augmented by the RSA -Message Digest 5 (MD5) 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 schemes and, in addition, provides a new -autokey scheme based on reverse hashing and public key -cryptography. Authentication can be configured separately for each -association using the key or autokey subcommands on -the peer, server, broadcast and -manycastclient commands as described in the Configuration Options page. - -

The authentication options specify the suite of keys, select the key -for each configured association and manage the configuration operations, -as described below. The auth flag which controls these -functions can be set or reset by the enable and -disable configuration commands and also by remote configuration -commands sent by a ntpdc program running in another machine. If -this flag is set, persistent peer associations and remote configuration -commands are effective only if cryptographically authenticated. If this -flag is disabled, these operations are effective even if not -cryptographic authenticated. It should be understood that operating in -the latter mode invites a significant vulnerability where a rogue hacker -can seriously disrupt client timekeeping. - -

The auth flag affects all authentication procedures -described below; however, it operates differently if cryptographic -support (AUTOKEY) is compiled in the distribution, which is -normally the case. If this support is available and the flag is enabled, -then persistent associations are mobilized in multicast client and -symmetric passive modes and remote configuration commands are effective -only if successfully authenticated. If the support is unavailable and -the flag is enabled, then it is not possible under any conditions to -mobilize persistent associations or respond to remote configuration -commands. The auth flag normally defaults to set if -cryptographic support is available and to reset otherwise. - -

With the above vulnerabilities in mind, it is desirable to set the -auth flag in all cases. One aspect which is often confusing is -the name resolution process which maps server names in the configuration -file to IP addresses. In order to protect against bogus name server -messages, this process is authenticated using an internally generated -key which is normally invisible to the user. However, if cryptographic -support is unavailable and the auth flag is enabled, the name -resolution process will fail. This can be avoided either by specifying -IP addresses instead of host names, which is generally inadvisable, or -by leaving the flag disabled and enabling it once the name resolution +

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 that server. 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) algorithm operating in Cipher Block +Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was +augmented 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 schemes, 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 a private value which is generated by each server +and never revealed. With autokey all key distribution and management +functions involve only public values, which considerably simplifies key +distribution and storage. + +

Authentication is configured separately for each association using +the key or autokey subcommands on the peer, +server, broadcast and manycastclient commands +as described in the Configuration Options page. +The authentication options described below specify the suite of keys, +select the key for each configured association and manage the +configuration operations. + +

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 +configuration commands and also by remote configuration commands sent by +a ntpdc program running in another machine. If this flag is +enabled, new broadcast client and symmetric passive associations and +remote configuration commands must be cryptographically authenticated +using either symmetric-key or public-key schemes. If this flag is +disabled, these operations are effective even if not cryptographic +authenticated. It should be understood that operating in the latter mode +invites a significant vulnerability where a rogue hacker can seriously +disrupt client timekeeping. + +

In networks with firewalls and large numbers of broadcast clients it +may be acceptable to disable authentication, since that avoids key +distribution and simplifies network maintenance. However, when the +configuration file contains host names, or when a server or client is +configured remotely, host names are resolved using the DNS and a +separate name resolution process. In order to protect against bogus name +server messages, name resolution messages are authenticated using an +internally generated key which is normally invisible to the user. +However, if cryptographic support is disabled, the name resolution +process will fail. This can be avoided either by specifying IP addresses +instead of host names, which is generally inadvisable, or by enabling +the flag for name resolution and disabled it once the name resolution process is complete. -

Private Key Scheme

+

In addition to the default symmetric-key cryptographic support, +support for public-key cryptography is available if the requisite +rsaref20 software distribution has been installed before +building the distribution. Public-key cryptography provides secure +authentication of servers without compromising accuracy and stability. +The security model and protocol schemes for both symmetric-key and +public-key cryptography are described below. + +

Symmetric-Key Scheme

The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by 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 +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 +associations, additional keys can be used as passwords for the ntpq and ntpdc utility programs. -

When ntpd is first started, it reads the key file and +

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, +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 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. +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. -

Autokey Schemes

+

Public-Key Scheme

The original NTPv3 authentication scheme described in RFC-1305 continues to be supported; however, in NTPv4 an additional authentication scheme -called autokey is available. It uses MD5 message digest, RSA -public-key signature and Diffie-Hellman key agreement algorithms -available from several sources, but not included in the NTPv4 software -distribution. In order to be effective, the rsaref20 package -must be installed as described in the README.rsa file. Once -installed, the configure and build process automatically detects it and +called autokey is available. It uses MD5 message digest, RSA public-key +signature and Diffie-Hellman key agreement algorithms available from +several sources, but not included in the NTPv4 software distribution. In +order to be effective, the rsaref20 package must be installed +as described in the README.rsa file. Once installed, the +configure and build process automatically detects it and compiles the routines required. -The scheme has several modes of operation corresponding to the various -NTP modes supported. RSA signatures and timestamps are used in all modes -to verify the source of cryptographic values. All modes use a special -cookie which can be computed independently by the client and server. In -symmetric modes the cookie is constructed using the Diffie-Hellman key -agreement algorithm. In other modes the cookie is constructed from the -IP addresses and a private value known only to the server. Multicast and -symmetric modes use in addition a variant of the S-KEY scheme, in which -a pseudo-random key list is generated and used in reverse order. These -schemes are described along with an executive summary, current status, -briefing slides and reading list, on the Autonomous Authentication page. -

The cryptographic values used by the autokey scheme are -incorporated as a set of files generated by the The cryptographic values used by the autokey scheme are incorporated +as a set of files generated by the ntp_genkeys program, including the DES/MD5 private keys, RSA public/private key pair, and the Diffie-Hellman parameters. See the ntp_genkeys page for a description of the -format and use of these files. They contain cryptographic values -generated by the algorithms of the rsaref20 package and are in -printable ASCII format. Since the algorithms are seeded by the system -clock, each run of this program will produce a different outcome. +formats of these files. They contain cryptographic values generated by +the algorithms of the rsaref20 package and are in printable +ASCII format. All file names include the timestamp, in NTP seconds, +following the default names given below. Since the file data are derived +from random values seeded by the system clock and the file name includes +the timestamp, every generation produces a different file.

The ntp.keys file contains the private DES/MD5 keys. It must be distributed by secure means to other servers and clients sharing the @@ -140,44 +149,41 @@ where host is the name of the host. Each configured server or peer association requires the public key file associated with the particular server or peer to be installed at a default location or as specified by the commands below. In addition, -public key files are required for associations that might be mobilized -by multicast or symmetric servers. These files can be widely distributed -and stored using insecure means, since the data are public values. +public key files are required for all configured associations, including +those that might be mobilized by multicast servers or symmetric peers. +These files can be widely distributed and stored using insecure means, +since the data are public values.

Due to the widespread use of interface-specific naming, the host names used in configured and mobilized associations are determined by -different rules. The ntp_genkeys program uses the name returned -by the Unix gethostname() library routine and this is the name -normally used when installing the file on some other host. However, the -default name used when configuring an association at run time is the -canonical name returned by the DNS resolver, and this might not be the -same name. The preferred workaround on the host installing the file is -to use the Unix nslookup command to determined the canonical -name and install a link from that name to the actual name. -Alternatively, the default can be overriden with by the -publickey subcommand of the server or peer -configuration command. - -

For other than configured associations that might be mobilized by -multicast servers or symmetric peers, the name is determined directly -from the server or peer as part of the protocol dance that authenticates -the source. The server or peer uses the same gethostname() -library routine as the ntp_genkeys program, so there is no -confusion. +the Unix gethostname() library routine. Both the +ntp_genkeys program and the run-time protocol derive the name +of the public key file using the name returned by this routine. While it +is usually necessary to configure the private key file name and +timestamp, the server and peer public file names are normally obtained +directly from the server or peer. + +

Key Management

All key files are installed by default in /usr/local/etc, which is normally in a shared filesystem in NFS-mounted networks and avoids installing them in each machine separately. The default can be -overriden by the keysdir configuration file command. However, -this is not a good place to install the private key file, since each -machine needs its own file. A suitable place to install it is -/etc, which is normally not in a shared filesystem. The default -can be overriden by the subcommand of the crypto -configuration command. +overridden by the keysdir configuration command. However, this +is not a good place to install the private key file, since each machine +needs its own file. A suitable place to install it is /etc, +which is normally not in a shared filesystem. The location can be +overridden by the crypto configuration command. + +

All cryptographic keys and parameters should be regenerated on a +periodic basis, like once per month. The ntp_genkeys program uses the same timestamp extension for all files generated at one time, so each generation is distinct and can be readily recognized. However, by default the file names expected by ntpd are without the timestamp extension. A simple approach to key maintenance is to distribute newly generated public files without the extension and install them in each server and client while in normal operation. This avoids the need to edit the NTP configuration file for each new generation. + +

A server and its clients load a new key generation in the following way. The server and its clients have loaded the old generation at startup and are operating normally. The new generation is installed at the server and its clients while the old generation is running. The server then restarts ntpd and loads the new generation, with result the clients no longer can authenticate. After a few minutes the clients time out and restart the protocol from the beginning, with result the new generation is loaded and operation continues normally. -

Authentication Commands

+

Key distribution can be done semi-automatically using a set of shell scripts and the Unix rdist utility. Each server runs the ntp_genkeys program from a cron job, and uploads the relevant public files to a common location accessible to the rdist utility. At that location a script selects one of the Diffie-Hellman files and bundles it along with the latest generation of public-key files for rdist, which downloads them to all servers and clients. -

+

Authentication Commands

+ +
autokey [logsec]
Specifies the interval between regenerations of the session key list @@ -187,58 +193,58 @@ 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 program, +
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 key +useful to diagnose and repair problems that affect ntpd +operation. The key argument to this command is a key identifier for a trusted key, where the value can be in the range 1 to -65534, inclusive.
+65534, inclusive. -
crypto [privatekey file] [publickey file] [dhparms -file]
-
This command requires the NTP daemon build process be configured +
crypto [privatekey file] [publickey file] [dhparms +file]
+
This command requires the NTP daemon build process be configured with the RSA library. The presence of this command causes the daemon to load the host RSA private key file, public key file and Diffie-Hellman parameter file. If one or more files are left unspecified, the default -names are used as described above. Following are the subcommands:
+names are used as described above. Following are the subcommands:
privatekey file
Specifies the directory for the RSA private key file, which -otherwise defaults to /usr/local/etc.
+otherwise defaults to /usr/local/etc.
publickey file
Specifies the directory for the RSA public key file, which otherwise -defaults to /usr/local/etc.
+defaults to /usr/local/etc.
dhparms file
Specifies the directory for the Diffie-Hellman parameters file, -which otherwise defaults to /usr/local/etc.
+which otherwise defaults to /usr/local/etc.
-
keys keyfile
-
Specifies the file name containing the private encryption keys and -key identifiers used by ntpd, ntpq and ntpdc -when operating in authenticated mode.
+
keys keyfile
+
Specifies the file name containing the private encryption keys and +key identifiers used by ntpd, ntpq and ntpdc +when operating in authenticated mode.
-
keysdir path
-
This command requires the NTP daemon build process be configured +
keysdir path
+
This command requires the NTP daemon build process be configured with the RSA library. It specifies the default directory path for the private key file, parameters file and one or more public key files. The default when this command does not appear in the configuration file is /usr/local/etc/.
-
requestkey key
-
Specifies the key identifier to use with the ntpdc utility +
requestkey key
+
Specifies the key identifier to use with the ntpdc utility 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 key identifier for a +implementation of ntpd. This program is useful to diagnose and +repair problems that affect ntpd operation. The +key argument to this command is a key identifier for a trusted key, where the value can be in the range 1 to 65534, inclusive. -
+
revoke [logsec]
Specifies the interval between re-randomization of certain @@ -249,19 +255,20 @@ 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 encryption key identifiers which are trusted for the +
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 +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.
+key arguments are 32-bit unsigned integers with values +from 1 to 65,534. -
+

Files

+ ntp.keys private MD5 keys
ntpkey RSA private key
ntpkey_host RSA public key diff --git a/html/genkeys.htm b/html/genkeys.htm index f155115a3..baa4ba221 100644 --- a/html/genkeys.htm +++ b/html/genkeys.htm @@ -10,19 +10,20 @@

Description

-

The cryptographic values used by the autokey scheme are -incorporated as a set of four files generated by the -ntp_genkeys program, including ntp.keys containing the -DES/MD5 private keys, ntpkey containing the RSA private key, +

The cryptographic values used by the autokey scheme are incorporated +as a set of four files generated by the ntp_genkeys program, +including ntp.keys containing the DES/MD5 private keys, +ntpkey containing the RSA private key, ntpkey_host containing the RSA public key, where host is the DNS name of the generating machine, and ntpkey_dh containing the parameters for the Diffie-Hellman key- agreement algorithm. The files contain cryptographic values generated by the algorithms of the rsaref20 package and are in printable -ASCII format. Since the algorythms are seeded by the system clock, each -run of this program will produce a different outcome. There are no -options or frills of any sort, although a number of options would seem -to be appropriate. +ASCII format. A timestamp in NTP seconds is appended to each file name +shown here. Since the algorithms are seeded by the system clock, each +run of this program produces a different file and file name. There are +no options or frills of any sort, although a number of options would +seem to be appropriate.

The ntp.keys file contains 16 MD5 keys. Each key consists of 16 characters randomized over the ASCII 95-character printing subset. @@ -128,7 +129,6 @@ Unix passwords. 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 diff --git a/ntpd/ntp_intres.c b/ntpd/ntp_intres.c index e2e8c4abc..e0bf0857c 100644 --- a/ntpd/ntp_intres.c +++ b/ntpd/ntp_intres.c @@ -270,7 +270,8 @@ ntp_intres(void) resolve_value <<= 1; resolve_timer = resolve_value; #ifdef DEBUG - msyslog(LOG_INFO, "resolve_timer: 0->%d", resolve_timer); + if (debug > 2) + msyslog(LOG_INFO, "resolve_timer: 0->%d", resolve_timer); #endif config_timer = CONFIG_TIME; doconfigure(1); @@ -278,7 +279,8 @@ ntp_intres(void) } else if (config_timer == 0) { config_timer = CONFIG_TIME; #ifdef DEBUG - msyslog(LOG_INFO, "config_timer: 0->%d", config_timer); + if (debug > 2) + msyslog(LOG_INFO, "config_timer: 0->%d", config_timer); #endif doconfigure(0); continue;