freebsd-dev/contrib/ntp/html/authopt.htm

416 lines
20 KiB
HTML
Raw Normal View History

2001-08-29 14:35:15 +00:00
<!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
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>