NetBSD/usr.sbin/xntp/html/authopt.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>