[ntp:bk-ntp-dev-send] BitKeeper patch

Harlan Stenn stenn at mail.eecis.udel.edu
Wed Nov 2 03:54:54 PST 2005


This BitKeeper patch contains the following changesets:
stenn at deacon.udel.edu|ChangeSet|20051102115406|21609

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# ID:	stenn at whimsy.udel.edu|ChangeSet|19990526004811|57482|8983e65c737bb465
# User:	stenn
# Host:	deacon.udel.edu
# Root:	/deacon/backroom/ntp-dev

#
#--- 1.34/html/authopt.html	2005-10-08 02:28:12 -04:00
#+++ 1.35/html/authopt.html	2005-11-02 06:53:56 -05:00
#@@ -13,7 +13,7 @@
# 		<h3>Authentication Options</h3>
# 		<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: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">03:35</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="286">Friday, September 23, 2005</csobj></p>
#+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">12:09</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="285">Thursday, October 27, 2005</csobj></p>
# 		<br clear="left">
# 		<h4>Related Links</h4>
# 		<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
#@@ -37,16 +37,16 @@
# 		<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> subcommand on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> configuration commands as described in the <a href="confopt.html">Configuration Options</a> page. The authentication options described below specify the locations of the key files, if other than default, which symmetric keys are trusted and the interval between various operations, if other than default.</p>
# 		<p>Authentication is always enabled, although ineffective if not configured as described below. If a NTP packet arrives including a message authentication code (MAC), it is accepted only if it passes all cryptographic checks. The checks require correct key ID, key value and message digest. If the packet has been modified in any way or replayed by an intruder, it will fail one or more of these checks and be discarded. Furthermore, the Autokey scheme requires a preliminary protocol exchange to obtain the server certificate, verify its credentials and initialize the protocol</p>
# 		<p>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running on another machine. If this flag is enabled, which is the default case, new broadcast/manycast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric key or public key cryptography. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating with the <tt>auth</tt> flag disabled invites a significant vulnerability where a rogue hacker can masquerade as a truechimer and seriously disrupt system timekeeping. It is important to note that this flag has no purpose other than to allow or disallow a new association in response to 
 new broadcast and symmetric active messages and remote configuration commands and, in particular, the flag has no effect on the authentication process itself.</p>
#-		<p>An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers as described in the <a href="manyopt.html">Automatic NTP Configuration Options</a> page. Either symmetric key or public key cryptographic authentication can be used in this mode. The principle advantage of manycast mode is that potential servers need not be configured in advance, since the client finds them during regular operation, and the configuration files for all clients can be identical.</p>
# 		<p>The security model and protocol schemes for both symmetric key and public key cryptography are summarized below; further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
# 		<h4 id="symm">Symmetric Key Cryptography</h4>
#-		The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key 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.
#+		
#+		The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key 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.
# 		<p>When <tt>ntpd</tt> is first started, it reads the key file specified in the <tt>keys</tt> configuration command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trusted</tt> command before use. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using <tt>ntpdc</tt>. This also provides a revocation capability that can be used if a key becomes compromised. The <tt>requestkey</tt> command selects the key used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key used as the password for the <tt>ntpq</tt> utility.</p>
# 		<h4 id="pub">Public Key Cryptography</h4>
#-		<p>NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. 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 with digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page and based on cryptographic challenge/response algorithms are also available. Using all of these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.</p>
#+		<p>NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. 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 with digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page and based on cryptographic challenge/response algorithms are also available. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.</p>
# 		<p>The cryptographic means necessary for all Autokey operations is provided by the OpenSSL software library. 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/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>The Autokey protocol has several modes of operation corresponding to the various NTP modes supported. Most modes use a special cookie which can be computed independently by the client and server, but encrypted in transmission. All modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. 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/%7emills/autokey.html">Autonomous Authentication</a> page.</p>
#-		<p>The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links generated by the <a href="keygen.html"><tt>ntp-keygen</tt></a> program. This includes a required host key file, required certificate file and optional sign key file, leapsecond file and identity scheme files. The digest/signature scheme is specified in the X.509 certificate along with the matching sign key. There are several schemes available in the OpenSSL software library, each identified by a specific string such as <tt>md5WithRSAEncryption</tt>, which stands for the MD5 message digest with RSA encryption scheme. The current NTP distribution supports all the schemes in the OpenSSL library, including those based on RSA and DSA digital signatures.</p>
#+		<p>The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links generated by the <a href="keygen.html"><tt>ntp-keygen</tt></a> program. This includes a required host key file, required host certificate file and optional sign key file, leapsecond file and identity scheme files. The digest/signature scheme is specified in the X.509 certificate along with the matching sign key. There are several schemes available in the OpenSSL software library, each identified by a specific string such as <tt>md5WithRSAEncryption</tt>, which stands for the MD5 message digest with RSA encryption scheme. The current NTP distribution supports all the schemes in the OpenSSL library, including those based on RSA and DSA digital signatures.</p>
# 		<p>NTP secure groups can be used to define cryptographic compartments and security hierarchies. It is important that every host in the group be able to construct a certificate trail to one or more trusted hosts in the same group. Each group host runs the Autokey protocol to obtain the certificates for all hosts along the trail to one or more trusted hosts. This requires the configuration file in all hosts to be engineered so that, even under anticipated failure conditions, the NTP&nbsp;subnet will form such that every group host can find a trail to at least one trusted host.</p>
# 		<h4>Naming and Addressing</h4>
# 		<p>It is important to note that Autokey does not use DNS&nbsp;to resolve addresses, since DNS can't be completely trusted until the name servers have synchronized clocks. The cryptographic name used by Autokey to bind the host identity credentials and cryptographic values must be independent of interface, network and any other naming convention. The name appears in the host certificate in either or both the subject and issuer fields, so protection against DNS&nbsp;compromise is essential.</p>
#

