idnits 2.17.1 draft-ietf-stime-ntpauth-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2000) is 8710 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '12' on line 33 looks like a reference -- Missing reference section? '10' on line 110 looks like a reference -- Missing reference section? '7' on line 80 looks like a reference -- Missing reference section? '1' on line 98 looks like a reference -- Missing reference section? '4' on line 98 looks like a reference -- Missing reference section? '11' on line 98 looks like a reference -- Missing reference section? '5' on line 108 looks like a reference -- Missing reference section? '6' on line 108 looks like a reference -- Missing reference section? '8' on line 163 looks like a reference -- Missing reference section? '3' on line 123 looks like a reference -- Missing reference section? '2' on line 124 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David L. Mills 3 Internet Draft University of Delaware 4 Document: < draft-ietf-stime-ntpauth-00.txt > June 2000 5 Category: Standards Track 7 Public-Key Cryptography for the Network Time Protocol 8 Version 1 10 Status of this Memorandum 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 28 This document is an Internet-Draft. 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC-2119 [12]. 34 1. Abstract 36 This memorandum describes a scheme for authenticating servers to 37 clients for the Network Time Protocol. It extends prior schemes based 38 on symmetric-key cryptography to a new scheme based on public-key 39 cryptography. The new scheme, called Autokey, is based on the premiss 40 that the IPSEC schemes proposed by the IETF cannot be adopted 41 intact,since that would preclude stateless servers and severely 42 compromise timekeeping accuracy. In addition, the IPSEC model 43 presumes timestamps are always available using authenticated means; 44 however, cryptographically verified timestamps require interaction 45 between the timekeeping function and authentication function in ways 46 not yet considered in the IPSEC model. 48 The main body of the memorandum contains a description of the 49 security model, approach rationale, protocol design and vulnerability 50 analysis. It obsoletes a previous report [10] primarily in the 51 schemes for distributing public keys and related values. A detailed 52 description of the protocol states, events and transition functions 53 is included. Detailed packet formats and field descriptions are given 54 in the appendix. A prototype of the Autokey design based on this 55 document and improvements described in this memorandum has been 56 implemented, tested and documented in the NTP Version 4 software 57 distribution for Unix, Windows and VMS. 59 While not strictly a security function, the Autokey scheme also 60 provides means to securely retrieve a table of historic leap seconds 61 necessary to convert ordinary civil time (UTC) to atomic time (TAI) 62 where needed. The tables can be retrieved either directly from 63 national time servers operated by NIST or indirectly through 64 intervening servers. 66 2. Introduction 68 A reliable distributed network service requires provisions to prevent 69 accidental or malicious attacks on the servers and clients in the 70 network. Reliability requires that clients can determine that 71 received packets are authentic; that is, were actually sent by the 72 intended server and not manufactured or modified by an intruder. 73 Ubiquity requires that any client can verify the authenticity of any 74 server using only public information. This is especially important in 75 such ubiquitous network services as directory services, cryptographic 76 key management and time synchronization. 78 The Network Time Protocol (NTP) contains provisions to 79 cryptographically authenticate individual servers as described in the 80 most recent protocol specification RFC-1305 [7]; however, that 81 specification does not provide a scheme for the distribution of 82 cryptographic keys, nor does it provide for the retrieval of 83 cryptographic media that reliably bind the server identification 84 credentials with the associated keys and related public values. 85 However, conventional key agreement and digital signatures with large 86 client populations can cause significant performance degradations, 87 especially in time critical applications such as NTP. In addition, 88 there are problems unique to NTP in the interaction between the 89 authentication and synchronization functions, since each requires the 90 other. 92 This memorandum describes a cryptographically sound and efficient 93 methodology for use in NTP and similar distributed protocols. As 94 demonstrated in the reports and briefings cited in the references at 95 the end of this memorandum, there is a place for Public-Key 96 Infrastructure (PKI) and related schemes, but none of these schemes 97 alone satisfies the requirements of the NTP security model. The 98 various key agreement schemes [1, 4, 11] proposed by the IETF require 99 per-association state variables, which contradicts the principles of 100 the remote procedure call (RPC) paradigm in which servers keep no 101 state for a possibly large client population. An evaluation of the 102 PKI model and algorithms as implemented in the rsaref2.0 package 103 formerly distributed by RSA Laboratories leads to the conclusion that 104 any scheme requiring every NTP packet to carry a PKI digital 105 signature would result in unacceptably poor timekeeping performance. 107 A revised security model and authentication scheme called Autokey was 108 proposed in earlier reports [5, 6, 8]. It has been evolved and 109 refined since then and implemented in NTP Version 4 for Unix, Windows 110 and VMS [10]. It is based on a combination of PKI and a pseudo-random 111 sequence generated by repeated hashes of a cryptographic value 112 involving both public and private components. This scheme has been 113 tested and evaluated in a local environment and is being deployed now 114 in the CAIRN experiment network funded by DARPA. A detailed 115 description of the security model, design principles and 116 implementation experience is presented in this memorandum. 118 3. Security Model 120 Over the last several years the IETF has defined and evolved the 121 IPSEC infrastructure for the protection of privacy and authentication 122 of sources in the Internet, The infrastructure includes the 123 Encapsulating Security Payload (ESP) [3] and Authentication Header 124 (AH) [2] for IPv4 and IPv6. Cryptographic algorithms that use these 125 headers for various purposes include those developed for the PKI, 126 including MD5 message digests, RSA digital signatures and several 127 variations of Diffie-Hellman key agreements. The fundamental 128 assumption in the security model is that packets transmitted over the 129 Internet can be intercepted by other than the intended receiver, 130 remanufactured in various ways and replayed in whole or part. These 131 packets can cause the client to believe or produce incorrect 132 information, cause protocol operations to fail, interrupt network 133 service or consume processor resources with needless cryptographic 134 calculations. 136 In the case of NTP, the assumed goal of the intruder is to inject 137 false time values, disrupt the protocol or clog the network and 138 receiver with spurious packets that exhaust resources and deny 139 service to legitimate processes. The mission of the algorithms and 140 protocols described in this memorandum is to detect and discard 141 spurious packets sent by other than the intended sender or sent by 142 the intended sender but modified or replayed by an intruder. The 143 cryptographic means of the reference implementation are based on the 144 rsaref2.0 algorithms, but other algorithms with equivalent 145 functionality could be used as well. It is important for distribution 146 purposes that the way in which these algorithms are used precludes 147 encryption of any data other than incidental to the construction of 148 digital signatures. 150 There are a number of defense mechanisms already built in the NTP 151 architecture, protocol and algorithms. The fundamental timestamp- 152 exchange scheme is inherently resistant to replay attacks. The 153 engineered clock filter, intersection and clustering algorithms are 154 designed to fend off Byzantine sources and cliques. While not 155 necessarily designed to defeat determined intruders, these algorithms 156 and accompanying eleven sanity checks have functioned well over the 157 years to deflect improperly operating but presumably friendly 158 scenarios. 160 However, these mechanisms do not securely identify and authenticate 161 the servers themselves. Without specific further protection, an 162 intruder can do any or all of the following mischiefs. Further 163 discussion on the assumed intruder model is given in [8], but beyond 164 the scope of this memorandum. 166 1. An intruder can intercept and archive packets forever and can 167 archive all the public values ever generated and transmitted over the 168 net. 170 2. An intruder can generate packets faster than the server or client 171 can process them if they require expensive PKI operations. 173 3. An intruder can intercept, modify and replay a packet. However, it 174 cannot permanently prevent packet transmission over the net; that is, 175 it cannot break the wire, only congest it. 177 The following assumptions are fundamental to the Autokey design. They 178 are discussed at some length in the briefing slides and links at 179 www.eecis.udel.edu/~mills/ntp.htm and will not be further discussed 180 in this memorandum. 182 1. The running times for public-key algorithms are relatively long 183 and highly variable. In general, the performance of the 184 synchronization function is badly degraded if these algorithms must 185 be used for every NTP packet. 187 2. In some modes of operation it is not feasible for a server to 188 retain cryptographic state variables for every client. It is however 189 feasible to regenerated them for a client upon arrival of a packet 190 from that client. 192 3. The lifetime of cryptographic values must be enforced, which 193 requires a reliable system clock. However, the sources that 194 synchronize the system clock must be cryptographically authenticated. 195 This circular interdependence of the timekeeping and authentication 196 functions requires special handling. 198 4. All authentication functions must involve only public values 199 transmitted over the net. Private values must never be disclosed 200 beyond the machine on which they were created. 202 5. Public keys and agreement parameters, where necessary, must be 203 retrievable directly from servers without requiring secured channels; 204 however, the fundamental security of identification credentials and 205 public values bound to those credentials must eventually be a 206 function of certificate authorities and webs of trust. 208 4. Approach 210 The Autokey protocol described in this memorandum is designed to meet 211 the following objectives. Again, in-depth discussions on these 212 objectives is in the web briefings and will not be elaborated in this 213 memorandum. 215 1. It must interoperate with the existing NTP architecture model and 216 protocol design. In particular, it must support the symmetric-key 217 scheme described in RFC-1305. As a practical matter, the reference 218 implementation must use the same internal key management system, 219 including the use of 32-bit key IDs and existing mechanisms to store, 220 activate and revoke keys. 222 2. It must provide for the independent collection of cryptographic 223 values and time values. A client is synchronized to an authentic 224 source only when the all cryptographic values have been obtained and 225 verified and the NTP timestamps have passed all sanity checks. 227 3. It must not significantly degrade the potential accuracy of the 228 NTP synchronization algorithms. In particular, it must not make 229 unreasonable demands on the network or host processor and memory 230 resources. 232 4. It must be resistant to cryptographic attacks, including 233 replay/modification and clogging attacks. In particular, it must be 234 tolerant of operation or implementation variances, such as packet 235 loss or misorder, or suboptimal configuration. 237 5. It must build on a widely available suite of cryptographic 238 algorithms, yet be independent of the particular choice. In 239 particular, it must not require data encryption other than incidental 240 to signature and verification functions. 242 6. It must function in all the modes supported by NTP, including 243 client/server, multicast/manycast and symmetric active/passive modes. 245 7. It must not require intricate per-client or per-server 246 configuration other than the availability of public/private key files 247 and agreement parameter files, as required. 249 8. The reference implementation must contain provisions to generate 250 cryptographic key values, including private/public keys and agreement 251 parameters specific to each client and server. Eventually, it must 252 contain provisions to validate public values using certificate 253 authorities and webs of trust. 255 4.1 Autokey Authentication Scheme 257 The Autokey public-key cryptography is based on the PKI algorithms of 258 the rsaref2.0 library, although other libraries with a compatible 259 interface could be used as well. The reference implementation uses 260 MD5 message digests to detect packet modification, timestamped RSA 261 digital signatures to verify the source, and Diffie-Hellman key 262 agreements to construct a private key from public values. However, 263 there is no reason why alternative signature schemes and agreement 264 algorithms could be supported. What makes the Autokey scheme unique 265 is the way in which these algorithms are used to deflect intruder 266 attacks while maintaining the integrity and accuracy of the time 267 synchronization function. 269 The NTP Version 3 symmetric-key cryptography uses keyed-MD5 message 270 digests with a 128-bit private key and 32-bit key ID. In order to 271 retain backward compatibility, the key ID space is partitioned in two 272 subspaces at a pivot point of 65536. Symmetric key IDs have values 273 less than 65536 and indefinite lifetime. Autokey keys have pseudo- 274 random values equal to or greater than 65536 and are expunged 275 immediately after use. 277 There are three Autokey protocol variants corresponding to each of 278 the three NTP modes: client/server, multicast/manycast and symmetric 279 active/passive. All three variants make use of a specially contrived 280 session key called an autokey and a pseudo-random sequence of key Ids 281 called the key list. As in the original NTP Version 3 authentication 282 scheme, the Autokey scheme operates separately for each association, 283 so there may be several key lists operating independently at the same 284 time and with associated values and signatures. 286 An autokey consists of four 32-bit fields in the network order shown 287 below: 289 +-----------+-----------+-----------+-----------+ 290 | Source IP | Dest IP | key ID | cookie | 291 +-----------+-----------+-----------+-----------+ 293 The source and destination IP addresses and key ID are public values 294 visible in the packet, while the cookie can be a public value or a 295 private value, depending on the mode. 297 The NTP packet format has been augmented to include one or more 298 extension fields piggybacked between the original NTP header and the 299 message authenticator code (MAC) at the end of the packet. For 300 packets without extension fields, the cookie is a private value 301 computed by an agreement algorithm. For packets with extension 302 fields, the cookie is a public value (0), since these packets can be 303 validated independently using signed data in an extension field. The 304 four values are hashed by the message digest algorithm to produce the 305 actual key value, which is stored along with the key ID in a cache 306 used for symmetric keys as well as autokeys. Keys are retrieved from 307 the cache by key ID using hash tables and a fast algorithm. 309 The key list consists of a sequence of key IDs starting with a random 310 value and each pointing to the next. To generate the next autokey on 311 the key list, the next key ID is the first 32 bits of the previous 312 key value. It may happen that a newly generated key ID is less than 313 65536 or collides with another one already generated. When this 314 happens, which can occur only rarely, the key list is terminated at 315 that point. The lifetime of each key is set to expire one poll 316 interval after its scheduled use. In the reference implementation, 317 the list is terminated when the maximum key lifetime is about one 318 hour. 320 The index of the last key ID in the list is saved along with the next 321 key ID of that entry, collectively called the autokey values. The 322 list is used in reverse order, so that the first key ID used is the 323 last one generated. The autokey protocol includes a message to 324 retrieve the autokey values and signature, so that subsequent packets 325 can be authenticated using one or more hashes that eventually match 326 the first key ID (valid) or exceed the index (invalid). In the 327 reference implementation the most recent key ID received is saved for 328 comparison with the first 32 bits of the next following key value. 329 This minimizes the number of hash operations in case a packet is 330 lost. 332 In client/server mode the server keeps no state for each client, but 333 uses a fast algorithm and a private value to regenerate the cookie 334 upon arrival of a client packet. The cookie is calculated in a manner 335 similar to the autokey, where the key ID field is zero and the cookie 336 field is the private value. The first 32 bits of the hash is the 337 cookie used for the actual autokey calculation and is returned to the 338 client on request. It is thus specific to each client separately and 339 of no use to other clients or an intruder. A client obtains the 340 cookie and signature using the Autokey protocol and saves it for 341 later use. 343 In client/server mode the cookie is a relatively weak function of the 344 IP addresses and a server private value. The client uses the cookie 345 and each key ID on the key list in turn to calculate the MAC for the 346 next NTP packet. The server calculates these values and checks the 347 MAC, then generates the MAC for the response using the same values, 348 but with the IP addresses reversed. The client calculates and checks 349 the MAC and verifies the key ID matches the one sent. In this mode 350 the sequential structure of the key list is not exploited, but doing 351 it this way simplifies and regularizes the implementation. 353 In multicast/manycast mode, clients normally do not send packets to 354 the server, except when first starting up to calibrate the 355 propagation delay in client/server mode. At the same time the client 356 temporarily authenticates as in that mode. After obtaining and 357 verifying the cookie, the client continues to obtain and verify the 358 autokey values. To obtain these values, the client must provide the 359 ID of the particular server association, since there can be more than 360 one operating in the same machine. For this purpose, the multicast 361 server includes the association ID in every packet sent, except when 362 sending the first packet after generating a new key list, when it 363 sends the autokey values instead. 365 In symmetric mode each peer keeps state variables related to the 366 other, so that a private cookie can be computed by a strong agreement 367 algorithm. The cookie itself is the first 32 bits of the agreed key. 368 The key list for each direction is generated separately by each peer 369 and used independently. 371 The server authentic bit is set only when the cookie or autokey 372 values, depending on mode, and signature are both valid. If the bit 373 is set, the client sends valid timestamps in signed responses. If the 374 bit is not set, the data and signature are processed in order to run 375 the Autokey protocol, but the NTP time values are ignored. Packets 376 with old timestamps are discarded immediately while avoiding 377 expensive cryptographic algorithms. Bogus packets with newer 378 timestamps must pass the MAC and autokey tests, which is highly 379 unlikely. 381 Once the authentic bit is set, the NTP time values are processed, so 382 that eventually the client will synchronize to an authentic source. 383 In client/server and symmetric modes, packets are normally sent 384 without an extension field, unless the packet is the first one sent 385 after generating a new key list or unless the client has requested 386 the cookie or autokey values. If for some reason the client clock is 387 stepped, rather than slewed, all cryptographic data and time values 388 for all associations are cleared and the synchronization and 389 authentication procedures start over from scratch. This insures that 390 old cryptographic and synchronization values never propagate beyond a 391 clock reset. 393 4.2 Public-Key Signatures 395 Since public-key signatures provide strong protection against 396 misrepresentation of sources, probably the most obvious intruder 397 strategy is to deny or restrict service by replaying old packets with 398 signed cryptographic values in a cut-and-paste attack. The basis 399 values on which the cryptographic operations depend are changed often 400 to deflect brute force cryptanalysis, so the client must be prepared 401 to abandon an old key in favor of a refreshed one. This invites the 402 opportunity for an intruder to clog the client or server by replaying 403 old Autokey messages or to invent bogus new ones. A client receiving 404 such messages might be forced to refresh the correct value from the 405 legitimate server and consume significant processor resources. 407 In order to foil such attacks, every extension field carries a 408 timestamp in the form of the NTP seconds at the signature time. The 409 signature includes the timestamp itself together with optional 410 additional data. If the Autokey protocol has verified the source is 411 authentic and the NTP algorithms have validated the time values, the 412 system clock is synchronized and signatures carry a nonzero (valid) 413 timestamp. Otherwise the system clock is unsynchronized and 414 signatures carry a zero (invalid) timestamp. Extension fields with 415 invalid or old timestamps are discarded before any values are used or 416 signatures verified. 418 There are three signature types: 420 1. The public agreement value is signed at the time of generation, 421 which occurs when the system clock is first synchronized and about 422 once per day after that in the reference implementation. For 423 convenience, the public key/host name, agreement parameters and leap 424 table signatures are recomputed at the same time as the public value 425 signature and carries the same timestamp. On request, each of these 426 values and associated signatures and timestamps are returned in an 427 extension field. 429 2. The cookie value is computed and signed upon arrival of a request 430 message. On request, the cookie, signature and timestamp are returned 431 in an extension field. 433 3. The autokey values are signed when a new key list is generated, 434 which occurs about once per hour in the reference implementation. On 435 request, the autokey values, signature and timestamp are returned in 436 an extension field. 438 The most recent timestamp for each of the three signature types is 439 saved for comparison. Once a signature with valid timestamp has been 440 received, packets carrying extension fields with invalid timestamps 441 or older valid timestamps of the same type are discarded before any 442 values are used or signatures verified. For packets containing signed 443 extension fields, the timestamp deflects replays that otherwise might 444 consume significant processor resources; for other packets the 445 Autokey protocol deflects message modification and replay. In 446 addition, the NTP protocol itself is inherently resistant to replays 447 and consumes only minimal processor resources. 449 While files carrying cryptographic data not specifically signed, the 450 file names have timestamp extensions which reliably determine the 451 time of generation. As the data are forwarded from machine to 452 machine, the filestamps are preserved. This can in principle be used 453 as a total ordering function to verify that the data are consistent 454 and represent the latest available generation. For this reason, the 455 files should always be generated on a machine when the system clock 456 is valid. 458 In order to further reduce the window of opportunity, even for a 459 fanatical intruder, additional causality constraints can be checked. 461 1. If the system clock if valid, all timestamps and filestamps must 462 be earlier than the current clock time. 464 2. All signature timestamps must be later than the public key 465 timestamp. 467 3. In multicast client mode, the cookie timestamp must be later than 468 the autokey timestamp. 470 4. In symmetric modes the autokey timestamp must be later than the 471 public value timestamp. 473 5. Timestamps for each cryptographic data type must be later than the 474 filestamps for that type. 476 In the above constraints, note the public key timestamp and signature 477 timestamps have a granularity of one second, so that a timestamp 478 difference of zero seconds is ambiguous. Furthermore, timestamps can 479 be in error as much as the value of the synchronization distance; 480 that is, the sum of the root dispersion plus one-half the root delay. 481 However, the NTP protocol operates with polling intervals much longer 482 than one second, so that successive timestamps for the same data type 483 can never by ambiguous. 485 4.3 Filestamps 487 All cryptographic values used by the protocol are time sensitive and 488 are regularly refreshed. In particular, files containing 489 cryptographic basis values used by signature and agreement algorithms 490 are regenerated from time to time. It is the intent that file 491 regeneration and loading of these values occur without specific 492 warning and without requiring distribution in advance. For these 493 reasons, the name of every cryptographic value file includes a 494 filestamp consisting of the decimal NTP seconds at the time of 495 generation. 497 When a client or server initializes, it reads its own public and 498 private key files, which are required for continued operation. 499 Optionally, it reads the agreement parameter file and constructs the 500 public and private values to be used later in the agreement protocol. 501 Also optionally, it reads the leap table file. When loading these 502 files it checks the filestamps for consistency and validity. When the 503 client is eventually synchronized to an authentic source, it checks 504 the filestamps for validity relative to the system clock time. If the 505 filestamps are later than the clock time, something is seriously 506 wrong and either the time has synchronized in error or the data files 507 are defective. 509 When a client mobilizes an association, it retrieves the server host 510 name and public key from the server using the Autokey protocol. 511 Optionally, it retrieves the agreement parameters and leap table, if 512 required, and constructs the public and private values. Optionally, 513 and before going further, it verifies the server credentials using 514 certificate authorities and a web of trust. As above, when the client 515 is eventually synchronized to an authentic source, it again checks 516 the filestamps for validity. 518 4.4 Error Recovery 520 The protocol state machine which drives the various autokey functions 521 includes provisions for various kinds of error conditions that can 522 arise due to missing key or agreement parameter files, corrupted 523 data, protocol state mismatches and packet loss or misorder, not to 524 mention hostile intrusion. There are two mechanisms which maintain 525 the liveness state of the protocol, the reachability register defined 526 in RFC-1305 and the watchdog timer, which is new in NTP Version 4. 528 The reachability register is an 8-bit register that shifts left with 529 zero replacing the rightmost bit. A shift occurs for every poll 530 interval, whether or not a poll is actually sent. If an arriving 531 packet passes all authentication and sanity checks, the rightmost bit 532 is set to one. Thus, the pattern of ones and zeros in this register 533 reveals the reachability status of the server for the last eight poll 534 intervals. 536 With respect to the issues at hand, if this register is nonzero, the 537 server is reachable, otherwise it is unreachable. If the server was 538 once reachable and then becomes unreachable, a general reset is 539 performed. A general reset reinitializes all association variables to 540 the state when first mobilized and returns all acquired resources to 541 the system. In addition, if the association is not configured, it is 542 demobilized until the next server packet is received. 544 The watchdog timer increments for every poll interval, whether or not 545 a poll is actually sent and regardless of the reachability state. The 546 counter is set to zero upon arrival of a cryptographically 547 authenticated packet, as determined by the Autokey protocol. In the 548 reference implementation, if the counter reaches 16 a general reset 549 is performed. 550 In addition, if the association is configured, the poll interval is 551 doubled. This reduces the network load for packets that are unlikely 552 to elicit a response. 554 The general approach to Autokey error recovery is to retry the 555 request message at intervals of about one minute until the watchdog 556 timer expires and then restart the protocol from the beginning. At 557 each state in the protocol the client expects a particular variable 558 to be received from the server. A NTP packet including the 559 appropriate request is sent at every poll interval until the variable 560 is received or a general reset occurs. While this behavior might be 561 considered rather conservative, the advantage is that old 562 cryptographic values can never persist from one mobilization to the 563 next. 565 There are a number of situations where some action causes the 566 remaining autokeys on the key list to become invalid. When one of 567 these situations happens, the key list and associated keys in the key 568 cache are purged. 569 A new key list is generated when the next NTP message is sent, 570 assuming there is one. Following is a list of these situations. 572 1. When a client switches from client/server mode to multicast client 573 mode. There is no further need for the key list, since the client 574 will not transmit again. 576 2. When the poll interval is changed in an association. In this case 577 the calculated expiration times for the keys become invalid. 579 3. When a general reset is performed in an association. 581 4. If a problem is detected when an entry is fetched from the key 582 list for an association. This could happen if the key was marked non- 583 trusted or timed out, either of which implies a software bug. 585 5. When the cryptographic values are refreshed, the key lists for all 586 associations are regenerated. 588 6. When the client is first synchronized to an authentic source or 589 the system clock is stepped, the key lists for all associations are 590 regenerated. 592 5 Autokey Protocols 594 This section describes the Autokey protocols supporting 595 cryptographically secure server and peer authentication. There are 596 three protocols corresponding to the NTP client/server, 597 multicast/manycast and symmetric active/passive modes. 599 In the descriptions below, it is assumed that the client has the 600 public key and agreement parameters, where required, for the server. 601 These data can be loaded from local files or automatically retrieved 602 from the server as described later in this memorandum. Further 603 information on generating and managing these files is in Appendix B. 605 The Autokey protocol data unit is the extension field, which contains 606 either a request with optional data or a response with data. To avoid 607 deadlocks, any number of responses can be included in a packet, but 608 only one request. Some requests and most responses are protected by 609 timestamped signatures. The signature covers the data, timestamp, 610 which is set valid (nonzero) only if the sender is synchronized to an 611 authentic source. An extension fields are discarded before the 612 signature is verified if a signature timestamp is the same as or 613 earlier than the last received timestamp of the same type. 615 An extension field is also discarded if a protocol or procedure error 616 occurs or the required cryptographic data are incomplete or 617 unavailable or the field values are inconsistent with these data. 618 Otherwise and in general, a response is generated for every request, 619 even if the requestor is not synchronized to an authentic source. 620 However, some responses may have truncated data fields under certain 621 conditions, although the signatures are always present and 622 verifiable. 624 5.1 Client/Server Modes (3/4) 626 In client/server modes the server keeps no state variables specific 627 to each of possibly very many clients and mobilizes no associations. 628 The server regenerates a cookie for each packet received from the 629 client. For this purpose, the cookie is hashed from the IP addresses 630 and private value with the key ID field set to zero, as described 631 previously. Both the client and server use the cookie to generate the 632 autokey which validates each packet received. To further strengthen 633 the validation process, the client selects a new key ID for every 634 packet and verifies that it matches the key ID in the server response 635 to that packet. 637 The following diagram shows the protocol dance in client/server mode. 638 In this and following diagrams the NTP packet type is shown above the 639 arrow and the extension field(s) message type shown below. There are 640 three cryptographic values instantiated by the dance: the cookie, 641 signature timestamp and authentic bit. 643 server client 644 | | 645 | NTP client | 646 1 |<-----------------| mobilize association; generate key list; 647 | cookie req | DNS lookup for canonical name, certificate 648 | | and public key 649 | NTP server | 650 2 |----------------->| store cookie; verify server credentials 651 | cookie rsp | 652 | ... | 653 | | 654 | NTP client | 655 3 |<-----------------| 656 | | 657 | NTP server | 658 4 |----------------->| 659 | | 660 | continue | 661 = client/server = 663 The dance begins when the client on the right sends a packet (1) 664 including a cookie request to the server on the left. The server 665 immediately responds with the cookie, signature and timestamp. Upon 666 arrival of this packet (2), the client checks the timestamp, verifies 667 the signature and, if successful, initializes the cookie and 668 signature timestamp and sets the authentic bit. The client will 669 retransmit packet (1) until receiving a valid timestamp and verified 670 signature (2) or until association timeout. 672 After successful verification, there is no further need for extension 673 fields, unless an error occurs or the server generates a new private 674 value. When this happens, the server fails to authenticate the packet 675 (3) and, following the original NTP protocol, responds with a NAK 676 packet (4), which the client ignores. Eventually, a general reset 677 occurs and the dance restarts from the beginning. 679 5.2 Multicast/Manycast Mode (5) 681 In multicast mode, packets are always sent with an extension field. 682 Since the autokey values for these packets use a well known cookie 683 (zero), they can in principle be remanufactured with a new MAC 684 acceptable to the receiver; however, the key list provides the 685 authentication function as described earlier. The multicast server 686 keeps no state variables specific to each of possibly very many 687 clients and mobilizes no associations for them. The server on the 688 left in the diagram below sends packets that are received by each of 689 a possibly large number of clients, one of which is shown on the 690 right. Ordinarily, clients do not send packets to the server, except 691 to calibrate the propagation delay and to obtain cryptographic values 692 such as the cookie and autokey values. 694 The following diagram shows the protocol dance in multicast mode. 695 There are four cryptographic values instantiated by the dance: the 696 signature timestamp, cookie, autokey values and authentic bit. 698 server client 699 | | 700 | NTP multicast | 701 1 |----------------->| mobilize association; generate key list; 702 | assoc ID rsp | reverse DNS lookup for canonical name, 703 | ... | certificate and public key 704 | | 705 | NTP client | 706 2 |<-----------------| 707 | cookie req | 708 | | 709 | NTP server | 710 3 |----------------->| store cookie; verify server credentials 711 | cookie rsp | 712 | ... | 713 | | 714 | NTP client | 715 4 |<-----------------| 716 | autokey req | 717 | | 718 | NTP server | 719 5 |----------------->| store autokey 720 | autokey rsp | 721 | ... | 722 | | 723 | NTP client | 724 |<-----------------| 725 | | 726 | NTP server | 727 |----------------->| 728 | | 729 | continue | 730 = volley = 731 | | 732 | NTP client | 733 |<-----------------| 734 | | 735 | NTP server | 736 |----------------->| initialize delay estimate; discard cookie 737 | | and remaining keys; switch to multicast 738 | | client mode 739 | continue | 740 = multicast = 741 | | 742 | NTP multicast | 743 |----------------->| server rolls new key list; client refreshes 744 | autokey rsp | autokey 745 | signature | 746 = = 748 The server sends multicast packets continuously at intervals of about 749 one minute (1) using the key list and regenerating the list as 750 required. The first packet sent after regenerating the list includes 751 an extension field containing the autokey values and signature; other 752 packets include an extension field containing only the association 753 ID. 755 Upon arrival of the first packet (1), the multicast client mobilizes 756 an association and loads the canonical name and public key as 757 described above. Alternately, it queries the DNS and loads the 758 canonical name, certificate and server public key. 760 Some time later the client generates a key list and sends a packet 761 (2) requesting the cookie as in client/server mode. The server 762 immediately responds (3) with the cookie, signature and timestamp. 763 The client checks the timestamp, verifies the signature and, if 764 successful, initializes the cookie and signature timestamp. The 765 client retransmits packet (2) until receiving a valid timestamp and 766 verified signature (3) or until a general reset occurs. 768 If an autokey response happens to be in one of the server packets (1, 769 3), the client can switch to multicast client mode and send no 770 further packets. Otherwise, some time later the client sends a packet 771 (4) requesting the autokey values. The server immediately responds 772 (5) with the values. The client checks the timestamp, verifies the 773 signature and, if successful, initializes the autokey values and 774 signature timestamp and sets the authentic bit. The client 775 retransmits packet (4) until receiving a valid timestamp and verified 776 signature (5) or until a general reset occurs. 778 After successful verification, there is no further need for extension 779 fields, unless the server regenerates the cookie or the server 780 regenerates the key list and the Autokey response message happens to 781 be lost. When this happens, the server fails to authenticate the 782 packets (1). Eventually, a general reset occurs and the dance 783 restarts from the beginning. However, it is the usual practice to 784 send additional client/server packets in order for the client 785 mitigation algorithms to refine the clock offset/delay estimates. 786 When a sufficient number of estimates have been accumulated, the 787 client discards the cookie and remaining keys on the key list, 788 switches to multicast client mode and sets the clock. 790 5.3 Symmetric Active/Passive Mode (1/2) 792 In symmetric modes there is no explicit client/server relationship, 793 since each peer in the relationship can operate as a server with the 794 other operating as a client. The particular choice of server depends 795 on which peer has the smallest root synchronization distance to its 796 ultimate reference source, and the choice may change from time to 797 time. 799 There are two protocol scenarios involving symmetric modes. The 800 simplest scenario is where both peers have configured associations 801 that operate continuously in symmetric-active mode and cryptographic 802 values such as host name and public key can be configured in advance. 803 The other scenario is when one peer operates with a configured 804 association and begins operation with another peer without a 805 configured association and begins operation in symmetric-passive 806 mode. 808 The following diagram shows the protocol dance in symmetric- 809 active/passive mode. The exchange is similar in the symmetric- 810 active/active mode, although the order can change depending on which 811 peer starts the dance. There are four cryptographic values 812 instantiated by the dance: the signature timestamp, cookie, autokey 813 values and authentic bit. 815 active passive 816 | | 817 | NTP active | 818 1 |----------------->| mobilize association; query DNS for 819 | public rsp | canonical name, certificate and public key; 820 | | verify public signature, compute and 821 | public req | initialize agreed key 822 | ... | 823 | | 824 | NTP passive | 825 2 |<-----------------| 826 | public rsp | 827 | autokey req | 828 | ... | 829 | | 830 | NTP active | 831 3 |----------------->| verify autokey signature, initialize 832 | autokey rsp | autokey key; sign public values 833 | autokey req | 834 | ... | 835 | | 836 | NTP passive | 837 4 |<-----------------| 838 | autokey rsp | 839 | ... | 840 | | 841 | NTP active | 842 |----------------->| regular operation 843 | ... | 844 | | 845 | NTP passive | 846 |<-----------------| 847 | | 848 | continue | 849 = active/passive = 851 The dance begins when the active peer on the left in the diagram 852 sends a packet (1) to the passive peer on the right. Before sending 853 the first packet, the active peer generates a key list using the 854 default key (zero) and initializes the autokey values and signature 855 along with the public agreement value and signature. 857 The first packet from the active peer includes its public value and 858 signature along with a request for the public value of the passive 859 peer. Upon arrival of this packet, the passive peer mobilizes an 860 association and loads the canonical name and public key as described 861 above. Alternately, it queries the DNS and loads the canonical name, 862 certificate and public key of the active peer. The passive peer 863 checks the timestamp, verifies the signature and, if successful, 864 executes the agreements algorithm and initializes the cookie and 865 signature timestamp. As the cookie affects the autokey values, the 866 key list is regenerated with the cookie. The active peer retransmits 867 packet (1) until receiving a valid public value (2) or until a 868 general reset occurs. 870 Some time later the passive peer sends a packet (2) to the active 871 peer including its public value and signature along with a request 872 for the autokey values of the active peer. Upon arrival of this 873 packet, the active peer checks the timestamp, verifies the signature 874 and, if successful, executes the agreements algorithm and initializes 875 the cookie and signature timestamp. As the cookie affects the autokey 876 values, the key list is regenerated with the cookie. The passive peer 877 retransmits packet (2) until receiving a valid autokey values (3) or 878 until a general reset occurs. 880 Some time later the active peer sends a packet (3) to the passive 881 peer including its autokey values and signature along with a request 882 for the autokey values of the passive peer. Upon arrival of this 883 packet, the passive peer checks the timestamp, verifies the signature 884 and, if successful, initializes the autokey values and sets its 885 authentic bit. The active peer retransmits packet (3) until receiving 886 a valid autokey values (4) or until a general reset occurs. 888 Some time later the passive peer sends a packet (4) to the active 889 peer including its autokey values and signature. Upon arrival of this 890 packet, the active peer checks the timestamp, verifies the signature 891 and, if successful, initializes the autokey values and sets the 892 authentic bit. 894 After successful verification, there is no further need for extension 895 fields, unless an error occurs or one of the peers generates new 896 public values. The protocol requires that, if a peer receives a 897 public value resulting in a different cookie, it must send its own 898 public value. Since the autokey values are included in an extension 899 field when a new key list is generated, there is ordinarily no need 900 to request these values, unless one or the other peer restarts the 901 protocol or the packet containing the autokey values is lost. In any 902 case, the request will be retransmitted at intervals until a general 903 reset occurs. 905 6. Additional Protocols 907 While not mentioned in the above protocol descriptions, there are 908 provisions to negotiate the algorithms and algorithm parameters, 909 retrieve the public key and host name, and retrieve the agreement 910 parameters and ancillary data using the defined requests summarized 911 in Appendix A. Ordinarily, a client or peer requests the public key 912 and host name in the first message from an association to a server or 913 peer. The response includes the filestamp and is signed by the server 914 using its private key. The signature and filestamp is useful to 915 confirm the correct key generation and to verify correct procedure. 917 Each association requiring public key authentication cannot proceed 918 until the response has been received. 920 The NIST provides a table showing the epoch for all occasions of leap 921 second insertions since 1972. The table is maintained in a file 922 called pub/leap-seconds and available for anonymous FTP download. 923 While not strictly a security function, the table can be retrieved 924 from an NTP server using the Autokey protocol if the feature is 925 enabled. If enabled and the leap table is not available, a request is 926 included in the next Autokey message. The response includes the 927 original filestamp generated by the NIST and is signed and 928 timestamped. Note that the table will be requested by all 929 associations, either configured or not; but, none of the associations 930 can proceed until one of them has received the response. After this, 931 the table can be provided on request to other clients and servers. 933 If any associations are operating in symmetric modes, the agreement 934 parameters are required to complete the protocol. If the parameters 935 are needed and not currently available, they are requested in the 936 next message. The response includes the original filestamp and is 937 signed as before. Note that the parameters will be requested by all 938 associations needing them, either configured or not; but, none of the 939 associations can proceed until one of them has received the response. 940 After this, the parameters can be provided on request to other 941 clients and servers. 943 7 Security Analysis 945 This section discusses the most obvious security vulnerabilities in 946 the various modes and phases of operation. Throughout the discussion 947 the cryptographic algorithms themselves are assumed secure; that is, 948 a successful brute force attack on the algorithms or public/private 949 keys or agreement parameters is unlikely. However, vulnerabilities 950 remain in the way the actual cryptographic data, including the cookie 951 and autokey values, are computed and used. 953 Some observations on the particular engineering constraints of the 954 Autokey protocol are in order. First, the number of bits in some 955 cryptographic values are considerably smaller than would ordinarily 956 be expected for strong cryptography. One of the reasons for this is 957 the need for compatibility with previous NTP versions; another is the 958 need for small and constant latencies and minimal processing 959 requirements. Therefore, what the scheme gives up on the strength of 960 these values must be regained by agility in the rate of change of the 961 cryptographic basis values. Thus, autokeys are used only once and 962 basis values are regenerated frequently. However, in most cases even 963 a successfulcryptanalysis of these values compromises only a 964 particular client/server association and does not represent a danger 965 to the general population. 967 There are three tiers of defense against hostile intruder 968 interference. The first is the message authentication code (MAC) 969 based on a keyed message digest or autokey generated as the hash of 970 the IP address fields, key ID field and a special cookie, which can 971 be public or the result of an agreement algorithm. If the message 972 digest computed by the client does not match the value in the MAC, 973 either the autokey used a different cookie than the server or the 974 packet was modified by an intruder. Packets that fail this test are 975 discarded without further processing; in particular, without spending 976 processor cycles on expensive public-key algorithms. 978 The second tier of defense involves the key list, which is generated 979 as a repeated hash of autokeys and used in the reverse order. While 980 any receiver can authenticate a message by hashing to match a 981 previous key ID, as a practical matter an intruder cannot predict the 982 next key ID and thus cannot spoof a packet acceptable to the client. 983 In addition, tedious hashing operations provoked by replays of old 984 packets are suppressed because of the basic NTP protocol design. 985 Finally, spurious public-key computations provoked by replays of old 986 packets with extension fields are suppressed because of the signature 987 timestamp check. 989 The third tier of defense is represented by the Autokey protocol and 990 extension fields with timestamped signatures. The signatures are used 991 to reliably bind the autokey values to the private key of a trusted 992 server. Once these values are instantiated, the key list 993 authenticates each packet relative to its predecessors and by 994 induction to the instantiated autokey values. 996 In addition to the three-tier defense strategy, all packets are 997 protected by the NTP sanity checks. Since all packets carry time 998 values, replays of old or bogus packets can be deflected once the 999 client has synchronized to authentic sources. However, the NTP sanity 1000 checks are only effective once the packet has passed all 1001 cryptographic tests. This is why the signature timestamp is necessary 1002 to avoid expensive calculations that might be provoked by replays. 1003 Since the signature and verify operations have a high manufacturing 1004 cost, in all except client/server modes the protocol design protects 1005 against a clogging attack by signing cryptographic values only when 1006 they are created or changed and not on request. 1008 7.1 Specific Attacks 1010 While the above arguments suggest that the vulnerability of the 1011 Autokey protocols to cryptanalysis is suitably hard, the same cannot 1012 be said about the vulnerability to a replay or clogging attack, 1013 especially when a client is first mobilized and has not yet 1014 synchronized to an authentic source. In the following discussion a 1015 clogging attack is considered a replay attack at high speed which can 1016 clog the network and deny service to other network users or clog the 1017 processor and deny service to other users on the same machine. While 1018 a clogging attack can be concentrated on any function or algorithm of 1019 the Autokey protocol, the must vulnerable target is the public key 1020 routines to sign and verify public values. It is vital to shield 1021 these routines from a clogging attack. 1023 In all modes the cryptographic seed data used to generate cookies and 1024 autokey values are changed from time to time. Thus, a determined 1025 intruder could save old request and response packets containing these 1026 values and replay them before or after the seed data have changed. 1027 Once the client has synchronized to an authentic source, the client 1028 will detect replays due to the old timestamp and discard the data. 1029 This is why the timestamp test is done first and before the signature 1030 is computed. However, before this happens, the client is vulnerable 1031 to replays whether or not they result in clogging. 1033 There are two vulnerabilities exposed in the protocol design: a sign 1034 attack where the intruder hopes to clog the victim with needless 1035 signature computations, and a verify attack where the intruder 1036 attempts to clog the victim with needless verification computations. 1037 The reference implementation uses the RSA public key algorithms for 1038 both sign and verify functions and these algorithms require 1039 significant processor resources. 1041 In order to reduce the exposure to a sign attack, signatures are 1042 computed only when the data have changed. For instance, the autokey 1043 values are signed only when the key list is regenerated, which 1044 happens about once an hour, while the public values are signed only 1045 when the agreement values are regenerated, which happens about once 1046 per day. However, a server is vulnerable to a sign attack where the 1047 intruder can clog the server with cookie-request messages. The 1048 protocol design precludes server state variables stored on behalf of 1049 any client, so the signature must be recomputed for every cookie 1050 request. Ordinarily, cookie requests are seldom used, except when the 1051 private values are regenerated. However, a determined intruder could 1052 replay intercepted cookie requests at high rate, which may very well 1053 clog the server. There appears no easy countermeasure for this 1054 particular attack. 1056 The intruder might be more successful with a verify attack. Once the 1057 client has synchronized to an authentic source, replays are detected 1058 and discarded before the signature is verified. However, if the 1059 cookie is known or compromised, the intruder can replace the 1060 timestamp in an old message with one in the future and construct a 1061 packet with a MAC acceptable to a client, even if it has bogus 1062 signature and incorrect autokey sequence. The packet passes the MAC 1063 test, but then tricks the client to verify the signature, which of 1064 course fails. What makes this kind of attack more serious is the fact 1065 that the cookie used when extension fields are present is well known 1066 (zero). Since all multicast packets have an extension field, all the 1067 intruder has to do is clog the clients with responses including 1068 timestamps in the future. Assuming the intruder has joined the NTP 1069 multicast group, the attack could clog all other members of the 1070 group. This attack can be deflected by the autokey test, which in the 1071 reference implementation is after extension field processing, but 1072 this requires very intricate protocol engineering and is left for a 1073 future refinement. 1075 An interesting vulnerability in client/server mode is for an intruder 1076 to replay a recent client packet with an intentional bit error. This 1077 could cause the server to return the special NAK packet. A naive 1078 client might conclude the server had refreshed its private value and 1079 so attempt to refresh the server cookie using a cookie-request 1080 message. This results in the server and client burning spurious 1081 machine cycles and invites a clogging attack. This is why the 1082 reference implementation simply discards all protocol and procedure 1083 errors and waits for timeout in order to refresh the values. However, 1084 a more clever client may notice that the NTP originate timestamp does 1085 not match the most recent client packet sent, so can discard the 1086 bogus NAK immediately. 1088 In multicast and symmetric modes the client must include the 1089 association ID in the Autokey request. Since association ID values 1090 for different invocations of the NTP daemon are randomized over the 1091 16-bit space, it is unlikely that a very old packet would contain a 1092 valid ID value. An intruder could save old server packets and replay 1093 them to the client population with the hope that the values will be 1094 accepted and cause general chaos. The conservative client will 1095 discard them on the basis of invalid timestamp. 1097 8 Present Status 1099 The Autokey scheme has been implemented in the public software 1100 distribution for NTP Version 4 and has been tested in all machines of 1101 either endian persuasion and both 32- and 64-bit architectures. 1102 Testing the implementation has been complicated by the many 1103 combinations of modes and failure/recovery mechanisms, including 1104 daemon restarts, key expiration, communication failures and various 1105 management mistakes. The experience points up the fact that many 1106 little gotchas that are survivable in ordinary protocol designs 1107 become showstoppers when strong cryptographic assurance is required. 1109 9 Future Plans 1111 The analysis, design and implementation of the Autokey scheme is 1112 basically mature; however, There are two remaining implementation 1113 issues. One has to do with the Unix sockets semantics used for 1114 multicast. The problem is how to set the source address when more 1115 than one interface is present. Since the Autokey scheme hashes the IP 1116 addresses, as well as the NTP header, it is necessary that the 1117 correct address be known before the hash can be computed. In the 1118 present implementation the address is not known until the first 1119 packet arrives, which considerably complicates the protocol. Probably 1120 nothing short of a complete rewrite of the I/O code will fix this. 1122 The other issue is support for Secure DNS services, especially the 1123 retrieval of public certificates. A complicating factor is the 1124 existing banal state of the configuration and resolver code in the 1125 NTP daemon. Over the years this code has sprouted to a fractal-like 1126 state where possibly the only correct repair is a complete rewrite. 1128 Appendix A. Packet Formats 1130 The NTP Version 4 packet consists of a number of fields made up of 1131 32-bit (4 octet) words. The packet consists of three components, the 1132 header, one or more optional extension fields and an optional message 1133 authenticator code (MAC), consisting of the Key ID and Message Digest 1134 fields. The format is shown below, where the size of some multiple 1135 word fields is shown in bits. 1137 1 2 3 1138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 |LI | VN |Mode | Stratum | Poll | Precision | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Root Delay | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Root Dispersion | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Reference ID | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | | 1149 | Reference Timestamp (64) | 1150 | | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | | 1153 | Originate Timestamp (64) | 1154 | | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | | 1157 | Receive Timestamp (64) | 1158 | | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | | 1161 | Transmit Timestamp (64) | 1162 | | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | | 1165 | | 1166 = Extension Field(s) = 1167 | | 1168 | | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Key ID | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | | 1173 | | 1174 | Message Digest (128) | 1175 | | 1176 | | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 The NTP header extends from the beginning of the packet to the end of 1180 the Transmit Timestamp field. The format and interpretation of the 1181 header fields are backwards compatible with the NTP Version 3 header 1182 fields as described in RFC-1305, except for a slightly modified 1183 computation for the Root Dispersion field. In NTP Version 3, this 1184 field includes an estimated jitter quantity based on weighted 1185 absolute differences, while in NTP Version 4 this quantity is based 1186 on weighted root-mean-square (RMS) differences. 1188 An unauthenticated NTP packet includes only the NTP header, while an 1189 authenticated one contains a MAC. The format and interpretation of 1190 the NTP Version 4 MAC is described in RFC-1305 when using the Digital 1191 Encryption Standard (DES) algorithm operating in cipher block 1192 chaining (CBC) node. While this algorithm and mode of operation is 1193 supported in NTP Version 4, the DES algorithm has been removed from 1194 the standard software distribution and must be obtained via other 1195 sources. The preferred replacement for NTP Version 4 is the Message 1196 Digest 5 (MD5) algorithm, which is included in the distribution. The 1197 Message Digest field is 64 bits for DES-CBC and 128 bits for MD5, 1198 while the Key ID field is 32 bits for either algorithm. 1200 In NTP Version 4 one or more extension fields can be inserted after 1201 the NTP header and before the MAC, which is always present when an 1202 extension field is present. Each extension field contains a request 1203 or response message, which consists of a 16-bit length field, an 8- 1204 bit control field, an 8-bit flags field and a variable length data 1205 field, all in network byte order: 1207 1 2 3 1208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 |R|E| Version | Code | Length | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | | 1213 = Data = 1214 | | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 There are two flag bits defined. Bit 0 is the response flag (R) and 1218 bit 1 is the error flag (E); the other six bits are presently unused 1219 and should be set to 0. The Version field identifies the version 1220 number of the extension field protocol; this memorandum specifies 1221 version 1. The Code field specifies the operation in request and 1222 response messages. The length includes all octets in the extension 1223 field, including the length field itself. Each extension field is 1224 rounded up to the next multiple of 4 octets and the last field 1225 rounded up to the next multiple of 8 octets. The extension fields can 1226 occur in any order; however, in some cases there is a preferred order 1227 which improves the protocol efficiency. The presence of the MAC and 1228 extension fields in the packet is determined from the length of the 1229 remaining area after the header to the end of the packet. The parser 1230 initializes a pointer just after the header. If the length is not a 1231 multiple of 4, a format error has occurred and the packet is 1232 discarded. If the length is zero the packet is not authenticated. If 1233 the length is 4 (1 word), the packet is an error report resulting 1234 from a previous packet that failed the message digest check. The 4 1235 octets are presently unused and should be set to 0. If the length is 1236 12 (3 words), a MAC (DES-CBC) is present, but no extension field; if 1237 20 (5 words), a MAC (MD5) is present, but no extension field; If the 1238 length is 8 (2 words) or 16 (4 words), the packet is discarded with a 1239 format error. If the length is greater than 20 (5 words), one or 1240 more extension fields are present. 1242 If an extension field is present, the parser examines the length 1243 field. If the length is less than 4 or not a multiple of 4, a format 1244 error has occurred and the packet is discarded; otherwise, the parser 1245 increments the pointer by this value. The parser now uses the same 1246 rules as above to determine whether a MAC is present and/or another 1247 extension field. An additional implementation-dependent test is 1248 necessary to ensure the pointer does not stray outside the buffer 1249 space occupied by the packet. 1251 In the most common protocol operations, a client sends a request to a 1252 server with an operation code specified in the Code field and the R 1253 bit set to 0. Ordinarily, the client sets the E bit to 0 as well, but 1254 may in future set it to 1 for some purpose. The server returns a 1255 response with the same operation code in the Code field and the R bit 1256 set to 1. The server can also set the E bit to 1 in case of error. 1257 However, it is not a protocol error to send an unsolicited response 1258 with no matching request. 1260 There are currently five request and six response messages. All 1261 request messages have the following format: 1263 1 2 3 1264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 |0|0| 1 | Code | Length | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Association ID | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 The Association ID field is used to match a client request to a 1271 particular server association. By convention, servers set the 1272 association ID in the response and clients include the same value in 1273 requests. Also by convention, until a client has received a response 1274 from a server, the client sets the Association ID field to 0. If for 1275 some reason the association ID value in a request does not match the 1276 association ID of any mobilized association, the server returns the 1277 request with both the R and E bits set to 1. 1279 The following request and response messages have been defined. 1281 Public Key (1) 1283 This extension field is reserved for future use as an algorithm and 1284 algorithm parameter offer/select exchange. The command code is 1285 reserved. 1287 Association ID (2) 1289 This message is sent by a multicast server as an unsolicited response 1290 only; there is no corresponding request message of this type. The 1291 response has the following format: 1293 1 2 3 1294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 |1|E| 1 | 2 | Length | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Association ID | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 The Association ID field contains the association ID of the server. 1302 This response is included in every packet sent by a multicast server, 1303 except when a new key list is generated. There is no timestamp or 1304 signature associated with this message. 1306 Cookie (3) 1308 A client sends the request to obtain the server cookie. The response 1309 has the following format: 1311 1 2 3 1312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 |1|E| 1 | 3 | Length | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Association ID | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Timestamp | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Cookie | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Signature Length | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | | 1325 | | 1326 = Signature = 1327 | | 1328 | | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 Since there is no server association matching the client, the 1332 association ID field for the request and response is 0. The Cookie 1333 field contains the cookie used in client/server modes. If the server 1334 is not synchronized to an authenticated source, the Timestamp field 1335 contains 0; otherwise, it contains the NTP seconds when the cookie 1336 was computed and signed. The signature covers the Timestamp and 1337 Cookie fields. If for some reason the cookie value is unavailable or 1338 the signing operation fails, the Cookie field contains 0 and the 1339 extension field is truncated following this field. 1341 Autokey (4) 1343 A multicast server or symmetric peer sends the request to obtain the 1344 autokey values. The response has the following format: 1346 1 2 3 1347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 |1|E| 1 | 4 | Length | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Association ID | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Timestamp | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Initial Sequence | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Initial Key ID | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Signature Length | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | | 1362 | | 1363 = Signature = 1364 | | 1365 | | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 The response is also sent unsolicited when the server or peer 1369 generates a new key list. The Initial Sequence field contains the 1370 first key number in the current key list and the Initial Key ID field 1371 contains the next key ID associated with that number. If the server 1372 is not synchronized to an authenticated source, the Timestamp field 1373 contains 0; otherwise, it contains the NTP seconds when the key list 1374 was generated and signed. The signature covers all fields from the 1375 Timestamp field through the Initial Key ID field. If for some reason 1376 these values are unavailable or the signing operation fails, the 1377 Initial Sequence and Initial Key ID fields contain 0 and the 1378 extension field is truncated following the Initial Key ID field. 1380 Diffie-Hellman Parameters (5) 1382 A symmetric peer uses the request and response to send the public 1383 value and signature to its peer. The response has the following 1384 format: 1386 1 2 3 1387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 |1|E| 1 | 5 | Length | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Association ID | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Timestamp | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Parameters Filestamp | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Parameters Length | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | | 1400 | | 1401 = Parameters = 1402 | | 1403 | | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Signature Length | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | | 1408 | | 1409 = Signature = 1410 | | 1411 | | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 The Parameters field contains the Diffie-Hellman parameters used to 1415 compute the public and private values. The Parameters Filestamp field 1416 contains the NTP seconds when the Diffie-Hellman parameter file was 1417 generated. If the server is not synchronized to an authenticated 1418 source, the Timestamp field contains 0; otherwise, it contains the 1419 NTP seconds when the public value was generated and signed. The 1420 signature covers the Timestamp, Parameters Length and Parameters 1421 fields. If for some reason these values are unavailable or the 1422 signing operation fails, the Parameters Length field contains 0 and 1423 the extension field is truncated following this field. 1425 Public Value (6) 1426 A symmetric peer uses the request and response to send the public 1427 value and signature to its peer. The response has the following 1428 format: 1430 1 2 3 1431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 |1|E| 1 | 5 | Length | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Association ID | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Timestamp | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Filestamp | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Public Value Length | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | | 1444 | | 1445 = Public Value = 1446 | | 1447 | | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Signature Length | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | | 1452 | | 1453 = Signature = 1454 | | 1455 | | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 The Public Value field contains the Diffie-Hellman public value used 1459 to compute the agreed key. 1461 The Filestamp field contains the NTP seconds when the Diffie-Hellman 1462 parameter file was generated. If the server is not synchronized to an 1463 authenticated source, the Timestamp field contains 0; otherwise, it 1464 contains the NTP seconds when the public value was generated and 1465 signed. The signature covers all fields from the Timestamp field 1466 through the Public Value field. If for some reason these values are 1467 unavailable or the signing operation fails, the Public Value Length 1468 field contains 0 and the extension field is truncated following this 1469 field. 1471 Public Key/Host Name (7) 1472 A client uses the request to retrieve the public key, host name and 1473 signature. The response has the following format: 1475 1 2 3 1476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 |1|E| 1 | 7 | Length | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Public Key ID | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Association ID | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Timestamp | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Filestamp | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Public Key Length | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | | 1491 | | 1492 = Public Key = 1493 | | 1494 | | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Host Name Length | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | | 1499 | | 1500 = Host Name = 1501 | | 1502 | | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Signature Length | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | | 1507 | | 1508 = Signature = 1509 | | 1510 | | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 Since the public key and host name are a property of the server and 1514 not any particular association, the association ID field for the 1515 request and response is 0. The Public Key field contains the RSA 1516 public key in rsaref2.0 format; that is, the modulus length (in bits) 1517 as the first word followed by the modulus bits. Note that in some 1518 architectures the rsaref2.0 modulus word may be something other than 1519 32 bits. The Host Name field contains the host name string returned 1520 by the Unix gethostname() library function. 1522 The Filestamp field contains the NTP seconds when the public/private 1523 key files were generated. If the server is not synchronized to an 1524 authenticated source, the Timestamp field contains 0; otherwise, it 1525 contains the NTP seconds when the public value was generated and 1526 signed. The signature covers all fields from the Timestamp field 1527 through the Host Name field. If for some reason these values are 1528 unavailable or the signing operation fails, the Host Name Length 1529 field contains 0 and the extension field is truncated following this 1530 field. 1532 TAI Leap Second Table (8) 1534 The civil timescale (UTC), which is based on Earth rotation, has been 1535 diverging from atomic time (TAI), which is based on an ensemble of 1536 cesium oscillators, at about one second per year. Since 1972 the 1537 International Bureau of Weights and Measures (BIPM) declares on 1538 occasion a leap second to be inserted in the UTC timescale on the 1539 last day of June or December. Sometimes it is necessary to correct 1540 UTC as disseminated by NTP to agree with TAI on the current or some 1541 previous epoch. 1543 A client uses the request to retrieve the leap second table and 1544 signature. The response has the following format: 1546 1 2 3 1547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 |1|E| 1 | 8 | Length | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Public Key ID | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Association ID | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Timestamp | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Filestamp | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Leap Second Table Length | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | | 1562 | | 1563 = Leap Second Table = 1564 | | 1565 | | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Signature Length | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | | 1570 | | 1571 = Signature = 1572 | | 1573 | | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 The NTP extension field format consists of a table with one entry in 1577 NTP seconds for each leap second insertion and in the order from the 1578 most recent insertion to the first. Since UTC led TAI by ten seconds 1579 at the first insertion and each insertion since then adds one second, 1580 the current UTC-TAI offset is simply the sum of these values. 1582 Since the leap second table is a property of the server and not any 1583 particular association, the association ID field for the request and 1584 response is 0. The Leap Second Table field contains a list of the 1585 historic epoches that leap seconds were inserted in the UTC 1586 timescale. Each list entry is a 32-bit word in NTP seconds, while the 1587 table is in order from the most recent to the oldest insertion. At 1588 the first insertion in January, 1972 UTC was ahead of TAI by 10 s and 1589 has increased by 1 s for each insertion since then. Thus, the table 1590 length in bytes divided by four plus nine is the current offset of 1591 UTC relative to TAI. 1593 The Filestamp field contains the NTP seconds when the leap second 1594 table was generated at the original host, in this case one of the 1595 public time servers operated by NIST. If the value of the filestamp 1596 is less than the first entry on the list, the first entry is the 1597 epoch of the predicted next leap insertion. The filestamp must always 1598 be greater than the second entry in the list. If the server is not 1599 synchronized to an authenticated source, the Timestamp field contains 1600 0; otherwise, it contains the NTP seconds when the public value was 1601 generated and signed. 1602 The signature covers all fields from the Timestamp field through the 1603 Leap Second Table field. If for some reason these values are 1604 unavailable or the signing operation fails, the Host Name Length 1605 field contains 0 and the extension field is truncated following this 1606 field. 1608 Appendix B. Key Generation and Management 1610 In the reference implementation the lifetimes of various 1611 cryptographic values are carefully managed and frequently refreshed. 1612 While permanent keys have lifetimes that expire only when manually 1613 revoked, autokeys have a lifetime specified at the time of 1614 generation. When generating a key list for an association, the 1615 lifetime of each autokey is set to expire one poll interval later 1616 than it is scheduled to be used. 1617 Ordinarily, key lists are regenerated and signed about once per hour 1618 and private cookie values and public agreement values are refreshed 1619 and signed about once per day. The protocol design is specially 1620 tailored to make a smooth transition when these values are refreshed 1621 and to avoid vulnerabilities due to clogging and replay attacks while 1622 refreshment is in progress. 1624 In the reference implementation, Autokey key management is handled in 1625 much the same way as in the ssh facility. A set of public and private 1626 keys and agreement parameters are generated by a utility program 1627 designed for this purpose. From these data the program generates four 1628 files, one containing random DES/MD5 private keys, which are not used 1629 in the Autokey scheme, another containing the RSA private key, a 1630 third the RSA public key, and a fourth the agreement parameters. In 1631 addition, the leap second table is generated and stored in public 1632 time servers maintained by NIST. The means to do this are beyond the 1633 scope of this memorandum. 1635 All files are based on random strings seeded by the system clock at 1636 the time of generation and are in printable ASCII format with base-64 1637 encoding. The name of each file includes an extension consisting of 1638 the NTP seconds at the time of generation. This is interpreted as a 1639 key ID in order to detect incorrect keys and to handle key 1640 changeovers in an orderly way. In the recommended method, all files 1641 except the RSA private key file are stored in shared directory 1642 /usr/local/etc, which is where the daemon looks for them by default. 1643 The private RSA key file should be stored in an unshared directory 1644 such as /etc. It is convenient to install links from the default file 1645 names, which do not have filestamp extensions, to the current files, 1646 which do. This way when a new generation of keys is installed, only 1647 the links need to be changed. 1649 When a server or client first initializes, it loads the RSA public 1650 and private key files, which are required for continued operation. It 1651 then attempts to load the agreement parameter file and, if enabled by 1652 a configuration file bit, it attempts to load the leap second table 1653 file. Neither of these files are necessary at this time, since the 1654 data can be retrieved later from another server. If obtaining these 1655 data from another server is considered a significant vulnerability, 1656 the files should be present. 1658 In the current management model, the keys and parameter files are 1659 generated on each machine separately and the private key obscured. 1660 The set of public key files for a community of users can be copied to 1661 all of those users, while one of the parameter files can be selected 1662 and copied to all users. However, if security considerations permit, 1663 the public key and parameter values, as well as the leap second table 1664 can be obtained from other servers during operation. These data 1665 completely define the security community and the servers configured 1666 for each client. In multicast client and symmetric passive modes the 1667 identity of a particular server may not be known in advance, so the 1668 protocol obtains and verifies the public key and host name directly 1669 from the server. Ultimately, these procedures will be automated using 1670 public certificates retrieved from secure directory services. 1672 Where security considerations permit and the public key and parameter 1673 data can be retrieved directly from the server, key and parameter 1674 refreshment can be easily automated. Each server and client runs a 1675 shell script perhaps once per month to generate new key and parameter 1676 files, update the links and then restarts the daemon. The daemon will 1677 load the necessary files and then restart the protocol with each of 1678 its servers or peers, refreshing public keys and parameter files 1679 during the process. 1680 Clients of the daemon will not be able to authenticate following 1681 daemon restart, of course, but the protocol design is such that they 1682 will eventually time out, restart the protocol and retrieve the 1683 latest data. 1685 The parameters and leap second table files are a special case, since 1686 the expectation is that all servers and clients in the network have 1687 the same versions. Therefore, the scripts should provide for 1688 automatic, secure transfer of these files to all the lowest-stratum 1689 servers in the security compartment. 1691 Unlike ssh, where the client must be securely identified to the 1692 server, in NTP the server must be securely identified to the client. 1693 In ssh each different interface address can be bound to a different 1694 name as returned by a reverse-DNS query. In this design separate 1695 public/private key pairs are required for each interface address with 1696 a distinct name. In the NTP design the canonical host name, as 1697 returned by the gethostname() library function, represents all 1698 interface addresses. Since at least in some host configurations the 1699 canonical name may not be identifiable in a DNS query, the name must 1700 be either configured in advance or obtained directly from the server 1701 using the Autokey protocol. 1703 10 References 1705 Note: Internet Engineering Task Force documents can be obtained at 1706 www.ietf.org. Other papers and reports can be obtained at 1707 www.eecis.udel.edu/~mills. Additional briefings in PowerPoint, 1708 PostScript and PDF are at that site in ./autokey.htm. 1710 1. Karn, P., and W. Simpson. Photuris: session-key management 1711 protocol. Request for Comments RFC-2522, Internet Engineering Task 1712 Force, March 1999. 1714 2. Kent, S., R. Atkinson. IP Authentication Header. Request for 1715 Comments RFC-2402, Internet Engineering Task Force, November 1998. 1717 3. Kent, S., and R. Atkinson. IP Encapsulating security payload 1718 (ESP). Request for Comments RFC-2406, Internet Engineering Task 1719 Force, November 1998. 1721 4. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet 1722 security association and key management protocol (ISAKMP). Request 1723 for Comments RFC-2408, Internet Engineering Task Force, November 1724 1998. 1726 5. Mills, D.L. Authentication scheme for distributed, ubiquitous, 1727 real- time protocols. Proc. Advanced Telecommunications/Information 1728 Distribution Research Program (ATIRP) Conference (College Park MD, 1729 January 1997), 293-298. 1731 6. Mills, D.L. Cryptographic authentication for real-time network 1732 protocols. In: AMS DIMACS Series in Discrete Mathematics and 1733 Theoretical Computer Science, Vol. 45 (1999), 135-144. 1735 7. Mills, D.L. Network Time Protocol (Version 3) specification, 1736 implementation and analysis. Network Working Group Report RFC-1305, 1737 University of Delaware, March 1992, 113 pp. 1739 8. Mills, D.L. Proposed authentication enhancements for the Network 1740 Time Protocol version 4. Electrical Engineering Report 96-10-3, 1741 University of Delaware, October 1996, 36 pp. 1743 9. Mills, D.L, and A. Thyagarajan. Network time protocol version 4 1744 proposed changes. Electrical Engineering Department Report 94-10-2, 1745 University of Delaware, October 1994, 32 pp. 1747 10. Mills, D.L. Public key cryptography for the Network Time 1748 Protocol. Electrical Engineering Report 00-5-1, University of 1749 Delaware, May 2000. 23 pp. 1751 11. Orman, H. The OAKLEY key determination protocol. Request for 1752 Comments RFC-2412, Internet Engineering Task Force, November 1998. 1754 12. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1755 Levels", BCP 14, RFC 2119, March 1997 1757 11. Author's Address 1759 David L. Mills 1760 Electrical and Computer Engineering Department 1761 University of Delaware 1762 Newark, DE 19716 1763 mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316 1764 web www.eecis.udel.edu/~mills 1766 Full Copyright Statement 1768 "Copyright (C) The Internet Society (date). All Rights Reserved. This 1769 document and translations of it may be copied and furnished to 1770 others, and derivative works that comment on or otherwise explain it 1771 or assist in its implmentation may be prepared, copied, published and 1772 distributed, in whole or in part, without restriction of any kind, 1773 provided that the above copyright notice and this paragraph are 1774 included on all such copies and derivative works. However, this 1775 document itself may not be modified in any way, such as by removing 1776 the copyright notice or references to the Internet Society or other 1777 Internet organizations, except as needed for the purpose of 1778 developing Internet standards in which case the procedures for 1779 copyrights defined in the Internet Standards process must be 1780 followed, or as required to translate it into.