]> git.ipfire.org Git - thirdparty/ntp.git/commitdiff
Documentation updates from Dave Mills
authorHarlan Stenn <stenn@ntp.org>
Fri, 29 Oct 2010 08:56:14 +0000 (04:56 -0400)
committerHarlan Stenn <stenn@ntp.org>
Fri, 29 Oct 2010 08:56:14 +0000 (04:56 -0400)
bk: 4cca8c2ewm2tPxPRVGGmDWYjCdD92A

ChangeLog
html/authentic.html

index d0d6af290cadd10adf65a9020d8f9919485c10fc..b1cddf675d5e63fd37e8e54b378c717e571c63a7 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,6 @@
 * [Bug 1685] from 4.2.6p3-RC8: NMEA driver mode byte confusion.
 * from 4.2.6p3-RC8: First cut at using scripts/checkChangeLog.
+* Documentation updates from Dave Mills.
 (4.2.7p73) 2010/10/27 Released by Harlan Stenn <stenn@ntp.org>
 * [Bug 1680] Fix alignment of clock_select() arrays.
 * refinements to new startup behavior from David Mills.
index 6264eb1e0a9cab9b3c20d6f24fb97a41b2c274d5..9a5948170179d61cef454cc418fd4ab9daf85fd0 100644 (file)
@@ -19,7 +19,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 -->02-Oct-2010  23:55<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->28-Oct-2010  17:34<!-- #EndDate -->
   UTC</p>
 <br clear="left">
 <h4>Related Links</h4>
@@ -43,10 +43,17 @@ required.</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, and the options described on this 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, authentication is required only for those packets that might require significant resources, such as broadcast, symmetric active or manycast server packets, as these represent a potential clogging vulnerability. In the current climate of targeted broadcast or &quot;letterbomb&quot; attacks, defeating this requirement would be decidedly dangerous. However, it can be defeated  using the <tt>disable auth</tt> command. Authentication is also an access control option using the <tt>restric</tt> command and the <tt>notrust</tt> flag.</p>
 <h4 id="symm">Symmetric Key Cryptography</h4>
-<p>The original RFC-1305 specification allows any one of possibly 65,534 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, key ID and key type to authenticate NTP packets. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key.  The digest is computed directly from the concatenation of the key string followed by the packet contents with the exception of the MAC itself.</p>
+<p>The original RFC-1305 specification allows any one of possibly 65,534 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, the reference implementation appends a message authentication code (MAC)  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 secret key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the 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 this happens at 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, 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. The program generates pseudo-random keys, one key for each line. Each line consists of three fields, the key identifier as a decimal number from 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>
+<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.  In the case of MD5, the key is restricted to ASCII printing characters, either a given string, such as <tt>2late4Me</tt> for key ID 10, or a random string. In other digest algorithms the key is a random hex string.</p>
+<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>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>Microsoft Windows Authentication</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="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>