# Diff checksum=52e63ebe


# Patch vers:	1.3
# Patch type:	REGULAR

== ChangeSet ==
stenn at whimsy.udel.edu|ChangeSet|19990526004811|57482|8983e65c737bb465
stenn at deacon.udel.edu|ChangeSet|20051031102654|21615
D 1.1430 05/11/02 06:54:06-05:00 stenn at deacon.udel.edu +1 -0
B stenn at whimsy.udel.edu|ChangeSet|19990526004811|57482|8983e65c737bb465
C
c Updates from Dave Mills
K 21609
P ChangeSet
------------------------------------------------

0a0
> stenn at whimsy.udel.edu|html/authopt.htm|19990526004812|01635|3aed0663 stenn at deacon.udel.edu|html/authopt.html|20051102115356|05643

== html/authopt.html ==
stenn at whimsy.udel.edu|html/authopt.htm|19990526004812|01635|3aed0663
stenn at deacon.udel.edu|html/authopt.html|20051008062812|45543
D 1.35 05/11/02 06:53:56-05:00 stenn at deacon.udel.edu +5 -5
B stenn at whimsy.udel.edu|ChangeSet|19990526004811|57482|8983e65c737bb465
C
c Updates from Dave Mills
K 5643
O -rw-rw-r--
P html/authopt.html
------------------------------------------------

D16 1
I16 1
		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">12:09</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="285">Thursday, October 27, 2005</csobj></p>
D40 1
D43 1
I43 2
		
		The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key 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.
D46 1
I46 1
		<p>NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. 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 with digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page and based on cryptographic challenge/response algorithms are also available. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.</p>
D49 1
I49 1
		<p>The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links generated by the <a href="keygen.html"><tt>ntp-keygen</tt></a> program. This includes a required host key file, required host certificate file and optional sign key file, leapsecond file and identity scheme files. The digest/signature scheme is specified in the X.509 certificate along with the matching sign key. There are several schemes available in the OpenSSL software library, each identified by a specific string such as <tt>md5WithRSAEncryption</tt>, which stands for the MD5 message digest with RSA encryption scheme. The current NTP distribution supports all the schemes in the OpenSSL library, including those based on RSA and DSA digital signatures.</p>

# Patch checksum=c6c6b324


More information about the bk-ntp-dev-send mailing list