contrib/ntp/html/authopt.htm

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
   2 <html>
   3 <head>
   4 <meta name="generator" content="HTML Tidy, see www.w3.org">
   5 <title>Authentication Options</title>
   6 </head>
   7 <body>
   8 <h3>Authentication Options</h3>
   9
  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>
  13
  14 <p>Our resident cryptographer; now you see him, now you don't.<br
  15 clear="left">
  16 </p>
  17
  18 <hr>
  19 <h4>Authentication Support</h4>
  20
  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
  32 key identifier.</p>
  33
  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>
  42
  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
  50 operations.</p>
  51
  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>
  65
  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
  79 complete.</p>
  80
  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>
  88
  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>
  96
  97 <h4>Symmetric-Key Scheme</h4>
  98
  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>
 109 utility programs.
 110
 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>
 122
 123 <h4>Public-Key Scheme</h4>
 124
 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.
 148
 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>
 161
 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>
 172
 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
 186 values.</p>
 187
 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
 197 values.</p>
 198
 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
 203 are ignored.</p>
 204
 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>
 217
 218 <h4>Leapseconds Table</h4>
 219
 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>
 227
 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>
 235
 236 <h4>Key Management</h4>
 237
 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>
 246
 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>
 257
 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>
 274
 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
 287 copy.</p>
 288
 289 <h4>Authentication Commands</h4>
 290
 291 <dl>
 292 <dt><tt>autokey [<i>logsec</i>]</tt></dt>
 293
 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
 300 sent.</dd>
 301
 302 <dt><tt>controlkey <i>key</i></tt></dt>
 303
 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>
 309
 310 <dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>]
 311 [publickey <i>file</i>] [dhparms <i>file</i>] [leap <i>
 312 file</i>]</tt></dt>
 313
 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
 320 subcommands:</dd>
 321
 322 <dd>
 323 <dl>
 324 <dt><tt>privatekey <i>file</i></tt></dt>
 325
 326 <dd>Specifies the location of the RSA private key file, which
 327 otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
 328
 329 <dt><tt>publickey <i>file</i></tt></dt>
 330
 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>
 334
 335 <dt><tt>dhparms <i>file</i></tt></dt>
 336
 337 <dd>Specifies the location of the Diffie-Hellman parameters file,
 338 which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
 339
 340 <dt><tt>leap <i>file</i></tt></dt>
 341
 342 <dd>Specifies the location of the leapsecond table file, which
 343 otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
 344 </dl>
 345 </dd>
 346
 347 <dt><tt>keys <i>keyfile</i></tt></dt>
 348
 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
 352 mode.</dd>
 353
 354 <dt><tt>keysdir <i>path</i></tt></dt>
 355
 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>
 361
 362 <dt><tt>requestkey <i>key</i></tt></dt>
 363
 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,
 369 inclusive.</dd>
 370
 371 <dt><tt>revoke [<i>logsec</i>]</tt></dt>
 372
 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>
 381
 382 <dt><tt>trustedkey <i>key</i> [...]</tt></dt>
 383
 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>
 392 </dl>
 393
 394 <h4>Files</h4>
 395
 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
 400
 401 <h4>Bugs</h4>
 402
 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.
 406
 407 <hr>
 408 <a href="index.htm"><img align="left" src="pic/home.gif" alt=
 409 "gif"></a>
 410
 411 <address><a href="mailto:mills@udel.edu">David L. Mills
 412 &lt;mills@udel.edu&gt;</a></address>
 413 </body>
 414 </html>
 415