idnits 2.17.1 draft-ietf-ntp-autokey-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2392. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2286: '... EXPLICIT Extensions OPTIONAL...' == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1305, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 25, 2008) is 5905 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-ntp-ntpv4-proto-08 -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. '2') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '5') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '7') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2875 (ref. '8') (Obsoleted by RFC 6955) -- Obsolete informational reference (is this intentional?): RFC 2510 (ref. '9') (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. '10') (Obsoleted by RFC 5280) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Haberman, Ed. 3 Internet-Draft JHU/APL 4 Obsoletes: RFC 1305 D. Mills 5 (if approved) U. Delaware 6 Intended status: Informational February 25, 2008 7 Expires: August 28, 2008 9 Network Time Protocol Version 4 Autokey Specification 10 draft-ietf-ntp-autokey-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 28, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This memo describes the Autokey security model for authenticating 44 servers to clients using the Network Time Protocol (NTP) and public 45 key cryptography. Its design is based on the premise that IPSEC 46 schemes cannot be adopted intact, since that would preclude stateless 47 servers and severely compromise timekeeping accuracy. In addition, 48 PKI schemes presume authenticated time values are always available to 49 enforce certificate lifetimes; however, cryptographically verified 50 timestamps require interaction between the timekeeping and 51 authentication functions. 53 This memo includes the Autokey requirements analysis, design 54 principles and protocol specification. A detailed description of the 55 protocol states, events and transition functions is included. A 56 prototype of the Autokey design based on this memo has been 57 implemented, tested and documented in the NTP Version 4 (NTPv4) 58 software distribution for Unix, Windows and VMS at 59 http://www.ntp.org. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. NTP Security Model . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Autokey Cryptography . . . . . . . . . . . . . . . . . . . . . 8 67 5. NTP Secure Groups . . . . . . . . . . . . . . . . . . . . . . 11 68 6. Identity Schemes . . . . . . . . . . . . . . . . . . . . . . . 15 69 7. Timestamps and Filestamps . . . . . . . . . . . . . . . . . . 16 70 8. Autokey Protocol Overview . . . . . . . . . . . . . . . . . . 18 71 9. Autokey Operations . . . . . . . . . . . . . . . . . . . . . . 20 72 10. Autokey Protocol Messages . . . . . . . . . . . . . . . . . . 21 73 10.1. No-Operation . . . . . . . . . . . . . . . . . . . . . . 23 74 10.2. Association Message (ASSOC) . . . . . . . . . . . . . . . 24 75 10.3. Certificate Message (CERT) . . . . . . . . . . . . . . . 24 76 10.4. Cookie Message (COOKIE) . . . . . . . . . . . . . . . . . 24 77 10.5. Autokey Message (AUTO) . . . . . . . . . . . . . . . . . 24 78 10.6. Leapseconds Values Message (LEAP) . . . . . . . . . . . . 25 79 10.7. Sign Message (SIGN) . . . . . . . . . . . . . . . . . . . 25 80 10.8. Identity Messages (IFF, GQ, MV) . . . . . . . . . . . . . 25 81 11. Autokey State Machine . . . . . . . . . . . . . . . . . . . . 25 82 11.1. Status Word . . . . . . . . . . . . . . . . . . . . . . . 25 83 11.2. Host State Variables . . . . . . . . . . . . . . . . . . 27 84 11.3. Client State Variables (all modes) . . . . . . . . . . . 29 85 11.4. Server State Variables (broadcast and symmetric modes) . 30 86 11.5. Protocol State Transitions . . . . . . . . . . . . . . . 30 87 11.5.1. Server Dance . . . . . . . . . . . . . . . . . . . . 30 88 11.5.2. Broadcast Dance . . . . . . . . . . . . . . . . . . . 31 89 11.5.3. Symmetric Dance . . . . . . . . . . . . . . . . . . . 32 90 11.6. Error Recovery . . . . . . . . . . . . . . . . . . . . . 34 91 11.7. Security Considerations . . . . . . . . . . . . . . . . . 36 92 11.8. Protocol Vulnerability . . . . . . . . . . . . . . . . . 36 93 11.9. Clogging Vulnerability . . . . . . . . . . . . . . . . . 37 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 95 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 98 14.2. Informative References . . . . . . . . . . . . . . . . . 38 99 Appendix A. Timestamps, Filestamps and Partial Ordering . . . . . 39 100 Appendix B. Identity Schemes . . . . . . . . . . . . . . . . . . 40 101 B.1. Private Certificate (PC) Scheme . . . . . . . . . . . . . 41 102 B.2. Trusted Certificate (TC) Scheme . . . . . . . . . . . . . 41 103 B.3. Schnorr (IFF) Identity Scheme . . . . . . . . . . . . . . 42 104 B.4. Guillard-Quisquater (GQ) Identity Scheme . . . . . . . . 44 105 B.5. Mu-Varadharajan (MV) Identity Scheme . . . . . . . . . . 46 106 Appendix C. ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 48 107 C.1. COOKIE request, IFF response, GQ response, MV response . 49 108 C.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 49 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 110 Intellectual Property and Copyright Statements . . . . . . . . . . 53 112 1. Introduction 114 A distributed network service requires reliable, ubiquitous and 115 survivable provisions to prevent accidental or malicious attacks on 116 the servers and clients in the network or the values they exchange. 117 Reliability requires that clients can determine that received packets 118 are authentic; that is, were ctually sent by the intended server and 119 not manufactured or modified by an intruder. Ubiquity requires that 120 a client can verify the authenticity of a server using only public 121 information. Survivability requires protection from faulty 122 implementations, improper operation and possibly malicious clogging 123 and replay attacks. 125 This memo describes a cryptographically sound and efficient 126 methodology for use in the Network Time Protocol (NTP) [1]. The 127 various key agreement schemes [2][3][4] proposed require per- 128 association state variables, which contradicts the principles of the 129 remote procedure call (RPC) paradigm in which servers keep no state 130 for a possibly large client population. An evaluation of the PKI 131 model and algorithms as implemented in the OpenSSL library leads to 132 the conclusion that any scheme requiring every NTP packet to carry a 133 PKI digital signature would result in unacceptably poor timekeeping 134 performance. 136 The Autokey protocol is based on a combination of PKI and a pseudo- 137 random sequence generated by repeated hashes of a cryptographic value 138 involving both public and private components. This scheme has been 139 implemented, tested and deployed in the Internet of today. A 140 detailed description of the security model, design principles and 141 implementation is presented in this memo. 143 2. NTP Security Model 145 NTP security requirements are even more stringent than most other 146 distributed services. First, the operation of the authentication 147 mechanism and the time synchronization mechanism are inextricably 148 intertwined. Reliable time synchronization requires cryptographic 149 keys which are valid only over esignated time intervals; but, time 150 intervals can be enforced only when participating servers and clients 151 are reliably synchronized to UTC. In addition, the NTP subnet is 152 hierarchical by nature, so time and trust flow from the primary 153 servers at the root through secondary servers to the clients at the 154 leaves. 156 A client can claim authentic to dependent applications only if all 157 servers on the path to the primary servers are bone-fide authentic. 158 In order to emphasize this requirement, in this memo the notion of 159 "authentic" is replaced by "proventic", a noun new to English and 160 derived from provenance, as in the provenance of a painting. Having 161 abused the language this far, the suffixes fixable to the various 162 derivatives of authentic will be adopted for proventic as well. In 163 NTP each server authenticates the next lower stratum servers and 164 proventicates (authenticates by induction) the lowest stratum 165 (primary) servers. Serious computer linguists would correctly 166 interpret the proventic relation as the transitive closure of the 167 authentic relation. 169 It is important to note that the notion of proventic does not 170 necessarily imply the time is correct. A NTP client mobilizes a 171 number of concurrent associations with different servers and uses a 172 crafted agreement algorithm to pluck truechimers from the population 173 possibly including falsetickers. A particular association is 174 proventic if the server certificate and identity have been verified 175 by the means described in this memo. However, the statement "the 176 client is synchronized to proventic sources" means that the system 177 clock has been set using the time values of one or more proventic 178 associations and according to the NTP mitigation algorithms. 180 Over the last several years the IETF has defined and evolved the 181 IPSEC infrastructure for privacy protection and source authentication 182 in the Internet. The infrastructure includes the Encapsulating 183 Security Payload (ESP) [5] and Authentication Header (AH) [6] for 184 IPv4 and IPv6. Cryptographic algorithms that use these headers for 185 various purposes include those developed for the PKI, including MD5 186 message digests, RSA digital signatures and several variations of 187 Diffie-Hellman key agreements. The fundamental assumption in the 188 security model is that packets transmitted over the Internet can be 189 intercepted by other than the intended recipient, remanufactured in 190 various ways and replayed in whole or part. These packets can cause 191 the client to believe or produce incorrect information, cause 192 protocol operations to fail, interrupt network service or consume 193 precious network and processor resources. 195 In the case of NTP, the assumed goal of the intruder is to inject 196 false time values, disrupt the protocol or clog the network, servers 197 or clients with spurious packets that exhaust resources and deny 198 service to legitimate applications. The mission of the algorithms 199 and protocols described in this memo is to detect and discard 200 spurious packets sent by other than the intended sender or sent by 201 the intended sender, but modified or replayed by an intruder. The 202 cryptographic means of the reference implementation are based on the 203 OpenSSL cryptographic software library available at www.openssl.org, 204 but other libraries with equivalent functionality could be used as 205 well. It is important for distribution and export purposes that the 206 way in which these algorithms are used precludes encryption of any 207 data other than incidental to the construction of digital signatures. 209 There are a number of defense mechanisms already built in the NTP 210 architecture, protocol and algorithms. The on-wire timestamp 211 exchange scheme is inherently resistant to spoofing, packet loss and 212 replay attacks. The engineered clock filter, selection and 213 clustering algorithms are designed to defend against evil cliques of 214 Byzantine traitors. While not necessarily designed to defeat 215 determined intruders, these algorithms and accompanying sanity checks 216 have functioned well over the years to deflect improperly operating 217 but presumably friendly scenarios. However, these mechanisms do not 218 securely identify and authenticate servers to clients. Without 219 specific further protection, an intruder can inject any or all of the 220 following attacks. 222 1. An intruder can intercept and archive packets forever, as well as 223 all the public values ever generated and transmitted over the 224 net. 226 2. An intruder can generate packets faster than the server, network 227 or client can process them, especially if they require expensive 228 cryptographic computations. 230 3. In a wiretap attack the intruder can intercept, modify and replay 231 a packet. However, it cannot permanently prevent onward 232 transmission of the original packet; that is, it cannot break the 233 wire, only tell lies and congest it. Except in unlikely cases 234 considered in Section 11.7, the modified packet cannot arrive at 235 the victim before the original packet, nor does it have the 236 server private keys or identity parameters. 238 4. In a middleman or masquerade attack the intruder is positioned 239 between the server and client, so it can intercept, modify and 240 replay a packet and prevent onward transmission of the original 241 packet. Except in unlikely cases considered in Section 11.7, the 242 middleman does not have the server private keys. 244 The NTP security model assumes the following possible limitations. 246 1. The running times for public key algorithms are relatively long 247 and highly variable. In general, the performance of the time 248 synchronization function is badly degraded if these algorithms 249 must be used for every NTP packet. 251 2. In some modes of operation it is not feasible for a server to 252 retain state variables for every client. It is however feasible 253 to regenerated them for a client upon arrival of a packet from 254 that client. 256 3. The lifetime of cryptographic values must be enforced, which 257 requires a reliable system clock. However, the sources that 258 synchronize the system clock must be cryptographically 259 proventicated. This circular interdependence of the timekeeping 260 and proventication functions requires special handling. 262 4. Client security functions must involve only public values 263 transmitted over the net. Private values must never be disclosed 264 beyond the machine on which they were created, except in the case 265 of a special trusted agent (TA) assigned for this purpose. 267 Unlike the Secure Shell security model, where the client must be 268 securely authenticated to the server, in NTP the server must be 269 securely authenticated to the client. In ssh each different 270 interface address can be bound to a different name, as returned by a 271 reverse-DNS query. In this design separate public/private key pairs 272 may be required for each interface address with a distinct name. A 273 perceived advantage of this design is that the security compartment 274 can be different for each interface. This allows a firewall, for 275 instance, to require some interfaces to authenticate the client and 276 others not. 278 3. Approach 280 The Autokey protocol described in this memo is designed to meet the 281 following objectives. In-depth discussions on these objectives is in 282 the web briefings and will not be elaborated in this memo. Note that 283 here and elsewhere in this memo mention of broadcast mode means 284 multicast mode as well, with exceptions as noted in the NTP software 285 documentation. 287 1. It must interoperate with the existing NTP architecture model and 288 protocol design. In particular, it must support the symmetric 289 key scheme described in [7]. As a practical matter, the 290 reference implementation must use the same internal key 291 management system, including the use of 32-bit key IDs and 292 existing mechanisms to store, activate and revoke keys. 294 2. It must provide for the independent collection of cryptographic 295 values and time values. A NTP packet is accepted for processing 296 only when the required cryptographic values have been obtained 297 and verified and the packet has passed all header sanity checks. 299 3. It must not significantly degrade the potential accuracy of the 300 NTP synchronization algorithms. In particular, it must not make 301 unreasonable demands on the network or host processor and memory 302 resources. 304 4. It must be resistant to cryptographic attacks, specifically those 305 identified in the security model above. In particular, it must 306 be tolerant of operational or implementation variances, such as 307 packet loss or misorder, or suboptimal configurations. 309 5. It must build on a widely available suite of cryptographic 310 algorithms, yet be independent of the particular choice. In 311 particular, it must not require data encryption other than 312 incidental to signature and cookie encryption operations. 314 6. It must function in all the modes supported by NTP, including 315 server, symmetric and broadcast modes. 317 4. Autokey Cryptography 319 Autokey cryptography is based on the PKI algorithms commonly used in 320 the Secure Shell and Secure Sockets Layer applications. As in these 321 applications Autokey uses message digests to detect packet 322 modification, digital signatures to verify credentials and public 323 certificates to provide traceable authority. What makes Autokey 324 cryptography unique is the way in which these algorithms are used to 325 deflect intruder attacks while maintaining the integrity and accuracy 326 of the time synchronization function. 328 NTPv3 and NTPv4 symmetric key cryptography uses keyed-MD5 message 329 digests with a 128-bit private key and 32-bit key ID. In order to 330 retain backward compatibility with NTPv3, the NTPv4 key ID space is 331 partitioned in two subspaces at a pivot point of 65536. Symmetric 332 key IDs have values less than the pivot and indefinite lifetime. 333 Autokey key IDs have pseudo-random values equal to or greater than 334 the pivot and are expunged immediately after use. 336 Both symmetric key and public key cryptography authenticate as shown 337 in Figure 1. The server looks up the key associated with the key ID 338 and calculates the message digest from the NTP header and extension 339 fields together with the key value. The key ID and digest form the 340 message authentication code (MAC) included with the message. The 341 client does the same computation using its local copy of the key and 342 compares the result with the digest in the MAC. If the values agree, 343 the message is assumed authentic. 345 +------------------+ 346 | NTP Header and | 347 | Extension Fields | 348 +------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | | Message Authenticator Code | 350 \|/ \|/ + (MAC) + 351 ******************** | +-------------------------+ | 352 * Compute Hash *<----| Key ID | Message Digest | + 353 ******************** | +-------------------------+ | 354 | +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+ 355 \|/ \|/ 356 +------------------+ +-------------+ 357 | Message Digest |------>| Compare | 358 +------------------+ +-------------+ 360 Figure 1: Message Authentication 362 Autokey uses specially contrived session keys, called autokeys, and a 363 precomputed pseudo-random sequence of autokeys which are saved in the 364 autokey list. The Autokey protocol operates separately for each 365 association, so there may be several autokey sequences operating 366 independently at the same time. 368 +-------------+-------------+--------+--------+ 369 | Src Address | Dst Address | Key ID | Cookie | 370 +-------------+-------------+--------+--------+ 372 Figure 2: NTPv4 Autokey 374 An autokey is computed from four fields in network byte order as 375 shown in Figure 2. The four values are hashed by the MD5 message 376 digest algorithm to produce the 128-bit autokey value, which in the 377 reference implementation is stored along with the key ID in a cache 378 used for symmetric keys as well as autokeys. Keys are retrieved from 379 the cache by key ID using hash tables and a fast lookup algorithm. 381 For use with IPv4 the Source Address and Dest Address fields contain 382 32 bits; for use with IPv6 these fields contain 128 bits. In either 383 case the Key ID and Cookie fields contain 32 bits. Thus, an IPv4 384 autokey has four 32-bit words, while an IPv6 autokey has ten 32-bit 385 words. The source and destination addresses and key ID are public 386 values visible in the packet, while the cookie can be a public value 387 or shared private value, depending on the NTP mode. 389 The NTP packet format has been augmented to include one or more 390 extension fields piggybacked between the original NTP header and the 391 MAC. For packets without extension fields, the cookie is a shared 392 private value. For packets with extension fields, the cookie has a 393 default public value of zero, since these packets are validated 394 independently using digital signatures. 396 There are some scenarios where the use of endpoint IP addresses may 397 be difficult or impossible. These include configurations where 398 network address translation (NAT) devices are in use or when 399 addresses are changed during an association lifetime due to mobility 400 constraints. For Autokey, the only restriction is that the address 401 fields visible in the transmitted packet must be the same as those 402 used to construct the autokey list and that these fields be the same 403 as those visible in the received packet. [The use of alternative 404 means, such as Autokey host names (discussed later) or hashes of 405 these names may be a topic for future study.] 407 +-----------+-----------+------+------+ +---------+ +-----+------+ 408 |Src Address|Dst Address|Key ID|Cookie|-->| | |Final|Final | 409 +-----------+-----------+------+------+ | Session | |Index|Key ID| 410 | | | | | Key ID | +-----+------+ 411 \|/ \|/ \|/ \|/ | List | | | 412 ************************************* +---------+ \|/ \|/ 413 * COMPUTE HASH * ******************* 414 ************************************* *COMPUTE SIGNATURE* 415 | Index n ******************* 416 \|/ | 417 +--------+ | 418 | Next | \|/ 419 | Key ID | +-----------+ 420 +--------+ | Signature | 421 Index n+1 +-----------+ 423 Figure 3: Constructing the Key List 425 Figure Figure 3 shows how the autokey list and autokey values are 426 computed. The key IDs used in the autokey list consists of a 427 sequence starting with a random 32-bit nonce (autokey seed) equal to 428 or greater than the pivot as the first key ID. The first autokey is 429 computed as above using the given cookie and autokey seed and 430 assigned index 0. The first 32 bits of the result in network byte 431 order become the next THe MD5 hash of the autokey is the key value 432 saved in the key cache along with the key ID. The first 32 bits of 433 the key become the key ID for the next autokey assigned index 1. 435 Operations continue to generate the entire list. It may happen that 436 a newly generated key ID is less than the pivot or collides with 437 another one already generated (birthday event). When this happens, 438 which occurs only rarely, the key list is terminated at that point. 439 The lifetime of each key is set to expire one poll interval after its 440 scheduled use. In the reference implementation, the list is 441 terminated when the maximum key lifetime is about one hour, so for 442 poll intervals above one hour a new key list containing only a single 443 entry is regenerated for every poll. 445 +------------------+ 446 | NTP Header and | 447 | Extension Fields | 448 +------------------+ 449 | | 450 \|/ \|/ +---------+ 451 **************** +--------+ | Session | 452 * COMPUTE HASH *<---| Key ID |<---| Key ID | 453 **************** +--------+ | List | 454 | | +---------+ 455 \|/ \|/ 456 +----------------------------------+ 457 | Message Authenticator Code (MAC) | 458 +----------------------------------+ 460 Figure 4: Transmitting Messages 462 The index of the last autokey in the list is saved along with the key 463 ID for that entry, collectively called the autokey values. The 464 autokey values are then signed for use later. The list is used in 465 reverse order as shown in Figure 4, so that the first autokey used is 466 the last one generated. 468 The Autokey protocol includes a message to retrieve the autokey 469 values and verify the signature, so that subsequent packets can be 470 validated using one or more hashes that eventually match the last key 471 ID (valid) or exceed the index (invalid). This is called the autokey 472 test in the following and is done for every packet, including those 473 with and without extension fields. In the reference implementation 474 the most recent key ID received is saved for comparison with the 475 first 32 bits in network byte order of the next following key value. 476 This minimizes the number of hash operations in case a single packet 477 is lost. 479 5. NTP Secure Groups 481 NTP secure groups are used to define cryptographic compartments and 482 security hierarchies. A secure group consists of a number of hosts 483 dynamically assembled as a forest with roots the trusted hosts (THs) 484 at the lowest stratum of the group. The THs do not have to be, but 485 often are, primary (stratum 1) servers. A trusted authority (TA), 486 not necessarily a group host, generates private identity keys for 487 servers and public identity keys for clients at the leaves of the 488 forest. The TA deploys the server keys to the THs and other 489 designated servers using secure means and posts the client keys on a 490 public web site. 492 For Autokey purposes all hosts belonging to a secure group have the 493 same group name but different host names, not necessarily related to 494 the DNS names. The group name is used in the subject and issuer 495 fields of the TH certificates; the host name is used in these fields 496 for other hosts. Thus, all host certificates are self-signed. 497 During the Autokey protocol a client requests the server to sign its 498 certificate and caches the result. A certificate trail is 499 constructed by each host, possibly via intermediate hosts and ending 500 at a TH. Thus, each host along the trail retrieves the entire trail 501 from its server(s) and provides this plus its own signed certicicates 502 to its clients. 504 Secure groups can be configured as hierarchies where a TH of one 505 group can be a client of one or more other groups operating at a 506 lower stratum. In one scenario, groups RED and GREEN can be 507 cryptographically distinct, but both be clients of group BLUE 508 operating at a lower stratum. In another scenario, group CYAN can be 509 a client of multiple groups YELLOW and MAGENTA, both operating at a 510 lower stratum. There are many other scenarios, but all must be 511 configured to include only acyclic certificate trails. 513 In Figure 5, the Alice group consists of THs Alice, which is also the 514 TA, and Carol. Dependent servers Brenda and Denise have configured 515 Alice and Carol, respectively, as their time sources. Stratum 3 516 server Eileen has configured both Brenda and Denise as her time 517 sources. Public certificates are identified by the subject and 518 signed by the issuer. Note that the server keys have been previously 519 installed on Brenda and Denise and the client keys installed on all 520 machines. 522 +-------------+ +-------------+ +-------------+ 523 | Alice | | Brenda | | Denise | 524 | | | | | | 525 | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | 526 Certificate | | Alice | | | | Brenda| | | | Denise| | 527 +-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | 528 | Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 | 529 +-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | 530 | Issuer | S | | | | | | 531 +-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ | 532 | ||Alice|| 3 | | | Alice | | | | Carol | | 533 Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ | 534 +=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 | 535 || Group || S | Carol | | +-+-+-+-+ | | +-+-+-+-+ | 536 +=========+ | | | | | | 537 | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | 538 S = step | | Carol | | | | Brenda| | | | Denise| | 539 * = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | 540 | | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 | 541 | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | 542 | | | | | | 543 | +=======+ | | +=======+ | | +=======+ | 544 | ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 | 545 | +=======+ | | +=======+ | | +=======+ | 546 +-------------+ +-------------+ +-------------+ 547 Stratum 1 Stratum 2 549 +---------------------------------------------+ 550 | Eileen | 551 | | 552 | +-+-+-+-+ +-+-+-+-+ | 553 | | Eileen| | Eileen| | 554 | +-+-+-+-+ +-+-+-+-+ | 555 | | Brenda| | Carol | 4 | 556 | +-+-+-+-+ +-+-+-+-+ | 557 | | 558 | +-+-+-+-+ +-+-+-+-+ | 559 | | Alice | | Carol | | 560 | +-+-+-+-+ +-+-+-+-+ | 561 | | Alice*| | Carol*| 2 | 562 | +-+-+-+-+ +-+-+-+-+ | 563 | | 564 | +-+-+-+-+ +-+-+-+-+ | 565 | | Brenda| | Denise| | 566 | +-+-+-+-+ +-+-+-+-+ | 567 | | Alice | | Carol | 2 | 568 | +-+-+-+-+ +-+-+-+-+ | 569 | | 570 | +-+-+-+-+ | 571 | | Eileen| | 572 | +-+-+-+-+ | 573 | | Eileen| 1 | 574 | +-+-+-+-+ | 575 | | 576 | +=======+ | 577 | ||Alice|| 3 | 578 | +=======+ | 579 +---------------------------------------------+ 580 Stratum 3 582 Figure 5: NTP Secure Groups 584 The steps in hiking the certificate trails and verifying identity are 585 as follows. Note the step number in the description matches the step 586 number in the figure. 588 1. The girls start by loading the host key, sign key, self-signed 589 certificate and group key. They start the Autokey protocol by 590 exchanging host names and negotiating digest/signature schemes 591 and identity schemes. 593 2. They continue to load certificates recursively until a self- 594 signed trusted certificate is found. Brenda and Denise 595 immediately find trusted certificates for Alice and Carol, 596 respectively, but Eileen will loop because neither Brenda nor 597 Denise have their own certificates signed by either Alice or 598 Carol. 600 3. Brenda and Denise continue with the selected identity schemes to 601 verify that Alice and Carol have the correct group key previously 602 generated by Alice. If this succeeds, each continues in step 4. 604 4. Brenda and Denise present their certificates for signature. If 605 this succeeds, either or both Brenda and Denise can now provide 606 these signed certificates to Eileen, which may be looping in step 607 2. Eileen can now verify the trail via either Brenda or Denise 608 to the trusted certificates for Alice and Carol. Once this is 609 done, Eileen can complete the protocol just as Brenda and Denise. 611 For various reasons it may be convenient for a server to have client 612 keys for more than one group. For example, Figure 6 shows three 613 secure groups Alice, Helen and Carol arranged in a hierarchy. Hosts 614 A, B, C and D belong to Alice, R, S to Helen and X, Y and Z belong to 615 Carol. While not strictly necessary, hosts A, B and R are stratum 1 616 and presumed trusted, but the TA generating the identity keys could 617 be one of them or another not shown. 619 ***** ***** @@@@@ 620 Stratum 1 * A * * B * @ R @ 621 ***** ***** @@@@@ 622 \ / / 623 \ / / 624 ***** @@@@@ ********* 625 2 * C * @ S @ * Alice * 626 ***** @@@@@ ********* 627 / \ / 628 / \ / @@@@@@@@@ 629 ***** ##### @ Helen @ 630 3 * D * # X # @@@@@@@@@ 631 ***** ##### 632 / \ ######### 633 / \ # Carol # 634 ##### ##### ######### 635 4 # Y # # Z # 636 ##### ##### 638 Figure 6: Hierarchical Overlapping Groups 640 The intent of the scenario is to provide security separation, so that 641 servers cannot masquerade as in other groups and clients cannot 642 masquerade as servers. Assume for example that Alice and Helen 643 belong to national standards laboratories and their server keys are 644 used to confirm identity between members of each group. Carol is a 645 prominent corporation receiving standards products and requiring 646 cryptographic authentication. Perhaps under contract, host X 647 belonging to Carol has client keys for both Alice and Helen and 648 server keys for Carol. The Autokey protocol operates for each group 649 separately while preserving security separation. Host X can prove 650 identity in Carol to clients Y and Z, but cannot prove to anybody 651 that it belongs to either Alice or Helen. 653 6. Identity Schemes 655 A digital signature scheme provides secure server authentication, but 656 it does not provide protection against masquerade, unless the server 657 identity is verified by other means. The PKI model requires a server 658 to prove identity to the client by a certificate trail, but 659 independent means such as a drivers license are required for a CA to 660 sign the server certificate. While Autokey supports this model by 661 default, in a hierarchical ad-hoc network, especially with server 662 discovery schemes like NTP Manycast, proving identity at each rest 663 stop on the trail must be an intrinsic capability of Autokey itself. 665 While the identity scheme described in [8] is based on a ubiquitous 666 Diffie-Hellman infrastructure, it is expensive to generate and use 667 when compared to others described in Appendix B. In principle, an 668 ordinary public key scheme could be devised for this purpose, but the 669 most stringent Autokey design requires that every challenge, even if 670 duplicated, results in a different acceptable response. 672 There are five schemes now implemented in the NTPv4 reference 673 implementation to prove identity: (1) private certificate (PC), (2) 674 trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka 675 Identify Friendly or Foe), (4) a modified Guillou-Quisquater 676 algorithm (GQ), and (5) a modified Mu-Varadharajan algorithm (MV). 677 Following is a summary description of each; details are given in 678 Appendix B. 680 The PC scheme involves a private certificate as group key. The 681 certificate is distributed to all other group members by secure means 682 and is never revealed outside the group. In effect, the private 683 certificate is used as a symmetric key. This scheme is used 684 primarily for testing and development and is not recommended for 685 regular use and is not considered further in this memo. 687 All other schemes involve a conventional certificate trail as 688 described in RFC 2510 [9]. This is the default scheme when an 689 identity scheme is not specified. While the remaining identity 690 schemes incorporate TC, it is not by itself considered further in 691 this memo. 693 The three remaining schemes IFF, GQ and MV involve a 694 cryptographically strong challenge-response exchange where an 695 intruder cannot deduce the server key, even after repeated 696 observations of multiple exchanges. In addition, the MV scheme is 697 properly described as a zero-knowledge proof, because the client can 698 verify the server has the correct group key without either the server 699 or client knowing its value. These schemes start when the client 700 sends a nonce to the server, which then rolls its own nonce, performs 701 a mathematical operation and sends the results to the client. The 702 client performs another mathematical operation and verifies the 703 results are correct. 705 7. Timestamps and Filestamps 707 While public key signatures provide strong protection against 708 misrepresentation of source, computing them is expensive. This 709 invites the opportunity for an intruder to clog the client or server 710 by replaying old messages or originating bogus messages. A client 711 receiving such messages might be forced to verify what turns out to 712 be an invalid signature and consume significant processor resources. 714 In order to foil such attacks, every Autokey message carries a 715 timestamp in the form of the NTP seconds when it was. If the system 716 clock is synchronized to a proventic source, a signature is produced 717 with valid (nonzero) timestamp. Otherwise, there is no signature and 718 the timestamp is invalid (zero). The protocol detects and discards 719 extension fields with old or duplicate timestamps, before any values 720 are used or signatures are verified. 722 Signatures are computed only when cryptgraphic values are created or 723 modified, which is by design not very ofter. Extension fields 724 carrying these signatures are copied to messages as needed, but the 725 signarutres are not recomputed. There are three signature tyupes: 727 1. Cookie signature/timestamp. The cookie is signed when created by 728 the server and sent to the cliente. 730 2. Autokey signature/timestamp. The autokey values are signed when 731 the key list is created. 733 3. Public values signature/timestamp. The public key, certificate 734 and leapsecond values are signed at the time of generation, which 735 occurs when the system clock is first synchronized to a proventic 736 source, when the values have changed and about once per day after 737 that, even if these values have not changed. 739 The most recent timestamp received of each type is saved for 740 comparison. Once a signature with valid timestamp has been received, 741 messages with invalid timestamps or earlier valid timestamps of the 742 same type are discarded before the signature is verified. This is 743 most important in broadcast mode, which could be vulnerable to a 744 clogging attack without this test. 746 All cryptographic values used by the protocol are time sensitive and 747 are regularly refreshed. In particular, files containing 748 cryptographic values used by signature and encryption algorithms are 749 regenerated from time to time. It is the intent that file 750 regenerations occur without specific advance warning and without 751 requiring prior distribution of the file contents. While 752 cryptographic data files are not specifically signed, every file is 753 associated with a filestamp showing the NTP seconds at the creation 754 epoch. 756 Filestamps and timestamps can be compared in any combination and use 757 the same conventions. It is necessary to compare them from time to 758 time to determine which are earlier or later. Since these quantities 759 have a granularity only to the second, such comparisons are ambiguous 760 if the values are in the same second. 762 It is important that filestamps be proventic data; thus, they cannot 763 be produced unless the producer has been synchronized to a proventic 764 source. As such, the filestamps throughout the NTP subnet represent 765 a partial ordering of all creation epochs and serve as means to 766 expunge old data and insure new data are consistent. As the data are 767 forwarded from server to client, the filestamps are preserved, 768 including those for certificate and leapseconds values. Packets with 769 older filestamps are discarded before spending cycles to verify the 770 signature. 772 8. Autokey Protocol Overview 774 The Autokey protocol includes a number of request/response exchanges 775 that must be completed in order. In each exchange a client sends a 776 request message with data and expects a server response message with 777 data. Requests and responses are containined in extension fields, 778 one request or response in each field, as described later. An NTP 779 packet can contain one request message and one or more response 780 messages. Following is a list of these messages. 782 o Parameter exchange. The request includes the client host name; 783 the response one contains the server host name and status word. 784 The status word specifies the digest/signature scheme it will use 785 and the identity schemes it supports. 787 o Certificate exchange. The request includes the subject name of a 788 certificate; the response consists of a signed certificate with 789 that subject name. If the the issuer name is not the same as the 790 subject name, it has been signed by a host one step closer to a 791 trusted host and certificate retrieval continues for the issuer 792 name. If it is trusted and self-signed, the trail concludes at 793 the trusted host. If nontrusted and self-signed, the host 794 certificate has not yet been signed, so the trail temporarily 795 loops. Completion of this exchange lights the VAL bit as 796 described below. 798 o Indentity exchange. The certificate trail is generally not 799 considered sufficient protection against middleman attacks unless 800 additional protection such as described inor proof-of-possession 801 scheme in [8] is available, but this is expensive and requires 802 servers to retain state. Autokey can use one of the challenge/ 803 response identity schemes described in Appendix B. Completion of 804 this exchange lights the IFF bit as described below. 806 o Cookie exchange. The request includes the public key of the 807 client. THe response includes the server cookie encrypted with 808 thise key. The client uses this value when constructing the key 809 list. Completion of this exchange lights the CKY bit as described 810 below. 812 o Autokey exchange. The request includes either no data or the 813 autokey values of the peer in symmetric modes. The response 814 includes the autiokey values of the server or peer. These values 815 are used to verify the autokey sequence. Completion of this 816 exchange lights the AUT bit as described below. 818 o Sign exchange. This exchange is executed only when the client has 819 synchronized to a proventic source. The request includes the 820 self-signed client certificate. The server acting as CA 821 interprets the certificate as a X.509v3 certificate request. It 822 extracts the subject, issuer, and extension fields, builds a new 823 certificate with these data along with its own serial number and 824 expiration time, then signs it using its own public key and 825 includes it in the response. The client uses the signed 826 certificate in its own role as server for dependent clients. 827 Completion of this exchange lights the SGN bit as described below. 829 o Leapseconds exchange. This exchange is executed only when the 830 client has synchronized to a proventic source. This exchange 831 occurs when the server has the leapseconds values, as indicated in 832 the host status word. If so, the client requests the values and 833 compares them with its own values, if available. If the server 834 values are newer than the client values, the client replaces its 835 own with the server values. The client, acting as server, can now 836 provide the most recent values to its dependent clients. In 837 symmetric mode, this results in both peers having the newest 838 values. Completion of this exchange lights the LPT bit as 839 described below. 841 Once the certificates and identity have been validated, subsequent 842 packets are validated by digital signatures and autokey sequences. 843 The association is now proventic with respect to the downstratum 844 trusted host, but in not yet selectable to discipline the system 845 clock. The associations accumulate time values and the mitigation 846 algorithms continue in the usual way. When these algorithms have 847 culled the falsetickers and cluster outlyers and at least three 848 survivors remain, the system clock has been synchronized to a 849 proventic sourc. 851 The time values for truechimer sources form a proventic partial 852 ordering relative to the applicable signature timestamps. This 853 raises the interesting issue of how to mitigate between the 854 timestamps of different associations. It might happen, for instance, 855 that the timestamp of some Autokey message is ahead of the system 856 clock by some presumably small amount. For this reason, timestamp 857 comparisons between different associations and between associations 858 and the system clock are avoided, except in the NTP intersection and 859 clustering algorithms and when determining whether a certificate has 860 expired. 862 9. Autokey Operations 864 The NTP protocol has three principal modes of operation: client/ 865 server, symmetric and broadast and each has its own Autokey program, 866 or dance. Autokey choreography is designed to be nonintrusive and to 867 require no additional packets other than for regular NTP operations. 868 The NTP and Autokey protocols operate simultaneously and 869 independently. When the dance is complete, subsequent packets are 870 validated by the autokey sequence and thus considered proventic as 871 well. Autokey assumes NTP clients poll servers at a relatively low 872 rate, such as once per minute or slower. In particular, it is 873 assumed that a request sent at one poll opportunity will normally 874 result in a response before the next poll opportunity; however the 875 protocol is robust against a missed or duplicate response. 877 The server dance was suggested by Steve Kent over lunch some time 878 ago, but considerably modified since that meal. The server keeps no 879 state for each client, but uses a fast algorithm and a 32-bit random 880 private value (server seed) to regenerate the cookie upon arrival of 881 a client packet. The cookie is calculated as the first 32 bits of 882 the autokey computed from the client and server addresses, key ID 883 zero and the server seed as cookie. The cookie is used for the 884 actual autokey calculation by both the client and server and is thus 885 specific to each client separately. 887 In the server dance the client uses the cookie and each key ID on the 888 key list in turn to retrieve the autokey and generate the MAC. The 889 server uses the same values to generate the message digest and 890 verifies it matches the MAC. It then generates the MAC for the 891 response using the same values, but with the client and server 892 addresses interchanged. The client generates the message digest and 893 verifies it matches the MAC. In order to deflect old replays, the 894 client verifies the key ID matches the last one sent. In this dance 895 the sequential structure of the key list is not exploited, but doing 896 it this way simplifies and regularizes the implementation while 897 making it nearly impossible for an intruder to guess the next key ID. 899 In the broadcast dance clients normally do not send packets to the 900 server, except when first starting up. At that time the client runs 901 the server dance to verify the server credentials and calibrate the 902 propagation delay. The dance requires the association ID of the 903 particular server association, since there can be more than one 904 operating in the same server. For this purpose, the server packet 905 includes the association ID in every response message sent and, when 906 sending the first packet after generating a new key list, it sends 907 the autokey values as well. After obtaining and verifying the 908 autokey values, no extension fields are necessary and the client 909 verifies further server packets using the autokey sequence. 911 The symmetric dance is similar to the server dance and requires only 912 a small amount of state between the arrival of a request and 913 departure of the response. The key list for each direction is 914 generated separately by each peer and used independently, but each is 915 generated with the same cookie. The cookie is conveyed in a way 916 similar to the server dance, except that the cookie is a simple 917 nonce. There exists a possible race condition where each peer sends 918 a cookie request before receiving the cookie response from the other 919 peer. In this case, each peer winds up with two values, one it 920 generated and one the other peer generated. The ambiguity is 921 resolved simply by computing the working cookie as the EXOR of the 922 two values. 924 Once the autokey dance has completed, it is normally dormant. In all 925 except the broadcast dance, packets are normally sent without 926 extension fields, unless the packet is the first one sent after 927 generating a new key list or unless the client has requested the 928 cookie or autokey values. If for some reason the client clock is 929 stepped, rather than slewed, all cryptographic and time values for 930 all associations are purged and the dances in all associations 931 restarted from scratch. This insures that stale values never 932 propagate beyond a clock step. 934 10. Autokey Protocol Messages 936 The Autokey protocol data unit is the extension field, one or more of 937 which can be piggybacked in the NTP packet. An extension field 938 contains either a request with optional data or a response with 939 optional data. To avoid deadlocks, any number of responses can be 940 included in a packet, but only one request. A response is generated 941 for every request, even if the requestor is not synchronized to a 942 proventic source, but most contain meaningful data only if the 943 responder is synchronized to a proventic source. Some requests and 944 most responses carry timestamped signatures. The signature covers 945 the entire extension field, including the timestamp and filestamp, 946 where applicable. Only if the packet passes all extension field 947 tests are cycles spent to verify the signature. 949 There are currently eight Autokey requests and eight corresponding 950 responses. The NTP packet format is described in [1] and the 951 extension field format used for these messages is illustrated in 952 Figure 7. 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Field Type | Length | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Association ID | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Timestamp | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Filestamp | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Value Length | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 \ / 967 / Value \ 968 \ / 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Signature Length | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 \ / 973 / Signature \ 974 \ / 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 \ / 977 / Padding (if needed) \ 978 \ / 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 Figure 7: NTPv4 Extension Field Format 983 Each extension field is zero-padded to a 4 octet boundary. The 984 Length field covers the entire extension field, including the Length 985 and Padding fields. While the minimum field length is 8 octets, a 986 maximum field length remains to be established. The reference 987 implementation discards any packet with a field length more than 1024 988 octets. 990 If an extension field is present, the parser examines the Length 991 field. If the length is less than 4 or not a multiple of 4, a format 992 error has occurred and the packet is discarded; otherwise, the parser 993 increments the pointer by the length value. The parser now uses the 994 same rules as above to determine whether a MAC is present and/or 995 another extension field. 997 The 8-bit Code field specifies the request or response operation, 998 while the 4-bit Version Number (VN) field is 2 for the current 999 protocol version. There are four flag bits: bit 0 is the Response 1000 Flag (R) and bit 1 is the Error Flag (E); the other two bits are 1001 presently unused and should be set to 0. The remaining fields will 1002 be described later. 1004 In the most common protocol operations, a client sends a request to a 1005 server with an operation code specified in the Code field and both 1006 the R bit and E bit dim. The Association ID field is set to the 1007 value previously received from the server or 0 otherwise. The server 1008 returns a response with the same operation code in the Code field and 1009 lights the R bit. The server can also light the E bit in case of 1010 error. The Association ID field is set to the association ID of the 1011 server as a handle for subsequent exchanges. If for some reason the 1012 association ID value in a request does not match the association ID 1013 of any mobilized association, the server returns the request with 1014 both the R and E bits lit. Note that it is not necessarily a 1015 protocol error to send an unsolicited response with no matching 1016 request. 1018 In some cases not all fields may be present. For requests, until a 1019 client has synchronized to a proventic source, signatures are not 1020 valid. In such cases the Timestamp and Signature Length fields are 0 1021 and the Signature field is empty. Responses are generated only when 1022 the responder has synchronized to a proventic source; otherwise, an 1023 error response message is sent. Some request and error response 1024 messages carry no value or signature fields, so in these messages 1025 only the first two words are present. 1027 The Timestamp and Filestamp words carry the seconds field of an NTP 1028 timestamp. The Timestamp field establishes the signature epoch of 1029 the data field in the message, while the filestamp establishes the 1030 generation epoch of the file that ultimately produced the data that 1031 is signed. A signature and timestamp are valid only when the signing 1032 host is synchronized to a proventic source; otherwise, the timestamp 1033 is zero. A cryptographic data file can only be generated if a 1034 signature is possible; otherwise, the filestamp is zero, except in 1035 the ASSOC response message, where it contains the server status word. 1037 Unless specified otherwise in the descriptions to follow, the data 1038 referred to are stored in the Value field. 1040 10.1. No-Operation 1042 A No-operation request (Field Type = 0) does nothing except return an 1043 empty response which can be used as a crypto-ping. 1045 10.2. Association Message (ASSOC) 1047 An Association Message (Field Type = 1) is used in the parameter 1048 exchange to obtain the host name and status word. The request 1049 contains the client status word in the Filestamp field and the host 1050 name in the Value field. The response contains the server status 1051 word in the Filestamp field and the host name in the Value field. By 1052 default the host name is the string returned by the Unix 1053 gethostname() library function. While minimum and maximum host name 1054 lengths remain to be established, the reference implementation uses 1055 the values 4 and 256, respectively. 1057 When multiple identity schemes are supported, the status words 1058 determine which one is used. The request message contains bits 1059 corresponding to the schemes the client supports, while the response 1060 message contains bits corresponding to the schemes the server 1061 supports. The server and client do an AND operation on the status 1062 words to select compatible identity schemes. If multiple schemes 1063 result, the bits are ranked from right to left. 1065 10.3. Certificate Message (CERT) 1067 A Certificate Message (Field Type = 2) is used in the certificate 1068 exchange to obtain a certificate by name. The request contains the 1069 subject name; the response contains the certificate encoded in X.509 1070 format with ASN.1 syntax as described in Appendix C. 1072 If the subject name in the response does not match the issuer name, 1073 the exchange continues with the issuer name replacing the subject 1074 name in the request. The exchange continues until a trusted, self- 1075 signed certificate is found. 1077 10.4. Cookie Message (COOKIE) 1079 The Cookie Message (Field Type = 3) is used in server and symmetric 1080 modes to obtain the server cookie. The request contains the host 1081 public key encoded with ASN.1 syntax as described in Appendix C. The 1082 response contains the cookie encrypted by the public key in the 1083 request. 1085 10.5. Autokey Message (AUTO) 1087 The Autokey Message (Field Type = 4) is used to obtain the autokey 1088 values. The request contains no value. The response contains two 1089 32-bit words in network byte order. The first word is the final key 1090 ID, while the second is the index of the final key ID. 1092 10.6. Leapseconds Values Message (LEAP) 1094 The Leapseconds Values Message (Field Type = 5) is used to obtain the 1095 leapseconds values as parsed from the leapseconds table from NIST. 1096 The request and response messages have the same format, except that 1097 the R bit is set to 0 in the request and set to 1 in the response. 1098 Both the request and response contains three 32-bit integers, the NTP 1099 seconds of the latest leap event followed by the NTP seconds when the 1100 latest NIST table expires and then the TAI offset following the leap 1101 event. 1103 10.7. Sign Message (SIGN) 1105 The Sign Message (Field Type = 6) requests the server to sign and 1106 return a certificate presented in the request. The request contains 1107 the client certificate encoded in X.509 format with ASN.1 syntax as 1108 described in Appendix C. The response contains the client 1109 certificate signed by the server private key. 1111 10.8. Identity Messages (IFF, GQ, MV) 1113 The Identity Messages (Field Type = 7 (IFF), 8 (GQ), or 9 (MV)) 1114 contains the client challenge, usually a 160- or 512-bit nonce. The 1115 response contains the result of the mathematical operation defined in 1116 Appendix B. The Response is encoded in ASN.1 syntax as described in 1117 Appendix C. 1119 11. Autokey State Machine 1121 This section describes the formal model of the Autokey state machine, 1122 its state variables and the state transition functions. 1124 11.1. Status Word 1126 Each server and client operating also as a server implements a host 1127 status word, while each client implements an association status word 1128 for each server. Both words have the format and content shown in 1129 Figure 8. The low order 16 bits of the status word define the state 1130 of the Autokey protocol, while the high order 16 bits specify the 1131 message digest/signature encryption scheme as encoded in the OpenSSL 1132 library. Bits 24-31 of the status word are reserved for server use, 1133 while bits 16-23 are reserved for client association use. In the 1134 host portion bits 24-27 specify the available identity schemes, while 1135 bits 28-31 specify the server capabilities. There are two additional 1136 bits implemented separately. 1138 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Digest / Signature NID | Client | Ident | Host | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Figure 8: Status Word 1146 The host status word is included in the ASSOC request and response 1147 messages. The client copies this word to the association status word 1148 and then lights additional status bits as the dance proceeds. Once 1149 enabled, these bits never come dark unless a general reset occurs and 1150 the protocol is restarted from the beginning. The status bits are 1151 defined as follows: 1153 o ENB (31) - Lit if the server implements the Autokey protocol 1155 o LPF (30) - Lit if the server has loaded leapseconds values 1157 o IDN (24-27) - These four bits select which identity scheme is in 1158 use. While specific coding for various schemes is yet to be 1159 determined, the schemes available in the reference implementation 1160 and described in Appendix B include the following: 1162 * 0x0 Trusted Certificate (TC) Scheme (default) 1164 * 0x1 Private Certificate (PC) Scheme 1166 * 0x2 Schnorr aka Identify-Friendly-or-Foe (IFF) Scheme 1168 * 0x4 Guillard-Quisquater (GC) Scheme 1170 * 0x8 Mu-Varadharajan (MV) Scheme 1172 The PC scheme is exclusive of any other scheme. Otherwise, the IFF, 1173 GQ and MV bits can be enabled in any combination. 1175 The association status bits are defined as follows: 1177 o VAL (0x0100) - Lit when the server certificate and public key are 1178 validated. 1180 o IFF (0x0200) - Lit when the server identity credentials are 1181 confirmed. 1183 o PRV (0x0400) - Lit when the server signature is verified using the 1184 public key and identity credentials. Also called the proventic 1185 bit elsewhere in this memo. When enabled, signed values in 1186 subsequent messages are presumed proventic. 1188 o CKY (0x0800) - Lit when the cookie is received and validated. 1189 When enabled, key lists with nonzero cookies can be generated. 1191 o AUT (0x1000) - Lit when the autokey values are received and 1192 validated. When enabled, clients can validate packets without 1193 extension fields according to the autokey sequence. 1195 o SGN (0x2000) - Lit when the host certificate is signed by the 1196 server. 1198 o LPT (0x4000) - Lit when the leapseconds values are received and 1199 validated. 1201 There are four additional status bits LST and SYN not included in the 1202 status word. LST is a client propertie, while SYN is a host 1203 property. LST is lit when the key list is regenerated and signed and 1204 DIM when the autokey values have been transmitted. This is necessary 1205 to avoid livelock under some conditions. SYN is lit when the client 1206 has synchronized to a proventic source and never dim after that. 1208 11.2. Host State Variables 1210 Following is a list of state variables used by the server protocol. 1212 o Host Name - The name of the host, by default the string returned 1213 by the Unix gethostname() library function. 1215 o Host Status Word - This word is initialized when the host first 1216 starts up. The format is described above. 1218 o Host Key - The RSA public/private key pair used to encrypt/decrypt 1219 cookies. This is also the default sign key. 1221 o Sign Key - The RSA or DSA public/private key pair used to encrypt/ 1222 decrypt signatures when the host key is not used for this purpose. 1224 o Sign Digest - The message digest algorithm used to compute the 1225 signature before encryption. 1227 o IFF Parameters - The parameters used in the optional IFF identity 1228 scheme described in Appendix B. 1230 o GQ Parameters - The parameters used in the optional GQ identity 1231 scheme described in Appendix B. 1233 o MV Parameters - The parameters used in the optional MV identity 1234 scheme described in Appendix B. 1236 o Server Seed - The private value hashed with the IP addresses to 1237 construct the cookie. 1239 o Certificate Information Structure (CIS) - Certificates are used to 1240 construct certificate information structures (CIS) which are 1241 stored on the certificate cache. The structure includes certain 1242 information fields from an X.509v3 certificate, together with the 1243 certificate itself encoded in ASN.1 syntax. Each structure 1244 carries the public value timestamp and the filestamp of the 1245 certificate file where it was generated. Elsewhere in this memo 1246 the CIS will not be distinguished from the certificate unless 1247 noted otherwise. A flags field in the CIS determines the status 1248 of the certificate. The field is encoded as follows: 1250 * TRST (0x01) - The certificate has been signed by a trusted 1251 issuer. If the certificate is self-signed and contains 1252 "trustRoot" in the Extended Key Usage field, this bit is lit 1253 when the CIS is constructed 1255 * SIGN (0x02) - The certificate signature has been verified. If 1256 the certificate is self-signed and verified using the contained 1257 public key, this bit is lit when the CIS is constructed. 1259 * VALD (0x04) - The certificate is valid and can be used to 1260 verify signatures. This bit is lit when a trusted certificate 1261 has been found on a valid certificate trail. 1263 * PRIV (0x08) - The certificate is private and not to be 1264 revealed. If the certificate is self-signed and contains 1265 "Private" in the Extended Key Usage field, this bit is lit when 1266 the CIS is constructed. 1268 * ERRR (0x80) - The certificate is defective and not to be used 1269 in any way. 1271 o Certificate List - CIS structures are stored on the certificate 1272 list in order of arrival, with the most recently received CIS 1273 placed first on the list. The list is initialized with the CIS 1274 for the host certificate, which is read from the certificate file. 1275 Additional CIS entries are pushed on the list as certificates are 1276 obtained from the servers during the certificate exchange. CIS 1277 entries are discarded if overtaken by newer ones or expire due to 1278 old age. 1280 o Host Certificate - The self-signed X.509v3 certificate for the 1281 host. The subject and issuer fields consist of the host name, 1282 while the message digest/signature encryption scheme consists of 1283 the sign key and message digest defined above. Optional 1284 information used in the identity schemes is carried in X.509v3 1285 extension fields compatible with [10]. 1287 o Public Key Values - The public encryption key for the COOKIE 1288 request, which consists of the public value of the host key. It 1289 carries the public values timestamp and the filestamp of the host 1290 key file. 1292 o Leapseconds Values. The leapseconds values parsed from the NIST 1293 leapseconds file. It carries the public values timestamp and the 1294 filestamp of the leapseconds values. 1296 11.3. Client State Variables (all modes) 1298 Following is a list of state variables used by the client association 1299 protocol in all modes. 1301 o Association ID - The association ID used in responses. It is 1302 assigned when the association is mobilized 1304 o Server Association ID - The server association ID used in 1305 requests. It is copied from the first nonzero association ID 1306 field in a response 1308 o Server Subject Name - The server host name determined in the 1309 parameter exchange 1311 o Server Issuer Name - The host name signing the certificate. It is 1312 extracted from the current server certificate upon arrival and 1313 used to request the next item on the certificate trail 1315 o Association Status Word - The host status word of the server 1316 determined in the parameter exchange 1318 o Server Public Key - The public key used to decrypt signatures. It 1319 is extracted from the first certificate received, which by design 1320 is the server host certificate 1322 o Server Message Digest - The digest/signature scheme determined in 1323 the parameter exchange 1325 o Identification Challenge - A 512-bit nonce used in the 1326 identification exchange 1328 o Group Key - A set of values used by the identification exchange. 1329 It identifies the cryptographic compartment shared by the server 1330 and client 1332 o Receive Cookie Values - The cookie returned in a COOKIE response, 1333 together with its timestamp and filestamp 1335 o Receive Autokey Values - The autokey values returned in an AUTO 1336 response, together with its timestamp and filestamp 1338 11.4. Server State Variables (broadcast and symmetric modes) 1340 Following is a list of server state variables used in broadcast and 1341 symmetric modes. 1343 o Send Cookie Values - The cookie encryption values, signature and 1344 timestamps 1346 o Send Autokey Values - The autokey values, signature and timestamps 1348 o Key List - A sequence of key IDs starting with the autokey seed 1349 and each pointing to the next. It is computed, timestamped and 1350 signed at the next poll opportunity when the key list becomes 1351 empty 1353 o Current Key Number - The index of the entry on the Key List to be 1354 used at the next poll opportunity 1356 11.5. Protocol State Transitions 1358 The protocol state machine is very simple but robust. The state is 1359 determined by the server status bits defined above. The state 1360 transitions of the three dances are shown below. The capitalized 1361 truth values represent the server status bits. All server bits are 1362 initialized dark and are lit upon the arrival of a specific response 1363 message, as detailed above. 1365 11.5.1. Server Dance 1367 The server dance begins when the client sends an ASSOC request to the 1368 server. It ends when the first signature is verified and PRV is lit. 1369 Subsequent packets received without extension fields are validated by 1370 the autokey sequence. An optional LEAP exchange updates the 1371 leapseconds values. Note the order of the identity exchanges and 1372 that only the first one will be used if multiple schemes are 1373 available. Note also that the SIGN and LEAP requests are not issued 1374 until the client has synchronized to a proventic source. 1376 while (1) { 1377 wait_for_next_poll; 1378 make_NTP_header; 1379 if (response_ready) 1380 send_response; 1381 if (!ENB) 1382 / * parameters exchange */ 1383 ASSOC_request; 1384 else if (!VAL) 1385 /* certificate exchange */ 1386 CERT_request(Host_Name); 1387 else if (IDN & GQ && !IFF) 1388 /* GQ identity exchange */ 1389 GQ_challenge; 1390 else if (IDN & IFF && !IFF) 1391 /* IFF identity exchange */ 1392 IFF_challenge; 1393 else if (!IFF) 1394 /* TC identity exchange */ 1395 CERT_request(Issuer_Name); 1396 else if (!CKY) 1397 /* cookie exchange */ 1398 COOKIE_request; 1399 else if (SYN && !SIG) 1400 /* signe exchange */ 1401 SIGN_request(Host_Certificate); 1402 else if (SYN && LPF & !LPT) 1403 /* leapseconds exchange */ 1404 LEAP_request; 1406 } 1408 When the PC identity scheme is in use, the ASSOC response sets VAL, 1409 IFF, and SIG to 1; the COOKIE response sets CKY and AUT to 1; and the 1410 first valid signature sets PRV to 1. 1412 11.5.2. Broadcast Dance 1414 The only difference between the broadcast and server dances is the 1415 inclusion of an autokey values exchange following the cookie 1416 exchange. The broadcast dance begins when the client receives the 1417 first broadcast packet, which includes an ASSOC response with 1418 association ID. The broadcast client uses the association ID to 1419 initiate a server dance in order to calibrate the propagation delay. 1421 The dance ends when the first signature is verified and PRV is lit. 1422 Subsequent packets received without extension fields are validated by 1423 the autokey sequence. An optional LEAP exchange updates the 1424 leapseconds values. When the server generates a new key list, the 1425 server replaces the ASSOC response with an AUTO response in the first 1426 packet sent. 1428 while (1) { 1429 wait_for_next_poll; 1430 make_NTP_header; 1431 if (response_ready) 1432 send_response; 1433 if (!ENB) 1434 /* parameters exchange */ 1435 ASSOC_request; 1436 else if (!VAL) 1437 /* certificate exchange */ 1438 CERT_request(Host_Name); 1439 else if (IDN & GQ && !IFF) 1440 /* GQ identity exchange */ 1441 GQ_challenge; 1442 else if (IDN & IFF && !IFF) 1443 /* IFF identity exchange */ 1444 IFF_challenge; 1445 else if (!IFF) 1446 /* TC identity exchange */ 1447 CERT_request(Issuer_Name); 1448 else if (!CKY) 1449 /* cookie exchange */ 1450 COOKIE_request; 1451 else if (!AUT) 1452 /* autokey values exchange */ 1453 AUTO_request; 1454 else if (SYN &&! SIG) 1455 /* sign exchange */ 1456 SIGN_request(Host_Certificate); 1457 else if (SYN && LPF & !LPT) 1458 /* leapseconds exchange */ 1459 LEAP_request; 1460 } 1462 When the PC identity scheme is in use, the ASSOC response lights VAL, 1463 IFF, and SIG; the COOKIE response lights CKY and AUT; and the first 1464 valid signature lights PRV. 1466 11.5.3. Symmetric Dance 1468 The symmetric dance is intricately choreographed. It begins when the 1469 active peer sends an ASSOC request to the passive peer. The passive 1470 peer mobilizes an association and both peers step the same dance from 1471 the beginning. Until the active peer is synchronized to a proventic 1472 source (which could be the passive peer) and can sign messages, the 1473 passive peer loops waiting for the timestamp in the ASSOC response to 1474 light up. Until then, the active peer dances the server steps, but 1475 skips the sign, cookie and leapseconds exchanges. 1477 while (1) { 1478 wait_for_next_poll; 1479 make_NTP_header; 1480 if (!ENB) 1481 /* parameters exchange */ 1482 ASSOC_request; 1483 else if (!VAL) 1484 /* certificate exchange */ 1485 CERT_request(Host_Name); 1486 else if (IDN & GQ && !IFF) 1487 /* GQ identity exchange */ 1488 GQ_challenge; 1489 else if (IDN & IFF && !IFF) 1490 /* IFF identity exchange */ 1491 IFF_challenge; 1492 else if (!IFF) 1493 /* TC identity exchange */ 1494 CERT_request(Issuer_Name); 1495 else if (SYN && !SIG) 1496 /* sign exchange */ 1497 SIGN_request(Host_Certificate); 1498 else if (SYN && !CKY) 1499 /* cookie exchange */ 1500 COOKIE_request; 1501 else if (!LST) 1502 /* autokey values response */ 1503 AUTO_response; 1504 else if (!AUT) 1505 /* autokey values exchange */ 1506 AUTO_request; 1507 else if (SYN && LPF & !LPT) 1508 /* leapseconds exchange */ 1509 LEAP_request; 1510 } 1512 When the PC identity scheme is in use, the ASSOC response lights VAL, 1513 IFF, and SIG; the COOKIE response lights CKY and AUT; and the first 1514 valid signature lights PRV. 1516 Once the active peer has synchronized to a proventic source, it 1517 includes timestamped signatures with its messages. The first thing 1518 it does after lighting timestamps is dance the sign exchange so that 1519 the passive peer can survive the default identity exchange, if 1520 necessary. This is pretty weird, since the passive peer will find 1521 the active certificate signed by its own public key. 1523 The passive peer, which has been stalled waiting for the active 1524 timestamps to light up, now mates the dance. The initial value of 1525 the cookie is zero. If a COOKIE response has not been received by 1526 either peer, the next message sent is a COOKIE request. The 1527 recipient rolls a random cookie, lights CKY and returns the encrypted 1528 cookie. The recipient decrypts the cookie and lights CKY. It is not 1529 a protocol error if both peers happen to send a COOKIE request at the 1530 same time. In this case both peers will have two values, one 1531 generated by itself and the other received from the other peer. In 1532 such cases the working cookie is constructed as the EXOR of the two 1533 values. 1535 At the next packet transmission opportunity, either peer generates a 1536 new key list and sets LST to 1; however, there may already be an AUTO 1537 request queued for transmission and the rules say no more than one 1538 request in a packet. When available, either peer sends an AUTO 1539 response and dims LST. The recipient initializes the autokey values 1540 and lights LST and AUT. Subsequent packets received without 1541 extension fields are validated by the autokey sequence. 1543 The above description assumes the active peer synchronizes to the 1544 passive peer, which itself is synchronized to some other source, such 1545 as a radio clock or another NTP server. In this case, the active 1546 peer is operating at a stratum level one greater than the passive 1547 peer and so the passive peer will not synchronize to it unless it 1548 loses its own sources and the active peer itself has another source. 1550 11.6. Error Recovery 1552 The Autokey protocol state machine includes provisions for various 1553 kinds of error conditions that can arise due to missing files, 1554 corrupted data, protocol violations and packet loss or misorder, not 1555 to mention hostile intrusion. This section describes how the 1556 protocol responds to reachability and timeout events which can occur 1557 due to such errors. 1559 A persistent NTP association is mobilized by an entry in the 1560 configuration file, while an ephemeral association is mobilized upon 1561 the arrival of a broadcast, manycast or symmetric active packet with 1562 no matching association. Subsequently, a general reset reinitializes 1563 all association variables to the initial state when first mobilized. 1564 In addition, if the association is ephemeral, the association is 1565 demobilized and all resources acquired are returned to the system. 1567 Every NTP association has two variables which maintain the liveness 1568 state of the protocol, the 8-bit reachability register defined in [7] 1569 and the watchdog timer, which is new in NTPv4. At every poll 1570 interval the reachability register is shifted left, the low order bit 1571 is dimmed and the high order bit is lost. At the same time the 1572 watchdog counter is incremented by one. If an arriving packet passes 1573 all authentication and sanity checks, the rightmost bit of the 1574 reachability register is lit and the watchdog counter is set to zero. 1575 If any bit in the reachability register is lit, the server is 1576 reachable, otherwise it is unreachable. 1578 When the first poll is sent from an association, the reachability 1579 register and watchdog counter are zero. If the watchdog counter 1580 reaches 16 before the server becomes reachable, a general reset 1581 occurs. This resets the protocol and clears any acquired resources 1582 before trying again. If the server was once reachable and then 1583 becomes unreachable, a general reset occurs. In addition, if the 1584 watchdog counter reaches 16 and the association is persistent, the 1585 poll interval is doubled. This reduces the network load for packets 1586 that are unlikely to elicit a response. 1588 At each state in the protocol the client expects a particular 1589 response from the server. A request is included in the NTP packet 1590 sent at each poll interval until a valid response is received or a 1591 general reset occurs, in which case the protocol restarts from the 1592 beginning. A general reset also occurs for an association when an 1593 unrecoverable protocol error occurs. A general reset occurs for all 1594 associations when the system clock is first synchronized or the clock 1595 is stepped or when the server seed is refreshed. 1597 There are special cases designed to quickly respond to broken 1598 associations, such as when a server restarts or refreshes keys. 1599 Since the client cookie is invalidated, the server rejects the next 1600 client request and returns a crypto-NAK packet. Since the crypto-NAK 1601 has no MAC, the problem for the client is to determine whether it is 1602 legitimate or the result of intruder mischief. In order to reduce 1603 the vulnerability in such cases, the crypto-NAK, as well as all 1604 responses, is believed only if the result of a previous packet sent 1605 by the client and not a replay, as confirmed by the NTP on-wire 1606 protocol. While this defense can be easily circumvented by a 1607 middleman, it does deflect other kinds of intruder warfare. 1609 There are a number of situations where some event happens that causes 1610 the remaining autokeys on the key list to become invalid. When one 1611 of these situations happens, the key list and associated autokeys in 1612 the key cache are purged. A new key list, signature and timestamp 1613 are generated when the next NTP message is sent, assuming there is 1614 one. Following is a list of these situations: 1616 1. When the cookie value changes for any reason. 1618 2. When a client switches from client mode to broadcast client mode. 1619 There is no further need for the key list, since the client will 1620 not transmit again. 1622 3. When the poll interval is changed. In this case the calculated 1623 expiration times for the keys become invalid. 1625 4. If a problem is detected when an entry is fetched from the key 1626 list. This could happen if the key was marked non-trusted or 1627 timed out, either of which implies a software bug. 1629 11.7. Security Considerations 1631 This section discusses the most obvious security vulnerabilities in 1632 the various Autokey dances. In the following discussion the 1633 cryptographic algorithms and private values themselves are assumed 1634 secure; that is, a brute force cryptanalytic attack will not reveal 1635 the host private key, sign private key, cookie value, identity 1636 parameters, server seed or autokey seed. In addition, an intruder 1637 will not be able to predict random generator values. 1639 11.8. Protocol Vulnerability 1641 While the protocol has not been subjected to a formal analysis, a few 1642 preliminary assertions can be made. In the client/server and 1643 symmetric dances the underlying NTP on-wire protocol is resistant to 1644 lost, duplicate and bogus packets, even if the clock is not 1645 synchronized, so the protocol is not vulnerable to a wiretapper 1646 attack. A middleman attack, even if it could simulate a valid 1647 cookie, could not present a valid signature. 1649 In the broadcast dance the client begins with a volley in client/ 1650 server mode to obtain the autokey values and signature, so has the 1651 same protection as in that mode. When continuing in receive-only 1652 mode, a wiretapper cannot produce a key list with valid signed 1653 autokey values. The most it can do is replay an old packet causing 1654 clients to repeat the autokey hash operations until exceeding the 1655 maximum key number. 1657 A client instantiates cryptographic variables only if the server is 1658 synchronized to a proventic source. A server does not sign values or 1659 generate cryptographic data files unless synchronized to a proventic 1660 source. This raises an interesting issue: how does a client generate 1661 proventic cryptographic files before it has ever been synchronized to 1662 a proventic source? [Who shaves the barber if the barber shaves 1663 everybody in town who does not shave himself?] In principle, this 1664 paradox is resolved by assuming the primary (stratum 1) servers are 1665 proventicated by external phenomenological means. 1667 11.9. Clogging Vulnerability 1669 A self-induced clogging incident cannot happen, since signatures are 1670 computed only when the data have changed and the data do not change 1671 very often. For instance, the autokey values are signed only when 1672 the key list is regenerated, which happens about once an hour, while 1673 the public values are signed only when one of them is updated during 1674 a dance or the server seed is refreshed, which happens about once per 1675 day. 1677 There are two clogging vulnerabilities exposed in the protocol 1678 design: an encryption attack where the intruder hopes to clog the 1679 victim server with needless cryptographic calculations, and a 1680 decryption attack where the intruder attempts to clog the victim 1681 client with needless cryptographic calculations. Autokey uses public 1682 key cryptography and the algorithms that perform these functions 1683 consume significant resources. 1685 In client/server and peer dances an encryption hazard exists when a 1686 wiretapper replays prior cookie request messages at speed. There is 1687 no obvious way to deflect such attacks, as the server retains no 1688 state between requests. Replays of cookie response messages are 1689 detected and discarded by the NTP on-wire protocol. 1691 In broadcast mode a client a decription hazard exists when a 1692 wiretapper replays autokey response messages at speed. Once 1693 synchronized to a proventic source, a legitimate extension field with 1694 timestamp the same as or earlier than the most recently received of 1695 that type is immediately discarded. This foils a middleman cut-and- 1696 paste attack using an earlier response, for example. A legitimate 1697 extension field with timestamp in the future is unlikely, as that 1698 would require predicting the autokey sequence. In either case the 1699 extension field is discarded before expensive signature computations. 1700 This defense is most useful in symmetric mode, but a useful 1701 redundancy in other modes. 1703 An interesting adventure is when an intruder replays a recent packet 1704 with an intentional bit error. A stateless server will return a 1705 crypto-NAK message which will be discarded by the NTP on-wire 1706 protocol. However, a legitimate crypto-NAK is sent if the server has 1707 just refreshed the server seed. In this case the the client performs 1708 a general reset and restarts the protocol as expected. 1710 12. IANA Considerations 1712 Any IANA registries needed? 1714 13. Acknowledgements 1716 ... 1718 14. References 1720 14.1. Normative References 1722 [1] Burbank, J., "Network Time Protocol Version 4 Protocol And 1723 Algorithms Specification", draft-ietf-ntp-ntpv4-proto-08 (work 1724 in progress), November 2007. 1726 14.2. Informative References 1728 [2] Maughan, D., Schneider, M., and M. Schertler, "Internet 1729 Security Association and Key Management Protocol (ISAKMP)", 1730 RFC 2408, November 1998. 1732 [3] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 1733 November 1998. 1735 [4] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1736 Protocol", RFC 2522, March 1999. 1738 [5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1739 (ESP)", RFC 2406, November 1998. 1741 [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1742 November 1998. 1744 [7] Mills, D., "Network Time Protocol (Version 3) Specification, 1745 Implementation", RFC 1305, March 1992. 1747 [8] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of- 1748 Possession Algorithms", RFC 2875, July 2000. 1750 [9] Adams, C. and S. Farrell, "Internet X.509 Public Key 1751 Infrastructure Certificate Management Protocols", RFC 2510, 1752 March 1999. 1754 [10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1755 Public Key Infrastructure Certificate and Certificate 1756 Revocation List (CRL) Profile", RFC 3280, April 2002. 1758 [11] Schnorr, C., "Efficient signature generation for smart cards", 1759 1991. 1761 [12] Stinson, D., "Cryptography - Theory and Practice", 1995. 1763 [13] Guillou, L. and J. Quisquatar, "A "paradoxical" identity-based 1764 signature scheme resulting from zero-knowledge", 1990. 1766 [14] Mu, Y. and V. Varadharajan, "Robust and secure broadcasting", 1767 2001. 1769 [15] Mills, D., ""Compouter Network Time Synchronization - the 1770 Network Time Protocol"", 2006. 1772 [16] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1773 Identifiers for the Internet X.509 Public Key Infrastructure 1774 Certificate and Certificate Revocation List (CRL) Profile", 1775 RFC 3279, April 2002. 1777 Appendix A. Timestamps, Filestamps and Partial Ordering 1779 When the host starts, it reads the host key and host certificate 1780 files, which are required for continued operation. It also reads the 1781 sign key and leapseconds values, when available. When reading these 1782 files the host checks the file formats and filestamps for validity; 1783 for instance, all filestamps must be later than the time the UTC 1784 timescale was established in 1972 and the certificate filestamp must 1785 not be earlier than its associated sign key filestamp. At the time 1786 the files are read the host is not synchronized, so it cannot 1787 determine whether the filestamps are bogus other than these simple 1788 checks. It must not produce filestamps or timestamps until 1789 sunchronized to a proventic source. 1791 In the following the relation A --> B is Lamport's "happens before" 1792 relation, which is true if event A happens before event B. When 1793 timestamps are compared to timestamps, the relation is false if A 1794 <--> B; that is, false if the events are simultaneous. For 1795 timestamps compared to filestamps and filestamps compared to 1796 filestamps, the relation is true if A <--> B. Note that the current 1797 time plays no part in these assertions except in (6) below; however, 1798 the NTP protocol itself insures a correct partial ordering for all 1799 current time values. 1801 The following assertions apply to all relevant responses: 1803 1. The client saves the most recent timestamp T0 and filestamp F0 1804 for the respective signature type. For every received message 1805 carrying timestamp T1 and filestamp F1, the message is discarded 1806 unless T0 --> T1 and F0 --> F1. The requirement that T0 --> T1 1807 is the primary defense against replays of old messages. 1809 2. For timestamp T and filestamp F, F --> T; that is, the filestamp 1810 must happen before the timestamp. If not, this could be due to a 1811 file generation error or a significant error in the system clock 1812 time. 1814 3. For sign key filestamp S, certificate filestamp C, cookie 1815 timestamp D and autokey timestamp A, S --> C --> D --> A; that 1816 is, the autokey must be generated after the cookie, the cookie 1817 after the certificate and the certificate after the sign key. 1819 4. For sign key filestamp S and certificate filestamp C specifying 1820 begin time B and end time E, S --> C--> B --> E; that is, the 1821 valid period must not be retroactive. 1823 5. A certificate for subject S signed by issuer I and with filestamp 1824 C1 obsoletes, but does not necessarily invalidate, another 1825 certificate with the same subject and issuer but with filestamp 1826 C0, where C0 --> C1. 1828 6. A certificate with begin time B and end time E is invalid and can 1829 not be used to verify signatures if t --> B or E --> t, where t 1830 is the current proventic time. Note that the public key 1831 previously extracted from the certificate continues to be valid 1832 for an indefinite time. This raises the interesting possibility 1833 where a truechimer server with expired certificate or a 1834 falseticker with valid certificate are not detected until the 1835 client has synchronized to a proventic source. 1837 Appendix B. Identity Schemes 1839 There are five identity schemes in the NTPv4 reference 1840 implementation: (1) private certificate (PC), (2) trusted certificate 1841 (TC), (3) a modified Schnorr algorithm (IFF - Identify Friend or 1842 Foe), (4) a modified Guillou-Quisquater algorithm (GQ), and (5) a 1843 modified Mu-Varadharajan algorithm (MV). 1845 The PC scheme is intended for testing and development and not 1846 recommended for general use. The TC scheme uses a certificate trail, 1847 but not an identity scheme. The IFF, GQ and MV identity schemes use 1848 a cryptographically strong challenge-response exchange where an 1849 intruder cannot learn the group key, even after repeated observations 1850 of multiple exchanges. These schemes begin when the client sends a 1851 nonce to the server, which then rolls its own nonce, performs a 1852 mathematical operation and sends the results to the client. The 1853 client performs a second mathematical operation to prove the server 1854 has the same group key as the client. 1856 B.1. Private Certificate (PC) Scheme 1858 The PC scheme shown in Figure Figure 12 uses a private certificate as 1859 the group key. 1861 Trusted 1862 Authority 1863 Secure +-------------+ Secure 1864 +--------------| Certificate |-------------+ 1865 | +-------------+ | 1866 | | 1867 \|/ \|/ 1868 +-------------+ +-------------+ 1869 | Certificate | | Certificate | 1870 +-------------+ +-------------+ 1871 Server Client 1873 Figure 12: Private Certificate (PC) Identity Scheme 1875 A certificate is designated private when the X509v3 Extended Key 1876 Usage extension field is present and contains "Private". The private 1877 certificate is distributed to all other group members by secret 1878 means, so in fact becomes a symmetric key. Private certificates are 1879 also trusted, so there is no need for a certificate trail or identity 1880 scheme. 1882 B.2. Trusted Certificate (TC) Scheme 1884 All other schemes involve a conventional certificate trail as shown 1885 in Figure Figure 13. 1887 Trusted 1888 Host Host Host 1889 +-----------+ +-----------+ +-----------+ 1890 +--->| Subject | +--->| Subject | +--->| Subject | 1891 | +-----------+ | +-----------+ | +-----------+ 1892 ...---+ | Issuer |---+ | Issuer |---+ | Issuer | 1893 +-----------+ +-----------+ +-----------+ 1894 | Signature | | Signature | | Signature | 1895 +-----------+ +-----------+ +-----------+ 1897 Figure 13: Trusted Certificate (TC) Identity Scheme 1899 As described in RFC-2510 [9], each certificate is signed by an issuer 1900 one step closer to the trusted host, which has a self-signed trusted 1901 certificate. A certificate is designated trusted when an X509v3 1902 Extended Key Usage extension field is present and contains 1903 "trustRoot". If no identity scheme is specified in the parameter 1904 exchange, this is the default scheme. 1906 B.3. Schnorr (IFF) Identity Scheme 1908 The IFF scheme is useful when the group key is concealed, so that 1909 client keys need not be protected. The primary disacvantage is that 1910 when the server key is refreshed all hosts must update the client 1911 key. The scheme shown in Figure Figure 14 involves a set of public 1912 parameters and a group key including both private and public 1913 components. The public component is the client key. 1915 Trusted 1916 Authority 1917 +------------+ 1918 | Parameters | 1919 Secure +------------+ Insecure 1920 +-------------| Group Key |-----------+ 1921 | +------------+ | 1922 \|/ \|/ 1923 +------------+ Challenge +------------+ 1924 | Parameters |<------------------------| Parameters | 1925 +------------+ +------------+ 1926 | Group Key |------------------------>| Client Key | 1927 +------------+ Response +------------+ 1928 Server Client 1930 Figure 14: Schnorr (IFF) Identity Scheme 1932 By happy coincidence, the mathematical principles on which IFF is 1933 based are similar to DSA. The scheme is a modification an algorithm 1934 described in [11] and [12] p. 285. The parameters are generated by 1935 routines in the OpenSSL library, but only the moduli p, q and 1936 generator g are used. The p is a 512-bit prime, g a generator of the 1937 multiplicative group Z_p* and q a 160-bit prime that divides (p-1) 1938 and is a qth root of 1 mod p; that is, g^q = 1 mod p. The TA rolls a 1939 private random group key b (0 < b < q), then computes public client 1940 key v = g^(q-b) mod p. The TA distributes (p, q, g, b) to all 1941 servers using secure means and (p, q, g, v) to all clients not 1942 necessarily using secure means. 1944 The TA hides IFF parameters and keys in an OpenSSL DSA cuckoo 1945 structure. The IFF parameters are identical to the DSA parameters, 1946 so the OpenSSL library can be used directly. The structure shown in 1947 FigureFigure 15 is written to a file as a DSA private key encoded in 1948 PEM. Unused structure members are set to one. 1950 +----------------------------------+-------------+ 1951 | IFF | DSA | Item | Include | 1952 +=========+==========+=============+=============+ 1953 | p | p | modulus | all | 1954 +---------+----------+-------------+-------------+ 1955 | q | q | modulus | all | 1956 +---------+----------+-------------+-------------+ 1957 | g | g | generator | all | 1958 +---------+----------+-------------+-------------+ 1959 | b | priv_key | group key | server | 1960 +---------+----------+-------------+-------------+ 1961 | v | pub_key | client key | client | 1962 +---------+----------+-------------+-------------+ 1964 Figure 15: IFF Identity Scheme Structure 1966 Alice challenges Bob to confirm identity using the following protocol 1967 exchange. 1969 1. Alice rolls random r (0 < r < q) and sends to Bob. 1971 2. Bob rolls random k (0 < k < q), computes y = k + br mod q and x = 1972 g^k mod p, then sends (y, hash(x)) to Alice. 1974 3. Alice computes z = g^y * v^r mod p and verifies hash(z) equals 1975 hash(x). 1977 If the hashes match, Alice knows that Bob has the group key b. 1979 Besides making the response shorter, the hash makes it effectively 1980 impossible for an intruder to solve for b by observing a number of 1981 these messages. The signed response binds this knowledge to Bob's 1982 private key and the public key previously received in his 1983 certificate. 1985 B.4. Guillard-Quisquater (GQ) Identity Scheme 1987 The GQ scheme is useful when the server key must be refreshed from 1988 time to time without changing the group key. The NTP utility 1989 programs include the GQ client key in the X509v3 Subject Key 1990 Identifier extension field. The primary disadvantage of the scheme 1991 is that the group key must be protected in both the server and 1992 client. A secondary disadvantage is that when a server key is 1993 refreshed, old extension fields no longer work. The scheme is shown 1994 in Figure Figure 16a involves a set of public parameters and group 1995 key used to generate private server keys and client keys. 1997 Trusted 1998 Authority 1999 +------------+ 2000 | Parameters | 2001 Secure +------------+ Secure 2002 +-------------| Group Key |-----------+ 2003 | +------------+ | 2004 \|/ \|/ 2005 +------------+ Challenge +------------+ 2006 | Parameters |<------------------------| Parameters | 2007 +------------+ +------------+ 2008 | Group Key | | Group Key | 2009 +------------+ Response +------------+ 2010 | Server Key |------------------------>| Client Key | 2011 +------------+ +------------+ 2012 Server Client 2014 Figure 16: Schnorr (IFF) Identity Scheme 2016 By happy coincidence, the mathematical principles on which GQ is 2017 based are similar to RSA. The scheme is a modification of an 2018 algorithm described in [13] and [12] p. 300 (with errors). The 2019 parameters are generated by routines in the OpenSSL library, but only 2020 the moduli p and q are used. The 512-bit public modulus is n=pq, 2021 where p and q are secret large primes. The TA rolls random large 2022 prime b (0 < b < n) and distributes (n, b) to all group servers and 2023 clients using secure means, since an intruder in possesion of these 2024 values could impersonate a legitimate server. The private server key 2025 and public client key are constructed later. 2027 The TA hides GQ parameters and keys in an OpenSSL RSA cuckoo 2028 structure. The GQ parameters are identical to the RSA parameters, so 2029 the OpenSSL library can be used directly. When generating a 2030 certificate, the server rolls random server key u (0 < u < n) and 2031 client key its inverse obscured by the group key v = (u^-1)^b mod n. 2032 These values replace the private and public keys normally generated 2033 by the RSA scheme. The client key is conveyed in a X.509 certificate 2034 extension. The updated GQ structure shown in Figure Figure 17 is 2035 written as an RSA private key encoded in PEM. Unused structure 2036 members are set to one. 2038 +---------------------------------+-------------+ 2039 | GQ | RSA | Item | Include | 2040 +=========+==========+============+=============+ 2041 | n | n | modulus | all | 2042 +---------+----------+------------+-------------+ 2043 | b | e | group key | all | 2044 +---------+----------+------------+-------------+ 2045 | u | p | server key | server | 2046 +---------+----------+------------+-------------+ 2047 | v | q | client key | client | 2048 +---------+----------+------------+-------------+ 2050 Figure 17: GQ Identity Scheme Structure 2052 Alice challenges Bob to confirm identity using the following 2053 exchange. 2055 1. Alice rolls random r (0 < r < n) and sends to Bob. 2057 2. Bob rolls random k (0 < k < n) and computes y = ku^r mod n and x 2058 = k^b mod n, then sends (y, hash(x)) to Alice. 2060 3. Alice computes z = (v^r)*(y^b) mod n and verifies hash(z) equals 2061 hash(x). 2063 If the hashes match, Alice knows that Bob has the corresponding 2064 server key u. Besides making the response shorter, the hash makes it 2065 effectively impossible for an intruder to solve for u by observing a 2066 number of these messages. The signed response binds this knowledge 2067 to Bob's private key and the client key previously received in his 2068 certificate. 2070 B.5. Mu-Varadharajan (MV) Identity Scheme 2072 The MV scheme is perhaps the most interesting and flexible of the 2073 three challenge/response schemes, but is devilishly complicated. It 2074 is most useful when a small number of servers provide synchronization 2075 to a large client population where there might be considerable risk 2076 of compromise between and among the servers and clients. The client 2077 population can be partitioned into a modest number of subgroups, each 2078 associated with an individual client key. 2080 The TA generates an intricate cryptosystem involving encryption and 2081 decryption keys, together with a number of activation keys and 2082 associated client keys. The TA can activate and revoke individual 2083 client keys without changing the client keys themselves. The TA 2084 provides to the servers an encryption key E and partial decryption 2085 keys g-bar and g-hat which depend on the activated keys. The servers 2086 have no additional information and, in particular, cannot masquerade 2087 as a TA. In addition, the TA provides to each client j individual 2088 partial decryption keys x-bar_j and x-hat_j, which do not need to be 2089 changed if the TA activates or deactivates any client key. The 2090 clients have no further information and, in particular, cannot 2091 masquerade as a server or TA. 2093 The scheme uses an encryption algorithm similar to El Gamal 2094 cryptography and a polynomial formed from the expansion of product 2095 terms (x-x_1)(x-x_2)(x-x_3)...(x-x_n), as described in [14]. The 2096 paper has significant errors and serious omissions. The cryptosystem 2097 is constructed so that, for every encrytion key E its iniverse is 2098 (g-bar^x-hat_j)(g-hat^x-bar_j) mod p for every j. This remains true 2099 if both quantities are raised to the power k mod p. The difficulty 2100 in finding E is equivalent to the descrete log problem. 2102 The scheme is shown in Figure Figure 18. The TA generates the 2103 parameters, group key, server keys and client keys, one for each 2104 client, all of which must be protected to prevent theft of service. 2105 Note that only the TA has the group key, which is not known to either 2106 the servers or clients. In this sense the MV scheme is a zero- 2107 knowledge proof. 2109 Trusted 2110 Authority 2111 +------------+ 2112 | Parameters | 2113 +------------+ 2114 | Group Key | 2115 +------------+ 2116 | Server Key | 2117 Secure +------------+ Secure 2118 +-------------| Client Key |-----------+ 2119 | +------------+ | 2120 \|/ \|/ 2121 +------------+ Challenge +------------+ 2122 | Parameters |<------------------------| Parameters | 2123 +------------+ +------------+ 2124 | Server Key |------------------------>| Client Key | 2125 +------------+ Response +------------+ 2126 Server Client 2128 Figure 18: Mu-Varadharajan (MV) Identity Scheme 2130 The TA hides MV parameters and keys in OpenSSL DSA cuckoo structures. 2131 The MV parameters are identical to the DSA parameters, so the OpenSSL 2132 library can be used directly. The structure shown in Figures below 2133 are written to files as a DSA private key encoded in PEM. Unused 2134 structure members are set to one. Figure Figure 19 shows the data 2135 structure used by the servers, while Figure Figure 20 shows the 2136 client data structure associated with each activation key. 2138 +---------------------------------+-------------+ 2139 | MV | DSA | Item | Include | 2140 +=========+==========+============+=============+ 2141 | p | p | modulus | all | 2142 +---------+----------+------------+-------------+ 2143 | q | q | modulus | server | 2144 +---------+----------+------------+-------------+ 2145 | E | g | private | server | 2146 | | | encrypt | | 2147 +---------+----------+------------+-------------+ 2148 | g-bar | priv_key | public | server | 2149 | | | decrypt | | 2150 +---------+----------+------------+-------------+ 2151 | g-hat | pub_key | public | server | 2152 | | | decrypt | | 2153 +---------+----------+------------+-------------+ 2154 Figure 19: MV Scheme Server Structure 2156 +---------------------------------+-------------+ 2157 | MV | DSA | Item | Include | 2158 +=========+==========+============+=============+ 2159 | p | p | modulus | all | 2160 +---------+----------+------------+-------------+ 2161 | x-bar_j | priv_key | public | client | 2162 | | | decrypt | | 2163 +---------+----------+------------+-------------+ 2164 | x-hat_j | pub_key | public | client | 2165 | | | decrypt | | 2166 +---------+----------+------------+-------------+ 2168 Figure 20: MV Scheme Client Structure 2170 The devil is in the details, which are beyond the scope of this memo. 2171 The steps in generating the cryptosystem activating the keys and 2172 generating the partial decryption keys are in [15] page 170 ff. 2174 Alice challenges Bob to confirm identity using the following 2175 exchange. 2177 1. Alice rolls random r (0 < r < q) and sends to Bob. 2179 2. Bob rolls random k (0 < k < q) and computes the session 2180 encryption key E-prime = E^k mod p and partial decryption keys 2181 g-bar-prime = g-bar^k mod p and g-hat-prime = g-hat^k mod p. He 2182 encrypts x = E-prime * r mod p and sends (x, g-bar-prime, g-hat- 2183 prime) to Alice. 2185 3. Alice computes the session decryption key E^-1 = (g-bar-prime)^x- 2186 hat_j (g-hat-prime)^x-bar_j mod p and verifies that r = E^-1 x. 2188 Appendix C. ASN.1 Encoding Rules 2190 Certain value fields in request and response messages contain data 2191 encoded in ASN.1 distinguished encoding rules (DER). The BNF grammar 2192 for each encoding rule is given below along with the OpenSSL routine 2193 used for the encoding in the reference implementation. The object 2194 identifiers for the encryption algorithms and message digest/ 2195 signature encryption schemes are specified in [16]. The particular 2196 algorithms required for conformance are not specified in this memo. 2198 C.1. COOKIE request, IFF response, GQ response, MV response 2200 The value field of the COOKIE request message contains a sequence of 2201 two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the 2202 OpenSSL distribution. In the request, n is the RSA modulus in bits 2203 and e is the public exponent. 2205 RSAPublicKey ::= SEQUENCE { 2206 n ::= INTEGER, 2207 e ::= INTEGER 2208 } 2210 The IFF and GQ responses contain a sequence of two integers (r, s) 2211 encoded by the i2d_DSA_SIG() routine in the OpenSSL distribution. In 2212 the responses, r is the challenge response and s is the hash of the 2213 private value. 2215 DSAPublicKey ::= SEQUENCE { 2216 r ::= INTEGER, 2217 s ::= INTEGER 2218 } 2220 The MV response contains a sequence of three integers (p, q, g) 2221 encoded by the i2d_DSAparams() routine in the OpenSSL library. In 2222 the response, p is the hash of the encrypted challenge value and (q, 2223 g) is the client portion of the decryption key. 2225 DSAparameters ::= SEQUENCE { 2226 p ::= INTEGER, 2227 q ::= INTEGER, 2228 g ::= INTEGER 2229 } 2231 C.2. Certificates 2233 Certificate extension fields are used to convey information used by 2234 the identity schemes. While the semantics of these fields generally 2235 conforms with conventional usage, there are subtle variations. The 2236 fields used by Autokey Version 2 include: 2238 o Basic Constraints. This field defines the basic functions of the 2239 certificate. It contains the string "critical,CA:TRUE", which 2240 means the field must be interpreted and the associated private key 2241 can be used to sign other certificates. While included for 2242 compatibility, Autokey makes no use of this field. 2244 o Key Usage. This field defines the intended use of the public key 2245 contained in the certificate. It contains the string 2246 "digitalSignature,keyCertSign", which means the contained public 2247 key can be used to verify signatures on data and other 2248 certificates. While included for compatibility, Autokey makes no 2249 use of this field. 2251 o Extended Key Usage. This field further refines the intended use 2252 of the public key contained in the certificate and is present only 2253 in self-signed certificates. It contains the string "Private" if 2254 the certificate is designated private or the string "trustRoot" if 2255 it is designated trusted. A private certificate is always 2256 trusted. 2258 o Subject Key Identifier. This field contains the client identity 2259 key used in the GQ identity scheme. It is present only if the GQ 2260 scheme is in use. 2262 The value field contains a X509v3 certificate encoded by the 2263 i2d_X509() routine in the OpenSSL distribution. The encoding follows 2264 the rules stated in [10], including the use of X509v3 extension 2265 fields. 2267 Certificate ::= SEQUENCE { 2268 tbsCertificate TBSCertificate, 2269 signatureAlgorithm AlgorithmIdentifier, 2270 signatureValue BIT STRING 2271 } 2273 The signatureAlgorithm is the object identifier of the message 2274 digest/signature encryption scheme used to sign the certificate. The 2275 signatureValue is computed by the certificate issuer using this 2276 algorithm and the issuer private key. 2278 TBSCertificate ::= SEQUENCE { 2279 version EXPLICIT v3(2), 2280 serialNumber CertificateSerialNumber, 2281 signature AlgorithmIdentifier, 2282 issuer Name, 2283 validity Validity, 2284 subject Name, 2285 subjectPublicKeyInfo SubjectPublicKeyInfo, 2286 extensions EXPLICIT Extensions OPTIONAL 2287 } 2289 The serialNumber is an integer guaranteed to be unique for the 2290 generating host. The reference implementation uses the NTP seconds 2291 when the certificate was generated. The signature is the object 2292 identifier of the message digest/signature encryption scheme used to 2293 sign the certificate. It must be identical to the 2294 signatureAlgorithm. 2296 CertificateSerialNumber ::= INTEGER 2297 Validity ::= SEQUENCE { 2298 notBefore UTCTime, 2299 notAfter UTCTime 2300 } 2302 The notBefore and notAfter define the period of validity as defined 2303 in Appendix B. 2305 SubjectPublicKeyInfo ::= SEQUENCE { 2306 algorithm AlgorithmIdentifier, 2307 subjectPublicKey BIT STRING 2308 } 2310 The AlgorithmIdentifier specifies the encryption algorithm for the 2311 subject public key. The subjectPublicKey is the public key of the 2312 subject. 2314 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 2315 Extension ::= SEQUENCE { 2316 extnID OBJECT IDENTIFIER, 2317 critical BOOLEAN DEFAULT FALSE, 2318 extnValue OCTET STRING 2319 } 2321 Name ::= SEQUENCE { 2322 OBJECT IDENTIFIER commonName 2323 PrintableString HostName 2324 } 2326 For trusted host certificates the subject and issuer HostName is the 2327 NTP name of the group, while for all other host certificates the 2328 subject and issuer HostName is the NTP name of the host. In the 2329 reference implementation if these names are not explicitly specified, 2330 they default to the string returned by the Unix gethostname() routine 2331 (trailing NUL removed). For other than self-signed certificates, the 2332 issuer HostName is the unique DNS name of the host signing the 2333 certificate. 2335 Authors' Addresses 2337 Brian Haberman (editor) 2338 The Johns Hopkins University Applied Physics Laboratory 2339 11100 Johns Hopkins Road 2340 Laurel, MD 20723-6099 2341 US 2343 Phone: +1 443 778 1319 2344 Email: brian@innovationslab.net 2346 Dr. David L. Mills 2347 University of Delaware 2348 Newark, DE 19716 2349 US 2351 Phone: +1 302 831 8247 2352 Email: mills@udel.edu 2354 Full Copyright Statement 2356 Copyright (C) The IETF Trust (2008). 2358 This document is subject to the rights, licenses and restrictions 2359 contained in BCP 78, and except as set forth therein, the authors 2360 retain all their rights. 2362 This document and the information contained herein are provided on an 2363 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2364 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2365 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2366 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2367 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2368 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2370 Intellectual Property 2372 The IETF takes no position regarding the validity or scope of any 2373 Intellectual Property Rights or other rights that might be claimed to 2374 pertain to the implementation or use of the technology described in 2375 this document or the extent to which any license under such rights 2376 might or might not be available; nor does it represent that it has 2377 made any independent effort to identify any such rights. Information 2378 on the procedures with respect to rights in RFC documents can be 2379 found in BCP 78 and BCP 79. 2381 Copies of IPR disclosures made to the IETF Secretariat and any 2382 assurances of licenses to be made available, or the result of an 2383 attempt made to obtain a general license or permission for the use of 2384 such proprietary rights by implementers or users of this 2385 specification can be obtained from the IETF on-line IPR repository at 2386 http://www.ietf.org/ipr. 2388 The IETF invites any interested party to bring to its attention any 2389 copyrights, patents or patent applications, or other proprietary 2390 rights that may cover technology that may be required to implement 2391 this standard. Please address the information to the IETF at 2392 ietf-ipr@ietf.org. 2394 Acknowledgment 2396 Funding for the RFC Editor function is provided by the IETF 2397 Administrative Support Activity (IASA).