* [Bug 1691] Use first NMEA sentence each second.
* Put the sntp tests under sntp/ .
* ... and only build/run them if we have gtest.
+* Documentation updates from Dave Mills.
(4.2.7p75) 2010/10/30 Released by Harlan Stenn <stenn@ntp.org>
* Documentation updates from Dave Mills.
* Include Linus Karlsson's GSoC 2010 testing code.
color: #FF0000;
font-weight: bold;
}
+.style1 {color: #FF0000}
-->
</style>
</head>
<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 -->28-Oct-2010 17:34<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->31-Oct-2010 4:18<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
</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.</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 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 key and key identifier 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>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 defines a scheme properly described as <em>symmetric key cryptography</em>. It uses 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 key and key identifier 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 "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 used when the distribution is built. Public key cryptography is generally 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>In addition to the symmetric key algorithms, 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 used when the distribution is built.</p>
+<p> Public key cryptography is generally 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>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, 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 "letterbomb" 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>
+<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 "letterbomb" 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>restrict</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 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>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 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>
+<p>Figure 1 shows a typical keys file used by the reference implementation. In the case of MD5, the key consists of 16 characters randomized over the ASCII printing codes The string can be edited later for a password, for instance as <tt>2late4Me</tt> for key ID 10. For message digest algorithms other than MD5, the key is a 20-octet 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>
<p>Microsoft Windows Authentication</p>
<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 -->14-Oct-2010 22:27<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->31-Oct-2010 3:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<dt id=automax><tt>automax [<i>logsec</i>]</tt></dt>
<dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol, as a power of 2 in seconds. Note that the size of the key list for each association depends on this interval and the current poll interval. The default interval is 12 (about 1.1 h). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information.</dd>
<dt id="controlkey"><tt>controlkey <i>keyid</i></tt></dt>
- <dd>Specifies the key ID
to use with the <a
+ <dd>Specifies the key ID
for the <a
href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the
standard protocol defined in RFC-1305. The <tt><i>keyid</i></tt> argument is the key ID for a <a href="#trustedkey">trusted
key</a>, where the value can be in the range 1 to 65534,
inclusive.</dd>
- <dt id="crypto"><tt>crypto [randfile <i>file</i>] [host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>]</tt></dt>
- <dd>This command requires the OpenSSL library. It activates public key cryptography
+ <dt id="crypto"><tt>crypto [digest</tt> <em><tt>digest</tt></em><tt>]</tt> <tt>[host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>] [randfile <i>file</i>]</tt></dt>
+ <dd>This command activates the Autokey public key cryptography
and loads the required host key and public certificate. If one or more files
are left unspecified, the default names are used as described below. Unless
the complete path and name of the file are specified, the location of a file
command or default <tt>/usr/local/etc</tt>. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information. Following are the options.</dd>
<dd>
<dl>
- <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 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,
+ <dt><tt>digest</tt> <em><tt>digest</tt></em></dt>
+ <dd> </dd>
+ <dd>Specify the message digest algorithm, with default MD5. If the OpenSSL library
+ is installed, <tt><i>digest</i></tt> can be be any message digest algorithm supported
+ by the library. The current selections are: <tt>MD2</tt>, <tt>MD4</tt>, <tt>MD5,</tt> <tt>MDC2</tt>, <tt>RIPEMD160</tt>, <tt>SHA</tt> and <tt>SHA1</tt>. All
+ participants in an Autokey subnet must use the same algorithm. The Autokey message digest algorithm is separate and distinct from the symmetric
+ key message digest algorithm. 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>
<dd>Specifies the string used when constructing the names for the host, sign
<dd>Specifies the location of the random seed file used by the OpenSSL library. The defaults are described on the <tt>ntp-keygen</tt> page.</dd>
</dl>
</dd>
- <dt id="keys"><tt>keys <i>keyfile</i></tt></dt>
- <dd>Specifies the complete path to the MD5 key file containing the keys and key IDs used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option. Note that the directory path for Autokey media is specified by the <tt>keysdir</tt> command.</dd>
+ <dt id="keys"><tt>keys <i>path</i></tt></dt>
+ <dd>Specifies the complete directory path for the key file containing the key IDs, key types and keys used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option. Note that the directory path for Autokey cryptographic media is specified by the <tt>keysdir</tt> command.</dd>
<dt id="keysdir"><tt>keysdir <i>path</i></tt>K</dt>
- <dd>This command specifies the default directory path for Autokey cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>. Note that the path for the symmetric keys file is specified by the <tt>keys</tt> command.</dd>
+ <dd>Specifies the complete directory path for the Autokey cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>. Note that the path for the symmetric keys file is specified by the <tt>keys</tt> command.</dd>
<dt id="requestkey"><tt>requestkey <i>keyid</i></tt></dt>
- <dd>Specifies the key ID
to use with the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which
+ <dd>Specifies the key ID
for the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which
uses a proprietary protocol specific to this implementation of <tt>ntpd</tt>. The <tt><i>keyid</i></tt> argument is a key ID
for a <a href="#trustedkey">trusted key</a>, in the range 1 to
65534, inclusive.</dd>
<dt id="revoke"><tt>revoke [<i>logsec</i>]</tt></dt>
- <dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds.
This command is available only if the AUtokey public key support has been enabled. See the <a href="autokey.html">Autokey Public-Key Authentication</a>a page for further information.</dd>
+ <dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. See the <a href="autokey.html">Autokey Public-Key Authentication</a>a page for further information.</dd>
<dt id="trustedkey"><tt>trustedkey [<i>keyid</i> | (<i>lowid</i> ... <i>highid</i>)] [...]</tt></dt>
<dd>Specifies the key ID(s) which are trusted for the purposes of
authenticating peers with symmetric key cryptography. Key IDs
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Sep-2010 3:22<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->31-Oct-2010 4:38<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
</ul>
<hr>
<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 used when the distribution is built. Public key cryptography is generally 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> 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 MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. 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. These schemes provide strong security against replay with or without message modification, spoofing, masquerade and most forms of clogging attacks. These schemes 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>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 used when the distribution is built.</p>
+<p> Public key cryptography is generally 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> 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 algorihtms such as MD5 and SHA and verifies the source using any of several digest/signature schemes. 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. These schemes provide strong security against replay with or without message modification, spoofing, masquerade and most forms of clogging attacks. These schemes 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 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 are operated outside firewall perimeters.</p>
-<p>There are three timeouts associated with the Autokey scheme. The key list timeout, which defaults to about 1.1 h, specifies the interval between generating new key lists. The revoke timeout, which defaults to about 36 h, specifies the interval between generating new private values. The restart timeout, with default about 5 d, specifies the interval between protocol restarts to refresh public values. In general, the behavior when these timeouts expire is not affected by the issues discussed on this page.</p>
+<p>There are three timeouts associated with the Autokey scheme. The key list timeout, which defaults to about 1.1 h, specifies the interval between generating new key lists. The revoke timeout, which defaults to about 36 hr, specifies the interval between generating new private values. The restart timeout, with default about 5 d, specifies the interval between protocol restarts to refresh public values. In general, the behavior when these timeouts expire is not affected by the issues discussed on this page.</p>
<h4 id="group">NTP Secure Groups</h4>
<p>NTP secure groups are used to define cryptographic compartments and security
hierarchies. All hosts belonging to a secure group have the same group name
of the <tt>crypto</tt> command is the group name of all group hosts and the
name used in the identity files. The file naming conventions are described on
the <a href="keygen.html">ntp-keygen</a> page.</p>
-<p>Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The group name is used in the subject and issuer fields of the TH self-signed trusted certificate for these hosts. The host name is used in the subject and issuer fields of the self-signed certificates for all other hosts.</p>
-<p>All group hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts and ending at a TH. When a host starts up, it recursively retrieves the certificates along the trail in order to verify group membership and avoid masquerade and middleman attacks.</p>
-<p>Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. A certificate trail consist of a chain of hosts starting at a client, leading through secondary servers of progressively lower stratum and ending at a TH. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.</p>
+<p>Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The group name is used in the subject and issuer fields of the TH self-signed trusted certificate for these hosts. The host name is used in the subject and issuer fields of the self-signed certificates for all other hosts in the group.</p>
+<p>All group hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts, and ending at a TH. When a host starts up, it recursively retrieves the certificates along the trail to the TH in order to verify group membership and avoid masquerade and middleman attacks.</p>
+<p>Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. In a typical scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.</p>
<h4 id="ident">Identity Schemes and Cryptotypes</h4>
-<p>All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page.</p>
+<p>All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three
optional identity schemes, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page.</p>
<p>A specific combination of authentication and identity schemes is called a
- cryptotype, which applies to clients and servers separately. A group can be
+ <em>cryptotype</em>, which applies to clients and servers separately. A group can be
configured using more than one cryptotype combination, although not all combinations
are interoperable. Note however that some cryptotype combinations may successfully
intemperate with each other, but may not represent good security practice. The
<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 -->12-Sep-2010 3:36<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->30-Oct-2010 3:19<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
<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 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
- ten pseudo-random printable ASCII strings suitable for the MD5 message digest algorithm included in the distribution. If the OpenSSL library is installed, it produces an additional ten hex-encoded random bit strings suitable for the SHA1 and other message digest algorithms. Printable ASCII keys can have length from one to 20 characters, inclusive. Bit string keys have length 20 octets (40 hex characters). All keys are 160 bits in length.</p>
+ ten pseudo-random printable ASCII strings suitable for the MD5 message digest algorithm included in the distribution. If the OpenSSL library is installed, it produces an additional ten hex-encoded random bit strings suitable for the SHA1 and other message digest algorithms. Printable ASCII keys can have length from one to 20 characters, inclusive. Bit string keys have length 20 octets (40 hex characters).</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.</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>
<p> The file can be edited later with
purpose-chosen passwords for the <tt>ntpq</tt> and <tt>ntpdc</tt> programs.
- Each line of the file contains three fields, first an integer between 1 and 65534, inclusive, representing the key identifier used in the <tt>server</tt> and <tt>peer</tt> configuration commands. Next is the key type for the message digest algorithm, which in the absence of the OpenSSL library should be the string <tt>MD5</tt> to designate the MD5 message digest algorithm. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by that library. However, if compatibility with FIPS 140-2 is required, the key type must be either <tt>SHA</tt> or <tt>SHA1</tt>.Finally is the key itself as a printable ASCII string excluding the space and # characters. If not greater than 20 characters in length, the string is the key itself; otherwise, it is interpreted as a hex-encoded bit string. As is custom, # and the remaining characters on the line are ignored. Later, this file can be edited to include the passwords for the <tt>ntpq</tt> and <tt>ntpdc</tt> utilities. If this is the only need, run <tt>ntp-keygen</tt> with the <tt>-M</tt> option and disregard the remainder of this page. </p>
+ Each line of the file contains three fields, first an integer between 1 and 65534, inclusive, representing the key identifier used in the <tt>server</tt> and <tt>peer</tt> configuration commands. Next is the key type for the message digest algorithm, which in the absence of the OpenSSL library must be the string <tt>MD5</tt> to designate the MD5 message digest algorithm. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by that library. However, if compatibility with FIPS 140-2 is required, the key type must be either <tt>SHA</tt> or <tt>SHA1</tt>. Finally is the key itself as a character printable ASCII string excluding the space and # characters. If not greater than 20 characters in length, the string is the key itself; otherwise, it is interpreted as a hex-encoded bit string. As is custom, # and the remaining characters on the line are ignored. Later, this file can be edited to include the passwords for the <tt>ntpq</tt> and <tt>ntpdc</tt> utilities. If this is the only need, run <tt>ntp-keygen</tt> with the <tt>-M</tt> option and disregard the remainder of this page. </p>
<p>The remaining generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.</p>
<p>Most files used by this program are encrypted using a private password. The <tt>-p</tt> option specifies the password for local files and the <tt>-q</tt> option the password for files sent to remote sites. If no local password is specified, the host name returned by the Unix <tt>gethostname()</tt> function, normally the DNS name of the host, is used. If no remote password is specified, the local password is used.</p>
<p>The <tt>pw</tt> option of the <tt>crypto</tt> configuration command specifies the read password for previously encrypted files. This must match the local password used by this program. If not specified, the host name is used. Thus, if files are generated by this program without password, they can be read back by <tt>ntpd</tt> without password, but only on the same host.</p>
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/stamp.html'>Timestamp Capture Principles</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/onwire.html'>Analysis and Simulation of the NTP On-Wire Protocols</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/proximity.html'>Time Synchroization for Space Data Links</a></li>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/security.html'>NTP Security Analysis</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autocfg.html'>Autonomous Configuration</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autokey.html'>Autonomous Authentication</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/proto.html'>Autokey Protocol</a></li>\
projects / thirdparty / ntp.git / commitdiff
