idnits 2.17.1 draft-ietf-stime-ntpauth-04.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The abstract seems to contain references ([RFC-2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (November 2002) is 7833 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-2026' is defined on line 1353, but no explicit reference was found in the text == Unused Reference: 'RFC-2412' is defined on line 1369, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Downref: Normative reference to an Experimental RFC: RFC 2522 ** Obsolete normative reference: RFC 2875 (Obsoleted by RFC 6955) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'MILLS00' -- Possible downref: Non-RFC (?) normative reference: ref. 'MILLS96' -- Possible downref: Non-RFC (?) normative reference: ref. 'STIMSON' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Time Working Group David L. Mills 3 Internet Draft University of Delaware 4 Document: draft-ietf-stime-ntpauth-04.txt November 2002 5 Expires: April 2003 7 Public Key Cryptography for the Network Time Protocol 8 Version 2 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC-2026]]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright (C), The Internet Society, 2002. All rights reserved. 32 Abstract 34 This document describes the Autokey security model for authenticating 35 servers to clients using the Network Time Protocol (NTP) and public 36 key cryptography. its design is based on the premiss that IPSEC 37 schemes cannot be adopted intact, since that would preclude stateless 38 servers and severely compromise timekeeping accuracy. In addition, 39 PKI schemes presume authenticated time values are always available to 40 enforce certificate lifetimes; however, cryptographically verified 41 timestamps require interaction between the timekeeping function and 42 authentication function in ways not yet considered by the IETF. 44 This Document includes the Autokey requirements analysis, design 45 principles and protocol specification. A detailed description of the 46 protocol states, events and transition functions is included. A 47 prototype of the Autokey design based on this document has been 48 implemented, tested and documented in the NTP Version 4 (NTPv4) 49 software distribution for Unix, Windows and VMS at 50 http://www.ntp.org. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [RFC-2119]. 58 Table of Contents 60 1. Introduction...................................................4 61 2. NTP Security Model.............................................5 62 3. Approach.......................................................8 63 4. Autokey Cryptography...........................................9 64 5. Autokey Operations............................................11 65 6. Public Key Signatures and Timestamps..........................14 66 7. Autokey Protocol Overview.....................................16 67 8. Autokey State Machine.........................................18 68 8.1 Status Word...............................................18 69 8.2 Host State Variables......................................20 70 8.3 Client State Variables (all modes)........................21 71 8.4 Server State Variables (broadcast and symmetric modes)....22 72 8.5 Autokey Messages..........................................23 73 9. Error Recovery................................................27 74 10. References...................................................29 75 Appendix A. Packet Formats.......................................31 76 A.1 Extension Field Format....................................32 77 A.2 Autokey Version 2 Messages................................34 78 Appendix B. Cryptographic Key and Certificate Management.........43 79 Appendix C. Autokey Error Checking...............................45 80 C.1 Packet Processing Rules...................................45 81 C.2 Timestamps, Filestamps and Partial Ordering...............47 82 Appendix D. Security Analysis....................................49 83 D.1 Protocol Vulnerability....................................49 84 D.2 Clogging Vulnerability....................................50 85 Appendix E. Identity Schemes.....................................53 86 E.1 Private Certificate (PC) Scheme...........................55 87 E.2 Trusted Certificate (TC) Scheme...........................55 88 E.3 Schnorr (IFF) Scheme......................................55 89 E.4 Guillard-Quisquater (GQ) Scheme...........................56 90 E.5 Interoperability Issues...................................57 91 Appendix F. File Examples........................................60 92 F.1 RSA-MD5cert File and ASN.1 Encoding.......................60 93 F.2 GQkey File and ASN.1 Encoding.............................61 94 F.3 GQpar File and ASN.1 Encoding.............................61 95 F.4 RSAkey File and ASN.1 Encoding............................61 96 F.5 IFFpar File and ASN.1 Encoding............................62 97 Appendix G. ASN.1 Encoding Rules.................................63 98 G.1 COOKIE request, IFF response, GQ response.................63 99 G.2 CERT response, SIGN request and response..................63 100 Security Considerations..........................................66 101 Author's Addresses...............................................66 103 1. Introduction 105 A distributed network service requires reliable, ubiquitous and 106 survivable provisions to prevent accidental or malicious attacks on 107 the servers and clients in the network or the values they exchange. 108 Reliability requires that clients can determine that received packets 109 are authentic; that is, were actually sent by the intended server and 110 not manufactured or modified by an intruder. Ubiquity requires that 111 any client can verify the authenticity of any server using only 112 public information. Survivability requires protection from faulty 113 implementations, improper operation and possibly malicious clogging 114 and replay attacks with or without data modification. These 115 requirements are especially stringent with widely distributed network 116 services, since damage due to failures can propagate quickly 117 throughout the network, devastating archives, routing databases and 118 monitoring systems and even bring down major portions of the network. 120 The Network Time Protocol (NTP) contains provisions to 121 cryptographically authenticate individual servers as described in the 122 most recent protocol NTP Version 3 (NTPv3) specification [RFC-1305]; 123 however, that specification does not provide a scheme for the 124 distribution of cryptographic keys, nor does it provide for the 125 retrieval of cryptographic media that reliably bind the server 126 identification credentials with the associated private keys and 127 related public values. However, conventional key agreement and 128 digital signatures with large client populations can cause 129 significant performance degradations, especially in time critical 130 applications such as NTP. In addition, there are problems unique to 131 NTP in the interaction between the authentication and synchronization 132 functions, since each requires the other. 134 This document describes a cryptographically sound and efficient 135 methodology for use in NTP and similar distributed protocols. As 136 demonstrated in the reports and briefings cited in the references at 137 the end of this document, there is a place for PKI and related 138 schemes, but none of these schemes alone satisfies the requirements 139 of the NTP security model. The various key agreement schemes [RFC- 140 2408], RFC-2412], [RFC-2522] proposed by the IETF require per- 141 association state variables, which contradicts the principles of the 142 remote procedure call (RPC) paradigm in which servers keep no state 143 for a possibly large client population. An evaluation of the PKI 144 model and algorithms as implemented in the RSAref2.0 package formerly 145 distributed by RSA Laboratories leads to the conclusion that any 146 scheme requiring every NTP packet to carry a PKI digital signature 147 would result in unacceptably poor timekeeping performance. 149 A revised security model and authentication scheme called Autokey was 150 proposed in earlier reports [MILLS96], [MILLS00]. It is based on a 151 combination of PKI and a pseudo-random sequence generated by repeated 152 hashes of a cryptographic value involving both public and private 153 components. This scheme has been tested and evaluated in a local 154 environment and in the CAIRN experiment network funded by DARPA. A 155 detailed description of the security model, design principles and 156 implementation experience is presented in this document. 158 Additional information about NTP, including executive summaries, 159 briefings and bibliography can be found on the NTP project page 160 linked from www.ntp.org. The NTPv4 reference implementation for Unix 161 and Windows, including sources and documentation in HTML, is 162 available from the NTP repository at the same site. All of the 163 features described in this document, including support for both IPv4 164 and IPv6 address families, are included in the current development 165 version at that repository. The reference implementation is not 166 intended to become part of any standard that may be evolved from this 167 document, but to serve as an example of how the procedures described 168 in this document can be implemented in a practical way. 170 2. NTP Security Model 172 NTP security requirements are even more stringent than most other 173 distributed services. First, the operation of the authentication 174 mechanism and the time synchronization mechanism are inextricably 175 intertwined. Reliable time synchronization requires cryptographic 176 keys which are valid only over designated time intervals; but, time 177 intervals can be enforced only when participating servers and clients 178 are reliably synchronized to UTC. Second, the NTP subnet is 179 hierarchical by nature, so time and trust flow from the primary 180 servers at the root through secondary servers to the clients at the 181 leaves. 183 A client can claim authentic to dependent applications only if all 184 servers on the path to the primary servers are bone-fide authentic. 185 In order to emphasize this requirement, in this document the notion 186 of "authentic" is replaced by "proventic", a noun new to English and 187 derived from provenance, as in the provenance of a painting. Having 188 abused the language this far, the suffixes fixable to the various 189 noun and verb derivatives of authentic will be adopted for proventic 190 as well. In NTP each server authenticates the next lower stratum 191 servers and proventicates (authenticates by induction) the lowest 192 stratum (primary) servers. Serious computer linguists would correctly 193 interpret the proventic relation as the transitive closure of the 194 authentic relation. 196 It is important to note that the notion of proventic does not 197 necessarily imply the time is correct. A NTP client mobilizes a 198 number of concurrent associations with different servers and uses a 199 crafted agreement algorithm to pluck truechimers from the population 200 possibly including falsetickers. A particular association is 201 proventic if the server certificate and identity have been verified 202 by the means described in this document. However, the statement "the 203 client is synchronized to proventic sources" means that the system 204 clock has been set using the time values of one or more proventic 205 client associations and according to the NTP mitigation algorithms. 206 While a certificate authority must satisfy this requirement when 207 signing a certificate request, the certificate itself can be stored 208 in public directories and retrieved over unsecured network paths. 210 Over the last several years the IETF has defined and evolved the 211 IPSEC infrastructure for privacy protection and source authentication 212 in the Internet, The infrastructure includes the Encapsulating 213 Security Payload (ESP) [RFC-2406] and Authentication Header (AH) 214 [RFC-2402] for IPv4 and IPv6. Cryptographic algorithms that use these 215 headers for various purposes include those developed for the PKI, 216 including MD5 message digests, RSA digital signatures and several 217 variations of Diffie-Hellman key agreements. The fundamental 218 assumption in the security model is that packets transmitted over the 219 Internet can be intercepted by other than the intended receiver, 220 remanufactured in various ways and replayed in whole or part. These 221 packets can cause the client to believe or produce incorrect 222 information, cause protocol operations to fail, interrupt network 223 service or consume precious network and processor resources. 225 In the case of NTP, the assumed goal of the intruder is to inject 226 false time values, disrupt the protocol or clog the network, servers 227 or clients with spurious packets that exhaust resources and deny 228 service to legitimate applications. The mission of the algorithms and 229 protocols described in this document is to detect and discard 230 spurious packets sent by other than the intended sender or sent by 231 the intended sender, but modified or replayed by an intruder. The 232 cryptographic means of the reference implementation are based on the 233 OpenSSL cryptographic software library available at www.openssl.org, 234 but other libraries with equivalent functionality could be used as 235 well. It is important for distribution and export purposes that the 236 way in which these algorithms are used precludes encryption of any 237 data other than incidental to the construction of digital signatures. 239 There are a number of defense mechanisms already built in the NTP 240 architecture, protocol and algorithms. The fundamental timestamp 241 exchange scheme is inherently resistant to spoof and replay attacks. 242 The engineered clock filter, selection and clustering algorithms are 243 designed to defend against evil cliques of Byzantine traitors. While 244 not necessarily designed to defeat determined intruders, these 245 algorithms and accompanying sanity checks have functioned well over 246 the years to deflect improperly operating but presumably friendly 247 scenarios. However, these mechanisms do not securely identify and 248 authenticate servers to clients. Without specific further protection, 249 an intruder can inject any or all of the following mischiefs. 251 The NTP security model assumes the following possible threats. 252 Further discussion is in [MILLS00] and in the briefings at the NTP 253 project page, but beyond the scope of this document. 255 1. An intruder can intercept and archive packets forever, as well as 256 all the public values ever generated and transmitted over the net. 258 2. An intruder can generate packets faster than the server, network 259 or client can process them, especially if they require expensive 260 cryptographic computations. 262 3. In a wiretap attack the intruder can intercept, modify and replay 263 a packet. However, it cannot permanently prevent onward transmission 264 of the original packet; that is, it cannot break the wire, only tell 265 lies and congest it. Except in unlikely cases considered in Appendix 266 D, the modified packet cannot arrive at the victim before the 267 original packet. 269 4. In a middleman or masquerade attack the intruder is positioned 270 between the server anc client, so it can intercept, modify and replay 271 a packet and prevent onward transmission of the original packet. 272 Except in unlikely cases considered in Appendix D, the middleman does 273 not have the server private keys or identity parameters. 275 The NTP security model assumes the following possible limitations. 276 Further discussion is in [MILLS00] and in the briefings at the NTP 277 project page, but beyond the scope of this document. 279 1. The running times for public key algorithms are relatively long 280 and highly variable. In general, the performance of the time 281 synchronization function is badly degraded if these algorithms must 282 be used for every NTP packet. 284 2. In some modes of operation it is not feasible for a server to 285 retain state variables for every client. It is however feasible to 286 regenerated them for a client upon arrival of a packet from that 287 client. 289 3. The lifetime of cryptographic values must be enforced, which 290 requires a reliable system clock. However, the sources that 291 synchronize the system clock must be cryptographically proventicated. 292 This circular interdependence of the timekeeping and proventication 293 functions requires special handling. 295 4. All proventication functions must involve only public values 296 transmitted over the net with the single exception of encrypted 297 signatures and cookies intended only to authenticate the source. 298 Private values must never be disclosed beyond the machine on which 299 they were created. 301 5. Public encryption keys and certificates must be retrievable 302 directly from servers without requiring secured channels; however, 303 the fundamental security of identification credentials and public 304 values bound to those credentials must be a function of certificate 305 authorities and/or webs of trust. 307 6. Error checking must be at the enhanced paranoid level, as network 308 terrorists may be able to craft errored packets that consume 309 excessive cycles with needless result. While this document includes 310 an informal vulnerability analysis and error protection paradigm, a 311 formal model based on communicating finite-state machine analysis 312 remains to be developed. 314 Unlike the Secure Shell security model, where the client must be 315 securely authenticated to the server, in NTP the server must be 316 securely authenticated to the client. In ssh each different interface 317 address can be bound to a different name, as returned by a reverse- 318 DNS query. In this design separate public/private key pairs may be 319 required for each interface address with a distinct name. A perceived 320 advantage of this design is that the security compartment can be 321 different for each interface. This allows a firewall, for instance, 322 to require some interfaces to proventicate the client and others not. 324 However, the NTP security model specifically assumes that access 325 control is performed by means external to the protocol and that all 326 time values and cryptographic values are public, so there is no need 327 to associate each interface with different cryptographic values. To 328 do so would create the possibility of a two-faced clock, which is 329 ordinarily considered a Byzantine hazard. In other words, there is 330 one set of private secrets for the host, not one for each interface. 331 In the NTP design the host name, as returned by the Unix 332 gethostname() library function, represents all interface addresses. 333 Since at least in some host configurations the host name may not be 334 identifiable in a DNS query, the name must be either configured in 335 advance or obtained directly from the server using the Autokey 336 protocol. 338 3. Approach 340 The Autokey protocol described in this document is designed to meet 341 the following objectives. Again, in-depth discussions on these 342 objectives is in the web briefings and will not be elaborated in this 343 document. Note that here and elsewhere in this document mention of 344 broadcast mode means multicast mode as well, with exceptions noted in 345 the NTP software documentation. 347 1. It must interoperate with the existing NTP architecture model and 348 protocol design. In particular, it must support the symmetric key 349 scheme described in [RFC-1305]. As a practical matter, the reference 350 implementation must use the same internal key management system, 351 including the use of 32-bit key IDs and existing mechanisms to store, 352 activate and revoke keys. 354 2. It must provide for the independent collection of cryptographic 355 values and time values. A NTP packet is accepted for processing only 356 when the required cryptographic values have been obtained and 357 verified and the NTP header has passed all sanity checks. 359 3. It must not significantly degrade the potential accuracy of the 360 NTP synchronization algorithms. In particular, it must not make 361 unreasonable demands on the network or host processor and memory 362 resources. 364 4. It must be resistant to cryptographic attacks, specifically those 365 identified in the security model above. In particular, it must be 366 tolerant of operational or implementation variances, such as packet 367 loss or misorder, or suboptimal configurations. 369 5. It must build on a widely available suite of cryptographic 370 algorithms, yet be independent of the particular choice. In 371 particular, it must not require data encryption other than incidental 372 to signature and cookie encryption operations. 374 6. It must function in all the modes supported by NTP, including 375 server, symmetric and broadcast modes. 377 7. It must not require intricate per-client or per-server 378 configuration other than the availability of the required 379 cryptographic keys and certificates. 381 8. The reference implementation must contain provisions to generate 382 cryptographic key files specific to each client and server. 384 4. Autokey Cryptography 386 Autokey public key cryptography is based on the PKI algorithms 387 commonly used in the Secure Shell and Secure Sockets Layer 388 applications. As in these applications Autokey uses keyed message 389 digests to detect packet modification, digital signatures to verify 390 the source and public key algorithms to encrypt cookies. What makes 391 Autokey cryptography unique is the way in which these algorithms are 392 used to deflect intruder attacks while maintaining the integrity and 393 accuracy of the time synchronization function. 395 The NTPv3 symmetric key cryptography uses keyed-MD5 message digests 396 with a 128-bit private key and 32-bit key ID. In order to retain 397 backward compatibility, the key ID space is partitioned in two 398 subspaces at a pivot point of 65536. Symmetric key IDs have values 399 less than the pivot and indefinite lifetime. Autokey key IDs have 400 pseudo-random values equal to or greater than the pivot and are 401 expunged immediately after use. 403 There are three Autokey protocol variants corresponding to each of 404 the three NTP modes: server, symmetric and broadcast. All three 405 variants make use of specially contrived session keys, called 406 autokeys, and a precomputed pseudo-random sequence of autokeys with 407 the key IDs saved in a key list. As in the original NTPv3 408 authentication scheme, the Autokey protocol operates separately for 409 each association, so there may be several autokey sequences operating 410 independently at the same time. 412 An autokey is computed from four fields in network byte order as 413 shown below: 415 +-----------+-----------+-----------+-----------+ 416 | Source IP | Dest IP | Key ID | Cookie | 417 +-----------+-----------+-----------+-----------+ 419 The four values are hashed by the MD5 message digest algorithm to 420 produce the 128-bit autokey value, which in the reference 421 implementation is stored along with the key ID in a cache used for 422 symmetric keys as well as autokeys. Keys are retrieved from the cache 423 by key ID using hash tables and a fast lookup algorithm. 425 For use with IPv4, the Source IP and Dest IP fields contain 32 bits; 426 for use with IPv6, these fields contain 128 bits. In either case the 427 Key ID and Cookie fields contain 32 bits. Thus, an IPv4 autokey has 428 four 32-bit words, while an IPv6 autokey has ten 32-bit words. The 429 source and destination IP addresses and key ID are public values 430 visible in the packet, while the cookie can be a public value or 431 shared private value, depending on the mode. 433 The NTP packet format has been augmented to include one or more 434 extension fields piggybacked between the original NTP header and the 435 message authenticator code (MAC) at the end of the packet. For 436 packets without extension fields, the cookie is a shared private 437 value conveyed in encrypted form. For packets with extension fields, 438 the cookie has a default public value of zero, since these packets 439 can be validated independently using digital signatures. 441 There are some scenarios where the use of endpoint IP addresses may 442 be difficult or impossible. These include configurations where 443 network address translation (NAT) devices are in use or when 444 addresses are changed during an association lifetime due to mobility 445 constraints. For Autokey, the only restriction is that the address 446 fields visible in the transmitted packet must be the same as those 447 used to construct the autokey sequence and key list and that these 448 fields be the same as those visible in the received packet. 450 Provisions are included in the reference implementation to handle 451 cases when these addresses change, as possible in mobile IP. For 452 scenarios where the endpoint IP addresses are not available, an 453 optional public identification value could be used instead of the 454 addresses. Examples include the Interplanetary Internet, where 455 bundles are identified by name rather than address. Specific 456 provisions are for further study. 458 The key list consists of a sequence of key IDs starting with a random 459 32-bit nonce (autokey seed) equal to or greater than the pivot as the 460 first key ID. The first autokey is computed as above using the given 461 cookie and the first 32 bits of the result in network byte order 462 become the next key ID. Operations continue in this way to generate 463 the entire list. It may happen that a newly generated key ID is less 464 than the pivot or collides with another one already generated 465 (birthday event). When this happens, which should occur only rarely, 466 the key list is terminated at that point. The lifetime of each key is 467 set to expire one poll interval after its scheduled use. In the 468 reference implementation, the list is terminated when the maximum key 469 lifetime is about one hour, so for poll intervals above one hour a 470 new key list containing only a single entry is regenerated for every 471 poll. 473 The index of the last key ID in the list is saved along with the next 474 key ID for that entry, collectively called the autokey values. The 475 autokey values are then signed. The list is used in reverse order, so 476 that the first autokey used is the last one generated. The Autokey 477 protocol includes a message to retrieve the autokey values and 478 signature, so that subsequent packets can be validated using one or 479 more hashes that eventually match the last key ID (valid) or exceed 480 the index (invalid). This is called the autokey test in the following 481 and is done for every packet, including those with and without 482 extension fields. In the reference implementation the most recent key 483 ID received is saved for comparison with the first 32 bits in network 484 byte order of the next following key value. This minimizes the number 485 of hash operations in case a packet is lost. 487 5. Autokey Operations 489 The Autokey protocol has three variations, called dances, 490 corresponding to the NTP server, symmetric and broadcast modes. The 491 server dance was suggested by Steve Kent over lunch some time ago, 492 but considerably modified since that meal. The server keeps no state 493 for each client, but uses a fast algorithm and a 32-bit random 494 private value (server seed) to regenerate the cookie upon arrival of 495 a client packet. The cookie is calculated as the first 32 bits of the 496 autokey computed from the client and server addresses, a key ID of 497 zero and the server seed as cookie. The cookie is used for the actual 498 autokey calculation by both the client and server and is thus 499 specific to each client separately. 501 In previous Autokey versions the cookie was transmitted in clear on 502 the assumption it was not useful to a wiretapper other than to launch 503 an ineffective replay attack. However, a middleman could intercept 504 the cookie and manufacture bogus messages acceptable to the client. 505 In order to reduce the risk of such an attack, the Autokey Version 2 506 server encrypts the cookie using a public key supplied by the client. 507 While requiring additional processor resources for the encryption, 508 this makes it effectively impossible to spoof a cookie or masquerade 509 as the server. 511 [Note in passing. In an attempt to avoid the use of overt encryption 512 operations, an experimental scheme used a Diffie-Hellman agreed key 513 as a stream cipher to encrypt the cookie. However, not only was the 514 protocol extremely awkward, but the processing time to execute the 515 agreement, encrypt the key and sign the result was horrifically 516 expensive - 15 seconds in a vintage Sun IPC. This scheme was quickly 517 dropped in favor of generic public key encryption.] 519 The server dance uses the cookie and each key ID on the key list in 520 turn to retrieve the autokey and generate the MAC in the NTP packet. 521 The server uses the same values to generate the message digest and 522 verifies it matches the MAC in the packet. It then generates the MAC 523 for the response using the same values, but with the client and 524 server addresses exchanged. The client generates the message digest 525 and verifies it matches the MAC in the packet. In order to deflect 526 old replays, the client verifies the key ID matches the last one 527 sent. In this mode the sequential structure of the key list is not 528 exploited, but doing it this way simplifies and regularizes the 529 implementation while making it nearly impossible for an intruder to 530 guess the next key ID. 532 In broadcast dance clients normally do not send packets to the 533 server, except when first starting up to verify credentials and 534 calibrate the propagation delay. At the same time the client runs the 535 broadcast dance to obtain the autokey values. The dance requires the 536 association ID of the particular server association, since there can 537 be more than one operating in the same server. For this purpose, the 538 server packet includes the association ID in every response message 539 sent and, when sending the first packet after generating a new key 540 list, it sends the autokey values as well. After obtaining and 541 verifying the autokey values, the client verifies further server 542 packets using the autokey sequence. 544 The symmetric dance is similar to the server dance and keeps only a 545 small amount of state between the arrival of a packet and departure 546 of the reply. The key list for each direction is generated separately 547 by each peer and used independently, but each is generated with the 548 same cookie. The cookie is conveyed in a way similar to the server 549 dance, except that the cookie is a random value. There exists a 550 possible race condition where each peer sends a cookie request 551 message before receiving the cookie response from the other peer. In 552 this case, each peer winds up with two values, one it generated and 553 one the other peer generated. The ambiguity is resolved simply by 554 computing the working cookie as the EXOR of the two values. 556 Autokey choreography includes one or more exchanges, each with a 557 specific purpose, that must be completed in order. The client obtains 558 the server host name, digest/signature scheme and identity shcme in 559 the parameter exchange. It recursively obtains and verifies 560 certificates on the trail leading to a trusted certificate in the 561 certificate exchange and verifies the server identity in the identity 562 exchange. In the values exchange the client obtains the cookie and 563 autokey values, depending on the particular dance. Finally, the 564 client presents its self-signed certificate to the server for 565 signature in the sign exchange. 567 The ultimate security of Autokey is based on digitally signed 568 certificates and a certificate infrastructure compatible with [RFC- 569 2510] and [RFC-3280]. The Autokey protocol builds the certificate 570 trail from the primary servers, which presumably have trusted self- 571 signed certificates, recursively by stratum. Each stratum n + 2 572 server obtains the certificate of a stratum n server, presumably 573 signed by a stratum n - 1 server, and then the stratum n + 1 server 574 presentes its own self-signed certificate for signature by the 575 stratum n server. As the NTP subnet forms from the primary servers at 576 the root outward to the leaves, each server accumulates non- 577 duplicative certificates for all associations and for all trails. In 578 typical NTP subnets, this results in a good deal of useful 579 redundancy, so far not explointed in the present implementation. 581 In order to prevent masquerade, it is necessary for the stratum n 582 server to prove identity to the stratum n + 1 server when signing its 583 certificate. In many applications a number of servers share a single 584 security compartment, so it is only necessary that each server 585 verifies identity to the group. Although no specific identity scheme 586 is specified in this document, Appendix E describes a number of them 587 based on cryptographic challenge-response algorithms. The reference 588 implementation includes all of them with provision to add more if 589 required. 591 Once the certificates and identity have been validated, subsequent 592 packets are validated by digital signatures or autokey sequences. 593 These packets are presumed to contain valid time values; however, 594 unless the system clock has already been set by some other proventic 595 means, it is not known whether these values actually represent a 596 truechime or falsetick source. As the protocol evolves, the NTP 597 associations continue to accumulate time values until a majority 598 clique is available to synchronize the system clock. At this point 599 the NTP intersection algorithm culls the falsetickers from the 600 population and the remaining truechimers are allowed to discipline 601 the clock. 603 The time values for truechimer sources form a proventic partial 604 ordering relative to the applicable signature timestamps. This raises 605 the interesting issue of how to mitigate between the timestamps of 606 different associations. It might happen, for instance, that the 607 timestamp of some Autokey message is ahead of the system clock by 608 some presumably small amount. For this reason, timestamp comparisons 609 between different associations and between associations and the 610 system clock are avoided, except in the NTP intersection and 611 clustering algorithms and when determining whether a certificate has 612 expired. 614 Once the Autokey values have been instantiated, the dances are 615 normally dormant. In all except the broadcast dance, packets are 616 normally sent without extension fields, unless the packet is the 617 first one sent after generating a new key list or unless the client 618 has requested the cookie or autokey values. If for some reason the 619 client clock is stepped, rather than slewed, all cryptographic and 620 time values for all associations are purged and the dances in all 621 associations restarted from scratch. This insures that stale values 622 never propagate beyond a clock step. At intervals of about one day 623 the reference implementation purges all associations, refreshes all 624 signatures, garbage collects expired certificates and refreshes the 625 server seed. 627 6. Public Key Signatures and Timestamps 629 While public key signatures provide strong protection against 630 misrepresentation of source, computing them is expensive. This 631 invites the opportunity for an intruder to clog the client or server 632 by replaying old messages or to originate bogus messages. A client 633 receiving such messages might be forced to verify what turns out to 634 be an invalid signature and consume significant processor resources. 636 In order to foil such attacks, every signed extension field carries a 637 timestamp in the form of the NTP seconds at the signature epoch. The 638 signature spans the entire extension field including the timestamp. 639 If the Autokey protocol has verified a proventic source and the NTP 640 algorithms have validated the time values, the system clock can be 641 synchronized and signatures will then carry a nonzero (valid) 642 timestamp. Otherwise the system clock is unsynchronized and 643 signatures carry a zero (invalid) timestamp. The protocol detects and 644 discards replayed extension fields with old or duplicate timestamps, 645 as well fabricated extension fields with bogus timestamps, before any 646 values are used or signatures verified. 648 There are three signature types currently defined: 650 1. Cookie signature/timestamp: Each association has a cookie for use 651 when generating a key list. The cookie value is determined along with 652 the cookie signature and timestamp upon arrival of a cookie request 653 message. The values are returned in a a cookie response message. 655 2. Autokey signature/timestamp: Each association has a key list for 656 generating the autokey sequence. The autokey values are determined 657 along with the autokey signature and timestamp when a new key list is 658 generated, which occurs about once per hour in the reference 659 implementation. The values are returned in a autokey response 660 message. 662 3. Public values signature/timestamp: All public key, certificate and 663 leapsecond table values are signed at the time of generation, which 664 occurs when the system clock is first synchronized to a proventic 665 source, when the values have changed and about once per day after 666 that, even if these values have not changed. During protocol 667 operations, each of these values and associated signatures and 668 timestamps are returned in the associated request or response 669 message. While there are in fact several public value signatures, 670 depending on the number of entries on the certificate list, the 671 values are all signed at the same time, so there is only one public 672 value timestamp. 674 The most recent timestamp received of each type is saved for 675 comparison. Once a valid signature with valid timestamp has been 676 received, messages with invalid timestamps or earlier valid 677 timestamps of the same type are discarded before the signature is 678 verified. For signed messages this deflects replays that otherwise 679 might consume significant processor resources; for other messages the 680 Autokey protocol deflects message modification or replay by a 681 wiretapper, but not necessarily by a middleman. In addition, the NTP 682 protocol itself is inherently resistant to replays and consumes only 683 minimal processor resources. 685 All cryptographic values used by the protocol are time sensitive and 686 are regularly refreshed. In particular, files containing 687 cryptographic basis values used by signature and encryption 688 algorithms are regenerated from time to time. It is the intent that 689 file regenerations occur without specific advance warning and without 690 requiring prior distribution of the file contents. While 691 cryptographic data files are not specifically signed, every file is 692 associated with a filestamp in the form of the NTP seconds at the 693 creation epoch. It is not the intent in this document to specify file 694 formats or names or encoding rules; however, whatever conventions are 695 used must support a NTP filestamp in one form or another. Additional 696 details specific to the reference implementation are in Appendix B. 698 Filestamps and timestamps can be compared in any combination and use 699 the same conventions. It is necessary to compare them from time to 700 time to determine which are earlier or later. Since these quantities 701 have a granularity only to the second, such comparisons are ambiguous 702 if the values are the same. Thus, the ambiguity must be resolved for 703 each comparison operation as described in Appendix C. 705 It is important that filestamps be proventic data; thus, they cannot 706 be produced unless the producer has been synchronized to a proventic 707 source. As such, the filestamps throughout the NTP subnet represent a 708 partial ordering of all creation epoches and serve as means to 709 expunge old data and insure new data are consistent. As the data are 710 forwarded from server to client, the filestamps are preserved, 711 including those for certificate and leapseconds files. Packets with 712 older filestamps are discarded before spending cycles to verify the 713 signature. 715 7. Autokey Protocol Overview 717 This section presents an overview of the three server, symmetric and 718 broadcast dances. Each dance is designed to be nonintrusive and to 719 require no additional packets other than for regular NTP operations. 720 The NTP and Autokey protocols operate independently and 721 simultaneously and use the same packets. When the preliminary dance 722 exchanges are complete, subsequent packets are validated by the 723 autokey sequence and thus considered proventic as well. Autokey 724 assumes clients poll servers at a relatively low rate, such as once 725 per minute. In particular, it is assumed that a request sent at one 726 poll opportunity will normally result in a response before the next 727 poll opportunity. 729 The Autokey protocol data unit is the extension field, one or more of 730 which can be piggybacked in the NTP packet. An extension field 731 contains either a request with optional data or a response with data. 732 To avoid deadlocks, any number of responses can be included in a 733 packet, but only one request. A response is generated for every 734 request, even if the requestor is not synchronized to a proventic 735 source, but contain meaningful data only if the responder is 736 synchronized to a proventic source. Some requests and most responses 737 carry timestamped signatures. The signature covers the entire 738 extension field, including the timestamp and filestamp, where 739 applicable. Only if the packet passes all extension field tests are 740 cycles spent to verify the signature. 742 All dances begin with the parameter exchange where the client obtains 743 the server host name and status word specifying the digest/signature 744 scheme it will use and the identity schemes it supports. The dance 745 continues with the certificate exchange where the client obtains and 746 verifies the certificates along the trail to a trusted, self-cigned 747 certifidate, usually, but not necessarily, provided by a primary 748 (stratum 1) server. Primary servers are by design proventic with 749 trusted, self-signed certificates. 751 However, the certificate trail is not sufficient protection against 752 middleman attacks unless an identity scheme such as described in 753 Appendix E or proof-of-posession scheme in [RFC-2875] is available. 754 While the protocol for a generic challenge/response scheme is defined 755 in this document, the choice of one or another required or optional 756 identification schemes is yet to be determined. If all certificate 757 signatures along the trail are verified and the server identity is 758 confirmed, the server is declared proventic. Once declared proventic, 759 the client verifies packets using digital signatures and/or the 760 autokey sequence. 762 Once synchronized to a proventic source, the client continues with 763 the sign exchange where the server acting as CA signs the client 764 certificate. The CA interprets the certificate as a X.509v3 765 certificate request, but verifies the signature if it is self-signed. 766 The CA extracts the subject, issuer, extension fields and public key, 767 then builds a new certificate with these data along with its own 768 serial number and begin and end times, then signs it using its own 769 public key. The client uses the signed certificate in its own role as 770 CA for dependent clients. 772 In the server dance the client presents its public key and requests 773 the server to generate and return a cookie encrypted with this key. 774 The server constructs the cookie as described above and encrypts it 775 using this key. The client decrypts the cookie for use in generating 776 the key list. A similar dance is used in symmetric mode, where one 777 peer acts as the client and the other the server. In case of 778 overlapping messages, each peer generates a cookie and the agreed 779 common value is computed as the EXOR of the two cookies. 781 The cookie is used to generate the key list and autokey values in all 782 dances. In the server dance there is no need to provide these values 783 to the server, so once the cookie has been obtained the client can 784 generate the key list and validate succeeding packets directly. In 785 other dances the client requests the autokey values from the server 786 or, in some modes, the server provides them as each new key list is 787 generated. Once these values have been received, the client validates 788 succeeding packets using the autokey sequence as described 789 previously. 791 A final exchange occurs when the server has the leapseconds table, as 792 indicated in the host status word. If so, the client requests the 793 table and compares the filestamp with its own leapseconds table 794 filestamp, if available. If the server table is newer than the client 795 table, the client replaces its table with the server table. The 796 client, acting as server, can now provide the most recent table to 797 any of its dependent clients. In symmetric mode, this results in both 798 peers having the newest table. 800 8. Autokey State Machine 802 This section describes the formal model of the Autokey state machine, 803 its state variables and the state transition functions. 805 8.1 Status Word 807 Each server and client operating also as a server implements a host 808 status word, while each client implements a server status word for 809 each server. Both words have the format and content shown below. The 810 low order 16 bits of the status words define the state of the Autokey 811 protocol, while the high order 16 bits specify the message 812 digest/signature encryption scheme. Bits 24-31 of the status word are 813 reserved for server use, while bits 16-23 are reserved for client 814 use. There are four additional bits implemented separately. 816 The host status word is included in the ASSOC request and response 817 messages. The client copies this word to the associatino status word 818 and then lights additional association bits as the dance proceeds. 819 Once lit, these bits never come dark unless a general reset occurs 820 and the protocol is restarted from the beginning. 822 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | | |L|S|A|C|P|I|V| | |L|E| 826 | Digest/Signature NID | |P|G|U|K|R|F|A| IDN | |P|N| 827 | | |T|N|T|Y|V|F|L| | |F|B| 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 The host status bits are defined as follows: 832 ENB - Lit if the server implements the Autokey protocol and is 833 prepared to dance. 835 LPF 836 Lit if the server has loaded a valid leapseconds file. This bit can 837 be either lit or dim. 839 IDN 840 These three bits select which identity scheme is in use. While 841 specific coding for various schemes is yet to be determined, the 842 schemes available in the reference implementation and described in 843 Appendix E include the following. 845 0x0 Trusted Certificate (TC) Scheme (default) 846 0x1 Private Certificate (PC) Scheme 847 0x2 Schnorr aka Identify-Friendly-or-Foe (IFF) Scheme 848 0x4 Guillard-Quisquater (GC) Scheme 850 The PC scheme is exclusive of any other scheme. Otherwise, either 851 none or the IFF scheme or the GC scheme or both can be selected. 853 The server status bits are defined as follows: 855 VAL 0x0100 856 Lit when the server certificate and public key are validated. 858 IFF 0x0200 859 Lit when the server identity credentials are confirmed by one of 860 several schemes described later. 862 PRV 0x0400 863 Lit when the server signature is verified using the public key and 864 identity credentials. Also called the proventic bit elsewhere in this 865 document. When lit, signed values in subsequent messages are presumed 866 proventic, but not necessarily time-synchronized. 868 CKY 0x0800 869 Lit when the cookie is received and validated. When lit, key lists 870 can be generated. 872 AUT 0x1000 873 Lit when the autokey values are received and validated. When lit, 874 clients can validate packets without extension fields according to 875 the autokey sequence. 877 SGN 0x2000 878 Lit when the host certificate is signed by the server. 880 LPT 0x4000 881 Lit when the leapseconds table is received and validated. 883 There are four additional status bits LST, LBK, DUP and SYN not 884 included in the status word. All except SYN are association 885 properties, while SYN is a host property. These bits may be lit or 886 dim as the protocol proceeds; all except LST are active whether or 887 not the protocol is running. LST is lit when the key list is 888 regenerated and signed and comes dim after the autokey values have 889 been transmitted. This is necessary to avoid livelock under some 890 conditions. SYN is lit when the client has synchronized to a 891 proventic source and never dim after that. There are two error bits: 892 LBK indicates the received packet does not match the last one sent 893 and DUP indicates a duplicate packet. These bits, which are described 894 in Appendix C, are lit if the corresponding error has occurred for 895 the current packet and dim otherwise. 897 8.2 Host State Variables 899 Host Name 900 The name of the host returned by the Unix gethostname() library 901 function. The name must agree with the subject name in the host 902 certificate. 904 Host Status Word 905 This word is initialized when the host first starts up. The format is 906 described above. 908 Host Key 909 The RSA public/private key used to encrypt/decrypt cookies. This is 910 also the default sign key. 912 Sign Key 913 The RSA or DSA public/private key used to encrypt/decrypt signatures 914 when the host key is not used for this purpose. 916 Sign Digest 917 The message digest algorithm used to compute the signature before 918 encryption. 920 IFF Parameters 921 The parameters used in the IFF identity scheme described in Appendix 922 E. 924 GQ Parameters 925 The parameters used in the GQ identity scheme described in Appendix 926 E. 928 GQ keys 929 The public/private key used in the GQ identity scheme described in 930 Appendix E. 932 Server Seed 933 The private value hashed with the IP addresses to construct the 934 cookie. 936 Certificate Information Structure (CIS) 937 A structure including certain information fields from an X.509v3 938 certificate, together with the certificate itself encoded in ASN.1 939 syntax and including X.509v3 extension fields. Each structure carries 940 the public value timestamp and the filestamp of the certificate file 941 where it was generated. Elsewhere in this document the CIS will not 942 be distinguished from the certificate unless noted otherwise. 944 Certificate List 945 CIS structures are stored on the certificate list in order of 946 arrival, with the most recently received CIS placed first on the 947 list. The list is initialized with the CIS for the host certificate, 948 which is read from the certificate file. Additional CIS entries are 949 pushed on the list as certificates are obtained from the servers 950 during the certificate exchange. CIS entries are discarded if 951 overtaken by newer ones or expire due to old age. 953 Host Certificate 954 The self-signed X.509v3 certificate for the host. The subject and 955 issuer fields consist of the host name, while the message 956 digest/signature encryption scheme consists of the sign key and 957 message digest defined above. Optional information used in the 958 identity schemes is carried in X.509v3 extension fields compatible 959 with [RFC-3280]. 961 Public Key Values 962 The public encryption key for the COOKIE request, which consists of 963 the public value of the host key. It carries the public values 964 timestamp and the filestamp of the host key file. 966 Leapseconds Table Values 967 The NIST leapseconds table from the NIST leapseconds file. It carries 968 the public values timestamp and the filestamp of the leapseconds 969 file. 971 8.3 Client State Variables (all modes) 973 Association ID 974 The association ID used in responses. It is assigned when the 975 association is mobilized. 977 Server Association ID 978 The server association ID used in requests. It is initialized from 979 the first nonzero association ID field in a response. 981 Server Subject Name 982 The server host name determined in the parameter exchange. 984 Server Issuer Name 985 The host name signing the certificate. It is extracted from the 986 current server certificate upon arrival and used to request the next 987 item on the certificate trail. 989 Server Status Word 990 The host status word of the server determined in the parameter 991 exchange. 993 Server Public Key 994 The public key used to decrypt signatures. It is extracted from the 995 first certificate received, which by design is the server host 996 certificate. 998 Server Message Digest 999 The digest/signature scheme determined in the parameter exchange. 1001 Identification Challenge 1002 A 512-bit nonce used in the identification exchange. 1004 Group Key 1005 A 512-bit secret group key used in the identification exchange. It 1006 identifies the cryptographic compartment shared by the server and 1007 client. 1009 Receive Cookie Values 1010 The cookie returned in a COOKIE response, together with its timestamp 1011 and filestamp. 1013 Receive Autokey Values 1014 The autokey values returned in an AUTO response, together with its 1015 timestamp and filestamp. 1017 Receive Leapsecond Values 1018 The leapsecond table returned by a LEAP response, together with its 1019 timestamp and filestamp. 1021 8.4 Server State Variables (broadcast and symmetric modes) 1023 Send Cookie Values 1024 The cookie encryption values, signature and timestamps. 1026 Send Autokey Values 1027 The autokey values, signature and timestamps. 1029 Key List 1030 A sequence of key IDs starting with the autokey seed and each 1031 pointing to the next. It is computed, timestamped and signed at the 1032 next poll opportunity when the key list becomes empty. 1034 Current Key Number 1035 The index of the entry on the Key List to be used at the next poll 1036 opportunity. 1038 8.5 Autokey Messages 1040 There are currently eight Autokey requests and eight corresponding 1041 responses. An abbreviated description of these messages is given 1042 below; the detailed formats are described in Appendix A. 1044 Association Message (ASSOC) 1045 This message is used in the parameter exchange. The client sends the 1046 request with its host name and status word. The server sends the 1047 response with its host name and status word. If the server response 1048 is acceptable, ENB is lit. When the PC identity scheme is in use, the 1049 ASSOC response lights VAL, IFF and SIG, since the IFF exchange is 1050 complete at this point. 1052 Certificate Message (CERT) 1053 In the certificate exchange the client sends the request with the 1054 server subject name and the server responds with the certificate with 1055 that subject name. In the TC identity scheme the client sends the 1056 request with the server issuer name and the server responds with the 1057 certificate with that subject name. In either case if the certificate 1058 is valid, the client lights VAL. 1060 Cookie Message (COOKIE) 1061 The client sends the request with its public key. The server responds 1062 with the cookie encrypted with this public key. If the cookie is 1063 valid, the client lights CKY. 1065 Autokey Message (AUTO) 1066 The client sends the request to retrieve the Autokey values. The 1067 server responds with these values. If the values are valid, the 1068 client lights AUT. 1070 Leapseconds Message (LEAP) 1071 The client sends the request with its leapseconds table, if 1072 available. The server responds with its own leapseconds table. Both 1073 the client and server agree to use the version with the latest 1074 filestamp. When the latest version is identified, the client lights 1075 LPT. 1077 Sign Message (SIGN) 1078 The client sends the request with its host certificate. The server 1079 extracts the subject, public key and optional extension fields, then 1080 returns a certificate signed using its own public key. If the 1081 certificate is valid when received by the client, it is linked in the 1082 certificate list and the client lights SGN. 1084 IFF Message (IFF) 1085 This exchange is used with the IFF identity scheme described in 1086 Appendix E. If the server identity is confirmed, the client lights 1087 IFF and PRV. 1089 GQ Message (GQ) 1090 This exchange is used with the GQ identity scheme described in 1091 Appendix E. If the server identity is confirmed, the client lights 1092 IFF and PRV. 1094 8.5 Protocol State Transitions 1096 The protocol state machine is very simple but robust. The state is 1097 determined by the server status bits defined above. The state 1098 transitions of the three dances are shown below. The capitalized 1099 truth values represent the server status bits. All server bits are 1100 initialized dark and light up upon the arrival of a specific response 1101 message, as detailed above. 1103 When the system clock is first set and about once per day after that, 1104 or when the system clock is stepped, the server seed is refreshed, 1105 signatures and timestamps updated and the protocol restarted in all 1106 associations. When the server seed is refreshed or a new certificate 1107 or leapsecond table is received, the public values timestamp is reset 1108 to the current time and all signatures are recomputed. 1110 8.5.1 Server Dance 1112 The server dance begins when the client sends an ASSOC request to the 1113 server. It ends when the first signature is verified and PRV is lit. 1114 Subsequent packets received without extension fields are validated by 1115 the autokey sequence. An optional LEAP exchange updates the 1116 leapseconds table. Note the order of the identity exchanges and that 1117 only the first one will be used if multiple schemes are available. 1118 Note also that the SIGN and LEAP requests are not issued until the 1119 client has synchronized to a proventic source. 1121 while (1) { 1122 wait_for_next_poll; 1123 make_NTP_header; 1124 if (response_ready) 1125 send_response; 1126 if (!ENB) /* parameters exchange */ 1127 ASSOC_request; 1128 else if (!VAL) /* certificate exchange */ 1129 CERT_request(Host_Name); 1130 else if (IDN & GQ && !IFF) /* GQ identity exchange */ 1131 GQ_challenge; 1132 else if (IDN & IFF && !IFF)/* IFF identity exchange */ 1133 IFF_challenge; 1134 else if (!IFF) /* TC identity exchange */ 1135 CERT_request(Issuer_Name); 1136 else if (!CKY) /* cookie exchange */ 1137 COOKIE_request; 1138 else if (SYN && !SIG) /* sign exchange */ 1139 SIGN_request(Host_Certificate); 1140 else if (SYN && LPF & !LPT)/* leapseconds exchange */ 1141 LEAP_request; 1142 } 1144 When the PC identity scheme is in use, the ASSOC response lights VAL, 1145 IFF and SIG, the COOKIE response lights CKY and AUT and the first 1146 valid signature lights PRV. 1148 8.5.2 Broadcast Dance 1150 THe only difference between the broadcast and server dances is the 1151 inclusion of an autokey values exchange following the cookie 1152 exchange. The broadcast dance begins when the client receives the 1153 first broadcast packet, which includes an ASSOC response with 1154 association ID. The broadcast client uses the association ID to 1155 initiate a server dance in order to calibrate the propagation delay. 1157 The dance ends when the first signature is verified and PRV is lit. 1158 Subsequent packets received without extension fields are validated by 1159 the autokey sequence. An optional LEAP exchange updates the 1160 leapseconds table. When the server generates a new key list, the 1161 server replaces the ASSOC response with an AUTO response in the first 1162 packet sent. 1164 while (1) { 1165 wait_for_next_poll; 1166 make_NTP_header; 1167 if (response_ready) 1168 send_response; 1169 if (!ENB) /* parameters exchange */ 1170 ASSOC_request; 1171 else if (!VAL) /* certificate exchange */ 1172 CERT_request(Host_Name); 1173 else if (IDN & GQ && !IFF) /* GQ identity exchange */ 1174 GQ_challenge; 1175 else if (IDN & IFF && !IFF)/* IFF identity exchange */ 1176 IFF_challenge; 1177 else if (!IFF) /* TC identity exchange */ 1178 CERT_request(Issuer_Name); 1179 else if (!CKY) /* cookie exchange */ 1180 COOKIE_request; 1181 else if (!AUT) /* autokey values exchange */ 1182 AUTO_request; 1183 else if (SYN && !SIG) /* sign exchange */ 1184 SIGN_request(Host_Certificate); 1185 else if (SYN && LPF & !LPT)/* leapseconds exchange */ 1186 LEAP_request; 1187 } 1189 When the PC identity scheme is in use, the ASSOC response lights VAL, 1190 IFF and SIG, the COOKIE response lights CKY and AUT and the first 1191 valid signature lights PRV. 1193 8.5.3 Symmetric Dance 1195 The symmetric dance is intricately choreographed. It begins when the 1196 active peer sends an ASSOC request to the passive peer. The passive 1197 peer mobilizes an association and both peers step the same dance from 1198 the beginning. Until the active peer is synchronized to a proventic 1199 source (which could be the passive peer) and can sign messages, the 1200 passive peer loops waiting for the timestamp in the ASSOC response to 1201 light up. Until then, the active peer dances the server steps, but 1202 skips the sign, cookie and leapseconds exchanges. 1204 while (1) { 1205 wait_for_next_poll; 1206 make_NTP_header; 1207 if (!ENB) /* parameters exchange */ 1208 ASSOC_request; 1209 else if (!VAL) /* certificate exchange */ 1210 CERT_request(Host_Name); 1211 else if (IDN & GQ && !IFF) /* GQ identity exchange */ 1212 GQ_challenge; 1213 else if (IDN & IFF && !IFF)/* IFF identity exchange */ 1214 IFF_challenge; 1215 else if (!IFF) /* TC identity exchange */ 1216 CERT_request(Issuer_Name); 1217 else if (SYN && !SIG) /* sign exchange */ 1218 SIGN_request(Host_Certificate); 1219 else if (SYN && !CKY) /* cookie exchange */ 1220 COOKIE_request; 1221 else if (!LST) /* autokey values response */ 1222 AUTO_response; 1223 else if (!AUT) /* autokey values exchange */ 1224 AUTO_request; 1226 else if (SYN && LPF & !LPT)/* leapseconds exchange */ 1227 LEAP_request; 1228 } 1230 When the PC identity scheme is in use, the ASSOC response lights VAL, 1231 IFF and SIG, the COOKIE response lights CKY and AUT and the first 1232 valid signature lights PRV. 1234 Once the active peer has synchronized to a proventic source, it 1235 includes timestamped signatures with its messages. The first thing it 1236 does after lighting timestamps is dance the sign exchange so that the 1237 passive peer can survive the default identity exchange, if necessary. 1238 This is pretty wierd, since the passive peer will find the active 1239 certificate signed by its own public key. 1241 The passive peer, which has been stalled waiting for the active 1242 timestamps to light up, now mates the dance. The initial value of the 1243 cookie is zero. If a COOKIE response has not been received by either 1244 peer, the next message sent is a COOKIE request. The recipient rolls 1245 a random cookie, lights CKY and returns the encrypted cookie. The 1246 recipient decrypts the cookie and lights CKY. It is not a protocol 1247 error if both peers happen to send a COOKIE request at the same time. 1248 In this case both peers will have two values, one generated by itself 1249 peer and the other received from the other peer. In such cases the 1250 working cookie is constructed as the EXOR of the two values. 1252 At the next packet transmission opportunity, either peer generates a 1253 new key list and lights LST; however, there may already be an AUTO 1254 request queued for transmission and the rules say no more than one 1255 request in a packet. When available, either peer sends an AUTO 1256 response and dims LST. The recipient initializes the autokey values, 1257 dims LST and lights AUT. Subsequent packets received without 1258 extension fields are validated by the autokey sequence. 1260 The above description assumes the active peer synchronizes to the 1261 passive peer, which itself is synchronized to some other source, such 1262 as a radio clock or another NTP server. In this case, the active peer 1263 is operating at a stratum level one greater than the passive peer and 1264 so the passive peer will not synchronize to it unless it loses its 1265 own sources and the active peer itself has another source. 1267 9. Error Recovery 1269 The Autokey protocol state machine includes provisions for various 1270 kinds of error conditions that can arise due to missing files, 1271 corrupted data, protocol violations and packet loss or misorder, not 1272 to mention hostile intrusion. This section describes how the protocol 1273 responds to reachability and timeout events which can occur due to 1274 such errors. Appendix C contains an extended discussion on error 1275 checking and timestamp validation. 1277 A persistent NTP association is mobilized by an entry in the 1278 configuration file, while an ephemeral association is mobilized upon 1279 the arrival of a broadcast, manycast or symmetric active packet. A 1280 general reset reinitializes all association variables to the initial 1281 state when first mobilized. In addition, if the association is 1282 ephemeral, the association is demobilized and all resources acquired 1283 are returned to the system. 1285 Every NTP association has two variables which maintain the liveness 1286 state of the protocol, the 8-bit reachability register defined in 1287 [RFC-1305] and the watchdog timer, which is new in NTPv4. At every 1288 poll interval the reachability register is shifted left, the low 1289 order bit is dimmed and the high order bit is lost. At the same time 1290 the watchdog counter is incremented by one. If an arriving packet 1291 passes all authentication and sanity checks, the rightmost bit of the 1292 reachability register is lit and the watchdog counter is set to zero. 1293 If any bit in the reachability register is lit, the server is 1294 reachable, otherwise it is unreachable. 1296 When the first poll is sent by an association, the reachability 1297 register and watchdog counter are zero. If the watchdog counter 1298 reaches 16 before the server becomes reachable, a general reset 1299 occurs. This resets the protocol and clears any acquired state before 1300 trying again. If the server was once reachable and then becomes 1301 unreachable, a general reset occurs. In addition, if the watchdog 1302 counter reaches 16 and the association is persistent, the poll 1303 interval is doubled. This reduces the network load for packets that 1304 are unlikely to elicit a response. 1306 At each state in the protocol the client expects a particular 1307 response from the server. A request is included in the NTP packet 1308 sent at each poll interval until a valid response is received or a 1309 general reset occurs, in which case the protocol restarts from the 1310 beginning. A general reset also occurs for an association when an 1311 unrecoverable protocol error occurs. A general reset occurs for all 1312 associations when the system clock is first synchronized or the clock 1313 is stepped or when the server seed is refreshed. 1315 There are special cases designed to quickly respond to broken 1316 associations, such as when a server restarts or refreshes keys. Since 1317 the client cookie is invalidated, the server rejects the next client 1318 request and returns a crypto-NAK packet. Since the crypto-NAK has no 1319 MAC, the problem for the client is to determine whether it is 1320 legitimate or the result of intruder mischief. In order to reduce the 1321 vulnerability in such cases, the crypto-NAK, as well as all 1322 responses, is believed only if the result of a previous packet sent 1323 by the client and not a replay, as confirmed by the LBK and DUP 1324 status bits described above. While this defense can be easily 1325 circumvented by a middleman, it does deflect other kinds of intruder 1326 warfare. 1328 There are a number of situations where some event happens that causes 1329 the remaining autokeys on the key list to become invalid. When one of 1330 these situations happens, the key list and associated autokeys in the 1331 key cache are purged. A new key list, signature and timestamp are 1332 generated when the next NTP message is sent, assuming there is one. 1333 Following is a list of these situations. 1335 1. When the cookie value changes for any reason. 1337 2. When a client switches from server mode to broadcast mode. There 1338 is no further need for the key list, since the client will not 1339 transmit again. 1341 3. When the poll interval is changed. In this case the calculated 1342 expiration times for the keys become invalid. 1344 4. If a problem is detected when an entry is fetched from the key 1345 list. This could happen if the key was marked non-trusted or timed 1346 out, either of which implies a software bug. 1348 10. References 1350 [RFC-1305] Mills, D.L., "Network Time Protocol (Version 3) 1351 Specification, Implementation and Analysis," RFC-1305, March 1992. 1353 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 1354 3", BCP 9, RFC 2026, October 1996. 1356 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1357 Requirement Levels", BCP 14, RFC 2119, March 1997. 1359 [RFC-2402] Kent, S., R. Atkinson, "IP Authentication Header," RFC- 1360 2402, November 1998. 1362 [RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security 1363 Payload (ESP)," RFC-2406, November 1998. 1365 [RFC-2408] Maughan, D., M. Schertler, M. Schneider, and J. Turner, 1366 "Internet Security Association and Key Management Protocol (ISAKMP)," 1367 RFC-2408, November 1998. 1369 [RFC-2412] Orman, H., "The OAKLEY Key Determination Protocol," RFC- 1370 2412, November 1998. 1372 [RFC-2510] Adams, C., S. Farrell, "Internet X.509 Public Key 1373 Infrastructure Certificate Management Protocols," RFC-2510, March 1374 1999. 1376 [RFC-2522] Karn, P., and W. Simpson, "Photuris: Session-key 1377 Management Protocol", RFC-2522, March 1999. 1379 [RFC-2875] Prafullchandra, H., and J. Schaad, "Diffie-Hellman Proof- 1380 of-Possession Algorithms," RFC-2875, July 2000, 23 pp. 1382 [RFC-3279] Bassham, L., W. Polk and R. Housley, "Algorithms and 1383 Identifiers for the Internet X.509 Public Key Infrastructure 1384 Certificate and Certificate Revocation Lists (CRL) Profile," RFC- 1385 3279, April 2002. 1387 [RFC-3280] Housley, R., et al., "Internet X.509 Public Key 1388 Infrastructure Certificate and Certificate Revocation List (CRL) 1389 Profile," RFC-3280, April 2002. 1391 [MILLS00] Mills, D.L. Public key cryptography for the Network Time 1392 Protocol. Electrical Engineering Report 00-5-1, University of 1393 Delaware, May 2000. 23 pp. 1395 [MILLS96] Mills, D.L. Proposed authentication enhancements for the 1396 Network Time Protocol version 4. Electrical Engineering Report 96-10- 1397 3, University of Delaware, October 1996, 36 pp. 1399 [STIMSON] Stimson, D.R. Cryptography - Theory and Practice. CRC 1400 Press, Boca Raton, FA, 1995, ISBN 0-8493-8521-0. 1402 Appendix A. Packet Formats 1404 The NTPv4 packet consists of a number of fields made up of 32-bit (4 1405 octet) words in network byte order. The packet consists of three 1406 components, the header, one or more optional extension fields and an 1407 optional message authenticator code (MAC), consisting of the Key ID 1408 and Message Digest fields. The header format is shown below, where 1409 the size of some multiple word fields is shown in words. 1411 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 |LI | VN |Mode | Stratum | Poll | Precision | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Root Delay | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Root Dispersion | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Reference ID | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | | 1423 | Reference Timestamp (2) | 1424 | | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | | 1427 | Originate Timestamp (2) | 1428 | | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | | 1431 | Receive Timestamp (2) | 1432 | | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | | 1435 | Transmit Timestamp (2) | 1436 | | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | | 1439 | | 1440 = Extension Field(s) = 1441 | | 1442 | | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Key ID | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | | 1447 | | 1448 | Message Digest (4) | 1449 | | 1450 | | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 The NTP header extends from the beginning of the packet to the end of 1454 the Transmit Timestamp field. The format and interpretation of the 1455 header fields are backwards compatible with the NTPv3 header fields 1456 as described in [RFC-1305]. 1458 A non-authenticated NTP packet includes only the NTP header, while an 1459 authenticated one contains in addition a MAC. The format and 1460 interpretation of the NTPv4 MAC is described in [RFC-1305] when using 1461 the Digital Encryption Standard (DES) algorithm operating in Cipher- 1462 Block Chaining (CBC) node. This algorithm and mode of operation is no 1463 longer supported in NTPv4. The preferred replacement in both NTPv3 1464 and NTPv4 is the Message Digest 5 (MD5) algorithm, which is included 1465 in the reference implementation. For MD5 the Message Digest field is 1466 4 words (8 octets), but the Key ID field remains 1 word (4 octets). 1468 A.1 Extension Field Format 1470 In NTPv4 one or more extension fields can be inserted after the NTP 1471 header and before the MAC, which is always present when an extension 1472 field is present. The extension fields can occur in any order; 1473 however, in some cases there is a preferred order which improves the 1474 protocol efficiency. While previous versions of the Autokey protocol 1475 used several different extension field formats, in version 2 of the 1476 protocol only a single extension field format is used. 1478 Each extension field contains a request or response message in the 1479 following format: 1481 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 |R|E| Version | Code | Length | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Association ID | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Timestamp | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Filestamp | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Value Length | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | | 1495 | | 1496 = Value = 1497 | | 1498 | | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Signature Length | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | | 1503 | | 1504 = Signature = 1505 | | 1506 | | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Padding | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 Each extension field except the last is zero-padded to a word (4 1512 octets) boundary, while the last is zero-padded to a doubleword (8 1513 octets) boundary. The Length field covers the entire extension field, 1514 including the Length and Padding fields. While the minimum field 1515 length is 8 octets, a maximum field length remains to be established. 1516 The reference implementation discards any packet with a field length 1517 more than 1024 octets. 1519 The presence of the MAC and extension fields in the packet is 1520 determined from the length of the remaining area after the header to 1521 the end of the packet. The parser initializes a pointer just after 1522 the header. If the length is not a multiple of 4, a format error has 1523 occurred and the packet is discarded. The following cases are 1524 possible based on the remaining length in words. 1526 0 The packet is not authenticated. 1527 4 The packet is an error report or crypto-NAK resulting from a 1528 previous packet that failed the message digest check. The 4 octets 1529 are presently unused and should be set to 0. 1530 2, 3, 4 The packet is discarded with a format error. 1531 5 The remainder of the packet is the MAC. 1532 >5 One or more extension fields are present. 1534 If an extension field is present, the parser examines the Length 1535 field. If the length is less than 4 or not a multiple of 4, a format 1536 error has occurred and the packet is discarded; otherwise, the parser 1537 increments the pointer by this value. The parser now uses the same 1538 rules as above to determine whether a MAC is present and/or another 1539 extension field. An additional implementation-dependent test is 1540 necessary to ensure the pointer does not stray outside the buffer 1541 space occupied by the packet. 1543 In the Autokey Version 2 format, the Code field specifies the request 1544 or response operation, while the Version field is 2 for the current 1545 protocol version. There are two flag bits defined. Bit 0 is the 1546 response flag (R) and bit 1 is the error flag (E); the other six bits 1547 are presently unused and should be set to 0. The remaining fields 1548 will be described later. 1550 In the most common protocol operations, a client sends a request to a 1551 server with an operation code specified in the Code field and lights 1552 the R bit. Ordinarily, the client dims the E bit as well, but may in 1553 future light it for some purpose. The Association ID field is set to 1554 the value previously received from the server or 0 otherwise. The 1555 server returns a response with the same operation code in the Code 1556 field and the R bit lit. The server can also light E bit in case of 1557 error. The Association ID field is set to the association ID sending 1558 the response as a handle for subsequent exchanges. If for some reason 1559 the association ID value in a request does not match the association 1560 ID of any mobilized association, the server returns the request with 1561 both the R and E bits lit. Note that it is not a protocol error to 1562 send an unsolicited response with no matching request. 1564 In some cases not all fields may be present. For requests, until a 1565 client has synchronized to a proventic source, signatures are not 1566 valid. In such cases the Timestamp and Signature Length fields are 0 1567 and the Signature field is empty. Responses are generated only when 1568 the responder has synchronized to a proventic source; otherwise, an 1569 error response message is sent. Some request and error response 1570 messages carry no value or signature fields, so in these messages 1571 only the first two words are present. 1573 The Timestamp and Filestamp words carry the seconds field of an NTP 1574 timestamp. The Timestamp field establishes the signature epoch of the 1575 data field in the message, while the filestamp establishes the 1576 generation epoch of the file that ultimately produced the data that 1577 is signed. Since a signature and timestamp are valid only when the 1578 signing host is synchronized to a proventic source and a 1579 cryptographic data file can only be generated if a signature is 1580 possible, the response filestamp is always nonzero, except in the 1581 Association response message, where it contains the server status 1582 word. 1584 A.2 Autokey Version 2 Messages 1586 Following is a list of the messages used by the protocol. 1588 A.2.1 Association Message (ASSOC) 1590 The Association message is used to obtain the host name and related 1591 values. The request and response are unsigned and have the following 1592 format: 1594 1 2 3 1595 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 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 |1|E| 1 | 1 | Length | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | 0 | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Public Values Timestamp | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Host Status Word | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | Host Name Length | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | | 1609 | | 1610 = Host Name = 1611 | | 1612 | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 The Host Name field contains the unterminated string returned by the 1616 Unix gethostname() library function. While minimum and maximum host 1617 name lengths remain to be established, the reference implementation 1618 uses the values 4 and 256, respectively. The remaining fields are 1619 defined previously in this document. 1621 A.2.2. Certificate Message (CERT) 1623 The Certificate message is used to obtain a certificate and related 1624 values by subject name. The unsigned request has the following 1625 format: 1627 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 |0|0| 2 | 2 | 8 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Association ID | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | Current Time | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Public Values Timestamp | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Subject Name Length | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | | 1641 | | 1642 = Subject Name = 1643 | | 1644 | | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 For the purposes of interoperability with older Autokey versions, if 1647 only the first two words are sent, the request is for the host 1648 certificate. The response has the following format: 1650 1 2 3 1651 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 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 |1|E| 2 | 2 | Length | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Association ID | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Public Values Timestamp | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Certificate Filestamp | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Certificate Length | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | | 1664 | | 1665 = Certificate = 1666 | | 1667 | | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Certificate Signature Length | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | | 1672 | | 1673 = Certificate Signature = 1674 | | 1675 | | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 The certificate is encoded in X.509 format with ASN.1 syntax as 1679 described in Appendix G. The remaining fields are defined previously 1680 in this document. 1682 A.2.3 Cookie Message (COOKIE) 1684 The Cookie message is used in server and symmetric modes to obtain 1685 the server cookie. The request has the following format: 1687 1 2 3 1688 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 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 |0|0| 3 | 3 | Length | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Association ID | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Public Values Timestamp | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Host Key Filestamp | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Public Key Length | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | | 1701 | | 1702 = Public Key = 1703 | | 1704 | | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Public Key Signature Length | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | | 1709 | | 1710 = Public Key Signature = 1711 | | 1712 | | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 The Public Key field contains the host public key encoded with ASN.1 1716 syntax as described in Appendix G. The remaining fields are defined 1717 previously in this document. 1719 The response message has the following format: 1721 1 2 3 1722 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 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 |1|E| 3 | 3 | Length | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Association ID | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Cookie Timestamp | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Public Key Timestamp | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Encrypted Cookie Length | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | | 1735 | | 1736 = Encrypted Cookie = 1737 | | 1738 | | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Cookie Signature Length | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | | 1743 | | 1744 = Cookie Signature = 1745 | | 1746 | | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 The Encrypted Cookie field contains the raw cookie value encrypted by 1750 the public key in the request. The Cookie Signature and Timestamp are 1751 determined when the response is sent. The Public Key Timestamp is 1752 copied from the request. The remaining fields are defined previously 1753 in this document. 1755 A.2.4 Autokey Message (AUTO) 1757 The Autokey message is used to obtain the autokey values. The request 1758 message has the following format: 1760 1 2 3 1761 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 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 |0|0| 2 | 4 | 8 | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Association ID | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 The response message has the following format: 1770 1 2 3 1771 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 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 |1|E| 4 | 4 | Length | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Association ID | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Autokey Timestamp | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Public Values Timestamp | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | 8 | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | Key ID | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 | Key Number | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | Autokey Signature Length | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | | 1790 | | 1791 = Autokey Signature = 1792 | | 1793 | | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 The Autokey Signature and Timestamp are determined when the key list 1797 is generated. The remaining fields are defined previously in this 1798 document. 1800 A.2.5 Leapseconds Table Message (LEAP) 1802 The Leapseconds Table message is used to exchange leapseconds tables. 1803 The request and response messages have the following format, except 1804 that the R bit is dim in the request and lit in the response: 1806 1 2 3 1807 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 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 |R|E| 2 | 5 | Length | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Association ID | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | Public Values Timestamp | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Leapseconds Filestamp | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Leapseconds Table Length | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | | 1820 | | 1821 = Leapseconds Table = 1822 | | 1823 | | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Leapseconds Signature Length | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | | 1828 | | 1829 = Leapseconds Signature = 1830 | | 1831 | | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 The Leapseconds Table field contains the leapseconds table as parsed 1835 from the leapseconds file from NIST. If the client already has a copy 1836 of the leapseconds data, it uses the one with the latest filestamp 1837 and discards the other. The remaining fields are defined previously 1838 in this document. 1840 A.2.6 Sign Message (SIGN) 1841 The Sign message requests the server to sign and return a certificate 1842 presented in the request. The request and response messages have the 1843 following format, except that the R bit is dim in the request and lit 1844 in the response: 1846 1 2 3 1847 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 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 |R|E| 2 | 6 | Length | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Association ID | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Public Values Timestamp | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Certificate Filestamp | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Certificate Length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | | 1860 | | 1861 = Certificate = 1862 | | 1863 | | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Certificate Signature Length | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | | 1868 | | 1869 = Certificate Signature = 1870 | | 1871 | | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 The certificate is in X.509 format encoded in ASN.1 syntax as 1875 described in Appendix G. The remaining fields are defined previously 1876 in this document. 1878 A.2.7 Identity Messages (IFF, GQ) 1880 The Identity request asks the server to perform a mathematical 1881 operation on the challenge and return the results in the response. 1882 The request message has the following format, where 7 is the IFF 1883 scheme and 8 is the GQ shseme: 1885 1 2 3 1886 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 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 |0|E| 2 | 7/8 | Length | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Association ID | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Challenge Timestamp | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Public Values Timestamp | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Challenge Length | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | | 1899 | | 1900 = Challenge (512 bits) = 1901 | | 1902 | | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Challenge Signature Length | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | | 1907 | | 1908 = Challenge Signature = 1909 | | 1910 | | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 The Challenge is a raw 512-bit nonce. The remaining fields are 1914 defined previously in this document. 1916 The Identity response contains the result of the mathematical 1917 operation and is in two parts, the results and a message digest. The 1918 response message has the following format, where 7 is the IFF scheme 1919 and 8 is for the GQ shseme: 1921 1 2 3 1922 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 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 |1|E| 2 | 7/8 | Length | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Association ID | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | Response Timestamp | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Public Values Timestamp | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Response Length | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | | 1935 | | 1936 = Response = 1937 | | 1938 | | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Resonse Signature Length | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 | | 1943 | | 1944 = Response Signature = 1945 | | 1946 | | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 The Response is encoded in ASN.1 syntax as described in Appendix G. 1950 The Response Signature and Timestamp are determined when the response 1951 is sent. The Parameters Filestamp is copied from the request. 1953 Appendix B. Cryptographic Key and Certificate Management 1955 This appendix describes how cryptographic keys and certificates are 1956 generated and managed in the NTPv4 reference implementation. These 1957 means are not intended to become part of any standard that may be 1958 evolved from this document, but to serve as an example of how these 1959 functions can be implemented and managed in a typical operational 1960 environment. 1962 The ntp-keygen utility program in the NTP software library generates 1963 public/private key files, certificate files, identity parameter files 1964 and public/private identity key files. By default the modulus of all 1965 encryption and identity keys is 512 bits. All random cryptographic 1966 data are based on a pseudo-random number generator seeded in such a 1967 way that random values are exceedingly unlikely to repeat. The files 1968 are PEM encoded in printable ASCII format suitable for mailing as 1969 MIME objects. 1971 Every file has a filestamp, which is a string of decimal digits 1972 representing the NTP seconds the file was created. The file name is 1973 formed from the concatenation of the host name, filestamp and 1974 constant strings, so files can be copied from one environment to 1975 another while preserving the original filestamp. The file header 1976 includes the file name and date and generation time in printable 1977 ASCII. The utility assumes the host is synchronized to a proventic 1978 source at the time of generation, so that filestamps are proventic 1979 data. This raises an interesting circularity issue that will not be 1980 further explored here. 1982 The generated files are typically stored in NFS mounted file systems, 1983 with files containing private keys obscured to all but root. Symbolic 1984 links are installed from default file names assumed by the NTP daemon 1985 to the selected files. Since the files of successive generations and 1986 different hosts have unique names, there is no possibility of name 1987 collisions. 1989 Public/private keys must be generated by the host to which they 1990 belong. OpenSSL public/private RSA and DSA keys are generated as an 1991 OpenSSL structure, which is then PEM encoded in ASN.1 syntax and 1992 written to the host key file. The host key must be RSA, since it is 1993 used to encrypt the cookie, as well as encrypt signatures by default. 1994 In principle, these files could be generated directly by OpenSSL 1995 utility programs, as long as the symbolic links are consistent. The 1996 optional sign key can be RSA or DSA, since it is used only to encrypt 1997 signatures. 1999 Identity parameters must be generated by the ntp-keygen utility, 2000 since they have proprietary formats. Since these are private to the 2001 group, they are generated by one machine acting as a trusted 2002 authority and then distributed to all other members of the group by 2003 secure means. Public/private identity keys are generated by the host 2004 to which they belong along with certificates with the public identity 2005 key. 2007 Certificates are usually, but not necessarily, generated by the host 2008 to which they belong. The ntp-keygen utility generates self-signed 2009 X.509v3 host certificate files with optional extension fields. 2010 Certificate requests are not used, since the certificate itself is 2011 used as a request to be signed. OpenSSL X.509v3 certificates are 2012 generated as an OpenSSL structure, which is then PEM encoded in ASN.1 2013 syntax and written to the host certificate file. The string returned 2014 by the Unix gethostname() routine is used for both the subject and 2015 issuer fields. The serial number and begin time fields are derived 2016 from the filestamp; the end time is one year hence. The host 2017 certificate is signed by the sign key or host key by default. 2019 An important design goal is to make cryptographic data refreshment as 2020 simple and intuitive as possible, so it can be driven by scripts on a 2021 periodic basis. When the ntp-keygen utility is run for the first 2022 time, it creates by default a RSA host key file and RSA-MD5 host 2023 certificate file and necessary symbolic links. After that, it creates 2024 a new certificate file and symbolic link using the existing host key. 2025 The program run with given options creates identity parameter files 2026 for one or both the IFF or GQ identity schemes. The parameter files 2027 must then be securely copied to all other group members and symbolic 2028 links installed from the default names to the installed files. In the 2029 GQ scheme the next and each subsequent time the ntp-keygen utility 2030 runs, it automatically creates or updates the private/public identity 2031 key file and certificate file using the existing identity parameters. 2033 Appendix C. Autokey Error Checking 2035 Exhaustive examination of possible vulnerabilities at the various 2036 processing steps of the NTPv3 protocol as specified in [RFC-1305] 2037 have resulted in a revised list of packet sanity tests. There are 12 2038 tests in the NTPv4 reference implementation, called TEST1 through 2039 TEST12, which are performed in a specific order designed to gain 2040 maximum diagnostic information while protecting against an accidental 2041 or malicious clogging attacks. These tests are described in detail in 2042 the NTP software documentation. Those relevant to the Autokey 2043 protocol are described in this appendix. 2045 The sanity tests are classified in four tiers. The first tier 2046 deflects access control and message digest violations. The second, 2047 represented by the autokey sequence, deflects spoofed or replayed 2048 packets. The third, represented by timestamped digital signatures, 2049 binds cryptographic values to verifiable credentials. The fourth 2050 deflects packets with invalid NTP header fields or out of bounds time 2051 values. However, the tests in this last group do not directly affect 2052 cryptographic protocol vulnerability, so are beyond the scope of 2053 discussion here. 2055 C.1 Packet Processing Rules 2057 Every arriving NTP packet is checked enthusiastically for format, 2058 content and protocol errors. Some packet header fields are checked by 2059 the main NTP code path both before and after the Autokey protocol 2060 engine cranks. These include the NTP version number, overall packet 2061 length and extension field lengths. Extension fields may be no longer 2062 than 1024 octets in the reference implementation. Packets failing any 2063 of these checks are discarded immediately. Packets denied by the 2064 access control mechanism will be discarded later, but processing 2065 continues temporarily in order to gather further information useful 2066 for error recovery and reporting. 2068 Next, the cookie and session key are determined and the MAC computed 2069 as described above. If the MAC fails to match the value included in 2070 the packet, the action depends on the mode and the type of packet. 2071 Packets failing the MAC check will be discarded later, but processing 2072 continues temporarily in order to gather further information useful 2073 for error recovery and reporting. 2075 The NTP transmit and receive timestamps are in effect nonces, since 2076 an intruder cannot effectively guess either value in advance. To 2077 minimize the possibility that an intruder can guess the nonces, the 2078 low order unused bits in all timestamps are obscured with random 2079 values. If the transmit timestamp matches the transmit timestamp in 2080 the last packet received, the packet is a duplicate, so the DUP bit 2081 is lit. If the packet mode is not broadcast and the last transmit 2082 timestamp does not match the originate timestamp in the packet, 2083 either it was delivered out of order or an intruder has injected a 2084 rogue packet, so the LBK bit is lit. Packets with either the DUP or 2085 LBK bit lie be discarded later, but processing continues temporarily 2086 in order to gather further information useful for error recovery and 2087 reporting. 2089 Further indicators of the server and client state are apparent from 2090 the transmit and receive timestamps of both the packet and the 2091 association. The quite intricate rules take into account these and 2092 the above error indicators They are designed to discriminate between 2093 legitimate cases where the server or client are in inconsistent 2094 states and recoverable, and when an intruder is trying to destabilize 2095 the protocol or force consumption of needless resources. The exact 2096 behavior is beyond the scope of discussion, but is clearly described 2097 in the source code documentation. 2099 Next, the Autokey protocol engine is cranked and the dances evolve as 2100 described above. Some requests and all responses have value fields 2101 which carry timestamps and filestamps. When the server or client is 2102 synchronized to a proventic source, most requests and responses with 2103 value fields carry signatures with valid timestamps. When not 2104 synchronized to a proventic source, value fields carry an invalid 2105 (zero) timestamp and the signature field and signature length word 2106 are omitted. 2108 The extension field parser checks that the Autokey version number, 2109 operation code and field length are valid. If the error bit is lit in 2110 a request, the request is discarded without response; if an error is 2111 discovered in processing the request, or if the responder is not 2112 synchronized to a proventic source, the response contains only the 2113 first two words of the request with the response and error bits lit. 2114 For messages with signatures, the parser requires that timestamps and 2115 filestampes are valid and not a replay, that the signature length 2116 matches the certificate public key length and only then verifies the 2117 signature. Errors are reported via the security logging facility. 2119 All certificates must have correct ASN.1 encoding, supported 2120 digest/signature scheme and valid subject, issuer, public key and, 2121 for self-signed certificates, valid signature. While the begin and 2122 end times can be checked relative to the filestamp and each other, 2123 whether the certificate is valid relative to the actual time cannot 2124 be determined until the client is synchronized to a proventic source 2125 and the certificate is signed and verified by the server. 2127 When the protocol starts the only response accepted is ASSOC with 2128 valid timestamp, after which the server status word must be nonzero. 2129 ASSOC responses are discarded if this word is nonzero. The only 2130 responses accepted after that and until the PRV bit is lit are CERT, 2131 IFF and GQ. Once identity is confirmed and IFF is lit, these 2132 responses are no longer accepted, but all other responses are 2133 accepted only if in response to a previously sent request and only in 2134 the order prescribed in the protocol dances. Additional checks are 2135 implemented for each request type and dance step. 2137 C.2 Timestamps, Filestamps and Partial Ordering 2139 When the host starts, it reads the host key and certificate files, 2140 which are required for continued operation. It also reads the sign 2141 key and leapseconds files, when available. When reading these files 2142 the host checks the file formats and filestamps for validity; for 2143 instance, all filestamps must be later than the time the UTC 2144 timescale was established in 1972 and the certificate filestamp must 2145 not be earlier than its associated sign key filestamp. In general, at 2146 the time the files are read, the host is not synchronized, so it 2147 cannot determine whether the filestamps are bogus other than these 2148 simple checks. 2150 In the following the relation A->B is Lamport's "happens before" 2151 relation, which is true if event A happens before event B. When 2152 timestamps are compared to timestamps, the relation is false if A == 2153 B; that is, false if the events are simultaneous. For timestamps 2154 compared to filestamps and filestamps compared to filestamps, the 2155 relation is true if A == B. Note that the current time plays no part 2156 in these assertions except in (6) below; however, the NTP protocol 2157 itself insures a correct partial ordering for all current time 2158 values. 2160 The following assertions apply to all relevant responses: 2162 1. The client saves the most recent timestamp T0 and filestamp F0 for 2163 the respective signature type. For every received message carrying 2164 timestamp T1 and filestamp F1, the message is discarded unless T0->T1 2165 and F0->F1. The requirement that T0->T1 is the primary defense 2166 against replays of old messages. 2168 2. For timestamp T and filestamp F, F->T; that is, the timestamp must 2169 not be earlier than the filestamp. This could be due to a file 2170 generation error or a significant error in the system clock time. 2172 3. For sign key filestamp S, certificate filestamp C, cookie 2173 timestamp D and autokey timestamp A, S->C->D->A; that is, the autokey 2174 must be generated after the cookie, the cookie after the certificate 2175 and the certificate after the sign key. 2177 4. For sign key filestamp S and certificate filestamp C specifying 2178 begin time B and end time E, S->C->B->E; that is, the valid period 2179 must not be retroactive. 2181 5. A certificate for subject S signed by issuer I and with filestamp 2182 C1 obsoletes, but does not necessarily invalidate, another 2183 certificate with the same subject and issuer but with filestamp C0, 2184 where C0->C1. 2186 6. A certificate with begin time B and end time E is invalid and can 2187 not be used to sign certificates if t->B or E->t, where t is the 2188 current time. Note that the public key previously extracted from the 2189 certificate continues to be valid for an indefinite time. This raises 2190 the interesting possibilities where a truechimer server with expired 2191 certificate or a falseticker with valid certificate are not detected 2192 until the client has synchronized to a clique of proventic 2193 truechimers. 2195 Appendix D. Security Analysis 2197 This section discusses the most obvious security vulnerabilities in 2198 the various Autokey dances. First, some observations on the 2199 particular engineering parameters of the Autokey protocol are in 2200 order. The number of bits in some cryptographic values are 2201 considerably smaller than would ordinarily be expected for strong 2202 cryptography. One of the reasons for this is the need for 2203 compatibility with previous NTP versions; another is the need for 2204 small and constant latencies and minimal processing requirements. 2205 Therefore, what the scheme gives up on the strength of these values 2206 must be regained by agility in the rate of change of the 2207 cryptographic basis values. Thus, autokeys are used only once and 2208 seed values are regenerated frequently. However, in most cases even a 2209 successful cryptanalysis of these values compromises only a 2210 particular association and does not represent a danger to the general 2211 population. 2213 Throughout the following discussion the cryptographic algorithms and 2214 private values themselves are assumed secure; that is, a brute force 2215 cryptanalytic attack will not reveal the host private key, sign 2216 private key, cookie value, identity parameters, server seed or 2217 autokey seed. In addition, an intruder will not be able to predict 2218 random generator values or predict the next autokey. On the other 2219 hand, the intruder can remember the totality of all past values for 2220 all packets ever sent. 2222 D.1 Protocol Vulnerability 2224 While the protocol has not been subjected to a formal analysis, a few 2225 preliminary assertions can be made. The protocol cannot loop forever 2226 in any state, since the watchdog counter and general reset insure 2227 that the association variables will eventually be purged and the 2228 protocol restarted from the beginning. However, if something is 2229 seriously wrong, the timeout/restart cycle could continue 2230 indefinitely until whatever is wrong is fixed. This is not a clogging 2231 hazard, as the timeout period is very long compared to expected 2232 network delays. 2234 The LBK and DUP bits described in the main body and Appendix C are 2235 effective whether or not cryptographic means are in use. The DUP bit 2236 deflects duplicate packets in any mode, while the LBK bit deflects 2237 bogus packets in all except broadcast mode. All packets must have the 2238 correct MAC, as verified with correct key ID and cookie. In all modes 2239 the next key ID cannot be predicted by a wiretapper, so are of no use 2240 for cryptanalysis. 2242 As long as the client has validated the server certificate trail, a 2243 wiretapper cannot produce a convincing signature and cannot produce 2244 cryptographic values acceptable to the client. As long as the 2245 identity values are not compromised, a middleman cannot masquerade as 2246 a legitimate group member and produce convincing certificates or 2247 signatures. In server and symmetric modes after the preliminary 2248 exchanges have concluded, extension fields are no longer used, a 2249 client validates the packet using the autokey sequence. A wiretapper 2250 cannot predict the next Key IDs, so cannot produce a valid MAC. A 2251 middleman cannot successfully modify and replay a message, since he 2252 does not know the cookie and without the cookie cannot produce a 2253 valid MAC. 2255 In broadcast mode a wiretapper cannot produce a key list with signed 2256 autokey values that a client will accept. The most it can do is 2257 replay an old packet causing clients to repeat the autokey hash 2258 operations until exceeding the maximum key number. However, a 2259 middleman could intercept an otherwise valid broadcast packet and 2260 produce a bogus packet with acceptable MAC, since in this case it 2261 knows the key ID before the clients do. Of course, the middleman key 2262 list would eventually be used up and clients would discover the ruse 2263 when verifying the signature of the autokey values. There does not 2264 seem to be a suitable defense against this attack. 2266 During the exchanges where extension fields are in use, the cookie is 2267 a public value rather than a shared secret and an intruder can easily 2268 construct a packet with a valid MAC, but not a valid signature. In 2269 the certificate and identity exchanges an intruder can generate fake 2270 request messages which may evade server detection; however, the LBK 2271 and DUP bits minimize the client exposure to the resulting rogue 2272 responses. A wiretapper might be able to intercept a request, 2273 manufacture a fake response and loft it swiftly to the client before 2274 the real server response. A middleman could do this without even 2275 being swift. However, once the identity exchange has completed and 2276 the PRV bit lit, these attacks are readily deflected. 2278 A client instantiates cryptographic variables only if the server is 2279 synchronized to a proventic source. A server does not sign values or 2280 generate cryptographic data files unless synchronized to a proventic 2281 source. This raises an interesting issue: how does a client generate 2282 proventic cryptographic files before it has ever been synchronized to 2283 a proventic source? [Who shaves the barber if the barber shaves 2284 everybody in town who does not shave himself?] In principle, this 2285 paradox is resolved by assuming the primary (stratum 1) servers are 2286 proventicated by external phenomological means. 2288 D.2 Clogging Vulnerability 2290 There are two clogging vulnerabilities exposed in the protocol 2291 design: a encryption attack where the intruder hopes to clog the 2292 victim server with needless cookie or signature encryptions or 2293 identity calculations, and a decryption attack where the intruder 2294 attempts to clog the victim client with needless cookie or 2295 verification decryptions. Autokey uses public key cryptography and 2296 the algorithms that perform these functions consume significant 2297 processor resources. 2299 In order to reduce exposure to decryption attacks the LBK and DUP 2300 bits deflect bogus and replayed packets before invoking any 2301 cryptographic operations. In order to reduce exposure to encryption 2302 attacks, signatures are computed only when the data have changed. For 2303 instance, the autokey values are signed only when the key list is 2304 regenerated, which happens about once an hour, while the public 2305 values are signed only when one of them changes or the server seed is 2306 refreshed, which happens about once per day. 2308 In some Autokey dances the protocol precludes server state variables 2309 on behalf of an individual client, so a request message must be 2310 processed and the response message sent without delay. The identity, 2311 cookie and sign exchanges are particularly vulnerable to a clogging 2312 attack, since these exchanges can involve expensive cryptographic 2313 algorithms as well as digital signatures. A determined intruder could 2314 replay identity, cookie or sign requests at high rate, which may very 2315 well be a useful munition for an encryption attack. Ordinarily, these 2316 requests are seldom used, except when the protocol is restarted or 2317 the server seed or public values are refreshed. 2319 Once synchronized to a proventic source, a legitimate extension field 2320 with timestamp the same as or earlier than the most recent received 2321 of that type is immediately discarded. This foils a middleman cut- 2322 and-paste attack using an earlier AUTO response, for example. A 2323 legitimate extension field with timestamp in the future is unlikely, 2324 as that would require predicting the autokey sequence. In either case 2325 the extension field is discarded before expensive signature 2326 computations. This defense is most useful in symmetric mode, but a 2327 useful redundancy in other modes. 2329 The client is vulnerable to a certificate clogging attack until 2330 declared proventic, after which CERT responses are discarded. Before 2331 that, a determined intruder could flood the client with bogus 2332 certificate responses and force spurious signature verifications, 2333 which of course would fail. The intruder could flood the server with 2334 bogus certificate requests and cause similar mischief. Once declared 2335 proventic, further certificate responses are discard, so these 2336 attacks would fail. The intruder could flood the server with replayed 2337 sign requests and cause the server to verify the request and sign the 2338 response, although the client would drop the response due invalid 2339 timestamp. 2341 An interesting adventure is when an intruder replays a recent packet 2342 with an intentional bit error. A stateless server will return a 2343 crypto-NAK message which the client will notice and discard, since 2344 the LBK bit is lit. However, a legitimate crypto-NAK is sent if the 2345 server has just refreshed the server seed. In this case the LBK bit 2346 is dim and the client performs a general reset and restarts the 2347 protocol as expected. Another adventure is to replay broadcast mode 2348 packets at high rate. These will be rejected by the clients by the 2349 timestamp check and before consuming signature cycles. 2351 In broadcast and symmetric modes the client must include the 2352 association ID in the AUTO request. Since association ID values for 2353 different invocations of the NTP daemon are randomized over the 16- 2354 bit space, it is unlikely that a bogus request would match a valid 2355 association with different IP addresses, for example, and cause 2356 confusion. 2358 Appendix E. Identity Schemes 2360 The Internet infrastructure model described in [RFC-2510] is based on 2361 certificate trails where a subject proves identity to a certificate 2362 authority (CA) who then signs the subject certificate using the CA 2363 issuer key. The CA in turn proves identity to the next CA and obtains 2364 its own signed certificate. The trail continues to a CA with a self- 2365 signed trusted root certificate independently validated by other 2366 means. If it is possible to prove identity at each step, each 2367 certificate along the trail can be considered trusted relative to the 2368 identity scheme and trusted root certificate. 2370 The import issue with respect to NTP and ad hoc sensor networks is 2371 the cryptographic strength of the identity scheme, since if a 2372 middleman could compromise it, the trail would have a security 2373 breach. In electric mail and commerce the identity scheme can be 2374 based on handwritten signatures, photographs, fingerprints and other 2375 things very hard to counterfeit. As applied to NTP subnets and 2376 identity proofs, the scheme must allow a client to securely verify 2377 that a server knows the same secret that it does, presuming the 2378 secret was previously instantiated by secure means, but without 2379 revealing the secret to members outside the group. 2381 The Autokey Version 2 reference implementation supports four identity 2382 schemes of varying cryptographic strengths: one using private 2383 certificates (PC), a second using trusted certificates (TC), a third 2384 using a modified Schnorr (IFF aka Identify Friend or Foe) algorithm, 2385 and the fourth using a modified Guillou-Quisquater (GQ) algorithm. 2386 The available schemes are selected during the key generation phase, 2387 with the particular scheme selected during the parameter exchange. 2389 The IFF and GQ schemes involve a cryptographically strong challenge- 2390 response exchange. These schemes begin when the client sends a nonce 2391 to the server, which then rolls its own nonce, performs a 2392 mathematical operation and sends the results along with a message 2393 digest to the client. The client performs a second mathematical 2394 operation to produce a digest that must match the one included in the 2395 message. Still another scheme based on a modified Diffie-Hellman 2396 agreement algorithm described in [RFC-2875], was considered, but the 2397 computation resources required are considerably more than the IFF and 2398 GQ schemes. 2400 Certificate extension fields are used to convey information used by 2401 the identity schemes, such as whether the certificate is private, 2402 trusted or contains a public identity key. While the semantics of 2403 these fields generally conforms with conventional usage, there are 2404 subtle variations. The fields used by Autokey Version 2 include: 2406 Basic Constraints 2407 This field defines the basic functions of the certificate. It 2408 contains the string "critical,CA:TRUE", which means the field must be 2409 interpreted and the associated private key can be used to sign other 2410 certificates. While included for compatibility, Autokey makes no use 2411 of this field. 2413 Key Usage 2414 This field defines the intended use of the public key contained in 2415 the certificate. It contains the string 2416 "digitalSignature,keyCertSign", which means the contained public key 2417 can be used to verify signatures on data and other certificates. 2418 While included for compatibility, Autokey makes no use of this field. 2420 Extended Key Usage 2421 This field further refines the intended use of the public key 2422 contained in the certificate and is present only in self-signed 2423 certificates. It contains the string "Private" if the certificate is 2424 designated private or the string "trustRoot" if it is designated 2425 trusted. A private certificate is always trusted. 2427 Subject Key Identifier: 2428 This field contains the public identity key used in the GQ identity 2429 scheme. It is present only if the GQ scheme is configured. 2431 Certificates are used to construct certificate information structures 2432 (CIS) which are stored on the certificate list. A flags field in the 2433 CIS determines the status of the certificate. The field is encoded as 2434 follows: 2436 Sign 0x01 2437 The certificate signature has been verified. If the certificate is 2438 self-signed and verified using the contained public key, this bit 2439 will be lit when the CIS is constructed. 2441 Trust 0x02 2442 The certificate has been signed by a trusted issuer. If the 2443 certificate is self-signed and contains "trustRoot" in the Extended 2444 Key Usage field, this bit will be lit when the CIS is constructed. 2446 Private 0x04 2447 The certificate is private and not to be revealed. If the certificate 2448 is self-signed and contains "Private" in the Extended Key Usage 2449 field, this bit will be lit when the CIS is constructed. 2451 Error 0x80 2452 The certificate is defective and not to be used in any way. 2454 These flags can also be set by the identity schemes described below. 2456 E.1 Private Certificate (PC) Scheme 2458 The PC scheme uses a private certificate as group key. A certificate 2459 is designated private for the purpose of the this scheme if the CIS 2460 Private bit is lit. The certificate is distributed to all other group 2461 members by secret means and never revealed outside the group. There 2462 is no identity exchange, since the certificate itself is the group 2463 key. Therefore, when the parameter exchange completes the VAL, IFF 2464 and SGN bits are lit in the server status word. When the following 2465 cookie exchange is complete, the PRV bit is lit and operation 2466 continues as described in the main body of this document. 2468 E.2 Trusted Certificate (TC) Scheme 2470 The TC identification exchange follows the parameter exchange in 2471 which the VAL bit is lit. It involves a conventional certificate 2472 trail and a sequence of certificates, each signed by an issuer one 2473 stratum level lower than the client, and terminating at a trusted 2474 certificate, as described in [RFC-2510]. A certificate is designated 2475 trusted for the purpose of the TC scheme if the CIS Trust bit is lit 2476 and the certificate is self-signed. Such would normally be the case 2477 when the trail ends at a primary (stratum 1) server, but the trail 2478 can end at a secondary server if the security model permits this. 2480 When a certificate is obtained from a server, or when a certificate 2481 is signed by a server, A CIS for the new certificate is pushed on the 2482 certificate list, but only if the certificate filestamp is greater 2483 than any with the same subject name and issuer name already on the 2484 list. The list is then scanned looking for signature opportunities. 2485 If a CIS issuer name matches the subject name of another CIS and the 2486 issuer certificate is verified using the public key of the subject 2487 certificate, the Sign bit is lit in the issuer CIS. Furthermore, if 2488 the Trust bit is lit in the subject CIS, the Trust bit is lit in the 2489 issuer CIS. 2491 The client continues to follow the certificate trail to a self-signed 2492 certificate, lighting the Sign and Trust bits as it proceeds. If it 2493 finds a self-signed certificate with Trust bit lit, the client lights 2494 the IFF and PRV bits and the exchange completes. It can, however, 2495 happen that the client finds a self-signed certificate with Trust bit 2496 dark. This can happen when a server is just coming up, has 2497 synchronized to a proventic source, but has not yet completed the 2498 sign exchange. This is considered a temporary condition, so the 2499 client simply retries at poll opportunities until the server 2500 certificate is signed. 2502 E.3 Schnorr (IFF) Scheme 2503 The Schnorr (IFF) identity scheme is useful when certificates are 2504 generated by means other than the NTP software library, such as a 2505 trusted public authority. In this case a X.509v3 extension field 2506 might not be available to convey the identity public key. The scheme 2507 involves a set of parameters which persist for the life of the 2508 scheme. New generations of these parameters must be securely 2509 transmitted to all members of the group before use. The scheme is 2510 self contained and independent of new generations of host keys, sign 2511 keys and certificates. 2513 The IFF identity scheme is based on DSA cryptography and algorithms 2514 adapted from Stimson p. 285 [STIMSON]. The IFF parameters are 2515 generated by OpenSSL routines normally used to generate DSA 2516 parameters. By happy coincidence, the mathematical principles on 2517 which IFF is based are similar to DSA, but only the prime p, 2518 generator g and prime q are used in identity calculations. The p is a 2519 512-bit prime and q a 160-bit prime that divides p - 1 and is a qth 2520 root of 1 mod p; that is, g^q = 1 mod p. The trusted authority rolls 2521 random group key a, computes public identity key v = g^(q - a) and 2522 shares (p, g, q, a, v) with the group members. These values are never 2523 revealed, although only a need be truly secret. 2525 Alice challenges Bob to confirm identity using the following 2526 exchange. Alice rolls new random challenge r and sends to Bob in the 2527 IFF request message. Bob rolls new random k, then computes y = k + a 2528 r mod q and x = g^k mod p and sends (y, hash(x)) to Alice in the IFF 2529 response message. Besides making the response shorter, the hash makes 2530 it effectively impossible for an intruder to solve for k and the 2531 unpredictable nonces make it effectively impossible to solve for a by 2532 monitoring multiple request and response message. 2534 Alice receives the response and computes g^y v^r mod p. After a bit 2535 of modular algebra, this simplifies to g^k. If hash(g^k) matches x, 2536 Alice knows that Bob has the group key a. The signed response binds 2537 this knowledge to Bob's private key and the public key previously 2538 received in his certificate. On success the IFF and PRV bits are lit 2539 in the server status word. 2541 E.4 Guillard-Quisquater (GQ) Scheme 2543 The Guillou-Quisquater (GQ) identity scheme is useful when 2544 certificates are generated using the NTP software library. These 2545 routines convey the GQ public key in a X.509v3 extension field. The 2546 scheme involves a set of parameters which persist for the life of the 2547 scheme and a private/public identity key, which is refreshed each 2548 time a new certificate is generated. The scheme is self contained and 2549 independent of new generations of host keys and sign keys and 2550 certificates. 2552 The GQ identity scheme is based on RSA cryptography and algorithms 2553 adapted from Stimson p. 300 [STIMSON] (with errors corrected). The GQ 2554 parameters are generated by OpenSSL routines normally used to 2555 generate RSA keys. By happy coincidence, the mathematical principles 2556 on which GQ is based are similar to RSA, but only the modulus n is 2557 used in identity calculations. The 512-bit public modulus is n = p q, 2558 where p and q are secret large primes, but not used in identity 2559 calculations. The trusted authority rolls random group key b and 2560 shares (n, b) with the group members. These values are never 2561 revealed, although only b need be truly secret. 2563 When generating a new certificate, group members roll a random nonce 2564 u and compute its inverse v = (u^-1)^b obscured by the group key b. 2565 Thus, each has a private identity key u and a public identity key v, 2566 but not necessarily the same ones. The public key is conveyed on the 2567 certificate in an extension field; the private key is never revealed. 2569 Alice challenges Bob to confirm identity using the following 2570 exchange. Alice rolls new random challenge r and sends to Bob in the 2571 GQ request message. Bob rolls new random k, then computes y = k u^r 2572 mod n and x = k^b mod n and sends (y, hash(x)) to Alice in the GQ 2573 response message. Besides making the response shorter, the hash makes 2574 it effectively impossible for an intruder to solve for b by observing 2575 a number of these messages. 2577 Alice receives the response and computes y^b v^r mod n. After a bit 2578 of modular algebra, this simplifies to k^b. If hash(k^b) matches x, 2579 Alice knows that Bob has the group key b. The signed response binds 2580 this knowledge to Bob's private key and the public key previously 2581 received in his certificate. Further evidence is the certificate 2582 containing the public identity key, since this is also signed with 2583 Bob's private key. On success the IFF and PRV bits are lit in the 2584 server status word. 2586 E.5 Interoperability Issues 2588 A specific combination of authentication scheme (none, symmetric key, 2589 Autokey), digest/signature scheme and identity scheme (PC, TC, GQ, 2590 IFF) is called a cryptotype, although not all combinations are 2591 possible. There may be management configurations where the servers 2592 and clients may not all support the same cryptotypes. A secure NTPv4 2593 subnet can be configured in several ways while keeping in mind the 2594 principles explained in this section. Note however that some 2595 cryptotype combinations may successfully interoperate with each 2596 other, but may not represent good security practice. 2598 The cryptotype of an association is determined at the time of 2599 mobilization, either at configuration time or some time later when a 2600 packet of appropriate cryptotype arrives. When a client, broadcast or 2601 symmetric active association is mobilized at configuration time, it 2602 can be designated non-authentic, authenticated with symmetric key or 2603 authenticated with some Autokey scheme, and subsequently it will send 2604 packets with that cryptotype. When a responding server, broadcast 2605 client or symmetric passive association is mobilized, it is 2606 designated with the same cryptotype as the received packet. 2608 When multiple identity schemes are supported, the parameter exchange 2609 determines which one is used. The request message contains bits 2610 corresponding to the schemes it supports, while the response message 2611 contains bits corresponding to the schemes it supports. The client 2612 matches the server bits with its own and selects a compatible 2613 identity scheme. The server is driven entirely by the client 2614 selection and remains stateless. When multiple selections are 2615 possible, the order from most secure to least is GC, IFF, TC. Note 2616 that PC does not interoperate with any of the others, since they 2617 require the host certificate which a PC server will not reveal. 2619 Following the principle that time is a public value, a server 2620 responds to any client packet that matches its cryptotype 2621 capabilities. Thus, a server receiving a non-authenticated packet 2622 will respond with a non-authenticated packet, while the same server 2623 receiving a packet of a cryptotype it supports will respond with 2624 packets of that cryptotype. However, new broadcast or manycast client 2625 associations or symmetric passive associations will not be mobilized 2626 unless the server supports a cryptotype compatible with the first 2627 packet received. By default, non-authenticated associations will not 2628 be mobilized unless overridden in a decidedly dangerous way. 2630 Some examples may help to reduce confusion. Client Alice has no 2631 specific cryptotype selected. Server Bob supports both symmetric key 2632 and Autokey cryptography. Alice's non-authenticated packets arrive at 2633 Bob, who replies with non-authenticated packets. Cathy has a copy of 2634 Bob's symmetric key file and has selected key ID 4 in packets to Bob. 2635 If Bob verifies the packet with key ID 4, he sends Cathy a reply with 2636 that key. If authentication fails, Bob sends Cathy a thing called a 2637 crypto-NAK, which tells her something broke. She can see the evidence 2638 using the utility programs of the NTP software library. 2640 Symmetric peers Bob and Denise have rolled their own host keys, 2641 certificates and identity parameters and lit the host status bits for 2642 the identity schemes they can support. Upon completion of the 2643 parameter exchange, both parties know the digest/signature scheme and 2644 available identity schemes of the other party. They do not have to 2645 use the same schemes, but each party must use the digest/signature 2646 scheme and one of the identity schemes supported by the other party. 2648 It should be clear from the above that Bob can support all the girls 2649 at the same time, as long as he has compatible authentication and 2650 identification credentials. Now, Bob can act just like the girls in 2651 his own choice of servers; he can run multiple configured 2652 associations with multiple different servers (or the same server, 2653 although that might not be useful). But, wise security policy might 2654 preclude some cryptotype combinations; for instance, running an 2655 identity scheme with one server and no authentication with another 2656 might not be wise. 2658 Appendix F. File Examples 2660 This appendix shows the file formats used by the OpenSSL library and 2661 the reference implementation. These are not included in the 2662 specification and are given here only as examples. In each case the 2663 actual file contents are shown followed by a dump produced by the 2664 OpenSSL asn1 program. 2666 F.1 RSA-MD5cert File and ASN.1 Encoding 2668 # ntpkey_RSA-MD5cert_whimsy.udel.edu.3236983143 2669 # Tue Jul 30 01:59:03 2002 2670 -----BEGIN CERTIFICATE----- 2671 MIIBkTCCATugAwIBAgIEwPBxZzANBgkqhkiG9w0BAQQFADAaMRgwFgYDVQQDEw93 2672 aGltc3kudWRlbC5lZHUwHhcNMDIwNzMwMDE1OTA3WhcNMDMwNzMwMDE1OTA3WjAa 2673 MRgwFgYDVQQDEw93aGltc3kudWRlbC5lZHUwWjANBgkqhkiG9w0BAQEFAANJADBG 2674 AkEA2PpOz6toSQ3BtdGrBt+F6cSSde6zhayOwRj5nAkOvtQ505hdxWhudfKe7ZOY 2675 HRLLqACvVJEfBaSvE5OFWldUqQIBA6NrMGkwDwYDVR0TAQH/BAUwAwEB/zALBgNV 2676 HQ8EBAMCAoQwSQYDVR0OBEIEQEVFGZar3afoZcHDmhbgiOmaBrtWTlLHRwIJswge 2677 LuqB1fbsNEgUqFebBR1Y9qLwYQUm7ylBD+3z9PlhcUOwtnIwDQYJKoZIhvcNAQEE 2678 BQADQQAVZMiNbYV2BjvFH9x+t0PB9//giOV3fQoLK8hXXpyiAF4KLleEqP13pK0H 2679 TceF3e3bxSRTndkIhklEAcbYXm66 2680 -----END CERTIFICATE----- 2682 0:d=0 hl=4 l= 401 cons: SEQUENCE 2683 4:d=1 hl=4 l= 315 cons: SEQUENCE 2684 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 2685 10:d=3 hl=2 l= 1 prim: INTEGER :02 2686 13:d=2 hl=2 l= 4 prim: INTEGER :-3F0F8E99 2687 19:d=2 hl=2 l= 13 cons: SEQUENCE 2688 21:d=3 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 2689 32:d=3 hl=2 l= 0 prim: NULL 2690 34:d=2 hl=2 l= 26 cons: SEQUENCE 2691 36:d=3 hl=2 l= 24 cons: SET 2692 38:d=4 hl=2 l= 22 cons: SEQUENCE 2693 40:d=5 hl=2 l= 3 prim: OBJECT:commonName 2694 45:d=5 hl=2 l= 15 prim: PRINTABLESTRING :whimsy.udel.edu 2695 62:d=2 hl=2 l= 30 cons: SEQUENCE 2696 64:d=3 hl=2 l= 13 prim: UTCTIME :020730015907Z 2697 79:d=3 hl=2 l= 13 prim: UTCTIME :030730015907Z 2698 94:d=2 hl=2 l= 26 cons: SEQUENCE 2699 96:d=3 hl=2 l= 24 cons: SET 2700 98:d=4 hl=2 l= 22 cons: SEQUENCE 2701 100:d=5 hl=2 l= 3 prim: OBJECT:commonName 2702 105:d=5 hl=2 l= 15 prim: PRINTABLESTRING :whimsy.udel.edu 2703 122:d=2 hl=2 l= 90 cons: SEQUENCE 2704 124:d=3 hl=2 l= 13 cons: SEQUENCE 2705 126:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption 2706 137:d=4 hl=2 l= 0 prim: NULL 2707 139:d=3 hl=2 l= 73 prim: BIT STRING 2708 214:d=2 hl=2 l= 107 cons: cont [ 3 ] 2709 216:d=3 hl=2 l= 105 cons: SEQUENCE 2710 218:d=4 hl=2 l= 15 cons: SEQUENCE 2711 220:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Basic Constraints 2712 225:d=5 hl=2 l= 1 prim: BOOLEAN :255 2713 228:d=5 hl=2 l= 5 prim: OCTET STRING 2714 235:d=4 hl=2 l= 11 cons: SEQUENCE 2715 237:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Key Usage 2716 242:d=5 hl=2 l= 4 prim: OCTET STRING 2717 248:d=4 hl=2 l= 73 cons: SEQUENCE 2718 250:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Subject Key Identifier 2719 255:d=5 hl=2 l= 66 prim: OCTET STRING 2720 323:d=1 hl=2 l= 13 cons: SEQUENCE 2721 325:d=2 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 2722 336:d=2 hl=2 l= 0 prim: NULL 2723 338:d=1 hl=2 l= 65 prim: BIT STRING 2725 F.2 GQkey File and ASN.1 Encoding 2727 # ntpkey_GQkey_whimsy.udel.edu.3236983143 2728 # Tue Jul 30 01:59:03 2002 2729 -----BEGIN RSA PUBLIC KEY----- 2730 MIGEAkAbYA9K8kpo2ki7Vq6cSkDccqe0RV6MTrFgjt/sp7E8Ki1mng45PJneAq9B 2731 ZO4rlLYrftLoejQY/nJA2q3MK7iMAkBFRRmWq92n6GXBw5oW4Ijpmga7Vk5Sx0cC 2732 CbMIHi7qgdX27DRIFKhXmwUdWPai8GEFJu8pQQ/t8/T5YXFDsLZy 2733 -----END RSA PUBLIC KEY----- 2735 0:d=0 hl=3 l= 132 cons: SEQUENCE 2736 3:d=1 hl=2 l= 64 prim: INTEGER : 2737 69:d=1 hl=2 l= 64 prim: INTEGER : 2739 F.3 GQpar File and ASN.1 Encoding 2741 # ntpkey_GQpar_whimsy.udel.edu.3236983143 2742 # Tue Jul 30 01:59:03 2002 2743 -----BEGIN RSA PUBLIC KEY----- 2744 MIGFAkEAvojViJ3TowkOKpsb6HBZ50SfzC1M4mAGd51q91WhT7S7IZBfIF/emwXe 2745 yJmZijRqYkCpQj+fp528yRwefq+IowJADgw/uaQ0qU/Q2JeMQ2JtSHKHCTmnVVPE 2746 mXPvH9UU/AnMEuiG0LL6AkdxIZiXRuUrOtXsb22tifzMnc/yrus+2g== 2747 -----END RSA PUBLIC KEY----- 2749 0:d=0 hl=3 l= 133 cons: SEQUENCE 2750 3:d=1 hl=2 l= 65 prim: INTEGER : 2751 70:d=1 hl=2 l= 64 prim: INTEGER : 2753 F.4 RSAkey File and ASN.1 Encoding 2755 # ntpkey_RSAkey_whimsy.udel.edu.3236983143 2756 # Tue Jul 30 01:59:03 2002 2757 -----BEGIN RSA PRIVATE KEY----- 2758 MIIBOgIBAAJBANj6Ts+raEkNwbXRqwbfhenEknXus4WsjsEY+ZwJDr7UOdOYXcVo 2759 bnXynu2TmB0Sy6gAr1SRHwWkrxOThVpXVKkCAQMCQQCQpt81HPAws9Z5NnIElQPx 2760 Lbb5Sc0DyF8rZfu9W18p4Zb5UH3KYqZfAO4K0GTmxuriFphgS9bELSw5L6ow4t6D 2761 AiEA7ACLlKZtCp91CaDohViPhs7KBdRVq7DG9n88z9MM/gMCIQDrXRQMb2dqR/ww 2762 PHJ7aljkhhTE78mxLpn2Po82PfYI4wIhAJ1VsmMZngcU+LEV8FjltQSJ3APi48fL 2763 L07/fd/iCKlXAiEAnOi4CEpE8YVSytL2/PGQmFljLfUxIMm7+X8KJClOsJcCICgU 2764 1w07kRO2ycicL2QRVh8J8vQL68VfH53H+oobKDCd 2765 -----END RSA PRIVATE KEY----- 2767 0:d=0 hl=4 l= 314 cons: SEQUENCE 2768 4:d=1 hl=2 l= 1 prim: INTEGER :00 2769 7:d=1 hl=2 l= 65 prim: INTEGER : 2770 74:d=1 hl=2 l= 1 prim: INTEGER :03 2771 77:d=1 hl=2 l= 65 prim: INTEGER : 2772 144:d=1 hl=2 l= 33 prim: INTEGER : 2773 179:d=1 hl=2 l= 33 prim: INTEGER : 2774 214:d=1 hl=2 l= 33 prim: INTEGER : 2775 249:d=1 hl=2 l= 33 prim: INTEGER : 2776 284:d=1 hl=2 l= 32 prim: INTEGER : 2778 F.5 IFFpar File and ASN.1 Encoding 2780 # ntpkey_IFFpar_whimsy.udel.edu.3236983143 2781 # Tue Jul 30 01:59:03 2002 2782 -----BEGIN DSA PRIVATE KEY----- 2783 MIH4AgEAAkEA7fBvqq9+3DH5BnBScMkruqH4QEB76oec1zjWQ23gyoP2U+L8tHfv 2784 z2LmogOqE1c0McgQynyfQMSDUEmxMyiDwQIVAJ18qdV84wmiCGmWgsHKbpAwepDX 2785 AkA4y42QqZ8aUzQRwkMuYTKbyRRnCG1TJi5eVJcCq65twl5c1bnn24xkbl+FXqck 2786 G6w9NcDtSzuYg1gFLxEuWsYaAkEAjc+nPJR7VY4BjDleVTna07edDfcySl9vy8Pa 2787 B4qArk51LdJlJ49yxEPUxFy/KBIFEHCwRZMc1J7z7dQ/Af26zQIUMXkbVz0D+2Yo 2788 YlG0C/F33Q+N5No= 2789 -----END DSA PRIVATE KEY----- 2791 0:d=0 hl=3 l= 248 cons: SEQUENCE 2792 3:d=1 hl=2 l= 1 prim: INTEGER :00 2793 6:d=1 hl=2 l= 65 prim: INTEGER : 2794 73:d=1 hl=2 l= 21 prim: INTEGER : 2795 96:d=1 hl=2 l= 64 prim: INTEGER : 2796 162:d=1 hl=2 l= 65 prim: INTEGER : 2797 229:d=1 hl=2 l= 20 prim: INTEGER : 2799 Appendix G. ASN.1 Encoding Rules 2801 Certain value fields in request and response messages contain data 2802 encoded in ASN.1 distinguished encoding rules (DER). The BNF grammer 2803 for each encoding rule is given below along with the OpenSSL routine 2804 used for the encoding in the reference implementation. The object 2805 identifiers for the encryption algorithms and message 2806 digest/signature encryption schemes are specified in [RFC-3279]. The 2807 particular algorithms required for conformance are not specified in 2808 this document. 2810 G.1 COOKIE request, IFF response, GQ response 2812 The value field of these messages contains a sequence of two integers 2813 (x, y). For the COOKIE request, the values are encoded by the 2814 i2d_RSAPublicKey() routine in the OpenSSL distribution. For the IFF 2815 and GQ responses, the values are encoded by the i2d_DSA_SIG() 2816 routine. 2818 In the COOKIE request, x is the RSA modulus in bits and y is the 2819 public exponent. In the IFF and GQ responses, x is the challenge 2820 response and y is the hash of the private value. 2822 RSAPublicKey ::= SEQUENCE { 2823 x ::= INTEGER, 2824 y ::= INTEGER 2825 } 2827 G.2 CERT response, SIGN request and response 2829 The value field contains a X509v3 certificate encoded by the 2830 i2d_X509() routine in the OpenSSL distribution. The encoding follows 2831 the rules stated in [RFC-3280], including the use of X509v3 extension 2832 fields. 2834 Certificate ::= SEQUENCE { 2835 tbsCertificate TBSCertificate, 2836 signatureAlgorithmAlgorithmIdentifier, 2837 signatureValue BIT STRING 2838 } 2839 The signatureAlgorithm is the object identifier of the message 2840 digest/signature encryption scheme used to sign the certificate. The 2841 signatureValue is computed by the certificate issuer using this 2842 algorithm and the issuer private key. 2844 TBSCertificate ::= SEQUENCE { 2845 version EXPLICIT v3(2), 2846 serialNumber CertificateSerialNumber, 2847 signature AlgorithmIdentifier, 2848 issuer Name, 2849 validity Validity, 2850 subject Name, 2851 subjectPublicKeyInfo SubjectPublicKeyInfo, 2852 extensions EXPLICIT Extensions OPTIONAL 2853 } 2855 The serialNumber is an integer guaranteed to be unique for the 2856 generating host. The reference implementation uses the NTP seconds 2857 when the certificate was generated. The signature is the object 2858 identifier of the message digest/signature encryption scheme used to 2859 sign the certificate. It must be identical to the signatureAlgorithm. 2861 CertificateSerialNumber ::= INTEGER 2863 Validity ::= SEQUENCE { 2864 notBefore UTCTime, 2865 notAfter UTCTime 2866 } 2868 The notBefore and notAfter define the period of validity as defined 2869 in and certificate filestamp are summarized in Appendix X. 2871 SubjectPublicKeyInfo ::= SEQUENCE { 2872 algorithm AlgorithmIdentifier, 2873 subjectPublicKey BIT STRING 2874 } 2876 The AlgorithmIdentifier specifies the encryption algorithm for the 2877 subject public key. The subjectPublicKey is the public key of the 2878 subject. 2880 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 2882 Extension ::= SEQUENCE { 2883 extnID OBJECT IDENTIFIER, 2884 critical BOOLEAN DEFAULT FALSE, 2885 extnValue OCTET STRING 2886 } 2888 Name ::= SEQUENCE { 2889 OBJECT IDENTIFIER commonName 2890 PrintableString HostName 2891 } 2893 For all certificates, the subject HostName is the unique DNS name of 2894 the host to which the public key belongs. The reference 2895 implementation uses the string returned by the Unix gethostname() 2896 routine (trailing NUL removed). For other than self-signed 2897 certificates, the issuer HostName is the unique DNS name of the host 2898 signing the certificate. 2900 Security Considerations 2902 Security issues are the main topic of this document. 2904 Author's Addresses 2906 David L. Mills 2907 Electrical and Computer Engineering Department 2908 University of Delaware 2909 Newark, DE 19716 2910 USA 2912 Email: mills@udel.edu 2913 Full Copyright Statement 2915 Copyright (C) The Internet Society (2002). All Rights Reserved. 2917 This document and translations of it may be copied and furnished to 2918 others, and derivative works that comment on or otherwise explain it 2919 or assist in its implementation may be prepared, copied, published 2920 and distributed, in whole or in part, without restriction of any 2921 kind, provided that the above copyright notice and this paragraph are 2922 included on all such copies and derivative works. However, this 2923 document itself may not be modified in any way, such as by removing 2924 the copyright notice or references to the Internet Society or other 2925 Internet organizations, except as needed for the purpose of 2926 developing Internet standards in which case the procedures for 2927 copyrights defined in the Internet Standards process must be 2928 followed, or as required to translate it into languages other than 2929 English. 2931 The limited permissions granted above are perpetual and will not be 2932 revoked by the Internet Society or its successors or assigns. 2934 This document and the information contained herein is provided on an 2935 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2936 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2937 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2938 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2939 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.