<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->31-Oct-2010 4:38<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Nov-2010 19:13<!-- #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.</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 algori
htms 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>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, 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 algori
thms, such as MD5 or SHA, and verifies the source using any of several digital signature schemes, including RSA and DSA. 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 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>
+<h4 id="config">Configuration</h4>
+<p>The Trusted Certificate (TC) is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server as root:</p>
+<p><tt># cd /usr/local/etc<br>
+# ntp-keygen -T</tt></p>
+<p>This generates an RSA private/public key pair and a self-signed certificate for the RSA digital signature algorithm with the MD5 message digest algoirhtm. 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>
+ # crypto<br>
+# driftfile /etc/nto.drift.</tt></p>
+<p>Note the first three lines are specific to the ACTS driver and NIST phone numbers. The second number will be tried if the first times out. Any other reference clock can be used, or even another time server.</p>
+<p>For each client 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 for a client such as grundoon.udel.edu something like</p>
+<p><tt># server time.nist.gov iburst<br>
+ # crypto<br>
+# driftfile /etc/nto.drift.</tt></p>
+<p>It is possible to configure client hosts of server grundoon in the same way with the server line pointing to grundoon. Dependent clients authenticate to time.nistg.gov through grundoon.udel.edu.</p>
+<p>In the above configuration examples, the default autokey host name is the string returned by the Unix gethostbyname() library routine. The host name is used as the subject and issuer names on the certificate, as well as the default deault password for the host key and certificate files. The host name can be chaned using the -s option with the ntp-keygen program. The default password can be changed using the -p optoin for the ntp-keygen and the pw option of the crypto command. </p>
+<p>It is important to note that certificates have a defined lifetime of one year from the time of creation. Sometime toward the end of the liftetime period, it is necessary to create a new certificat at both the server and client. For each server and client as root:</p>
+<p><tt># ntp_keygen</tt></p>
+<p>The options are copied from the current certificarte.</p>
+<p> </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
<img src="pic/alice32.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>Alice is trying to find the PPS signal connector.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Sep-2010 4:09<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Nov-2010 22:57<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<p>The gadget box shown above is assembled in a 5"x3"x2" aluminum minibox containing the the circuitry, serial connector and optional 12-V power connector. A complete set of schematics, PCB artwork, drill templates can be obtained via the web from ftp.udel.edu as <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
<p> The gadget box includes two subcircuits. One of these converts a TTL positive edge into a fixed-width pulse at EIA levels and is for use with a timecode receiver or precision oscillator with a TTL PPS output. The other converts the timecode modulation broadcast by Canadian time/frequency standard station CHU into a 300-bps serial character stream at EIA levels and is for use with the <a href="drivers/driver7.html">Radio CHU Audio Demodulator/Decoder</a> driver.</p>
<h4 id="opsys">Operating System Support</h4>
-<p>Both the serial and parallel port connection require operating system support, which is available in a few operating systems, including FreeBSD, Linux (with PPSkit patch) and Solaris. Support on an experimental basis is available for several other systems, including SunOS and HP/Compaq/Digital Tru64. The kernel interface described on the <a href="kernpps.html">PPSAPI Interface for Precision Time Signals</a> page is the only interface currently supported. Older PPS interfaces based on the <tt>ppsclock</tt> and <tt>tty_clk</tt> streams modules are no longer supported. The interface consists of the <tt>ppstime.h</tt> header file which is specific to each system. It is included automatically when the distribution is built.</p>
+<p>Both the serial and parallel port connection require operating system support, which is available in a few operating systems, including FreeBSD, Linux (with PPSkit patch) and Solaris. Support on an experimental basis is available for several other systems, including SunOS and HP/Compaq/Digital Tru64. The kernel interface described on the <a href="kernpps.html">PPSAPI Interface for Precision Time Signals</a> page is the only interface currently supported. Older PPS interfaces based on the <tt>ppsclock</tt> and <tt>tty_clk</tt> streams modules are no longer supported. The interface consists of the <tt>timepps.h</tt> header file which is specific to each system. It is included automatically when the distribution is built.</p>
<h4>PPS Driver</h4>
<p>PPS support requires is built into some drivers, in particular the WWVB and NMEA drivers, and may be added to other drivers in future. Alternatively, the PPS driver described on the <a href="drivers/driver22.html">Type 22 PPS Clock Discipline</a> page can be used. It operates in conjunction with another source that provides seconds numbering. The selected source is designate a prefer peer, as using the <tt>prefer</tt> option, as described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. The prefer peer is ordinarily the radio clock that provides the PPS signal, but in principle another radio clock or even a remote Internet server could be designated preferred Note that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p>
<h4 id="use">Using the Pulse-per-Second (PPS) Signal</h4>
projects / thirdparty / ntp.git / commitdiff
