<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->15-Dec-2010 6:06<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->18-Dec-2010 4:29<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</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 specified when the distribution is built.</p>
<p> Public key cryptography is generally considered more secure than symmetric key cryptography. Symmetic key cryptography is based on a shared secret key which must be distributed by secure means to all participats. Public key cryptography is based on a private secret key known only to the originator and a public key known to all participants. A recipient can verify the originator has the correct private key using the public key and any of several digital signature algortihms.</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 algorithms, such as MD5 or SHA, and verifies the source using any of several digital signature schemes, such as RSA or DSA. As used in Autokey, message digests are exceptionlly difficult to cryptanalyze, as the keys are used only once.</p>
-<p> 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.
Identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficulat to cryptanalyze, as the challenge/response exchange data are used only once. They 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> 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.
Optional identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficulat to cryptanalyze, as the challenge/response exchange data are used only once. They 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 IP 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 and clients are operated outside firewall perimeters.</p>
<p>Auokey 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, whle 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 server and the time period over which the the server 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. 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>
-<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. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or an NTP secure group as described in the next section.. Autokey hosts operate as servers, clients or both at the same time.</p>
+<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. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or an NTP secure group as described in the next section. Autokey hosts operate as servers, clients or both at the same time.</p>
<p>A certificate trail is a sequence of certificates, each signed by a host nearer the THs and terminating at the self-signed certificate of a TH. As the Autokey protocol proceeds, each client provides its self-signed certificate to a server nearer the THs for signature. 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. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.</p>
+<dd class="style1">The requirement that the NTP subnet be acyclic means that, if peers are configured with each other in symmetric modes, each must be a TH.</dd>
<p>The Autokey protocol runs for each association separately. During the protocol the client recursively obtains all the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it. </p>
<p>The certificates derived from each association are combined in the cache with duplicates suppressed. If it happens that two different associations contribute certificates to the cache, a certificate on the trail from one association could expire before any on another trail. In this case the remaining trails will survive until the expired certificate is replaced. Once saved in the cache, a certificate remains valid until it expires or is replaced by a new one.</p>
<p> It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains valid until it is demobilized, even if certificates on the trail to the THs expire.</p>
using the <tt>-q</tt> option and chosen remote password. In either case the data are installed as a file
and then renamed using the name given as the first line in the file, but without
the filestamp.</p>
+<p> </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><tt># cd /usr/local/etc<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>
+<p>Example</p>
+<div align="center"><img src="pic/flt8.gif" alt="gif">
+ <p>Figure 1. Example Configuration</p>
+</div>
+<p>Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. For the moment, assume that all associations are client/server; so, for example, TH X has two mobilized associations, one to Alice host C, the other to Carol host S. While not shown in the figure, Alice hosts A and B could configure symmetric active mode between them for redundancy and backup.</p>
<h4 ident="ident">Configuration - Identity Schemes</h4>
<p> For the simplest identity scheme TC, the server generates host keys, trusted certificate and identity files using an <tt>ntp-keygen </tt> program commadn with options specified in this section, while the clients use the same command with no options. The server uses the <tt>crypto</tt> command in the comnfiguration file with options specified in this section, while the clients use the same command with no options. Additonia client options are specified in the <tt>server</tt> command for each association. </p>
<p> It's best to start with a functioning TC configuation and add commands as necessary. For example, the CA generates an encrypted server keys file using the command</p>
<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>
+<p>Example</p>
+<p>Returnign 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, Carols' TH X is vulnerale to masquerade on the links between X and C and S. Therefor, X runs an identity scheme with C and S For example, C uses the command</p>
+<p>ntp-keygen -I -i YELLOW -e>ntpkey_iffpar_C</p>
+<p>and includes the command</p>
+<p>crypto ident YELLOW</p>
+<p>in its configuraiton file. S runs a similar configuration</p>
+<p>ntp-keygen -G -i ORANGE -e >orange</p>
+<p>crypto ident ORANGE</p>
+<p>in her configuration file. X needs only</p>
+<p>ntp-keygen </p>
+<p>to generate RSA keys and cetificate, but moblizes assoctions</p>
+<p>server C autokey ident YELLOW</p>
+<p>server S autiokey ident ORANGE</p>
+<p>X needs in install files yellow and orange under the names biven as the files like in the ifle, but without the filestamp.</p>
<h4 id="exam">Examples</h4>
<div align="center"> <img src="pic/group.gif" alt="gif"> </div>
<p>Consider a scenario involving three secure groups RED, GREEN and BLUE. RED and BLUE are typical of national laboratories providing certified time to the Internet at large. As shown ion the figure, RED TH mort and BLUE TH macabre run NTP symmetric mode with each other for monitoring or backup. For the purpose of illustration, assume both THs are primary servers. GREEN is typical of a large university providing certified time to the campus community. GREEN TH howland is a broadcast client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys. YELLOW is a client of GREEN and for purposes of illustration a TH for YELLOW.</p>
projects / thirdparty / ntp.git / commitdiff
