1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
4
<meta name="generator" content="HTML Tidy, see www.w3.org">
5
<title>Authentication Options</title>
8
<h3>Authentication Options</h3>
10
<img align="left" src="pic/alice44.gif" alt="gif"><a href=
11
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
12
Adventures in Wonderland</i>, Lewis Carroll</a>
14
<p>Our resident cryptographer; now you see him, now you don't.<br
19
<h4>Authentication Support</h4>
21
<p>Authentication support allows the NTP client to verify that the
22
server is in fact known and trusted and not an intruder intending
23
accidentally or on purpose to masquerade as that server. The NTPv3
24
specification RFC-1305 defines an scheme which provides
25
cryptographic authentication of received NTP packets. Originally,
26
this was done using the Data Encryption Standard (DES) algorithm
27
operating in Cipher Block Chaining (CBC) mode, commonly called
28
DES-CBC. Subsequently, this was augmented by the RSA Message Digest
29
5 (MD5) algorithm using a private key, commonly called keyed-MD5.
30
Either algorithm computes a message digest, or one-way hash, which
31
can be used to verify the server has the correct private key and
34
<p>NTPv4 retains the NTPv3 schemes, properly described as
35
symmetric-key cryptography and, in addition, provides a new Autokey
36
scheme based on public-key cryptography. Public-key cryptography is
37
generally considered more secure than symmetric-key cryptography,
38
since the security is based on a private value which is generated
39
by each server and never revealed. With Autokey all key
40
distribution and management functions involve only public values,
41
which considerably simplifies key distribution and storage.</p>
43
<p>Authentication is configured separately for each association
44
using the <tt>key</tt> or <tt>autokey</tt> subcommands on the <tt>
45
peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>
46
manycastclient</tt> commands as described in the <a href=
47
"config.htm">Configuration Options</a> page. The authentication
48
options described below specify the suite of keys, select the key
49
for each configured association and manage the configuration
52
<p>The <tt>auth</tt> flag controls whether new associations or
53
remote configuration commands require cryptographic authentication.
54
This flag can be set or reset by the <tt>enable</tt> and <tt>
55
disable</tt> configuration commands and also by remote
56
configuration commands sent by a <tt>ntpdc</tt> program running in
57
another machine. If this flag is enabled, which is the default
58
case, new broadcast client and symmetric passive associations and
59
remote configuration commands must be cryptographically
60
authenticated using either symmetric-key or public-key schemes. If
61
this flag is disabled, these operations are effective even if not
62
cryptographic authenticated. It should be understood that operating
63
in the latter mode invites a significant vulnerability where a
64
rogue hacker can seriously disrupt client timekeeping.</p>
66
<p>In networks with firewalls and large numbers of broadcast
67
clients it may be acceptable to disable authentication, since that
68
avoids key distribution and simplifies network maintenance.
69
However, when the configuration file contains host names, or when a
70
server or client is configured remotely, host names are resolved
71
using the DNS and a separate name resolution process. In order to
72
protect against bogus name server messages, name resolution
73
messages are authenticated using an internally generated key which
74
is normally invisible to the user. However, if cryptographic
75
support is disabled, the name resolution process will fail. This
76
can be avoided either by specifying IP addresses instead of host
77
names, which is generally inadvisable, or by enabling the flag for
78
name resolution and disabled it once the name resolution process is
81
<p>An attractive alternative where multicast support is available
82
is manycast mode, in which clients periodically troll for servers.
83
Cryptographic authentication in this mode uses public-key schemes
84
as described below. The principle advantage of this manycast mode
85
is that potential servers need not be configured in advance, since
86
the client finds them during regular operation, and the
87
configuration files for all clients can be identical.</p>
89
<p>In addition to the default symmetric-key cryptographic support,
90
support for public-key cryptography is available if the requisite
91
<tt>rsaref20</tt> software distribution has been installed before
92
building the distribution. Public-key cryptography provides secure
93
authentication of servers without compromising accuracy and
94
stability. The security model and protocol schemes for both
95
symmetric-key and public-key cryptography are described below.</p>
97
<h4>Symmetric-Key Scheme</h4>
99
The original RFC-1305 specification allows any one of possibly
100
65,534 keys, each distinguished by a 32-bit key identifier, to
101
authenticate an association. The servers and clients involved must
102
agree on the key and key identifier to authenticate their messages.
103
Keys and related information are specified in a key file, usually
104
called <tt>ntp.keys</tt>, which should be exchanged and stored
105
using secure procedures beyond the scope of the NTP protocol
106
itself. Besides the keys used for ordinary NTP associations,
107
additional keys can be used as passwords for the <tt><a href=
108
"ntpq.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">ntpdc</a></tt>
111
<p>When <tt>ntpd</tt> is first started, it reads the key file
112
specified int he <tt>keys</tt> command and installs the keys in the
113
key cache. However, the keys must be activated with the <tt>
114
trusted</tt> command before use. This allows, for instance, the
115
installation of possibly several batches of keys and then
116
activating or deactivating each batch remotely using <tt>
117
ntpdc</tt>. This also provides a revocation capability that can be
118
used if a key becomes compromised. The <tt>requestkey</tt> command
119
selects the key used as the password for the <tt>ntpdc</tt>
120
utility, while the <tt>controlkey</tt> command selects the key used
121
as the password for the <tt>ntpq</tt> utility.</p>
123
<h4>Public-Key Scheme</h4>
125
The original NTPv3 authentication scheme described in RFC-1305
126
continues to be supported; however, in NTPv4 an additional
127
authentication scheme called Autokey is available. It uses MD5
128
message digest, RSA public-key signature and Diffie-Hellman key
129
agreement algorithms available from several sources, but not
130
included in the NTPv4 software distribution. In order to be
131
effective, the <tt>rsaref20</tt> package must be installed as
132
described in the <tt>README.rsa</tt> file. Once installed, the
133
configure and build process automatically detects it and compiles
134
the routines required. The Autokey scheme has several modes of
135
operation corresponding to the various NTP modes supported. RSA
136
signatures with timestamps are used in all modes to verify the
137
source of cryptographic values. All modes use a special cookie
138
which can be computed independently by the client and server. In
139
symmetric modes the cookie is constructed using the Diffie-Hellman
140
key agreement algorithm. In other modes the cookie is constructed
141
from the IP addresses and a private value known only to the server.
142
All modes use in addition a variant of the S-KEY scheme, in which a
143
pseudo-random key list is generated and used in reverse order.
144
These schemes are described along with an executive summary,
145
current status, briefing slides and reading list, on the <a href=
146
"http://www.eecis.udel.edu/~mills/autokey.htm">Autonomous
147
Authentication</a> page.
149
<p>The cryptographic values used by the Autokey scheme are
150
incorporated as a set of files generated by the <a href=
151
"genkeys.htm"><tt>ntp-genkeys</tt></a> program, including the
152
symmetric private keys, public/private key pair, and the agreement
153
parameters. See the <tt>ntp-genkeys</tt> page for a description of
154
the formats of these files. They contain cryptographic values
155
generated by the algorithms of the <tt>rsaref20</tt> package and
156
are in printable ASCII format. All file names include the
157
timestamp, in NTP seconds, following the default names given below.
158
Since the file data are derived from random values seeded by the
159
system clock and the file name includes the timestamp, every
160
generation produces a different file and different file name.</p>
162
<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It
163
must be distributed by secure means to other servers and clients
164
sharing the same security compartment and made visible only to
165
root. While this file is not used with the Autokey scheme, it is
166
needed to authenticate some remote configuration commands used by
167
the <a href="ntpdc.htm"><tt>ntpq</tt></a> and <a href="ntpq.htm">
168
<tt>ntpdc</tt></a> utilities. The <tt>ntpkey</tt> file contains the
169
RSA private key. It is useful only to the machine that generated it
170
and never shared with any other daemon or application program, so
171
must be made visible only to root.</p>
173
<p>The <tt>ntp_dh</tt> file contains the agreement parameters,
174
which are used only in symmetric (active and passive) modes. It is
175
necessary that both peers beginning a symmetric-mode association
176
share the same parameters, but it does not matter which <tt>
177
ntp_dh</tt> file generates them. If one of the peers contains the
178
parameters, the other peer obtains them using the Autokey protocol.
179
If both peers contain the parameters, the most recent copy is used
180
by both peers. If a peer does not have the parameters, they will be
181
requested by all associations, either configured or not; but, none
182
of the associations can proceed until one of them has received the
183
parameters. Once loaded, the parameters can be provided on request
184
to other clients and servers. The <tt>ntp_dh</tt> file can be also
185
be distributed using insecure means, since the data are public
188
<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public
189
key, where <tt><i>host</i></tt> is the name of the host. Each host
190
must have its own <tt>ntpkey_<i>host</i></tt> file, which is
191
normally provided to other hosts using the Autokey protocol Each
192
<tt>server</tt> or <tt>peer</tt> association requires the public
193
key associated with the particular server or peer to be loaded
194
either directly from a local file or indirectly from the server
195
using the Autokey protocol. These files can be widely distributed
196
and stored using insecure means, since the data are public
199
<p>The optional <tt>ntpkey_certif_<i>host</i></tt> file contains
200
the PKI certificate for the host. This provides a binding between
201
the host hame and RSA public key. In the current implementation the
202
certificate is obtained by a client, if present, but the contents
205
<p>Due to the widespread use of interface-specific naming, the host
206
names used in configured and mobilized associations are determined
207
by the Unix <tt>gethostname()</tt> library routine. Both the <tt>
208
ntp-genkeys</tt> program and the Autokey protocol derive the name
209
of the public key file using the name returned by this routine.
210
While every server and client is required to load their own public
211
and private keys, the public keys for each client or peer
212
association can be obtained from the server or peer using the
213
Autokey protocol. Note however, that at the current stage of
214
development the authenticity of the server or peer and the
215
cryptographic binding of the server name, address and public key is
216
not yet established by a certificate authority or web of trust.</p>
218
<h4>Leapseconds Table</h4>
220
<p>The NIST provides a table showing the epoch for all historic
221
occasions of leap second insertion since 1972. The leapsecond table
222
shows each epoch of insertion along with the offset of
223
International Atomic Time (TAI) with respect to Coordinated
224
Universtal Time (UTC), as disseminated by NTP. The table can be
225
obtained directly from NIST national time servers using <tt>
226
ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.</p>
228
<p>While not strictly a security function, the Autokey scheme
229
provides means to securely retrieve the leapsecond table from a
230
server or peer. Servers load the leapsecond table directly from the
231
file specified in the <tt>crypto</tt> command, while clients can
232
load the table indirectly from the servers using the Autokey
233
protocol. Once loaded, the table can be provided on request to
234
other clients and servers.</p>
236
<h4>Key Management</h4>
238
<p>All key files are installed by default in <tt>
239
/usr/local/etc</tt>, which is normally in a shared filesystem in
240
NFS-mounted networks and avoids installing them in each machine
241
separately. The default can be overridden by the <tt>keysdir</tt>
242
configuration command. However, this is not a good place to install
243
the private key file, since each machine needs its own file. A
244
suitable place to install it is in <tt>/etc</tt>, which is normally
245
not in a shared filesystem.</p>
247
<p>The recommended practice is to keep the timestamp extensions
248
when installing a file and to install a link from the default name
249
(without the timestamp extension) to the actual file. This allows
250
new file generations to be activated simply by changing the link.
251
However, <tt>ntpd</tt> parses the link name when present to extract
252
the extension value and sends it along with the public key and host
253
name when requested. This allows clients to verify that the file
254
and generation time are always current. However, the actual
255
location of each file can be overridden by the <tt>crypto</tt>
256
configuration command.</p>
258
<p>All cryptographic keys and related parameters should be
259
regenerated on a periodic and automatic basis, like once per month.
260
The <tt>ntp-genkeys</tt> program uses the same timestamp extension
261
for all files generated at one time, so each generation is distinct
262
and can be readily recognized in monitoring data. While a
263
public/private key pair must be generated by every server and
264
client, the public keys and agreement parameters do not need to be
265
explicitly copied to all machines in the same security compartment,
266
since they can be obtained automatically using the Autokey
267
protocol. However, it is necessary that all primary servers have
268
the same agreement parameter file. The recommended way to do this
269
is for one of the primary servers to generate that file and then
270
copy it to the other primary servers in the same compartment using
271
the Unix <tt>rdist</tt> command. Future versions of the Autokey
272
protocol are to contain provisions for an agreement protocol to do
273
this automatically.</p>
275
<p>Servers and clients can make a new generation in the following
276
way. All machines have loaded the old generation at startup and are
277
operating normally. At designated intervals, each machine generates
278
a new public/private key pair and makes links from the default file
279
names to the new file names. The <tt>ntpd</tt> is then restarted
280
and loads the new generation, with result clients no longer can
281
authenticate correctly. The Autokey protocol is designed so that
282
after a few minutes the clients time out and restart the protocol
283
from the beginning, with result the new generation is loaded and
284
operation continues as before. A similar procedure can be used for
285
the agreement parameter file, but in this case precautions must be
286
take to be sure that all machines with this file have the same
289
<h4>Authentication Commands</h4>
292
<dt><tt>autokey [<i>logsec</i>]</tt></dt>
294
<dd>Specifies the interval between regenerations of the session key
295
list used with the Autokey protocol. Note that the size of the key
296
list for each association depends on this interval and the current
297
poll interval. The default value is 12 (4096 s or about 1.1 hours).
298
For poll intervals above the specified interval, a session key list
299
with a single entry will be regenerated for every message
302
<dt><tt>controlkey <i>key</i></tt></dt>
304
<dd>Specifies the key identifier to use with the <a href=
305
"ntpq.htm"><tt>ntpq</tt></a> utility, which uses the standard
306
protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is
307
the key identifier for a trusted key, where the value can be in the
308
range 1 to 65534, inclusive.</dd>
310
<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>]
311
[publickey <i>file</i>] [dhparms <i>file</i>] [leap <i>
314
<dd>This command requires the NTP daemon build process be
315
configured with the RSA library. This command activates public-key
316
cryptography and loads the required RSA private and public key
317
files and the optional Diffie-Hellman agreement parameter file, if
318
present. If one or more files are left unspecified, the default
319
names are used as described below. Following are the
324
<dt><tt>privatekey <i>file</i></tt></dt>
326
<dd>Specifies the location of the RSA private key file, which
327
otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
329
<dt><tt>publickey <i>file</i></tt></dt>
331
<dd>Specifies the location of the RSA public key file, which
332
otherwise defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>.,
333
where <i>host</i> is the name of the generating machine.</dd>
335
<dt><tt>dhparms <i>file</i></tt></dt>
337
<dd>Specifies the location of the Diffie-Hellman parameters file,
338
which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
340
<dt><tt>leap <i>file</i></tt></dt>
342
<dd>Specifies the location of the leapsecond table file, which
343
otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
347
<dt><tt>keys <i>keyfile</i></tt></dt>
349
<dd>Specifies the location of the DES/MD5 private key file
350
containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>
351
ntpq</tt> and <tt>ntpdc</tt> when operating in symmetric-key
354
<dt><tt>keysdir <i>path</i></tt></dt>
356
<dd>This command requires the NTP daemon build process be
357
configured with the RSA library. It specifies the default directory
358
path for the private key file, agreement parameters file and one or
359
more public key files. The default when this command does not
360
appear in the configuration file is <tt>/usr/local/etc/</tt>.</dd>
362
<dt><tt>requestkey <i>key</i></tt></dt>
364
<dd>Specifies the key identifier to use with the <a href=
365
"ntpdc.htm"><tt>ntpdc</tt></a> utility program, which uses a
366
proprietary protocol specific to this implementation of <tt>
367
ntpd</tt>. The <tt><i>key</i></tt> argument is a key identifier for
368
the trusted key, where the value can be in the range 1 to 65534,
371
<dt><tt>revoke [<i>logsec</i>]</tt></dt>
373
<dd>Specifies the interval between re-randomization of certain
374
cryptographic values used by the Autokey scheme, as a power of 2 in
375
seconds. These values need to be updated frequently in order to
376
deflect brute-force attacks on the algorithms of the scheme;
377
however, updating some values is a relatively expensive operation.
378
The default interval is 16 (65,536 s or about 18 hours). For poll
379
intervals above the specified interval, the values will be updated
380
for every message sent.</dd>
382
<dt><tt>trustedkey <i>key</i> [...]</tt></dt>
384
<dd>Specifies the key identifiers which are trusted for the
385
purposes of authenticating peers with symmetric-key cryptography,
386
as well as keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt>
387
programs. The authentication procedures require that both the local
388
and remote servers share the same key and key identifier for this
389
purpose, although different keys can be used with different
390
servers. The <tt><i>key</i></tt> arguments are 32-bit unsigned
391
integers with values from 1 to 65,534.</dd>
396
<tt>ntp.keys</tt> private MD5 keys <br>
397
<tt>ntpkey</tt> RSA private key <br>
398
<tt>ntpkey_<i>host</i></tt> RSA public key <br>
399
<tt>ntp_dh</tt> Diffie-Hellman agreement parameters
403
The <tt>ntpkey_<i>host</i></tt> files are really digital
404
certificates. These should be obtained via secure directory
405
services when they become universally available.
408
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
411
<address><a href="mailto:mills@udel.edu">David L. Mills
412
<mills@udel.edu></a></address>
added
removed
html/authopt.htm
