Fix ntp multiple vulnerabilities.

Approved by:	so

3 files changed, 24 insertions, 24 deletions

diff --git a/contrib/ntp/html/authentic.html b/contrib/ntp/html/authentic.html
index ecfb466..e529a6d 100644
--- a/contrib/ntp/html/authentic.html
+++ b/contrib/ntp/html/authentic.html
@@ -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 -->1-Dec-2012  04:44<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->5-Feb-2016  09:13<!-- #EndDate -->
   UTC</p>
 <br clear="left">
 <h4>Related Links</h4>
@@ -35,28 +35,28 @@ color: #FF0000;
 </ul>
 <hr>
 <h4 id="auth">Introduction</h4>
-<p>This page describes the various cryptographic authentication provisions in NTPv4. Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. A detailed discussion of the NTP multi-layer security model and vulnerability analysis is in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>.</p>
-<p> The NTPv3 specification (RFC-1305) defined an authentication scheme properly described as <em>symmetric key cryptography</em>. It used the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same message digest as the server. The MD5 message digest algorithm is included in the distribution, so without further cryptographic support, the distribution can be freely exported.</p>
-<p>If the OpenSSL cryptographic library is installed prior to building the distribution, all message digest algorithms included in the library may be used, including SHA and SHA1.   However, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms can be used. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and  build process automatically detects the library and links the library routines
+<p>This page describes the various cryptographic authentication provisions in NTPv4.  Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server.  A detailed discussion of the NTP multi-layer security model and vulnerability analysis is in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>.</p>
+<p> The NTPv3 specification (RFC-1305) defined an authentication scheme properly described as <em>symmetric key cryptography</em>.  It used the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode.  Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5.  Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same message digest as the server.  The MD5 message digest algorithm is included in the distribution, so without further cryptographic support, the distribution can be freely exported.</p>
+<p>If the OpenSSL cryptographic library is installed prior to building the distribution, all message digest algorithms included in the library may be used, including SHA and SHA1.  However, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms can be used.  This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page.  Once installed, the configure and build process automatically detects the library and links the library routines
 required.</p>
-<p>In addition to  the symmetric key algorithms, this distribution includes support for the  Autokey public key algorithms and protocol specified in RFC-5906 &quot;Network Time Protocol Version 4: Autokey Specification&quot;. This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option   is used when the distribution is built.</p>
-<p> Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services,  the OpenSSL application program, or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
-<p>Note that according to US law, NTP binaries including OpenSSL library components, including the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commerce. Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.</p>
-<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. 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>
-<p>By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server  responds with  authenticated packets if correct, or a crypto-NAK packet if not.. In the case of unsolicited packets which might consume significant resources, such as broadcast or symmetric mode  packets, , authentication is required, unless overridden by a <tt>disable auth</tt> command.  In the current climate of targeted broadcast or &quot;letterbomb&quot; attacks, defeating this requirement would be decidedly dangerous. In any case, the <tt>notrust </tt>flag,  described on the <a href="authopt.html">Access Control Options</a> page, can be used to disable access to all but correctly authenticated clients..</p>
+<p>In addition to the symmetric key algorithms, this distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 &quot;Network Time Protocol Version 4: Autokey Specification&quot;.  This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is used when the distribution is built.</p>
+<p> Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed.  Autokey uses X.509 public certificates, which can be produced by commercial services, the OpenSSL application program, or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
+<p>Note that according to US law, NTP binaries including OpenSSL library components, including the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commerce.  Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.</p>
+<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page.  The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes.  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>
+<p>By default, the client sends non-authenticated packets and the server responds with non-authenticated packets.  If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not.  In the case of unsolicited packets which might consume significant resources, such as broadcast or symmetric mode packets, authentication is required, unless overridden by a <tt>disable auth</tt> command.  In the current climate of targeted broadcast or &quot;letterbomb&quot; attacks, defeating this requirement would be decidedly dangerous.  In any case, the <tt>notrust </tt>flag, described on the <a href="authopt.html">Access Control Options</a> page, can be used to disable access to all but correctly authenticated clients.</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 MACs 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-NAK.</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, and a  message digest key consisting of a printable ASCII string less than 40 characters, or a 40-character hex digit string. If the OpenSSL library is installed, the key type  can be any message digest algorithm supported by the  library.   If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
+<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 MACs 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-NAK.</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 or four fields: a key ID in the range 1 to 65,534, inclusive, a key type, a message digest key consisting of a printable ASCII string less than 40 characters or a 40-character hex digit string, and an optional comma-separated list of IPs that are allowed to serve time.  If the OpenSSL library is installed, the key type can be any message digest algorithm supported by the library.  If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
 <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 when the OpenSSL library is installed.   In this figure, for key IDs in he range 1-10, the  key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is  a 40-character hex digit string.   The key  is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field.  The key can be  change  to a  password,  such as   <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</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>
