idnits 2.17.1 draft-ietf-ntp-network-time-security-04.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 ([I-D.ietf-tictoc-security-requirements]), 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 (July 04, 2014) is 3584 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) -- 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 ** Downref: Normative reference to an Informational RFC: RFC 5906 ** Obsolete normative reference: RFC 6277 (Obsoleted by RFC 6960) == Outdated reference: A later version (-12) exists of draft-ietf-tictoc-security-requirements-10 Summary: 5 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: January 5, 2015 6 K. Teichel 7 PTB 8 July 04, 2014 10 Network Time Security 11 draft-ietf-ntp-network-time-security-04.txt 13 Abstract 15 This document describes the Network Time Security (NTS) protocol that 16 enables secure authentication of time servers using Network Time 17 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 [I-D.ietf-tictoc-security-requirements]. 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 January 5, 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 . . . . . . . . . . . . . . . . . . . . . 6 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. Certificate Messages . . . . . . . . . . . . . . . . . . 7 74 6.2.1. Message Type: "client_cert" . . . . . . . . . . . . . 8 75 6.2.2. Message Type: "server_cert" . . . . . . . . . . . . . 8 76 6.3. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 9 77 6.3.1. Message Type: "client_cook" . . . . . . . . . . . . . 9 78 6.3.2. Message Type: "server_cook" . . . . . . . . . . . . . 9 79 6.4. Unicast Time Synchronisation Messages . . . . . . . . . . 10 80 6.4.1. Message Type: "time_request" . . . . . . . . . . . . 10 81 6.4.2. Message Type: "time_response" . . . . . . . . . . . . 10 82 6.5. Broadcast Parameter Messages . . . . . . . . . . . . . . 11 83 6.5.1. Message Type: "client_bpar" . . . . . . . . . . . . . 11 84 6.5.2. Message Type: "server_bpar" . . . . . . . . . . . . . 11 85 6.6. Broadcast Message . . . . . . . . . . . . . . . . . . . . 12 86 6.6.1. Message Type: "server_broad" . . . . . . . . . . . . 12 87 7. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 13 88 7.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 13 89 7.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 13 90 7.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 17 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 . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 20 111 13.2. Informative References . . . . . . . . . . . . . . . . . 21 112 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 22 113 Appendix B. Extension Fields . . . . . . . . . . . . . . . . . . 25 114 Appendix C. TICTOC Security Requirements . . . . . . . . . . . . 25 115 Appendix D. Broadcast Mode . . . . . . . . . . . . . . . . . . . 26 116 D.1. Server Preparations . . . . . . . . . . . . . . . . . . . 27 117 D.2. Client Preparation . . . . . . . . . . . . . . . . . . . 28 118 D.3. Sending Authenticated Broadcast Packets . . . . . . . . . 29 119 D.4. Authentication of Received Packets . . . . . . . . . . . 29 120 Appendix E. Random Number Generation . . . . . . . . . . . . . . 30 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 123 1. Introduction 125 Time synchronization protocols are increasingly utilized to 126 synchronize clocks in networked infrastructures. The reliable 127 performance of such infrastructures can be degraded seriously by 128 successful attacks against the time synchronization protocol. 129 Therefore, time synchronization protocols applied in critical 130 infrastructures have to provide security measures to defeat possible 131 adversaries. Consequently, the widespread Network Time Protocol 132 (NTP) [RFC5905] was supplemented by the autokey protocol [RFC5906] 133 which shall ensure authenticity of the NTP server and integrity of 134 the protocol packets. Unfortunately, the autokey protocol exhibits 135 various severe security vulnerabilities as revealed in a thorough 136 analysis of the protocol [Roettger]. For the Precision Time Protocol 137 (PTP), Annex K of the standard document IEEE 1588 [IEEE1588] defines 138 an informative security protocol that is still in experimental state. 140 Because of autokey's security vulnerabilities and the absence of a 141 standardized security protocol for PTP, these protocols cannot be 142 applied in environments in which compliance requirements demand 143 authenticity and integrity protection. This document specifies a 144 security protocol which ensures authenticity of the time server via a 145 Public Key Infrastructure (PKI) and integrity of the time 146 synchronization protocol packets and which therefore enables the 147 usage of NTP and PTP in such environments. 149 The protocol is specified with the prerequisite in mind that precise 150 timekeeping can only be accomplished with stateless time 151 synchronization communication, which excludes the utilization of 152 standard security protocols like IPsec or TLS for time 153 synchronization messages. This prerequisite corresponds with the 154 requirement that a security mechanism for timekeeping must be 155 designed in such a way that it does not degrade the quality of the 156 time transfer [I-D.ietf-tictoc-security-requirements]. 158 Note: 160 The intent is to formulate the protocol to be applicable to NTP 161 and also PTP. In the current state the draft focuses on the 162 application to NTP. 164 2. Security Threats 166 A profound analysis of security threats and requirements for NTP and 167 PTP can be found in the "Security Requirements of Time Protocols in 168 Packet Switched Networks" [I-D.ietf-tictoc-security-requirements]. 170 3. Objectives 172 The objectives of the NTS specification are as follows: 174 o Authenticity: NTS enables the client to authenticate its time 175 server. 177 o Integrity: NTS protects the integrity of time synchronization 178 protocol packets via a message authentication code (MAC). 180 o Confidentiality: NTS does not provide confidentiality protection 181 of the time synchronization packets. 183 o Modes of operation: All operational modes of NTP are supported. 185 o Operational modes of PTP should be supported as far as possible. 187 o Hybrid mode: Both secure and insecure communication modes are 188 possible for NTP servers and clients, respectively. 190 o Compatibility: 192 * Unsecured NTP associations shall not be affected. 194 * An NTP server that does not support NTS shall not be affected 195 by NTS authentication requests. 197 4. Terms and Abbreviations 199 MITM Man In The Middle 201 NTP Network Time Protocol 203 NTS Network Time Security 205 PTP Precision Time Protocol 207 TESLA Timed Efficient Stream Loss-Tolerant Authentication 209 5. NTS Overview 211 5.1. Symmetric and Client/Server Mode 213 NTS applies X.509 certificates to verify the authenticity of the time 214 server and to exchange a symmetric key, the so-called cookie. This 215 cookie is then used to protect authenticity and integrity of the 216 subsequent time synchronization packets by means of a Message 217 Authentication Code (MAC), which is attached to each time 218 synchronization packet. The calculation of the MAC includes the 219 whole time synchronization packet and the cookie which is shared 220 between client and server. It is calculated according to: 222 cookie = MSB_128 (HMAC(server seed, H(certificate of client))), 224 with the server seed as key, where H is a hash function, and where 225 the function MSB_128 cuts off the 128 most significant bits of the 226 result of the HMAC function. The server seed is a 128 bit random 227 value of the server, which has to be kept secret. The cookie never 228 changes as long as the server seed stays the same, but the server 229 seed has to be refreshed periodically in order to provide key 230 freshness as required in [I-D.ietf-tictoc-security-requirements]. 231 See Section 8 for details on the seed refresh and Section 7.1.1 for 232 the client's reaction to it. 234 The server does not keep a state of the client. Therefore it has to 235 recalculate the cookie each time it receives a request from the 236 client. To this end, the client has to attach the hash value of its 237 certificate to each request (see Section 6.4). 239 5.2. Broadcast Mode 241 Just as in the case of the client server mode and symmetric mode, 242 authenticity and integrity of the NTP packets are ensured by a MAC, 243 which is attached to the NTP packet by the sender. The verification 244 of the authenticity is based on the TESLA protocol, in particular on 245 its "Not Re-using Keys" scheme, see section 3.7.2 of [RFC4082]. 246 TESLA is based on a one-way chain of keys, where each key is the 247 output of a one-way function applied on the previous key in the 248 chain. The last element of the chain is shared securely with all 249 clients. The server splits time into intervals of uniform duration 250 and assigns each key to an interval in reverse order, starting with 251 the penultimate. At each time interval, the server sends an NTP 252 broadcast packet appended by a MAC, calculated using the 253 corresponding key, and the key of the previous disclosure interval. 254 The client verifies the MAC by buffering the packet until the 255 disclosure of the key in its associated disclosure interval. In 256 order to be able to verify the validity of the key, the client has to 257 be loosely time synchronized to the server. This has to be 258 accomplished during the initial client server exchange between 259 broadcast client and server. For a more detailed description of the 260 TESLA protocol see Appendix D. 262 6. Protocol Messages 264 Note that this section currently describes the realization of the 265 message format of NTS only for its utilization for NTP, in which the 266 NTS specific data are enclosed in extension fields on top of NTP 267 packets. A specification of NTS messages for PTP would have to be 268 developed accordingly. 270 The steps described in Section 6.1 - Section 6.4 belong to the 271 unicast mode, while Section 6.5 and Section 6.6 explain the steps 272 involved in the broadcast mode of NTS. 274 6.1. Association Messages 276 In this message exchange, the hash and signature algorithms that are 277 used throughout the protocol are negotiated. 279 6.1.1. Message Type: "client_assoc" 281 The protocol sequence starts with the client sending an association 282 message, called client_assoc. This message contains 284 o the NTS message ID "client_assoc", 286 o the version number of NTS that the client wants to use (this 287 SHOULD be the highest version number that it supports), 289 o the hostname of the client, 291 o a selection of accepted hash algorithms, 293 o a selection of accepted encryption algorithms, and 295 o a selection of accepted algorithms for the signatures. 297 For NTP, this message is realized as a packet with an extension field 298 of type "association", which contains all this data. 300 6.1.2. Message Type: "server_assoc" 302 This message is sent by the server upon receipt of client_assoc. It 303 contains 305 o the NTS message ID "server_assoc", 307 o the version number used for the rest of the protocol (which SHOULD 308 be determined as the minimum over the client's suggestion in the 309 client_assoc message and the highest supported by the server), 311 o the hostname of the server, and 313 o the server's choice of algorithm for encryption, for the 314 signatures and for cryptographic hashing , all of which MUST be 315 chosen from the client's proposals. 317 In the case of NTP, the data is enclosed in a packet's extension 318 field, also of type "association". 320 6.2. Certificate Messages 322 In this message exchange, the client receives the certification chain 323 up to a trusted anchor. With the established certification chain the 324 client is able to verify the server's signatures and, hence, 325 authenticity of future NTS messages from the server is ensured. 327 Discussion: 329 Note that in this step the client validates the authenticity of 330 its immediate NTP server only. It does not recursively validate 331 the authenticity of each NTP server on the time synchronization 332 chain. Recursive authentication (and authorization) as formulated 333 in [I-D.ietf-tictoc-security-requirements] depends on the chosen 334 trust anchor. 336 6.2.1. Message Type: "client_cert" 338 This message is sent by the client, after it successfully verified 339 the content of the received server_assoc message (see Section 7.1.1). 340 It contains 342 o the NTS message ID "client_cert", 344 o the negotiated version number, 346 o the client's hostname, and 348 o the signature algorithm negotiated during the association 349 messages. 351 In the case of NTP, the data is enclosed in a packet's extension 352 field of type "certificate request". 354 6.2.2. Message Type: "server_cert" 356 This message is sent by the server, upon receipt of a client_cert 357 message, if the version number and choice of methods communicated in 358 that message are actually supported by the server. It contains 360 o the NTS message ID "server_cert", 362 o the version number as transmitted in client_cert, 364 o a signature, calculated over the data listed above, with the 365 server's private key and according to the signature algorithm 366 transmitted in server_cert, 368 o all the information necessary to authenticate the server to the 369 client. This is a chain of certificates, which starts at the 370 server and goes up to a trusted authority, where each certificate 371 MUST be certified by the one directly following it. 373 This message is realized for NTP as a packet with extension field of 374 type "certificate" which holds all of the data listed above. 376 6.3. Cookie Messages 378 During this message exchange, the server transmits a secret cookie to 379 the client securely. The cookie will be used for integrity 380 protection during unicast time synchronization. 382 6.3.1. Message Type: "client_cook" 384 This message is sent by the client, upon successful authentication of 385 the server. In this message, the client requests a cookie from the 386 server. The message contains 388 o the NTS message ID "client_cook", 390 o the negotiated version number, 392 o the negotiated signature algorithm, 394 o the negotiated encryption algorithm, 396 o a 128-bit nonce, 398 o the negotiated hash algorithm H, 400 o the client's certificate. 402 For NTP, an extension field of type "cookie request" holds the listed 403 data. 405 6.3.2. Message Type: "server_cook" 407 This message is sent by the server, upon receipt of a client_cook 408 message. The server generates the hash of the client's certificate, 409 as conveyed during client_cook, in order to calculate the cookie 410 according to Section 5.1. This message contains a concatenated 411 datum, which is encrypted with the client's public key, according to 412 the encryption algorithm transmitted in the client_cook message. The 413 concatenated datum contains 415 o the NTS message ID "server_cook" 417 o the version number as transmitted in client_cook, 419 o the nonce transmitted in client_cook, 421 o the cookie, and 422 o a signature, created with the server's private key, calculated 423 over 425 * all of the data listed above, and also 427 * the hash of the client's certificate. 429 This signature MUST be calculated according to the transmitted 430 signature algorithm from the client_cook message. 432 In the case of NTP, this is a packet with an extension field of type 433 "cookie transmit". 435 6.4. Unicast Time Synchronisation Messages 437 In this message exchange, the usual time synchronization process is 438 executed, with the addition of integrity protection for all messages 439 that the server sends. This message can be repeatedly exchanged as 440 often as the client desires and as long as the integrity of the 441 server's time responses is verified successfully. 443 6.4.1. Message Type: "time_request" 445 This message is sent by the client when it requests time exchange. 446 It contains 448 o the NTS message ID "time_request", 450 o the negotiated version number, 452 o a 128-bit nonce, 454 o the negotiated hash algorithm H, 456 o the hash of the client's certificate under H. 458 In the case of NTP the data is enclosed in the packet's extension 459 field of type "time request". 461 6.4.2. Message Type: "time_response" 463 This message is sent by the server, after it received a time_request 464 message. Prior to this the server MUST recalculate the client's 465 cookie by using the hash of the client's certificate and the 466 transmitted hash algorithm. The message contains 468 o the NTS message ID "time_response", 469 o the version number as transmitted in time_request, 471 o the server's time synchronization response data, 473 o the nonce transmitted in time_request, 475 o a MAC (generated with the cookie as key) for verification of all 476 of the above data. 478 In the case of NTP, this is a packet with the necessary time 479 synchronization data and a new extension field of type "time 480 response". This packet has an appended MAC that is generated over 481 the time synchronization data and the extension field, with the 482 cookie as the key. 484 6.5. Broadcast Parameter Messages 486 In this message exchange, the client receives the necessary 487 information to execute the TESLA protocol in a secured broadcast 488 association. The client can only initiate a secure broadcast 489 association after a successful unicast run, see Section 7.1.2. 491 See Appendix D for more details on TESLA. 493 6.5.1. Message Type: "client_bpar" 495 This message is sent by the client in order to establish a secured 496 time broadcast association with the server. It contains 498 o the NTS message ID "client_bpar", 500 o the version number negotiated during association in unicast mode, 502 o the client's hostname, and 504 o the signature algorithm negotiated during unicast. 506 For NTP, this message is realized as a packet with an extension field 507 of type "broadcast request". 509 6.5.2. Message Type: "server_bpar" 511 This message is sent by the server upon receipt of a client_bpar 512 message during the broadcast loop of the server. It contains 514 o the NTS message ID "server_bpar", 516 o the version number as transmitted in the client_bpar message, 517 o the one-way function used for building the one-way key chain, 519 o the last key of the one-way key chain, and 521 o the disclosure schedule of the keys. This contains: 523 * time interval duration, 525 * the disclosure delay (number of intervals between use and 526 disclosure of a key), 528 * the time at which the next time interval will start, and 530 * the next interval's associated index. 532 o The message also contains a signature signed by the server with 533 its private key, verifying all the data listed above. 535 It is realized for NTP as a packet with an extension field of type 536 "broadcast parameters", which contains all the given data. 538 6.6. Broadcast Message 540 Via this message, the server keeps sending broadcast time 541 synchronization messages to all participating clients. 543 6.6.1. Message Type: "server_broad" 545 This message is sent by the server over the course of its broadcast 546 schedule. It is part of any broadcast association. It contains 548 o the NTS message ID "server_broad", 550 o the version number that the server's broadcast mode is working 551 under, 553 o time broadcast data, 555 o the index that belongs to the current interval (and therefore 556 identifies the current, yet undisclosed key), 558 o the disclosed key of the previous disclosure interval (current 559 time interval minus disclosure delay), 561 o a MAC, calculated with the key for the current time interval, 562 verifying 564 * the message ID, 565 * the version number, and 567 * the time data. 569 For NTP, this message is realized as an NTP broadcast packet with the 570 time broadcast data and with an extension field of type "broadcast 571 message", which contains the rest of the listed data. The NTP packet 572 is then appended by a MAC verifying its contents. 574 7. Protocol Sequence 576 7.1. The Client 578 7.1.1. The Client in Unicast Mode 580 For a unicast run, the client performs the following steps: 582 1. It sends a client_assoc message to the server. It MUST keep the 583 transmitted values for version number and algorithms available 584 for later checks. 586 2. It waits for a reply in the form of a server_assoc message. 587 After receipt of the message it performs the following checks: 589 * The client checks that the message contains a conform version 590 number. 592 * It also has to verify that the server has chosen the signature 593 and hash algorithms from its proposal sent in the client_assoc 594 message. 596 If one of the checks fails, the client MUST abort the run. 598 3. The client then sends a client_cert message to the server. 599 Again, it MUST remember the transmitted values for version number 600 and algorithms for later checks. 602 4. It awaits a reply in the form of a server_cert message and 603 performs authenticity checks on the certificate chain and the 604 signature for the version number. If one of these checks fails, 605 the client MUST abort the run. 607 5. Next, it sends a client_cook message to the server. The client 608 MUST save the included nonce until the reply has been processed. 610 6. It awaits a reply in the form of a server_cook message; upon 611 receipt it executes the following actions: 613 * It decrypts the message with its own private key. 615 * It checks that the decrypted message is of the expected 616 format: the concatenation of version number, a 128 bit nonce, 617 a 128 bit cookie and a signature value. 619 * It verifies that the received version number matches the one 620 negotiated before. 622 * It verifies that the received nonce matches the nonce sent in 623 the client_cook message. 625 * It verifies the signature using the server's public key. The 626 signature has to authenticate the version number, the nonce, 627 the cookie, and the hash of the client's certificate. 629 If one of those checks fails, the client MUST abort the run. 631 7. The client sends a time_request message to the server. The 632 client MUST save the included nonce and the transmit_timestamp 633 (from the time synchronization data) as a correlated pair for 634 later verification steps. 636 8. It awaits a reply in the form of a time_response message. Upon 637 receipt, it checks: 639 * that the transmitted version number matches the one negotiated 640 before, 642 * that the transmitted nonce belongs to a previous time_request 643 message, 645 * that the transmit_timestamp in that time_request message 646 matches the corresponding time stamp from the synchronization 647 data received in the time_response, and 649 * that the appended MAC verifies the received synchronization 650 data, version number and nonce. 652 If at least one of the first three checks fails (i.e. if the 653 version number does not match, if the client has never used the 654 nonce transmitted in the time_response message or if it has used 655 the nonce with initial time synchronization data different from 656 that in the response), then the client MUST ignore this 657 time_response message. If the MAC is invalid, the client MUST do 658 one of the following: abort the run or go back to step 5 (because 659 the cookie might have changed due to a server seed refresh). If 660 both checks are successful, the client SHOULD continue time 661 synchronization by going back to step 7. 663 The client's behavior in unicast mode is also expressed in Figure 1. 665 7.1.2. The Client in Broadcast Mode 667 To establish a secure broadcast association with a broadcast server, 668 the client MUST initially authenticate the broadcast server and 669 securely synchronize its time to it up to an upper bound for its time 670 offset in unicast mode. After that, the client performs the 671 following steps: 673 1. It sends a client_bpar message to the server. It MUST remember 674 the transmitted values for version number and signature 675 algorithm. 677 2. It waits for a reply in the form of a server_bpar message after 678 which it performs the following checks: 680 * The message must contain all the necessary information for the 681 TESLA protocol, as listed in Section 6.5.2. 683 * Verification of the message's signature. 685 If any information is missing or the server's signature cannot be 686 verified, the client MUST abort the broadcast run. If all checks 687 are successful, the client MUST remember all the broadcast 688 parameters received for later checks. 690 3. The client awaits time synchronization data in the form of a 691 server_broadcast message. Upon receipt, it performs the 692 following checks: 694 1. Proof that the MAC is based on a key that is not yet 695 disclosed. This is achieved via a disclosure schedule and 696 requires the loose time synchronization. If verified, the 697 packet will be buffered for later authentication. Otherwise, 698 the client MUST discard it. Note that the time information 699 included in the packet will not be used for synchronization 700 until its authenticity could be verified. 702 2. The client checks whether it already knows the disclosed key. 703 If so, the client SHOULD discard the packet to avoid a buffer 704 overrun. If not, the client verifies that the disclosed key 705 belongs to the one-way key chain by applying the one-way 706 function until equality with a previous disclosed key is 707 verified. If falsified, the client MUST discard the packet. 709 3. If the disclosed key is legitimate the client verifies the 710 authenticity of any packet that it received during the 711 corresponding time interval. If authenticity of a packet is 712 verified it is released from the buffer and the packet's time 713 information can be utilized. If the verification fails 714 authenticity is no longer given. In this case the client 715 MUST request authentic time from the server by means of a 716 unicast time request message. 718 See RFC 4082[RFC4082] for a detailed description of the packet 719 verification process. 721 The client MUST restart the broadcast sequence with a client_bpar 722 message Section 6.5.1 if the one-way key chain expires. 724 The client's behavior in broadcast mode can also be seen in Figure 2. 726 7.2. The Server 728 7.2.1. The Server in Unicast Mode 730 To support unicast mode, the server MUST be ready to perform the 731 following actions: 733 o Upon receipt of a client_assoc message, the server constructs and 734 sends a reply in the form of a server_assoc message as described 735 in Section 6.1.2. 737 o Upon receipt of a client_cert message, the server checks whether 738 it supports the given signature algorithm. If so, it constructs 739 and sends a server_cert message as described in Section 6.2.2. 741 o Upon receipt of a client_cook message, the server checks whether 742 it supports the given cryptographic algorithms. It then 743 calculates the cookie according to the formula given in 744 Section 5.1. With this, it MUST construct a server_cook message 745 as described in Section 6.3.2. 747 o Upon receipt of a time_request message, the server re-calculates 748 the cookie, then computes the necessary time synchronization data 749 and constructs a time_response message as given in Section 6.4.2. 751 The server MUST refresh its server seed periodically (see 752 Section 8.1). 754 7.2.2. The Server in Broadcast Mode 756 A broadcast server MUST also support unicast mode, in order to 757 provide the initial time synchronization which is a precondition for 758 any broadcast association. To support NTS broadcast, the server MUST 759 additionally be ready to perform the following actions: 761 o Upon receipt of a client_bpar message, the server constructs and 762 sends a server_bpar message as described in Section 6.5.2. 764 o The server follows the TESLA protocol in all other aspects, by 765 regularly sending server_broad messages as described in 766 Section 6.6.1, adhering to its own disclosure schedule. 768 It is also the server's responsibility to watch for the expiration 769 date of the one-way key chain and generate a new key chain 770 accordingly. 772 8. Server Seed Considerations 774 The server has to calculate a random seed which has to be kept 775 secret. The server MUST generate a seed for each supported hash 776 algorithm, see Section 9.1. 778 8.1. Server Seed Refresh 780 According to the requirements in 781 [I-D.ietf-tictoc-security-requirements] the server MUST refresh each 782 server seed periodically. As a consequence, the cookie memorized by 783 the client becomes obsolete. In this case the client cannot verify 784 the MAC attachted to subsequent time response messages and has to 785 respond accordingly by re-initiating the protocol with a cookie 786 request (Section 6.3). 788 8.2. Server Seed Algorithm 790 8.3. Server Seed Lifetime 792 9. Hash Algorithms and MAC Generation 794 9.1. Hash Algorithms 796 Hash algorithms are used at different points: calculation of the 797 cookie and the MAC, and hashing of the client's certificate. Client 798 and server negotiate a hash algorithm H during the association 799 message exchange (Section 6.1) at the beginning of a unicast run. 800 The selected algorithm H is used for all hashing processes in that 801 run. 803 In broadcast mode, hash algorithms are used as pseudo random 804 functions to construct the one-way key chain. Here, the utilized 805 hash algorithm is communicated by the server and non-negotiable. 807 The list of the hash algorithms supported by the server has to 808 fulfill the following requirements: 810 o it MUST NOT include SHA-1 or weaker algorithms, 812 o it MUST include SHA-256 or stronger algorithms. 814 Note 816 Any hash algorithm is prone to be compromised in the future. A 817 successful attack on a hash algorithm would enable any NTS client 818 to derive the server seed from their own cookie. Therefore, the 819 server MUST have separate seed values for its different supported 820 hash algorithms. This way, knowledge gained from an attack on a 821 hash algorithm H can at least only be used to compromise such 822 clients who use hash algorithm H as well. 824 9.2. MAC Calculation 826 For the calculation of the MAC, client and server are using a Keyed- 827 Hash Message Authentication Code (HMAC) approach [RFC2104]. The HMAC 828 is generated with the hash algorithm specified by the client (see 829 Section 9.1). 831 10. IANA Considerations 833 11. Security Considerations 835 11.1. Initial Verification of the Server Certificates 837 The client has to verify the validity of the certificates during the 838 certification message exchange (Section 6.2). Since it generally has 839 no reliable time during this initial communication phase, it is 840 impossible to verify the period of validity of the certificates. 841 Therefore, the client MUST use one of the following approaches: 843 o The validity of the certificates is preconditioned. Usually this 844 will be the case in corporate networks. 846 o The client ensures that the certificates are not revoked. To this 847 end, the client uses the Online Certificate Status Protocol (OCSP) 848 defined in [RFC6277]. 850 o The client requests a different service to get an initial time 851 stamp in order to be able to verify the certificates' periods of 852 validity. To this end, it can, e.g., use a secure shell 853 connection to a reliable host. Another alternative is to request 854 a time stamp from a Time Stamping Authority (TSA) by means of the 855 Time-Stamp Protocol (TSP) defined in [RFC3161]. 857 11.2. Revocation of Server Certificates 859 According to Section 8.1, it is the client's responsibility to 860 initiate a new association with the server after the server's 861 certificate expires. To this end the client reads the expiration 862 date of the certificate during the certificate message exchange 863 (Section 6.2). Besides, certificates may also be revoked prior to 864 the normal expiration date. To increase security the client MAY 865 verify the state of the server's certificate via OCSP periodically. 867 11.3. Usage of NTP Pools 869 The certification based authentication scheme described in Section 6 870 is not applicable to the concept of NTP pools. Therefore, NTS is not 871 able to provide secure usage of NTP pools. 873 11.4. Denial-of-Service in Broadcast Mode 875 TESLA authentication buffers packets for delayed authentication. 876 This makes the protocol vulnerable to flooding attacks, causing the 877 client to buffer excessive numbers of packets. To add stronger DoS 878 protection to the protocol, client and server use the "Not Re-using 879 Keys" scheme of TESLA as pointed out in section 3.7.2 of RFC 4082 880 [RFC4082]. In this scheme the server never uses a key for the MAC 881 generation more than once. Therefore the client can discard any 882 packet that contains a disclosed key it knows already, thus 883 preventing memory flooding attacks. 885 Note, an alternative approach to enhance TESLA's resistance against 886 DoS attacks involves the addition of a group MAC to each packet. 887 This requires the exchange of an additional shared key common to the 888 whole group. This adds additional complexity to the protocol and 889 hence is currently not considered in this document. 891 11.5. Delay Attack 893 In a packet delay attack, an adversary with the ability to act as a 894 MITM delays time synchronization packets between client and server 895 asymmetrically [I-D.ietf-tictoc-security-requirements]. This 896 prevents the client to measure the network delay, and hence its time 897 offset to the server, accurately [Mizrahi]. The delay attack does 898 not modifiy the content of the exchanged synchronization packets. 899 Therefore cryptographic means are not feasible to mitigate this 900 attack. However, serveral non-cryptographic precautions can be taken 901 in order to detect this attack. 903 o Usage of multiple time servers: this enables the client to detect 904 the attack provided that the adversary is unable to delay the 905 synchronizations packets between the majority of servers. This 906 approach is commonly used in NTP to exclude incorrect time servers 907 [RFC5905]. 909 o Multiple communication paths: The client and server are utilizing 910 different paths for packet exchange as described in the I-D 911 [I-D.shpiner-multi-path-synchronization]. The client can detect 912 the attack provided that the adversary is unable to manipulate the 913 majority of the available paths [Shpiner]. Note, that this 914 approach is not yet available, neither for NTP nor for PTP. 916 o The introduction of a threshold value for the delay time of the 917 synchronization packets. The client can discard a time server if 918 the packet delay time of this time server is larger than the 919 threshold value. 921 o Usage of an encrypted connection: the client exchanges all packets 922 with the time server over an encrypted connection (e.g. IPsec). 923 This measure does not mitigate the delay attack but it makes it 924 more difficult for the adversary to identify the time 925 synchronization packets. 927 12. Acknowledgements 929 The authors would like to thank Steven Bellovin, David Mills and Kurt 930 Roeckx for discussions and comments on the design of NTS. Also, 931 thanks to Harlan Stenn for his technical review and specific text 932 contributions to this document. 934 13. References 936 13.1. Normative References 938 [IEEE1588] 939 IEEE Instrumentation and Measurement Society. TC-9 Sensor 940 Technology, "IEEE standard for a precision clock 941 synchronization protocol for networked measurement and 942 control systems", 2008. 944 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 945 Hashing for Message Authentication", RFC 2104, February 946 1997. 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 952 "Internet X.509 Public Key Infrastructure Time-Stamp 953 Protocol (TSP)", RFC 3161, August 2001. 955 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 956 Briscoe, "Timed Efficient Stream Loss-Tolerant 957 Authentication (TESLA): Multicast Source Authentication 958 Transform Introduction", RFC 4082, June 2005. 960 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 961 Time Protocol Version 4: Protocol and Algorithms 962 Specification", RFC 5905, June 2010. 964 [RFC5906] Haberman, B. and D. Mills, "Network Time Protocol Version 965 4: Autokey Specification", RFC 5906, June 2010. 967 [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate 968 Status Protocol Algorithm Agility", RFC 6277, June 2011. 970 13.2. Informative References 972 [I-D.ietf-tictoc-security-requirements] 973 Mizrahi, T., "Security Requirements of Time Protocols in 974 Packet Switched Networks", draft-ietf-tictoc-security- 975 requirements-10 (work in progress), July 2014. 977 [I-D.shpiner-multi-path-synchronization] 978 Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- 979 Path Time Synchronization", draft-shpiner-multi-path- 980 synchronization-03 (work in progress), February 2014. 982 [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks 983 against time synchronization protocols", in Proceedings of 984 Precision Clock Synchronization for Measurement Control 985 and Communication, ISPCS 2012, pp. 1-6, September 2012. 987 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 988 Requirements for Security", BCP 106, RFC 4086, June 2005. 990 [Roettger] 991 Roettger, S., "Analysis of the NTP Autokey Procedures", 992 February 2012. 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 1000 +---------------------+ 1001 |Association Messages | 1002 +----------+----------+ 1003 | 1004 v 1005 +---------------------+ 1006 |Certificate Messages | 1007 +----------+----------+ 1008 | 1009 +------------------------------>o 1010 | | 1011 | v 1012 | +---------------+ 1013 | |Cookie Messages| 1014 | +-------+-------+ 1015 | | 1016 | o<------------------------------+ 1017 | | | 1018 | v | 1019 | +-------------------+ | 1020 | |Time Sync. Messages| | 1021 | +---------+---------+ | 1022 | | | 1023 | v | 1024 | +-----+ | 1025 | |Check| | 1026 | +--+--+ | 1027 | | | 1028 | /------------------+------------------\ | 1029 | v v v | 1030 | .-----------. .-------------. .-------. | 1031 | ( MAC Failure ) ( Nonce Failure ) ( Success ) | 1032 | '-----+-----' '------+------' '---+---' | 1033 | | | | | 1034 | v v v | 1035 | +-------------+ +-------------+ +--------------+ | 1036 | |Discard Data | |Discard Data | |Sync. Process | | 1037 | +-------------+ +------+------+ +------+-------+ | 1038 | | | | | 1039 | | | v | 1040 +-----------+ +------------------>o-----------+ 1042 Figure 1: The client's behavior in NTS unicast mode. 1044 +-----------------------------+ 1045 |Broadcast Parameter Messages | 1046 +--------------+--------------+ 1047 | 1048 o<--------------------------+ 1049 | | 1050 v | 1051 +-----------------------------+ | 1052 |Broadcast Time Sync. Message | | 1053 +--------------+--------------+ | 1054 | | 1055 +-------------------------------------->o | 1056 | | | 1057 | v | 1058 | +-------------------+ | 1059 | |Key and Auth. Check| | 1060 | +---------+---------+ | 1061 | | | 1062 | /----------------*----------------\ | 1063 | v v | 1064 | .---------. .---------. | 1065 | ( Verified ) ( Falsified ) | 1066 | '----+----' '----+----' | 1067 | | | | 1068 | v v | 1069 | +-------------+ +-------+ | 1070 | |Store Message| |Discard| | 1071 | +------+------+ +---+---+ | 1072 | | | | 1073 | v +---------o 1074 | +---------------+ | 1075 | |Check Previous | | 1076 | +-------+-------+ | 1077 | | | 1078 | /--------*--------\ | 1079 | v v | 1080 | .---------. .---------. | 1081 | ( Verified ) ( Falsified ) | 1082 | '----+----' '----+----' | 1083 | | | | 1084 | v v | 1085 | +-------------+ +-----------------+ | 1086 | |Sync. Process| |Discard Previous | | 1087 | +------+------+ +--------+--------+ | 1088 | | | | 1089 +-----------+ +-----------------------------------+ 1091 Figure 2: The client's behaviour in NTS broadcast mode. 1093 Appendix B. Extension Fields 1095 In Section 6, some new extension fields for NTP packets are 1096 introduced. They are listed here again, for reference. 1098 +------------------------+---------------+ 1099 | name | used in | 1100 +------------------------+---------------+ 1101 | "association" | client_assoc | 1102 | | server_assoc | 1103 | | | 1104 | "certificate request" | client_cert | 1105 | | | 1106 | "certificate" | server_cert | 1107 | | | 1108 | "cookie request" | client_cook | 1109 | | | 1110 | "cookie transmit" | server_cook | 1111 | | | 1112 | "time request" | time_request | 1113 | | | 1114 | "time response" | time_response | 1115 | | | 1116 | "broadcast request" | client_bpar | 1117 | | | 1118 | "broadcast parameters" | server_bpar | 1119 | | | 1120 | "broadcast message" | server_broad | 1121 +------------------------+---------------+ 1123 Appendix C. TICTOC Security Requirements 1125 The following table compares the NTS specifications against the 1126 TICTOC security requirements [I-D.ietf-tictoc-security-requirements]. 1128 +---------+------------------------------------+-------------+------+ 1129 | Section | Requirement from I-D tictoc | Requirement | NTS | 1130 | | security-requirements-05 | level | | 1131 +---------+------------------------------------+-------------+------+ 1132 | 5.1.1 | Authentication of Servers | MUST | OK | 1133 +---------+------------------------------------+-------------+------+ 1134 | 5.1.1 | Authorization of Servers | MUST | OK | 1135 +---------+------------------------------------+-------------+------+ 1136 | 5.1.2 | Recursive Authentication of | MUST | OK | 1137 | | Servers (Stratum 1) | | | 1138 +---------+------------------------------------+-------------+------+ 1139 | 5.1.2 | Recursive Authorization of Servers | MUST | OK | 1140 | | (Stratum 1) | | | 1141 +---------+------------------------------------+-------------+------+ 1142 | 5.1.3 | Authentication and Authorization | MAY | - | 1143 | | of Slaves | | | 1144 +---------+------------------------------------+-------------+------+ 1145 | 5.2 | Integrity protection. | MUST | OK | 1146 +---------+------------------------------------+-------------+------+ 1147 | 5.4 | Protection against DoS attacks | SHOULD | OK | 1148 +---------+------------------------------------+-------------+------+ 1149 | 5.5 | Replay protection | MUST | OK | 1150 +---------+------------------------------------+-------------+------+ 1151 | 5.6 | Key freshness. | MUST | OK | 1152 +---------+------------------------------------+-------------+------+ 1153 | | Security association. | SHOULD | OK | 1154 +---------+------------------------------------+-------------+------+ 1155 | | Unicast and multicast | SHOULD | OK | 1156 | | associations. | | | 1157 +---------+------------------------------------+-------------+------+ 1158 | 5.7 | Performance: no degradation in | MUST | OK | 1159 | | quality of time transfer. | | | 1160 +---------+------------------------------------+-------------+------+ 1161 | | Performance: lightweight | SHOULD | OK | 1162 | | computation | | | 1163 +---------+------------------------------------+-------------+------+ 1164 | | Performance: storage, bandwidth | SHOULD | OK | 1165 +---------+------------------------------------+-------------+------+ 1166 | 5.7 | Confidentiality protection | MAY | NO | 1167 +---------+------------------------------------+-------------+------+ 1168 | 5.9 | Protection against Packet Delay | SHOULD | NA*) | 1169 | | and Interception Attacks | | | 1170 +---------+------------------------------------+-------------+------+ 1171 | 5.10 | Secure mode | MUST | - | 1172 +---------+------------------------------------+-------------+------+ 1173 | | Hybrid mode | SHOULD | - | 1174 +---------+------------------------------------+-------------+------+ 1176 *) See discussion in section Section 11.5. 1178 Comparison of NTS sepecification against TICTOC security 1179 requirements. 1181 Appendix D. Broadcast Mode 1183 For the broadcast mode, NTS adopts the TESLA protocol, which is based 1184 on a one-way key chain. This appendix provides details on the 1185 generation and usage of the one-way key chain collected and assembled 1186 from [RFC4082]. Note that NTS is using the "not re-using keys" 1187 scheme of TESLA as described in section 3.7.2. of [RFC4082]. 1189 D.1. Server Preparations 1191 Server setup: 1193 1. The server determines a reasonable upper bound B on the network 1194 delay between itself and an arbitrary client, measured in 1195 milliseconds. 1197 2. It determines the number n+1 of keys in the one-way key chain. 1198 This yields the number n of keys that are usable to authenticate 1199 broadcast packets. This number n is therefore also the number of 1200 time intervals during which the server can send authenticated 1201 broadcast messages before it has to calculate a new key chain. 1203 3. It divides time into n uniform intervals I_1, I_2, ..., I_n. 1204 Each of these time intervals has length L, measured in 1205 milliseconds. In order to fulfill the requirement 3.7.2. of RFC 1206 4082 the time interval L has to be smaller than the time interval 1207 between the broadcast messages. 1209 4. The server generates a random key K_n. 1211 5. Using a one-way function F, the server generates a one-way chain 1212 of n+1 keys K_0, K_1, ..., K_{n} according to 1214 K_i = F(K_{i+1}). 1216 6. Using another one-way function F', it generates a sequence of n+1 1217 MAC keys K'_0, K'_1, ..., K'_{n-1} according to 1219 K'_i = F'(K_i). 1221 7. Each MAC key K'_i is assigned to the time interval I_i. 1223 8. The server determines the key disclosure delay d, which is the 1224 number of intervals between using a key and disclosing it. Note 1225 that although security is still provided for all choices d>0, the 1226 choice still makes a difference: 1228 * If d is chosen too short, the client might discards packets 1229 because it fails to verify that the key used for their MAC has 1230 not been yet disclosed. 1232 * If d is chosen too long, the received packets have to be 1233 buffered for a unnecessarily long time before they can be 1234 verified by the client and subsequently be utilized for time 1235 synchronization. 1237 The server SHOULD calculate d according to 1239 d = ceil( 2*B / L) + 1, 1241 where ceil gives the smallest integer greater than or equal to 1242 its argument. 1244 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1245 Generation of Keys 1247 F F F F 1248 K_0 <-------- K_1 <-------- ... <-------- K_{n-1} <-------- K_n 1249 | | | | 1250 | | | | 1251 | F' | F' | F' | F' 1252 | | | | 1253 v v v v 1254 K'_0 K'_1 ... K'_{n-1} K'_n 1255 [______________|____ ____|_________________|__________] 1256 I_1 ... I_{n-1} I_n 1258 Course of Time/Usage of Keys 1259 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 1261 A Schematic explanation on the TESLA protocol's one-way key chain 1263 D.2. Client Preparation 1265 A client needs the following information in order to participate in a 1266 TESLA broadcast. 1268 o One key K_i from the one-way key chain, which has to be 1269 authenticated as belonging to the server. Typically, this will be 1270 K_0. 1272 o The disclosure schedule of the keys. This consists of: 1274 * the length n of the one-way key chain, 1276 * the length L of the time intervals I_1, I_2, ..., I_n, 1278 * the starting time T_i of an interval I_i. Typically this is 1279 the starting time T_1 of the first interval; 1281 * the disclosure delay d. 1283 o The one-way function F used to recursively derive the keys in the 1284 one-way key chain, 1286 o The second one-way function F' used to derive the MAC keys K'_0, 1287 K'_1, ... , K'_n from the keys in the one-way chain. 1289 o An upper bound D_t on how far its own clock is "behind" that of 1290 the server. 1292 Note that if D_t is greater than (d - 1) * L, then some authentic 1293 packets might be discarded. If D_t is greater than d * L, then all 1294 authentic packets will be discarded. In the latter case, the client 1295 should not participate in the broadcast, since there will be no 1296 benefit in doing so. 1298 D.3. Sending Authenticated Broadcast Packets 1300 During each time interval I_i, the server sends one authenticated 1301 broadcast packet P_i. This packet consists of: 1303 o a message M_i, 1305 o the index i (in case a packet arrives late), 1307 o a MAC authenticating the message M_i, with K'_i used as key, 1309 o the key K_{i-d}, which is included for disclosure. 1311 D.4. Authentication of Received Packets 1313 When a client receives a packet P_i as described above, it first 1314 checks that it has not received a packet with associated index i 1315 before. This is done to avoid replay/flooding attacks. A packet 1316 that fails this test is discarded. 1318 Next, the client checks that, according to the disclosure schedule 1319 and with respect to the upper bound D_t determined above, the server 1320 cannot have disclosed the key K_i yet. Specifically, it needs to 1321 check that the server's clock cannot read a time that is in time 1322 interval I_{i+d} or later. Since it works under the assumption that 1323 the server's clock is not more than D_t "ahead" of the client's 1324 clock, the client can calculate an upper bound t_i for the server's 1325 clock at the time when P_i arrived by 1327 t_i = R + D_t, 1329 where R is the client's clock at the arrival of P_i. This implies 1330 that at the time of arrival of P_i, the server could have been in 1331 interval I_x at most, with 1333 x = floor((t_i - T_1) / L), 1335 where floor gives the greatest integer less than or equal to its 1336 argument. The client now needs to verify that 1338 x < i+d 1340 is valid (see also section 3.5 of [RFC4082]). If falsified, it is 1341 discarded. 1343 Next the client verifies that a newly disclosed key K_{i-d} belongs 1344 to the one-way key chain. To this end it verifies identity with some 1345 earlier disclosed key by recursively applies the one-way function F 1346 to K_{i-d} (see Clause 3.5 in RFC 4082, item 3). 1348 If a packet P_i passes all tests listed above, it is stored for later 1349 authentication. Also, if at this time there is a package with index 1350 i-d already buffered, then the client uses the disclosed key K_{i-d} 1351 to derive K'_{i-d} and uses that to check the MAC included in package 1352 P_{i-d}. On success, it regards M_{i-d} as authenticated. 1354 Appendix E. Random Number Generation 1356 At various points of the protocol, the generation of random numbers 1357 is required. The employed methods of generation need to be 1358 cryptographically secure. See [RFC4086] for guidelines concerning 1359 this topic. 1361 Authors' Addresses 1363 Dieter Sibold 1364 Physikalisch-Technische Bundesanstalt 1365 Bundesallee 100 1366 Braunschweig D-38116 1367 Germany 1369 Phone: +49-(0)531-592-8420 1370 Fax: +49-531-592-698420 1371 Email: dieter.sibold@ptb.de 1373 Stephen Roettger 1375 Email: stephen.roettger@googlemail.com 1376 Kristof Teichel 1377 Physikalisch-Technische Bundesanstalt 1378 Bundesallee 100 1379 Braunschweig D-38116 1380 Germany 1382 Phone: +49-(0)531-592-8421 1383 Email: kristof.teichel@ptb.de