<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->04-Nov-2009 20:57<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->05-Nov-2009 20:12<!-- #EndDate -->
UTC</p>
<br clear="left">
Options</a> page. Details about the automatic server discovery schemes are described
on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. Additional
information is available in the papers, reports, memoranda and briefings
- on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.
- Note that in the native version support is available only for symmetric key
- cryptography using the MD5 message digest algorithm. If the OpenSSL cryptographic
- library is installed, support is available for symmetric key cryptography
- and all the algorithms supported by this library. Note however, if conformance
- to FIPS 140-2 is required, only a limited subset of these algorithms is available.</p>
-
-<p>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. The NTPv3 specification RFC-1305 defines a scheme using the Data Encryption Standard (DES) algorithm, commonly called DES-CBC. Subsequently, this scheme 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 key as the server.</p>
-
-<p>NTPv4 includes the NTPv3 scheme, properly described as symmetric key cryptography and, in addition a new scheme based on public key cryptography and called Autokey. 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, utility programs in the OpenSSL software library or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
+ cited on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.
+ 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.</p>
+
+<p> The NTPv3 specification RFC-1305 defines a scheme properly described as
+ symmetric key cryptography. It uses the Data Encryption Standard (DES)
+ algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this
+ scheme 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 key and key identifier
+ as the server. If the OpenSSL cryptographic library is installed, support
+ is available for all algorithms included in the library. Note however, if
+ conformance to FIPS 140-2 is required, only a limited subset of these algorithms
+ is available.</p>
+
+<p>NTPv4 includes the NTPv3 scheme, properly called symmetric key cryptography,
+ and in addition a new scheme based on public key cryptography and called
+ Autokey. 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, utility programs in the OpenSSL software library
+ or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility
+ program in the NTP software distribution.</p>
<p>While the algorithms for symmetric key cryptography are included in the NTPv4 software distribution, Autokey cryptography requires the OpenSSL software library to be installed before building the NTP distribution. 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>Note that according to US law, NTP binaries including OpenSSL library components,
- notwithstanding the OpenSSL library itself, cannot be exported outside the
+ 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>
+ 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, 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>
<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 and key ID 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.</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, 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.</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 using an ordinary text editor.</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 65534 inclusive,
+ a key type chosen from the keywords of the <tt>digest</tt> option of the <tt>crypto</tt> command,
+ and a 16-character printable ASCII string as the key itself.</p>
<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>
<p>By default, the message digest algorithm is MD5 selected by the key type
- "M" in the keys file. However, if the OpenSSL library is installed,
+ <tt>M</tt> in the keys file. However, if the OpenSSL library is installed,
any message digest algorithm supported by that library can be used. The key
type is selected as the algorithm name given in the OpenSSL documentation.
- The ley type is associated with the key and can be diffeent for each key
- separately. Note of course that both the server and client
- must share the same key and key type. Note that if conformance to FIPS 140-2
- is required, the message digest algorithm must conform to the Secure Hash
- Standard (SHS), which requires an algorithm from the Secure Hash Algorith
- (SHA) family, and the digital signature encryption algorithm must
- conform to the Digital Signature Standard (DSS), which requires the Digital
- Signature Algorithm (DSA) family.</p>
+ The key type is associated with the key and can be different for different
+ keys. The server and client
+ must share the same key, key ID and key type and both must be trusted. Note
+ that if conformance to FIPS 140-2 is required, the message digest algorithm
+ must conform to the Secure Hash Standard (SHS), which requires an algorithm
+ from the Secure Hash Algorithm (SHA) family, and the digital signature encryption
+ algorithm, if used, must conform to the Digital Signature Standard (DSS),
+ which requires the Digital Signature Algorithm (DSA).</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.
<dd><dl>
-<dt><tt>digest <i>name</i></tt></dt>
+<dt><tt>digest</tt> <tt>MD2</tt> | <tt>MD4</tt> | <tt>MD5</tt> | <tt>MDC2</tt> | <tt>RIPEMD160</tt> | <tt>SHA</tt> | <tt>SHA1</tt></dt>
<dd>Specify the message digest algorithm, with default MD5. If the OpenSSL library
is installed, <tt><i>name</i></tt> can be be any message digest algorithm supported
by the library not exceeding 160 bits in length. However, all Autokey
- participants in a Autokey subnet must use the same algorithm. Note that the
- Autokey message digest algorithm is separate and distinct form the symmetric
- key message digest algorithms. Note: If compliance with FIPS 140-2 is required, <tt><i>name</i></tt> must
+ participants in an Autokey subnet must use the same algorithm. Note that
+ the Autokey message digest algorithm is separate and distinct form the symmetric
+ key message digest algorithms. Note: If compliance with FIPS 140-2 is required, the algorithm must
be ether <tt>SHA</tt> or <tt>SHA1</tt>.</dd>
<dt><tt>host <i>name</i></tt></dt>
projects / thirdparty / ntp.git / commitdiff