+<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed.  In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string.  For key IDs in the range 11-20, the key is a 40-character hex digit string.  The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type.  The line can be edited later or new lines can be added to change any field.  The key can be change to a password, such as <tt>2late4Me</tt> for key ID 10.  Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</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 id="windows">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="accopt.html#restrict">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>
+<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="accopt.html#restrict">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>
 <hr>
diff --git a/contrib/ntp/html/monopt.html b/contrib/ntp/html/monopt.html
index acf4847..82dd8ba 100644
--- a/contrib/ntp/html/monopt.html
+++ b/contrib/ntp/html/monopt.html
@@ -11,7 +11,7 @@
 <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html"></a> from <i>Pogo</i>, Walt Kelly</a>
 <p>Pig was hired to watch the logs.</p>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->31-Jan-2014  06:54<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->14-Feb-2016  09:38<!-- #EndDate -->
     UTC</p>
 <br clear="left">
 <h4>Related Links</h4>
@@ -295,7 +295,7 @@
   <dd>The status field is encoded in hex format as described in Appendix B of
     the NTP specification RFC 1305.</dd>
   <dt><tt>protostats</tt></dt>
-  <dd>Record significant peer, system and [rptpcp; events. Each significant event
+  <dd>Record significant peer, system and protocol events. Each significant event
     appends one line to the <tt>protostats</tt> file set:</dd>
   <dd><tt>49213 525.624 128.4.1.1 963a 8a <i>message</i></tt></dd>
   <dd>
diff --git a/contrib/ntp/html/xleave.html b/contrib/ntp/html/xleave.html
index 417185c..8f532f8 100644
--- a/contrib/ntp/html/xleave.html
+++ b/contrib/ntp/html/xleave.html
@@ -11,17 +11,17 @@
 <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
 <p>You need a little magic.</p>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->10-Mar-2014  05:25<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->6-Feb-2016  07:17<!-- #EndDate -->
     UTC</p>
 <br clear="left">
 <hr>
-<p>In the protocol described in the NTP specification and reference implementation up to now, the transmit timestamp, which is captured before the message digest is computed and the packet  queued for output,  is properly called as a <em>softstamp</em> The receive timestamp, which is captured after the input driver interrupt routine and before  the packet is queued for input,  is properly called  a <em>drivestamp</em>.  For enhanced accuracy it is desirable to capture the transmit timestamp  as close to the wire as possible; for example, after the output driver interrupt routine.</p>
-<p> In other words, we would like to replace the transmit softstamp with a drivestamp, but the problem is the transmit drivestamp is available only after the packet has been sent. A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation. In interleaved modes the transmit drivestamp for one packet is actually carried in the immediately following packet. The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.</p>
-<p> The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine. In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies. The difference between the two timestamps, which is  called the interleaved or output delay, varies from 16 &mu;s for a dual-core Pentium  running FreeBSD 6.1 to 1100 &mu;s for a Sun Blade 1500 running Solaris 10.</p>
+<p>In the protocol described in the NTP specification and reference implementation up to now, the transmit timestamp, which is captured before the message digest is computed and the packet queued for output, is properly called as a <em>softstamp</em>.  The receive timestamp, which is captured after the input driver interrupt routine and before the packet is queued for input, is properly called a <em>drivestamp</em>.  For enhanced accuracy it is desirable to capture the transmit timestamp as close to the wire as possible; for example, after the output driver interrupt routine.</p>
+<p> In other words, we would like to replace the transmit softstamp with a drivestamp, but the problem is the transmit drivestamp is available only after the packet has been sent.  A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation.  In interleaved modes the transmit drivestamp for one packet is actually carried in the immediately following packet.  The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.</p>
+<p> The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine.  In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies.  The difference between the two timestamps, which is called the interleaved or output delay, varies from 16 &mu;s (microseconds) for a dual-core Pentium running FreeBSD 6.1 to 1100 &mu;s (microseconds) for a Sun Blade 1500 running Solaris 10.</p>
 <p>Interleaved mode can be used only in NTP symmetric and broadcast modes.
   It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> configuration
-commands. A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary  and interleaved broadcast clients can use the same packets. An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in  interleaved mode. </p>
-<p>As demonstrated in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>, the interleaved modes have the same resistance to  lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper <a href="http://www.eecis.udel.edu/~mills/proximity.html">Time Synchronization for Space Data Links</a>.</p>
+commands.  A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary and interleaved broadcast clients can use the same packets.  An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in interleaved mode.</p>
+<p>As demonstrated in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes.  An application of the interleaved symmetric mode in space missions is presented in the white paper <a href="http://www.eecis.udel.edu/~mills/proximity.html">Time Synchronization for Space Data Links</a>.</p>
 <hr>
 <div align="center"> <img src="pic/pogo1a.gif" alt="gif"> </div>
 <br>