idnits 2.17.1 draft-ietf-ntp-network-time-security-05.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 abstract seems to contain references ([RFC7384]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2014) is 3473 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-ntp-cms-for-nts-messages' is mentioned on line 263, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 4082 ** Obsolete normative reference: RFC 6277 (Obsoleted by RFC 6960) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: April 26, 2015 Google Inc 6 K. Teichel 7 PTB 8 October 23, 2014 10 Network Time Security 11 draft-ietf-ntp-network-time-security-05.txt 13 Abstract 15 This document describes the Network Time Security (NTS) protocol that 16 enables secure time synchronization with time servers using Network 17 Time Protocol (NTP) or Precision Time Protocol (PTP). Its design 18 considers the special requirements of precise timekeeping, which are 19 described in Security Requirements of Time Protocols in Packet 20 Switched Networks [RFC7384]. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 26, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Security Threats . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 66 5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 5 68 5.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 5 69 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. Association Messages . . . . . . . . . . . . . . . . . . 6 71 6.1.1. Message Type: "client_assoc" . . . . . . . . . . . . 7 72 6.1.2. Message Type: "server_assoc" . . . . . . . . . . . . 7 73 6.2. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 8 74 6.2.1. Message Type: "client_cook" . . . . . . . . . . . . . 8 75 6.2.2. Message Type: "server_cook" . . . . . . . . . . . . . 8 76 6.3. Unicast Time Synchronisation Messages . . . . . . . . . . 9 77 6.3.1. Message Type: "time_request" . . . . . . . . . . . . 9 78 6.3.2. Message Type: "time_response" . . . . . . . . . . . . 9 79 6.4. Broadcast Parameter Messages . . . . . . . . . . . . . . 10 80 6.4.1. Message Type: "client_bpar" . . . . . . . . . . . . . 10 81 6.4.2. Message Type: "server_bpar" . . . . . . . . . . . . . 10 82 6.5. Broadcast Messages . . . . . . . . . . . . . . . . . . . 11 83 6.5.1. Message Type: "server_broad" . . . . . . . . . . . . 11 84 6.6. Broadcast Key Check . . . . . . . . . . . . . . . . . . . 11 85 6.6.1. Message Type: "client_keycheck" . . . . . . . . . . . 11 86 6.6.2. Message Type: "server_keycheck" . . . . . . . . . . . 12 87 7. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 12 88 7.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 12 90 7.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 14 91 7.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 16 93 7.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 16 94 8. Server Seed Considerations . . . . . . . . . . . . . . . . . 17 95 8.1. Server Seed Refresh . . . . . . . . . . . . . . . . . . . 17 96 8.2. Server Seed Algorithm . . . . . . . . . . . . . . . . . . 17 97 8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 17 98 9. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 17 99 9.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 17 100 9.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 18 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 103 11.1. Initial Verification of the Server Certificates . . . . 18 104 11.2. Revocation of Server Certificates . . . . . . . . . . . 18 105 11.3. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 19 106 11.4. Denial-of-Service in Broadcast Mode . . . . . . . . . . 19 107 11.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 19 108 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 111 13.2. Informative References . . . . . . . . . . . . . . . . . 21 112 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 22 113 Appendix B. TICTOC Security Requirements . . . . . . . . . . . . 24 114 Appendix C. Broadcast Mode . . . . . . . . . . . . . . . . . . . 25 115 C.1. Server Preparations . . . . . . . . . . . . . . . . . . . 25 116 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 27 117 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 27 118 C.4. Authentication of Received Packets . . . . . . . . . . . 28 119 Appendix D. Random Number Generation . . . . . . . . . . . . . . 29 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 122 1. Introduction 124 Time synchronization protocols are increasingly utilized to 125 synchronize clocks in networked infrastructures. The reliable 126 performance of such infrastructures can be degraded seriously by 127 successful attacks against the time synchronization protocol. 128 Therefore, time synchronization protocols have to be secured if they 129 are applied in environments that are prone to malicious attacks. 130 This can be accomplished by utilization of external security 131 protocols like IPsec or by intrinsic security measures of the time 132 synchronization protocol. 134 The two most popular time synchronization protocols, the Network Time 135 Protocol (NTP) [RFC5905] and the Precision Time Protocol (PTP) 136 [IEEE1588], currently do not provide adequate intrinsic security 137 precautions. This document specifies security measures for NTP and 138 PTP which enable these protocols to verify authenticity of the time 139 server and integrity of the time synchronization protocol packets. 141 The protocol is specified with the prerequisite in mind that precise 142 timekeeping can only be accomplished with stateless time 143 synchronization communication, which excludes the utilization of 144 standard security protocols like IPsec or TLS for time 145 synchronization messages. This prerequisite corresponds with the 146 requirement that a security mechanism for timekeeping must be 147 designed in such a way that it does not degrade the quality of the 148 time transfer [RFC7384]. 150 Note: 152 The intent is to formulate the protocol to be applicable to NTP 153 and also PTP. In the current state the specification focuses on 154 the application to NTP. 156 2. Security Threats 158 A profound analysis of security threats and requirements for NTP and 159 PTP can be found in the "Security Requirements of Time Protocols in 160 Packet Switched Networks" [RFC7384]. 162 3. Objectives 164 The objectives of the NTS specification are as follows: 166 o Authenticity: NTS enables the client to authenticate its time 167 servers. 169 o Integrity: NTS protects the integrity of time synchronization 170 protocol packets via a message authentication code (MAC). 172 o Confidentiality: NTS does not provide confidentiality protection 173 of the time synchronization packets. 175 o Modes of operation: All operational modes of NTP are supported. 177 o Operational modes of PTP should be supported as far as possible. 179 o Hybrid mode: Both secure and insecure communication modes are 180 possible for NTP servers and clients, respectively. 182 o Compatibility: 184 * Unsecured NTP associations shall not be affected. 186 * An NTP server that does not support NTS shall not be affected 187 by NTS authentication requests. 189 4. Terms and Abbreviations 191 MITM Man In The Middle 193 NTP Network Time Protocol [RFC5905] 195 NTS Network Time Security 197 PTP Precision Time Protocol [IEEE1588] 199 TESLA Timed Efficient Stream Loss-Tolerant Authentication 201 5. NTS Overview 203 5.1. Symmetric and Client/Server Mode 205 NTS applies X.509 certificates to verify the authenticity of the time 206 server and to exchange a symmetric key, the so-called cookie. This 207 cookie is then used to protect authenticity and integrity of the 208 subsequent time synchronization packets by means of a Message 209 Authentication Code (MAC), which is attached to each time 210 synchronization packet. The calculation of the MAC includes the 211 whole time synchronization packet and the cookie which is shared 212 between client and server. The cookie is calculated according to: 214 cookie = MSB_128 (HMAC(server seed, H(certificate of client))), 216 with the server seed as key, where H is a hash function, and where 217 the function MSB_128 cuts off the 128 most significant bits of the 218 result of the HMAC function. The server seed is a 128 bit random 219 value of the server, which has to be kept secret. The cookie never 220 changes as long as the server seed stays the same, but the server 221 seed has to be refreshed periodically in order to provide key 222 freshness as required in [RFC7384]. See Section 8 for details on the 223 seed refresh and Section 7.1.1 for the client's reaction to it. 225 The server does not keep a state of the client. Therefore it has to 226 recalculate the cookie each time it receives a request from the 227 client. To this end, the client has to attach the hash value of its 228 certificate to each request (see Section 6.3). 230 5.2. Broadcast Mode 232 Just as in the case of the client server mode and symmetric mode, 233 authenticity and integrity of the NTP packets are ensured by a MAC, 234 which is attached to the NTP packet by the sender. Verification of 235 the packets' authenticity is based on the TESLA protocol, in 236 particular on its "not re-using keys" scheme, see section 3.7.2 of 238 [RFC4082]. TESLA uses a one-way chain of keys, where each key is the 239 output of a one-way function applied to the previous key in the 240 chain. The last element of the chain is shared securely with all 241 clients. The server splits time into intervals of uniform duration 242 and assigns each key to an interval in reverse order, starting with 243 the penultimate. At each time interval, the server sends an NTP 244 broadcast packet appended by a MAC, calculated using the 245 corresponding key, and the key of the previous disclosure interval. 246 The client verifies the MAC by buffering the packet until the 247 disclosure of the key in its associated disclosure interval. In 248 order to be able to verify the validity of the key, the client has to 249 be loosely time synchronized to the server. This has to be 250 accomplished during the initial client server exchange between 251 broadcast client and server. In addition, NTS uses another, more 252 rigorous check to what is used in the TESLA protocol. For a more 253 detailed description of how NTS employs and customizes TESLA, see 254 Appendix C. 256 6. Protocol Messages 258 This section describes the types of messages needed for secure time 259 synchronization with NTS. 261 For some guidance on how these message types can be realized in 262 practice, for use with existing time synchronization protocols, see 263 [I-D.ietf-ntp-cms-for-nts-messages], a companion document for NTS. 264 Said document describes ASN.1 encodings for those message parts that 265 have to be added to a time synchronization protocol for security 266 reasons as well as CMS (Cryptographic Message Syntax, see [RFC5652]) 267 conventions that can be used to get the cryptographic aspects right. 269 Note that currently, the companion document describes realizations of 270 NTS messages only for utilization with NTP, in which the NTS specific 271 data are enclosed in extension fields on top of NTP packets. A 272 specification of NTS messages for PTP will have to be developed 273 accordingly. 275 The steps described in Section 6.1 - Section 6.3 belong to the 276 unicast mode, while Section 6.4 and Section 6.5 explain the steps 277 involved in the broadcast mode of NTS. 279 6.1. Association Messages 281 In this message exchange, the hash and encryption algorithms that are 282 used throughout the protocol are negotiated. Also, the client 283 receives the certification chain up to a trusted anchor. With the 284 established certification chain the client is able to verify the 285 server's signatures and, hence, authenticity of future NTS messages 286 from the server is ensured. 288 6.1.1. Message Type: "client_assoc" 290 The protocol sequence starts with the client sending an association 291 message, called client_assoc. This message contains 293 o the NTS message ID "client_assoc", 295 o the version number of NTS that the client wants to use (this 296 SHOULD be the highest version number that it supports), 298 o the hostname of the client, 300 o a selection of accepted hash algorithms, and 302 o a selection of accepted encryption algorithms. 304 6.1.2. Message Type: "server_assoc" 306 This message is sent by the server upon receipt of client_assoc. It 307 contains 309 o the NTS message ID "server_assoc", 311 o the version number used for the rest of the protocol (which SHOULD 312 be determined as the minimum over the client's suggestion in the 313 client_assoc message and the highest supported by the server), 315 o the hostname of the server, and 317 o the server's choice of algorithm for encryption and for 318 cryptographic hashing, all of which MUST be chosen from the 319 client's proposals. 321 o a signature, calculated over the data listed above, with the 322 server's private key and according to the signature algorithm 323 which is also used for the certificates which are included (see 324 below), 326 o a chain of certificates, which starts at the server and goes up to 327 a trusted authority, and each certificate MUST be certified by the 328 one directly following it. 330 6.2. Cookie Messages 332 During this message exchange, the server transmits a secret cookie to 333 the client securely. The cookie will be used for integrity 334 protection during unicast time synchronization. 336 6.2.1. Message Type: "client_cook" 338 This message is sent by the client, upon successful authentication of 339 the server. In this message, the client requests a cookie from the 340 server. The message contains 342 o the NTS message ID "client_cook", 344 o the negotiated version number, 346 o the negotiated signature algorithm, 348 o the negotiated encryption algorithm, 350 o a 128-bit nonce, 352 o the negotiated hash algorithm H, 354 o the client's certificate. 356 6.2.2. Message Type: "server_cook" 358 This message is sent by the server, upon receipt of a client_cook 359 message. The server generates the hash of the client's certificate, 360 as conveyed during client_cook, in order to calculate the cookie 361 according to Section 5.1. This message contains 363 o the NTS message ID "server_cook" 365 o the version number as transmitted in client_cook, 367 o a concatenated datum, which is encrypted with the client's public 368 key, according to the encryption algorithm transmitted in the 369 client_cook message. The concatenated datum contains 371 * the nonce transmitted in client_cook, and 373 * the cookie. 375 o a signature, created with the server's private key, calculated 376 over all of the data listed above. This signature MUST be 377 calculated according to the transmitted signature algorithm from 378 the client_cook message. 380 6.3. Unicast Time Synchronisation Messages 382 In this message exchange, the usual time synchronization process is 383 executed, with the addition of integrity protection for all messages 384 that the server sends. This message can be repeatedly exchanged as 385 often as the client desires and as long as the integrity of the 386 server's time responses is verified successfully. 388 6.3.1. Message Type: "time_request" 390 This message is sent by the client when it requests time exchange. 391 It contains 393 o the NTS message ID "time_request", 395 o the negotiated version number, 397 o a 128-bit nonce, 399 o the negotiated hash algorithm H, 401 o the hash of the client's certificate under H. 403 6.3.2. Message Type: "time_response" 405 This message is sent by the server, after it received a time_request 406 message. Prior to this the server MUST recalculate the client's 407 cookie by using the hash of the client's certificate and the 408 transmitted hash algorithm. The message contains 410 o the NTS message ID "time_response", 412 o the version number as transmitted in time_request, 414 o the server's time synchronization response data, 416 o the 128-bit nonce transmitted in time_request, 418 o a MAC (generated with the cookie as key) for verification of all 419 of the above data. 421 6.4. Broadcast Parameter Messages 423 In this message exchange, the client receives the necessary 424 information to execute the TESLA protocol in a secured broadcast 425 association. The client can only initiate a secure broadcast 426 association after a successful unicast run, see Section 7.1.2. 428 See Appendix C for more details on TESLA. 430 6.4.1. Message Type: "client_bpar" 432 This message is sent by the client in order to establish a secured 433 time broadcast association with the server. It contains 435 o the NTS message ID "client_bpar", 437 o the version number negotiated during association in unicast mode, 439 o the client's hostname, and 441 o the signature algorithm negotiated during unicast. 443 6.4.2. Message Type: "server_bpar" 445 This message is sent by the server upon receipt of a client_bpar 446 message during the broadcast loop of the server. It contains 448 o the NTS message ID "server_bpar", 450 o the version number as transmitted in the client_bpar message, 452 o the one-way functions used for building the key chain, and 454 o the disclosure schedule of the keys. This contains: 456 * the last key of the key chain, 458 * time interval duration, 460 * the disclosure delay (number of intervals between use and 461 disclosure of a key), 463 * the time at which the next time interval will start, and 465 * the next interval's associated index. 467 o The message also contains a signature signed by the server with 468 its private key, verifying all the data listed above. 470 6.5. Broadcast Messages 472 Via this message, the server keeps sending broadcast time 473 synchronization messages to all participating clients. 475 6.5.1. Message Type: "server_broad" 477 This message is sent by the server over the course of its broadcast 478 schedule. It is part of any broadcast association. It contains 480 o the NTS message ID "server_broad", 482 o the version number that the server's broadcast mode is working 483 under, 485 o time broadcast data, 487 o the index that belongs to the current interval (and therefore 488 identifies the current, yet undisclosed key), 490 o the disclosed key of the previous disclosure interval (current 491 time interval minus disclosure delay), 493 o a MAC, calculated with the key for the current time interval, 494 verifying 496 * the message ID, 498 * the version number, and 500 * the time data. 502 6.6. Broadcast Key Check 504 This message exchange is performed for an additional check of packet 505 timeliness in the course of the TESLA scheme, see Appendix C. 507 6.6.1. Message Type: "client_keycheck" 509 A message of this type is sent by the client in order to initiate an 510 additional check of packet timeliness for the TESLA scheme. It 511 contains 513 o the NTS message ID "client_keycheck", 515 o the version number chosen for the broadcast, 517 o a 128-bit nonce, 518 o an interval number from the TESLA disclosure schedule, 520 o the hash algorithm H negotiated in unicast mode, and 522 o the hash of the client's certificate under H. 524 6.6.2. Message Type: "server_keycheck" 526 A message of this type is sent by the server upon receipt of a 527 client_keycheck message during the broadcast loop of the server. 528 Prior to this the server MUST recalculate the client's cookie by 529 using the hash of the client's certificate and the transmitted hash 530 algorithm. It contains 532 o the NTS message ID "server_keycheck" 534 o the version number that the server's broadcast mode is working 535 under, 537 o the 128-bit nonce transmitted in the client_keycheck message, 539 o the interval number transmitted in the client_keycheck message, 540 and 542 o a MAC (generated with the cookie as key) for verification of all 543 of the above data. 545 7. Protocol Sequence 547 7.1. The Client 549 7.1.1. The Client in Unicast Mode 551 For a unicast run, the client performs the following steps: 553 1. It sends a client_assoc message to the server. It MUST keep the 554 transmitted values for version number and algorithms available 555 for later checks. 557 2. It waits for a reply in the form of a server_assoc message. 558 After receipt of the message it performs the following checks: 560 * The client checks that the message contains a conform version 561 number. 563 * It also verifies that the server has chosen the encryption and 564 hash algorithms from its proposal sent in the client_assoc 565 message. 567 * Furthermore, it performs authenticity checks on the 568 certificate chain and the signature for the version number. 570 If one of the checks fails, the client MUST abort the run. 571 Discussion: 573 Note that by performing the above message exchange and checks, 574 the client validates the authenticity of its immediate NTP 575 server only. It does not recursively validate the 576 authenticity of each NTP server on the time synchronization 577 chain. Recursive authentication (and authorization) as 578 formulated in [RFC7384] depends on the chosen trust anchor. 580 3. Next, it sends a client_cook message to the server. The client 581 MUST save the included nonce until the reply has been processed. 583 4. It awaits a reply in the form of a server_cook message; upon 584 receipt it executes the following actions: 586 * It verifies that the received version number matches the one 587 negotiated before. 589 * It verifies the signature using the server's public key. The 590 signature has to authenticate the encrypted data. 592 * It decrypts the encrypted data with its own private key. 594 * It checks that the decrypted message is of the expected 595 format: the concatenation of a 128 bit nonce and a 128 bit 596 cookie. 598 * It verifies that the received nonce matches the nonce sent in 599 the client_cook message. 601 If one of those checks fails, the client MUST abort the run. 603 5. The client sends a time_request message to the server. The 604 client MUST save the included nonce and the transmit_timestamp 605 (from the time synchronization data) as a correlated pair for 606 later verification steps. 608 6. It awaits a reply in the form of a time_response message. Upon 609 receipt, it checks: 611 * that the transmitted version number matches the one negotiated 612 before, 614 * that the transmitted nonce belongs to a previous time_request 615 message, 617 * that the transmit_timestamp in that time_request message 618 matches the corresponding time stamp from the synchronization 619 data received in the time_response, and 621 * that the appended MAC verifies the received synchronization 622 data, version number and nonce. 624 If at least one of the first three checks fails (i.e. if the 625 version number does not match, if the client has never used the 626 nonce transmitted in the time_response message or if it has used 627 the nonce with initial time synchronization data different from 628 that in the response), then the client MUST ignore this 629 time_response message. If the MAC is invalid, the client MUST do 630 one of the following: abort the run or go back to step 5 (because 631 the cookie might have changed due to a server seed refresh). If 632 both checks are successful, the client SHOULD continue time 633 synchronization by going back to step 7. 635 The client's behavior in unicast mode is also expressed in Figure 1. 637 7.1.2. The Client in Broadcast Mode 639 To establish a secure broadcast association with a broadcast server, 640 the client MUST initially authenticate the broadcast server and 641 securely synchronize its time to it up to an upper bound for its time 642 offset in unicast mode. After that, the client performs the 643 following steps: 645 1. It sends a client_bpar message to the server. It MUST remember 646 the transmitted values for version number and signature 647 algorithm. 649 2. It waits for a reply in the form of a server_bpar message after 650 which it performs the following checks: 652 * The message must contain all the necessary information for the 653 TESLA protocol, as listed in Section 6.4.2. 655 * Verification of the message's signature. 657 If any information is missing or the server's signature cannot be 658 verified, the client MUST abort the broadcast run. If all checks 659 are successful, the client MUST remember all the broadcast 660 parameters received for later checks. 662 3. The client awaits time synchronization data in the form of a 663 server_broadcast message. Upon receipt, it performs the 664 following checks: 666 1. Proof that the MAC is based on a key that is not yet 667 disclosed (packet timeliness). This is achieved via a 668 combination of checks. First the disclosure schedule is 669 used, which requires the loose time synchronization. If this 670 is successful, the client gets a stronger guarantee via a key 671 check exchange: it sends a client_keycheck message and waits 672 for the appropriate response. Note that it needs to memorize 673 the nonce and the time interval number that it sends as a 674 correlated pair. For more detail on both of the mentioned 675 timeliness checks, see Appendix Appendix C.4. If its 676 timeliness is verified, the packet will be buffered for later 677 authentication. Otherwise, the client MUST discard it. Note 678 that the time information included in the packet will not be 679 used for synchronization until its authenticity could also be 680 verified. 682 2. The client checks that it does not already know the disclosed 683 key. Otherwise, the client SHOULD discard the packet to 684 avoid a buffer overrun. If verified, the client ensures that 685 the disclosed key belongs to the one-way key chain by 686 applying the one-way function until equality with a previous 687 disclosed key is shown. If falsified, the client MUST 688 discard the packet. 690 3. If the disclosed key is legitimate, then the client verifies 691 the authenticity of any packet that it received during the 692 corresponding time interval. If authenticity of a packet is 693 verified it is released from the buffer and the packet's time 694 information can be utilized. If the verification fails, then 695 authenticity is no longer given. In this case the client 696 MUST request authentic time from the server by means of a 697 unicast time request message. 699 See RFC 4082[RFC4082] for a detailed description of the packet 700 verification process. 702 The client MUST restart the broadcast sequence with a client_bpar 703 message Section 6.4.1 if the one-way key chain expires. 705 The client's behavior in broadcast mode can also be seen in Figure 2. 707 7.2. The Server 709 7.2.1. The Server in Unicast Mode 711 To support unicast mode, the server MUST be ready to perform the 712 following actions: 714 o Upon receipt of a client_assoc message, the server constructs and 715 sends a reply in the form of a server_assoc message as described 716 in Section 6.1.2. 718 o Upon receipt of a client_cook message, the server checks whether 719 it supports the given cryptographic algorithms. It then 720 calculates the cookie according to the formula given in 721 Section 5.1. With this, it MUST construct a server_cook message 722 as described in Section 6.2.2. 724 o Upon receipt of a time_request message, the server re-calculates 725 the cookie, then computes the necessary time synchronization data 726 and constructs a time_response message as given in Section 6.3.2. 728 The server MUST refresh its server seed periodically (see 729 Section 8.1). 731 7.2.2. The Server in Broadcast Mode 733 A broadcast server MUST also support unicast mode, in order to 734 provide the initial time synchronization which is a precondition for 735 any broadcast association. To support NTS broadcast, the server MUST 736 additionally be ready to perform the following actions: 738 o Upon receipt of a client_bpar message, the server constructs and 739 sends a server_bpar message as described in Section 6.4.2. 741 o Upon receipt of a client_keycheck message, the server looks up if 742 it has already disclosed the key associated with the interval 743 number transmitted in that message. If it has not disclosed it, 744 it constructs and sends the appropriate server_keycheck message as 745 described in Section 6.6.2. For more detail, see also Appendix C. 747 o The server follows the TESLA protocol in all other aspects, by 748 regularly sending server_broad messages as described in 749 Section 6.5.1, adhering to its own disclosure schedule. 751 It is also the server's responsibility to watch for the expiration 752 date of the one-way key chain and generate a new key chain 753 accordingly. 755 8. Server Seed Considerations 757 The server has to calculate a random seed which has to be kept 758 secret. The server MUST generate a seed for each supported hash 759 algorithm, see Section 9.1. 761 8.1. Server Seed Refresh 763 According to the requirements in [RFC7384] the server MUST refresh 764 each server seed periodically. As a consequence, the cookie 765 memorized by the client becomes obsolete. In this case the client 766 cannot verify the MAC attached to subsequent time response messages 767 and has to respond accordingly by re-initiating the protocol with a 768 cookie request (Section 6.2). 770 8.2. Server Seed Algorithm 772 8.3. Server Seed Lifetime 774 9. Hash Algorithms and MAC Generation 776 9.1. Hash Algorithms 778 Hash algorithms are used at different points: calculation of the 779 cookie and the MAC, and hashing of the client's certificate. Client 780 and server negotiate a hash algorithm H during the association 781 message exchange (Section 6.1) at the beginning of a unicast run. 782 The selected algorithm H is used for all hashing processes in that 783 run. 785 In broadcast mode, hash algorithms are used as pseudo random 786 functions to construct the one-way key chain. Here, the utilized 787 hash algorithm is communicated by the server and non-negotiable. 789 The list of the hash algorithms supported by the server has to 790 fulfill the following requirements: 792 o it MUST NOT include SHA-1 or weaker algorithms, 794 o it MUST include SHA-256 or stronger algorithms. 796 Note 798 Any hash algorithm is prone to be compromised in the future. A 799 successful attack on a hash algorithm would enable any NTS client 800 to derive the server seed from their own cookie. Therefore, the 801 server MUST have separate seed values for its different supported 802 hash algorithms. This way, knowledge gained from an attack on a 803 hash algorithm H can at least only be used to compromise such 804 clients who use hash algorithm H as well. 806 9.2. MAC Calculation 808 For the calculation of the MAC, client and server are using a Keyed- 809 Hash Message Authentication Code (HMAC) approach [RFC2104]. The HMAC 810 is generated with the hash algorithm specified by the client (see 811 Section 9.1). 813 10. IANA Considerations 815 11. Security Considerations 817 11.1. Initial Verification of the Server Certificates 819 The client has to verify the validity of the certificates during the 820 certification message exchange (Section 6.1.2). Since it generally 821 has no reliable time during this initial communication phase, it is 822 impossible to verify the period of validity of the certificates. 823 Therefore, the client MUST use one of the following approaches: 825 o The validity of the certificates is preconditioned. Usually this 826 will be the case in corporate networks. 828 o The client ensures that the certificates are not revoked. To this 829 end, the client uses the Online Certificate Status Protocol (OCSP) 830 defined in [RFC6277]. 832 o The client requests a different service to get an initial time 833 stamp in order to be able to verify the certificates' periods of 834 validity. To this end, it can, e.g., use a secure shell 835 connection to a reliable host. Another alternative is to request 836 a time stamp from a Time Stamping Authority (TSA) by means of the 837 Time-Stamp Protocol (TSP) defined in [RFC3161]. 839 11.2. Revocation of Server Certificates 841 According to Section 8.1, it is the client's responsibility to 842 initiate a new association with the server after the server's 843 certificate expires. To this end the client reads the expiration 844 date of the certificate during the certificate message exchange 845 (Section 6.1.2). Besides, certificates may also be revoked prior to 846 the normal expiration date. To increase security the client MAY 847 verify the state of the server's certificate via OCSP periodically. 849 11.3. Usage of NTP Pools 851 The certification based authentication scheme described in Section 6 852 is not applicable to the concept of NTP pools. Therefore, NTS is not 853 able to provide secure usage of NTP pools. 855 11.4. Denial-of-Service in Broadcast Mode 857 TESLA authentication buffers packets for delayed authentication. 858 This makes the protocol vulnerable to flooding attacks, causing the 859 client to buffer excessive numbers of packets. To add stronger DoS 860 protection to the protocol, client and server use the "not re-using 861 keys" scheme of TESLA as pointed out in section 3.7.2 of RFC 4082 862 [RFC4082]. In this scheme the server never uses a key for the MAC 863 generation more than once. Therefore the client can discard any 864 packet that contains a disclosed key it knows already, thus 865 preventing memory flooding attacks. 867 Note that an alternative approach to enhance TESLA's resistance 868 against DoS attacks involves the addition of a group MAC to each 869 packet. This requires the exchange of an additional shared key 870 common to the whole group. This adds additional complexity to the 871 protocol and hence is currently not considered in this document. 873 11.5. Delay Attack 875 In a packet delay attack, an adversary with the ability to act as a 876 MITM delays time synchronization packets between client and server 877 asymmetrically [RFC7384]. This prevents the client to measure the 878 network delay, and hence its time offset to the server, accurately 879 [Mizrahi]. The delay attack does not modify the content of the 880 exchanged synchronization packets. Therefore cryptographic means do 881 not provide a feasible way to mitigate this attack. However, several 882 non-cryptographic precautions can be taken in order to detect this 883 attack. 885 1. Usage of multiple time servers: this enables the client to detect 886 the attack provided that the adversary is unable to delay the 887 synchronizations packets between the majority of servers. This 888 approach is commonly used in NTP to exclude incorrect time 889 servers [RFC5905]. 891 2. Multiple communication paths: The client and server are utilizing 892 different paths for packet exchange as described in the I-D 893 [I-D.shpiner-multi-path-synchronization]. The client can detect 894 the attack provided that the adversary is unable to manipulate 895 the majority of the available paths [Shpiner]. Note that this 896 approach is not yet available, neither for NTP nor for PTP. 898 3. Usage of an encrypted connection: the client exchanges all 899 packets with the time server over an encrypted connection (e.g. 900 IPsec). This measure does not mitigate the delay attack but it 901 makes it more difficult for the adversary to identify the time 902 synchronization packets. 904 4. For the unicast mode: Introduction of a threshold value for the 905 delay time of the synchronization packets. The client can 906 discard a time server if the packet delay time of this time 907 server is larger than the threshold value. 909 Additional provision against delay attacks has to be taken in the 910 broadcast mode. This mode relies on the TESLA scheme which is based 911 on the requirement that a client and the broadcast server are loosely 912 time synchronized. Therefore, a broadcast client has to establish 913 time synchronization with its broadcast server before it maintains 914 time synchronization by utilization of the broadcast mode. To this 915 end it initially establishes a unicast association with its broadcast 916 server until time synchronization and calibration of the packet delay 917 time is achieved. After that it establishes a broadcast association 918 to the broadcast server and utilizes TESLA to verify integrity and 919 authenticity of any received broadcast packets. 921 An adversary who is able to delay broadcast packets can cause a time 922 adjustment at the receiving broadcast clients. If the adversary 923 delays broadcast packets continuously, then the time adjustment will 924 accumulate until the loose time synchronization requirement is 925 violated, which breaks the TESLA scheme. To mitigate this 926 vulnerability the security condition in TESLA has to be supplemented 927 by an additional check in which the client, upon receipt of a 928 broadcast message, verifies the status of the corresponding key via a 929 unicast message exchange with the broadcast server (see section 930 Appendix C.4 for a detailed description of this check). Note, that a 931 broadcast client should also apply the above mentioned precautions as 932 far as possible. 934 12. Acknowledgements 936 The authors would like to thank Russ Housley, Steven Bellovin, David 937 Mills and Kurt Roeckx for discussions and comments on the design of 938 NTS. Also, thanks to Harlan Stenn for his technical review and 939 specific text contributions to this document. 941 13. References 942 13.1. Normative References 944 [IEEE1588] 945 IEEE Instrumentation and Measurement Society. TC-9 Sensor 946 Technology, "IEEE standard for a precision clock 947 synchronization protocol for networked measurement and 948 control systems", 2008. 950 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 951 Hashing for Message Authentication", RFC 2104, February 952 1997. 954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 955 Requirement Levels", BCP 14, RFC 2119, March 1997. 957 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 958 "Internet X.509 Public Key Infrastructure Time-Stamp 959 Protocol (TSP)", RFC 3161, August 2001. 961 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 962 Briscoe, "Timed Efficient Stream Loss-Tolerant 963 Authentication (TESLA): Multicast Source Authentication 964 Transform Introduction", RFC 4082, June 2005. 966 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 967 RFC 5652, September 2009. 969 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 970 Time Protocol Version 4: Protocol and Algorithms 971 Specification", RFC 5905, June 2010. 973 [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate 974 Status Protocol Algorithm Agility", RFC 6277, June 2011. 976 13.2. Informative References 978 [I-D.shpiner-multi-path-synchronization] 979 Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- 980 Path Time Synchronization", draft-shpiner-multi-path- 981 synchronization-03 (work in progress), February 2014. 983 [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks 984 against time synchronization protocols", in Proceedings of 985 Precision Clock Synchronization for Measurement Control 986 and Communication, ISPCS 2012, pp. 1-6, September 2012. 988 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 989 Requirements for Security", BCP 106, RFC 4086, June 2005. 991 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 992 Packet Switched Networks", RFC 7384, October 2014. 994 [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time 995 Protocols", in Proceedings of Precision Clock 996 Synchronization for Measurement Control and Communication, 997 ISPCS 2013, pp. 1-6, September 2013. 999 Appendix A. Flow Diagrams of Client Behaviour 1001 +---------------------+ 1002 |Association Messages | 1003 +----------+----------+ 1004 | 1005 +------------------------------>o 1006 | | 1007 | v 1008 | +---------------+ 1009 | |Cookie Messages| 1010 | +-------+-------+ 1011 | | 1012 | o<------------------------------+ 1013 | | | 1014 | v | 1015 | +-------------------+ | 1016 | |Time Sync. Messages| | 1017 | +---------+---------+ | 1018 | | | 1019 | v | 1020 | +-----+ | 1021 | |Check| | 1022 | +--+--+ | 1023 | | | 1024 | /------------------+------------------\ | 1025 | v v v | 1026 | .-----------. .-------------. .-------. | 1027 | ( MAC Failure ) ( Nonce Failure ) ( Success ) | 1028 | '-----+-----' '------+------' '---+---' | 1029 | | | | | 1030 | v v v | 1031 | +-------------+ +-------------+ +--------------+ | 1032 | |Discard Data | |Discard Data | |Sync. Process | | 1033 | +-------------+ +------+------+ +------+-------+ | 1034 | | | | | 1035 | | | v | 1036 +-----------+ +------------------>o-----------+ 1038 Figure 1: The client's behavior in NTS unicast mode. 1040 +-----------------------------+ 1041 |Broadcast Parameter Messages | 1042 +--------------+--------------+ 1043 | 1044 o<--------------------------+ 1045 | | 1046 v | 1047 +-----------------------------+ | 1048 |Broadcast Time Sync. Message | | 1049 +--------------+--------------+ | 1050 | | 1051 +-------------------------------------->o | 1052 | | | 1053 | v | 1054 | +-------------------+ | 1055 | |Key and Auth. Check| | 1056 | +---------+---------+ | 1057 | | | 1058 | /----------------*----------------\ | 1059 | v v | 1060 | .---------. .---------. | 1061 | ( Verified ) ( Falsified ) | 1062 | '----+----' '----+----' | 1063 | | | | 1064 | v v | 1065 | +-------------+ +-------+ | 1066 | |Store Message| |Discard| | 1067 | +------+------+ +---+---+ | 1068 | | | | 1069 | v +---------o 1070 | +---------------+ | 1071 | |Check Previous | | 1072 | +-------+-------+ | 1073 | | | 1074 | /--------*--------\ | 1075 | v v | 1076 | .---------. .---------. | 1077 | ( Verified ) ( Falsified ) | 1078 | '----+----' '----+----' | 1079 | | | | 1080 | v v | 1081 | +-------------+ +-----------------+ | 1082 | |Sync. Process| |Discard Previous | | 1083 | +------+------+ +--------+--------+ | 1084 | | | | 1085 +-----------+ +-----------------------------------+ 1087 Figure 2: The client's behaviour in NTS broadcast mode. 1089 Appendix B. TICTOC Security Requirements 1091 The following table compares the NTS specifications against the 1092 TICTOC security requirements [RFC7384]. 1094 +---------+------------------------------------+-------------+------+ 1095 | Section | Requirement from I-D tictoc | Requirement | NTS | 1096 | | security-requirements-05 | level | | 1097 +---------+------------------------------------+-------------+------+ 1098 | 5.1.1 | Authentication of Servers | MUST | OK | 1099 +---------+------------------------------------+-------------+------+ 1100 | 5.1.1 | Authorization of Servers | MUST | OK | 1101 +---------+------------------------------------+-------------+------+ 1102 | 5.1.2 | Recursive Authentication of | MUST | OK | 1103 | | Servers (Stratum 1) | | | 1104 +---------+------------------------------------+-------------+------+ 1105 | 5.1.2 | Recursive Authorization of Servers | MUST | OK | 1106 | | (Stratum 1) | | | 1107 +---------+------------------------------------+-------------+------+ 1108 | 5.1.3 | Authentication and Authorization | MAY | - | 1109 | | of Slaves | | | 1110 +---------+------------------------------------+-------------+------+ 1111 | 5.2 | Integrity protection. | MUST | OK | 1112 +---------+------------------------------------+-------------+------+ 1113 | 5.4 | Protection against DoS attacks | SHOULD | OK | 1114 +---------+------------------------------------+-------------+------+ 1115 | 5.5 | Replay protection | MUST | OK | 1116 +---------+------------------------------------+-------------+------+ 1117 | 5.6 | Key freshness. | MUST | OK | 1118 +---------+------------------------------------+-------------+------+ 1119 | | Security association. | SHOULD | OK | 1120 +---------+------------------------------------+-------------+------+ 1121 | | Unicast and multicast | SHOULD | OK | 1122 | | associations. | | | 1123 +---------+------------------------------------+-------------+------+ 1124 | 5.7 | Performance: no degradation in | MUST | OK | 1125 | | quality of time transfer. | | | 1126 +---------+------------------------------------+-------------+------+ 1127 | | Performance: lightweight | SHOULD | OK | 1128 | | computation | | | 1129 +---------+------------------------------------+-------------+------+ 1130 | | Performance: storage, bandwidth | SHOULD | OK | 1131 +---------+------------------------------------+-------------+------+ 1132 | 5.7 | Confidentiality protection | MAY | NO | 1133 +---------+------------------------------------+-------------+------+ 1134 | 5.9 | Protection against Packet Delay | SHOULD | NA*) | 1135 | | and Interception Attacks | | | 1136 +---------+------------------------------------+-------------+------+ 1137 | 5.10 | Secure mode | MUST | - | 1138 +---------+------------------------------------+-------------+------+ 1139 | | Hybrid mode | SHOULD | - | 1140 +---------+------------------------------------+-------------+------+ 1142 *) See discussion in section Section 11.5. 1144 Comparison of NTS sepecification against TICTOC security 1145 requirements. 1147 Appendix C. Broadcast Mode 1149 For the broadcast mode, NTS adopts the TESLA protocol with some 1150 customizations. This appendix provides details on the generation and 1151 usage of the one-way key chain collected and assembled from 1152 [RFC4082]. Note that NTS is using the "not re-using keys" scheme of 1153 TESLA as described in section 3.7.2. of [RFC4082]. 1155 C.1. Server Preparations 1157 Server setup: 1159 1. The server determines a reasonable upper bound B on the network 1160 delay between itself and an arbitrary client, measured in 1161 milliseconds. 1163 2. It determines the number n+1 of keys in the one-way key chain. 1164 This yields the number n of keys that are usable to authenticate 1165 broadcast packets. This number n is therefore also the number of 1166 time intervals during which the server can send authenticated 1167 broadcast messages before it has to calculate a new key chain. 1169 3. It divides time into n uniform intervals I_1, I_2, ..., I_n. 1170 Each of these time intervals has length L, measured in 1171 milliseconds. In order to fulfill the requirement 3.7.2. of RFC 1172 4082 the time interval L has to be smaller than the time interval 1173 between the broadcast messages. 1175 4. The server generates a random key K_n. 1177 5. Using a one-way function F, the server generates a one-way chain 1178 of n+1 keys K_0, K_1, ..., K_{n} according to 1180 K_i = F(K_{i+1}). 1182 6. Using another one-way function F', it generates a sequence of n+1 1183 MAC keys K'_0, K'_1, ..., K'_{n-1} according to 1184 K'_i = F'(K_i). 1186 7. Each MAC key K'_i is assigned to the time interval I_i. 1188 8. The server determines the key disclosure delay d, which is the 1189 number of intervals between using a key and disclosing it. Note 1190 that although security is provided for all choices d>0, the 1191 choice still makes a difference: 1193 * If d is chosen too short, the client might discard packets 1194 because it fails to verify that the key used for their MAC has 1195 not been yet disclosed. 1197 * If d is chosen too long, the received packets have to be 1198 buffered for a unnecessarily long time before they can be 1199 verified by the client and subsequently be utilized for time 1200 synchronization. 1202 The server SHOULD calculate d according to 1204 d = ceil( 2*B / L) + 1, 1206 where ceil gives the smallest integer greater than or equal to 1207 its argument. 1209 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1210 Generation of Keys 1212 F F F F 1213 K_0 <-------- K_1 <-------- ... <-------- K_{n-1} <------- K_n 1214 | | | | 1215 | | | | 1216 | F' | F' | F' | F' 1217 | | | | 1218 v v v v 1219 K'_0 K'_1 ... K'_{n-1} K'_n 1220 [______________|____ ____|_________________|_______] 1221 I_1 ... I_{n-1} I_n 1223 Course of Time/Usage of Keys 1224 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -> 1226 A Schematic explanation on the TESLA protocol's one-way key chain 1228 C.2. Client Preparation 1230 A client needs the following information in order to participate in a 1231 TESLA broadcast. 1233 o One key K_i from the one-way key chain, which has to be 1234 authenticated as belonging to the server. Typically, this will be 1235 K_0. 1237 o The disclosure schedule of the keys. This consists of: 1239 * the length n of the one-way key chain, 1241 * the length L of the time intervals I_1, I_2, ..., I_n, 1243 * the starting time T_i of an interval I_i. Typically this is 1244 the starting time T_1 of the first interval; 1246 * the disclosure delay d. 1248 o The one-way function F used to recursively derive the keys in the 1249 one-way key chain, 1251 o The second one-way function F' used to derive the MAC keys K'_0, 1252 K'_1, ... , K'_n from the keys in the one-way chain. 1254 o An upper bound D_t on how far its own clock is "behind" that of 1255 the server. 1257 Note that if D_t is greater than (d - 1) * L, then some authentic 1258 packets might be discarded. If D_t is greater than d * L, then all 1259 authentic packets will be discarded. In the latter case, the client 1260 should not participate in the broadcast, since there will be no 1261 benefit in doing so. 1263 C.3. Sending Authenticated Broadcast Packets 1265 During each time interval I_i, the server sends one authenticated 1266 broadcast packet P_i. This packet consists of: 1268 o a message M_i, 1270 o the index i (in case a packet arrives late), 1272 o a MAC authenticating the message M_i, with K'_i used as key, 1274 o the key K_{i-d}, which is included for disclosure. 1276 C.4. Authentication of Received Packets 1278 When a client receives a packet P_i as described above, it first 1279 checks that it has not received a packet with the same disclosed key 1280 before. This is done to avoid replay/flooding attacks. A packet 1281 that fails this test is discarded. 1283 Next, the client begins to check the packet's timeliness by ensuring 1284 that, according to the disclosure schedule and with respect to the 1285 upper bound D_t determined above, the server cannot have disclosed 1286 the key K_i yet. Specifically, it needs to check that the server's 1287 clock cannot read a time that is in time interval I_{i+d} or later. 1288 Since it works under the assumption that the server's clock is not 1289 more than D_t "ahead" of the client's clock, the client can calculate 1290 an upper bound t_i for the server's clock at the time when P_i 1291 arrived. This upper bound t_i is calculated according to 1293 t_i = R + D_t, 1295 where R is the client's clock at the arrival of P_i. This implies 1296 that at the time of arrival of P_i, the server could have been in 1297 interval I_x at most, with 1299 x = floor((t_i - T_1) / L) + 1, 1301 where floor gives the greatest integer less than or equal to its 1302 argument. The client now needs to verify that 1304 x < i+d 1306 is valid (see also section 3.5 of [RFC4082]). If falsified, it is 1307 discarded. 1309 If the check above is successful, the client performs another more 1310 rigorous check: it sends a key check request to the server (in the 1311 form of a client_keycheck message), asking explicitly if K_i has 1312 already been disclosed. It remembers the timestamp t_check of the 1313 sending time of that request as well as the nonce it used correlated 1314 with the interval number i. If it receives an answer from the server 1315 stating that K_i has not yet been disclosed and it is able to verify 1316 the HMAC on that response, then it deduces that K_i was undisclosed 1317 at t_check and therefore also at R. In this case, the clients 1318 accepts P_i as timely. 1320 Next the client verifies that a newly disclosed key K_{i-d} belongs 1321 to the one-way key chain. To this end it applies the one-way 1322 function F to K_{i-d} until it can verify identity with an earlier 1323 disclosed key (see Clause 3.5 in RFC 4082, item 3). 1325 Next the client verifies that the transmitted time value s_i belongs 1326 to the time interval I_i, by checking 1328 T_i =< s_i, and 1330 s_i < T_{i+1}. 1332 If falsified, the packet MUST be discarded and the client MUST 1333 reinitialize the broadcast mode with a unicast association (because a 1334 falsification of this check yields that the packet was not generated 1335 according to protocol, which suggests an attack). 1337 If a packet P_i passes all tests listed above, it is stored for later 1338 authentication. Also, if at this time there is a package with index 1339 i-d already buffered, then the client uses the disclosed key K_{i-d} 1340 to derive K'_{i-d} and uses that to check the MAC included in package 1341 P_{i-d}. On success, it regards M_{i-d} as authenticated. 1343 Appendix D. Random Number Generation 1345 At various points of the protocol, the generation of random numbers 1346 is required. The employed methods of generation need to be 1347 cryptographically secure. See [RFC4086] for guidelines concerning 1348 this topic. 1350 Authors' Addresses 1352 Dieter Sibold 1353 Physikalisch-Technische Bundesanstalt 1354 Bundesallee 100 1355 Braunschweig D-38116 1356 Germany 1358 Phone: +49-(0)531-592-8420 1359 Fax: +49-531-592-698420 1360 Email: dieter.sibold@ptb.de 1362 Stephen Roettger 1363 Google Inc 1365 Email: stephen.roettger@googlemail.com 1366 Kristof Teichel 1367 Physikalisch-Technische Bundesanstalt 1368 Bundesallee 100 1369 Braunschweig D-38116 1370 Germany 1372 Phone: +49-(0)531-592-8421 1373 Email: kristof.teichel@ptb.de