idnits 2.17.1 draft-ietf-ntp-using-nts-for-ntp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 06, 2015) is 3332 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4082 == Outdated reference: A later version (-06) exists of draft-ietf-ntp-cms-for-nts-message-01 == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group D. Sibold 3 Internet-Draft PTB 4 Intended status: Standards Track S. Roettger 5 Expires: September 7, 2015 Google Inc 6 K. Teichel 7 PTB 8 March 06, 2015 10 Using the Network Time Security Specification to Secure the Network Time 11 Protocol 12 draft-ietf-ntp-using-nts-for-ntp-00.txt 14 Abstract 16 This document describes how to use the measures described in the 17 Network Time Security (NTS) specification to secure time 18 synchronization with servers using the Network Time Protocol (NTP). 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 7, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 63 4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4 64 4.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 4 65 4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 4 66 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 4 67 5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 4 68 5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 4 69 5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 6 70 5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 8 72 5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 9 73 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 74 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 75 6.1.1. Association Messages . . . . . . . . . . . . . . . . 9 76 6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 77 6.1.3. Time Synchronization Messages . . . . . . . . . . . . 10 78 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 11 79 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 11 80 6.2.2. Broadcast Time Synchronization Message . . . . . . . 11 81 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 11 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 7.1. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 12 84 7.2. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 12 85 7.3. Supported Hash Algorithms . . . . . . . . . . . . . . . . 12 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 89 9.2. Informative References . . . . . . . . . . . . . . . . . 13 90 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 One of the most popular time synchronization protocols, the Network 96 Time Protocol (NTP) [RFC5905], currently does not provide adequate 97 intrinsic security precautions. The Network Time Security draft 98 [I-D.ietf-ntp-network-time-security] specifies security measures 99 which can be used to enable time synchronization protocols to verify 100 authenticity of the time server and integrity of the time 101 synchronization protocol packets. 103 This document provides detail on how to specifically use those 104 measures to secure time synchronization between NTP clients and 105 servers. 107 2. Objectives 109 The objectives of the NTS specification are as follows: 111 o Authenticity: NTS enables an NTP client to authenticate its time 112 server(s). 114 o Integrity: NTS protects the integrity of NTP time synchronization 115 protocol packets via a message authentication code (MAC). 117 o Confidentiality: NTS does not provide confidentiality protection 118 of the time synchronization packets. 120 o Authorization: NTS optionally enables the server to verify the 121 client's authorization. 123 o Request-Response-Consistency: NTS enables a client to match an 124 incoming response to a request it has sent. NTS also enables the 125 client to deduce from the response whether its request to the 126 server has arrived without alteration. 128 o Modes of operation: Both the unicast and the broadcast mode of NTP 129 are supported. 131 o Hybrid mode: Both secure and insecure communication modes are 132 possible for both NTP servers and clients. 134 o Compatibility: 136 * Unsecured NTP associations are not be affected. 138 * An NTP server that does not support NTS are not affected by 139 NTS-secured authentication requests. 141 3. Terms and Abbreviations 143 MITM Man In The Middle 145 NTP Network Time Protocol [RFC5905] 147 NTS Network Time Security 149 TESLA Timed Efficient Stream Loss-Tolerant Authentication 151 MAC Message Authentication Code 153 HMAC Keyed-Hash Message Authentication Code 155 4. Overview of NTS-Secured NTP 157 4.1. Symmetric and Client/Server Mode 159 The server does not keep a state of the client. NTS applies X.509 160 certificates to verify the authenticity of the time server and to 161 exchange a symmetric key, the so-called cookie. The "association" 162 and "cookie" message exchanges are utilized for this. In subsequent 163 "unicast time synchronization" message exchanges, the cookie is then 164 used to protect authenticity and integrity of NTP unicast time 165 synchronization packets. This is achieved by a MAC attached to each 166 time synchronization packet. 168 4.2. Broadcast Mode 170 After the client has accomplished the necessary initial time 171 synchronization via client-server mode, a "broadcast parameter" 172 message exchange is utilized to communicate the necessary broadcast 173 parameters to the client. Subsequently, "broadcast time 174 synchronization" message exchanges are utilized in combination with 175 optional "broadcast keycheck" exchanges to protect authenticity and 176 integrity of NTP broadcast time synchronization packets. This is 177 also achieved by MACs. 179 5. Protocol Sequence 181 5.1. The Client 183 5.1.1. The Client in Unicast Mode 185 For a unicast run, the client performs the following steps: 187 1. It sends a client_assoc message to the server. It MUST keep the 188 transmitted nonce as well as the values for the version number 189 and algorithms available for later checks. 191 2. It waits for a reply in the form of a server_assoc message. 192 After receipt of the message it performs the following checks: 194 * The client checks that the message contains a conforming 195 version number. 197 * It checks that the nonce sent back by the server matches the 198 one transmitted in client_assoc, 200 * It also verifies that the server has chosen the encryption and 201 hash algorithms from its proposal sent in the client_assoc 202 message and that this proposal was not altered. 204 * Furthermore, it performs authenticity checks on the 205 certificate chain and the signature. 207 If one of the checks fails, the client MUST abort the run. 208 Discussion: 210 Note that by performing the above message exchange and checks, 211 the client validates the authenticity of its immediate NTP 212 server only. It does not recursively validate the 213 authenticity of each NTP server on the time synchronization 214 chain. Recursive authentication (and authorization) as 215 formulated in RFC 7384 [RFC7384] depends on the chosen trust 216 anchor. 218 3. Next it sends a client_cook message to the server. The client 219 MUST save the included nonce until the reply has been processed. 221 4. It awaits a reply in the form of a server_cook message; upon 222 receipt it executes the following actions: 224 * It verifies that the received version number matches the one 225 negotiated beforehand. 227 * It verifies the signature using the server's public key. The 228 signature has to authenticate the encrypted data. 230 * It decrypts the encrypted data with its own private key. 232 * It checks that the decrypted message is of the expected 233 format: the concatenation of a 128 bit nonce and a 128 bit 234 cookie. 236 * It verifies that the received nonce matches the nonce sent in 237 the client_cook message. 239 If one of those checks fails, the client MUST abort the run. 241 5. The client sends a time_request message to the server. The 242 client MUST save the included nonce and the transmit_timestamp 243 (from the time synchronization data) as a correlated pair for 244 later verification steps. 246 6. It awaits a reply in the form of a time_response message. Upon 247 receipt, it checks: 249 * that the transmitted version number matches the one negotiated 250 previously, 252 * that the transmitted nonce belongs to a previous time_request 253 message, 255 * that the transmit_timestamp in that time_request message 256 matches the corresponding time stamp from the synchronization 257 data received in the time_response, and 259 * that the appended MAC verifies the received synchronization 260 data, version number and nonce. 262 If at least one of the first three checks fails (i.e. if the 263 version number does not match, if the client has never used the 264 nonce transmitted in the time_response message, or if it has used 265 the nonce with initial time synchronization data different from 266 that in the response), then the client MUST ignore this 267 time_response message. If the MAC is invalid, the client MUST do 268 one of the following: abort the run or go back to step 5 (because 269 the cookie might have changed due to a server seed refresh). If 270 both checks are successful, the client SHOULD continue time 271 synchronization by repeating the exchange of time_request and 272 time_response messages. 274 The client's behavior in unicast mode is also expressed in Figure 1. 276 5.1.2. The Client in Broadcast Mode 278 To establish a secure broadcast association with a broadcast server, 279 the client MUST initially authenticate the broadcast server and 280 securely synchronize its time with it up to an upper bound for its 281 time offset in unicast mode. After that, the client performs the 282 following steps: 284 1. It sends a client_bpar message to the server. It MUST remember 285 the transmitted values for the nonce, the version number and the 286 signature algorithm. 288 2. It waits for a reply in the form of a server_bpar message after 289 which it performs the following checks: 291 * The message must contain all the necessary information for the 292 TESLA protocol, as specified for a server_bpar message. 294 * The message must contain a nonce belonging to a client_bpar 295 message that the client has previously sent. 297 * Verification of the message's signature. 299 If any information is missing or if the server's signature cannot 300 be verified, the client MUST abort the broadcast run. If all 301 checks are successful, the client MUST remember all the broadcast 302 parameters received for later checks. 304 3. The client awaits time synchronization data in the form of a 305 server_broadcast message. Upon receipt, it performs the 306 following checks: 308 1. Proof that the MAC is based on a key that is not yet 309 disclosed (packet timeliness). This is achieved via a 310 combination of checks. First, the disclosure schedule is 311 used, which requires loose time synchronization. If this is 312 successful, the client obtains a stronger guarantee via a key 313 check exchange: it sends a client_keycheck message and waits 314 for the appropriate response. Note that it needs to memorize 315 the nonce and the time interval number that it sends as a 316 correlated pair. For more detail on both of the mentioned 317 timeliness checks, see [I-D.ietf-ntp-network-time-security]. 318 If its timeliness is verified, the packet will be buffered 319 for later authentication. Otherwise, the client MUST discard 320 it. Note that the time information included in the packet 321 will not be used for synchronization until its authenticity 322 could also be verified. 324 2. The client checks that it does not already know the disclosed 325 key. Otherwise, the client SHOULD discard the packet to 326 avoid a buffer overrun. If verified, the client ensures that 327 the disclosed key belongs to the one-way key chain by 328 applying the one-way function until equality with a previous 329 disclosed key is shown. If it is falsified, the client MUST 330 discard the packet. 332 3. If the disclosed key is legitimate, then the client verifies 333 the authenticity of any packet that it has received during 334 the corresponding time interval. If authenticity of a packet 335 is verified it is released from the buffer and the packet's 336 time information can be utilized. If the verification fails, 337 then authenticity is no longer given. In this case, the 338 client MUST request authentic time from the server by means 339 of a unicast time request message. Also, the client MUST re- 340 initialize the broadcast sequence with a "client_bpar" 341 message if the one-way key chain expires, which it can check 342 via the disclosure schedule. 344 See RFC 4082 [RFC4082] for a detailed description of the packet 345 verification process. 347 The client MUST restart the broadcast sequence with a client_bpar 348 message ([I-D.ietf-ntp-network-time-security]) if the one-way key 349 chain expires. 351 The client's behavior in broadcast mode can also be seen in Figure 2. 353 5.2. The Server 355 5.2.1. The Server in Unicast Mode 357 To support unicast mode, the server MUST be ready to perform the 358 following actions: 360 o Upon receipt of a client_assoc message, the server constructs and 361 sends a reply in the form of a server_assoc message as described 362 in [I-D.ietf-ntp-network-time-security]. 364 o Upon receipt of a client_cook message, the server checks whether 365 it supports the given cryptographic algorithms. It then 366 calculates the cookie according to the formula given in 367 Section 4.1. With this, it MUST construct a server_cook message 368 as described in [I-D.ietf-ntp-network-time-security]. 370 o Upon receipt of a time_request message, the server re-calculates 371 the cookie, then computes the necessary time synchronization data 372 and constructs a time_response message as given in 373 [I-D.ietf-ntp-network-time-security]. 375 The server MUST refresh its server seed periodically (see 376 [I-D.ietf-ntp-network-time-security]). 378 5.2.2. The Server in Broadcast Mode 380 A broadcast server MUST also support unicast mode in order to provide 381 the initial time synchronization, which is a precondition for any 382 broadcast association. To support NTS broadcast, the server MUST 383 additionally be ready to perform the following actions: 385 o Upon receipt of a client_bpar message, the server constructs and 386 sends a server_bpar message as described in 387 [I-D.ietf-ntp-network-time-security]. 389 o Upon receipt of a client_keycheck message, the server looks up 390 whether it has already disclosed the key associated with the 391 interval number transmitted in that message. If it has not 392 disclosed it, it constructs and sends the appropriate 393 server_keycheck message as described in 394 [I-D.ietf-ntp-network-time-security]. For more details, see also 395 [I-D.ietf-ntp-network-time-security]. 397 o The server follows the TESLA protocol in all other aspects, by 398 regularly sending server_broad messages as described in 399 [I-D.ietf-ntp-network-time-security], adhering to its own 400 disclosure schedule. 402 It is also the server's responsibility to watch for the expiration 403 date of the one-way key chain and generate a new key chain 404 accordingly. 406 6. Implementation Notes: ASN.1 Structures and Use of the CMS 408 This section presents some hints about the structures of the 409 communication packets for the different message types when one wishes 410 to implement NTS for NTP. See document 411 [I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes 412 for CMS structures as well as for the ASN.1 structures that are 413 referenced here. 415 6.1. Unicast Messages 417 6.1.1. Association Messages 419 6.1.1.1. Message Type: "client_assoc" 421 This message is realized as an NTP packet with an extension field 422 which holds an "NTS-Plain" archetype CMS structure. This structure 423 contains in its core an NTS message object of the type 424 "ClientAssociationData", which holds all the data necessary for the 425 NTS security mechanisms. 427 6.1.1.2. Message Type: "server_assoc" 429 Like "client_assoc", this message is realized as an NTP packet with 430 an extension field which holds an "NTS-Plain" archetype CMS 431 structure. This structure contains in its core an NTS message object 432 of the type "ServerAssociationData". The latter holds all the data 433 necessary for NTS. 435 6.1.2. Cookie Messages 437 6.1.2.1. Message Type: "client_cook" 439 This message type is realized as an NTP packet with an extension 440 field which holds a CMS structure of archetype "NTS-Certified", 441 containing in its core an NTS message object of the type 442 "ClientCookieData". The latter holds all the data necessary for the 443 NTS security mechanisms. 445 6.1.2.2. Message Type: "server_cook" 447 This message type is realized as an NTP packet with an extension 448 field containing a CMS structure of archetype "NTS-Signed-and- 449 Encrypted". The NTS message object in that structure is a 450 "ServerCookieData" object, which holds all data required by NTS for 451 this message type. 453 6.1.3. Time Synchronization Messages 455 6.1.3.1. Message Type: "time_request" 457 This message type is realized as an NTP packet which actually 458 contains regular NTP time synchronization data, as an unsecured NTP 459 packet from a client to a server would. Furthermore, the packet has 460 an extension field which contains an ASN.1 object of type 461 "TimeRequestSecurityData" (packed in a CMS structure of archetype 462 "NTS-Plain"), whose structure is as follows: 464 6.1.3.2. Message Type: "time_response" 466 This message is also realized as an NTP packet with regular NTP time 467 synchronization data. The packet also has an extension field which 468 contains an ASN.1 object of type "TimeResponseSecurityData". 469 Finally, this NTP packet has a MAC field which contains a Message 470 Authentication Code generated over the whole packet (including the 471 extension field). 473 6.2. Broadcast Messages 475 6.2.1. Broadcast Parameter Messages 477 6.2.1.1. Message Type: "client_bpar" 479 This first broadcast message is realized as an NTP packet which is 480 empty except for an extension field which contains an ASN.1 object of 481 type "BroadcastParameterRequest" (packed in a CMS structure of 482 archetype "CMS-Plain"). This is sufficient to transport all data 483 specified by NTS. 485 6.2.1.2. Message Type: "server_bpar" 487 This message type is realized as an NTP packet whose extension field 488 carries the necessary CMS structure (archetype: "NTS-Signed"). The 489 NTS message object in this case is an ASN.1 object of type 490 "BroadcastParameterResponse". 492 6.2.2. Broadcast Time Synchronization Message 494 6.2.2.1. Message Type: "server_broad" 496 This message's realization works via an NTP packet which carries 497 regular NTP broadcast time data as well as an extension field, which 498 contains an ASN.1 object of type "BroadcastTime" (packed in a CMS 499 structure with archetype "NTS-Plain"). In addition to all this, this 500 packet has a MAC field which contains a Message Authentication Code 501 generated over the whole packet (including the extension field). 503 6.2.3. Broadcast Keycheck 505 6.2.3.1. Message Type: "client_keycheck" 507 This message is realized as an NTP packet with an extension field, 508 which transports a CMS structure of archetype "NTS-Plain", containing 509 an ASN.1 object of type "ClientKeyCheckSecurityData". 511 6.2.3.2. Message Type: "server_keycheck" 513 This message is also realized as an NTP packet with an extension 514 field, which contains an ASN.1 object of type 515 "ServerKeyCheckSecurityData" (packed in a CMS structure of archetype 516 "NTS-Plain"). Additionally, this NTP packet has a MAC field which 517 contains a Message Authentication Code generated over the whole 518 packet (including the extension field). 520 7. Security Considerations 522 7.1. Usage of NTP Pools 524 The certification-based authentication scheme described in 525 [I-D.ietf-ntp-network-time-security] is not applicable to the concept 526 of NTP pools. Therefore, NTS is unable to provide secure usage of 527 NTP pools. 529 7.2. Server Seed Lifetime 531 tbd 533 7.3. Supported Hash Algorithms 535 The list of the hash algorithms supported by the server has to 536 fulfill the following requirements: 538 o it MUST NOT include SHA-1 or weaker algorithms, 540 o it MUST include SHA-256 or stronger algorithms. 542 8. Acknowledgements 544 The authors would like to thank Russ Housley, Steven Bellovin, David 545 Mills and Kurt Roeckx for discussions and comments on the design of 546 NTS. Also, thanks to Harlan Stenn for his technical review and 547 specific text contributions to this document. 549 9. References 551 9.1. Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 557 Briscoe, "Timed Efficient Stream Loss-Tolerant 558 Authentication (TESLA): Multicast Source Authentication 559 Transform Introduction", RFC 4082, June 2005. 561 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 562 Time Protocol Version 4: Protocol and Algorithms 563 Specification", RFC 5905, June 2010. 565 9.2. Informative References 567 [I-D.ietf-ntp-cms-for-nts-message] 568 Sibold, D., Roettger, S., Teichel, K., and R. Housley, 569 "Protecting Network Time Security Messages with the 570 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 571 for-nts-message-01 (work in progress), January 2015. 573 [I-D.ietf-ntp-network-time-security] 574 Sibold, D., Roettger, S., and K. Teichel, "Network Time 575 Security", draft-ietf-ntp-network-time-security-07 (work 576 in progress), March 2015. 578 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 579 Packet Switched Networks", RFC 7384, October 2014. 581 Appendix A. Flow Diagrams of Client Behaviour 582 +---------------------+ 583 |Association Messages | 584 +----------+----------+ 585 | 586 +------------------------------>o 587 | | 588 | v 589 | +---------------+ 590 | |Cookie Messages| 591 | +-------+-------+ 592 | | 593 | o<------------------------------+ 594 | | | 595 | v | 596 | +-------------------+ | 597 | |Time Sync. Messages| | 598 | +---------+---------+ | 599 | | | 600 | v | 601 | +-----+ | 602 | |Check| | 603 | +--+--+ | 604 | | | 605 | /------------------+------------------\ | 606 | v v v | 607 | .-----------. .-------------. .-------. | 608 | ( MAC Failure ) ( Nonce Failure ) ( Success ) | 609 | '-----+-----' '------+------' '---+---' | 610 | | | | | 611 | v v v | 612 | +-------------+ +-------------+ +--------------+ | 613 | |Discard Data | |Discard Data | |Sync. Process | | 614 | +-------------+ +------+------+ +------+-------+ | 615 | | | | | 616 | | | v | 617 +-----------+ +------------------>o-----------+ 619 Figure 1: The client's behavior in NTS unicast mode. 621 +-----------------------------+ 622 |Broadcast Parameter Messages | 623 +--------------+--------------+ 624 | 625 o<--------------------------+ 626 | | 627 v | 628 +-----------------------------+ | 629 |Broadcast Time Sync. Message | | 630 +--------------+--------------+ | 631 | | 632 +-------------------------------------->o | 633 | | | 634 | v | 635 | +-------------------+ | 636 | |Key and Auth. Check| | 637 | +---------+---------+ | 638 | | | 639 | /----------------*----------------\ | 640 | v v | 641 | .---------. .---------. | 642 | ( Verified ) ( Falsified ) | 643 | '----+----' '----+----' | 644 | | | | 645 | v v | 646 | +-------------+ +-------+ | 647 | |Store Message| |Discard| | 648 | +------+------+ +---+---+ | 649 | | | | 650 | v +---------o 651 | +---------------+ | 652 | |Check Previous | | 653 | +-------+-------+ | 654 | | | 655 | /--------*--------\ | 656 | v v | 657 | .---------. .---------. | 658 | ( Verified ) ( Falsified ) | 659 | '----+----' '----+----' | 660 | | | | 661 | v v | 662 | +-------------+ +-----------------+ | 663 | |Sync. Process| |Discard Previous | | 664 | +------+------+ +--------+--------+ | 665 | | | | 666 +-----------+ +-----------------------------------+ 668 Figure 2: The client's behaviour in NTS broadcast mode. 670 Authors' Addresses 672 Dieter Sibold 673 Physikalisch-Technische Bundesanstalt 674 Bundesallee 100 675 Braunschweig D-38116 676 Germany 678 Phone: +49-(0)531-592-8420 679 Fax: +49-531-592-698420 680 Email: dieter.sibold@ptb.de 682 Stephen Roettger 683 Google Inc 685 Email: stephen.roettger@googlemail.com 687 Kristof Teichel 688 Physikalisch-Technische Bundesanstalt 689 Bundesallee 100 690 Braunschweig D-38116 691 Germany 693 Phone: +49-(0)531-592-8421 694 Email: kristof.teichel@ptb.de