131 lines
5.9 KiB
HTML
131 lines
5.9 KiB
HTML
|
<!-- $NetBSD: authopt.html,v 1.1 1998/12/30 20:20:33 mcr Exp $ -->
|
||
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
|
||
|
<html><head><title>
|
||
|
Authentication Options
|
||
|
</title></head><body><h3>
|
||
|
Authentication Options
|
||
|
</h3><hr>
|
||
|
|
||
|
<p><h4>Authentication Support</h4>
|
||
|
|
||
|
<p>The NTP standard specifies an extension which provides cryptographic
|
||
|
authentication of received NTP packets. This is implemented in
|
||
|
<code>xntpd</code> using the DES or MD5 algorithms to compute a digital
|
||
|
signature, or message digest. The specification allows any one of
|
||
|
possibly 4 billion keys, numbered with 32-bit key identifiers, to be
|
||
|
used to authenticate an association. The servers involved in an
|
||
|
association must agree on the key and key identifier used to
|
||
|
authenticate their messages.
|
||
|
|
||
|
<p>Keys and related information are specified in a key file, which
|
||
|
should be exchanged and stored using secure procedures beyond the scope
|
||
|
of the protocol. There are three classes of keys involved in the current
|
||
|
implementation. One class is used for ordinary NTP associations, another
|
||
|
for the <a href = "ntpq.html"> <code>ntpq</code></a> utility program and
|
||
|
the third for the <a href = "xntpdc.html"> <code>xntpdc</code></a>
|
||
|
utility program.
|
||
|
|
||
|
<p><h4>Authentication Commands</h4>
|
||
|
|
||
|
<dl>
|
||
|
|
||
|
<dt><code>keys <i>keyfile</i></code>
|
||
|
<dd>Specifies the file name containing the encryption keys and key
|
||
|
identifiers used by <code>xntpd</code>, <code>ntpq</code> and
|
||
|
<code>xntpdc</code> when operating in authenticated mode. The format of
|
||
|
this file is described later in this document.
|
||
|
|
||
|
<p><dt><code>trustedkey <i>key</i> [ ... ]</code>
|
||
|
<dd>Specifies the encryption key identifiers which are trusted for the
|
||
|
purposes of authenticating peers suitable for synchronization. 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
|
||
|
<code><i>key</i></code> arguments are 32-bit unsigned integers. Note
|
||
|
that NTP key 0 is fixed and globally known. If meaningful authentication
|
||
|
is to be performed the 0 key should not be trusted.
|
||
|
|
||
|
<p><dt><code>requestkey <i>key</i></code>
|
||
|
<dd>Specifies the key identifier to use with the <code>xntpdc</code>
|
||
|
program, which uses a proprietary protocol specific to this
|
||
|
implementation of <code>xntpd</code>. This program is useful to diagnose
|
||
|
and repair problems that affect <code>xntpd</code> operation. The
|
||
|
<code><i>key</i></code> argument to this command is a 32-bit unsigned
|
||
|
integer. If no <code>requestkey</code> command is included in the
|
||
|
configuration file, or if the keys don't match, such requests will be
|
||
|
ignored.
|
||
|
|
||
|
<p><dt><code>controlkey <i>key</i></code>
|
||
|
<dd>Specifies the key identifier to use with the <code>ntpq</code>
|
||
|
program, which uses the standard protocol defined in RFC-1305. This
|
||
|
program is useful to diagnose and repair problems that affect
|
||
|
<code>xntpd</code> operation. The <code><i>key</i></code> argument to
|
||
|
this command is a 32-bit unsigned integer. If no <code>requestkey</code>
|
||
|
command is included in the configuration file, or if the keys don't
|
||
|
match, such requests will be ignored.
|
||
|
|
||
|
</dl>
|
||
|
<p><h4>Authentication Key File Format</h4>
|
||
|
|
||
|
<p>In the case of DES, the keys are 56 bits long with, depending on
|
||
|
type, a parity check on each byte. In the case of MD5, the keys are 64
|
||
|
bits (8 bytes). <code>xntpd</code> reads its keys from a file specified
|
||
|
using the <code>-k</code> command line option or the <code>keys</code>
|
||
|
statement in the configuration file. While key number 0 is fixed by the
|
||
|
NTP standard (as 56 zero bits) and may not be changed, one or more of
|
||
|
the keys numbered 1 through 15 may be arbitrarily set in the keys file.
|
||
|
|
||
|
<p>The key file uses the same comment conventions as the configuration
|
||
|
file. Key entries use a fixed format of the form
|
||
|
|
||
|
<p><code><i>keyno type key</i></code>
|
||
|
|
||
|
<p>where <code><i>keyno</i></code> is a positive integer,
|
||
|
<code><i>type</i></code> is a single character which defines the key
|
||
|
format, and <code><i>key</i></code> is the key itself.
|
||
|
|
||
|
<p>The key may be given in one of three different formats, controlled by
|
||
|
the <code><i>type</i></code> character. The three key types, and
|
||
|
corresponding formats, are listed following.
|
||
|
|
||
|
<dl>
|
||
|
|
||
|
<dt><code>S</code>
|
||
|
<dd>The key is a 64-bit hexadecimal number in the format specified in
|
||
|
the DES specification; that is, the high order seven bits of each octet
|
||
|
are used to form the 56-bit key while the low order bit of each octet is
|
||
|
given a value such that odd parity is maintained for the octet. Leading
|
||
|
zeroes must be specified (i.e., the key must be exactly 16 hex digits
|
||
|
long) and odd parity must be maintained. Hence a zero key, in standard
|
||
|
format, would be given as <code>0101010101010101</code>.
|
||
|
|
||
|
<p><dt><code>N</code>
|
||
|
<dd>The key is a 64-bit hexadecimal number in the format specified in
|
||
|
the NTP standard. This is the same as the DES format, except the bits in
|
||
|
each octet have been rotated one bit right so that the parity bit is now
|
||
|
the high order bit of the octet. Leading zeroes must be specified and
|
||
|
odd parity must be maintained. A zero key in NTP format would be
|
||
|
specified as <code>8080808080808080</code>.
|
||
|
|
||
|
<p><dt><code>A</code>
|
||
|
<dd>The key is a 1-to-8 character ASCII string. A key is formed from
|
||
|
this by using the low order 7 bits of each ASCII character in the
|
||
|
string, with zeroes added on the right when necessary to form a full
|
||
|
width 56-bit key, in the same way that encryption keys are formed from
|
||
|
Unix passwords.
|
||
|
|
||
|
<p><dt><code>M</code>
|
||
|
<dd>The key is a 1-to-8 character ASCII string, using the MD5
|
||
|
authentication scheme. Note that both the keys and the authentication
|
||
|
schemes (DES or MD5) must be identical between a set of peers sharing
|
||
|
the same key number.
|
||
|
|
||
|
</dl>
|
||
|
|
||
|
<p>Note that the keys used by the <code>ntpq</code> and
|
||
|
<code>xntpdc</code> programs are checked against passwords requested by
|
||
|
the programs and entered by hand, so it is generally appropriate to
|
||
|
specify these keys in ASCII format.
|
||
|
|
||
|
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>
|