diff options
| author | roberto <roberto@FreeBSD.org> | 2004-07-20 15:19:51 +0000 |
|---|---|---|
| committer | roberto <roberto@FreeBSD.org> | 2004-07-20 15:19:51 +0000 |
| commit | 52f0477edd81105d995864898a64a601b67d66d8 (patch) | |
| tree | 3528c92623def79de13bd8f8caaa5639362dd64b /contrib/ntp/html/authopt.htm | |
| parent | 4155ac9f07c2f1986843c07b428ac66e6f11ffe0 (diff) | |
| download | FreeBSD-src-52f0477edd81105d995864898a64a601b67d66d8.zip FreeBSD-src-52f0477edd81105d995864898a64a601b67d66d8.tar.gz | |
Merge conflicts.
Lots of added files, some removed and quite a large number of renames :(
Diffstat (limited to 'contrib/ntp/html/authopt.htm')
| -rw-r--r-- | contrib/ntp/html/authopt.htm | 415 |
1 files changed, 0 insertions, 415 deletions
diff --git a/contrib/ntp/html/authopt.htm b/contrib/ntp/html/authopt.htm deleted file mode 100644 index 29df75d..0000000 --- a/contrib/ntp/html/authopt.htm +++ /dev/null @@ -1,415 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> -<html> -<head> -<meta name="generator" content="HTML Tidy, see www.w3.org"> -<title>Authentication Options</title> -</head> -<body> -<h3>Authentication Options</h3> - -<img align="left" src="pic/alice44.gif" alt="gif"><a href= -"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's -Adventures in Wonderland</i>, Lewis Carroll</a> - -<p>Our resident cryptographer; now you see him, now you don't.<br -clear="left"> -</p> - -<hr> -<h4>Authentication Support</h4> - -<p>Authentication support allows the NTP client to verify that the -server is in fact known and trusted and not an intruder intending -accidentally or on purpose to masquerade as that server. The NTPv3 -specification RFC-1305 defines an scheme which provides -cryptographic authentication of received NTP packets. Originally, -this was done using the Data Encryption Standard (DES) algorithm -operating in Cipher Block Chaining (CBC) mode, commonly called -DES-CBC. Subsequently, this was augmented by the RSA Message Digest -5 (MD5) algorithm using a private key, commonly called keyed-MD5. -Either algorithm computes a message digest, or one-way hash, which -can be used to verify the server has the correct private key and -key identifier.</p> - -<p>NTPv4 retains the NTPv3 schemes, properly described as -symmetric-key cryptography and, in addition, provides a new Autokey -scheme based on public-key cryptography. Public-key cryptography is -generally considered more secure than symmetric-key cryptography, -since the security is based on a private value which is generated -by each server and never revealed. With Autokey all key -distribution and management functions involve only public values, -which considerably simplifies key distribution and storage.</p> - -<p>Authentication is configured separately for each association -using the <tt>key</tt> or <tt>autokey</tt> subcommands on the <tt> -peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt> -manycastclient</tt> commands as described in the <a href= -"config.htm">Configuration Options</a> page. The authentication -options described below specify the suite of keys, select the key -for each configured association and manage the configuration -operations.</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> configuration commands and also by remote -configuration commands sent by a <tt>ntpdc</tt> program running in -another machine. If this flag is enabled, which is the default -case, new broadcast client and symmetric passive associations and -remote configuration commands must be cryptographically -authenticated using either symmetric-key or public-key schemes. If -this flag is disabled, these operations are effective even if not -cryptographic authenticated. It should be understood that operating -in the latter mode invites a significant vulnerability where a -rogue hacker can seriously disrupt client timekeeping.</p> - -<p>In networks with firewalls and large numbers of broadcast -clients it may be acceptable to disable authentication, since that -avoids key distribution and simplifies network maintenance. -However, when the configuration file contains host names, or when a -server or client is configured remotely, host names are resolved -using the DNS and a separate name resolution process. In order to -protect against bogus name server messages, name resolution -messages are authenticated using an internally generated key which -is normally invisible to the user. However, if cryptographic -support is disabled, the name resolution process will fail. This -can be avoided either by specifying IP addresses instead of host -names, which is generally inadvisable, or by enabling the flag for -name resolution and disabled it once the name resolution process is -complete.</p> - -<p>An attractive alternative where multicast support is available -is manycast mode, in which clients periodically troll for servers. -Cryptographic authentication in this mode uses public-key schemes -as described below. The principle advantage of this 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>In addition to the default symmetric-key cryptographic support, -support for public-key cryptography is available if the requisite -<tt>rsaref20</tt> software distribution has been installed before -building the distribution. Public-key cryptography provides secure -authentication of servers without compromising accuracy and -stability. The security model and protocol schemes for both -symmetric-key and public-key cryptography are described below.</p> - -<h4>Symmetric-Key Scheme</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 their messages. -Keys and related information are specified in a key file, usually -called <tt>ntp.keys</tt>, which should be exchanged and stored -using secure procedures 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.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">ntpdc</a></tt> -utility programs. - -<p>When <tt>ntpd</tt> is first started, it reads the key file -specified int he <tt>keys</tt> command and installs the keys in the -key cache. However, the 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>Public-Key Scheme</h4> - -The original NTPv3 authentication scheme described in RFC-1305 -continues to be supported; however, in NTPv4 an additional -authentication scheme called Autokey is available. It uses MD5 -message digest, RSA public-key signature and Diffie-Hellman key -agreement algorithms available from several sources, but not -included in the NTPv4 software distribution. In order to be -effective, the <tt>rsaref20</tt> package must be installed as -described in the <tt>README.rsa</tt> file. Once installed, the -configure and build process automatically detects it and compiles -the routines required. The Autokey scheme has several modes of -operation corresponding to the various NTP modes supported. RSA -signatures with timestamps are used in all modes to verify the -source of cryptographic values. All modes use a special cookie -which can be computed independently by the client and server. In -symmetric modes the cookie is constructed using the Diffie-Hellman -key agreement algorithm. In other modes the cookie is constructed -from the IP addresses and a private value known only to the server. -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/~mills/autokey.htm">Autonomous -Authentication</a> page. - -<p>The cryptographic values used by the Autokey scheme are -incorporated as a set of files generated by the <a href= -"genkeys.htm"><tt>ntp-genkeys</tt></a> program, including the -symmetric private keys, public/private key pair, and the agreement -parameters. See the <tt>ntp-genkeys</tt> page for a description of -the formats of these files. They contain cryptographic values -generated by the algorithms of the <tt>rsaref20</tt> package and -are in printable ASCII format. All file names include the -timestamp, in NTP seconds, following the default names given below. -Since the file data are derived from random values seeded by the -system clock and the file name includes the timestamp, every -generation produces a different file and different file name.</p> - -<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It -must be distributed by secure means to other servers and clients -sharing the same security compartment and made visible only to -root. While this file is not used with the Autokey scheme, it is -needed to authenticate some remote configuration commands used by -the <a href="ntpdc.htm"><tt>ntpq</tt></a> and <a href="ntpq.htm"> -<tt>ntpdc</tt></a> utilities. The <tt>ntpkey</tt> file contains the -RSA private key. It is useful only to the machine that generated it -and never shared with any other daemon or application program, so -must be made visible only to root.</p> - -<p>The <tt>ntp_dh</tt> file contains the agreement parameters, -which are used only in symmetric (active and passive) modes. It is -necessary that both peers beginning a symmetric-mode association -share the same parameters, but it does not matter which <tt> -ntp_dh</tt> file generates them. If one of the peers contains the -parameters, the other peer obtains them using the Autokey protocol. -If both peers contain the parameters, the most recent copy is used -by both peers. If a peer does not have the parameters, they will be -requested by all associations, either configured or not; but, none -of the associations can proceed until one of them has received the -parameters. Once loaded, the parameters can be provided on request -to other clients and servers. The <tt>ntp_dh</tt> file can be also -be distributed using insecure means, since the data are public -values.</p> - -<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public -key, where <tt><i>host</i></tt> is the name of the host. Each host -must have its own <tt>ntpkey_<i>host</i></tt> file, which is -normally provided to other hosts using the Autokey protocol Each -<tt>server</tt> or <tt>peer</tt> association requires the public -key associated with the particular server or peer to be loaded -either directly from a local file or indirectly from the server -using the Autokey protocol. These files can be widely distributed -and stored using insecure means, since the data are public -values.</p> - -<p>The optional <tt>ntpkey_certif_<i>host</i></tt> file contains -the PKI certificate for the host. This provides a binding between -the host hame and RSA public key. In the current implementation the -certificate is obtained by a client, if present, but the contents -are ignored.</p> - -<p>Due to the widespread use of interface-specific naming, the host -names used in configured and mobilized associations are determined -by the Unix <tt>gethostname()</tt> library routine. Both the <tt> -ntp-genkeys</tt> program and the Autokey protocol derive the name -of the public key file using the name returned by this routine. -While every server and client is required to load their own public -and private keys, the public keys for each client or peer -association can be obtained from the server or peer using the -Autokey protocol. Note however, that at the current stage of -development the authenticity of the server or peer and the -cryptographic binding of the server name, address and public key is -not yet established by a certificate authority or web of trust.</p> - -<h4>Leapseconds Table</h4> - -<p>The NIST provides a table showing the epoch for all historic -occasions of leap second insertion since 1972. The leapsecond table -shows each epoch of insertion along with the offset of -International Atomic Time (TAI) with respect to Coordinated -Universtal Time (UTC), as disseminated by NTP. The table can be -obtained directly from NIST national time servers using <tt> -ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.</p> - -<p>While not strictly a security function, the Autokey scheme -provides means to securely retrieve the leapsecond table from a -server or peer. Servers load the leapsecond table directly from the -file specified in the <tt>crypto</tt> command, while clients can -load the table indirectly from the servers using the Autokey -protocol. Once loaded, the table can be provided on request to -other clients and servers.</p> - -<h4>Key Management</h4> - -<p>All key files are installed by default in <tt> -/usr/local/etc</tt>, which is normally in a shared filesystem in -NFS-mounted networks and avoids installing them in each machine -separately. The default can be overridden by the <tt>keysdir</tt> -configuration command. However, this is not a good place to install -the private key file, since each machine needs its own file. A -suitable place to install it is in <tt>/etc</tt>, which is normally -not in a shared filesystem.</p> - -<p>The recommended practice is to keep the timestamp extensions -when installing a file and to install a link from the default name -(without the timestamp extension) to the actual file. This allows -new file generations to be activated simply by changing the link. -However, <tt>ntpd</tt> parses the link name when present to extract -the extension value and sends it along with the public key and host -name when requested. This allows clients to verify that the file -and generation time are always current. However, the actual -location of each file can be overridden by the <tt>crypto</tt> -configuration command.</p> - -<p>All cryptographic keys and related parameters should be -regenerated on a periodic and automatic basis, like once per month. -The <tt>ntp-genkeys</tt> program uses the same timestamp extension -for all files generated at one time, so each generation is distinct -and can be readily recognized in monitoring data. While a -public/private key pair must be generated by every server and -client, the public keys and agreement parameters do not need to be -explicitly copied to all machines in the same security compartment, -since they can be obtained automatically using the Autokey -protocol. However, it is necessary that all primary servers have -the same agreement parameter file. The recommended way to do this -is for one of the primary servers to generate that file and then -copy it to the other primary servers in the same compartment using -the Unix <tt>rdist</tt> command. Future versions of the Autokey -protocol are to contain provisions for an agreement protocol to do -this automatically.</p> - -<p>Servers and clients can make a new generation in the following -way. All machines have loaded the old generation at startup and are -operating normally. At designated intervals, each machine generates -a new public/private key pair and makes links from the default file -names to the new file names. The <tt>ntpd</tt> is then restarted -and loads the new generation, with result clients no longer can -authenticate correctly. The Autokey protocol is designed so that -after a few minutes the clients time out and restart the protocol -from the beginning, with result the new generation is loaded and -operation continues as before. A similar procedure can be used for -the agreement parameter file, but in this case precautions must be -take to be sure that all machines with this file have the same -copy.</p> - -<h4>Authentication Commands</h4> - -<dl> -<dt><tt>autokey [<i>logsec</i>]</tt></dt> - -<dd>Specifies the interval between regenerations of the session key -list used with the Autokey protocol. Note that the size of the key -list for each association depends on this interval and the current -poll interval. The default value is 12 (4096 s or about 1.1 hours). -For poll intervals above the specified interval, a session key list -with a single entry will be regenerated for every message -sent.</dd> - -<dt><tt>controlkey <i>key</i></tt></dt> - -<dd>Specifies the key identifier to use with the <a href= -"ntpq.htm"><tt>ntpq</tt></a> utility, which uses the standard -protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is -the key identifier for a trusted key, where the value can be in the -range 1 to 65534, inclusive.</dd> - -<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>] -[publickey <i>file</i>] [dhparms <i>file</i>] [leap <i> -file</i>]</tt></dt> - -<dd>This command requires the NTP daemon build process be -configured with the RSA library. This command activates public-key -cryptography and loads the required RSA private and public key -files and the optional Diffie-Hellman agreement parameter file, if -present. If one or more files are left unspecified, the default -names are used as described below. Following are the -subcommands:</dd> - -<dd> -<dl> -<dt><tt>privatekey <i>file</i></tt></dt> - -<dd>Specifies the location of the RSA private key file, which -otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd> - -<dt><tt>publickey <i>file</i></tt></dt> - -<dd>Specifies the location of the RSA public key file, which -otherwise defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>., -where <i>host</i> is the name of the generating machine.</dd> - -<dt><tt>dhparms <i>file</i></tt></dt> - -<dd>Specifies the location of the Diffie-Hellman parameters file, -which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd> - -<dt><tt>leap <i>file</i></tt></dt> - -<dd>Specifies the location of the leapsecond table file, which -otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd> -</dl> -</dd> - -<dt><tt>keys <i>keyfile</i></tt></dt> - -<dd>Specifies the location of the DES/MD5 private key file -containing the keys and key identifiers used by <tt>ntpd</tt>, <tt> -ntpq</tt> and <tt>ntpdc</tt> when operating in symmetric-key -mode.</dd> - -<dt><tt>keysdir <i>path</i></tt></dt> - -<dd>This command requires the NTP daemon build process be -configured with the RSA library. It specifies the default directory -path for the private key file, agreement parameters file and one or -more public key files. The default when this command does not -appear in the configuration file is <tt>/usr/local/etc/</tt>.</dd> - -<dt><tt>requestkey <i>key</i></tt></dt> - -<dd>Specifies the key identifier to use with the <a href= -"ntpdc.htm"><tt>ntpdc</tt></a> utility program, which uses a -proprietary protocol specific to this implementation of <tt> -ntpd</tt>. The <tt><i>key</i></tt> argument is a key identifier for -the trusted key, where the value can be in the range 1 to 65534, -inclusive.</dd> - -<dt><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. These values need to be updated frequently in order to -deflect brute-force attacks on the algorithms of the scheme; -however, updating some values is a relatively expensive operation. -The default interval is 16 (65,536 s or about 18 hours). For poll -intervals above the specified interval, the values will be updated -for every message sent.</dd> - -<dt><tt>trustedkey <i>key</i> [...]</tt></dt> - -<dd>Specifies the key identifiers which are trusted for the -purposes of authenticating peers with symmetric-key cryptography, -as well as keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt> -programs. The authentication procedures require that both the local -and remote servers share the same key and key identifier for this -purpose, although different keys can be used with different -servers. The <tt><i>key</i></tt> arguments are 32-bit unsigned -integers with values from 1 to 65,534.</dd> -</dl> - -<h4>Files</h4> - -<tt>ntp.keys</tt> private MD5 keys <br> -<tt>ntpkey</tt> RSA private key <br> -<tt>ntpkey_<i>host</i></tt> RSA public key <br> -<tt>ntp_dh</tt> Diffie-Hellman agreement parameters - -<h4>Bugs</h4> - -The <tt>ntpkey_<i>host</i></tt> files are really digital -certificates. These should be obtained via secure directory -services when they become universally available. - -<hr> -<a href="index.htm"><img align="left" src="pic/home.gif" alt= -"gif"></a> - -<address><a href="mailto:mills@udel.edu">David L. Mills -<mills@udel.edu></a></address> -</body> -</html> - |
