idnits 2.17.1 draft-ietf-ntp-network-time-security-13.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 (February 25, 2016) is 2983 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 ** Downref: Normative reference to an Informational RFC: RFC 7384 == Outdated reference: A later version (-06) exists of draft-ietf-ntp-cms-for-nts-message-04 == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-multi-path-synchronization-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group D. Sibold 3 Internet-Draft PTB 4 Intended status: Standards Track S. Roettger 5 Expires: August 28, 2016 Google Inc. 6 K. Teichel 7 PTB 8 February 25, 2016 10 Network Time Security 11 draft-ietf-ntp-network-time-security-13 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 August 28, 2016. 45 Copyright Notice 47 Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 65 2.2. Common Terminology for PTP and NTP . . . . . . . . . . . 4 66 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Unicast Time Synchronisation Messages . . . . . . . . . . 7 71 6.1.1. Preconditions for the Unicast Time Synchronization 72 Exchange . . . . . . . . . . . . . . . . . . . . . . 7 73 6.1.2. Goals of the Unicast Time Synchronization Exchange . 8 74 6.1.3. Message Type: "time_request" . . . . . . . . . . . . 8 75 6.1.4. Message Type: "time_response" . . . . . . . . . . . . 8 76 6.1.5. Procedure Overview of the Unicast Time 77 Synchronization Exchange . . . . . . . . . . . . . . 9 78 6.2. Broadcast Time Synchronization Exchange . . . . . . . . . 10 79 6.2.1. Preconditions for the Broadcast Time Synchronization 80 Exchange . . . . . . . . . . . . . . . . . . . . . . 10 81 6.2.2. Goals of the Broadcast Time Synchronization Exchange 11 82 6.2.3. Message Type: "server_broad" . . . . . . . . . . . . 11 83 6.2.4. Procedure Overview of Broadcast Time Synchronization 84 Exchange . . . . . . . . . . . . . . . . . . . . . . 12 85 6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 13 86 6.3.1. Preconditions for the Broadcast Keycheck Exchange . . 13 87 6.3.2. Goals of the Broadcast Keycheck Exchange . . . . . . 14 88 6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 14 89 6.3.4. Message Type: "server_keycheck" . . . . . . . . . . . 14 90 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 15 91 7. Server Seed, Hash Algorithms and Generating MACs . . . . . . 16 92 7.1. Server Seed . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16 94 7.3. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 17 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 9.2. Initial Verification of the Server Certificates . . . . . 18 99 9.3. Revocation of Server Certificates . . . . . . . . . . . . 18 100 9.4. Mitigating Denial-of-Service for broadcast packets . . . 18 101 9.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 19 102 9.6. Random Number Generation . . . . . . . . . . . . . . . . 20 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 106 11.2. Informative References . . . . . . . . . . . . . . . . . 21 107 Appendix A. (informative) TICTOC Security Requirements . . . . . 22 108 Appendix B. (normative) Inherent Association Protocol Messages . 23 109 B.1. Overview of NTS with Inherent Association Protocol . . . 23 110 B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24 111 B.2.1. Goals of the Access Message Exchange . . . . . . . . 24 112 B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24 113 B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24 114 B.2.4. Procedure Overview of the Access Exchange . . . . . . 25 115 B.3. Association Message Exchange . . . . . . . . . . . . . . 25 116 B.3.1. Goals of the Association Exchange . . . . . . . . . . 25 117 B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 26 118 B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26 119 B.3.4. Procedure Overview of the Association Exchange . . . 27 120 B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 28 121 B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28 122 B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 29 123 B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 29 124 B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 30 125 B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 31 126 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 33 127 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 33 128 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 35 129 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 36 130 C.4. Authentication of Received Packets . . . . . . . . . . . 36 131 Appendix D. (informative) Dependencies . . . . . . . . . . . . . 38 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 134 1. Introduction 136 Time synchronization protocols are increasingly utilized to 137 synchronize clocks in networked infrastructures. Successful attacks 138 against the time synchronization protocol can seriously degrade the 139 reliable performance of such infrastructures. Therefore, time 140 synchronization protocols have to be secured if they are applied in 141 environments that are prone to malicious attacks. This can be 142 accomplished either by utilization of external security protocols, 143 like IPsec or TLS, or by intrinsic security measures of the time 144 synchronization protocol. 146 The two most popular time synchronization protocols, the Network Time 147 Protocol (NTP) [RFC5905] and the Precision Time Protocol (PTP) 148 [IEEE1588], currently do not provide adequate intrinsic security 149 precautions. This document specifies generic security measures which 150 enable these and possibly other protocols to verify the authenticity 151 of the time server/master and the integrity of the time 152 synchronization protocol packets. The utilization of these measures 153 for a given specific time synchronization protocol has to be 154 described in a separate document. 156 [RFC7384] specifies that a security mechanism for timekeeping must be 157 designed in such a way that it does not degrade the quality of the 158 time transfer. This implies that for time keeping the increase in 159 bandwidth and message latency caused by the security measures should 160 be small. Also, NTP as well as PTP work via UDP and connections are 161 stateless on the server/master side. Therefore, all security 162 measures in this document are designed in such a way that they add 163 little demand for bandwidth, that the necessary calculations can be 164 executed in a fast manner, and that the measures do not require a 165 server/master to keep state of a connection. 167 2. Terminology 169 2.1. Terms and Abbreviations 171 MITM Man In The Middle 173 NTS Network Time Security 175 TESLA Timed Efficient Stream Loss-tolerant Authentication 177 MAC Message Authentication Code 179 HMAC Keyed-Hash Message Authentication Code 181 2.2. Common Terminology for PTP and NTP 183 This document refers to different time synchronization protocols, in 184 particular to both the PTP and the NTP. Throughout the document the 185 term "server" applies to both a PTP master and an NTP server. 186 Accordingly, the term "client" applies to both a PTP slave and an NTP 187 client. 189 3. Security Threats 191 The document "Security Requirements of Time Protocols in Packet 192 Switched Networks" [RFC7384] contains a profound analysis of security 193 threats and requirements for time synchronization protocols. 195 4. Objectives 197 The objectives of the NTS specification are as follows: 199 o Authenticity: NTS enables the client to authenticate its time 200 server(s). 202 o Integrity: NTS protects the integrity of time synchronization 203 protocol packets via a message authentication code (MAC). 205 o Confidentiality: NTS does not provide confidentiality protection 206 of the time synchronization packets. 208 o Authorization: NTS enables the client to verify its time server's 209 authorization. NTS optionally enables the server to verify the 210 client's authorization as well. 212 o Request-Response-Consistency: NTS enables a client to match an 213 incoming response to a request it has sent. NTS also enables the 214 client to deduce from the response whether its request to the 215 server has arrived without alteration. 217 o Applicability to Protocols: NTS can be used to secure different 218 time synchronization protocols, specifically at least NTP and PTP. 220 o Integration with Protocols: A client or server running an NTS- 221 secured version of a time protocol does not negatively affect 222 other participants who are running unsecured versions of that 223 protocol. 225 o Server-Side Statelessness: All security measures of NTS work 226 without creating the necessity for a server to keep state of a 227 connection. 229 o Prevention of Amplification Attacks: All communication introduced 230 by NTS offers protection against abuse for amplification denial- 231 of-service attacks. 233 5. NTS Overview 235 NTS initially verifies the authenticity of the time server and 236 exchanges a symmetric key, the so-called cookie, as well as a key 237 input value (KIV). The KIV can be opaque for the client. After the 238 cookie and the KIV are exchanged, the client then uses them to 239 protect the authenticity and the integrity of subsequent unicast-type 240 time synchronization packets. In order to do this, a Message 241 Authentication Code (MAC) is attached to each time synchronization 242 packet. The calculation of the MAC includes the whole time 243 synchronization packet and the cookie which is shared between client 244 and server. 246 The cookie is calculated according to: 248 cookie = MSB_ (HMAC(server seed, KIV)), 250 with the server seed as the key, where KIV is the client's key input 251 value, and where the application of the function MSB_ returns only 252 the b most significant bits. The server seed is a random value of 253 bit length b that the server possesses, which has to remain secret. 254 The cookie deterministically depends on KIV as long as the server 255 seed stays the same. The server seed has to be refreshed 256 periodically in order to provide key freshness as required in 257 [RFC7384]. See Section 7 for details on seed refreshing. 259 Since the server does not keep a state of the client, it has to 260 recalculate the cookie each time it receives a unicast time 261 synchronization request from the client. To this end, the client has 262 to attach its KIV to each request (see Section 6.1). 264 Note: The communication of the KIV and the cookie can be performed 265 between client and server directly, or via a third party key 266 distribution entity. 268 For broadcast-type messages, authenticity and integrity of the time 269 synchronization packets are also ensured by a MAC, which is attached 270 to the time synchronization packet by the sender. Verification of 271 the broadcast-type packets' authenticity is based on the TESLA 272 protocol, in particular on its "not re-using keys" scheme, see 273 Section 3.7.2 of [RFC4082]. TESLA uses a one-way chain of keys, 274 where each key is the output of a one-way function applied to the 275 previous key in the chain. The server securely shares the last 276 element of the chain with all clients. The server splits time into 277 intervals of uniform duration and assigns each key to an interval in 278 reverse order. At each time interval, the server sends a broadcast 279 packet appended by a MAC, calculated using the corresponding key, and 280 the key of the previous disclosure interval. The client verifies the 281 MAC by buffering the packet until disclosure of the key in its 282 associated disclosure interval occurs. In order to be able to verify 283 the timeliness of the packets, the client has to be loosely time 284 synchronized with the server. This has to be accomplished before 285 broadcast associations can be used. For checking timeliness of 286 packets, NTS uses another, more rigorous check in addition to just 287 the clock lookup used in the TESLA protocol. For a more detailed 288 description of how NTS employs and customizes TESLA, see Appendix C. 290 6. Protocol Messages 292 This section describes the types of messages needed for secure time 293 synchronization with NTS. 295 For some guidance on how these message types can be realized in 296 practice, and integrated into the communication flow of existing time 297 synchronization protocols, see [I-D.ietf-ntp-cms-for-nts-message], a 298 companion document for NTS. Said document describes ASN.1 encodings 299 for those message parts that have to be added to a time 300 synchronization protocol for security reasons. 302 6.1. Unicast Time Synchronisation Messages 304 In this message exchange, the usual time synchronization process is 305 executed, with the addition of integrity protection for all messages 306 that the server sends. This message exchange can be repeatedly 307 performed as often as the client desires and as long as the integrity 308 of the server's time responses is verified successfully. 310 6.1.1. Preconditions for the Unicast Time Synchronization Exchange 312 Before this message exchange is available, there are some 313 requirements that the client and server need to meet: 315 o They MUST negotiate the hash algorithm for the MAC used in the 316 time synchronization messages. Authenticity and integrity of the 317 communication MUST be ensured. 319 o The client MUST know a key input value KIV. Authenticity and 320 integrity of the communication MUST be ensured. 322 o Client and server MUST exchange the cookie (which depends on the 323 KIV as described in section Section 5). Authenticity, 324 confidentiality and integrity of the communication MUST be 325 ensured. 327 One way of realizing these requirements is to use the Association and 328 Cookie Message Exchanges described in Appendix B. 330 6.1.2. Goals of the Unicast Time Synchronization Exchange 332 The unicast time synchronization exchange: 334 o exchanges time synchronization data as specified by the 335 appropriate time synchronization protocol, 337 o guarantees authenticity and integrity of the request to the 338 server, 340 o guarantees authenticity and integrity of the response to the 341 client, 343 o guarantees request-response-consistency to the client. 345 6.1.3. Message Type: "time_request" 347 This message is sent by the client when it requests a time exchange. 348 It contains 350 o the NTS message ID "time_request", 352 o the negotiated version number, 354 o a nonce, 356 o the negotiated hash algorithm H, 358 o the client's key input value (for which the client knows the 359 associated cookie), 361 o optional: a MAC (generated with the cookie as key) for 362 verification of all of the above data. 364 6.1.4. Message Type: "time_response" 366 This message is sent by the server after it has received a 367 time_request message. Prior to this the server MUST recalculate the 368 client's cookie by using the received key input value and the 369 transmitted hash algorithm. The message contains 371 o the NTS message ID "time_response", 373 o the version number as transmitted in time_request, 375 o the server's time synchronization response data, 377 o the nonce transmitted in time_request, 378 o a MAC (generated with the cookie as key) for verification of all 379 of the above data. 381 6.1.5. Procedure Overview of the Unicast Time Synchronization Exchange 383 For a unicast time synchronization exchange, the following steps are 384 performed: 386 1. The client sends a time_request message to the server. The 387 client MUST save the included nonce and the transmit_timestamp 388 (from the time synchronization data) as a correlated pair for 389 later verification steps. Optionally, the client protects the 390 request message with an appended MAC. 392 2. Upon receipt of a time_request message, the server performs the 393 following steps: 395 * It re-calculates the cookie. 397 * If the request message contains a MAC the server re-calculates 398 the MAC and compares this value with the MAC in the received 399 data. 401 + If the re-calculated MAC does not match the MAC in the 402 received data the server MUST stop the processing of the 403 request. 405 + If the re-calculated MAC matches the MAC in the received 406 data the server continues to process the request. 408 * The server computes the necessary time synchronization data 409 and constructs a time_response message as given in 410 Section 6.1.4. 412 3. The client awaits a reply in the form of a time_response message. 413 Upon receipt, it checks: 415 * that the transmitted version number matches the one negotiated 416 previously, 418 * that the transmitted nonce belongs to a previous time_request 419 message, 421 * that the transmit_timestamp in that time_request message 422 matches the corresponding time stamp from the synchronization 423 data received in the time_response, and 425 * that the appended MAC verifies the received synchronization 426 data, version number and nonce. 428 If at least one of the first three checks fails (i.e. if the 429 version number does not match, if the client has never used the 430 nonce transmitted in the time_response message, or if it has used 431 the nonce with initial time synchronization data different from 432 that in the response), then the client MUST ignore this 433 time_response message. If the MAC is invalid, the client MUST do 434 one of the following: abort the run or send another cookie 435 request (because the cookie might have changed due to a server 436 seed refresh). If both checks are successful, the client SHOULD 437 continue time synchronization. 439 +-----------------------+ 440 | o Re-generate cookie | 441 | o Assemble response | 442 | o Generate MAC | 443 +-----------+-----------+ 444 | 445 <-+-> 447 Server -----------------------------------------------> 448 /| \ 449 time_ / \ time_ 450 request / \ response 451 / \| 452 Client -----------------------------------------------> 454 <------ Unicast time ------> <- Client-side -> 455 synchronization validity 456 exchange checks 458 Procedure for unicast time synchronization exchange. 460 6.2. Broadcast Time Synchronization Exchange 462 6.2.1. Preconditions for the Broadcast Time Synchronization Exchange 464 Before this message exchange is available, there are some 465 requirements that the client and server need to meet: 467 o The client MUST receive all the information necessary to process 468 broadcast time synchronization messages from the server. This 469 includes 471 * the one-way functions used for building the key chain, 472 * the last key of the key chain, 474 * time interval duration, 476 * the disclosure delay (number of intervals between use and 477 disclosure of a key), 479 * the time at which the next time interval will start, and 481 * the next interval's associated index. 483 o The communication of the data listed above MUST guarantee 484 authenticity of the server, as well as integrity and freshness of 485 the broadcast parameters to the client. 487 6.2.2. Goals of the Broadcast Time Synchronization Exchange 489 The broadcast time synchronization exchange: 491 o transmits (broadcast) time synchronization data from the server to 492 the client as specified by the appropriate time synchronization 493 protocol, 495 o guarantees to the client that the received synchronization data 496 has arrived in a timely manner as required by the TESLA protocol 497 and is trustworthy enough to be stored for later checks, 499 o additionally guarantees authenticity of a certain broadcast 500 synchronization message in the client's storage. 502 6.2.3. Message Type: "server_broad" 504 This message is sent by the server over the course of its broadcast 505 schedule. It is part of any broadcast association. It contains 507 o the NTS message ID "server_broad", 509 o the version number that the server is working under, 511 o time broadcast data, 513 o the index that belongs to the current interval (and therefore 514 identifies the current, yet undisclosed, key), 516 o the disclosed key of the previous disclosure interval (current 517 time interval minus disclosure delay), 519 o a MAC, calculated with the key for the current time interval, 520 verifying 522 * the message ID, 524 * the version number, and 526 * the time data. 528 6.2.4. Procedure Overview of Broadcast Time Synchronization Exchange 530 A broadcast time synchronization message exchange consists of the 531 following steps: 533 1. The server follows the TESLA protocol by regularly sending 534 server_broad messages as described in Section 6.2.3, adhering to 535 its own disclosure schedule. 537 2. The client awaits time synchronization data in the form of a 538 server_broadcast message. Upon receipt, it performs the 539 following checks: 541 * Proof that the MAC is based on a key that is not yet disclosed 542 (packet timeliness). This is achieved via a combination of 543 checks. First, the disclosure schedule is used, which 544 requires loose time synchronization. If this is successful, 545 the client obtains a stronger guarantee via a key check 546 exchange (see below). If its timeliness is verified, the 547 packet will be buffered for later authentication. Otherwise, 548 the client MUST discard it. Note that the time information 549 included in the packet will not be used for synchronization 550 until its authenticity could also be verified. 552 * The client checks that it does not already know the disclosed 553 key. Otherwise, the client SHOULD discard the packet to avoid 554 a buffer overrun. If this check is successful, the client 555 ensures that the disclosed key belongs to the one-way key 556 chain by applying the one-way function until equality with a 557 previous disclosed key is shown. If it is falsified, the 558 client MUST discard the packet. 560 * If the disclosed key is legitimate, then the client verifies 561 the authenticity of any packet that it has received during the 562 corresponding time interval. If authenticity of a packet is 563 verified, then it is released from the buffer and its time 564 information can be utilized. If the verification fails, then 565 authenticity is not given. In this case, the client MUST 566 request authentic time from the server by means other than 567 broadcast messages. Also, the client MUST re-initialize the 568 broadcast sequence with a "client_bpar" message if the one-way 569 key chain expires, which it can check via the disclosure 570 schedule. 572 See RFC 4082[RFC4082] for a detailed description of the packet 573 verification process. 575 Server ----------------------------------> 576 \ 577 \ server_ 578 \ broad 579 \| 580 Client ----------------------------------> 582 < Broadcast > <- Client-side -> 583 time sync. validity and 584 exchange timeliness 585 checks 587 Procedure for broadcast time synchronization exchange. 589 6.3. Broadcast Keycheck 591 This message exchange is performed for an additional check of packet 592 timeliness in the course of the TESLA scheme, see Appendix C. 594 6.3.1. Preconditions for the Broadcast Keycheck Exchange 596 Before this message exchange is available, there are some 597 requirements that the client and server need to meet: 599 o They MUST negotiate the hash algorithm for the MAC used in the 600 time synchronization messages. Authenticity and integrity of the 601 communication MUST be ensured. 603 o The client MUST know a key input value KIV. Authenticity and 604 integrity of the communication MUST be ensured. 606 o Client and server MUST exchange the cookie (which depends on the 607 KIV as described in section Section 5). Authenticity, 608 confidentiality and integrity of the communication MUST be 609 ensured. 611 These requirements conform to those for the unicast time 612 synchronization exchange. Accordingly, they too can be realized via 613 the Association and Cookie Message Exchanges described in Appendix B 614 (Appendix B). 616 6.3.2. Goals of the Broadcast Keycheck Exchange 618 The keycheck exchange: 620 o guarantees to the client that the key belonging to the respective 621 TESLA interval communicated in the exchange had not been disclosed 622 before the client_keycheck message was sent. 624 o guarantees to the client the timeliness of any broadcast packet 625 secured with this key if it arrived before client_keycheck was 626 sent. 628 6.3.3. Message Type: "client_keycheck" 630 A message of this type is sent by the client in order to initiate an 631 additional check of packet timeliness for the TESLA scheme. It 632 contains 634 o the NTS message ID "client_keycheck", 636 o the NTS version number negotiated during association, 638 o a nonce, 640 o an interval number from the TESLA disclosure schedule, 642 o the hash algorithm H negotiated during association, 644 o the client's key input value KIV, and 646 o optional: a MAC (generated with the cookie as key) for 647 verification of all of the above data. 649 6.3.4. Message Type: "server_keycheck" 651 A message of this type is sent by the server upon receipt of a 652 client_keycheck message during the broadcast loop of the server. 653 Prior to this, the server MUST recalculate the client's cookie by 654 using the received key input value and the transmitted hash 655 algorithm. It contains 657 o the NTS message ID "server_keycheck" 659 o the version number as transmitted in "client_keycheck, 661 o the nonce transmitted in the client_keycheck message, 662 o the interval number transmitted in the client_keycheck message, 663 and 665 o a MAC (generated with the cookie as key) for verification of all 666 of the above data. 668 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 670 A broadcast keycheck message exchange consists of the following 671 steps: 673 1. The client sends a client_keycheck message. It MUST memorize the 674 nonce and the time interval number that it sends as a correlated 675 pair. 677 2. Upon receipt of a client_keycheck message the server performs as 678 follows: If the client_keycheck message contains a MAC the server 679 re-calculates the MAC and compares this value with the MAC in the 680 received data. 682 * If the re-calculated MAC does not match the MAC in the 683 received data the server MUST stop the processing of the 684 request. 686 * If the re-calculated MAC matches the MAC in the received data 687 the server continues to process the request: It looks up 688 whether it has already disclosed the key associated with the 689 interval number transmitted in that message. If it has not 690 disclosed it, it constructs and sends the appropriate 691 server_keycheck message as described in Section 6.3.4. For 692 more details, see also Appendix C. 694 3. The client awaits a reply in the form of a server_keycheck 695 message. On receipt, it performs the following checks: 697 * that the transmitted version number matches the one negotiated 698 previously, 700 * that the transmitted nonce belongs to a previous 701 client_keycheck message, 703 * that the TESLA interval number in that client_keycheck message 704 matches the corresponding interval number from the 705 server_keycheck, and 707 * that the appended MAC verifies the received data. 709 +----------------------+ 710 | o Assemble response | 711 | o Re-generate cookie | 712 | o Generate MAC | 713 +-----------+----------+ 714 | 715 <-+-> 716 Server ---------------------------------------------> 717 \ /| \ 718 \ server_ client_ / \ server_ 719 \ broad keycheck / \ keycheck 720 \| / \| 721 Client ---------------------------------------------> 722 <-------- Extended broadcast time -------> 723 synchronization exchange 725 <---- Keycheck exchange ---> 727 Procedure for extended broadcast time synchronization exchange. 729 7. Server Seed, Hash Algorithms and Generating MACs 731 7.1. Server Seed 733 The server has to calculate a random seed which has to be kept 734 secret. The server MUST generate a seed for each supported hash 735 algorithm, see Section 7.2. 737 According to the requirements in [RFC7384], the server MUST refresh 738 each server seed periodically. Consequently, the cookie memorized by 739 the client becomes obsolete. In this case, the client cannot verify 740 the MAC attached to subsequent time response messages and has to 741 respond accordingly by re-initiating the protocol with a cookie 742 request (Appendix B.4). 744 7.2. Hash Algorithms 746 Hash algorithms are used for calculation of the cookie and the MAC. 747 The client and the server negotiate a hash algorithm H during the 748 association phase at the beginning. The selected algorithm H MUST be 749 used for all hashing processes in that run. 751 In the TESLA scheme, hash algorithms are used as pseudo-random 752 functions to construct the one-way key chain. Here, the utilized 753 hash algorithm is communicated by the server and is non-negotiable. 755 Note: Any hash algorithm is prone to be compromised in the future. 756 A successful attack on a hash algorithm would enable any NTS 757 client to derive the server seed from its own cookie. Therefore, 758 the server MUST have separate seed values for its different 759 supported hash algorithms. This way, knowledge gained from an 760 attack on a hash algorithm H can at least only be used to 761 compromise such clients who use hash algorithm H as well. 763 7.3. MAC Calculation 765 For the calculation of the MAC, client and server MUST use a Keyed- 766 Hash Message Authentication Code (HMAC) as described in [RFC2104]. 767 The HMAC is generated with the hash algorithm specified by the client 768 (see Section 7.2). The input values for the HMAC are the cookie and 769 the content that has to be protected by NTS. 771 8. IANA Considerations 773 As mentioned, this document generically specifies security measures 774 whose utilization for any given specific time synchronization 775 protocol requires a separate document. Consequently, this document 776 itself does not have any IANA actions (TO BE REVIEWED). 778 9. Security Considerations 780 Aspects of security for time synchronization protocols are treated 781 throughout this document. For a comprehensive discussion of security 782 requirements in time synchronization contexts, refer to [RFC7384]. 783 See Appendix A for a tabular overview of how NTS deals with those 784 requirements. 786 Additional NTS specific discussion of security issues can be found in 787 the following subsections. 789 Note: Any separate document describing the utilization of NTS to a 790 specific time synchronization protocol may additionally introduce 791 discussion of its own specific security considerations. 793 9.1. Privacy 795 The payload of time synchronization protocol packets of two-way time 796 transfer approaches like NTP and PTP consists basically of time 797 stamps, which are not considered secret [RFC7384]. Therefore, 798 encryption of the time synchronization protocol packet's payload is 799 not considered in this document. However, an attacker can exploit 800 the exchange of time synchronization protocol packets for topology 801 detection and inference attacks as described in [RFC7624]. To make 802 such attacks more difficult, that draft recommends the encryption of 803 the packet payload. Yet, in the case of time synchronization 804 protocols the confidentiality protection of time synchronization 805 packet's payload is of secondary importance since the packet's meta 806 data (IP addresses, port numbers, possibly packet size and regular 807 sending intervals) carry more information than the payload. To 808 enhance the privacy of the time synchronization partners, the usage 809 of tunnel protocols such as IPsec and MACsec, where applicable, is 810 therefore more suited than confidentiality protection of the payload. 812 9.2. Initial Verification of the Server Certificates 814 The client may wish to verify the validity of certificates during the 815 initial association phase. Since it generally has no reliable time 816 during this initial communication phase, it is impossible to verify 817 the period of validity of the certificates. To solve this chicken- 818 and-egg problem, the client has to rely on external means. 820 9.3. Revocation of Server Certificates 822 According to Section 7, it is the client's responsibility to initiate 823 a new association with the server after the server's certificate 824 expires. To this end, the client reads the expiration date of the 825 certificate during the certificate message exchange (Appendix B.3.3). 826 Furthermore, certificates may also be revoked prior to the normal 827 expiration date. To increase security the client MAY periodically 828 verify the state of the server's certificate via Online Certificate 829 Status Protocol (OCSP) Online Certificate Status Protocol (OCSP) 830 [RFC6960]. 832 9.4. Mitigating Denial-of-Service for broadcast packets 834 TESLA authentication buffers packets for delayed authentication. 835 This makes the protocol vulnerable to flooding attacks, causing the 836 client to buffer excessive numbers of packets. To add stronger DoS 837 protection to the protocol, the client and the server use the "not 838 re-using keys" scheme of TESLA as pointed out in Section 3.7.2 of RFC 839 4082 [RFC4082]. In this scheme the server never uses a key for the 840 MAC generation more than once. Therefore, the client can discard any 841 packet that contains a disclosed key it already knows, thus 842 preventing memory flooding attacks. 844 Discussion: Note that an alternative approach to enhance TESLA's 845 resistance against DoS attacks involves the addition of a group 846 MAC to each packet. This requires the exchange of an additional 847 shared key common to the whole group. This adds additional 848 complexity to the protocol and hence is currently not considered 849 in this document. 851 9.5. Delay Attack 853 In a packet delay attack, an adversary with the ability to act as a 854 MITM delays time synchronization packets between client and server 855 asymmetrically [RFC7384]. This prevents the client from accurately 856 measuring the network delay, and hence its time offset to the server 857 [Mizrahi]. The delay attack does not modify the content of the 858 exchanged synchronization packets. Therefore, cryptographic means do 859 not provide a feasible way to mitigate this attack. However, several 860 non-cryptographic precautions can be taken in order to detect this 861 attack. 863 1. Usage of multiple time servers: this enables the client to detect 864 the attack, provided that the adversary is unable to delay the 865 synchronization packets between the majority of servers. This 866 approach is commonly used in NTP to exclude incorrect time 867 servers [RFC5905]. 869 2. Multiple communication paths: The client and server utilize 870 different paths for packet exchange as described in the I-D 871 [I-D.ietf-tictoc-multi-path-synchronization]. The client can 872 detect the attack, provided that the adversary is unable to 873 manipulate the majority of the available paths [Shpiner]. Note 874 that this approach is not yet available, neither for NTP nor for 875 PTP. 877 3. Usage of an encrypted connection: the client exchanges all 878 packets with the time server over an encrypted connection (e.g. 879 IPsec). This measure does not mitigate the delay attack, but it 880 makes it more difficult for the adversary to identify the time 881 synchronization packets. 883 4. For unicast-type messages: Introduction of a threshold value for 884 the delay time of the synchronization packets. The client can 885 discard a time server if the packet delay time of this time 886 server is larger than the threshold value. 888 Additional provision against delay attacks has to be taken for 889 broadcast-type messages. This mode relies on the TESLA scheme which 890 is based on the requirement that a client and the broadcast server 891 are loosely time synchronized. Therefore, a broadcast client has to 892 establish time synchronization with its broadcast server before it 893 starts utilizing broadcast messages for time synchronization. 895 One possible way to achieve this initial synchronization is to 896 establish a unicast association with its broadcast server until time 897 synchronization and calibration of the packet delay time is achieved. 898 After that, the client can establish a broadcast association with the 899 broadcast server and utilizes TESLA to verify integrity and 900 authenticity of any received broadcast packets. 902 An adversary who is able to delay broadcast packets can cause a time 903 adjustment at the receiving broadcast clients. If the adversary 904 delays broadcast packets continuously, then the time adjustment will 905 accumulate until the loose time synchronization requirement is 906 violated, which breaks the TESLA scheme. To mitigate this 907 vulnerability the security condition in TESLA has to be supplemented 908 by an additional check in which the client, upon receipt of a 909 broadcast message, verifies the status of the corresponding key via a 910 unicast message exchange with the broadcast server (see Appendix C.4 911 for a detailed description of this check). Note that a broadcast 912 client should also apply the above-mentioned precautions as far as 913 possible. 915 9.6. Random Number Generation 917 At various points of the protocol, the generation of random numbers 918 is required. The employed methods of generation need to be 919 cryptographically secure. See [RFC4086] for guidelines concerning 920 this topic. 922 10. Acknowledgements 924 The authors would like to thank Tal Mizrahi, Russ Housley, Steven 925 Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer 926 and Florian Weimer for discussions and comments on the design of NTS. 927 Also, thanks go to Harlan Stenn and Richard Welty for their technical 928 review and specific text contributions to this document. 930 11. References 932 11.1. Normative References 934 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 935 Hashing for Message Authentication", RFC 2104, DOI 936 10.17487/RFC2104, February 1997, 937 . 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 941 RFC2119, March 1997, 942 . 944 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 945 Briscoe, "Timed Efficient Stream Loss-Tolerant 946 Authentication (TESLA): Multicast Source Authentication 947 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 948 June 2005, . 950 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 951 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 952 October 2014, . 954 11.2. Informative References 956 [I-D.ietf-ntp-cms-for-nts-message] 957 Sibold, D., Teichel, K., Roettger, S., and R. Housley, 958 "Protecting Network Time Security Messages with the 959 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 960 for-nts-message-04 (work in progress), July 2015. 962 [I-D.ietf-tictoc-multi-path-synchronization] 963 Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- 964 Path Time Synchronization", draft-ietf-tictoc-multi-path- 965 synchronization-02 (work in progress), April 2015. 967 [IEEE1588] 968 IEEE Instrumentation and Measurement Society. TC-9 Sensor 969 Technology, "IEEE standard for a precision clock 970 synchronization protocol for networked measurement and 971 control systems", 2008. 973 [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks 974 against time synchronization protocols", in Proceedings of 975 Precision Clock Synchronization for Measurement Control 976 and Communication, ISPCS 2012, pp. 1-6, September 2012. 978 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 979 "Randomness Requirements for Security", BCP 106, RFC 4086, 980 DOI 10.17487/RFC4086, June 2005, 981 . 983 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 984 "Network Time Protocol Version 4: Protocol and Algorithms 985 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 986 . 988 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 989 Galperin, S., and C. Adams, "X.509 Internet Public Key 990 Infrastructure Online Certificate Status Protocol - OCSP", 991 RFC 6960, DOI 10.17487/RFC6960, June 2013, 992 . 994 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 995 Trammell, B., Huitema, C., and D. Borkmann, 996 "Confidentiality in the Face of Pervasive Surveillance: A 997 Threat Model and Problem Statement", RFC 7624, DOI 998 10.17487/RFC7624, August 2015, 999 . 1001 [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time 1002 Protocols", in Proceedings of Precision Clock 1003 Synchronization for Measurement Control and Communication, 1004 ISPCS 2013, pp. 1-6, September 2013. 1006 Appendix A. (informative) TICTOC Security Requirements 1008 The following table compares the NTS specifications against the 1009 TICTOC security requirements [RFC7384]. 1011 +---------+------------------------------+-------------+------------+ 1012 | Section | Requirement from RFC 7384 | Requirement | NTS | 1013 | | | level | | 1014 +---------+------------------------------+-------------+------------+ 1015 | 5.1.1 | Authentication of Servers | MUST | OK | 1016 +---------+------------------------------+-------------+------------+ 1017 | 5.1.1 | Authorization of Servers | MUST | OK | 1018 +---------+------------------------------+-------------+------------+ 1019 | 5.1.2 | Recursive Authentication of | MUST | OK | 1020 | | Servers (Stratum 1) | | | 1021 +---------+------------------------------+-------------+------------+ 1022 | 5.1.2 | Recursive Authorization of | MUST | OK | 1023 | | Servers (Stratum 1) | | | 1024 +---------+------------------------------+-------------+------------+ 1025 | 5.1.3 | Authentication and | MAY | Optional, | 1026 | | Authorization of Clients | | Limited | 1027 +---------+------------------------------+-------------+------------+ 1028 | 5.2 | Integrity protection | MUST | OK | 1029 +---------+------------------------------+-------------+------------+ 1030 | 5.3 | Spoofing Prevention | MUST | OK | 1031 +---------+------------------------------+-------------+------------+ 1032 | 5.4 | Protection from DoS attacks | SHOULD | OK | 1033 | | against the time protocol | | | 1034 +---------+------------------------------+-------------+------------+ 1035 | 5.5 | Replay protection | MUST | OK | 1036 +---------+------------------------------+-------------+------------+ 1037 | 5.6 | Key freshness | MUST | OK | 1038 +---------+------------------------------+-------------+------------+ 1039 | | Security association | SHOULD | OK | 1040 +---------+------------------------------+-------------+------------+ 1041 | | Unicast and multicast | SHOULD | OK | 1042 | | associations | | | 1043 +---------+------------------------------+-------------+------------+ 1044 | 5.7 | Performance: no degradation | MUST | OK | 1045 | | in quality of time transfer | | | 1046 +---------+------------------------------+-------------+------------+ 1047 | | Performance: lightweight | SHOULD | OK | 1048 | | computation | | | 1049 +---------+------------------------------+-------------+------------+ 1050 | | Performance: storage | SHOULD | OK | 1051 +---------+------------------------------+-------------+------------+ 1052 | | Performance: bandwidth | SHOULD | OK | 1053 +---------+------------------------------+-------------+------------+ 1054 | 5.8 | Confidentiality protection | MAY | NO | 1055 +---------+------------------------------+-------------+------------+ 1056 | 5.9 | Protection against Packet | MUST | Limited*) | 1057 | | Delay and Interception | | | 1058 | | Attacks | | | 1059 +---------+------------------------------+-------------+------------+ 1060 | 5.10 | Secure mode | MUST | OK | 1061 +---------+------------------------------+-------------+------------+ 1062 | | Hybrid mode | SHOULD | - | 1063 +---------+------------------------------+-------------+------------+ 1065 *) See discussion in Section 9.5. 1067 Comparison of NTS specification against Security Requirements of Time 1068 Protocols in Packet Switched Networks (RFC 7384) 1070 Appendix B. (normative) Inherent Association Protocol Messages 1072 This appendix presents a procedure that performs the association, the 1073 cookie, and also the broadcast parameter message exchanges between a 1074 client and a server. This procedure is one possible way to achieve 1075 the preconditions listed in Sections Section 6.1.1, Section 6.2.1, 1076 and Section 6.3.1 while taking into account the objectives given in 1077 Section Section 4. 1079 B.1. Overview of NTS with Inherent Association Protocol 1081 This inherent association protocol applies X.509 certificates to 1082 verify the authenticity of the time server and to exchange the 1083 cookie. This is done in two separate message exchanges, described 1084 below. An additional required exchange in advance serves to limit 1085 the amplification potential of the association message exchange. 1087 A client needs a public/private key pair for encryption, with the 1088 public key enclosed in a certificate. A server needs a public/ 1089 private key pair for signing, with the public key enclosed in a 1090 certificate. If a participant intends to act as both a client and a 1091 server, it MUST have two different key pairs for these purposes. 1093 If this protocol is employed, the hash value of the client's 1094 certificate is used as the client's key input value, i.e. the cookie 1095 is calculated according to: 1097 cookie = MSB_ (HMAC(server seed, H(certificate of client))). 1099 The client's certificate contains the client's public key and enables 1100 the server to identify the client, if client authorization is 1101 desired. 1103 B.2. Access Message Exchange 1105 This message exchange serves only to prevent the next (association) 1106 exchange from being abusable for amplification denial-of-service 1107 attacks. 1109 B.2.1. Goals of the Access Message Exchange 1111 The access message exchange: 1113 o transfers a secret value from the server to the client 1114 (initiator), 1116 o the secret value permits the client to initiate an association 1117 message exchange. 1119 B.2.2. Message Type: "client_access" 1121 This message is sent by a client who intends to perform an 1122 association exchange with the server in the future. It contains: 1124 o the NTS message ID "client_access". 1126 B.2.3. Message Type: "server_access" 1128 This message is sent by the server on receipt of a client_access 1129 message. It contains: 1131 o the NTS message ID "server_access", 1132 o an access key. 1134 B.2.4. Procedure Overview of the Access Exchange 1136 For an access exchange, the following steps are performed: 1138 1. The client sends a client_access message to the server. 1140 2. Upon receipt of a client_access, the server calculates the access 1141 key. It then sends a reply in the form of a server_access 1142 message. The server must either memorize the access key or 1143 alternatively apply a means by which it can reconstruct the 1144 access key. Note that in both cases the access key must be 1145 correlated with the address of the requester. Note also that if 1146 the server memorizes the access key for a requester, it has to 1147 keep state for a certain amount of time. 1149 3. The client waits for a response in the form of a server_access 1150 message. Upon receipt of one, it MUST memorize the included 1151 access key. 1153 B.3. Association Message Exchange 1155 In this message exchange, the participants negotiate the hash and 1156 encryption algorithms that are used throughout the protocol. In 1157 addition, the client receives the certification chain up to a trusted 1158 anchor. With the established certification chain the client is able 1159 to verify the server's signatures and, hence, the authenticity of 1160 future NTS messages from the server is ensured. 1162 B.3.1. Goals of the Association Exchange 1164 The association exchange: 1166 o enables the client to verify any communication with the server as 1167 authentic, 1169 o lets the participants negotiate NTS version and algorithms, 1171 o guarantees authenticity and integrity of the negotiation result to 1172 the client, 1174 o guarantees to the client that the negotiation result is based on 1175 the client's original, unaltered request. 1177 B.3.2. Message Type: "client_assoc" 1179 This message is sent by the client if it wants to perform association 1180 with a server. It contains 1182 o the NTS message ID "client_assoc", 1184 o a nonce, 1186 o the access key obtained earlier via an access message exchange, 1188 o the version number of NTS that the client wants to use (this 1189 SHOULD be the highest version number that it supports), 1191 o a selection of accepted hash algorithms, and 1193 o a selection of accepted encryption algorithms. 1195 B.3.3. Message Type: "server_assoc" 1197 This message is sent by the server upon receipt of client_assoc. It 1198 contains 1200 o the NTS message ID "server_assoc", 1202 o the nonce transmitted in client_assoc, 1204 o the client's proposal for the version number, selection of 1205 accepted hash algorithms and selection of accepted encryption 1206 algorithms, as transmitted in client_assoc, 1208 o the version number used for the rest of the protocol (which SHOULD 1209 be determined as the minimum over the client's suggestion in the 1210 client_assoc message and the highest supported by the server), 1212 o the server's choice of algorithm for encryption and for 1213 cryptographic hashing, all of which MUST be chosen from the 1214 client's proposals, 1216 o a signature, calculated over the data listed above, with the 1217 server's private key and according to the signature algorithm 1218 which is also used for the certificates that are included (see 1219 below), and 1221 o a chain of certificates, which starts at the server and goes up to 1222 a trusted authority; each certificate MUST be certified by the one 1223 directly following it. 1225 B.3.4. Procedure Overview of the Association Exchange 1227 For an association exchange, the following steps are performed: 1229 1. The client sends a client_assoc message to the server. It MUST 1230 keep the transmitted values for the version number and algorithms 1231 available for later checks. 1233 2. Upon receipt of a client_assoc message, the server checks the 1234 validity of the included access key. If it is not valid, the 1235 server MUST abort communication. If it is valid, the server 1236 constructs and sends a reply in the form of a server_assoc 1237 message as described in Appendix B.3.3. Upon unsuccessful 1238 negotiation for version number or algorithms the server_assoc 1239 message MUST contain an error code. 1241 3. The client waits for a reply in the form of a server_assoc 1242 message. After receipt of the message it performs the following 1243 checks: 1245 * The client checks that the message contains a conforming 1246 version number. 1248 * It checks that the nonce sent back by the server matches the 1249 one transmitted in client_assoc, 1251 * It also verifies that the server has chosen the encryption and 1252 hash algorithms from its proposal sent in the client_assoc 1253 message and that this proposal was not altered. 1255 * Furthermore, it performs authenticity checks on the 1256 certificate chain and the signature. 1258 If one of the checks fails, the client MUST abort the run. 1260 +------------------------+ 1261 | o Check access key | 1262 +------------------------+ 1263 | o Choose version | 1264 | o Choose algorithms | 1265 | o Acquire certificates | 1266 | o Assemble response | 1267 | o Create signature | 1268 +-----------+------------+ 1269 | 1270 <-+-> 1272 Server ---------------------------> 1273 /| \ 1274 client_ / \ server_ 1275 assoc / \ assoc 1276 / \| 1277 Client ---------------------------> 1279 <------ Association -----> 1280 exchange 1282 Procedure for association and cookie exchange. 1284 B.4. Cookie Message Exchange 1286 During this message exchange, the server transmits a secret cookie to 1287 the client securely. The cookie will later be used for integrity 1288 protection during unicast time synchronization. 1290 B.4.1. Goals of the Cookie Exchange 1292 The cookie exchange: 1294 o enables the server to check the client's authorization via its 1295 certificate (optional), 1297 o supplies the client with the correct cookie and corresponding KIV 1298 for its association to the server, 1300 o guarantees to the client that the cookie originates from the 1301 server and that it is based on the client's original, unaltered 1302 request. 1304 o guarantees that the received cookie is unknown to anyone but the 1305 server and the client. 1307 B.4.2. Message Type: "client_cook" 1309 This message is sent by the client upon successful authentication of 1310 the server. In this message, the client requests a cookie from the 1311 server. The message contains 1313 o the NTS message ID "client_cook", 1315 o a nonce, 1317 o the negotiated version number, 1319 o the negotiated signature algorithm, 1321 o the negotiated encryption algorithm, 1323 o the negotiated hash algorithm H, 1325 o the client's certificate. 1327 B.4.3. Message Type: "server_cook" 1329 This message is sent by the server upon receipt of a client_cook 1330 message. The server generates the hash of the client's certificate, 1331 as conveyed during client_cook, in order to calculate the cookie 1332 according to Section 5. This message contains 1334 o the NTS message ID "server_cook" 1336 o the version number as transmitted in client_cook, 1338 o a concatenated datum which is encrypted with the client's public 1339 key, according to the encryption algorithm transmitted in the 1340 client_cook message. The concatenated datum contains 1342 * the nonce transmitted in client_cook, and 1344 * the cookie. 1346 o a signature, created with the server's private key, calculated 1347 over all of the data listed above. This signature MUST be 1348 calculated according to the transmitted signature algorithm from 1349 the client_cook message. 1351 B.4.4. Procedure Overview of the Cookie Exchange 1353 For a cookie exchange, the following steps are performed: 1355 1. The client sends a client_cook message to the server. The client 1356 MUST save the included nonce until the reply has been processed. 1358 2. Upon receipt of a client_cook message, the server checks whether 1359 it supports the given cryptographic algorithms. It then 1360 calculates the cookie according to the formula given in 1361 Section 5. The server MAY use the client's certificate to check 1362 that the client is authorized to use the secure time 1363 synchronization service. With this, it MUST construct a 1364 server_cook message as described in Appendix B.4.3. 1366 3. The client awaits a reply in the form of a server_cook message; 1367 upon receipt it executes the following actions: 1369 * It verifies that the received version number matches the one 1370 negotiated beforehand. 1372 * It verifies the signature using the server's public key. The 1373 signature has to authenticate the encrypted data. 1375 * It decrypts the encrypted data with its own private key. 1377 * It checks that the decrypted message is of the expected 1378 format: the concatenation of a nonce and a cookie of the 1379 expected bit lengths. 1381 * It verifies that the received nonce matches the nonce sent in 1382 the client_cook message. 1384 If one of those checks fails, the client MUST abort the run. 1386 +----------------------------+ 1387 | o OPTIONAL: Check client's | 1388 | authorization | 1389 | o Generate cookie | 1390 | o Encrypt inner message | 1391 | o Generate signature | 1392 +-------------+--------------+ 1393 | 1394 <-+-> 1396 Server ---------------------------> 1397 /| \ 1398 client_ / \ server_ 1399 cook / \ cook 1400 / \| 1401 Client ---------------------------> 1403 <--- Cookie exchange --> 1405 Procedure for association and cookie exchange. 1407 B.4.5. Broadcast Parameter Messages 1409 In this message exchange, the client receives the necessary 1410 information to execute the TESLA protocol in a secured broadcast 1411 association. The client can only initiate a secure broadcast 1412 association after successful association and cookie exchanges and 1413 only if it has made sure that its clock is roughly synchronized to 1414 the server's. 1416 See Appendix C for more details on TESLA. 1418 B.4.5.1. Goals of the Broadcast Parameter Exchange 1420 The broadcast parameter exchange 1422 o provides the client with all the information necessary to process 1423 broadcast time synchronization messages from the server, and 1425 o guarantees authenticity, integrity and freshness of the broadcast 1426 parameters to the client. 1428 B.4.5.2. Message Type: "client_bpar" 1430 This message is sent by the client in order to establish a secured 1431 time broadcast association with the server. It contains 1433 o the NTS message ID "client_bpar", 1434 o the NTS version number negotiated during association, 1436 o a nonce, and 1438 o the signature algorithm negotiated during association. 1440 B.4.5.3. Message Type: "server_bpar" 1442 This message is sent by the server upon receipt of a client_bpar 1443 message during the broadcast loop of the server. It contains 1445 o the NTS message ID "server_bpar", 1447 o the version number as transmitted in the client_bpar message, 1449 o the nonce transmitted in client_bpar, 1451 o the one-way functions used for building the key chain, and 1453 o the disclosure schedule of the keys. This contains: 1455 * the last key of the key chain, 1457 * time interval duration, 1459 * the disclosure delay (number of intervals between use and 1460 disclosure of a key), 1462 * the time at which the next time interval will start, and 1464 * the next interval's associated index. 1466 o The message also contains a signature signed by the server with 1467 its private key, verifying all the data listed above. 1469 B.4.5.4. Procedure Overview of the Broadcast Parameter Exchange 1471 A broadcast parameter exchange consists of the following steps: 1473 1. The client sends a client_bpar message to the server. It MUST 1474 remember the transmitted values for the nonce, the version number 1475 and the signature algorithm. 1477 2. Upon receipt of a client_bpar message, the server constructs and 1478 sends a server_bpar message as described in Appendix B.4.5.3. 1480 3. The client waits for a reply in the form of a server_bpar 1481 message, on which it performs the following checks: 1483 * The message must contain all the necessary information for the 1484 TESLA protocol, as listed in Appendix B.4.5.3. 1486 * The message must contain a nonce belonging to a client_bpar 1487 message that the client has previously sent. 1489 * Verification of the message's signature. 1491 If any information is missing or if the server's signature cannot 1492 be verified, the client MUST abort the broadcast run. If all 1493 checks are successful, the client MUST remember all the broadcast 1494 parameters received for later checks. 1496 +---------------------+ 1497 | o Assemble response | 1498 | o Create public-key | 1499 | signature | 1500 +----------+----------+ 1501 | 1502 <-+-> 1504 Server ---------------------------------------------> 1505 /| \ 1506 client_ / \ server_ 1507 bpar / \ bpar 1508 / \| 1509 Client ---------------------------------------------> 1511 <------- Broadcast ------> <- Client-side -> 1512 parameter validity 1513 exchange checks 1515 Procedure for unicast time synchronization exchange. 1517 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 1519 For broadcast-type messages, NTS adopts the TESLA protocol with some 1520 customizations. This appendix provides details on the generation and 1521 usage of the one-way key chain collected and assembled from 1522 [RFC4082]. Note that NTS uses the "not re-using keys" scheme of 1523 TESLA as described in Section 3.7.2. of [RFC4082]. 1525 C.1. Server Preparation 1527 Server setup: 1529 1. The server determines a reasonable upper bound B on the network 1530 delay between itself and an arbitrary client, measured in 1531 milliseconds. 1533 2. It determines the number n+1 of keys in the one-way key chain. 1534 This yields the number n of keys that are usable to authenticate 1535 broadcast packets. This number n is therefore also the number of 1536 time intervals during which the server can send authenticated 1537 broadcast messages before it has to calculate a new key chain. 1539 3. It divides time into n uniform intervals I_1, I_2, ..., I_n. 1540 Each of these time intervals has length L, measured in 1541 milliseconds. In order to fulfill the requirement 3.7.2. of RFC 1542 4082, the time interval L has to be shorter than the time 1543 interval between the broadcast messages. 1545 4. The server generates a random key K_n. 1547 5. Using a one-way function F, the server generates a one-way chain 1548 of n+1 keys K_0, K_1, ..., K_{n} according to 1550 K_i = F(K_{i+1}). 1552 6. Using another one-way function F', it generates a sequence of n 1553 MAC keys K'_0, K'_1, ..., K'_{n-1} according to 1555 K'_i = F'(K_i). 1557 7. Each MAC key K'_i is assigned to the time interval I_i. 1559 8. The server determines the key disclosure delay d, which is the 1560 number of intervals between using a key and disclosing it. Note 1561 that although security is provided for all choices d>0, the 1562 choice still makes a difference: 1564 * If d is chosen too short, the client might discard packets 1565 because it fails to verify that the key used for its MAC has 1566 not yet been disclosed. 1568 * If d is chosen too long, the received packets have to be 1569 buffered for an unnecessarily long time before they can be 1570 verified by the client and be subsequently utilized for time 1571 synchronization. 1573 It is RECOMMENDED that the server calculate d according to 1575 d = ceil( 2*B / L) + 1, 1577 where ceil yields the smallest integer greater than or equal to 1578 its argument. 1580 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1581 Generation of Keys 1583 F F F F 1584 K_0 <-------- K_1 <-------- ... <-------- K_{n-1} <------- K_n 1585 | | | | 1586 | | | | 1587 | F' | F' | F' | F' 1588 | | | | 1589 v v v v 1590 K'_0 K'_1 ... K'_{n-1} K'_n 1591 [______________|____ ____|_________________|_______] 1592 I_1 ... I_{n-1} I_n 1594 Course of Time/Usage of Keys 1595 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -> 1597 A schematic explanation of the TESLA protocol's one-way key chain 1599 C.2. Client Preparation 1601 A client needs the following information in order to participate in a 1602 TESLA broadcast: 1604 o One key K_i from the one-way key chain, which has to be 1605 authenticated as belonging to the server. Typically, this will be 1606 K_0. 1608 o The disclosure schedule of the keys. This consists of: 1610 * the length n of the one-way key chain, 1612 * the length L of the time intervals I_1, I_2, ..., I_n, 1614 * the starting time T_i of an interval I_i. Typically this is 1615 the starting time T_1 of the first interval; 1617 * the disclosure delay d. 1619 o The one-way function F used to recursively derive the keys in the 1620 one-way key chain, 1622 o The second one-way function F' used to derive the MAC keys K'_0, 1623 K'_1, ... , K'_n from the keys in the one-way chain. 1625 o An upper bound D_t on how far its own clock is "behind" that of 1626 the server. 1628 Note that if D_t is greater than (d - 1) * L, then some authentic 1629 packets might be discarded. If D_t is greater than d * L, then all 1630 authentic packets will be discarded. In the latter case, the client 1631 SHOULD NOT participate in the broadcast, since there will be no 1632 benefit in doing so. 1634 C.3. Sending Authenticated Broadcast Packets 1636 During each time interval I_i, the server sends at most one 1637 authenticated broadcast packet P_i. Such a packet consists of: 1639 o a message M_i, 1641 o the index i (in case a packet arrives late), 1643 o a MAC authenticating the message M_i, with K'_i used as key, 1645 o the key K_{i-d}, which is included for disclosure. 1647 C.4. Authentication of Received Packets 1649 When a client receives a packet P_i as described above, it first 1650 checks that it has not already received a packet with the same 1651 disclosed key. This is done to avoid replay/flooding attacks. A 1652 packet that fails this test is discarded. 1654 Next, the client begins to check the packet's timeliness by ensuring 1655 that according to the disclosure schedule and with respect to the 1656 upper bound D_t determined above, the server cannot have disclosed 1657 the key K_i yet. Specifically, it needs to check that the server's 1658 clock cannot read a time that is in time interval I_{i+d} or later. 1659 Since it works under the assumption that the server's clock is not 1660 more than D_t "ahead" of the client's clock, the client can calculate 1661 an upper bound t_i for the server's clock at the time when P_i 1662 arrived. This upper bound t_i is calculated according to 1664 t_i = R + D_t, 1666 where R is the client's clock at the arrival of P_i. This implies 1667 that at the time of arrival of P_i, the server could have been in 1668 interval I_x at most, with 1670 x = floor((t_i - T_1) / L) + 1, 1672 where floor gives the greatest integer less than or equal to its 1673 argument. The client now needs to verify that 1675 x < i+d 1677 is valid (see also Section 3.5 of [RFC4082]). If it is falsified, it 1678 is discarded. 1680 If the check above is successful, the client performs another more 1681 rigorous check: it sends a key check request to the server (in the 1682 form of a client_keycheck message), asking explicitly if K_i has 1683 already been disclosed. It remembers the time stamp t_check of the 1684 sending time of that request as well as the nonce it used correlated 1685 with the interval number i. If it receives an answer from the server 1686 stating that K_i has not yet been disclosed and it is able to verify 1687 the HMAC on that response, then it deduces that K_i was undisclosed 1688 at t_check and therefore also at R. In this case, the client accepts 1689 P_i as timely. 1691 Next the client verifies that a newly disclosed key K_{i-d} belongs 1692 to the one-way key chain. To this end, it applies the one-way 1693 function F to K_{i-d} until it can verify the identity with an 1694 earlier disclosed key (see Clause 3.5 in RFC 4082, item 3). 1696 Next the client verifies that the transmitted time value s_i belongs 1697 to the time interval I_i, by checking 1699 T_i =< s_i, and 1701 s_i < T_{i+1}. 1703 If it is falsified, the packet MUST be discarded and the client MUST 1704 reinitialize its broadcast module by performing time synchronization 1705 by other means than broadcast messages, and it MUST perform a new 1706 broadcast parameter exchange (because a falsification of this check 1707 yields that the packet was not generated according to protocol, which 1708 suggests an attack). 1710 If a packet P_i passes all the tests listed above, it is stored for 1711 later authentication. Also, if at this time there is a package with 1712 index i-d already buffered, then the client uses the disclosed key 1713 K_{i-d} to derive K'_{i-d} and uses that to check the MAC included in 1714 package P_{i-d}. Upon success, it regards M_{i-d} as authenticated. 1716 Appendix D. (informative) Dependencies 1718 +---------+--------------+--------+-------------------------------+ 1719 | Issuer | Type | Owner | Description | 1720 +---------+--------------+--------+-------------------------------+ 1721 | Server | private key | server | Used for server_assoc, | 1722 | PKI | (signature) | | server_cook, server_bpar. | 1723 | +--------------+--------+ The server uses the private | 1724 | | public key | client | key to sign these messages. | 1725 | | (signature) | | The client uses the public | 1726 | +--------------+--------+ key to verify them. | 1727 | | certificate | server | The certificate is used in | 1728 | | | | server_assoc messages, for | 1729 | | | | verifying authentication and | 1730 | | | | (optionally) authorization. | 1731 +---------+--------------+--------+-------------------------------+ 1732 | Client | private key | client | The server uses the client's | 1733 | PKI | (encryption) | | public key to encrypt the | 1734 | +--------------+--------+ content of server_cook | 1735 | | public key | server | messages. The client uses | 1736 | | (encryption) | | the private key to decrypt | 1737 | +--------------+--------+ them. The certificate is | 1738 | | certificate | client | sent in client_cook messages, | 1739 | | | | where it is used for trans- | 1740 | | | | portation of the public key | 1741 | | | | as well as (optionally) for | 1742 | | | | verification of client | 1743 | | | | authorization. | 1744 +---------+--------------+--------+-------------------------------+ 1746 This table shows the kind of cryptographic resources that NTS 1747 participants of server and client role should have ready before NTS 1748 communication starts. 1750 ++===========================================++ 1751 || || 1752 || Secure Authentication and Cookie Exchange || 1753 || || 1754 ++=======_ _=================================++ 1755 | 1756 | At least one 1757 | successful 1758 V 1759 ++=======[ ]=======++ 1760 || Unicast Time |>-----\ As long as further 1761 || Synchronization || | synchronization 1762 || Exchange(s) |<-----/ is desired 1763 ++=======_ _=======++ 1764 | 1765 \ Other (unspecified) 1766 Sufficient \ / methods which give 1767 accuracy \ either or / sufficient accuracy 1768 \----------\ /---------/ 1769 | 1770 | 1771 V 1772 ++========[ ]=========++ 1773 || Broadcast || 1774 || Parameter Exchange || 1775 ++========_ _=========++ 1776 | 1777 | One successful 1778 | per client 1779 V 1780 ++=======[ ]=======++ 1781 || Broadcast Time |>--------\ As long as further 1782 || Synchronization || | synchronization 1783 || Reception |<--------/ is desired 1784 ++=======_ _=======++ 1785 | 1786 / \ 1787 either / \ or 1788 /----------/ \-------------\ 1789 | | 1790 V V 1791 ++========[ ]========++ ++========[ ]========++ 1792 || Keycheck Exchange || || Keycheck Exchange || 1793 ++===================++ || with TimeSync || 1794 ++===================++ 1796 This diagram shows the dependencies between the different message 1797 exchanges and procedures which NTS offers. 1799 Authors' Addresses 1801 Dieter Sibold 1802 Physikalisch-Technische Bundesanstalt 1803 Bundesallee 100 1804 Braunschweig D-38116 1805 Germany 1807 Phone: +49-(0)531-592-8420 1808 Fax: +49-531-592-698420 1809 Email: dieter.sibold@ptb.de 1811 Stephen Roettger 1812 Google Inc. 1814 Email: stephen.roettger@googlemail.com 1816 Kristof Teichel 1817 Physikalisch-Technische Bundesanstalt 1818 Bundesallee 100 1819 Braunschweig D-38116 1820 Germany 1822 Phone: +49-(0)531-592-8421 1823 Email: kristof.teichel@ptb.de