idnits 2.17.1 draft-ietf-stime-ntpauth-01.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: ---------------------------------------------------------------------------- ** 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. == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 907 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([11]), 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: ---------------------------------------------------------------------------- == Line 998 has weird spacing: '...tic bit set ...' == Line 1082 has weird spacing: '... values initi...' == Line 1085 has weird spacing: '...tic bit set ...' == Line 1245 has weird spacing: '... values initi...' == Line 1248 has weird spacing: '...tic bit set ...' == 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 (April 2001) is 8383 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? '1' on line 32 looks like a reference -- Missing reference section? '11' on line 154 looks like a reference -- Missing reference section? '7' on line 126 looks like a reference -- Missing reference section? '2' on line 142 looks like a reference -- Missing reference section? '5' on line 152 looks like a reference -- Missing reference section? '12' on line 142 looks like a reference -- Missing reference section? '6' on line 152 looks like a reference -- Missing reference section? '8' on line 152 looks like a reference -- Missing reference section? '4' on line 185 looks like a reference -- Missing reference section? '3' on line 185 looks like a reference -- Missing reference section? '9' on line 222 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 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-01.txt > April 2001 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 all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 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 material 22 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 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. This document is an Internet-Draft. 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC-2119 [1]. 33 1. Abstract 35 This memorandum describes a scheme for authenticating servers to clients 36 in the Network Time Protocol. It extends prior schemes based on 37 symmetric-key cryptography to a new scheme based on public-key 38 cryptography. The new scheme, called Autokey, is based on the premiss 39 that the IPSEC schemes proposed by the IETF cannot be adopted intact, 40 since that would preclude stateless servers and severely compromise 41 timekeeping accuracy. In addition, the IPSEC model presumes 42 authenticated timestamps are always available; however, 43 cryptographically verified timestamps require interaction between the 44 timekeeping function and authentication function in ways not yet 45 considered in the IPSEC model. 47 The main body of this memorandum contains a description of the security 48 model, approach rationale, protocol design and vulnerability analysis. 49 It obsoletes a previous report [11] primarily in the schemes for 50 distributing public keys and related values. A detailed description of 51 the protocol states, events and transition functions is included. 52 Detailed packet formats and field descriptions are given in the 53 appendix. A prototype of the Autokey design based on this memorandum has 54 been implemented, tested and documented in the NTP Version 4 software 55 distribution for Unix, Windows and VMS at www.ntp.org. 57 While not strictly a security function, the Autokey protocol also 58 provides means to securely retrieve a table of historic leap seconds 59 necessary to convert ordinary civil time (UTC) to atomic time (TAI) 60 where needed. The tables can be retrieved either directly from national 61 time servers operated by NIST or indirectly through intervening servers. 63 Changes Since the Preceeding Draft 65 There are a number of changes scattered through this memorandum to 66 clarify the presentation and add a few new features. Among the most 67 important: 69 1. An optional parameter negotiation message has been added to the 70 protocol state machine. The values it may carry and the interpretation 71 of these values are not defined in this memorandum. 73 2. A preliminary value exchange has been added to begin the protocol 74 dance. This is necessary to avoid a vulnerability where unsolicited 75 public key responses could clog the victim with needless signature 76 cycles. 78 3. The value exchange, which is piggybacked on the association ID 79 message, supports a timestamp-based agreement scheme which floods the 80 latest version of the agreement parameters and leapseconds table. Using 81 this scheme any one of a clique of trusted primary servers running 82 symmetric modes with each other and broadcast or client/server modes 83 with the secondary server population can refresh these data at any time 84 and the refreshed data will update all older data everywhere in the NTP 85 subnet within one day. 87 4. An optional certificate retrieval operation has been added to the 88 protocol state machine. While the operation has been implemented and 89 tested, the contents of the certificate itself have not been determined. 91 5. A couple of subtle livelock problems with symmetric mode and 92 broadcast mode were found and fixed. The problem with source addresses 93 not yet bound has been fixed in the reference implementation. 95 6. The protocol descriptions and state diagrams have been updated. Some 96 packet formats have been changed in minor ways. 98 7. Provisions for the use of IPv6 addresses in calculating the autokey 99 have been added. 101 8. Provisions for the use of arbitrary identification values to be used 102 in lieu or IP addresses in calculating the autokey have been added. 104 9. A simplified version of the protocol appropriate for SNTP clients is 105 proposed; details to follow. 107 Introduction 109 A distributed network service requires reliable, ubiquitous and 110 survivable provisions to prevent accidental or malicious attacks on the 111 servers and clients in the network or the values they exchange. 112 Reliability requires that clients can determine that received packets 113 are authentic; that is, were actually sent by the intended server and 114 not manufactured or modified by an intruder. Ubiquity requires that any 115 client can verify the authenticity of any server using only public 116 information. Survivability requires protection from faulty 117 implementations, improper operation and possibly malicious clogging and 118 replay attacks with or without data modification. These requirements are 119 especially stringent with widely distributed network services, since 120 damage due to failures can propagate quickly throughout the network, 121 devastating archives, routing databases and monitoring systems and even 122 bring down major portions of the network. 124 The Network Time Protocol (NTP) contains provisions to cryptographically 125 authenticate individual servers as described in the most recent protocol 126 specification RFC-1305 [7]; however, that specification does not provide 127 a scheme for the distribution of cryptographic keys, nor does it provide 128 for the retrieval of cryptographic media that reliably bind the server 129 identification credentials with the associated keys and related public 130 values. However, conventional key agreement and digital signatures with 131 large client populations can cause significant performance degradations, 132 especially in time critical applications such as NTP. In addition, there 133 are problems unique to NTP in the interaction between the authentication 134 and synchronization functions, since each requires the other. 136 This memorandum describes a cryptographically sound and efficient 137 methodology for use in NTP and similar distributed protocols. As 138 demonstrated in the reports and briefings cited in the references at the 139 end of this memorandum, there is a place for Public-Key Infrastructure 140 (PKI) and related schemes, but none of these schemes alone satisfies the 141 requirements of the NTP security model. The various key agreement 142 schemes [2, 5, 12] proposed by the IETF require per-association state 143 variables, which contradicts the principles of the remote procedure call 144 (RPC) paradigm in which servers keep no state for a possibly large 145 client population. An evaluation of the PKI model and algorithms as 146 implemented in the rsaref2.0 package formerly distributed by RSA 147 Laboratories leads to the conclusion that any scheme requiring every NTP 148 packet to carry a PKI digital signature would result in unacceptably 149 poor timekeeping performance. 151 A revised security model and authentication scheme called Autokey was 152 proposed in earlier reports [5, 6, 8]. It has been evolved and refined 153 since then and implemented in NTP Version 4 for Unix, Windows and VMS 154 [11]. It is based on a combination of PKI and a pseudo-random sequence 155 generated by repeated hashes of a cryptographic value involving both 156 public and private components. This scheme has been tested and evaluated 157 in a local environment and is being deployed now in the CAIRN experiment 158 network funded by DARPA. A detailed description of the security model, 159 design principles and implementation experience is presented in this 160 memorandum. 162 Security Model 164 NTP security requirements are even more stringent than most other 165 distributed services. First, the operation of the authentication 166 mechanism and the time synchronization mechanism are inextricably 167 intertwined. Reliable time synchronization requires cryptographic keys 168 which are valid only over designated time intervals; but, time intervals 169 can be enforced only when all servers and clients are reliably 170 synchronized to UTC. Second, the NTP subnet is hierarchical by nature, 171 so time and trust flow from the primary servers at the root through 172 secondary servers to the clients at the leaves. A client can claim 173 authentic only if all servers on the path to the primary servers are 174 bone-fide authentic. In order to emphasize this requirement, in this 175 memorandum, the notion of "authentic" is replaced by "proventic", a noun 176 new to English and derived from provenance, as in the provenance of a 177 painting. Having abused the language this far, the suffixes fixable to 178 the various noun and verb derivatives of authentic will be adopted for 179 proventic as well. In NTP each server authenticates the next lower 180 stratum servers and proventicates the lowest stratum (primary) servers. 182 Over the last several years the IETF has defined and evolved the IPSEC 183 infrastructure for privacy protection and source authentication in the 184 Internet, The infrastructure includes the Encapsulating Security Payload 185 (ESP) [4] and Authentication Header (AH) [3] for IPv4 and IPv6. 186 Cryptographic algorithms that use these headers for various purposes 187 include those developed for the PKI, including MD5 message digests, RSA 188 digital signatures and several variations of Diffie-Hellman key 189 agreements. The fundamental assumption in the security model is that 190 packets transmitted over the Internet can be intercepted by other than 191 the intended receiver, remanufactured in various ways and replayed in 192 whole or part. These packets can cause the client to believe or produce 193 incorrect information, cause protocol operations to fail, interrupt 194 network service or consume processor resources with needless 195 cryptographic calculations. 197 In the case of NTP, the assumed goal of the intruder is to inject false 198 time values, disrupt the protocol or clog the network or servers or 199 clients with spurious packets that exhaust resources and deny service to 200 legitimate processes. The mission of the algorithms and protocols 201 described in this memorandum is to detect and discard spurious packets 202 sent by other than the intended sender or sent by the intended sender 203 but modified or replayed by an intruder. The cryptographic means of the 204 reference implementation are based on the rsaref2.0 algorithms, but 205 other algorithms with equivalent functionality could be used as well. It 206 is important for distribution and export purposes that the way in which 207 these algorithms are used precludes encryption of any data other than 208 incidental to the construction of digital signatures. 210 There are a number of defense mechanisms already built in the NTP 211 architecture, protocol and algorithms. The fundamental timestamp- 212 exchange scheme is inherently resistant to replay attacks. The 213 engineered clock filter, selection and clustering algorithms are 214 designed to defend against Byzantine traitors and evil cliques. While 215 not necessarily designed to defeat determined intruders, these 216 algorithms and accompanying sanity checks have functioned well over the 217 years to deflect improperly operating but presumably friendly scenarios. 219 However, these mechanisms do not securely identify and authenticate 220 servers to clients. Without specific further protection, an intruder can 221 inject any or all of the following mischiefs. Further discussion on the 222 assumed intruder model is given in [9], but beyond the scope of this 223 memorandum. 225 1. An intruder can intercept and archive packets forever and can archive 226 all the public values ever generated and transmitted over the net. 228 2. An intruder can generate packets faster than the server or client can 229 process them, especially if they require expensive PKI operations. 231 3. An intruder can intercept, modify and replay a packet. However, it 232 cannot permanently prevent the original packet transmission over the 233 net; that is, it cannot break the wire, only congest it. 235 The following assumptions are fundamental to the Autokey design. They 236 are discussed at some length in the briefing slides and links at 237 www.eecis.udel.edu/~mills/ntp.htm and will not be further discussed in 238 this memorandum. 240 1. The running times for public-key algorithms are relatively long and 241 highly variable. In general, the performance of the synchronization 242 function is badly degraded if these algorithms must be used for every 243 NTP packet. 245 2. In some modes of operation it is not feasible for a server to retain 246 cryptographic state variables for every client. It is however feasible 247 to regenerated them for a client upon arrival of a packet from that 248 client. 250 3. The lifetime of cryptographic values must be enforced, which requires 251 a reliable system clock. However, the sources that synchronize the 252 system clock must be cryptographically proventicated. This circular 253 interdependence of the timekeeping and proventication functions requires 254 special handling. 256 4. All proventication functions must involve only public values 257 transmitted over the net. Private values must never be disclosed beyond 258 the machine on which they were created. 260 5. Public keys and agreement parameters, where necessary, must be 261 retrievable directly from servers without requiring secured channels; 262 however, the fundamental security of identification credentials and 263 public values bound to those credentials must eventually be a function 264 of certificate authorities and/or webs of trust. 266 Unlike the ssh security model, where the client must be securely 267 identified to the server, in NTP the server must be securely identified 268 to the client. In ssh each different interface address can be bound to a 269 different name, as returned by a reverse-DNS query. In this design 270 separate public/private key pairs may be required for each interface 271 address with a distinct name. A perceived advantage of this design is 272 that the security compartment can be different for each interface. This 273 allows a firewall, for instance, to require some interfaces to 274 proventicate the client and others not. 276 However, the NTP security model specifically assumes all time values and 277 cryptoraphic values are public, so there is no need to associate each 278 interface with different cryptoraphic values. In the NTP design the host 279 name, as returned by the gethostname() library function, represents all 280 interface addresses. Since at least in some host configurations the host 281 name may not be identifiable in a DNS query, the name must be either 282 configured in advance or obtained directly from the server using the 283 Autokey protocol. 285 Approach 287 The Autokey protocol described in this memorandum is designed to meet 288 the following objectives. Again, in-depth discussions on these 289 objectives is in the web briefings and will not be elaborated in this 290 memorandum. Note that here and elsewhere in this memorandum mention of 291 broadcast mode means multicast mode as well, with exceptions as noted. 293 1. It must interoperate with the existing NTP architecture model and 294 protocol design. In particular, it must support the symmetric-key scheme 295 described in RFC-1305. As a practical matter, the reference 296 implementation must use the same internal key management system, 297 including the use of 32-bit key IDs and existing mechanisms to store, 298 activate and revoke keys. 300 2. It must provide for the independent collection of cryptographic 301 values and time values. A client is proventicated only when the all 302 cryptographic values have been obtained and verified and the NTP 303 timestamps have passed all sanity checks. 305 3. It must not significantly degrade the potential accuracy of the NTP 306 synchronization algorithms. In particular, it must not make unreasonable 307 demands on the network or host processor and memory resources. 309 4. It must be resistant to cryptographic attacks, including 310 replay/modification and clogging attacks. In particular, it must be 311 tolerant of operation or implementation variances, such as packet loss 312 or misorder, or suboptimal configuration. 314 5. It must build on a widely available suite of cryptographic 315 algorithms, yet be independent of the particular choice. In particular, 316 it must not require data encryption other than incidental to signature 317 and verification functions. 319 6. It must function in all the modes supported by NTP, including 320 client/server, broadcast and symmetric active/passive modes. 322 7. It must not require intricate per-client or per-server configuration 323 other than the availability of public/private key files and agreement 324 parameter files, as required. 326 8. The reference implementation must contain provisions to generate 327 cryptographic key values, including private/public keys and agreement 328 parameters specific to each client and server. Eventually, it must 329 contain provisions to validate public values using certificate 330 authorities and/or webs of trust. 332 Autokey Proventication Scheme 334 Autokey public-key cryptography is based on the PKI algorithms of the 335 rsaref2.0 library, although other libraries with a compatible interface 336 could be used as well. The reference implementation uses keyed-MD5 337 message digests to detect packet modification, timestamped RSA digital 338 signatures to verify the source, and Diffie-Hellman key agreements to 339 construct a private shared key from public values. However, there is no 340 reason why alternative signature schemes and agreement algorithms could 341 be supported. What makes Autokey cryptography unique is the way in which 342 these algorithms are used to deflect intruder attacks while maintaining 343 the integrity and accuracy of the time synchronization function. 345 The NTP Version 3 symmetric-key cryptography uses keyed-MD5 message 346 digests with a 128-bit private key and 32-bit key ID. In order to retain 347 backward compatibility, the key ID space is partitioned in two subspaces 348 at a pivot point of 65536. Symmetric key IDs have given values less than 349 65536 and indefinite lifetime. Autokey key IDs have pseudo-random values 350 equal to or greater than 65536 and are expunged immediately after use. 352 There are three Autokey protocol variants corresponding to each of the 353 three NTP modes: client/server, broadcast and symmetric active/passive. 354 All three variants make use of a specially contrived session key called 355 an autokey and a pseudo-random sequence of key IDs called the key list. 356 As in the original NTP Version 3 authentication scheme, the Autokey 357 protocol operates separately for each association, so there may be 358 several key lists operating independently at the same time and with 359 distinct associated values and signatures. 361 An autokey consists of four fields in network byte order as shown below: 363 +-----------+-----------+-----------+-----------+ 364 | Source IP | Dest IP | Key ID | Cookie | 365 +-----------+-----------+-----------+-----------+ 367 For use with IPv4, the Source IP and Dest IP fields contain 32 bits; for 368 use with IPv6, these fields contain 128 bits. In either case the Key ID 369 and Cookie fields contain 32 bits. Thus, an IPv4 autokey has four 32-bit 370 words, while an IPv6 autokey has ten 32-bit words. The source and 371 destination IP addresses and key ID are public values visible in the 372 packet, while the cookie can be a public value or a private value, 373 depending on the mode. 375 There are some scenarios where the use of endpoint IP addresses when 376 calculating the autokey may be difficult or impossible. These include 377 configurations where Network Address Translation (NAT) devices are in 378 use or when addresses are changed during an association lifetime due to 379 mobility constraints. As described below, NTP associations are 380 identified by the endpoint IP addresses, so the natural approach is to 381 authenticate associations using these values. For scenarios where this 382 is not possible, an optional identification value can be used instead of 383 the endpoint IP addresses. The Parameter Negotiation message contains an 384 option to specify these data; however, the format, encoding and use of 385 this option are not specified in this memorandum. For the purposes of 386 this memorandum, the endpoint IP addresses will be assumed. 388 The NTP packet format has been augmented to include one or more 389 extension fields piggybacked between the original NTP header and the 390 message authenticator code (MAC) at the end of the packet. For packets 391 without extension fields, the cookie is a private value computed by an 392 agreement algorithm. For packets with extension fields, the cookie has a 393 default public value of zero, since these packets can be validated 394 independently using signed data in the extension fields. The four values 395 are hashed by the message digest algorithm to produce the actual key 396 value, which is stored along with the key ID in a cache used for 397 symmetric keys as well as autokeys. Keys are retrieved from the cache by 398 key ID using hash tables and a fast algorithm. 400 The key list consists of a sequence of key IDs starting with a random 401 value and each pointing to the next. To generate the next autokey on the 402 key list, the next key ID is the first 32 bits in network byte order of 403 the previous key value. It may happen that a newly generated key ID is 404 less than 65536 or collides with another one already generated (birthday 405 event). When this happens, which should occur only rarely, the key list 406 is terminated at that point. The lifetime of each key is set to expire 407 one poll interval after its scheduled use. In the reference 408 implementation, the list is terminated when the maximum key lifetime is 409 about one hour. 411 The index of the last key ID in the list is saved along with the next 412 key ID of that entry, collectively called the autokey values. The list 413 is used in reverse order, so that the first key ID used is the last one 414 generated. The Autokey protocol includes a message to retrieve the 415 autokey values and signature, so that subsequent packets can be 416 authenticated using one or more hashes that eventually match the first 417 key ID (valid) or exceed the index (invalid). This is called the autokey 418 test in the following and is done for every packet, including those with 419 and without extension fields. In the reference implementation the most 420 recent key ID received is saved for comparison with the first 32 bits in 421 network byte order of the next following key value. This minimizes the 422 number of hash operations in case a packet is lost. 424 The scheme used in client/server mode was suggested by Steve Kent over 425 lunch. The server keeps no state for each client, but uses a fast 426 algorithm and a private value to regenerate the cookie upon arrival of a 427 client packet. The cookie is calculated in a manner similar to the 428 autokey, but the key ID field is zero and the cookie field is the 429 private value. The first 32 bits of the hash is the cookie used for the 430 actual autokey calculation and is returned to the client on request. It 431 is thus specific to each client separately and of no use to other 432 clients or an intruder. A client obtains the cookie and signature using 433 the Autokey protocol and saves it for later use. 435 In client/server mode the cookie is a relatively weak function of the IP 436 addresses and a server private value. The client uses the cookie and 437 each key ID on the key list in turn to calculate the MAC for the next 438 NTP packet. The server calculates these values and checks the MAC, then 439 generates the MAC for the response using the same values, but with the 440 IP source and destination addresses exchanged. The client calculates and 441 checks the MAC and verifies the key ID matches the one sent. In this 442 mode the sequential structure of the key list is not exploited, but 443 doing it this way simplifies and regularizes the implementation. 445 In broadcast mode, clients normally do not send packets to the server, 446 except when first starting up to calibrate the propagation delay in 447 client/server mode. At the same time the client temporarily 448 authenticates as in that mode. After obtaining and verifying the cookie, 449 the client continues to obtain and verify the autokey values. To obtain 450 these values, the client must provide the ID of the particular server 451 association, since there can be more than one operating in the same 452 machine. For this purpose, the broadcast server includes the association 453 ID in every packet sent, except when sending the first packet after 454 generating a new key list, when it sends the autokey values instead. 456 In symmetric mode each peer keeps state variables related to the other, 457 so that a private cookie can be computed by a strong agreement 458 algorithm. The cookie itself is the first 32 bits of the agreed key. The 459 key list for each direction is generated separately by each peer and 460 used independently, but each is generated with the same cookie. 462 The server proventic bit is set only when the cookie or autokey values, 463 depending on mode, and the associated timestamp and signature are all 464 valid. If the bit is set, the client processes NTP time values; if the 465 bit is not set, extension field messages are processed in order to run 466 the Autokey protocol, but the NTP time values are ignored. Packets with 467 old timestamps are discarded immediately while avoiding expensive 468 cryptographic algorithms. Bogus packets with newer timestamps must pass 469 the MAC and autokey tests, which is highly unlikely. 471 Once the proventic bit has been set, the Autokey protocol is normally 472 dormant. In all modes except broadcast server, packets are normally sent 473 without an extension field, unless the packet is the first one sent 474 after generating a new key list or unless the client has requested the 475 cookie or autokey values. If for some reason the client clock is 476 stepped, rather than slewed, all cryptographic and time values for all 477 associations are purged and the Autokey protocol restarted from scratch. 478 This insures that stale values never propagate beyond a clock step. 480 Public-Key Signatures 482 Since public-key signatures provide strong protection against 483 misrepresentation of sources, probably the most obvious intruder 484 strategy is to deny or restrict service by replaying old packets with 485 signed cryptographic values in a cut-and-paste attack. The basis values 486 on which the cryptographic operations depend are changed often to 487 deflect brute force cryptanalysis, so the client must be prepared to 488 abandon an old key in favor of a refreshed one. This invites the 489 opportunity for an intruder to clog the client or server by replaying 490 old Autokey messages or to invent bogus new ones. A client receiving 491 such messages might be forced to refresh the correct value from the 492 legitimate server and consume significant processor resources. 494 In order to foil such attacks, every extension field carries a timestamp 495 in the form of the NTP seconds at the signature time. The signature 496 includes the timestamp itself together with optional additional data. If 497 the Autokey protocol has verified a proventic source and the NTP 498 algorithms have validated the time values, the system clock is 499 synchronized and signatures carry a nonzero (valid) timestamp. Otherwise 500 the system clock is unsynchronized and signatures carry a zero (invalid) 501 timestamp. Extension fields with invalid or old timestamps are discarded 502 before any values are used or signatures verified. 504 There are three signature types and six values to be signed: 506 1. The public value is signed at the time of generation, which occurs 507 when the system clock is first synchronized and about once per day after 508 that in the reference implementation. Besides the public value, the 509 public key/host name, agreement parameters and leapseconds table are all 510 signed as well, even if their values have not changed. All four of these 511 values carry the same timestamp. On request, each of these values and 512 associated signatures and timestamps are returned in an extension field. 514 2. The cookie value is computed and signed upon arrival of a cookie 515 request message. The response message contains the cookie, signature and 516 timestamp in an extension field. 518 3. The autokey values are signed when a new key list is generated, which 519 occurs about once per hour in the reference implementation. On request, 520 the autokey values, signature and timestamp are returned in an extension 521 field. 523 The most recent timestamp for each of the six values is saved for 524 comparison. Once a signature with valid timestamp has been received, 525 packets carrying extension fields with invalid timestamps or older valid 526 timestamps for the same value are discarded before the signature is 527 verified. For packets containing signed extension fields, the timestamp 528 deflects replays that otherwise might consume significant processor 529 resources; for other packets the Autokey protocol deflects message 530 modification and replay. In addition, the NTP protocol itself is 531 inherently resistant to replays and consumes only minimal processor 532 resources. 534 All cryptographic values used by the protocol are time sensitive and are 535 regularly refreshed. In particular, files containing cryptographic basis 536 values used by signature and agreement algorithms are regenerated from 537 time to time. It is the intent that file regeneration and loading of 538 these values occur without specific warning and without requiring 539 distribution in advance. While files carrying cryptographic data are not 540 specifically signed, the file names have extensions called filestamps 541 which reliably determine the time of generation. The filestamp for a 542 file is a string of decimal digits representing the NTP seconds at the 543 time the file was created. 545 As the data are forwarded from server to client, the filestamps are 546 preserved, including those for the public key/host name, agreement 547 parameters and leapseconds table. Packets with older filestamps are 548 discarded befor the signature is verified. Filestamps can in principle 549 be used as a total ordering function to verify that the data are 550 consistent and represent the latest available generation. For this 551 reason, the files should always be generated on a machine when the 552 system clock is valid. 554 When a client or server initializes, it reads its own public and private 555 key files, which are required for continued operation. Optionally, it 556 reads the agreement parameters file and constructs the public and 557 private values to be used later in the agreement algorithm. Also 558 optionally, it reads the leapseconds table file. When reading these 559 files it checks the filestamps for validity; for instance, all 560 filestamps must be later than the time the UTC timescale was established 561 in 1972. 563 When the client first validates a proventic source and when the clock is 564 stepped and when new cryptographic values are loaded from a server, the 565 client recomputes all signatures and checks the filestamps for validity 566 and consistency with the signature timestmaps: 568 1. If the system clock if valid, all timestamps and filestamps must be 569 earlier than the current clock time. 571 2. All signature timestamps must be later than the public key timestamp. 573 3. In broadcast client mode, the cookie timestamp must be later than the 574 autokey timestamp. 576 4. In symmetric modes the autokey timestamp must be later than the 577 public value timestamp. 579 5. Timestamps for each cryptographic data type must be later than the 580 filestamps for that type. 582 In the above constraints, note that timestamps and filestamps have a 583 granularity of one second, so that a difference of zero seconds is 584 ambiguous. Furthermore, timestamps and filestamps can be in error as 585 much as the value of the synchronization distance; that is, the sum of 586 the root dispersion plus one-half the root delay. However, the NTP 587 protocol normally operates with polling intervals much longer than one 588 second, so that successive timestamps for the same data type are 589 nonambiguous. On most machines, the processor time to generate a 590 complete set of key files is longer than one second, so it is not 591 possible to generate two generations in the same second. 593 However, it may happen that agreement parameters files may be generated 594 on two machines with the same filestamps, which creates an ordering 595 ambiguity. The filestamps for leapseconds files should also be 596 nonambiguous, since these files are created by NIST not more often than 597 twice per year. While filestamp collisions should be so rare as to be 598 safely ignored, a good management approach might require that these 599 files be generated only on a schedule that guarantees that no more than 600 one client or server generates a new key file set on any one day. 602 Certificates 604 PKI principles call for the use of certificates to reliably bind the 605 server distinguished name (host name), public key and related values to 606 each other. The certificate includes these values together with the 607 distinguished name of the certificate atuthority (CA) and other values 608 such as serial number and valid lifetime. These values are then signed 609 by the CA using its private key. The Autokey protocol includes 610 provisions to obtain the certificate, but at the present time does 611 nothing with the values. A future version of the protocol is to include 612 provisions to validate the binding using procedures established by the 613 IETF. 615 Packet Processing Rules 617 Exhaustive examination of possible vulnerabilities at the various 618 processing steps of the NTP protocol as specified in RFC-1305 have 619 resulted in a revised list of packet sanity tests. These tests have been 620 formulated to harden the protocol against defective header and data 621 values. These are summarized below, since they are an integral component 622 of the NTP cryptograhic defense mechanism. There are eleven tests, 623 called TEST1 through TEST11 in the reference implementation, which are 624 performed in a specific order designed to gain maximum diagnostic 625 information while protecting against accidental or malicious errors. 627 The tests are divided into three groups. The first group is designed to 628 deflect access control and authentication violations. While access 629 control and message digest violations always result immediate discard, 630 it is necessary when first mobilizing an association to disable the 631 autokey test and certain timestamp tests. However, after the proventic 632 bit is set, all tests are enforced. 634 The second group of tests is designed to deflect packets from broken or 635 unsynchronized servers and replays. In order to synchronize an 636 association in symmetric modes, it is necessary to save the originate 637 and receive timestamps in order to send them at a later time. This 638 happens for the first packet that arrives, even if it violates the 639 autokey test. In the normal case, the second packet to arrive will be 640 accepted and the association marked reachable. However, an agressive 641 intruder could replay old packets that could disrupt the saved 642 timestamps. This could not result in incorrect time values, but could 643 prevent a legitimate client from synchronizing the association. 645 The third group of tests is designed to deflect packets with invalid 646 header fields or time values with excessive errors. However, these tests 647 do not directly affect cryptographic source proventication or 648 vulnerability, so are beyond the scope of discussion in this document. 650 For packets containing signed extension fields additional tests apply, 651 depending on request type. There are the usual tests for valid extension 652 field format, length and values. An instantiated variable, such as the 653 public key/host name, agreement paramaters, public value, cookie or 654 autokey values, is valid when the accompaning timestamp and filestamp 655 are valid. The public key must be instantiated before any signatures can 656 be verified. In symmetric modes the agreement parameters must be 657 instantiated before the public and private agreement values can be 658 determined; the public agreement value must be instantiated before the 659 agreement algorithm can be run to determine the cookie. In all modes the 660 cookie value must be determined before the key list can be generated. 662 The object of the Autokey dances described below is to set the proventic 663 bit. In client/server mode this bit is set when the cookie is validated. 664 In other modes this bit is set when the autokey values are validated. 665 The bit is cleared initially and when the autokey test fails. If once 666 the bit is set and then cleared, the protocol will send an autokey 667 request message at the next poll opportunity and continue to send this 668 message until receiving valid autokey values or a general reset occurs. 670 This behavior is a compromise between protocol responsiveness, where the 671 current association can be maintained without interruption, and protocol 672 vulnerability, where an intruder can repeatedly clog the receiver with 673 replays that cause the client to needlessly poll the server and refresh 674 the values. 676 Error Recovery 678 The protocol state machine which drives the various Autokey functions 679 includes provisions for various kinds of error conditions that can arise 680 due to missing files, corrupted data, protocol violation and packet loss 681 or misorder, not to mention hostile intrusion. There are two mechanisms 682 which maintain the liveness state of the protocol, the reachability 683 register defined in RFC-1305 and the watchdog timer, which is new in NTP 684 Version 4. 686 The reachability register is an 8-bit register that shifts left with 687 zero replacing the rightmost bit. A shift occurs for every poll 688 interval, whether or not a poll is actually sent. If an arriving packet 689 passes all authentication and sanity checks, the rightmost bit is set to 690 one. If any bit in this register is one, the server is reachable, 691 otherwise it is unreachable. If the server was once reachable and then 692 becomes unreachable, a general reset is performed. A general reset 693 reinitializes all association variables to the state when first 694 mobilized and returns all acquired resources to the system. In addition, 695 if the association is not configured, it is demobilized until the next 696 packet is received. 698 The watchdog timer increments for every poll interval, whether or not a 699 poll is actually sent and regardless of the reachability state. The 700 counter is set to zero upon arrival of a packet from a proventicated 701 source, as determined by the Autokey protocol. In the reference 702 implementation, if the counter reaches 16 a general reset is performed. 703 In addition, if the association is configured, the poll interval is 704 doubled. This reduces the network load for packets that are unlikely to 705 elicit a response. 707 At each state in the protocol the client expects a particular response 708 from the server. A request is included in the NTP message sent at every 709 poll interval until the authentic response is received or a general 710 reset occurs, in which case the protocol restarts from the beginning. 711 While this behavior might be considered rather conservative, the 712 advantage is that old cryptographic and time values can never persist 713 from one mobilization to the next. 715 There are a number of situations where some action on an association 716 causes the remaining autokeys on the key list to become invalid. When 717 one of these situations happens, the key list and associated keys in the 718 key cache are purged. A new key list, signature and timestamp are 719 generated when the next NTP message is sent, assuming there is one. 720 Following is a list of these situations. 722 1. When the cookie value changes for any reason. 724 2. When a client switches from client/server mode to broadcast client 725 mode. There is no further need for the key list, since the client will 726 not transmit again. 728 3. When the poll interval is changed. In this case the calculated 729 expiration times for the keys become invalid. 731 4. When a general reset is performed. 733 5. If a problem is detected when an entry is fetched from the key list. 734 This could happen if the key was marked non-trusted or timed out, either 735 of which implies a software bug. 737 6. When the cryptographic values are refreshed, the key lists for all 738 associations are regenerated. 740 7. When the client is first proventicated or the system clock is 741 stepped, the key lists for all associations are regenerated. 743 Autokey Protocols 745 This section describes the Autokey protocols supporting 746 cryptographically secure server proventication. There are three 747 subprotocols, called dances, corresponding to the NTP client/server, 748 broadcast and symmetric active/passive modes. While Autokey messages are 749 piggybacked in NTP packets, the NTP protocol assumes clients poll 750 servers at a relatively low rate, such as once per minute, and where 751 possible avoids large packets. In particular, it is assumed that a 752 request sent at one poll opportunity will normally result in a response 753 before the next poll opportunity. 755 It is important to observe that, while the Autokey dances are obtaining 756 and validating cryptographic values, the underlying NTP protocol 757 continues to operate. Most packets used during the dances contain 758 signatures, so the values can be believed even before the dance has 759 concluded. Since signatures are valid once the certificate has been 760 validated during the initial steps of the dance, by the time the Autokey 761 values are validated the clock is usually already set. In this way the 762 sometimes intricate Autokey dance interactions do not delay the 763 accumulation of time values that will eventually set the clock. Each 764 autokey dance is designed to be nonintrusive and to require no 765 additional packets other than for regular NTP operations. Therefore, the 766 phrase "some time later" in the descriptions applies to the next poll 767 opportunity. 769 The Autokey protocol data unit is the extension field, one or more of 770 which can be piggybacked in the NTP packet. An extension field contains 771 either a request with optional data or a response with data. To avoid 772 deadlocks, any number of responses can be included in a packet, but only 773 one request. Some requests and most responses are protected by 774 timestamped signatures. The signature covers the data, timestamp and 775 filestamp, where applicable. The timestamp is set to the default (zero) 776 when the sender is not proventicated; otherwise, it is set to the NTP 777 seconds when the signature was generated. The following rules are 778 designed to detect invalid header or data fields and to deflect clogging 779 attacks. Each extension field is validated in the following order and 780 discarded if: 782 1. The request or response code is invalid or the data field has 783 incorrect length. 785 2. The signature field is either missing or has incorrect length. 787 3. The public key is missing or has incorrect length. 789 4. In the case of the agreement algorithm, the agreement parameterss are 790 missing or have incorrect lengths. 792 5. The signature timestamp is earlier than the last received timestamp 793 of the same type or the two timestamps are equal and the proventic bit 794 is set.. 796 6. Where applicable, the filestamp is earlier than the last received 797 filiestamp of the same type. 799 Only if the extension field passes all the above tests is the signature 800 verified using PKI algorithms. Otherwise and in general, a response is 801 generated for every request, even if the requestor is not proventicated. 802 However, some responses may have truncated data or signature fields 803 under certain conditions. If these fields are present and have correct 804 length, signatures are present and verifiable. 806 In the Autokey protocol every transmitted packet is associated with an 807 autokey previously computed and stored in the key list. When the last 808 entry in the list is used, a new list is constructed as described above. 809 This requires knowledge of the cookie value. If for some reason the 810 cookie value is changed, the remaining entries in the key list are 811 purged and a new one constructed. However, if an extension field is 812 present, the current autokey is discarded and the autokey reconstructed 813 using a cookie value of zero. 815 A timestamp-based agreement protocol is used to manage the distribution 816 of the certificate, agreement parameters and leapseconds table. The 817 association ID request and response messages include the certificate, 818 agreement and leapseconds bits from the system status word. one or more 819 of these bits are set when the associated data are present, either 820 loaded from local files or retrieved from another server at some earlier 821 time. If any of these bits are set in the association ID response to a 822 client in client/server mode or a peer in symmetric mode, the data are 823 requested from the server or peer and, once obtained, the bits are 824 reset. However, the response data are stored only if more recent than 825 the data already stored. 827 In the descriptions below, it is assumed that the client and server have 828 loaded their own private key and public key, as well as certificate, 829 agreement parameters and leapseconds table, where available. Public keys 830 for other servers, as well as the agreement parameters and leapseconds 831 table, can be loaded from local files or retrieved from any server. 832 Further information on generating and managing these files is in 833 Appendix B. 835 Preliminaries 837 The first thing the server needs to do is obtain the system status word, 838 which reveals which cryptographic values the server is prepared to 839 offer, and then the public key and certificate. These steps are 840 independent of which mode the server is operating in - client/server, 841 broadcast or symmetric modes. 843 The following pseudo-code describes the client state machine operations. 844 Note that the packet can one request and one or more responses. The 845 machine requires the association ID, public key and optional 846 certificate, in that order. While not further specified in this 847 memorandum, an optional parameter request message can be used to 848 negotiate algorithm identifiers, parameters and alternate identification 849 values. Note that the association ID response message also contains the 850 system status word, which contains the certificate bit. 852 if (response_pending) 853 send_response; 854 if (!parameters) 855 request_parameters; 856 if (!association_ID) 857 request_association_ID; 858 else if (!public_key) 859 request_public_key; 860 else if (certificate_bit) 861 request_certificate; 863 The following diagram shows the preliminary protocol dance. In this and 864 following diagrams the NTP packet type is shown above the arrow and the 865 extension field(s) message type shown below. Note that in the 866 client/server mode the server responds immediately to the request, but 867 in the symmetric modes the response may be delayed for a period up to 868 the current poll interval. The following cryptographic values are 869 instantiated by the dance: 871 public key server public key 872 host name server host name 873 CA name certificate authority host name (optional) 874 filestamp generation time of public key file 875 secure bit set when the public key is stored and validated 877 server client 878 | | 879 | NTP client | 880 1 |<-----------------| mobilize client association; generate key list 881 | assoc ID req | with default cookie; send status word 882 | | 883 | NTP server | 884 2 |----------------->| store status word 885 | assoc ID rsp | 886 | | 887 | NTP client | 888 3 |<-----------------| request public key and host name 889 | key/name req | 890 | | 891 | NTP server | 892 4 |----------------->| store public key, host name, filestamp and 893 | key/name rsp | timestamp 894 | ... | 895 | | 896 | NTP client | 897 5 |<-----------------| request certificate 898 | certif req | 899 | | 900 | NTP server | 901 6 |----------------->| store certificate; verify credentials; set 902 | certif rsp | secure bit 903 | ... | 905 The dance begins when the client (or symmetric-active peer) on the right 906 mobilizes an association, generates a key list using the default cookie 907 and sends an association ID request message (1) to the server (or 908 symmetric-passive peer) on the left. The server responds with an 909 association ID response message (2) including the server association ID 910 and status word. To protect against a clogging attack, the transmit 911 timestamp in the NTP header in the request must be identical to the 912 originate timestamp in the response. The client retransmits request (1) 913 at every poll opportunity until receiving a valid response (2) or 914 association timeout. 916 Some time later the client sends a public key/host name request (3) to 917 the server. The server responds with the requested data and associated 918 timestamp and filestamp (4). The client checks the timestamp and 919 filestamp, verifies the signature and initializes the public key and 920 host name. If the certificate bit in the status word is zero, indicating 921 the server is not prepared to send one, and if the client concurs, the 922 secure bit is set at this time and the certificate exchange is bypassed. 923 The client retransmits request (3) at every poll opportunity until 924 receiving a valid response (4) or association timeout. 926 The public key/host name message can be interpreted as a poor-man's 927 certificate, since it is signed and timestamped. However, strong 928 security requires a CA sign the host name and public key values and 929 establish a period of validity for the signature. As an optional 930 feature, the client sends a certificate request (5) to the server. The 931 server responds with the requested data and assciated timestamp and 932 filestamp (6). The response is signed by the CA's public key, so a 933 further step may be necessary to obtain the CA's certificate, which 934 contains its public key. The details for these additional steps are for 935 further study. 937 Since (4) is the first signed message received, the timestamp and 938 filestamp have only marginal utility, but do serve to avoid messages 939 from unsynchronized servers and deflect replays. The interesting 940 question is whether to provide automatic update when the server makes a 941 new key generation, since the new generation would have a later 942 filestamp and instantly deprecate all cryptographic values with earlier 943 timestamps. This brings up the question of a distributed greeting 944 protocol, which may be a topic for future study. Meanwhile, the 945 reference implementation accepts only the first message received and 946 discards all others. 948 When the secure bit is set, data in packets with signatures are valid 949 and the NTP protocol continues in parallel with the Autokey protocol. 951 Client/Server Modes (3/4) 953 In client/server modes the server keeps no state variables specific to 954 each of possibly very many clients and mobilizes no associations. The 955 server regenerates a cookie for each packet received from the client. 956 For this purpose, the server hashes the cookie from the IP addresses and 957 private value with the key ID field set to zero, as described 958 previously, then provides it to the client. Both the client and server 959 use the cookie to generate the autokey which validates each packet 960 received. To further strengthen the validation process, the client 961 selects a new key ID for every packet and verifies that it matches the 962 key ID in the server response to that packet. 964 Before proceeding to the full protocol description, it should be noted 965 that in the case of lightweight SNTP protocol associations, it is not 966 necessary to proceed beyond the preliminary protocol defined above. Most 967 if not all SNTP implementations send only a single client-mode packet 968 and expect only a single NTP server-mode packet in return. Since the 969 Autokey protocol is piggybacked in the NTP packet, the clock can be set 970 and the server authenticated with a single packet exchange if a 971 certificate is not required and in two exchanges if it is. Details of 972 this simplified protocol remain to be determined. 974 The following pseudo-code describes the client state machine operations. 975 The machine requires the association ID, public key, optional 976 certificate, cookie, autokey values and leapseconds table in that order, 977 but the autokey values are required only if broadcast client mode. 979 if (response_pending) 980 send_response; 981 if (!cookie) 982 request_cookie; 983 else if (!autokey_values && broadcast_client)) 984 request_autokey_values; 985 else if (!leapseconds_table) 986 request_leapseconds_table; 988 The following diagram shows the protocol dance in client/server mode. 989 The following cryptographic values are instantiated by the dance: 991 public key server public key 992 host name server host name 993 filestamp generation time of public key file 994 timestamp signature time of public key/host name values 996 cookie cookie determined by the server for this client 997 timestamp signature time of cookie 998 proventic bit set when client clock is synchronized to source 1000 server client 1001 | | 1002 | NTP client | 1003 7 |<-----------------| request cookie 1004 | cookie req | 1005 | | 1006 | NTP server | 1007 8 |----------------->| store cookie and timestamp; set proventic bit; 1008 | cookie rsp | 1009 | ... | 1010 | | 1011 | NTP client | 1012 9 |<-----------------| regenerate key list with server cookie 1013 | | 1014 | NTP server | 1015 10 |----------------->| 1016 | | 1017 | continue | 1018 = client/server = 1020 The dance begins when the client on the right mobilizes an association 1021 and validates the public key as in the preliminary dance above. Some 1022 time later the client sends a cookie request (7). The server immediately 1023 responds with the cookie and timestamp (8). The client checks the 1024 timestamp, verifies the signature and initializes the cookie and cookie 1025 timestamp, then sets the proventic bit. Since the cookie has changed, 1026 the client regenerates the key list with this cookie when the next 1027 packet is sent. The client retransmits request (7) at every poll 1028 opportunity until receiving a valid response (8) or association timeout. 1030 After successful verification, there is no further need for extension 1031 fields, unless an error occurs or the server generates a new private 1032 value. When this happens, the server fails to authenticate packet (9) 1033 and, following the original NTP protocol, responds with a NAK packet 1034 (10), which the client ignores. Eventually, an association timeout and 1035 general reset occurs and the dance restarts from the beginning. Of 1036 course, the NAK client could interpret the NAK message to restart the 1037 protocol immediately and avoid the timeout. However, this invites the 1038 opportunity for an intruder to destabilize the state machine with 1039 spurious NAK messages. 1041 Broadcast Mode (5) 1043 In broadcast mode, packets are always sent with an extension field. 1044 Since the autokey values for these packets use a well known default 1045 cookie (zero), they can in principle be remanufactured with a new MAC 1046 acceptable to the receiver; however, the key list provides the 1047 authentication function as described earlier. The broadcast server keeps 1048 no state variables specific to each of possibly very many clients and 1049 mobilizes no associations for them. 1051 The following pseudo-code describes the broadcast server state machine 1052 operations. Each broadcast packet includes one response message 1053 containing either the signed autokey values, if the first autokey on the 1054 key list, or the association ID and status word otherwise. Note however, 1055 when a broadcast client first comes up, the state machine also responds 1056 to client requests as in client/server mode without affecting the 1057 broadcast packets. Note that the association ID request and response 1058 messages also contain the system status word. 1060 if (new_list) 1061 send_autokey_values; 1063 else 1064 send_association_ID; 1066 The server on the left in the diagram below sends packets that are 1067 received by each of a possibly large number of clients, one of which is 1068 shown on the right. Ordinarily, clients do not send packets to the 1069 server, except to calibrate the propagation delay and to obtain 1070 cryptographic values such as the cookie and autokey values. The 1071 following diagram shows the protocol dance in broadcast mode. The 1072 following cryptographic values are instantiated by the dance: 1074 public key server public key 1075 host name server host name 1076 filestamp generation time of public key file 1077 timestamp signature time of public key/host name values 1079 cookie cookie determined by the server for this client 1080 timestamp signature time of cookie 1082 autokey values initial key ID, initial autokey 1083 timestamp signature time of autokey values 1085 proventic bit set when client clock is synchronized to source 1087 server client 1088 | | 1089 | NTP broadcast | 1090 1 |----------------->| mobilize broadcast client association; set 1091 | assoc ID rsp | initially to operate in client/server mode 1092 | | 1093 | ... | continue as in preliminary protocol above 1094 | | 1095 | NTP client | 1096 7 |<-----------------| request cookie 1097 | cookie req | 1098 | | 1099 | NTP server | 1100 8 |----------------->| store cookie and timestamp 1101 | cookie rsp | 1102 | ... | 1103 | | 1104 | NTP client | 1105 9 |<-----------------| regenerate key list with server cookie 1106 | autokey req | 1107 | | 1108 | NTP server | 1109 10 |----------------->| store autokey values and timestamp; set 1110 | autokey rsp | proventic bit 1111 | ... | 1112 | | 1113 | NTP client | 1114 |<-----------------| continue to accumulate time values 1115 | | 1116 | NTP server | 1117 |----------------->| 1118 | | 1119 | continue | 1120 = volley = 1121 | | 1122 | NTP client | 1123 |<-----------------| 1124 | | 1125 | NTP server | 1126 |----------------->| set clock and propagation estimate; discard 1127 | | remaining keys; switch to broadcast client mode 1128 | continue | 1129 = broadcast = 1130 | | 1131 | NTP broadcast | 1132 |----------------->| server rolls new key list; client refreshes 1133 | autokey rsp | autokey values 1134 | | 1135 = = 1137 The server sends broadcast packets (1) continuously at intervals of 1138 about one minute using the key list and regenerating the list as 1139 required. The first packet sent after regenerating the list includes the 1140 autokey values and signature; other packets include only the association 1141 ID and status word. 1143 The dance begins when the client on the right receives a broadcast 1144 message (1). It mobilizes a broadcast client association set initially 1145 to operate in client/server mode. It then continues to operate as in the 1146 prelimiary protocol to obtain and validate the public key and host name 1147 values. However, the client does not initiate the dance until some time 1148 later (to avoid implosion at the server). However, in addition to the 1149 status word, the association ID response includes the association ID of 1150 the server, so the correct association, if more than one, can be 1151 identified. 1153 Some time later the client sends a cookie request (7). The server 1154 immediately responds with the requested value (8). The client checks the 1155 timestamp, verifies the signature and initializes the cookie and cookie 1156 timestamp. Since the cookie has changed, the client regenerates the key 1157 list with this cookie when the next packet is sent. The client 1158 retransmits request (7) at every poll opportunity until receiving a 1159 valid response (8) or association timeout. 1161 If an autokey response happens to be in one of the server packets (1), 1162 the client has stored the autokey values and autokey timestamp, so can 1163 switch immediately to broadcast client mode and send no further packets. 1164 Otherwise, some time later the client sends an autokey request (9). The 1165 server immediately responds with the values (10). The client checks the 1166 timestamp, verifies the signature and initializes the autokey values and 1167 autokey timestamp and sets the proventic bit. The client retransmits 1168 packet (9) until receiving a valid response (10) or association timeout. 1170 After successful verification, there is no further need for extension 1171 fields and the client can switch to broadcast client mode and send no 1172 additional packets. However, it is the usual practice to send additional 1173 client/server packets in order for the client mitigation algorithms to 1174 refine the clock offset/delay estimates. When a sufficient number of 1175 estimates are available, the client discards the cookie and remaining 1176 keys on the key list, switches to broadcast client mode, calculates the 1177 propagation delay and sets the clock. 1179 When the server regenerates the key list, it sends an autokey response 1180 in the first packet, which allows the clients to validate it and reset 1181 the autokey values. Unless this packet happens to be lost, the clients 1182 can continue with no further interaction with the server. Otherwise, the 1183 client fails to authenticate the packets (1). Eventually, an association 1184 timeout and general reset occurs and the dance restarts from the 1185 beginning. 1187 Symmetric Active/Passive Mode (1/2) 1189 In symmetric modes there is no explicit client/server relationship, 1190 since each peer in the relationship can operate as a server with the 1191 other operating as a client. Which peer acts as the server depends on 1192 which peer has the smallest root synchronization distance to its 1193 ultimate reference source, and the choice may change from time to time. 1194 This requirement results in a quite complex interaction between the 1195 peers, especially when considering the many possibilities of failure and 1196 recovery. 1198 There are two protocol scenarios involving symmetric modes. The simplest 1199 scenario is where both peers have configured associations that operate 1200 continuously in symmetric active mode and cryptographic values such as 1201 the public key/host name, certificate, agreement parameters and public 1202 value can be configured in advance. A more interesting scenario is when 1203 a symmetric active peer with a configured association begins operation 1204 with a symmetric-passive peer initially without such an association. 1206 The following pseudo-code describes the symmetric state machine 1207 operations. Note that the packet can contain one request and one or two 1208 responses. The machine requires the association ID, public key, 1209 certificate, agreement parameters, agreement public value, autokey 1210 values and leapseconds table in that order. There is a provision to send 1211 the current autokey values when the peer has not requested them. This 1212 happens when a peer first proventicates and recomputes the key list 1213 using the agreed cookie. 1215 if (response_pending) 1216 send_response; 1217 if (!agreement_parameters) 1218 request_agreement_parameters; 1219 else if (!agreement) 1220 send_agreement; 1221 else if (!autokey_values) 1222 request_autokey_values; 1223 else if (!new_list) 1224 send_autokey_values; 1225 else if (!leapseconds_table) 1226 request_leapseconds_table; 1228 The following diagrams show the protocol dance in symmetric 1229 active/passive mode. The dance in symmetric active/active mode is much 1230 simpler and similar to two independent client/server modes, one for each 1231 direction, but with the cookie requests replaced by an agreement 1232 algorithm. Note that in the following the NTP client header is replaced 1233 by the NTP symmetric active header and the NTP server header is replaced 1234 by the NTP symmetric passive header. The following cryptographic values 1235 are instantiated by each peer in the dance: 1237 public key server public key 1238 host name server host name 1239 filestamp generation time of public key file 1240 timestamp signature time of public key/host name values 1242 cookie cookie determined by the agreement algorithm 1243 timestamp signature time of cookie 1245 autokey values initial key ID, initial autokey 1246 timestamp signature time of autokey values 1248 proventic bit set when client clock is synchronized to source 1250 passive active 1251 | | 1252 | NTP active | 1253 1 |<-----------------| mobilize symmetric active association; generate 1254 | assocID req | key list with default cookie; send status word 1255 | | 1256 | ... | continue as in preliminary protocol above 1257 | | 1258 | NTP passive | 1259 2 |----------------->| store status word 1260 | assoc ID rsp | 1261 | | 1262 | NTP active | 1263 1 |<-----------------| generate key list with default cookie; request 1264 | key/name req | passive key/name 1265 | ... | 1266 | | 1267 | NTP passive | 1268 2 |----------------->| verify passive credentials 1269 | key/name rsp | 1270 | key/name req | 1271 | ... | 1272 | | 1273 | NTP active | 1274 3 |<-----------------| send active key/name; request agreement 1275 | key/name rsp | parameters 1276 | param req | 1277 | ... | 1278 | | 1279 | NTP passive | 1280 4 |----------------->| store agreement parameters; and timestamp; set 1281 | param rsp | proventic bit 1282 | agree rsp | 1283 | ... | 1284 | | 1285 | NTP active | 1286 3 |<-----------------| send active key/name; request agreement 1287 | key/name rsp | parameters 1288 | param req | 1289 | ... | 1290 | | 1291 | NTP passive | 1292 4 |----------------->| store autokey values and timestamp; set 1293 | key/name req | proventic bit 1294 | autokey rsp | 1295 | ... | 1296 | | 1297 | NTP active | 1298 5 |<-----------------| continue to accumulate time values 1299 | key/name rsp | 1300 | | 1301 = continue = 1302 | | 1303 | NTP passive | 1304 6 |----------------->| set clock 1305 | key/name req | 1306 | | 1307 | continue below | 1308 = = 1310 The dance begins when the active peer on the right generates a key list 1311 with default cookie and timestamp and sends a public key/host name 1312 request to the passive peer on the left (1). The passive peer checks its 1313 access control list and (optionally) queries the DNS using the server IP 1314 address to obtain related cryptographic values. If successful, the peer 1315 mobilizes an association in symmetric passive mode, but takes no further 1316 action until the next poll interval, as required by the NTP protocol. 1317 From this point the passive peer responds to requests, but otherwise 1318 ignores all time values until the active peer has set its clock and can 1319 provide valid timestamps. 1321 Some time later the passive peer generates a key list with default 1322 cookie and timestamp and sends its public key/host name values along 1323 with a request for the public key/host name values of the active peer 1324 (2). Subsequently, the active peer sends these values, but they are 1325 ignored since the timestamps are invalid. Meanwhile, the active peer 1326 checks the timestamp, verifies the signature and initializes the public 1327 key/host name values, filestamp and timestamp. The active peer 1328 retransmits request (1) at every poll opportunity until receiving a 1329 valid response (2) or until association timeout. 1331 Some time later the active peer sends the requested public key/host name 1332 values along with an autokey request (3). The passive peer retransmits 1333 request (2) at every poll opportunity until receiving a valid timestamp 1334 and verified signature or until association timeout. Since the cookies 1335 for each peer already have a common value and the active peer is 1336 unsynchronized, it is pointless to run the agreement algorithm. 1338 Some time later the passive peer sends the requested autokey values (4). 1339 The active peer checks the timestamp, verifies the signature and 1340 initializes the autokey values and timestamp and sets the proventic bit. 1341 At this point the active peer has authenticated the passive peer, but 1342 may not have accumulated sufficient time values to set the clock and 1343 provide valid timestamps. Operation continues in rounds where the 1344 passive peer requests the public key/host name values and the active 1345 peer returns them, but the passive peer ignores them. Eventually, the 1346 active peer accumulates sufficient time values to set the clock. While 1347 the cookie has not changed, the timestamp has, so the key list is 1348 regenerated with the default key (strictly speaking, only the signature 1349 needs to be recomputed). The active peer is now proventicated, but the 1350 passive peer has not yet authenticated the active peer. 1352 Some understanding of the tricky actions to follow can be gained from 1353 the observation that, up until this point every message received by the 1354 active peer had a signed response field, so that the cookie value is the 1355 default. However, at this point the active peer has all the 1356 cryptographic means at hand and does not need to request anything 1357 further from the passive peer. Thus, the passive peer sends nothing but 1358 requests and these are not signed or timestamped. Since the cryptograhic 1359 security relies entirely on the autokey test, it is important that both 1360 peers generate key lists with the same cookie. 1362 The steps now taken are shown below with the active peer on the left and 1363 the passive peer on the right. 1365 active passive 1366 | | 1367 | NTP active | 1368 1 |----------------->| validate active peer, compute agreed key, 1369 | key/name rsp | regenerate key list with peer key 1370 | public req | 1371 | | 1372 | NTP passive | 1373 2 |<-----------------| active computes agreed key, regenerates key 1374 | public rsp | list with agreed key 1375 | autokey req | 1376 | ... | 1377 | | 1378 | NTP active | 1379 3 |----------------->| set authentic 1380 | autokey rsp | 1381 | autokey req | 1382 | ... | 1383 | | 1384 | NTP passive | 1385 4 |<-----------------| 1386 | autokey rsp | 1387 | ... | 1388 | | 1389 | NTP active | 1390 5 |----------------->| regular operation (no extension fields) 1391 | ... | 1392 | | 1393 | NTP passive | 1394 6 |<-----------------| 1395 | | 1396 | continue | 1397 = active/passive = 1399 The agreement parameters must have been previously obtained by at least 1400 one of the peers, either directly from a file or indirectly from another 1401 server running the Autokey protocol. A peer needing the parameters sends 1402 an agreement parameters request to the other peer and that peer responds 1403 with the requested data. This exchange, along with the leapseconds table 1404 exchange, is similar to the public key/host name exchange, but not shown 1405 here. 1407 Once the proventic bit is set, the next message sent by the active peer 1408 contains the public key/host name requested by the passive peer, but now 1409 with valid timestamp, plus a public value request containing the active 1410 peer public value (1). The passive peer checks the public key/host name 1411 filestamp and timestamp, verifies the signature and initializes the 1412 values. Optionally, it checks its access control list and queries the 1413 DNS using the server IP address to obtain related cryptographic values. 1414 Conceivably, the active peer could be found bogus at this time; what to 1415 do in this case is for further study. 1417 The passive peer next checks the public value request timestamp, 1418 verifies the signature and runs the agreement algorithm to construct the 1419 shared cookie. Since the cookie has changed, the peer regenerates the 1420 key list with this cookie when the next packet is sent. 1422 Some time later the passive peer sends a public value response including 1423 its own public value together with an autokey request (2). The active 1424 peer checks the timestamp, verifies the signature and runs the agreement 1425 algorithm to construct the shared cookie. Since the cookie has changed, 1426 the peer regenerates the key list with this cookie when the next packet 1427 is sent. The active peer retransmits the public value request (only) (1) 1428 at every poll opportunity until receiving a valid response (2) or 1429 association timeout. 1431 Some time later the active peer sends its autokey values as requested 1432 together with an autokey request (3). The passive peer checks the 1433 timestamp, verifies the signature, initializes the autokey values and 1434 sets its proventic bit. The passive peer retransmits request (2) at 1435 every poll opportunity until receiving a valid response (3) or 1436 association timeout. 1438 Some time later the passive peer sends its autokey values as requested 1439 (4). The active peer checks the timestamp, verifies the signature, and 1440 initializes the autokey values (the proventic bit is already set). The 1441 active retransmits the autokey request (only) (3) until receiving a 1442 valid response (4) or association timeout. 1444 At this point both peers have completed the Autokey dance and each is 1445 authenticated to the other. However, note that the NTP rules require a 1446 peer operating at a lower stratum disregards time values from a hither 1447 stratum peer; so, while the peers continue to exchange time values, the 1448 values will not be used unless the passive server for some reason loses 1449 its synchronization source. 1451 After successful authentication, there is no further need for extension 1452 fields, unless an error occurs or one of the peers generates new public 1453 values. The protocol requires that, if a peer receives a public value 1454 resulting in a different cookie, it must send its own public value. 1455 Since the autokey values are included in an extension field when a new 1456 key list is generated, there is ordinarily no need to request these 1457 values, unless one or the other peer restarts the protocol or the packet 1458 containing the autokey values is lost. Eventually, an association 1459 timeout and general reset occurs and the dance restarts from the 1460 beginning. 1462 Security Analysis 1464 This section discusses the most obvious security vulnerabilities in the 1465 various modes and phases of operation. Throughout the discussion the 1466 cryptographic algorithms themselves are assumed secure; that is, a 1467 successful brute force attack on the algorithms or public/private keys 1468 or agreement values is unlikely. However, vulnerabilities remain in the 1469 way the actual cryptographic data, including the cookie and autokey 1470 values, are computed and used. 1472 While the protocol has not been subjected to a formal analysis, a few 1473 preliminary observations are warranted. The protocol cannot loop forever 1474 in any state, since the association timeout and general reset insure 1475 that the association variables will eventually be purged and the 1476 protocol will start from the beginning. A general reset is performed on 1477 all associations when the clock is first set and when it is stepped 1478 after that. This purges all cryptographic values and time values 1479 dependent on unproventicated sources. 1481 The first exchange in all protocol modes involves an association ID 1482 request and response cycle. Bits in the server status word indicate 1483 whether the server has the agreement paramters and/or leapseconds table. 1484 The association ID messages are not protected by a signature, so 1485 presumably an intruder can manufacture fake bits causing a client 1486 livelock or deadlock condition. To protect against this vulnerability, 1487 the transmit timestamp of the request is matched against the originate 1488 timestamp of the response. The response is accepted only if the two 1489 values match. An intruder is unlikely to predict the transmit timestamp, 1490 which in this case is an effective nonce. 1492 Once the clock is set, and except for the special cases summarized 1493 below, no old or duplicate values will be accepted in any state and an 1494 intruder cannot induce a clogging attack, since the MAC, autokey and 1495 timestamp tests will discard packets before a clogging vulnerability is 1496 exposed. While significant vulnerabilities exist during the initial 1497 protocol states while the necessary values are being obtained, the most 1498 an intruder can do is prevent the protocol dance from completing. If it 1499 does complete, it must complete correctly. 1501 The cryptographic values are always obtained in the same order and in 1502 the same order as the dependency relationships between them. No 1503 cryptographic variables or time variables are instantiated unless the 1504 server is proventic and proventicated. The public key and host name must 1505 be obtained first and no other messages are accepted until they have 1506 been obtained. The cookie must be obtained before the autokey values 1507 that depend on them, etc. Finally, in symmetric modes, both peers obtain 1508 cryptographic values in the same order, so deadlock cannot occur. 1510 Some observations on the particular engineering constraints of the 1511 Autokey protocol are in order. First, the number of bits in some 1512 cryptographic values are considerably smaller than would ordinarily be 1513 expected for strong cryptography. One of the reasons for this is the 1514 need for compatibility with previous NTP versions; another is the need 1515 for small and constant latencies and minimal processing requirements. 1516 Therefore, what the scheme gives up on the strength of these values must 1517 be regained by agility in the rate of change of the cryptographic basis 1518 values. Thus, autokeys are used only once and basis values are 1519 regenerated frequently. However, in most cases even a successful 1520 cryptanalysis of these values compromises only a particular 1521 client/server association and does not represent a danger to the general 1522 population. 1524 There are three tiers of defense against hostile intruder interference. 1525 The first is the message authentication code (MAC) based on a keyed 1526 message digest or autokey generated as the hash of the IP address 1527 fields, key ID field and a special cookie, which can be public or the 1528 result of an agreement algorithm. If the message digest computed by the 1529 client does not match the value in the MAC, either the autokey used a 1530 different cookie than the server or the packet was modified by an 1531 intruder. Packets that fail this test are discarded without further 1532 processing; in particular, without spending processor cycles on 1533 expensive public-key algorithms. 1535 The second tier of defense involves the key list, which is generated as 1536 a repeated hash of autokeys and used in the reverse order. While any 1537 receiver can authenticate a message by hashing to match a previous key 1538 ID, as a practical matter an intruder cannot predict the next key ID and 1539 thus cannot spoof a packet acceptable to the client. In addition, 1540 tedious hashing operations provoked by replays of old packets are 1541 suppressed because of the basic NTP protocol design. Finally, spurious 1542 public-key computations provoked by replays of old packets with 1543 extension fields are suppressed because of the signature timestamp 1544 check. 1546 The third tier of defense is represented by the Autokey protocol and 1547 extension fields with timestamped signatures. The signatures are used to 1548 reliably bind the autokey values to the private key of a trusted server. 1549 Once these values are instantiated, the key list authenticates each 1550 packet relative to its predecessors and by induction to the instantiated 1551 autokey values. 1553 In addition to the three-tier defense strategy, all packets are 1554 protected by the NTP sanity checks. Since all packets carry time values, 1555 replays of old or bogus packets can be deflected once the client has 1556 synchronized to proventic sources. However, the NTP sanity checks are 1557 only effective once the packet has passed all cryptographic tests. This 1558 is why the signature timestamp is necessary to avoid expensive 1559 calculations that might be provoked by replays. Since the signature and 1560 verify operations have a high manufacturing cost, in all except 1561 client/server modes the protocol design protects against a clogging 1562 attack by signing cryptographic values only when they are created or 1563 changed and not on request. 1565 Specific Attacks 1567 While the above arguments suggest that the vulnerability of the Autokey 1568 protocols to cryptanalysis is suitably hard, the same cannot be said 1569 about the vulnerability to a replay or clogging attack, especially when 1570 a client is first mobilized and has not yet proventicated. In the 1571 following discussion a clogging attack is considered a replay attack at 1572 high speed which can clog the network and deny service to other network 1573 users or clog the processor and deny service to other users on the same 1574 machine. While a clogging attack can be concentrated on any function or 1575 algorithm of the Autokey protocol, the must vulnerable target is the 1576 public key routines to sign and verify public values. It is vital to 1577 shield these routines from a clogging attack. 1579 In all modes the cryptographic seed data used to generate cookies and 1580 autokey values are changed from time to time. Thus, a determined 1581 intruder could save old request and response packets containing these 1582 values and replay them before or after the seed data have changed. Once 1583 the client has proventicated, the client will detect replays due to the 1584 old timestamp and discard the data. This is why the timestamp test is 1585 done first and before the signature is computed. However, before this 1586 happens, the client is vulnerable to replays whether or not they result 1587 in clogging. 1589 There are two vulnerabilities exposed in the protocol design: a sign 1590 attack where the intruder hopes to clog the victim with needless 1591 signature computations, and a verify attack where the intruder attempts 1592 to clog the victim with needless verification computations. The 1593 reference implementation uses the RSA public key algorithms for both 1594 sign and verify functions and these algorithms require significant 1595 processor resources. 1597 In order to reduce the exposure to a sign attack, signatures are 1598 computed only when the data have changed. For instance, the autokey 1599 values are signed only when the key list is regenerated, which happens 1600 about once an hour, while the public values are signed only when the 1601 agreement values are regenerated, which happens about once per day. 1602 However, a server is vulnerable to a sign attack where the intruder can 1603 clog the server with cookie-request messages. The protocol design 1604 precludes server state variables stored on behalf of any client, so the 1605 signature must be recomputed for every cookie request. Ordinarily, 1606 cookie requests are seldom used, except when the private values are 1607 regenerated. However, a determined intruder could replay intercepted 1608 cookie requests at high rate, which may very well clog the server. There 1609 appears no easy countermeasure for this particular attack. 1611 The intruder might be more successful with a verify attack. Once the 1612 client has proventicated, replays are detected and discarded before the 1613 signature is verified. However, if the cookie is known or compromised, 1614 the intruder can replace the timestamp in an old message with one in the 1615 future and construct a packet with a MAC acceptable to a client, even if 1616 it has bogus signature and incorrect autokey sequence. The packet passes 1617 the MAC test, but then tricks the client to verify the signature, which 1618 of course fails. What makes this kind of attack more serious is the fact 1619 that the cookie used when extension fields are present is well known 1620 (zero). Since all broadcast packets have an extension field, all the 1621 intruder has to do is clog the clients with responses including 1622 timestamps in the future. Assuming the intruder has joined the NTP 1623 broadcast group, the attack could clog all other members of the group. 1624 This attack can be deflected by the autokey test, which in the reference 1625 implementation is after extension field processing, but this requires 1626 very intricate protocol engineering and is left for a future refinement. 1628 An interesting vulnerability in client/server mode is for an intruder to 1629 replay a recent client packet with an intentional bit error. This could 1630 cause the server to return the special NAK packet. A naive client might 1631 conclude the server had refreshed its private value and so attempt to 1632 refresh the server cookie using a cookie-request message. This results 1633 in the server and client burning spurious machine cycles and invites a 1634 clogging attack. This is why the reference implementation simply 1635 discards all protocol and procedure errors and waits for timeout in 1636 order to refresh the values. However, a more clever client may notice 1637 that the NTP originate timestamp does not match the most recent client 1638 packet sent, so can discard the bogus NAK immediately. 1640 In broadcast and symmetric modes the client must include the association 1641 ID in the Autokey request. Since association ID values for different 1642 invocations of the NTP daemon are randomized over the 16-bit space, it 1643 is unlikely that a very old packet would contain a valid ID value. An 1644 intruder could save old server packets and replay them to the client 1645 population with the hope that the values will be accepted and cause 1646 general chaos. The conservative client will discard them on the basis of 1647 invalid timestamp. 1649 As mentioned earlier in this memorandum, an intruder could pounce on the 1650 initial volley between peers in symmetric mode before both peers have 1651 determined each other reachable. In this volley the peers are vulnerable 1652 to an intruder using fake timestamps. The result can be that the peers 1653 never synchronize the timestamps and never completely mobilize their 1654 associations. 1656 Present Status and Unifinished Business 1658 The Autokey protocol described in this memorandu has been implemented in 1659 the public software distribution for NTP Version 4 and has been tested 1660 in machines of either endian persuasion and both 32- and 64-bit 1661 architectures and kernels. Testing the implementation has been 1662 complicated by the many combinations of modes and failure/recovery 1663 mechanisms, including daemon restarts, key expiration, communication 1664 failures and various management mistakes. The experience points up the 1665 fact that many little gotchas that are survivable in ordinary protocol 1666 designs become showstoppers when strong cryptographic assurance is 1667 required. 1669 The analysis, design and implementation of the Autokey protocol is 1670 basically mature; however, There are several remaining implementation 1671 issues. One has to do with cryptographic parameter negotiation, as in 1672 IPSEC protocols such as Photuris. As with Photuris, there may be a need 1673 to offer and agree to one of possibly several hashing algorithms, 1674 signature algorithms and agreement algorithms. A message type has been 1675 defined for this purpose, but its syntax and semantics remain to be 1676 provoked. 1678 Another issue is support for certificates and certificate authorities, 1679 in particular Secure DNS services. In the reference implementation a 1680 complicating factor is the existing banal state of the configuration and 1681 resolver code. Over the years this code has sprouted to a fractal-like 1682 state where possibly the only correct repair is a complete rewrite. 1684 Appendix A. Packet Formats 1686 The NTP Version 4 packet consists of a number of fields made up of 32- 1687 bit (4 octet) words. The packet consists of three components, the 1688 header, one or more optional extension fields and an optional message 1689 authenticator code (MAC), consisting of the Key ID and Message Digest 1690 fields. The format is shown below, where the size of some multiple word 1691 fields is shown in bits. 1693 1 2 3 1694 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 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 |LI | VN |Mode | Stratum | Poll | Precision | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Root Delay | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Root Dispersion | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Reference ID | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | | 1705 | Reference Timestamp (64) | 1706 | | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | | 1709 | Originate Timestamp (64) | 1710 | | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | | 1713 | Receive Timestamp (64) | 1714 | | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | | 1717 | Transmit Timestamp (64) | 1718 | | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | | 1721 | | 1722 = Extension Field(s) = 1723 | | 1724 | | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Key ID | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | | 1729 | | 1730 | Message Digest (128) | 1731 | | 1732 | | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 The NTP header extends from the beginning of the packet to the end of 1736 the Transmit Timestamp field. The format and interpretation of the 1737 header fields are backwards compatible with the NTP Version 3 header 1738 fields as described in RFC-1305, except for a slightly modified 1739 computation for the Root Dispersion field. In NTP Version 3, this field 1740 includes an estimated jitter quantity based on weighted absolute 1741 differences, while in NTP Version 4 this quantity is based on weighted 1742 root-mean-square (RMS) differences. 1744 An unauthenticated NTP packet includes only the NTP header, while an 1745 authenticated one contains a MAC. The format and interpretation of the 1746 NTP Version 4 MAC is described in RFC-1305 when using the Digital 1747 Encryption Standard (DES) algorithm operating in cipher block chaining 1748 (CBC) node. While this algorithm and mode of operation is supported in 1749 NTP Version 4, the DES algorithm has been removed from the standard 1750 software distribution and must be obtained via other sources. The 1751 preferred replacement for NTP Version 4 is the Message Digest 5 (MD5) 1752 algorithm, which is included in the distribution. The Message Digest 1753 field is 64 bits for DES-CBC and 128 bits for MD5, while the Key ID 1754 field is 32 bits for either algorithm. 1756 In NTP Version 4 one or more extension fields can be inserted after the 1757 NTP header and before the MAC, which is always present when an extension 1758 field is present. Each extension field contains a request or response 1759 message, which consists of a 16-bit length field, an 8-bit control 1760 field, an 8-bit flags field and a variable length data field, all in 1761 network byte order: 1763 1 2 3 1764 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 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 |R|E| Version | Code | Length | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | | 1769 = Data = 1770 | | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 There are two flag bits defined. Bit 0 is the response flag (R) and bit 1774 1 is the error flag (E); the other six bits are presently unused and 1775 should be set to 0. The Version field identifies the version number of 1776 the extension field protocol; this memorandum specifies version 1. The 1777 Code field specifies the operation in request and response messages. The 1778 length includes all octets in the extension field, including the length 1779 field itself. Each extension field is rounded up to the next multiple of 1780 4 octets and the last field rounded up to the next multiple of 8 octets. 1781 The extension fields can occur in any order; however, in some cases 1782 there is a preferred order which improves the protocol efficiency. 1784 The presence of the MAC and extension fields in the packet is determined 1785 from the length of the remaining area after the header to the end of the 1786 packet. The parser initializes a pointer just after the header. If the 1787 length is not a multiple of 4, a format error has occurred and the 1788 packet is discarded. If the length is zero the packet is not 1789 authenticated. If the length is 4 (1 word), the packet is an error 1790 report resulting from a previous packet that failed the message digest 1791 check. The 4 octets are presently unused and should be set to 0. If the 1792 length is 12 (3 words), a MAC (DES-CBC) is present, but no extension 1793 field; if 20 (5 words), a MAC (MD5) is present, but no extension field; 1794 If the length is 8 (2 words) or 16 (4 words), the packet is discarded 1795 with a format error. If the length is greater than 20 (5 words), one or 1796 more extension fields are present. 1798 If an extension field is present, the parser examines the length field. 1799 If the length is less than 4 or not a multiple of 4, a format error has 1800 occurred and the packet is discarded; otherwise, the parser increments 1801 the pointer by this value. The parser now uses the same rules as above 1802 to determine whether a MAC is present and/or another extension field. An 1803 additional implementation-dependent test is necessary to ensure the 1804 pointer does not stray outside the buffer space occupied by the packet. 1806 In the most common protocol operations, a client sends a request to a 1807 server with an operation code specified in the Code field and the R bit 1808 set to 0. Ordinarily, the client sets the E bit to 0 as well, but may in 1809 future set it to 1 for some purpose. The server returns a response with 1810 the same operation code in the Code field and the R bit set to 1. The 1811 server can also set the E bit to 1 in case of error. However, it is not 1812 a protocol error to send an unsolicited response with no matching 1813 request. 1815 There are currently five request and six response messages. All request 1816 messages except the Association ID request message have the following 1817 format: 1819 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 |0|0| 1 | Code | Length | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | Association ID | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 The Association ID field is used to match a client request to a 1828 particular server association. By convention, servers set the 1829 association ID in the response and clients include the same value in 1830 requests. Also by convention, until a client has received a response 1831 from a server, the client sets the Association ID field to 0. If for 1832 some reason the association ID value in a request does not match the 1833 association ID of any mobilized association, the server returns the 1834 request with both the R and E bits set to 1. 1836 The following request and response messages have been defined. 1838 Parameter Negotiation (1) 1840 This extension field is reserved for future use as an algorithm and 1841 algorithm parameter offer/select exchange, as well as to provide the 1842 optional identification value to use in lieu of endpoint IP addresses 1843 when calculating the autokey. The format, encoding and use of these data 1844 remain to be specified. The command code is reserved. 1846 Association ID (2) 1847 A client sends the request to obtain the association ID and status 1848 flags. A broadcast server sends an unsolicited response for all except 1849 the first autokey sent from the key list. The request and response have 1850 the following format (except for the response bit): 1852 1 2 3 1853 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 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 |0|E| 1 | 2 | Length | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Association ID | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Flags | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 The Association ID field contains the association ID of the server. The 1863 status flags currently defined are 1865 Bit Function 1866 ================ 1867 31 autokey is enabled 1868 30 public and private keys have been loaded 1869 29 agreement parameters have been loaded 1870 28 leapseconds table has been loaded 1872 Additional bits may be defined in future, so for now bits 0-27 should be 1873 set to zero. There is no timestamp or signature associated with this 1874 message. 1876 Autokey (3) 1878 A broadcast server or symmetric peer sends the request to obtain the 1879 autokey values. The response has the following format: 1881 1 2 3 1882 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 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 |1|E| 1 | 4 | Length | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Association ID | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | Timestamp | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Initial Sequence | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Initial Key ID | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Signature Length | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | | 1897 | | 1898 = Signature = 1899 | | 1900 | | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 The response is also sent unsolicited when the server or peer generates 1904 a new key list. The Initial Sequence field contains the first key number 1905 in the current key list and the Initial Key ID field contains the next 1906 key ID associated with that number. If the server is not synchronized to 1907 a proventicated source, the Timestamp field contains 0; otherwise, it 1908 contains the NTP seconds when the key list was generated and signed. The 1909 signature covers all fields from the Timestamp field through the Initial 1910 Key ID field. If for some reason these values are unavailable or the 1911 signing operation fails, the Initial Sequence and Initial Key ID fields 1912 contain 0 and the extension field is truncated following the Initial Key 1913 ID field. 1915 Cookie (4) 1917 A client sends the request to obtain the server cookie. The response has 1918 the following format: 1920 1 2 3 1921 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 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 |1|E| 1 | 3 | Length | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | Association ID | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Timestamp | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Cookie | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Signature Length | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | | 1934 | | 1935 = Signature = 1936 | | 1937 | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 Since there is no server association matching the client, the 1941 association ID field for the request and response is 0. The Cookie field 1942 contains the cookie used in client/server modes. If the server is not 1943 synchronized to a proventicated source, the Timestamp field contains 0; 1944 otherwise, it contains the NTP seconds when the cookie was computed and 1945 signed. The signature covers the Timestamp and Cookie fields. If for 1946 some reason the cookie value is unavailable or the signing operation 1947 fails, the Cookie field contains 0 and the extension field is truncated 1948 following this field. 1950 Diffie-Hellman Parameters (5) 1951 A symmetric peer uses the request and response to send the public value 1952 and signature to its peer. The response has the following format: 1954 1 2 3 1955 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 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 |1|E| 1 | 5 | Length | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | Association ID | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Timestamp | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Parameters Filestamp | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Parameters Length | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | | 1968 | | 1969 = Parameters = 1970 | | 1971 | | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Signature Length | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | | 1976 | | 1977 = Signature = 1978 | | 1979 | | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 The Parameters field contains the Diffie-Hellman parameters used to 1983 compute the public and private values. The Parameters Filestamp field 1984 contains the NTP seconds when the Diffie-Hellman parameter file was 1985 generated. If the server is not synchronized to a proventicated source, 1986 the Timestamp field contains 0; otherwise, it contains the NTP seconds 1987 when the public value was generated and signed. The signature covers the 1988 Timestamp, Parameters Length and Parameters fields. If for some reason 1989 these values are unavailable or the signing operation fails, the 1990 Parameters Length field contains 0 and the extension field is truncated 1991 following this field. 1993 Public Value (6) 1995 A symmetric peer uses the request and response to send the public value 1996 and signature to its peer. The response has the following format: 1998 1 2 3 1999 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 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 |1|E| 1 | 5 | Length | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Association ID | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | Timestamp | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Filestamp | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | Public Value Length | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | | 2012 | | 2013 = Public Value = 2014 | | 2015 | | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Signature Length | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | | 2020 | | 2021 = Signature = 2022 | | 2023 | | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 The Public Value field contains the Diffie-Hellman public value used to 2027 compute the agreed key. 2029 The Filestamp field contains the NTP seconds when the Diffie-Hellman 2030 parameter file was generated. If the server is not synchronized to a 2031 proventicated source, the Timestamp field contains 0; otherwise, it 2032 contains the NTP seconds when the public value was generated and signed. 2033 The signature covers all fields from the Timestamp field through the 2034 Public Value field. If for some reason these values are unavailable or 2035 the signing operation fails, the Public Value Length field contains 0 2036 and the extension field is truncated following this field. 2038 Public Key/Host Name (7) 2040 A client uses the request to retrieve the public key, host name and 2041 signature. The response has the following format: 2043 1 2 3 2044 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 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 |1|E| 1 | 7 | Length | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Public Key ID | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Association ID | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 | Timestamp | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | Filestamp | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | Public Key Length | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | | 2059 | | 2060 = Public Key = 2061 | | 2062 | | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Host Name Length | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | | 2067 | | 2068 = Host Name = 2069 | | 2070 | | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Signature Length | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 | | 2075 | | 2076 = Signature = 2077 | | 2078 | | 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 Since the public key and host name are a property of the server and not 2082 any particular association, the association ID field for the request and 2083 response is 0. The Public Key field contains the RSA public key in 2084 rsaref2.0 format; that is, the modulus length (in bits) as the first 2085 word followed by the modulus bits. Note that in some architectures the 2086 rsaref2.0 modulus word may be something other than 32 bits. The Host 2087 Name field contains the host name string returned by the Unix 2088 gethostname() library function. 2090 The Filestamp field contains the NTP seconds when the public/private key 2091 files were generated. If the server is not synchronized to a 2092 proventicated source, the Timestamp field contains 0; otherwise, it 2093 contains the NTP seconds when the public value was generated and signed. 2094 The signature covers all fields from the Timestamp field through the 2095 Host Name field. If for some reason these values are unavailable or the 2096 signing operation fails, the Host Name Length field contains 0 and the 2097 extension field is truncated following this field. 2099 Leapseconds table (8) 2101 The civil timescale (UTC), which is based on Earth rotation, has been 2102 diverging from atomic time (TAI), which is based on an ensemble of 2103 cesium oscillators, at about one second per year. Since 1972 the 2104 International Bureau of Weights and Measures (BIPM) declares on occasion 2105 a leap second to be inserted in the UTC timescale on the last day of 2106 June or December. Sometimes it is necessary to correct UTC as 2107 disseminated by NTP to agree with TAI on the current or some previous 2108 epoch. 2110 A client uses the request to retrieve the leapseconds table and 2111 signature. The response has the following format: 2113 1 2 3 2114 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 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |1|E| 1 | 8 | Length | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Public Key ID | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | Association ID | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | Timestamp | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | Filestamp | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | Leapseconds table Length | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | | 2129 | | 2130 = Leapseconds table = 2131 | | 2132 | | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Signature Length | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | | 2137 | | 2138 = Signature = 2139 | | 2140 | | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 The NTP extension field format consists of a table with one entry in NTP 2144 seconds for each leap second. 2146 Since the leapseconds table is a property of the server and not any 2147 particular association, the association ID field for the request and 2148 response is 0. The Leapseconds table field contains a list of the 2149 historic epoches that leap seconds were inserted in the UTC timescale. 2150 Each list entry is a 32-bit word in NTP seconds, while the table is in 2151 order from the most recent to the oldest insertion. At the first 2152 insertion in January, 1972 UTC was ahead of TAI by 10 s and has 2153 increased by 1 s for each insertion since then. Thus, the table length 2154 in bytes divided by four plus nine is the current offset of UTC relative 2155 to TAI. 2157 The Filestamp field contains the NTP seconds when the leapseconds table 2158 was generated at the original host, in this case one of the public time 2159 servers operated by NIST. If the value of the filestamp is less than the 2160 first entry on the list, the first entry is the epoch of the predicted 2161 next leap insertion. The filestamp must always be greater than the 2162 second entry in the list. If the server is not synchronized to a 2163 proventicated source, the Timestamp field contains 0; otherwise, it 2164 contains the NTP seconds when the public value was generated and signed. 2165 The signature covers all fields from the Timestamp field through the 2166 Leapseconds table field. If for some reason these values are unavailable 2167 or the signing operation fails, the Host Name Length field contains 0 2168 and the extension field is truncated following this field. 2170 Appendix B. Key Generation and Management 2172 In the reference implementation the lifetimes of various cryptographic 2173 values are carefully managed and frequently refreshed. While permanent 2174 keys have lifetimes that expire only when manually revoked, autokeys 2175 have a lifetime specified at the time of generation. When generating a 2176 key list for an association, the lifetime of each autokey is set to 2177 expire one poll interval later than it is scheduled to be used. 2178 Ordinarily, key lists are regenerated and signed about once per hour and 2179 private cookie values and public agreement values are refreshed and 2180 signed about once per day. The protocol design is specially tailored to 2181 make a smooth transition when these values are refreshed and to avoid 2182 vulnerabilities due to clogging and replay attacks while refreshment is 2183 in progress. 2185 Autokey key management can be handled in much the same way as in the ssh 2186 facility. A set of public and private keys and agreement parameters are 2187 generated by a utility program designed for this purpose. The program 2188 generates four files, one containing random DES/MD5 private keys, which 2189 are not used in the Autokey protocol, a second containing the RSA 2190 private key, a third the RSA public key, and a fourth the Diffie-Hellman 2191 agreement parameters. In addition, the leapseconds table is generated 2192 and stored in public time servers maintained by NIST. The means to do 2193 this are beyond the scope of this memorandum. 2195 All files are based on random strings seeded by the system clock at the 2196 time of generation and are in printable ASCII format with PEM (base-64) 2197 encoding. The name of each file includes an extension consisting of the 2198 NTP seconds at the time of generation. This is interpreted as a key ID 2199 in order to detect incorrect keys and to handle key changeovers in an 2200 orderly way. In the recommended method, all files except the RSA private 2201 key file are installed in a shared directory /usr/local/etc, which is 2202 where the daemon looks for them by default. The private RSA key file is 2203 installed in an unshared directory such as /etc. It is convenient to 2204 install links from the default file names, which do not have filestamp 2205 extensions, to the current files, which do. This way when a new 2206 generation of keys is installed, only the links need to be changed. 2208 When a server or client first initializes, it loads the RSA public and 2209 private key files, which are required for continued operation. It then 2210 attempts to load the agreement parameters file, certificate file and 2211 leapseconds table file. If one or more of these files are present, the 2212 associated bit is set in the system status word. Neither of these files 2213 are necessary at this time, since the data can be retrieved later from 2214 another server. If obtaining these data from another server is 2215 considered a significant vulnerability, the files should be present. 2217 In the current management model, the keys and parameter files are 2218 generated on each machine separately and the private key obscured. For 2219 the most demanding applications, the public key files for a community of 2220 users can be copied to all of those users, while one of the parameter 2221 files can be selected and copied to all users. However, if security 2222 considerations permit, the public key and parameter values, as well as 2223 the certificate file and leapseconds table file, can be obtained from 2224 other servers during operation. These data completely define the 2225 security community and the servers configured for each client. In 2226 broadcast client and symmetric passive modes the identity of a 2227 particular server may not be known in advance, so the protocol obtains 2228 and verifies the public key and host name directly from the server. 2229 Ultimately, these procedures may be automated using public certificates 2230 retrieved from secure directory services. 2232 Since all files carry a filestamp incorporated in the file name, newer 2233 file generations are detected in the data obtained from the one or more 2234 configured servers. When detected, the newer generations replace the 2235 older ones automatically and the newer ones made available to dependent 2236 clients as required. Since the filestamp signatures are refreshed once 2237 per day, which causes all associations to reset, the newer generations 2238 will eventually overtake all older ones throughout the subnet of servers 2239 and dependent clients. 2241 Where security considerations permit and the public key, certificate and 2242 agreement parameter files can be retrieved directly from the server, 2243 these data can be easily automated. Each server and client runs a shell 2244 script perhaps once per month. The script generates new key and 2245 parameter files, updates the links and then restarts the daemon. The 2246 daemon loads the necessary files and then restarts the protocol with 2247 each of its servers, refreshing public keys and parameter files during 2248 the process. Clients will not be able to authenticate following daemon 2249 restart, but the protocol design is such that they will eventually time 2250 out, restart the protocol and retrieve the latest data. 2252 Security Considerations 2254 Security issues are the main topic of this memorandum. 2256 References 2258 Note: Internet Engineering Task Force documents can be obtained at 2259 www.ietf.org. Other papers and reports can be obtained at 2260 www.eecis.udel.edu/~mills. Additional briefings in PowerPoint, 2261 PostScript and PDF are at that site in ./autokey.htm. 2263 1. Bradner, S. Key words for use in RFCs to indicate requirement levels. 2264 Request for Comments RFC-2119, BCP 14, Internet Engineering Task Force, 2265 March 1997. 2267 2. Karn, P., and W. Simpson. Photuris: session-key management protocol. 2268 Request for Comments RFC-2522, Internet Engineering Task Force, March 2269 1999. 2271 3. Kent, S., R. Atkinson. IP Authentication Header. Request for Comments 2272 RFC-2402, Internet Engineering Task Force, November 1998. 2274 4. Kent, S., and R. Atkinson. IP Encapsulating security payload (ESP). 2275 Request for Comments RFC-2406, Internet Engineering Task Force, November 2276 1998. 2278 5. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet 2279 security association and key management protocol (ISAKMP). Request for 2280 Comments RFC-2408, Internet Engineering Task Force, November 1998. 2282 6. Mills, D.L. Authentication scheme for distributed, ubiquitous, real- 2283 time protocols. Proc. Advanced Telecommunications/Information 2284 Distribution Research Program (ATIRP) Conference (College Park MD, 2285 January 1997), 293-298. 2287 7. Mills, D.L. Cryptographic authentication for real-time network 2288 protocols. In: AMS DIMACS Series in Discrete Mathematics and Theoretical 2289 Computer Science, Vol. 45 (1999), 135-144. 2291 8. Mills, D.L. Network Time Protocol (Version 3) specification, 2292 implementation and analysis. Network Working Group Report RFC-1305, 2293 University of Delaware, March 1992, 113 pp. 2295 9. Mills, D.L. Proposed authentication enhancements for the Network Time 2296 Protocol version 4. Electrical Engineering Report 96-10-3, University of 2297 Delaware, October 1996, 36 pp. 2299 10. Mills, D.L, and A. Thyagarajan. Network time protocol version 4 2300 proposed changes. Electrical Engineering Department Report 94-10-2, 2301 University of Delaware, October 1994, 32 pp. 2303 11. Mills, D.L. Public key cryptography for the Network Time Protocol. 2304 Electrical Engineering Report 00-5-1, University of Delaware, May 2000. 2305 23 pp. 2307 12. Orman, H. The OAKLEY key determination protocol. Request for 2308 Comments RFC-2412, Internet Engineering Task Force, November 1998. 2310 Author's Address 2312 David L. Mills 2313 Electrical and Computer Engineering Department 2314 University of Delaware 2315 Newark, DE 19716 2316 mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316 2317 web www.eecis.udel.edu/~mills 2318 Edited into Internet-draft form by: 2320 Patrick Cain. Please notify pcain@genuity.com of editorial omissions or 2321 errors. 2323 Full Copyright Statement 2325 "Copyright (C) The Internet Society (date). All Rights Reserved. This 2326 document and translations of it may be copied and furnished to others, 2327 and derivative works that comment on or otherwise explain it or assist 2328 in its implmentation may be prepared, copied, published and distributed, 2329 in whole or in part, without restriction of any kind, provided that the 2330 above copyright notice and this paragraph are included on all such 2331 copies and derivative works. However, this document itself may not be 2332 modified in any way, such as by removing the copyright notice or 2333 references to the Internet Society or other Internet organizations, 2334 except as needed for the purpose of developing Internet standards in 2335 which case the procedures for copyrights defined in the Internet 2336 Standards process must be followed, or as required to translate it into.