<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->15-Jan-2011 21:26<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Feb-2011 10:36<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a></li>
- <li class="inline"><a href="#group">NTP Secure Groups</a></li>
+ <li class="inline"><a href="#subnet">Autokey Subnets</a></li>
+ <li class="inline"><a href="#names">Subnet Group Names's</a></li>
+ <li class="inline"><a href="#secure">Secure Groups</a></li>
+ <li class="inline"><a href="#cfg">Configuration - Authentication Schemes</a></li>
+ <li class="inline"><a href="#scfg">Configuration - Identity Schemes</a></li>
<li class="inline"><a href="#ident">Identity Schemes and Cryptotypes</a></li>
- <li class="inline"><a href="#cfg">Configuration</a></li>
- <li class="inline"><a href="#exam">Examples</a></li>
+ <li class="inline"><a href="#files">Files</a></li>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
<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 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="cert">Autokey Subnets</h4>
+<h4 id="subnet">Autokey Subnets</h4>
<p> An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. Note that the requirement that the NTP subnet be acyclic means that, if two hosts are configured with each other in symmetric modes, each must be a TH. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or one or more trusted agents (TAs) of a parent subnet. NTP subnets can be nested, with the THs of a child subnet configured for one or more TAs of a parent subnet. The TAs can serve one or more child subnets, each with its own security policy and set of THs.</p>
<p>A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. The requirement that the subnet be acyclic means certificate trails can never loop. NTP servers operate as certificate authorities (CAs) to sign certificates provided by their clients. The CAs include the TAs of the parent subnet and those subnet servers with dependent clients.</p>
<p> In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired.</p>
</div>
<p>Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Alice and Helen are parent groups for Carol with TA C belonging to Alice and TA S belonging to Helen. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server, child subnet TH X has two mobilized associations, one to Alice TA host C and the other to Carol TA host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.</p>
<p>Note that host D certificate trail is D→C→A or D→C→B, depending on the particular order the trails are built. Host Y certificate trail is only Y→X, since X is a TH. Host X has two certificate trails X→C→A or X→C→B, and X→S→R.</p>
-<h4 ident="names">Subnet Group Names</h4>
-<p>In some configurations where more than one subnet shares an Ethernet or when multiple subnets exist in a manycast or pool configuration, it is useful to isolate one subnet from another. In Autokey this can be done using subnet group names. An Autokey host name is specified by the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program using the syntax <tt><em>host</em>@<em>group</em></tt>, where <em><tt>host</tt></em> is the host name and <em><tt>group</tt></em> is the optional subnet group name. If <em><tt>host</tt></em> is omitted, the host name defaults to the string returned by the Unix <tt>gethostname()</tt> routine. Thus, for host <tt>beauregard.udel.edu</tt> the option <tt>-s @red</tt> specifies the Autokey host name <tt>beauegard.udel.edu@red</tt>.</p>
+<h4 id="names">Subnet Group Names</h4>
+<p>In some configurations where more than one subnet shares an Ethernet or when multiple subnets exist in a manycast or pool configuration, it is useful to isolate one subnet from another. In Autokey this can be done using group names. An Autokey host name is specified by the <tt>-s</tt><tt><em> host</em>@<em>group</em></tt> option of the <tt>ntp-keygen</tt> program, where <em><tt>host</tt></em> is the host name and <em><tt>group</tt></em> is the group name. If <em><tt>host</tt></em> is omitted, the name defaults to the string returned by the Unix <tt>gethostname()</tt> routine, ordinarily the DNS name of the host. Thus, for host <tt>beauregard.udel.edu</tt> the option <tt>-s @red</tt> specifies the Autokey host name <tt>beauegard.udel.edu@red</tt>.</p>
<p>A subnet host with a given group name will discard ASSOC packets from all subnets with a different group name. This effectively disables the Autokey protocol without additional packet overhead. For instance, one or more manycast or pool servers will not respond to ASSOC packets from subnets with difference group names. Groups sharing an Ethernet will be filtered in the same way.</p>
-<p>However, as shown in Figure 1, there are configurations where a TH of one group needs to listen to a TA of a different group. This is accomplished using the <tt>ident</tt> option of the <tt>crypto</tt> command and/or the <tt>ident</tt> option of the <tt>server</tt> command. The former case applies to all hosts sharing a common broadcast, manycast or symmetric passive modes, while the latter case applies to each individual client/server or symmetric active mode association. In either case the host listens to the specified group name in addition to the group name specified in the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program.</p>
-<h4 id="group">NTP Secure Groups</h4>
+<p>However, as shown in Figure 1, there are configurations where a TH of one group needs to listen to a TA of a different group. This is accomplished using the <tt>ident <em>group</em></tt> option of the <tt>crypto</tt> command and/or the <tt>ident <em>group</em></tt> option of the <tt>server</tt> command. The former case applies to all hosts sharing a common broadcast, manycast or symmetric passive modes, while the latter case applies to each individual client/server or symmetric active mode association. In either case the host listens to the specified group name in addition to the group name specified in the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program.</p>
+<h4 id="secure">Secure Groups</h4>
<p>NTP security groups are an extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page. NTP secure groups are used to define cryptographic compartments and security
hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.</p>
<p> An NTP secure group is an NTP subnet configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. They run an identity exchange with the TAs of parent subnets All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. The TH verifies authenticity with the TA of the parent subnet using an identity exchange.</p>
<div align="center"><img src="pic/flt9.gif" alt="gif">
<p>Figure 2. Identify Scheme</p>
</div>
-<p>The identity exchange is run between a TA acting as a server and a TH acting as a client. As shown in Figure 2, the identity exchange involves a challenge-response protocol where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.</p>
+<p>The identity exchange is run between a TA acting as a server and a TH acting as a client. As shown in Figure 2, the identity exchange involves a challenge-response protocol where a client generates a nonce and sends it to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.</p>
<p> Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secret group key to persist long after the longest period of certificate validity. In the Schnorr (Identify Friend or Foe - IFF) scheme, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.</p>
<p>As described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted server keys file and a nonencrypted client keys file, also called the parameters file, which usually contains a subset of the keys file.</p>
<p> Figure 2 shows how keys and parameters are distributed to servers and clients. A TA constructs the encrypted keys file and the nonencrypted parameters file. Hosts with no dependent clients can retrieve client parameter files from an
- archive or web page. The <tt>ntp-keygen</tt> program can export parameter files using the <tt>-e</tt> option. By convention, the file name is the name of the secure group and must match the <tt>ident</tt> command option and the <tt>ident</tt> option of the <tt>server</tt> command.</p>
-<p> When more than one TH Is involved in the secure group, it is convenient for the TAs and THs to use the same files. To do this, one of the parent TAs includes the <tt>-i <em>group</em></tt> option on the <tt>ntp-keygen</tt> command line, where <em><tt>group</tt></em> is the name of the child secure group. The <tt>ntp-keygen</tt> program can export server keys files
- using the <tt>-q</tt> option and chosen remote password. The files are installed
- on the TAs and then renamed using the name given as the first line in the file, but without
- the filestamp. The secure group name must match the <tt>ident <em>group</em></tt> option of the <tt>crypto</tt> command for all TAs.</p>
+ archive or web page. The <tt>ntp-keygen</tt> program can export parameter files using the <tt>-e</tt> option. By convention, the file name is the name of the secure group and must match the <tt>ident</tt> option of the <tt>crypto</tt> command or the <tt>ident</tt> option of the <tt>server</tt> command.</p>
+<p> When more than one TH Is involved in the secure group, it is convenient for the TAs and THs to use the same encrypted key files. To do this, one of the parent TAs includes the <tt>-i <em>group</em></tt> option on the <tt>ntp-keygen</tt> command line, where <em><tt>group</tt></em> is the name of the child secure group. The <tt>ntp-keygen</tt> program can export server keys files using the <tt>-q</tt> option and a chosen remote password. The files are installed on the TAs and then renamed using the name given as the first line in the file, but without the filestamp. The secure group name must match the <tt>ident</tt> option for all TAs.</p>
<dl>
<dd><span class="style1">In the latest Autokey version, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></dd>
</dl>
<p>In special circumstances the Autokey message digest algorithm can be changed using the <tt>digest</tt> option of the <tt>crypto</tt> command. The digest algorithm is separate and distinct from the symmetric
key message digest algorithm. If compliance with FIPS 140-2 is required,
-the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.</p>
+ the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.</p>
<p>Example</p>
-<p>Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S run an identity exchange with child group TH X. Both have the same encrypted keys file and X the common parameters file.</p>
-<h4 id="config2">Configuration - Authentication Schemes</h4>
-<p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. <tt>time.nist.gov,</tt> as root:</p>
+<p>Returning to the example of Figure 1, Alice, Helen and Carol run run the Trusted Certificate (TC) scheme, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S run an identity exchange with child subnet TH X. Both have the same encrypted keys file and X the common parameters file.</p>
+<h4 id="cfg">Configuration - Authentication Schemes</h4>
+<p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple.</p>
+<p> Referring to Figure 1, for each TH, A, B, R and X, as root:</p>
<p><tt># cd /usr/local/etc<br>
# ntp-keygen -T</tt></p>
-<p>This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. Include in the <tt>ntp.conf</tt> configuration file something like</p>
-<p><tt># disable kernel<br>
- # server 127.127.18.1 minpoll 12 maxpoll 17 # ACTS modem<br>
- # phone atdt913035547785 atddt913034944774<br>
+<p>and for the other hosts the same commands without the <tt>-T</tt> option. This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. For the THs a trusted certificate is generated; for the others a nontreusted certificate is generated. Include in the <tt>ntp.conf</tt> configuration file for all hosts other than the primary servers, A, B and R, something like</p>
+<p><tt> # server <em>host</em> autokey<br>
# crypto<br>
# driftfile /etc/ntp.drift</tt></p>
-<p>Note the first three lines are specific to the ACTS driver and NIST modem telephone numbers. The second number will be tried if the first times out. Alternatively, any other reference clock can be used, or even another time server.</p>
-<p>For each client, e.g. <tt>grundoon.udel.edu,</tt> as root:</p>
-<p><tt># cd /usr/local/etc<br>
- # ntp-keygen</tt></p>
-<p>(There is no -<tt>T</tt> option). Include in the <tt>ntp.conf</tt> configuration file something like</p>
-<p><tt># server time.nist.gov iburst autokey<br>
- # crypto<br>
- # driftfile /etc/ntp.drift</tt></p>
-<p>It is possible to configure clients of server <tt>grundoon.udel.edu</tt> in the same way with the server line pointing to <tt>grundoon.udel.edu</tt>. Dependent clients authenticate to <tt>time.nistg.gov</tt> through <tt>grundoon.udel.edu</tt>.</p>
-<p>In the above configuration examples, the default Autokey host name is the string returned by the Unix <tt>gethostname()</tt> library routine. However, this name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys files. The Autokey host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> command.</p>
-<h4 id="ident">Configuration - Identity Schemes</h4>
-<p> The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. A parent subnet TA generates IFF identity files using an <tt>ntp-keygen </tt> program command with options specified in this section, while the child secure group TH uses the same program command with no options. Both the TA and TH use the <tt>crypto</tt> command with no options. In addition, the TH specifies options for the <tt>server</tt> and <tt>ident</tt> commands as described in this section. </p>
-<p> It's best to start with a functioning TC configuration and add commands as necessary. For example, the TA generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the command</p>
-<p><tt>ntp-keygen -I</tt>.</p>
-<p> Note the TA is not necessarily a trusted host, so may not need the <tt>-T</tt> option. The nonencrypted client parameters can be exported using the command</p>
+<p>where <em><tt>host</tt></em> is the selected server name as shown in the figure. Servers A, B and R are configured for local reference clocks or trusted remoter servers as required.</p>
+<p>In the above configuration examples, the default host name is the string returned by the Unix <tt>gethostname()</tt> routine, ordinarily the DNS name of the host. This name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys file. The host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> configuration command.</p>
+<p>Group names can be added to this configuration by including the <tt>-s <em>host</em>@<em>group</em></tt> option with the <tt>ntp-keygen</tt> program. For the purpose of illustration, the <tt><em>host</em></tt> string is empty, signifying the default host name. For example, @<tt>yellow</tt> can be used for the Alice group, @<tt>orange</tt> for the Helen group and @<tt>blue</tt> for the Carol group. In addition, for TH X the <tt>ident yellow</tt> option should be added to the <tt>server</tt> command for the Alice group and the <tt>ident orange</tt> option should be added to the <tt>server</tt> command for the Helen group.</p>
+<h4 id="scfg">Configuration - Identity Schemes</h4>
+<p> The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. It's best to start with a functioning TC configuration and add commands as necessary. We start with the subnets of Figure 1 configured as in the previous section. Recall that the parent subnet TA for Alice is C and for Helen is S. Each of the TAs generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the <tt>-I</tt> option of the <tt>ntp-keygen</tt> program. Note the TAs are not necessarily trusted hosts, so may not need the <tt>-T</tt> option.</p>
+<p>The nonencrypted client parameters can be exported using the command</p>
<p><tt>ntp-keygen -e ><i>file</i></tt>,</p>
-<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command </p>
+<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command</p>
<p><tt>ntp-keygen -q <em>passw2</em> ><i>file</i></tt>,</p>
-<p>where <em><tt>passwd2</tt></em> is the read password for another TH. While the file name used for the client parameters file is arbitrary, it is common practice to use the subnet group name as described above, such as <tt>red</tt>. On the other hand, the file name used for the keys file must follow the conventions described on the <tt>ntp-keygen</tt> page. The encrypted server keys file is exported to other TAs that may serve the secure group, while the nonencrypted client parameters file can be distributed to all THs by nonsecure means.</p>
-<p>To complete the configuration, the TH includes the client parameters file name as the <tt>ident</tt> option of the the <tt>server</tt> command for the TA association</p>
+<p>where <em><tt>passwd2</tt></em> is the read password for another TA. We won't need this file here.</p>
+<p> While the file names used for the exported files are arbitrary, it is common practice to use the name given as the first line in the file with the filestamp suppressed. Thus, the nonencryted parameters file from each TA is copied to X with this name.</p>
+<p>To complete the configuration, the TH includes the client parameters file name in the <tt>ident</tt> option of the the <tt>server</tt> command for the TA association</p>
<p><tt>server 1.2.3.4 ident <em>group</em>,</tt></p>
-<p> where <em><tt>group</tt></em> is the chosen group name, in this case <tt>red</tt>. In addition, if operating as a broadcast/multicast client or a symmetric passive peer, the TH includes an <tt>ident</tt> command</p>
-<p><tt>ident <em>group</em>,</tt></p>
-<p>where <em><tt>group</tt></em> is the chosen group name, in this case <tt>red</tt>.</p>
-<h4 id="ident2">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 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 <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
- server and client cryptotypes are defined by the the following codes.</p>
+<p> where <em><tt>group</tt></em> is the file name given above. </p>
+<h4 id="ident">Identity Schemes and Cryptotypes</h4>
+<p>A specific combination of authentication and identity schemes is called a <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 server and client cryptotypes are defined by the the following codes.</p>
<dl>
<dt>NONE</dt>
<dd>A client or server is type NONE if authentication is not available or not configured. Packets exchanged between client and server have no MAC.</dd>
<dt>115 protocol error</dt>
<dd>The protocol state machine has wedged due to unexpected restart.</dd>
</dl>
-<h4 id="file">Files</h4>
+<h4 id="files">Files</h4>
<p>See the <a href="keygen.html"><tt>ntp-keygen</tt></a> page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.</p>
<hr>
<p>
<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 -->18-sep-10 3:29<!-- #EndDate -->
+ <!-- #BeginDate format:En1m -->25-feb-11 20:01<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<p>NTP has been under development for almost 30 years, but the paint ain't dry even now. This release of the NTP Version 4 (NTPv4) distribution for Unix, VMS and Windows incorporates new features and refinements, but retaining backwards compatibility with older versions, including NTPv3 and NTPv2, but not NTPv1. Support for NTPv1 has been discontinued because of certain security vulnerabilities.</p>
<h4 id="new">New Features</h4>
<ul>
- <li>The behavior of the daemon at startup has been considerably improved. The time to measure the frequency and correct an initial offset error when started fro the first time is now no more than ten minutes. Upon restart, it takes no more than five minutes to reduce the initial offset to less than one millisecond without adversely affecting the frequency. This avoids a subsequent frequency correction which could take up to several hours.</li>
+ <li>The behavior of the daemon at startup has been considerably improved. The time to measure the frequency and correct an initial offset error when started for the first time is now no more than ten minutes. Upon restart, it takes no more than five minutes to reduce the initial offset to less than one millisecond without adversely affecting the frequency. This avoids a subsequent frequency correction which could take up to several hours.</li>
<li>A new feature called interleaved mode can be used in NTP
symmetric and broadcast modes. It is designed to improve accuracy
- by minimizing errors due to queu
eing and transmission delays. It is described on the <a href="xleave.html">NTP
+ by minimizing errors due to queuing and transmission delays. It is described on the <a href="xleave.html">NTP
Interleaved Modes</a> page.</li>
<li>The huff-n'-puff filter is designed to avoid large errors with DSL circuits and highly asymmetrical traffic, as when downloading large files. Details are on the <a href="huffpuff.html">The Huff-n'-Puff Filter</a> page.</li>
- <li>A new feature called orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It provides rel
able backup in isolated networks or in pr when Internet sources have become unavaillable. See the <a href="orphan.html">Orphan Mode</a> page for further information.</li>
- <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>A new feature called orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It provides rel
iable backup in isolated networks or in pr when Internet sources have become unavailable. See the <a href="orphan.html">Orphan Mode</a> page for further information.</li>
+ <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
routine have been removed from the base distribution. All 128- and 160- bit message digests routines are now supported for both symmetric key and public key cryptosystems. See the <a href="authentic.html">Authetication Support</a> pagefor 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. Additional information about Autokey is on the <a href="autokey.html">Autokey Publid Key Authentication</a> page and links from there.</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>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>
<li>Several new options have been added for the <tt>ntpd</tt> command line. For the inveterate knob twiddlers several of the more important performance variables can be changed to fit actual or perceived special conditions. In particular, the <tt>tinker</tt> and <tt>tos</tt> commands can be used to adjust thresholds, throw switches and change limits.</li>
<li>The <tt>ntpd</tt> daemon can be operated in a one-time mode similar to <tt>ntpdate</tt>, which program is headed for retirement. See the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page for the new features.</li>
+ <li>A number of white papers have been added to the library on the NTP Reseatch Project Page, including:</li>
</ul>
+<script type="text/javascript" language="javascript" src="scripts/external.txt"></script>
<h4 id="change">Changes and Upgrades Since the NTPv3 Version (xntp3-5) </h4>
<ul>
<li>If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is supported in addition to the default support for the IPv4 address family. In contexts where a host name is expected, a <tt>-4</tt> qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a <tt>-6</tt> qualifier forces DNS resolution to the IPv6 namespace.</li>
<body>
<h3>How NTP Works</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->14-Oct-2010 16:45<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->22-Feb-2011 17:55<!-- #EndDate -->
UTC</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/special.txt"></script>
</ul>
<hr>
<h4 id="intro">Introduction and Overview</h4>
-<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in late 2010 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
-<p> The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio and telephone modem. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice.</p>
-<p>This page presents an overview of the NTP daemon included in this distribution. We refer to this daemon as the <em>reference implementation</em> only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
+<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in early 2011 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
+<p> The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio or telephone modem. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice.</p>
+<p>This page presents an overview of the NTP daemon included in this
software distribution. We refer to this daemon as the <em>reference implementation</em> only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<div align="center">
<p><img src="pic/fig_3_1.gif" alt="gif"></p>
<p>Figure 1. NTP Daemon Processes and Algorithms</p>
<p>offset = [(<em>T</em><sub>2</sub> -<em> T</em><sub>1</sub>) + (<em>T</em><sub>3</sub> - <em>T</em><sub>4</sub>)] / 2<br>
delay = (<em>T</em><sub>4</sub> - <em>T</em><sub>1</sub>) - (<em>T</em><sub>3</sub> - <em>T</em><sub>2</sub>).</p>
</div>
-<p>The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page selects the offset and delay samples most likely to produce accurate
time. Those peers that have passed the peer sanity tests of the <a href="decode.html#flash">flash status word</a> are declared <em>selectable</em>. From the selectable population the statistics are used by the algorithm described on the <a href="select.html">Clock Select Algorithm</a> page to determine a number of <em>truechimers</em> according to correctness principles. From the truechimer population the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page determines a number of <em>survivors</em> on the basis of statistical clustering principles. The algorithms described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page combine the survivor offsets, designate one of them as the <em>system peer</em> and produces the final offset used by the algorithm described on the <a href="discipline.html">Clock Discipline Algorithm</a> page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. For additional details about these algorithms, see the Architecture Briefing on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
+<p>The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page selects the offset and delay samples most likely to produce accurate
results. Those servers that have passed the sanity tests are declared <em>selectable</em>. From the selectable population the statistics are used by the algorithm described on the <a href="select.html">Clock Select Algorithm</a> page to determine a number of <em>truechimers</em> according to correctness principles. From the truechimer population the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page determines a number of <em>survivors</em> on the basis of statistical clustering principles. The algorithms described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page combine the survivor offsets, designate one of them as the <em>system peer</em> and produces the final offset used by the algorithm described on the <a href="discipline.html">Clock Discipline Algorithm</a> page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. For additional details about these algorithms, see the Architecture Briefing on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<h4 id="budget">Statistics Budget</h4>
<p>Each source is characterized by the offset and delay samples measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm. In a window of eight samples, this algorithm selects the offset sample with the lowest delay, which generally represents the most accurate data. The selected samples become the <em>peer offset</em> and <em>peer delay</em>. The <em>peer dispersion</em> is determined as a weighted average of the dispersion samples in the window. It continues to grow at the same rate as the sample dispersion, 15 <font face="symbol">m</font>s/s. Finally, the <em>peer jitter</em> is determined as the root-mean-square (RMS) average of the offset samples in the window relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter are recorded by the <tt>peerstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. Peer variables are displayed by the <tt>rv</tt> command of the <a href="ntpq.html#peer"><tt>ntpq</tt></a> program.</p>
<p> The clock filter algorithm continues to process packets in this way until the source is no longer reachable. Reachability is determined by an eight-bit shift register, which is shifted left by one bit as each poll packet is sent, with 0 replacing the vacated rightmost bit. Each time an update is received, the rightmost bit is set to 1. The source is considered reachable if any bit is set to 1 in the register; otherwise, it is considered unreachable.</p>
<h4 id="quality">Quality of Service</h4>
<p>The mitigation algorithms deliver several important statistics, including <em>system offset</em> and <em>system jitter</em>. These statistics are determined by the mitigation algorithms's from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</p>
<p>Of interest in this discussion is how the daemon determines the quality of service from a particular reference clock or remote server. This is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error, or system jitter, is determined from various jitter components; it represents the nominal error in determining the mean clock offset. </p>
-<p>Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called <em>synchronization distance</em>. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettime
ofday()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
+<p>Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called <em>synchronization distance</em>. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettime()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
<p>The maximum error is computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.</p>
<p>A source is considered selectable only if its maximum error is less than the <em>select threshold</em>, by default 1.5 s, but can be changed according to client preference using the <tt>maxdist</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. A common consequences is when an upstream server loses all sources and its maximum error apparent to dependent clients begins to increase. The clients are not aware of this condition and continues to accept synchronization as long as the maximum error is less than the select threshold.</p>
-<p>Although it might seem counter-intuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the clock select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. This means that not every sample can be used to update the peer variables and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration for feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.</p>
+<p>Although it might seem counter-intuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the clock select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. The reason for these rules is to limit the time delay in the the clock discipline algorithm. This is necessary to preserve the optimum impulse response and thus the risetime and overshoot.</p>
+<p>This means that not every sample can be used to update the peer variables and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration for feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
projects / thirdparty / ntp.git / commitdiff
