<h3>Authentication Options</h3>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:37</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">03:35</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="286">Friday, September 23, 2005</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
<li class="inline"><a href="#auth">Authentication Support</a>
<li class="inline"><a href="#symm">Symmetric Key Cryptography</a>
<li class="inline"><a href="#pub">Public Key Cryptography</a>
- <li class="inline"><a href="#auto">Autokey Dances</a>
+ <li class="inline"><a href="#cfg">Configuration</a>
<li class="inline"><a href="#inter">Operation</a>
<li class="inline"><a href="#key">Key Management</a>
<li class="inline"><a href="#cmd">Authentication Commands</a>
<hr>
<h4 id="auth">Authentication Support</h4>
<p>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 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.</p>
- <p>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 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. 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.</p>
+ <p>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 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. 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.</p>
<p>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. Directions for doing that are on the <a href="build/build.html">Building and Installing the Distribution</a> page.</p>
<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> subcommand on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> configuration commands as described in the <a href="confopt.html">Configuration Options</a> page. The authentication options described below specify the locations of the key files, if other than default, which symmetric keys are trusted and the interval between various operations, if other than default.</p>
<p>Authentication is always enabled, although ineffective if not configured as described below. If a NTP packet arrives including a message authentication code (MAC), it is accepted only if it passes all cryptographic checks. The checks require correct key ID, key value and message digest. If the packet has been modified in any way or replayed by an intruder, it will fail one or more of these checks and be discarded. Furthermore, the Autokey scheme requires a preliminary protocol exchange to obtain the server certificate, verify its credentials and initialize the protocol</p>
- <p>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running on another machine. If this flag is enabled, which is the default case, 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 <tt>auth</tt> flag disabled invites a significant vulnerability where a rogue hacker can masquerade as a falseticker 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.</p>
+ <p>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running on another machine. If this flag is enabled, which is the default case, 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 <tt>auth</tt> flag disabled invites a significant vulnerability where a rogue hacker can masquerade as a truechimer 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.</p>
<p>An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers as described in the <a href="manyopt.html">Automatic NTP Configuration Options</a> page. Either symmetric key or public key cryptographic authentication can be used in this mode. The principle advantage of manycast mode is that potential servers need not be configured in advance, since the client finds them during regular operation, and the configuration files for all clients can be identical.</p>
<p>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 <a href="http://www.ntp.org">www.ntp.org</a>.</p>
<h4 id="symm">Symmetric Key Cryptography</h4>
<p>It is important to note that Autokey does not use DNS to resolve addresses, since DNS can't be completely trusted until the name servers have synchronized clocks. The cryptographic name used by Autokey to bind the host identity credentials and cryptographic values must be independent of interface, network and any other naming convention. The name appears in the host certificate in either or both the subject and issuer fields, so protection against DNS compromise is essential.</p>
<p>By convention, the name of an Autokey host is the name returned by the Unix <tt>gethostname()</tt> system call or equivalent in other systems. By the system design model, there are no provisions to allow alternate names or aliases. However, this is not to say that DNS aliases, different names for each interface, etc., are constrained in any way.</p>
<p>It is also important to note that Autokey verifies authenticity using the host name, network address and public keys, all of which are bound together by the protocol specifically to deflect masquerade attacks. For this reason Autokey includes the source and destinatino IP addresses in message digest computations and so the same addresses must be available 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.</p>
+ <h4 id="cfg">Configuration</h4>
+ <p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. The simplest configuration consists of a subnet with one or more servers at the same low stratum acting as trusted hosts and with dependent clients at higher strata and sharing a single secure group and identity scheme. Each trusted host generates a host key, trusted certificate and group key. Each client generates a host key, normal certificate and installs the group key of each trusted host using secure means and renames it as the name of the trusted host.</p>
+ <p>For example, trusted host Alice generates keys using</p>
+ <p><tt>ntp-keygen -H -T -I -p xyz</tt></p>
+ <p>where H specifies a new host key, T the trusted certificate, I the IFF identity scheme and p the password used to encrypt the private key files. The group key file is <tt>ntpkey_IFFpar_alice.<i>filestamp</i></tt><i>, </i>where <i>filestamp </i>represents the NTP time in seconds when the file was generated.</p>
+ <p>Host Bob generate keys using</p>
+ <p><tt>ntp-keygen -H -p abc</tt></p>
+ <p>where <tt>abc</tt> is different for each group host. The trusted host generates a password-protected group key using</p>
+ <p><tt>ntp-keygen -q xyz -p abc -e ><i>temp</i></tt></p>
+ <p>where <tt>xyz</tt> is the trusted host password, <tt>abc</tt> is the password supplied by the client and <i><tt>temp</tt></i> is a temporary file. This file is transmitted to Bob using secure means and renamed to the fully qualified host name for Alice preceded by the string <tt>ntpkey_iff_</tt>.</p>
<h4>Operation</h4>
<p>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.</p>
<p>The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when a message of appropriate cryptotype arrives. When mobilized by a <tt>server</tt> or <tt>peer</tt> configuration command and no <tt>key</tt> or <tt>autokey</tt> subcommands are present, the association is not authenticated; if the <tt>key</tt> subcommand is present, the association is authenticated using the symmetric key ID specified; if the <tt>autokey</tt> subcommand is present, the association is authenticated using Autokey.</p>
- <p>When multiple identity schemes are supported in the Autokey protocol, the first message exchange determines which one is used. The client request message contains bits corresponding to which schemes it has available. The server response message contains bits corresponding to which schemes it has available. Both server and client match the received bits with their own and select a common scheme.</p>
- <p>Following the principle that time is a public value, a server responds to any client packet that matches its cryptotype capabilities. Thus, a server receiving an unauthenticated packet will respond with an unauthenticated packet, while the same server receiving a packet of a cryptotype it supports will respond with packets of that cryptotype. However, unconfigured broadcast or manycast client associations or symmetric passive associations will not be mobilized unless the server supports a cryptotype compatible with the first packet received. By default, unauthenticated associations will not be mobilized unless overridden in a decidedly dangerous way.</p>
- <p>Some examples may help to reduce confusion. Client Alice has no specific cryptotype selected. Server Bob has both a symmetric key file and minimal Autokey files. Alice's unauthenticated messages arrive at Bob, who replies with unauthenticated messages. Cathy has a copy of Bob's symmetric key file and has selected key ID 4 in messages to Bob. Bob verifies the message with his key ID 4. If it's the same key and the message is verified, Bob sends Cathy a reply authenticated with that key. If verification fails, Bob sends Cathy a thing called a crypto-NAK, which tells her something broke. She can see the evidence using the <tt>ntpq</tt> program.</p>
- <p>Denise has rolled her own host key and certificate. She also uses one of the identity schemes as Bob. She sends the first Autokey message to Bob and they both dance the protocol authentication and identity steps. If all comes out okay, Denise and Bob continue as described above.</p>
- <p>It should be clear from the above that Bob can support all the girls at the same time, as long as he has compatible authentication and identity credentials. Now, Bob can act just like the girls in his own choice of servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful). But, wise security policy might preclude some cryptotype combinations; for instance, running an identity scheme with one server and no authentication with another might not be wise.</p>
<h4 id="key">Key Management</h4>
<p>The cryptographic values used by the Autokey protocol are incorporated as a set of files generated by the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program, including symmetric key, host key and public certificate files, as well as sign key, identity parameters and leapseconds files. Alternatively, host and sign keys and certificate files can be generated by the OpenSSL utilities and certificates can be imported from public certificate authorities. Note that symmetric keys are necessary for the <tt>ntpq</tt> and <tt>ntpdc</tt> utility programs. The remaining files are necessary only for the Autokey protocol.</p>
<p>Certificates imported from OpenSSL or public certificate authorities have certian limitations. The certificate should be in ASN.1 syntax, X.509 Version 3 format and encoded in PEM, which is the same format used by OpenSSL. The overall length of the certificate encoded in ASN.1 must not exceed 1024 bytes. The subject distinguished name field (<tt>CN</tt>) is the fully qualified name of the host on which it is used; the remaining subject fields are ignored. The certificate extension fields must not contain either a subject key identifier or a issuer key identifier field; however, an extended key usage field for a trusted host must contain the value <tt>trustRoot</tt>;. Other extension fields are ignored.</p>
<dd>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.
<dt><tt>controlkey <i>key</i></tt>
<dd>Specifies the key identifier to use with the <a href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the standard protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
- <dt><tt>crypto [cert <i>file</i>] [leap <i>file</i>] [randfile <i>file</i>] [host <i>file</i>] [sign <i>file</i>] [gq <i>file</i>] [gqpar <i>file</i>] [iffpar <i>file</i>] [mvpar <i>file</i>] [pw <i>password</i>]</tt>
+ <dt><tt>crypto [cert <i>file</i>] [leap <i>file</i>] [randfile <i>file</i>] [host <i>file</i>] [sign <i>file</i>] [ident <i>scheme</i>] [iffpar <i>file</i>] [gqpar <i>file</i>] [mvpar <i>file</i>] [pw <i>password</i>]</tt>
<dd>This command requires the OpenSSL library. It activates public key cryptography, selects the message digest and signature encryption scheme and loads the required private and public values described above. If one or more files are left unspecified, the default names are used as described above. 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 <tt>keysdir</tt> command or default <tt>/usr/local/etc</tt>. Following are the subcommands:
<dl>
<dt><tt>cert <i>file</i></tt>
<dd>Specifies the location of the required host public certificate file. This overrides the link <tt>ntpkey_cert_<i>hostname</i></tt> in the keys directory.
+ <dt><tt>gq</tt>
+ <dd>Requests the GQ server identity scheme.
<dt><tt>gqpar <i>file</i></tt>
- <dd>Specifies the location of the optional GQ parameters file. This overrides the link <tt>ntpkey_gq_<i>hostname</i></tt> in the keys directory.
+ <dd>Specifies the location of the client GQ parameters file. This overrides the link <tt>ntpkey_gq_<i>hostname</i></tt> in the keys directory.
<dt><tt>host <i>file</i></tt>
<dd>Specifies the location of the required host key file. This overrides the link <tt>ntpkey_key_<i>hostname</i></tt> in the keys directory.
- <dt><tt>iffpar <i>file</i></tt>
+ <dt><tt>ident <i>scheme</i></tt>
+ <dd>Requests the server identity <i>scheme</i>, where <i>scheme</i> can be IFF, GQ or MV. This is used when the host will not be a server for a dependent client.<dt><tt>iffpar <i>file</i></tt>
<dd>Specifies the location of the optional IFF parameters file.This overrides the link <tt>ntpkey_iff_<i>hostname</i></tt> in the keys directory.
<dt><tt>leap <i>file</i></tt>
- <dd>Specifies the location of the optional leapsecond file. This overrides the link <tt>ntpkey_leap</tt> in the keys directory.
+ <dd>Specifies the location of the client leapsecond file. This overrides the link <tt>ntpkey_leap</tt> in the keys directory.
+ <dt><tt>mv</tt>
+ <dd>Requests the MV server identity scheme.
<dt><tt>mvpar <i>file</i></tt>
- <dd>Specifies the location of the optional MV parameters file. This overrides the link <tt>ntpkey_mv_<i>hostname</i></tt> in the keys directory.
+ <dd>Specifies the location of the client MV parameters file. This overrides the link <tt>ntpkey_mv_<i>hostname</i></tt> in the keys directory.
<dt><tt>pw <i>password</i></tt>
<dd>Specifies the password to decrypt files containing private keys and identity parameters. This is required only if these files have been encrypted.
<dt><tt>randfile <i>file</i></tt>
<h3>Server Options</h3>
<img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The chicken is getting configuration advice.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:37</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:29</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="284">Saturday, October 01, 2005</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<dt><tt>iburst</tt>
<dd>When the server is unreachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first two packets can be changed with the <tt>calldelay</tt> command to allow additional time for a modem or ISDN call to complete. This is designed to speed the initial synchronization acquisition with the <tt>server</tt> command and <tt>s</tt> addresses and when <tt>ntpd</tt> is started with the <tt>-q</tt> option.
<dt><tt>key</tt> <i><tt>key</tt></i>
- <dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified <i>key</i> identifier with values from 1 to 65534, inclusive. The default is to include no encryption field.
+ <dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified <i><tt>key</tt></i> identifier with values from 1 to 65534, inclusive. The default is to include no encryption field.
<dt><tt>minpoll <i>minpoll</i></tt><br>
<tt>maxpoll <i>maxpoll</i></tt>
<dd>These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two. The maximum poll interval defaults to 10 (1,024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit of 17 (36.4 h). The minimum poll interval defaults to 6 (64 s), but can be decreased by the <tt>minpoll</tt> option to a lower limit of 4 (16 s).
<h3><tt>ntp-keygen</tt> - generate public and private keys</h3>
<img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Alice holds the key.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:40</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">03:35</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="286">Friday, September 23, 2005</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
<h3>Automatic NTP Configuration Options</h3>
<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">23:21</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="275">Saturday, August 20, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">02:11</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="268">Sunday, October 02, 2005</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
<p>About once an hour or less often if the poll interval exceeds this, the client regenerates the Autokey key list. This is in general transparent in client/server mode. However, about once per day the server private value used to generate cookies is refreshed along with all manycast client associations. In this case all cryptographic values including certificates is refreshed. If a new certificate has been generated since the last refresh epoch, it will automatically revoke all prior certificates that happen to be in the certificate cache. At the same time, the manycast scheme starts all over from the beginning and the expanding ring shrinks to the minimum and increments from there while collecting all servers in scope.</p>
<h4 id="opt">Manycast Options</h4>
<dl>
- <dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxdistance <i>maxdistance</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt>
+ <dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | ghetto <i>ghetto</i> | maxdistance <i>maxdistance</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt>
<dd>This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows:
<dl> <dt><tt>beacon <i>beacon</i></tt>
<dd>The manycast server sends packets at intervals of 64 s if less than <i><tt>maxclock</tt></i> servers are available. Otherwise, it sends packets at the <i><tt>beacon</tt></i> interval in seconds. The default is 3600 s.<dt><tt>ceiling <i>ceiling</i></tt>
<dd>This is a binary flag which enables (0) or disables (1) manycast server replies to manycast clients with the same stratum level. This is useful to reduce implosions where large numbers of clients with the same stratum level are present. The default is to enable these replies.
<dt><tt>floor <i>floor</i></tt>
<dd>Peers with strata below <i>floor</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15.
- <dt><tt>mindist <i>mindistance</i></tt>
+ <dt><tt>orphan <i>stratum</i></tt>
+ <dd>If <tt><i>stratum</i></tt> is set at some value less than 16 a special orphan mode is enterred when no outside source of synchronization is available. To use orphan mode a number of participants are identically configured both as broadcast client and as broadcast server. One or more participants are configured to use an outside source, either a reference clock or another Internet server. When the source or sources fail, the system stratum is set at <tt><i>stratum</i></tt> and a leader is elected to serve as the reference source. When an outside source of synchronization is again available, the orphan mode is disabled.<dt><tt>mindist <i>mindistance</i></tt>
<dd>The slection algorithm normally pads each intersection a minimum of one millisecond to avoid needless classification. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the padding. This command can be used for that purpose. As a general rule, set the mindistance to the maximum expected offset plus the maxiumum expected jitter, in seconds.
<dt><tt>maxdist <i>maxdistance</i></tt>
<dd>The selection algorithm accumulates a number of packets before setting the clock in order to use the best data available. The number is determined by the synchronization distance for each association and a limit called the distance threshold. The synchronization distance starts at 16, then drops by a factor of about two as each packet is received. The default distance threshold is 1.0, which usually results in four packets. Setting maxdistance to some value between 1 and 16 can be used to change the number of packets required. For instance, setting it to 16 will set the clock on the first packet received; howver, setting it to this value essentially disables the mitigation and grooming algorithms.
<h3>Miscellaneous Options</h3>
<img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We have three, now looking for more.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:42</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:08</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="284">Saturday, October 01, 2005</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<dd>This command controls the amount and type of output written to the system <tt>syslog</tt> facility or the alternate <tt>logfile</tt> log file. By default, all output is turned on. All <i><tt>configkeyword</tt></i> keywords can be prefixed with <tt>=</tt>, <tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the <tt>syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages. <tt>syslog messages</tt> can be controlled in four classes (<tt>clock</tt>, <tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>). Within these classes four types of messages can be controlled: informational messages (<tt>info</tt>), event messages (<tt>events</tt>), statistics messages (<tt>statistics</tt>) and status messages (<tt>status</tt>).
<p>Configuration keywords are formed by concatenating the message class with the event class. The <tt>all</tt> prefix can be used instead of a message class. A message class may also be followed by the <tt>all</tt> keyword to enable/disable all messages of the respective message class.Thus, a minimal log configuration could look like this:</p>
<p><tt>logconfig=syncstatus +sysevents</tt></p>
- <p>This would just list the synchronizations state of <tt>ntpd</tt> and the major system events. For a simple reference server, the following minimum message configuration could be useful:</p>
+ <dl>
+ <dd>
+ <p>This would just list the synchronizations state of <tt>ntpd</tt> and the major system events. For a simple reference server, the following minimum message configuration could be useful:</p>
+
+ </dl>
+
+ <dd>
<p><tt>logconfig=syncall +clockall</tt></p>
- <p>This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.</p>
+ <dl>
+ <dd>
+ <p>This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.</p>
+
+ </dl>
+ <dd>
<p><tt>logfile <i>logfile</i></tt></p>
- <p>This command specifies the location of an alternate log file to be used instead of the default system <tt>syslog</tt> facility. This is the same operation as the <tt>-l </tt>command line option.</p>
+ <dl>
+ <dd>
+ <p>This command specifies the location of an alternate log file to be used instead of the default system <tt>syslog</tt> facility. This is the same operation as the <tt>-l </tt>command line option.</p>
+
+ </dl>
<dt><tt>phone <i>dial</i>1 <i>dial</i>2 ...</tt>
- <dd>This command is used in conjunction with the ACTS modem driver (type 18). The arguments consist of a maximum of 10 telephone numbers used to dial USNO, NIST or European time services. The Hayes command ATDT is normally prepended to the number, which can contain other modem control codes as well.
+ <dl>
+ <dd>This command is used in conjunction with the ACTS modem driver (type 18). The arguments consist of a maximum of 10 telephone numbers used to dial USNO, NIST or European time services. The Hayes command ATDT is normally prepended to the number, which can contain other modem control codes as well.
+ </dl>
<dt><tt>setvar <i>variable</i> [default]</tt>
<dd>This command adds an additional system variable. These variables can be used to distribute additional information such as the access policy. If the variable of the form <tt><i>name</i> = <i>value</i></tt> is followed by the <tt>default</tt> keyword, the variable will be listed as part of the default system variables (<tt>ntpq rv</tt> command). These additional variables serve informational purposes only. They are not related to the protocol other that they can be listed. The known protocol variables will always override any variables defined via the <tt>setvar</tt> mechanism. There are three special variables that contain the names of all variable of the same group. The <tt>sys_var_list</tt> holds the names of all system variables. The <tt>peer_var_list</tt> holds the names of all peer variables and the <tt>clock_var_list</tt> holds the names of the reference clock variables.
<dt><tt>tinker [ allan <i>allan</i> | dispersion <i>dispersion</i> | freq <i>freq</i> | huffpuff <i>huffpuff</i> | panic <i>panic</i> | step <i>step</i> | stepout <i>stepout</i> ]</tt>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
<html>
-
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntpd System Log Messages</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
-
<body>
<h3><tt>ntpd</tt> System Log Messages</h3>
<img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The mushroom knows all the error codes, which is more than most of us do.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:43</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:24</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="284">Saturday, October 01, 2005</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <p><script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
</p>
<hr>
<p>You have come here because you found a cryptic message in the system log. This page by no means lists all messages that might be found, since new ones come and old ones go. Generally, however, the most common ones will be found here. They are listed by program module and log severity code in bold: <tt><b>LOG_ERR</b></tt>, <b><tt>LOG_NOTICE</tt></b> and <tt><b>LOG_INFO</b></tt>.</p>
<h4>Protocol Module</h4>
<p><tt><b>LOG_ERR</b></tt></p>
<dl>
- <dt>buffer overflow ?
+ <dt><tt>buffer overflow ?
+ </tt>
<dd>Fatal error. An input packet is too long for processing.
</dl>
<p><tt><b>LOG_NOTICE</b></tt></p>
<dl>
- <dt><tt>no reply; clock not set </tt>
+ <dt><tt>no reply; clock not set</tt>
<dd>In <tt>ntpdate</tt> mode no servers have been found. The server(s) and/or network may be down. Standard debugging procedures apply.
- </dl>
- <p><tt><b>LOG_INFO</b></tt></p>
- <dl>
- <dt><tt>proto_config: illegal item ?, value ? </tt>
+ <p><tt><b>LOG_INFO</b></tt></p>
+ <dt><tt>proto_config: illegal item ?, value ?</tt>
<dd>Program error. Please report to bugs@ntp.org.
- <dt><tt>pps sync enabled </tt>
+ <dt><tt>pps sync enabled</tt>
<dd>The PPS signal has been detected and enabled.
- <dt><tt>transmit: encryption key ? not found </tt>
- <dd>The key cache is inconsistent. Please report to bugs@ntp.org.
+ <dt><tt>transmit: encryption key ? not found</tt>
+ <dd>The encryption key is not defined or not trusted.
<dt><tt>precision = ? usec </tt>
<dd>This reports the precision measured for this machine.
- <dt><tt>using 10ms tick adjustments </tt>
+ <dt><tt>using 10ms tick adjustments</tt>
<dd>Gotcha for some machines with dirty rotten clock hardware.
- <dt><tt>no servers reachable </tt>
+ <dt><tt>no servers reachable</tt>
<dd>The system clock is running on internal batteries. The server(s) and/or network may be down.
</dl>
<h4>Clock Discipline Module</h4>
<dl>
<dt><tt>time correction of ? seconds exceeds sanity limit (?); set clock manually to the correct UTC time</tt>.
<dd>Fatal error. Better do what it says, then restart the daemon. Be advised NTP and Unix know nothing about local time zones. The clock must be set to Coordinated Universal Time (UTC). Believe it; by international agreement abbreviations are in French and descriptions are in English.
- <dt><tt>sigaction() fails to save SIGSYS trap: ? </tt>
- <dt><tt>sigaction() fails to restore SIGSYS trap: ? </tt>
- <dd>Program error. Please report to bugs@ntp.org.
+ <dt><tt>sigaction() fails to save SIGSYS trap: ?<br>
+ </tt><tt>sigaction() fails to restore SIGSYS trap: ?</tt>
+ <dt>Program error. Please report to bugs@ntp.org.
</dl>
<p><tt><b>LOG_NOTICE</b></tt></p>
<dl>
<dt><tt>frequency error ? exceeds tolerance 500 PPM</tt>
<dd>The hardware clock frequency error exceeds the rate the kernel can correct. This could be a hardware or a kernel problem.
- <dt><tt>time slew ? s </tt>
+ <dt><tt>time slew ? s</tt>
<dd>The time error exceeds the step threshold and is being slewed to the correct time. You may have to wait a very long time.
- <dt><tt>time reset ? s </tt>
+ <dt><tt>time reset ? s</tt>
<dd>The time error exceeds the step threshold and has been reset to the correct time. Computer scientists don't like this, but they can set the <tt>ntpd -x</tt> option and wait forever.
- <dt><tt>kernel time sync disabled ? </tt>
+ <dt><tt>kernel time sync disabled ?</tt>
<dd>The kernel reports an error. See the codes in the <tt>timex.h</tt> file.
- <dt><tt>pps sync disabled </tt>
+ <dt><tt>pps sync disabled</tt>
<dd>The PPS signal has died, probably due to a dead radio, broken wire or loose connector.
</dl>
<p><tt><b>LOG_INFO</b></tt></p>
- <tt>kernel time sync status ? </tt>
<dl>
+ <dt><tt>kernel time sync status ? </tt>
<dd>For information only. See the codes in the <tt>timex.h</tt> file.
</dl>
<h4>Cryptographic Module</h4>
<p><tt><b>LOG_ERR</b></tt></p>
<dl>
- <dt><tt>cert_parse ? </tt>
- <dt><tt>cert_sign ? </tt>
- <dt><tt>crypto_cert ? </tt>
- <dt><tt>crypto_encrypt ? </tt>
- <dt><tt>crypto_gq ? </tt>
- <dt><tt>crypto_iff ? </tt>
- <dt><tt>crypto_key ? </tt>
- <dt><tt>crypto_mv ? </tt>
- <dt><tt>crypto_setup ? </tt>
- <dt><tt>make_keys ? </tt>
+ <dt><tt>cert_parse ?<br>
+ </tt><tt>cert_sign ?<br>
+ </tt><tt>crypto_cert ?<br>
+ </tt><tt>crypto_encrypt ?<br>
+ </tt><tt>crypto_gq ?<br>
+ </tt><tt>crypto_iff ?<br>
+ </tt><tt>crypto_key ?<br>
+ </tt><tt>crypto_mv ?<br>
+ </tt><tt>crypto_setup ?<br>
+ </tt><tt>make_keys ?</tt>
<dd>Usually fatal errors. These messages display error codes returned from the OpenSSL library. See the OpenSSL documentation for explanation.
- <dt><tt>crypto_setup: certificate ? is trusted, but not self signed. </tt>
- <dt><tt>crypto_setup: certificate ? not for this host </tt>
- <dt><tt>crypto_setup: certificate file ? not found or corrupt </tt>
- <dt><tt>crypto_setup: host key file ? not found or corrupt </tt>
- <dt><tt>crypto_setup: host key is not RSA key type </tt>
- <dt><tt>crypto_setup: random seed file ? not found</tt>
- <dt><tt>crypto_setup: random seed file not specified </tt>
+ <dt><tt>crypto_setup: certificate ? is trusted, but not self signed.<br>
+ </tt><tt>crypto_setup: certificate ? not for this host<br>
+ </tt><tt>crypto_setup: certificate file ? not found or corrupt<br>
+ </tt><tt>crypto_setup: host key file ? not found or corrupt<br>
+ </tt><tt>crypto_setup: host key is not RSA key type<br>
+ </tt><tt>crypto_setup: random seed file ? not found<br>
+ </tt><tt>rypto_setup: random seed file not specified</tt>
<dd>Fatal errors. These messages show problems during the initialization procedure.
</dl>
<p><tt><b>LOG_INFO</b></tt></p>
<dl>
- <dt><tt>cert_parse: expired ? </tt>
- <dt><tt>cert_parse: invalid issuer ? </tt>
- <dt><tt>cert_parse: invalid signature ? </tt>
- <dt><tt>cert_parse: invalid subject ? </tt>
+ <dt><tt>cert_parse: expired ?<br>
+ </tt><tt>cert_parse: invalid issuer ?<br>
+ </tt><tt>cert_parse: invalid signature ?<br>
+ </tt><tt>cert_parse: invalid subject ?</tt>
<dd>There is a problem with a certificate. Operation cannot proceed untill the problem is fixed. If the certificate is local, it can be regenerated using the <tt>ntp-keygen</tt> program. If it is held somewhere else, it must be fixed by the holder.
- <dt><tt>crypto_?: defective key </tt>
- <dt><tt>crypto_?: invalid filestamp </tt>
- <dt><tt>crypto_?: missing challenge </tt>
- <dt><tt>crypto_?: scheme unavailable </tt>
+ <dt><tt>crypto_?: defective key<br>
+ </tt><tt>crypto_?: invalid filestamp<br>
+ </tt><tt>crypto_?: missing challenge<br>
+ </tt><tt>crypto_?: scheme unavailable</tt>
<dd>There is a problem with the identity scheme. Operation cannot proceed untill the problem is fixed. Usually errors are due to misconfiguration or an orphan association. If the latter, <tt>ntpd</tt> will usually time out and recover by itself.
- <dt><tt>crypto_cert: wrong PEM type ? </tt>
+ <dt><tt>crypto_cert: wrong PEM type ?</tt>
<dd>The certificate does not have MIME type <tt>CERTIFICATE</tt>. You are probably using the wrong type from OpenSSL or an external certificate authority.
- <dt><tt>crypto_ident: no compatible identity scheme found </tt>
+ <dt><tt>crypto_ident: no compatible identity scheme found</tt>
<dd>Configuration error. The server and client identity schemes are incompatible.
- <dt><tt>crypto_tai: kernel TAI update failed </tt>
+ <dt><tt>crypto_tai: kernel TAI update failed</tt>
<dd>The kernel does not support this function. You may need a new kernel or patch.
- <dt><tt>crypto_tai: leapseconds file ? error ? </tt>
+ <dt><tt>crypto_tai: leapseconds file ? error ?</tt>
<dd>The leapseconds file is corrupt. Obtain the latest file from <tt>time.nist.gov</tt>.
</dl>
<hr>
projects / thirdparty / ntp.git / commitdiff
