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