idnits 2.17.1 draft-ietf-ntp-network-time-security-06.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 (January 16, 2015) is 3359 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 4082 ** Obsolete normative reference: RFC 6277 (Obsoleted by RFC 6960) ** Downref: Normative reference to an Informational RFC: RFC 7384 == Outdated reference: A later version (-06) exists of draft-ietf-ntp-cms-for-nts-message-00 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group D. Sibold 3 Internet-Draft PTB 4 Intended status: Standards Track S. Roettger 5 Expires: July 20, 2015 Google Inc. 6 K. Teichel 7 PTB 8 January 16, 2015 10 Network Time Security 11 draft-ietf-ntp-network-time-security-06.txt 13 Abstract 15 This document describes Network Time Security (NTS), a collection of 16 measures that enable secure time synchronization with time servers 17 using protocols like the Network Time Protocol (NTP) or the Precision 18 Time Protocol (PTP). Its design considers the special requirements 19 of precise timekeeping which are described in Security Requirements 20 of Time Protocols in Packet 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 July 20, 2015. 45 Copyright Notice 47 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 4 66 5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 67 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 5 68 6.1. Association Messages . . . . . . . . . . . . . . . . . . 6 69 6.1.1. Message Type: "client_assoc" . . . . . . . . . . . . 6 70 6.1.2. Message Type: "server_assoc" . . . . . . . . . . . . 6 71 6.2. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 7 72 6.2.1. Message Type: "client_cook" . . . . . . . . . . . . . 7 73 6.2.2. Message Type: "server_cook" . . . . . . . . . . . . . 7 74 6.3. Unicast Time Synchronisation Messages . . . . . . . . . . 8 75 6.3.1. Message Type: "time_request" . . . . . . . . . . . . 8 76 6.3.2. Message Type: "time_response" . . . . . . . . . . . . 8 77 6.4. Broadcast Parameter Messages . . . . . . . . . . . . . . 9 78 6.4.1. Message Type: "client_bpar" . . . . . . . . . . . . . 9 79 6.4.2. Message Type: "server_bpar" . . . . . . . . . . . . . 9 80 6.5. Broadcast Messages . . . . . . . . . . . . . . . . . . . 10 81 6.5.1. Message Type: "server_broad" . . . . . . . . . . . . 10 82 6.6. Broadcast Key Check . . . . . . . . . . . . . . . . . . . 10 83 6.6.1. Message Type: "client_keycheck" . . . . . . . . . . . 10 84 6.6.2. Message Type: "server_keycheck" . . . . . . . . . . . 11 85 7. Message Dependencies . . . . . . . . . . . . . . . . . . . . 11 86 8. Server Seed Considerations . . . . . . . . . . . . . . . . . 12 87 9. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 13 88 9.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 13 89 9.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 13 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 13 93 11.2. Initial Verification of the Server Certificates . . . . 14 94 11.3. Revocation of Server Certificates . . . . . . . . . . . 14 95 11.4. Mitigating Denial-of-Service for broadcast packets . . . 14 96 11.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 15 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 100 13.2. Informative References . . . . . . . . . . . . . . . . . 17 101 Appendix A. TICTOC Security Requirements . . . . . . . . . . . . 17 102 Appendix B. Using TESLA for Broadcast-Type Messages . . . . . . 19 103 B.1. Server Preparation . . . . . . . . . . . . . . . . . . . 19 104 B.2. Client Preparation . . . . . . . . . . . . . . . . . . . 20 105 B.3. Sending Authenticated Broadcast Packets . . . . . . . . . 21 106 B.4. Authentication of Received Packets . . . . . . . . . . . 21 107 Appendix C. Random Number Generation . . . . . . . . . . . . . . 23 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 110 1. Introduction 112 Time synchronization protocols are increasingly utilized to 113 synchronize clocks in networked infrastructures. The reliable 114 performance of such infrastructures can be degraded seriously by 115 successful attacks against the time synchronization protocol. 116 Therefore, time synchronization protocols have to be secured if they 117 are applied in environments that are prone to malicious attacks. 118 This can be accomplished either by utilization of external security 119 protocols, like IPsec or TLS, or by intrinsic security measures of 120 the time synchronization protocol. 122 The two most popular time synchronization protocols, the Network Time 123 Protocol (NTP) [RFC5905] and the Precision Time Protocol (PTP) 124 [IEEE1588], currently do not provide adequate intrinsic security 125 precautions. This document specifies security measures which enable 126 these protocols to verify the authenticity of the time server and the 127 integrity of the time synchronization protocol packets. 129 The given measures are specified with the prerequisite in mind that 130 precise timekeeping can only be accomplished with stateless time 131 synchronization communication, which excludes the utilization of 132 standard security protocols, like IPsec or TLS, for time 133 synchronization messages. This prerequisite corresponds with the 134 requirement that a security mechanism for timekeeping must be 135 designed in such a way that it does not degrade the quality of the 136 time transfer [RFC7384]. 138 Note: 140 It is recommended that details on how to apply NTS to specific 141 time synchronization protocols be formulated in separate 142 documents, with one separate document for each protocol. 144 2. Security Threats 146 A profound analysis of security threats and requirements for time 147 synchronization protocols can be found in the "Security Requirements 148 of Time Protocols in Packet Switched Networks" [RFC7384]. 150 3. Objectives 152 The objectives of the NTS specification are as follows: 154 o Authenticity: NTS enables a client/slave to authenticate its time 155 server(s)/master(s). 157 o Integrity: NTS protects the integrity of time synchronization 158 protocol packets via a message authentication code (MAC). 160 o Confidentiality: NTS does not provide confidentiality protection 161 of the time synchronization packets. 163 o Integration with protocols: NTS can be used to secure different 164 time synchronization protocols, specifically at least NTP and PTP. 165 An client or server running an NTS-secured version of a time 166 protocol does not negatively affect other participants who are 167 running unsecured versions of that protocol. 169 4. Terms and Abbreviations 171 MITM Man In The Middle 173 NTS Network Time Security 175 TESLA Timed Efficient Stream Loss-tolerant Authentication 177 5. NTS Overview 179 NTS applies X.509 certificates to verify the authenticity of the time 180 server/master and to exchange a symmetric key, the so-called cookie. 181 This cookie is then used to protect the authenticity and the 182 integrity of subsequent unicast-type time synchronization packets. 183 This is done by means of a Message Authentication Code (MAC), which 184 is attached to each time synchronization packet. The calculation of 185 the MAC includes the whole time synchronization packet and the cookie 186 which is shared between client and server. The cookie is calculated 187 according to: 189 cookie = MSB_ (HMAC(server seed, H(certificate of client))), 191 with the server seed as the key, where H is a hash function, and 192 where the function MSB_ cuts off the b most significant bits of 193 the result of the HMAC function. The server seed is a random value 194 of bit length b that the server possesses, which has to be kept 195 secret. The cookie never changes as long as the server seed stays 196 the same, but the server seed has to be refreshed periodically in 197 order to provide key freshness as required in [RFC7384]. See 198 Section 8 for details on seed refreshing. 200 Since the server does not keep a state of the client, it has to 201 recalculate the cookie each time it receives a unicast time 202 synchronization request from the client. To this end, the client has 203 to attach the hash value of its certificate to each request (see 204 Section 6.3). 206 For broadcast-type messages, authenticity and integrity of the time 207 synchronization packets are also ensured by a MAC, which is attached 208 to the time synchronization packet by the sender. Verification of 209 the broadcast-type packets' authenticity is based on the TESLA 210 protocol, in particular on its "not re-using keys" scheme, see 211 Section 3.7.2 of [RFC4082]. TESLA uses a one-way chain of keys, 212 where each key is the output of a one-way function applied to the 213 previous key in the chain. The last element of the chain is shared 214 securely with all clients. The server splits time into intervals of 215 uniform duration and assigns each key to an interval in reverse 216 order, starting with the penultimate. At each time interval, the 217 server sends a broadcast packet appended by a MAC, calculated using 218 the corresponding key, and the key of the previous disclosure 219 interval. The client verifies the MAC by buffering the packet until 220 disclosure of the key in its associated disclosure interval occurs. 221 In order to be able to verify the validity of the key, the client has 222 to be loosely time synchronized with the server. This has to be 223 accomplished during the initial client server exchange between the 224 broadcast client and the server. In addition, NTS uses another, more 225 rigorous check than what is used in the TESLA protocol. For a more 226 detailed description of how NTS employs and customizes TESLA, see 227 Appendix B. 229 6. Protocol Messages 231 This section describes the types of messages needed for secure time 232 synchronization with NTS. 234 For some guidance on how these message types can be realized in 235 practice, and integrated into the communication flow of existing time 236 synchronization protocols, see [I-D.ietf-ntp-cms-for-nts-message], a 237 companion document for NTS. Said document describes ASN.1 encodings 238 for those message parts that have to be added to a time 239 synchronization protocol for security reasons as well as CMS 240 (Cryptographic Message Syntax, see [RFC5652]) conventions that can be 241 used to get the cryptographic aspects right. 243 6.1. Association Messages 245 In this message exchange, the hash and encryption algorithms that are 246 used throughout the protocol are negotiated. In addition , the 247 client receives the certification chain up to a trusted anchor. With 248 the established certification chain the client is able to verify the 249 server's signatures and, hence, the authenticity of future NTS 250 messages from the server is ensured. 252 6.1.1. Message Type: "client_assoc" 254 The protocol sequence starts with the client sending an association 255 message, called client_assoc. This message contains 257 o the NTS message ID "client_assoc", 259 o the version number of NTS that the client wants to use (this 260 SHOULD be the highest version number that it supports), 262 o the hostname of the client, 264 o a selection of accepted hash algorithms, and 266 o a selection of accepted encryption algorithms. 268 6.1.2. Message Type: "server_assoc" 270 This message is sent by the server upon receipt of client_assoc. It 271 contains 273 o the NTS message ID "server_assoc", 275 o the version number used for the rest of the protocol (which SHOULD 276 be determined as the minimum over the client's suggestion in the 277 client_assoc message and the highest supported by the server), 279 o the hostname of the server, 281 o the server's choice of algorithm for encryption and for 282 cryptographic hashing, all of which MUST be chosen from the 283 client's proposals, 285 o a signature, calculated over the data listed above, with the 286 server's private key and according to the signature algorithm 287 which is also used for the certificates that are included (see 288 below), and 290 o a chain of certificates, which starts at the server and goes up to 291 a trusted authority; each certificate MUST be certified by the one 292 directly following it. 294 6.2. Cookie Messages 296 During this message exchange, the server transmits a secret cookie to 297 the client securely. The cookie will later be used for integrity 298 protection during unicast time synchronization. 300 6.2.1. Message Type: "client_cook" 302 This message is sent by the client upon successful authentication of 303 the server. In this message, the client requests a cookie from the 304 server. The message contains 306 o the NTS message ID "client_cook", 308 o the negotiated version number, 310 o the negotiated signature algorithm, 312 o the negotiated encryption algorithm, 314 o a nonce, 316 o the negotiated hash algorithm H, 318 o the client's certificate. 320 6.2.2. Message Type: "server_cook" 322 This message is sent by the server upon receipt of a client_cook 323 message. The server generates the hash of the client's certificate, 324 as conveyed during client_cook, in order to calculate the cookie 325 according to Section 5. This message contains 327 o the NTS message ID "server_cook" 329 o the version number as transmitted in client_cook, 330 o a concatenated datum which is encrypted with the client's public 331 key, according to the encryption algorithm transmitted in the 332 client_cook message. The concatenated datum contains 334 * the nonce transmitted in client_cook, and 336 * the cookie. 338 o a signature, created with the server's private key, calculated 339 over all of the data listed above. This signature MUST be 340 calculated according to the transmitted signature algorithm from 341 the client_cook message. 343 6.3. Unicast Time Synchronisation Messages 345 In this message exchange, the usual time synchronization process is 346 executed, with the addition of integrity protection for all messages 347 that the server sends. This message can be repeatedly exchanged as 348 often as the client desires and as long as the integrity of the 349 server's time responses is verified successfully. 351 6.3.1. Message Type: "time_request" 353 This message is sent by the client when it requests a time exchange. 354 It contains 356 o the NTS message ID "time_request", 358 o the negotiated version number, 360 o a nonce, 362 o the negotiated hash algorithm H, 364 o the hash of the client's certificate under H. 366 6.3.2. Message Type: "time_response" 368 This message is sent by the server after it has received a 369 time_request message. Prior to this the server MUST recalculate the 370 client's cookie by using the hash of the client's certificate and the 371 transmitted hash algorithm. The message contains 373 o the NTS message ID "time_response", 375 o the version number as transmitted in time_request, 377 o the server's time synchronization response data, 378 o the nonce transmitted in time_request, 380 o a MAC (generated with the cookie as key) for verification of all 381 of the above data. 383 6.4. Broadcast Parameter Messages 385 In this message exchange, the client receives the necessary 386 information to execute the TESLA protocol in a secured broadcast 387 association. The client can only initiate a secure broadcast 388 association after a successful unicast run. 390 See Appendix B for more details on TESLA. 392 6.4.1. Message Type: "client_bpar" 394 This message is sent by the client in order to establish a secured 395 time broadcast association with the server. It contains 397 o the NTS message ID "client_bpar", 399 o the NTS version number negotiated during association in unicast 400 mode, 402 o the client's hostname, and 404 o the signature algorithm negotiated during unicast. 406 6.4.2. Message Type: "server_bpar" 408 This message is sent by the server upon receipt of a client_bpar 409 message during the broadcast loop of the server. It contains 411 o the NTS message ID "server_bpar", 413 o the version number as transmitted in the client_bpar message, 415 o the one-way functions used for building the key chain, and 417 o the disclosure schedule of the keys. This contains: 419 * the last key of the key chain, 421 * time interval duration, 423 * the disclosure delay (number of intervals between use and 424 disclosure of a key), 426 * the time at which the next time interval will start, and 428 * the next interval's associated index. 430 o The message also contains a signature signed by the server with 431 its private key, verifying all the data listed above. 433 6.5. Broadcast Messages 435 Via this message, the server keeps sending broadcast time 436 synchronization messages to all participating clients. 438 6.5.1. Message Type: "server_broad" 440 This message is sent by the server over the course of its broadcast 441 schedule. It is part of any broadcast association. It contains 443 o the NTS message ID "server_broad", 445 o the version number that the server is working under, 447 o time broadcast data, 449 o the index that belongs to the current interval (and therefore 450 identifies the current, yet undisclosed, key), 452 o the disclosed key of the previous disclosure interval (current 453 time interval minus disclosure delay), 455 o a MAC, calculated with the key for the current time interval, 456 verifying 458 * the message ID, 460 * the version number, and 462 * the time data. 464 6.6. Broadcast Key Check 466 This message exchange is performed for an additional check of packet 467 timeliness in the course of the TESLA scheme, see Appendix B. 469 6.6.1. Message Type: "client_keycheck" 471 A message of this type is sent by the client in order to initiate an 472 additional check of packet timeliness for the TESLA scheme. It 473 contains 474 o the NTS message ID "client_keycheck", 476 o the NTS version number negotiated during association in unicast 477 mode, 479 o a nonce, 481 o an interval number from the TESLA disclosure schedule, 483 o the hash algorithm H negotiated in unicast mode, and 485 o the hash of the client's certificate under H. 487 6.6.2. Message Type: "server_keycheck" 489 A message of this type is sent by the server upon receipt of a 490 client_keycheck message during the broadcast loop of the server. 491 Prior to this, the server MUST recalculate the client's cookie by 492 using the hash of the client's certificate and the transmitted hash 493 algorithm. It contains 495 o the NTS message ID "server_keycheck" 497 o the version number as transmitted in "client_keycheck, 499 o the nonce transmitted in the client_keycheck message, 501 o the interval number transmitted in the client_keycheck message, 502 and 504 o a MAC (generated with the cookie as key) for verification of all 505 of the above data. 507 7. Message Dependencies 508 +--------------------+ 509 |Association Exchange| 510 +--------------------+ 511 | 512 At least one successful 513 | 514 v 515 +---------------+ 516 |Cookie Exchange| 517 +---------------+ 518 | 519 At least one successful 520 | 521 v 522 +----------------------------------------+ 523 |Unicast Time Synchronization Exchange(s)| 524 +----------------------------------------+ 525 | 526 Until sufficient accuracy has been reached 527 | 528 v 529 +----------------------------+ 530 |Broadcast Parameter Exchange| 531 +----------------------------+ 532 | 533 One successful per client 534 | 535 v 536 +----------------------------------------+ 537 |Broadcast Time Synchronization Reception| 538 +----------------------------------------+ 539 | 540 Whenever deemed necessary 541 | 542 v 543 +-----------------+ 544 |Keycheck Exchange| 545 +-----------------+ 547 8. Server Seed Considerations 549 The server has to calculate a random seed which has to be kept 550 secret. The server MUST generate a seed for each supported hash 551 algorithm, see Section 9.1. 553 According to the requirements in [RFC7384], the server MUST refresh 554 each server seed periodically. Consequently, the cookie memorized by 555 the client becomes obsolete. In this case, the client cannot verify 556 the MAC attached to subsequent time response messages and has to 557 respond accordingly by re-initiating the protocol with a cookie 558 request (Section 6.2). 560 9. Hash Algorithms and MAC Generation 562 9.1. Hash Algorithms 564 Hash algorithms are used at different points: calculation of the 565 cookie and the MAC, and hashing of the client's certificate. The 566 client and the server negotiate a hash algorithm H during the 567 association message exchange (Section 6.1) at the beginning of a 568 unicast run. The selected algorithm H is used for all hashing 569 processes in that run. 571 In the TESLA scheme, hash algorithms are used as pseudo-random 572 functions to construct the one-way key chain. Here, the utilized 573 hash algorithm is communicated by the server and is non-negotiable. 575 Note: 577 Any hash algorithm is prone to be compromised in the future. A 578 successful attack on a hash algorithm would enable any NTS client 579 to derive the server seed from its own cookie. Therefore, the 580 server MUST have separate seed values for its different supported 581 hash algorithms. This way, knowledge gained from an attack on a 582 hash algorithm H can at least only be used to compromise such 583 clients who use hash algorithm H as well. 585 9.2. MAC Calculation 587 For the calculation of the MAC, client and server use a Keyed-Hash 588 Message Authentication Code (HMAC) approach [RFC2104]. The HMAC is 589 generated with the hash algorithm specified by the client (see 590 Section 9.1). 592 10. IANA Considerations 594 11. Security Considerations 596 11.1. Privacy 598 tbd 600 11.2. Initial Verification of the Server Certificates 602 The client has to verify the validity of the certificates during the 603 certification message exchange (Section 6.1.2). Since it generally 604 has no reliable time during this initial communication phase, it is 605 impossible to verify the period of validity of the certificates. 606 Therefore, the client MUST use one of the following approaches: 608 o The validity of the certificates is preconditioned. Usually this 609 will be the case in corporate networks. 611 o The client ensures that the certificates are not revoked. To this 612 end, the client uses the Online Certificate Status Protocol (OCSP) 613 defined in [RFC6277]. 615 o The client requests a different service to get an initial time 616 stamp in order to be able to verify the certificates' periods of 617 validity. To this end, it can, e.g., use a secure shell 618 connection to a reliable host. Another alternative is to request 619 a time stamp from a Time Stamping Authority (TSA) by means of the 620 Time-Stamp Protocol (TSP) defined in [RFC3161]. 622 11.3. Revocation of Server Certificates 624 According to Section 8, it is the client's responsibility to initiate 625 a new association with the server after the server's certificate 626 expires. To this end, the client reads the expiration date of the 627 certificate during the certificate message exchange (Section 6.1.2). 628 Furthermore, certificates may also be revoked prior to the normal 629 expiration date. To increase security the client MAY periodically 630 verify the state of the server's certificate via OCSP. 632 11.4. Mitigating Denial-of-Service for broadcast packets 634 TESLA authentication buffers packets for delayed authentication. 635 This makes the protocol vulnerable to flooding attacks, causing the 636 client to buffer excessive numbers of packets. To add stronger DoS 637 protection to the protocol, the client and the server use the "not 638 re-using keys" scheme of TESLA as pointed out in Section 3.7.2 of RFC 639 4082 [RFC4082]. In this scheme the server never uses a key for the 640 MAC generation more than once. Therefore, the client can discard any 641 packet that contains a disclosed key it already knows, thus 642 preventing memory flooding attacks. 644 Note that an alternative approach to enhance TESLA's resistance 645 against DoS attacks involves the addition of a group MAC to each 646 packet. This requires the exchange of an additional shared key 647 common to the whole group. This adds additional complexity to the 648 protocol and hence is currently not considered in this document. 650 11.5. Delay Attack 652 In a packet delay attack, an adversary with the ability to act as a 653 MITM delays time synchronization packets between client and server 654 asymmetrically [RFC7384]. This prevents the client from accurately 655 measuring the network delay, and hence its time offset to the server 656 [Mizrahi]. The delay attack does not modify the content of the 657 exchanged synchronization packets. Therefore, cryptographic means do 658 not provide a feasible way to mitigate this attack. However, several 659 non-cryptographic precautions can be taken in order to detect this 660 attack. 662 1. Usage of multiple time servers: this enables the client to detect 663 the attack, provided that the adversary is unable to delay the 664 synchronization packets between the majority of servers. This 665 approach is commonly used in NTP to exclude incorrect time 666 servers [RFC5905]. 668 2. Multiple communication paths: The client and server utilize 669 different paths for packet exchange as described in the I-D 670 [I-D.shpiner-multi-path-synchronization]. The client can detect 671 the attack, provided that the adversary is unable to manipulate 672 the majority of the available paths [Shpiner]. Note that this 673 approach is not yet available, neither for NTP nor for PTP. 675 3. Usage of an encrypted connection: the client exchanges all 676 packets with the time server over an encrypted connection (e.g. 677 IPsec). This measure does not mitigate the delay attack, but it 678 makes it more difficult for the adversary to identify the time 679 synchronization packets. 681 4. For unicast-type messages: Introduction of a threshold value for 682 the delay time of the synchronization packets. The client can 683 discard a time server if the packet delay time of this time 684 server is larger than the threshold value. 686 Additional provision against delay attacks has to be taken for 687 broadcast-type messages. This mode relies on the TESLA scheme which 688 is based on the requirement that a client and the broadcast server 689 are loosely time synchronized. Therefore, a broadcast client has to 690 establish time synchronization with its broadcast server before it 691 starts utilizing broadcast messages for time synchronization. To 692 this end, it initially establishes a unicast association with its 693 broadcast server until time synchronization and calibration of the 694 packet delay time is achieved. After that it establishes a broadcast 695 association with the broadcast server and utilizes TESLA to verify 696 integrity and authenticity of any received broadcast packets. 698 An adversary who is able to delay broadcast packets can cause a time 699 adjustment at the receiving broadcast clients. If the adversary 700 delays broadcast packets continuously, then the time adjustment will 701 accumulate until the loose time synchronization requirement is 702 violated, which breaks the TESLA scheme. To mitigate this 703 vulnerability the security condition in TESLA has to be supplemented 704 by an additional check in which the client, upon receipt of a 705 broadcast message, verifies the status of the corresponding key via a 706 unicast message exchange with the broadcast server (see Appendix B.4 707 for a detailed description of this check). Note that a broadcast 708 client should also apply the above-mentioned precautions as far as 709 possible. 711 12. Acknowledgements 713 The authors would like to thank Russ Housley, Steven Bellovin, David 714 Mills and Kurt Roeckx for discussions and comments on the design of 715 NTS. Also, thanks go to Harlan Stenn for his technical review and 716 specific text contributions to this document. 718 13. References 720 13.1. Normative References 722 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 723 Hashing for Message Authentication", RFC 2104, February 724 1997. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 730 "Internet X.509 Public Key Infrastructure Time-Stamp 731 Protocol (TSP)", RFC 3161, August 2001. 733 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 734 Briscoe, "Timed Efficient Stream Loss-Tolerant 735 Authentication (TESLA): Multicast Source Authentication 736 Transform Introduction", RFC 4082, June 2005. 738 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 739 RFC 5652, September 2009. 741 [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate 742 Status Protocol Algorithm Agility", RFC 6277, June 2011. 744 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 745 Packet Switched Networks", RFC 7384, October 2014. 747 13.2. Informative References 749 [I-D.ietf-ntp-cms-for-nts-message] 750 Sibold, D., Roettger, S., Teichel, K., and R. Housley, 751 "Protecting Network Time Security Messages with the 752 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 753 for-nts-message-00 (work in progress), October 2014. 755 [I-D.shpiner-multi-path-synchronization] 756 Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- 757 Path Time Synchronization", draft-shpiner-multi-path- 758 synchronization-03 (work in progress), February 2014. 760 [IEEE1588] 761 IEEE Instrumentation and Measurement Society. TC-9 Sensor 762 Technology, "IEEE standard for a precision clock 763 synchronization protocol for networked measurement and 764 control systems", 2008. 766 [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks 767 against time synchronization protocols", in Proceedings of 768 Precision Clock Synchronization for Measurement Control 769 and Communication, ISPCS 2012, pp. 1-6, September 2012. 771 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 772 Requirements for Security", BCP 106, RFC 4086, June 2005. 774 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 775 Time Protocol Version 4: Protocol and Algorithms 776 Specification", RFC 5905, June 2010. 778 [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time 779 Protocols", in Proceedings of Precision Clock 780 Synchronization for Measurement Control and Communication, 781 ISPCS 2013, pp. 1-6, September 2013. 783 Appendix A. TICTOC Security Requirements 785 The following table compares the NTS specifications against the 786 TICTOC security requirements [RFC7384]. 788 +---------+------------------------------------+-------------+------+ 789 | Section | Requirement from I-D tictoc | Requirement | NTS | 790 | | security-requirements-05 | level | | 791 +---------+------------------------------------+-------------+------+ 792 | 5.1.1 | Authentication of Servers | MUST | OK | 793 +---------+------------------------------------+-------------+------+ 794 | 5.1.1 | Authorization of Servers | MUST | OK | 795 +---------+------------------------------------+-------------+------+ 796 | 5.1.2 | Recursive Authentication of | MUST | OK | 797 | | Servers (Stratum 1) | | | 798 +---------+------------------------------------+-------------+------+ 799 | 5.1.2 | Recursive Authorization of Servers | MUST | OK | 800 | | (Stratum 1) | | | 801 +---------+------------------------------------+-------------+------+ 802 | 5.1.3 | Authentication and Authorization | MAY | - | 803 | | of Slaves | | | 804 +---------+------------------------------------+-------------+------+ 805 | 5.2 | Integrity protection | MUST | OK | 806 +---------+------------------------------------+-------------+------+ 807 | 5.4 | Protection against DoS attacks | SHOULD | OK | 808 +---------+------------------------------------+-------------+------+ 809 | 5.5 | Replay protection | MUST | OK | 810 +---------+------------------------------------+-------------+------+ 811 | 5.6 | Key freshness | MUST | OK | 812 +---------+------------------------------------+-------------+------+ 813 | | Security association | SHOULD | OK | 814 +---------+------------------------------------+-------------+------+ 815 | | Unicast and multicast associations | SHOULD | OK | 816 +---------+------------------------------------+-------------+------+ 817 | 5.7 | Performance: no degradation in | MUST | OK | 818 | | quality of time transfer | | | 819 +---------+------------------------------------+-------------+------+ 820 | | Performance: lightweight | SHOULD | OK | 821 | | computation | | | 822 +---------+------------------------------------+-------------+------+ 823 | | Performance: storage, bandwidth | SHOULD | OK | 824 +---------+------------------------------------+-------------+------+ 825 | 5.7 | Confidentiality protection | MAY | NO | 826 +---------+------------------------------------+-------------+------+ 827 | 5.9 | Protection against Packet Delay | SHOULD | NA*) | 828 | | and Interception Attacks | | | 829 +---------+------------------------------------+-------------+------+ 830 | 5.10 | Secure mode | MUST | - | 831 +---------+------------------------------------+-------------+------+ 832 | | Hybrid mode | SHOULD | - | 833 +---------+------------------------------------+-------------+------+ 835 *) See discussion in Section 11.5. 837 Comparison of NTS specification against TICTOC security requirements. 839 Appendix B. Using TESLA for Broadcast-Type Messages 841 For broadcast-type messages , NTS adopts the TESLA protocol with some 842 customizations. This appendix provides details on the generation and 843 usage of the one-way key chain collected and assembled from 844 [RFC4082]. Note that NTS uses the "not re-using keys" scheme of 845 TESLA as described in Section 3.7.2. of [RFC4082]. 847 B.1. Server Preparation 849 Server setup: 851 1. The server determines a reasonable upper bound B on the network 852 delay between itself and an arbitrary client, measured in 853 milliseconds. 855 2. It determines the number n+1 of keys in the one-way key chain. 856 This yields the number n of keys that are usable to authenticate 857 broadcast packets. This number n is therefore also the number of 858 time intervals during which the server can send authenticated 859 broadcast messages before it has to calculate a new key chain. 861 3. It divides time into n uniform intervals I_1, I_2, ..., I_n. 862 Each of these time intervals has length L, measured in 863 milliseconds. In order to fulfill the requirement 3.7.2. of RFC 864 4082, the time interval L has to be shorter than the time 865 interval between the broadcast messages. 867 4. The server generates a random key K_n. 869 5. Using a one-way function F, the server generates a one-way chain 870 of n+1 keys K_0, K_1, ..., K_{n} according to 872 K_i = F(K_{i+1}). 874 6. Using another one-way function F', it generates a sequence of n+1 875 MAC keys K'_0, K'_1, ..., K'_{n-1} according to 877 K'_i = F'(K_i). 879 7. Each MAC key K'_i is assigned to the time interval I_i. 881 8. The server determines the key disclosure delay d, which is the 882 number of intervals between using a key and disclosing it. Note 883 that although security is provided for all choices d>0, the 884 choice still makes a difference: 886 * If d is chosen too short, the client might discard packets 887 because it fails to verify that the key used for its MAC has 888 not yet been disclosed. 890 * If d is chosen too long, the received packets have to be 891 buffered for an unnecessarily long time before they can be 892 verified by the client and be subsequently utilized for time 893 synchronization. 895 The server SHOULD calculate d according to 897 d = ceil( 2*B / L) + 1, 899 where ceil yields the smallest integer greater than or equal to 900 its argument. 902 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 903 Generation of Keys 905 F F F F 906 K_0 <-------- K_1 <-------- ... <-------- K_{n-1} <------- K_n 907 | | | | 908 | | | | 909 | F' | F' | F' | F' 910 | | | | 911 v v v v 912 K'_0 K'_1 ... K'_{n-1} K'_n 913 [______________|____ ____|_________________|_______] 914 I_1 ... I_{n-1} I_n 916 Course of Time/Usage of Keys 917 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -> 919 A schematic explanation of the TESLA protocol's one-way key chain 921 B.2. Client Preparation 923 A client needs the following information in order to participate in a 924 TESLA broadcast: 926 o One key K_i from the one-way key chain, which has to be 927 authenticated as belonging to the server. Typically, this will be 928 K_0. 930 o The disclosure schedule of the keys. This consists of: 932 * the length n of the one-way key chain, 933 * the length L of the time intervals I_1, I_2, ..., I_n, 935 * the starting time T_i of an interval I_i. Typically this is 936 the starting time T_1 of the first interval; 938 * the disclosure delay d. 940 o The one-way function F used to recursively derive the keys in the 941 one-way key chain, 943 o The second one-way function F' used to derive the MAC keys K'_0, 944 K'_1, ... , K'_n from the keys in the one-way chain. 946 o An upper bound D_t on how far its own clock is "behind" that of 947 the server. 949 Note that if D_t is greater than (d - 1) * L, then some authentic 950 packets might be discarded. If D_t is greater than d * L, then all 951 authentic packets will be discarded. In the latter case, the client 952 should not participate in the broadcast, since there will be no 953 benefit in doing so. 955 B.3. Sending Authenticated Broadcast Packets 957 During each time interval I_i, the server sends one authenticated 958 broadcast packet P_i. This packet consists of: 960 o a message M_i, 962 o the index i (in case a packet arrives late), 964 o a MAC authenticating the message M_i, with K'_i used as key, 966 o the key K_{i-d}, which is included for disclosure. 968 B.4. Authentication of Received Packets 970 When a client receives a packet P_i as described above, it first 971 checks that it has not already received a packet with the same 972 disclosed key. This is done to avoid replay/flooding attacks. A 973 packet that fails this test is discarded. 975 Next, the client begins to check the packet's timeliness by ensuring 976 that according to the disclosure schedule and with respect to the 977 upper bound D_t determined above, the server cannot have disclosed 978 the key K_i yet. Specifically, it needs to check that the server's 979 clock cannot read a time that is in time interval I_{i+d} or later. 980 Since it works under the assumption that the server's clock is not 981 more than D_t "ahead" of the client's clock, the client can calculate 982 an upper bound t_i for the server's clock at the time when P_i 983 arrived. This upper bound t_i is calculated according to 985 t_i = R + D_t, 987 where R is the client's clock at the arrival of P_i. This implies 988 that at the time of arrival of P_i, the server could have been in 989 interval I_x at most, with 991 x = floor((t_i - T_1) / L) + 1, 993 where floor gives the greatest integer less than or equal to its 994 argument. The client now needs to verify that 996 x < i+d 998 is valid (see also Section 3.5 of [RFC4082]). If it is falsified, it 999 is discarded. 1001 If the check above is successful, the client performs another more 1002 rigorous check: it sends a key check request to the server (in the 1003 form of a client_keycheck message), asking explicitly if K_i has 1004 already been disclosed. It remembers the time stamp t_check of the 1005 sending time of that request as well as the nonce it used correlated 1006 with the interval number i. If it receives an answer from the server 1007 stating that K_i has not yet been disclosed and it is able to verify 1008 the HMAC on that response, then it deduces that K_i was undisclosed 1009 at t_check and therefore also at R. In this case, the client accepts 1010 P_i as timely. 1012 Next the client verifies that a newly disclosed key K_{i-d} belongs 1013 to the one-way key chain. To this end, it applies the one-way 1014 function F to K_{i-d} until it can verify the identity with an 1015 earlier disclosed key (see Clause 3.5 in RFC 4082, item 3). 1017 Next the client verifies that the transmitted time value s_i belongs 1018 to the time interval I_i, by checking 1020 T_i =< s_i, and 1022 s_i < T_{i+1}. 1024 If it is falsified, the packet MUST be discarded and the client MUST 1025 reinitialize its broadcast module by performing a unicast time 1026 synchronization as well as a new broadcast parameter exchange 1027 (because a falsification of this check yields that the packet was not 1028 generated according to protocol, which suggests an attack). 1030 If a packet P_i passes all the tests listed above, it is stored for 1031 later authentication. Also, if at this time there is a package with 1032 index i-d already buffered, then the client uses the disclosed key 1033 K_{i-d} to derive K'_{i-d} and uses that to check the MAC included in 1034 package P_{i-d}. Upon success, it regards M_{i-d} as authenticated. 1036 Appendix C. Random Number Generation 1038 At various points of the protocol, the generation of random numbers 1039 is required. The employed methods of generation need to be 1040 cryptographically secure. See [RFC4086] for guidelines concerning 1041 this topic. 1043 Authors' Addresses 1045 Dieter Sibold 1046 Physikalisch-Technische Bundesanstalt 1047 Bundesallee 100 1048 Braunschweig D-38116 1049 Germany 1051 Phone: +49-(0)531-592-8420 1052 Fax: +49-531-592-698420 1053 Email: dieter.sibold@ptb.de 1055 Stephen Roettger 1056 Google Inc. 1058 Email: stephen.roettger@googlemail.com 1060 Kristof Teichel 1061 Physikalisch-Technische Bundesanstalt 1062 Bundesallee 100 1063 Braunschweig D-38116 1064 Germany 1066 Phone: +49-(0)531-592-8421 1067 Email: kristof.teichel@ptb.de