[ntp:bk-ntp-dev-send] BitKeeper diffs
Harlan Stenn
stenn at deacon.udel.edu
Mon Oct 3 21:53:16 UTC 2011
#### ChangeSet ####
2011-10-03 17:51:59-04:00, stenn at deacon.udel.edu
Documentation updates from Dave Mills
==== ChangeLog ====
2011-10-03 17:50:43-04:00, stenn at deacon.udel.edu +1 -0
Documentation updates from Dave Mills
--- 1.1049/ChangeLog 2011-10-03 01:00:20 -04:00
+++ 1.1050/ChangeLog 2011-10-03 17:50:43 -04:00
@@ -1,3 +1,4 @@
+* Documentation updates from Dave Mills.
(4.2.7p218) 2011/10/03 Released by Harlan Stenn <stenn at ntp.org>
* [Bug 2019] Allow selection of cipher for private key files.
* Documentation updates from Dave Mills.
==== html/authentic.html ====
2011-10-03 17:51:05-04:00, stenn at deacon.udel.edu +12 -5
Documentation updates from Dave Mills
--- 1.7/html/authentic.html 2011-10-02 17:43:34 -04:00
+++ 1.8/html/authentic.html 2011-10-03 17:51:05 -04:00
@@ -20,7 +20,7 @@ color: #FF0000;
<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:
- <!-- #BeginDate format:En2m -->29-Sep-2011 15:16<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Oct-2011 16:14<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
@@ -47,15 +47,22 @@ required.</p>
<h4 id="symm">Symmetric Key Cryptography</h4>
<p>The original NTPv3 specification (RFC-1305), as well as the current NTPv4 specification (RFC-5905), allows any one of possibly 65,534 message digest keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key ID, key type and key to authenticate NTP packets.</p>
<p>The message digest is a cryptographic hash computed by an algorithm such as MD5 or SHA. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of a 128- or 160- bit message digest key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two digests are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a <em>crypto-NAK</em>. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NA
K.</p>
-<p>Keys and related information are specified in a keys file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor. Each line consists of three fields, a key ID in the range 1 to 65,534, inclusive, a key type chosen from the keywords of the <tt>digest</tt> option of the <tt>crypto</tt> command, and a 20-character printable ASCII string or a 40-character hex string as the key itself.</p>
+<p>Keys and related information are specified in a keys file, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor.</p>
+<p> Each line of the keys file consists of three fields, a key ID in the range 1 to 65,534, inclusive, a key type chosen from the keywords of the <tt>digest</tt> option of the <tt>crypto</tt> command, and a printable ASCII string less than 40 characters in length, or a 40-character hex string, as the key itself.</p>
+<blockquote>
+ <p>Note: If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
+</blockquote>
<div align="center">
<p><img src="pic/sx5.gif" alt="gif"></p>
<p>Figure 1. Typical Symmetric Key File</p>
</div>
-<p>Figure 1 shows a typical keys file used by the reference implementation. If the length of the key is less than 40 characters, it is interpreted as a printable ASCII string; if equal to 40 characters, it is interpreted as a hex string. The string can be edited later for a password, for instance as <tt>2late4Me</tt> for key ID 10.</p>
+<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. If the length of the key is less than 40 characters, it is interpreted as a printable ASCII string; if equal to 40 characters, it is interpreted as a hex string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The string can be edited later for a password, for instance as <tt>2late4Me</tt> for key ID 10.</p>
+<blockquote>
+ <p>Note. If the OpenSSL library is not installed, the keys file must be permitted root access only. If the library is installed, the file can be optionally encrypted with any encryption algorithm supported by the library.</p>
+</blockquote>
<h4 id="windows"></h4>
-<p>When <tt>ntpd</tt> is first started, it reads the key file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
-<p>Microsoft Windows Authentication</p>
+<p>When <tt>ntpd</tt> is started, it reads the keys file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
+<h4>Microsoft Windows Authentication</h4>
<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="authopt.html">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
<h4 id="pub">Public Key Cryptography</h4>
<p>See the <a href="autokey.html">Autokey Public-Key Authentication</a> page.</p>
==== html/autokey.html ====
2011-10-03 17:51:05-04:00, stenn at deacon.udel.edu +3 -3
Documentation updates from Dave Mills
--- 1.20/html/autokey.html 2011-05-10 15:45:37 -04:00
+++ 1.21/html/autokey.html 2011-10-03 17:51:05 -04:00
@@ -16,7 +16,7 @@
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->11-Feb-2011 10:36<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->01-Oct-2011 16:11<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
@@ -34,10 +34,10 @@
<h4 id="intro">Introduction</h4>
<p>This distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is specified when the distribution is built.</p>
<p> Public key cryptography is generally considered more secure than symmetric key cryptography. Symmetric key cryptography is based on a shared secret key which must be distributed by secure means to all participants. Public key cryptography is based on a private secret key known only to the originator and a public key known to all participants. A recipient can verify the originator has the correct private key using the public key and any of several digital signature algorithms.</p>
-<p>The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using message digest algorithms, such as MD5 or SHA, and verifies the source using any of several digital signature schemes, such as RSA or DSA. As used in Autokey, message digests are exceptionally difficult to cryptanalyze, as the keys are used only once.</p>
+<p>The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using message digest algorithms, such as MD5 or SHA, and verifies the source using digital signature schemes, such as RSA or DSA. As used in Autokey, message digests are exceptionally difficult to cryptanalyze, as the keys are used only once.</p>
<p> Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. Optional identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficult to cryptanalyze, as the challenge/response exchange data are used only once. They are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same IP addresses 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 and clients are operated outside firewall perimeters.</p>
-<p>Autokey is designed to authenticate servers to clients, not the other way around as in SSH. An Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme described in RFC 5905, while a client is free to choose between the various options. It is important to understand that these provisions are optional and that selection of which option is at the discretion of the client. If the client does not require authentication, it is free to ignore it, even if some other client of the same server elects to participate in either symmetric key or public key cryptography.</p>
+<p>Autokey is designed to authenticate servers to clients, not the other way around as in SSH. An Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme described in RFC 5906, while a client is free to choose between the various options. It is important to understand that these provisions are optional and that selection of which option is at the discretion of the client. If the client does not require authentication, it is free to ignore it, even if some other client of the same server elects to participate in either symmetric key or public key cryptography.</p>
<p> Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the client and the time period over which the the public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produced with the Autokey host name as subject and the host that signs the certificate as issuer.</p>
<p>There are two timeouts associated with the Autokey scheme. The <em>key list timeout</em> is set by the <tt>automax</tt> command, which specifies the interval between generating new key lists by the client or server. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The <em>revoke timeout</em> is set by the <tt>revoke</tt> 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.</p>
<h4 id="subnet">Autokey Subnets</h4>
==== html/drivers/driver20.html ====
2011-10-03 17:51:31-04:00, stenn at deacon.udel.edu +12 -21
Documentation updates from Dave Mills
--- 1.24/html/drivers/driver20.html 2011-01-19 01:58:00 -05:00
+++ 1.25/html/drivers/driver20.html 2011-10-03 17:51:31 -04:00
@@ -2,8 +2,7 @@
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"><title>Generic NMEA GPS Receiver</title>
- <link href="driver20_files/a" type="text/css" rel="stylesheet">
-
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
table.dlstable { font-size:85%; }
td.ttf{ font-family:Courier; font-weight:bold; }
@@ -214,22 +213,22 @@
</tr><tr>
<td rowspan="6" align="center">4-6</td>
<td align="center">0</td>
- <td>linespeed 4800bps</td>
+ <td>linespeed 4800 bps</td>
</tr><tr>
<td align="center">16</td>
- <td>linespeed 9600bps</td>
+ <td>linespeed 9600 bps</td>
</tr><tr>
<td align="center">32</td>
- <td>linespeed 19200bps</td>
+ <td>linespeed 19200 bps</td>
</tr><tr>
<td align="center">48</td>
- <td>linespeed 38400bps</td>
+ <td>linespeed 38400 bps</td>
</tr><tr>
<td align="center">64</td>
- <td>linespeed 57600bps</td>
+ <td>linespeed 57600 bps</td>
</tr><tr>
<td align="center">80</td>
- <td>linespeed 115200bps</td>
+ <td>linespeed 115200 bps</td>
</tr><tr>
<td align="center">7</td>
<td align="center">128</td>
@@ -244,7 +243,7 @@
<p>
The default (mode 0) is to process all supported sentences at a linespeed
- of 4800bps, which results in the first one received and recognised in
+ of 4800 bps, which results in the first one received and recognised in
each cycle being used. If only specific sentences should be
recognised, then the mode byte must be chosen to enable only the selected
ones. Multiple sentences may be selected by adding their mode bit
@@ -267,12 +266,12 @@
increase the precision of the timing device. Higher line speeds are
not necessarily helpful for the NMEA driver, either. They can be
used to accomodate for an amount of data that does not fit into a
- 1-second cycle at 4800bps, but high-speed high-volume NMEA data is likely
+ 1-second cycle at 4800 bps, but high-speed high-volume NMEA data is likely
to cause trouble with the serial line driver since NMEA supports no
protocol handshake. Any device that is exclusively used for time
synchronisation purposes should be configured to transmit the relevant
data only, e.g. one <tt>$GPRMC</tt> or <tt>$GPZDA</tt> per second, at a
- linespeed of 4800bps or eventually 9600bps.
+ linespeed of 4800 bps or 9600 bps.
</p>
<p>
@@ -287,14 +286,6 @@
decimal value into the clock configuration line.
</p>
- <p>
- The driver will send a <tt>$PMOTG,RMC,0000*1D<cr><lf></tt>
- command each poll interval. This is not needed on most GPS
- receivers because they automatically send <tt>$GPRMC</tt> every second,
- but helps a Motorola GPS receiver that is otherwise silent. NMEA
- devices ignore commands they do not understand.
- </p>
-
<h4>Setting up the Garmin GPS-25XL</h4>
Switch off all output with by sending it the following string.
@@ -337,7 +328,7 @@
</dl>
<p>Additional Information</p>
- <p><a href="">Reference Clock Drivers</a></p>
+ <p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
- <script type="text/javascript" language="javascript" src="driver20_files/a"></script>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body></html>
==== html/drivers/driver8.html ====
2011-10-03 17:51:31-04:00, stenn at deacon.udel.edu +2 -2
Documentation updates from Dave Mills
--- 1.27/html/drivers/driver8.html 2011-07-25 00:36:07 -04:00
+++ 1.28/html/drivers/driver8.html 2011-10-03 17:51:31 -04:00
@@ -260,6 +260,6 @@ Note about auxiliary Sun STREAMS modules
<p>Additional Information</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
- </body>
-
+<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+</body>
</html>
==== html/history.html ====
2011-10-03 17:51:05-04:00, stenn at deacon.udel.edu +2 -2
Documentation updates from Dave Mills
--- 1.1/html/history.html 2011-10-02 18:08:38 -04:00
+++ 1.2/html/history.html 2011-10-03 17:51:05 -04:00
@@ -38,7 +38,7 @@
<p>The leap armed condition is displayed in the host status word. Transitions between warnings and no warnings are reported to the protostats file, system log and traps.</p>
<h4>7. Orphan Mode and Local Clock Driver</h4>
<p>The orphan mode code has been overhauled to correct some minor bugs and to clarify operation under normal and recovery conditions. The requirement that all subnet hosts have orphan configuration has been removed. The only requirement is that the orphan clients on the DMZ network sharing the root server(s) be so configured The scheme now works if the root servers are configured with each other, either in symmetric or broadcast modes. Orphan mode is not considered in the NTPv4 protocol specification.</p>
-<p>The local clock driver can be very dangerous when used as a fallback when connectivity to Internet time servers is interrupted. Orphan mode was designed to reduce the need for the local clock driver, as it is active only if no sever is available. The local clock driver has been modified to have the same characteristics, regardless of stratum. Only if the host running the local clock driver loses all servers, regardless of stratum, is the driver activated. Thus, it is possible, but not recommended, to run the driver at any stratum, including zero.</p>
+<p>The local clock driver can be very dangerous when used as a fallback when connectivity to Internet time servers is interrupted. Orphan mode was designed to reduce the need for the local clock driver, as it is active only if no server is available. The local clock driver has been modified to have the same characteristics, regardless of stratum. Only if the host running the local clock driver loses all servers, regardless of stratum, is the driver activated. Thus, it is possible, but not recommended, to run the driver at any stratum, including zero.</p>
<h4>8. Poll Rate Control</h4>
<p>One of the most persistent problems is when after long operation and then a failure and then subsequently recovery, a client can take a long time to refresh the clock filter and resynchronize. Once the client has backed off the poll interval after a lengthy outage, it sends polls at that interval until receiving a response. At that time it temporarily retries at the minimum poll interval to fill up the clock filter. If iburst is configured, this will happen after 10 seconds or so and the client then resumes its poll interval required by the discipline time constant. This avoids needless network traffic while the poll interval increases gradually to the maximum. Further information is in the current web documentation.</p>
<p>The same thing happens on initial startup or when an association is restarted. The intent is to avoid a blast of <tt>iburst</tt> packets unless the server actually responds to the first one and to retry only while responding to the the rate controls.</p>
@@ -56,7 +56,7 @@
<p>A more serious comment has to do with using other than the NTP packet, status words and events for monitoring purposes. Emphasis added: monitors should not parse such things as the flash codes, clock state or anything else not called out in the NTPv4 specification. The clock state machine is defined in the specification, but no specific numbers are assigned to the states.</p>
<p>When the numbers were changed to align for reporting purposes, some scripts no longer worked. The scripts should be changed to use only the leap and select fields of the system status word. If the leap field is other than 0, the client has synchronized at least once; if the select field is other than 0, the client is currently synchronized to the source indicated in the decode.</p>
<h4>11. Two-step and timestamp capture</h4>
-<p>A number of interesting ideas were found in the IEEE 1588 Precision Time Protocol specification. One of them was the two-step protocol in which the transmit timestamp is sent in a following message. However, the PTP design operates only in a master-slave configuration and is not directly usable in NTP. The protocol was adapted to the NTP symmetric design, which requires four state variables rather than two. It is described on <a href=" www.eecis.udel.edu/~mills/stamp.html">Timestamp Capture Principles</a>. This might be an interesting project for future research.</p>
+<p>A number of interesting ideas were found in the IEEE 1588 Precision Time Protocol specification. One of them was the two-step protocol in which the transmit timestamp is sent in a following message. However, the PTP design operates only in a master-slave configuration and is not directly usable in NTP. The protocol was adapted to the NTP symmetric design, which requires four state variables rather than two. It is described on <a href="http://www.eecis.udel.edu/~mills/stamp.html">Timestamp Capture Principles</a>. This might be an interesting project for future research.</p>
<p>A detailed study of the timestamp capture opportunities for both hardware and software timestamping revealed that the most accurate and interoperable design involves the transmit timestamp at the beginning of the packet and then receive timestamp at the end. This makes it possible to accurately measure the offset and delay even if the ends of the synchronization path operate at different rates. It is described on the Timestamp Capture Principles page.</p>
<h4>12. Windows client bug</h4>
<p>The Windows XP and Vista clients send the NTP request in symmetric active mode rather than client mode. An unsuspecting server could mobilize a symmetric passive association, which is a serious security vulnerability. The NTPv4 servers, including those at NIST and USNO, discard symmetric active requests unless cryptographically authenticated, so Windows clients do not work. The Microsoft KB 875424 discusses the preferred workaround; however, an optional workaround is now available so that, if the request is not authenticated, the server responds with symmetric passive mode, but without mobilize an association. The workaround is enabled with the WINTIME build option.</p>
==== html/keygen.html ====
2011-10-03 17:51:06-04:00, stenn at deacon.udel.edu +10 -10
Documentation updates from Dave Mills
--- 1.30/html/keygen.html 2011-10-02 17:43:34 -04:00
+++ 1.31/html/keygen.html 2011-10-03 17:51:06 -04:00
@@ -11,7 +11,7 @@
<p><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>
<p>Alice holds the key.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->29-Sep-2011 15:03<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->03-Oct-2011 7:03<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
@@ -21,8 +21,6 @@
<li class="inline"><a href="#synop">Synopsis</a></li>
<li class="inline"><a href="#descrip">Description</a></li>
<li class="inline"><a href="#run">Running the program</a></li>
- <li class="inline"><a href="#trust">Trusted Hosts and Secure Groups</a></li>
- <li class="inline"><a href="#ident">Identity Schemes</a></li>
<li class="inline"><a href="#cmd">Command Line Options</a></li>
<li class="inline"><a href="#rand">Random Seed File</a></li>
<li class="inline"><a href="#fmt">Cryptographic Data Files</a></li>
@@ -30,11 +28,11 @@
</ul>
<hr>
<h4 id="synop">Synopsis</h4>
-<p id="intro"><tt>ntp-keygen [ -deGHIMPT ] [ -c [RSA-MD2 | RSA-MD5 | RSA-SHA
- | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ] ] [
- -i <i>group</i> ]
- -l <em>days</em>] [ -m <i>modulus</i> ] [ -p <i>passwd1</i> ] [ -q <i>passwd2</i> ] [ -S
- [ RSA | DSA ] ] [ -s <i>host</i> ] [ -V <i>nkeys</i> ]</tt></p>
+<p id="intro"><tt>ntp-keygen [ -deGHIMPT ] [ -c [ RSA-MD2 | RSA-MD5 | RSA-SHA
+ | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ] ]
+ [ -C <i>cipher</i> ] [-i <i>group</i> ] [ -l <em>days</em>]
+ [ -m <i>modulus</i> ] [ -p <i>passwd1</i> ] [ -q <i>passwd2</i> ]
+ [ -S [ RSA | DSA ] ] [ -s <i>host</i> ] [ -V <i>nkeys</i> ]</tt></p>
<h4 id="descrip">Description</h4>
<p>This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It can generate message digest keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it can generate host keys, sign keys, certificates, and identity keys and parameters used by the Autokey public key cryptography. The message digest keys file is generated in a format compatible with NTPv3. All other files are in PEM-encoded printable ASCII format so they can be embedded as MIME attachments in mail to other sites.</p>
<p>When used to generate message digest keys, the program produces a file containing
@@ -54,6 +52,8 @@
<dl>
<dt><tt>-c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]</tt></dt>
<dd>Select certificate digital signature and message digest scheme. Note that RSA schemes must be used with an RSA sign key and DSA schemes must be used with a DSA sign key. The default without this option is <tt>RSA-MD5</tt>. If compatibility with FIPS 140-2 is required, either the <tt>DSA-SHA</tt> or <tt>DSA-SHA1</tt> scheme must be used.</dd>
+ <dt><tt>-C <i>cipher</i></tt></dt>
+ <dd>Select the OpenSSL cipher to use for password-protected keys. The <tt>openssl -h</tt> command provided with OpenSSL displays available ciphers. The default without this option is <tt>des-ede3-cbc</tt>.</dd>
<dt><tt>-d</tt></dt>
<dd>Enable debugging. This option displays the cryptographic data produced for eye-friendly billboards.</dd>
<dt><tt>-e</tt></dt>
@@ -63,7 +63,7 @@
<dt><tt>-H</tt></dt>
<dd>Generate a new encrypted RSA public/private host key file.</dd>
<dt><tt>-i <i>group</i></tt></dt>
- <dd>Set the optional group name to <tt><i>group</i></tt>. This is used in the identity file names. If used, it must match the file name specified in the <tt>ident</tt> option of the <tt>crypto</tt> configuration command.</dd>
+ <dd>Set the optional Autokey group name to <tt><i>group</i></tt>. This is used in the identity scheme parameter file names. In that role, the default is the host name if no group is provided. The group name, if specified using <tt>-i</tt> or using <tt>-s</tt> following an <tt>@</tt> character, is also used in certificate subject and issuer names in the form <tt><i>host</i>@<i>group</i></tt> and should match the group specified via <tt>crypto ident</tt> or <tt>server ident</tt> in ntpd's configuration file.</dd>
<dt><tt>-I</tt></dt>
<dd>Generate a new encrypted IFF key file for the Schnorr (IFF) identity scheme. This option is mutually exclusive with the <tt>-G</tt> and <tt>-V</tt> options.</dd>
<dt><tt>-l <i>days</i></tt></dt>
@@ -83,7 +83,7 @@
the host key and has the same type. If compatibly with FIPS 140-2 is required,
the sign key type must be <tt>DSA</tt>.</dd>
<dt><tt>-s <i>host</i>[@<i>group</i>]</tt></dt>
- <dd>Specify the Autokey host name, where <em><tt>host</tt></em> is the host name and <em><tt>group</tt></em> is the optional group name. The Autokey host name is also the certificate subject and issuer names. If <em><tt>host</tt></em> is not specified, the default host name is the string returned by the Unix <tt>gethostname()</tt> routine.</dd>
+ <dd>Specify the Autokey host name, where <tt><i>host</i></tt> is the host name and <tt><i>group</i></tt> is the optional group name. The host name, and if provided, group name are used in <tt><i>host</i>@<i>group</i></tt> form as certificate subject and issuer. Specifying <tt>-s @<i>group</i></tt> is allowed, and results in leaving the host name unchanged, as with <tt>-i <i>group</i></tt>. The group name, or if no group is provided, the host name are also used in the file names of IFF, GQ, and MV identity scheme parameter files. If <tt><i>host</i></tt> is not specified, the default host name is the string returned by the <tt>gethostname()</tt> routine.</dd>
<dt><tt>-T</tt></dt>
<dd>Generate a trusted certificate. By default, the program generates nontrusted certificates.</dd>
<dt><tt>-V <i>nkeys</i></tt></dt>
==== html/release.html ====
2011-10-03 17:51:06-04:00, stenn at deacon.udel.edu +3 -3
Documentation updates from Dave Mills
--- 1.41/html/release.html 2011-10-02 17:43:34 -04:00
+++ 1.42/html/release.html 2011-10-03 17:51:06 -04:00
@@ -11,7 +11,7 @@
<img src="pic/hornraba.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>The rabbit toots to make sure you read this.</p>
<p>Last update:
- <!-- #BeginDate format:En1m -->5-aug-11 18:32<!-- #EndDate -->
+ <!-- #BeginDate format:En1m -->3-oct-11 18:20<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
@@ -36,7 +36,7 @@
<li>This release includes comprehensive packet rate management tools to help reduce the level of spurious network traffic and protect the busiest servers from overload. There is support for the optional Kiss-o'-Death (KoD) packet intended to slow down an abusive client. See the <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a> page for further information.</li>
<li>There are two new burst mode features available where special conditions apply. One of these is enabled by the <tt>iburst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where it is important to set the clock quickly when an association is first mobilized. The other is enabled by the <tt>burst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where the network attachment requires an initial calling or training procedure. See the <a href="assoc.html">Association Management</a> page for further information.</li>
<li>The OpenSSL cryptographic library has replaced the library formerly available from RSA Laboratories. All cryptographic routines except a version of the MD5 message digest algorithm have been removed from the base distribution. All 128-bit and 160-bit message digests algorithms are now supported for both symmetric key and public key cryptosystems. See the <a href="authentic.html">Authentication Support</a> page for further information and the <a href="authopt.html">Authentication Options</a> page for a list of supported digest algorithms.</li>
- <li>This release includes support for Autokey public-key cryptography for authenticating public servers to clients, as described in RFC 5906. This support requires the --enabld-autokey option when building the distribution. The deployment of Autokey subnets is now considerably simpler than in earlier versions. A subnet naming scheme is now available to filter manycast and pool configurations. Additional information about Autokey is on the <a href="autokey.html">Autokey Public Key Authentication</a> page and links from there.</li>
+ <li>This release includes support for Autokey public-key cryptography for authenticating public servers to clients, as described in RFC 5906. This support requires the --enable-autokey option when building the distribution, which is the default is OpenSSL is available. The deployment of Autokey subnets is now considerably simpler than in earlier versions. A subnet naming scheme is now available to filter manycast and pool configurations. Additional information about Autokey is on the <a href="autokey.html">Autokey Public Key Authentication</a> page and links from there.</li>
<li>The NTP descrete even simulator has been substantially upgraded, now including scenarios with multiple servers and time-sensitive scripts. This allows the NTP algorithms to be tested in an embedded environment with systematic and pseudo-random network delay and oscillator wander distributions. This has been used to verify correct operation under conditions of extreme error and misconfiguration. See the <a href="ntpdsim.html"><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a> page. A technical description and performance analysis is given in the white papers at the <a href="http://www.eecis.udel.edu/~mills/ntp.html">NTP Project Page</a>.</li>
<li>NTPv4 includes three new server discovery schemes, which in most applications can avoid per-host configuration altogether. Two of these are based on IP multicast technology, while the remaining one is based on crafted DNS lookups. See the <a href="discover.html">Automatic NTP Configuration Schemes</a> page for further information.</li>
<li>The status display and event report monitoring functions have been considerably expanded, including new statistics files and event reporting to files and the system log. See the <a href="decode.html">Event Messages and Status Words</a> page for further information.</li>
@@ -54,7 +54,7 @@
<li>Support for the precision time kernel modifications, which are now in stock FreeBSD and optional in Linux kernels, is included. With this support the system clock can be disciplined to the order of one nanosecond. The older microtime kernel modifications in Digital/Compaq/HP Tru64, Digital Ultrix and Sun Microsystems SunOS and Solaris, continue to be supported. In either case the support eliminates sawtooth error, which can be in the hundreds of microseconds. Further information is on the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page.</li>
<li>New reference clock drivers have been added for several GPS receivers now on the market for a total of 44 drivers. The reference clock driver interface is smaller, more rational, more flexible and more accurate. Most of the drivers in NTPv3 have been converted to the NTPv4 interface and continue to operate as before. A summary of the supported drivers is on the <a href="refclock.html">Reference Clock Support</a> page. Audio drivers for the Canadian standard time and frequency station CHU, the US standard time and frequency stations WWV/H and for IRIG signals have been updated and capabilities added to allow direct connection of these signals to an audio port. See the <a href="audio.html">Reference Clock Audio Drivers</a> page for further information.</li>
<li>Support for pulse-per-second (PPS) signals has been extended to all drivers as an intrinsic function. Further information is on the <a href="pps.html">Pulse-Per-Second (PPS) Signal Interfacing</a> page. Typical performance with the PPS interface and a fast machine are in the low microseconds.</li>
- <li>Several small changes have been made to make administration and maintenance more convenience. The entire distribution has been converted to gnu <tt>automake</tt>, which greatly ease the task of porting to new and different programming environments, as well as reduce the incidence of bugs due to improper handling of idiosyncratic kernel functions. Version control is provided by Bitkeeper using an online repository at www.ntp.org. Trouble ticket reporting is provided using Bugzilla. If <tt>ntpd</tt>, is configured with NetInfo support, it will attempt to read its configuration from the NetInfo service if the default <tt>ntp.conf</tt> file cannot be read and no file is specified by the <tt>-c</tt> option.When <tt>ntpd</tt> starts it looks at the value of <tt>umask</tt>, and if zero <tt>ntpd</tt> will set the <tt>umask</tt> to <tt>022</tt>.</li>
+ <li>Several small changes have been made to make administration and maintenance more convenience. The entire distribution has been converted to gnu <tt>automake</tt>, which greatly ease the task of porting to new and different programming environments, as well as reduce the incidence of bugs due to improper handling of idiosyncratic kernel functions. Version control is provided by Bitkeeper using an online repository at www.ntp.org. Trouble ticket reporting is provided using Bugzilla. If <tt>ntpd</tt>, is configured with NetInfo support, it will attempt to read its configuration from the NetInfo service if the default <tt>ntp.conf</tt> file cannot be read and no file is specified by the <tt>-c</tt> option. When <tt>ntpd</tt> starts it looks at the value of <tt>umask</tt>, and if zero <tt>ntpd</tt> will set the <tt>umask</tt> to <tt>022</tt>.</li>
</ul>
<h4 id="nasty">Nasty Surprises</h4>
<p>There are a few things different about this release that have changed since the latest NTP Version 3 release. Following are a few things to worry about:</p>
==== html/scripts/footer.txt ====
2011-10-03 17:51:25-04:00, stenn at deacon.udel.edu +6 -1
Documentation updates from Dave Mills
--- 1.3/html/scripts/footer.txt 2010-10-21 23:51:11 -04:00
+++ 1.4/html/scripts/footer.txt 2011-10-03 17:51:25 -04:00
@@ -1,7 +1,12 @@
document.write("\
+
<table><tr>\
+
<td width='50%' ><img src='icons/home.gif' align='middle' alt='gif'>\
+
<a href='index.html'>Home Page</a></td>\
+
<td width='50%' ><img src='icons/mail2.gif' align='middle' alt='gif'>\
-<a href='http://www.ntp.org/contact.html'>Contacts</a></i></td>\
+
+<a href='http://support.ntp.org/bin/view/Main/ContactInformation'>Contacts</a></i></td>\
</tr></table>")
==== html/sntp.html ====
2011-10-03 17:51:07-04:00, stenn at deacon.udel.edu +4 -4
Documentation updates from Dave Mills
--- 1.8/html/sntp.html 2011-08-04 19:40:35 -04:00
+++ 1.9/html/sntp.html 2011-10-03 17:51:07 -04:00
@@ -10,12 +10,12 @@
<img src="pic/dogsnake.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>S is for snakeoil.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->04-Aug-2010 1:38<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->03-Oct-2011 5:33<!-- #EndDate -->
UTC</p>
<br clear="left">
<hr>
<h4>Synopsis</h4>
-<tt>sntp [{--help -?}][{-4 -6}][-a <i>keynum</i>][-b <i>bcaddress</i>][-B <i>bctimeout</i>][-c][-d][-D <i>debug-level</i>][-h <i>delay</i>][-K <i>kodfile</i>][-k <i>keyfile</i>][-l <i>logfile</i>][-M <i>steplimit</i>][-o <i>ntpver</i>][-r][-S][-s][-u <i>uctimeout</i>][--wait][--version][<i>address(es)</i>]</tt>
+<tt>sntp [{--help -?}][{-4 -6}][-a <i>keynum</i>][-b <i>bcaddress</i>][-B <i>bctimeout</i>][-c][-d][-D <i>debug-level</i>][-g <i>delay</i>][-K <i>kodfile</i>][-k <i>keyfile</i>][-l <i>logfile</i>][-M <i>steplimit</i>][-o <i>ntpver</i>][-r][-S][-s][-u <i>uctimeout</i>][--wait][--version][<i>address(es)</i>]</tt>
<h4>Description</h4>
<p>This program is a Simple Network Time Protocol (SNTP) client that can be used to query a Network Time Protocol (NTP) server and display the time offset of the system clock relative to the server clock. Run as root it can correct the system clock to this offset as well. It can be run as an interactive command or from a script by a <tt>cron</tt> job. The program implements the SNTP client protocol defined in RFC 5905, including the full on-wire protocol but does not provide the sanity checks, access controls, security functions and mitigation algorithms as in the full NTP version 4 specification, also defined in RFC 5905.</p>
<p>By default, <tt>sntp</tt> writes the local date and time (i.e., not UTC) to the standard output in the format</p>
@@ -43,8 +43,8 @@
<dd>Increase debug verbosity level by one. May be specified multiple times. See also the <tt>-D, --set-debug-level</tt> option.</dd>
<dt><tt>-D <i>debug-level</i>, --set-debug-level <i>debug-level</i></tt></dt>
<dd>Set the debug verbosity level to <i>debug-level</i>. The default level is zero. Note that the short option is <tt>-D</tt>, an uppercase letter D. See also the <tt>-d, --debug-level</tt> option.</dd>
- <dt><tt>-h <i>delay</i>, --headspace <i>delay</i></tt></dt>
- <dd>Specify the <i>delay</i> in milliseconds between outgoing queries, defaulting to 10. <tt>sntp</tt> sends queries to all provided hostnames/addresses in short succession, and by default terminates once the first valid response is received. With multiple time sources provided, all but one will not be used. To limit the number of queries whose responses will not be used, each query is separated from the preceding one by <i>delay</i> milliseconds, to allow time for responses to earlier queries to be received. A larger <i>delay</i> reduces the query load on the time sources, increasing the time to receive a valid response if the first source attempted is slow or unreachable.</dd>
+ <dt><tt>-g <i>delay</i>, --gap <i>delay</i></tt></dt>
+ <dd>Specify the <i>delay</i> in milliseconds between outgoing queries, defaulting to 50. <tt>sntp</tt> sends queries to all provided hostnames/addresses in short succession, and by default terminates once the first valid response is received. With multiple time sources provided, all but one will not be used. To limit the number of queries whose responses will not be used, each query is separated from the preceding one by <i>delay</i> milliseconds, to allow time for responses to earlier queries to be received. A larger <i>delay</i> reduces the query load on the time sources, increasing the time to receive a valid response if the first source attempted is slow or unreachable.</dd>
<dt><tt>-K <i>kodfile</i>, --kod <i>kodfile</i></tt></dt>
<dd>Specifies the filename <i>kodfile</i> to be used for the persistent history of KoD (Kiss Of Death, or rate-limiting) responses received from servers. The default is <tt>/var/db/ntp-kod</tt>. Note that the short option is <tt>-K</tt>, an uppercase letter K.</dd>
<dt><tt>-k <i>keyfile</i>, --keyfile <i>keyfile</i></tt></dt>
More information about the bk-ntp-dev-send
mailing list