idnits 2.17.1 draft-ietf-ntp-network-time-security-15.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 (September 22, 2016) is 2773 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) == Unused Reference: 'RFC2104' is defined on line 919, but no explicit reference was found in the text ** 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 (~~), 4 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: March 26, 2017 Google Inc. 6 K. Teichel 7 PTB 8 September 22, 2016 10 Network Time Security 11 draft-ietf-ntp-network-time-security-15 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 March 26, 2017. 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, MAC Algorithms and Generating MACs . . . . . . . 16 92 7.1. Server Seed . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . 16 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 9.2. Initial Verification of the Server Certificates . . . . . 18 98 9.3. Revocation of Server Certificates . . . . . . . . . . . . 18 99 9.4. Mitigating Denial-of-Service for broadcast packets . . . 18 100 9.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 18 101 9.6. Random Number Generation . . . . . . . . . . . . . . . . 20 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 105 11.2. Informative References . . . . . . . . . . . . . . . . . 21 106 Appendix A. (informative) TICTOC Security Requirements . . . . . 22 107 Appendix B. (normative) Inherent Association Protocol Messages . 23 108 B.1. Overview of NTS with Inherent Association Protocol . . . 23 109 B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24 110 B.2.1. Goals of the Access Message Exchange . . . . . . . . 24 111 B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24 112 B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24 113 B.2.4. Procedure Overview of the Access Exchange . . . . . . 24 114 B.3. Association Message Exchange . . . . . . . . . . . . . . 25 115 B.3.1. Goals of the Association Exchange . . . . . . . . . . 25 116 B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 25 117 B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26 118 B.3.4. Procedure Overview of the Association Exchange . . . 26 119 B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 27 120 B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28 121 B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 28 122 B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 28 123 B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 29 124 B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 30 125 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 32 126 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 32 127 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 34 128 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 35 129 C.4. Authentication of Received Packets . . . . . . . . . . . 35 130 Appendix D. (informative) Dependencies . . . . . . . . . . . . . 37 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 133 1. Introduction 135 Time synchronization protocols are increasingly utilized to 136 synchronize clocks in networked infrastructures. Successful attacks 137 against the time synchronization protocol can seriously degrade the 138 reliable performance of such infrastructures. Therefore, time 139 synchronization protocols have to be secured if they are applied in 140 environments that are prone to malicious attacks. This can be 141 accomplished either by utilization of external security protocols, 142 like IPsec or TLS, or by intrinsic security measures of the time 143 synchronization protocol. 145 The two most popular time synchronization protocols, the Network Time 146 Protocol (NTP) [RFC5905] and the Precision Time Protocol (PTP) 147 [IEEE1588], currently do not provide adequate intrinsic security 148 precautions. This document specifies generic security measures which 149 enable these and possibly other protocols to verify the authenticity 150 of the time server/master and the integrity of the time 151 synchronization protocol packets. The utilization of these measures 152 for a given specific time synchronization protocol has to be 153 described in a separate document. 155 [RFC7384] specifies that a security mechanism for timekeeping must be 156 designed in such a way that it does not degrade the quality of the 157 time transfer. This implies that for time keeping the increase in 158 bandwidth and message latency caused by the security measures should 159 be small. Also, NTP as well as PTP work via UDP and connections are 160 stateless on the server/master side. Therefore, all security 161 measures in this document are designed in such a way that they add 162 little demand for bandwidth, that the necessary calculations can be 163 executed in a fast manner, and that the measures do not require a 164 server/master to keep state of a connection. 166 2. Terminology 168 2.1. Terms and Abbreviations 170 MITM Man In The Middle 172 NTS Network Time Security 174 TESLA Timed Efficient Stream Loss-tolerant Authentication 176 MAC Message Authentication Code 178 2.2. Common Terminology for PTP and NTP 180 This document refers to different time synchronization protocols, in 181 particular to both the PTP and the NTP. Throughout the document the 182 term "server" applies to both a PTP master and an NTP server. 183 Accordingly, the term "client" applies to both a PTP slave and an NTP 184 client. 186 3. Security Threats 188 The document "Security Requirements of Time Protocols in Packet 189 Switched Networks" [RFC7384] contains a profound analysis of security 190 threats and requirements for time synchronization protocols. 192 4. Objectives 194 The objectives of the NTS specification are as follows: 196 o Authenticity: NTS enables the client to authenticate its time 197 server(s). 199 o Integrity: NTS protects the integrity of time synchronization 200 protocol packets via a message authentication code (MAC). 202 o Confidentiality: NTS does not provide confidentiality protection 203 of the time synchronization packets. 205 o Authorization: NTS enables the client to verify its time server's 206 authorization. NTS optionally enables the server to verify the 207 client's authorization as well. 209 o Request-Response-Consistency: NTS enables a client to match an 210 incoming response to a request it has sent. NTS also enables the 211 client to deduce from the response whether its request to the 212 server has arrived without alteration. 214 o Applicability to Protocols: NTS can be used to secure different 215 time synchronization protocols, specifically at least NTP and PTP. 217 o Integration with Protocols: A client or server running an NTS- 218 secured version of a time protocol does not negatively affect 219 other participants who are running unsecured versions of that 220 protocol. 222 o Server-Side Statelessness: All security measures of NTS work 223 without creating the necessity for a server to keep state of a 224 connection. 226 o Prevention of Amplification Attacks: All communication introduced 227 by NTS offers protection against abuse for amplification denial- 228 of-service attacks. 230 5. NTS Overview 232 NTS initially verifies the authenticity of the time server and 233 exchanges a symmetric key, the so-called cookie, as well as a key 234 input value (KIV). The KIV can be opaque for the client. After the 235 cookie and the KIV are exchanged, the client then uses them to 236 protect the authenticity and the integrity of subsequent unicast-type 237 time synchronization packets. In order to do this, a Message 238 Authentication Code (MAC) is attached to each time synchronization 239 packet. The calculation of the MAC includes the whole time 240 synchronization packet and the cookie which is shared between client 241 and server. 243 The cookie is calculated according to: 245 cookie = MSB_ (MAC(server seed, KIV)), 247 with the server seed as the key, where KIV is the client's key input 248 value, and where the application of the function MSB_ returns only 249 the b most significant bits. The server seed is a random value of 250 bit length b that the server possesses, which has to remain secret. 251 The cookie deterministically depends on KIV as long as the server 252 seed stays the same. The server seed has to be refreshed 253 periodically in order to provide key freshness as required in 254 [RFC7384]. See Section 7 for details on seed refreshing. 256 Since the server does not keep a state of the client, it has to 257 recalculate the cookie each time it receives a unicast time 258 synchronization request from the client. To this end, the client has 259 to attach its KIV to each request (see Section 6.1). 261 Note: The communication of the KIV and the cookie can be performed 262 between client and server directly, or via a third party key 263 distribution entity. 265 For broadcast-type messages, authenticity and integrity of the time 266 synchronization packets are also ensured by a MAC, which is attached 267 to the time synchronization packet by the sender. Verification of 268 the broadcast-type packets' authenticity is based on the TESLA 269 protocol, in particular on its "not re-using keys" scheme, see 270 Section 3.7.2 of [RFC4082]. TESLA uses a one-way chain of keys, 271 where each key is the output of a one-way function applied to the 272 previous key in the chain. The server securely shares the last 273 element of the chain with all clients. The server splits time into 274 intervals of uniform duration and assigns each key to an interval in 275 reverse order. At each time interval, the server sends a broadcast 276 packet appended by a MAC, calculated using the corresponding key, and 277 the key of the previous disclosure interval. The client verifies the 278 MAC by buffering the packet until disclosure of the key in its 279 associated disclosure interval occurs. In order to be able to verify 280 the timeliness of the packets, the client has to be loosely time 281 synchronized with the server. This has to be accomplished before 282 broadcast associations can be used. For checking timeliness of 283 packets, NTS uses another, more rigorous check in addition to just 284 the clock lookup used in the TESLA protocol. For a more detailed 285 description of how NTS employs and customizes TESLA, see Appendix C. 287 6. Protocol Messages 289 This section describes the types of messages needed for secure time 290 synchronization with NTS. 292 For some guidance on how these message types can be realized in 293 practice, and integrated into the communication flow of existing time 294 synchronization protocols, see [I-D.ietf-ntp-cms-for-nts-message], a 295 companion document for NTS. Said document describes ASN.1 encodings 296 for those message parts that have to be added to a time 297 synchronization protocol for security reasons. 299 6.1. Unicast Time Synchronisation Messages 301 In this message exchange, the usual time synchronization process is 302 executed, with the addition of integrity protection for all messages 303 that the server sends. This message exchange can be repeatedly 304 performed as often as the client desires and as long as the integrity 305 of the server's time responses is verified successfully. 307 6.1.1. Preconditions for the Unicast Time Synchronization Exchange 309 Before this message exchange is available, there are some 310 requirements that the client and server need to meet: 312 o They MUST negotiate the algorithm for the MAC used in the time 313 synchronization messages. Authenticity and integrity of the 314 communication MUST be ensured. 316 o The client MUST know a key input value KIV. Authenticity and 317 integrity of the communication MUST be ensured. 319 o Client and server MUST exchange the cookie (which depends on the 320 KIV as described in section Section 5). Authenticity, 321 confidentiality and integrity of the communication MUST be 322 ensured. 324 One way of realizing these requirements is to use the Association and 325 Cookie Message Exchanges described in Appendix B. 327 6.1.2. Goals of the Unicast Time Synchronization Exchange 329 The unicast time synchronization exchange: 331 o exchanges time synchronization data as specified by the 332 appropriate time synchronization protocol, 334 o guarantees authenticity and integrity of the request to the 335 server, 337 o guarantees authenticity and integrity of the response to the 338 client, 340 o guarantees request-response-consistency to the client. 342 6.1.3. Message Type: "time_request" 344 This message is sent by the client when it requests a time exchange. 345 It contains 347 o the NTS message ID "time_request", 349 o the negotiated version number, 351 o a nonce, 353 o the negotiated MAC algorithm, 355 o the client's key input value (for which the client knows the 356 associated cookie), 358 o optional: a MAC (generated with the cookie as key) for 359 verification of all of the above data. 361 6.1.4. Message Type: "time_response" 363 This message is sent by the server after it has received a 364 time_request message. Prior to this the server MUST recalculate the 365 client's cookie by using the received key input value and the 366 transmitted MAC algorithm. The message contains 368 o the NTS message ID "time_response", 370 o the version number as transmitted in time_request, 372 o the server's time synchronization response data, 374 o the nonce transmitted in time_request, 375 o a MAC (generated with the cookie as key) for verification of all 376 of the above data. 378 6.1.5. Procedure Overview of the Unicast Time Synchronization Exchange 380 For a unicast time synchronization exchange, the following steps are 381 performed: 383 1. The client sends a time_request message to the server. The 384 client MUST save the included nonce and the transmit_timestamp 385 (from the time synchronization data) as a correlated pair for 386 later verification steps. Optionally, the client protects the 387 request message with an appended MAC. 389 2. Upon receipt of a time_request message, the server performs the 390 following steps: 392 * It re-calculates the cookie. 394 * If the request message contains a MAC the server re-calculates 395 the MAC and compares this value with the MAC in the received 396 data. 398 + If the re-calculated MAC does not match the MAC in the 399 received data the server MUST stop the processing of the 400 request. 402 + If the re-calculated MAC matches the MAC in the received 403 data the server continues to process the request. 405 * The server computes the necessary time synchronization data 406 and constructs a time_response message as given in 407 Section 6.1.4. 409 3. The client awaits a reply in the form of a time_response message. 410 Upon receipt, it checks: 412 * that the transmitted version number matches the one negotiated 413 previously, 415 * that the transmitted nonce belongs to a previous time_request 416 message, 418 * that the transmit_timestamp in that time_request message 419 matches the corresponding time stamp from the synchronization 420 data received in the time_response, and 422 * that the appended MAC verifies the received synchronization 423 data, version number and nonce. 425 If at least one of the first three checks fails (i.e. if the 426 version number does not match, if the client has never used the 427 nonce transmitted in the time_response message, or if it has used 428 the nonce with initial time synchronization data different from 429 that in the response), then the client MUST ignore this 430 time_response message. If the MAC is invalid, the client MUST do 431 one of the following: abort the run or send another cookie 432 request (because the cookie might have changed due to a server 433 seed refresh). If both checks are successful, the client SHOULD 434 continue time synchronization. 436 +-----------------------+ 437 | o Re-generate cookie | 438 | o Assemble response | 439 | o Generate MAC | 440 +-----------+-----------+ 441 | 442 <-+-> 444 Server -----------------------------------------------> 445 /| \ 446 time_ / \ time_ 447 request / \ response 448 / \| 449 Client -----------------------------------------------> 451 <------ Unicast time ------> <- Client-side -> 452 synchronization validity 453 exchange checks 455 Procedure for unicast time synchronization exchange. 457 6.2. Broadcast Time Synchronization Exchange 459 6.2.1. Preconditions for the Broadcast Time Synchronization Exchange 461 Before this message exchange is available, there are some 462 requirements that the client and server need to meet: 464 o The client MUST receive all the information necessary to process 465 broadcast time synchronization messages from the server. This 466 includes 468 * the one-way functions used for building the key chain, 469 * the last key of the key chain, 471 * time interval duration, 473 * the disclosure delay (number of intervals between use and 474 disclosure of a key), 476 * the time at which the next time interval will start, and 478 * the next interval's associated index. 480 o The communication of the data listed above MUST guarantee 481 authenticity of the server, as well as integrity and freshness of 482 the broadcast parameters to the client. 484 6.2.2. Goals of the Broadcast Time Synchronization Exchange 486 The broadcast time synchronization exchange: 488 o transmits (broadcast) time synchronization data from the server to 489 the client as specified by the appropriate time synchronization 490 protocol, 492 o guarantees to the client that the received synchronization data 493 has arrived in a timely manner as required by the TESLA protocol 494 and is trustworthy enough to be stored for later checks, 496 o additionally guarantees authenticity of a certain broadcast 497 synchronization message in the client's storage. 499 6.2.3. Message Type: "server_broad" 501 This message is sent by the server over the course of its broadcast 502 schedule. It is part of any broadcast association. It contains 504 o the NTS message ID "server_broad", 506 o the version number that the server is working under, 508 o time broadcast data, 510 o the index that belongs to the current interval (and therefore 511 identifies the current, yet undisclosed, key), 513 o the disclosed key of the previous disclosure interval (current 514 time interval minus disclosure delay), 516 o a MAC, calculated with the key for the current time interval, 517 verifying 519 * the message ID, 521 * the version number, and 523 * the time data. 525 6.2.4. Procedure Overview of Broadcast Time Synchronization Exchange 527 A broadcast time synchronization message exchange consists of the 528 following steps: 530 1. The server follows the TESLA protocol by regularly sending 531 server_broad messages as described in Section 6.2.3, adhering to 532 its own disclosure schedule. 534 2. The client awaits time synchronization data in the form of a 535 server_broadcast message. Upon receipt, it performs the 536 following checks: 538 * Proof that the MAC is based on a key that is not yet disclosed 539 (packet timeliness). This is achieved via a combination of 540 checks. First, the disclosure schedule is used, which 541 requires loose time synchronization. If this is successful, 542 the client obtains a stronger guarantee via a key check 543 exchange (see below). If its timeliness is verified, the 544 packet will be buffered for later authentication. Otherwise, 545 the client MUST discard it. Note that the time information 546 included in the packet will not be used for synchronization 547 until its authenticity could also be verified. 549 * The client checks that it does not already know the disclosed 550 key. Otherwise, the client SHOULD discard the packet to avoid 551 a buffer overrun. If this check is successful, the client 552 ensures that the disclosed key belongs to the one-way key 553 chain by applying the one-way function until equality with a 554 previous disclosed key is shown. If it is falsified, the 555 client MUST discard the packet. 557 * If the disclosed key is legitimate, then the client verifies 558 the authenticity of any packet that it has received during the 559 corresponding time interval. If authenticity of a packet is 560 verified, then it is released from the buffer and its time 561 information can be utilized. If the verification fails, then 562 authenticity is not given. In this case, the client MUST 563 request authentic time from the server by means other than 564 broadcast messages. Also, the client MUST re-initialize the 565 broadcast sequence with a "client_bpar" message if the one-way 566 key chain expires, which it can check via the disclosure 567 schedule. 569 See RFC 4082[RFC4082] for a detailed description of the packet 570 verification process. 572 Server ----------------------------------> 573 \ 574 \ server_ 575 \ broad 576 \| 577 Client ----------------------------------> 579 < Broadcast > <- Client-side -> 580 time sync. validity and 581 exchange timeliness 582 checks 584 Procedure for broadcast time synchronization exchange. 586 6.3. Broadcast Keycheck 588 This message exchange is performed for an additional check of packet 589 timeliness in the course of the TESLA scheme, see Appendix C. 591 6.3.1. Preconditions for the Broadcast Keycheck Exchange 593 Before this message exchange is available, there are some 594 requirements that the client and server need to meet: 596 o They MUST negotiate the algorithm for the MAC used in the time 597 synchronization messages. Authenticity and integrity of the 598 communication MUST be ensured. 600 o The client MUST know a key input value KIV. Authenticity and 601 integrity of the communication MUST be ensured. 603 o Client and server MUST exchange the cookie (which depends on the 604 KIV as described in section Section 5). Authenticity, 605 confidentiality and integrity of the communication MUST be 606 ensured. 608 These requirements conform to those for the unicast time 609 synchronization exchange. Accordingly, they too can be realized via 610 the Association and Cookie Message Exchanges described in Appendix B 611 (Appendix B). 613 6.3.2. Goals of the Broadcast Keycheck Exchange 615 The keycheck exchange: 617 o guarantees to the client that the key belonging to the respective 618 TESLA interval communicated in the exchange had not been disclosed 619 before the client_keycheck message was sent. 621 o guarantees to the client the timeliness of any broadcast packet 622 secured with this key if it arrived before client_keycheck was 623 sent. 625 6.3.3. Message Type: "client_keycheck" 627 A message of this type is sent by the client in order to initiate an 628 additional check of packet timeliness for the TESLA scheme. It 629 contains 631 o the NTS message ID "client_keycheck", 633 o the NTS version number negotiated during association, 635 o a nonce, 637 o an interval number from the TESLA disclosure schedule, 639 o the MAC algorithm negotiated during association, 641 o the client's key input value KIV, and 643 o optional: a MAC (generated with the cookie as key) for 644 verification of all of the above data. 646 6.3.4. Message Type: "server_keycheck" 648 A message of this type is sent by the server upon receipt of a 649 client_keycheck message during the broadcast loop of the server. 650 Prior to this, the server MUST recalculate the client's cookie by 651 using the received key input value and the transmitted MAC algorithm. 652 It contains 654 o the NTS message ID "server_keycheck" 656 o the version number as transmitted in "client_keycheck, 658 o the nonce transmitted in the client_keycheck message, 659 o the interval number transmitted in the client_keycheck message, 660 and 662 o a MAC (generated with the cookie as key) for verification of all 663 of the above data. 665 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 667 A broadcast keycheck message exchange consists of the following 668 steps: 670 1. The client sends a client_keycheck message. It MUST memorize the 671 nonce and the time interval number that it sends as a correlated 672 pair. 674 2. Upon receipt of a client_keycheck message the server performs as 675 follows: If the client_keycheck message contains a MAC the server 676 re-calculates the MAC and compares this value with the MAC in the 677 received data. 679 * If the re-calculated MAC does not match the MAC in the 680 received data the server MUST stop the processing of the 681 request. 683 * If the re-calculated MAC matches the MAC in the received data 684 the server continues to process the request: It looks up 685 whether it has already disclosed the key associated with the 686 interval number transmitted in that message. If it has not 687 disclosed it, it constructs and sends the appropriate 688 server_keycheck message as described in Section 6.3.4. For 689 more details, see also Appendix C. 691 3. The client awaits a reply in the form of a server_keycheck 692 message. On receipt, it performs the following checks: 694 * that the transmitted version number matches the one negotiated 695 previously, 697 * that the transmitted nonce belongs to a previous 698 client_keycheck message, 700 * that the TESLA interval number in that client_keycheck message 701 matches the corresponding interval number from the 702 server_keycheck, and 704 * that the appended MAC verifies the received data. 706 +----------------------+ 707 | o Assemble response | 708 | o Re-generate cookie | 709 | o Generate MAC | 710 +-----------+----------+ 711 | 712 <-+-> 713 Server ---------------------------------------------> 714 \ /| \ 715 \ server_ client_ / \ server_ 716 \ broad keycheck / \ keycheck 717 \| / \| 718 Client ---------------------------------------------> 719 <-------- Extended broadcast time -------> 720 synchronization exchange 722 <---- Keycheck exchange ---> 724 Procedure for extended broadcast time synchronization exchange. 726 7. Server Seed, MAC Algorithms and Generating MACs 728 7.1. Server Seed 730 The server has to calculate a random seed which has to be kept 731 secret. The server MUST generate a seed for each supported MAC 732 algorithm, see Section 7.2. 734 According to the requirements in [RFC7384], the server MUST refresh 735 each server seed periodically. Consequently, the cookie memorized by 736 the client becomes obsolete. In this case, the client cannot verify 737 the MAC attached to subsequent time response messages and has to 738 respond accordingly by re-initiating the protocol with a cookie 739 request (Appendix B.4). 741 7.2. MAC Algorithms 743 MAC algorithms are used for calculation of the cookie and the actual 744 MAC. The client and the server negotiate a MAC algorithm during the 745 association phase at the beginning. The selected algorithm MUST be 746 used for all cookie and MAC creation processes in that run. 748 Note: Any MAC algorithm is prone to be compromised in the future. A 749 successful attack on a MAC algorithm would enable any NTS client 750 to derive the server seed from its own cookie. Therefore, the 751 server MUST have separate seed values for its different supported 752 MAC algorithms. This way, knowledge gained from an attack on a 753 MAC algorithm can at least only be used to compromise such clients 754 who use this algorithm as well. 756 8. IANA Considerations 758 As mentioned, this document generically specifies security measures 759 whose utilization for any given specific time synchronization 760 protocol requires a separate document. Consequently, this document 761 itself does not have any IANA actions (TO BE REVIEWED). 763 9. Security Considerations 765 Aspects of security for time synchronization protocols are treated 766 throughout this document. For a comprehensive discussion of security 767 requirements in time synchronization contexts, refer to [RFC7384]. 768 See Appendix A for a tabular overview of how NTS deals with those 769 requirements. 771 Additional NTS specific discussion of security issues can be found in 772 the following subsections. 774 Note: Any separate document describing the utilization of NTS to a 775 specific time synchronization protocol may additionally introduce 776 discussion of its own specific security considerations. 778 9.1. Privacy 780 The payload of time synchronization protocol packets of two-way time 781 transfer approaches like NTP and PTP consists basically of time 782 stamps, which are not considered secret [RFC7384]. Therefore, 783 encryption of the time synchronization protocol packet's payload is 784 not considered in this document. However, an attacker can exploit 785 the exchange of time synchronization protocol packets for topology 786 detection and inference attacks as described in [RFC7624]. To make 787 such attacks more difficult, that draft recommends the encryption of 788 the packet payload. Yet, in the case of time synchronization 789 protocols the confidentiality protection of time synchronization 790 packet's payload is of secondary importance since the packet's meta 791 data (IP addresses, port numbers, possibly packet size and regular 792 sending intervals) carry more information than the payload. To 793 enhance the privacy of the time synchronization partners, the usage 794 of tunnel protocols such as IPsec and MACsec, where applicable, is 795 therefore more suited than confidentiality protection of the payload. 797 9.2. Initial Verification of the Server Certificates 799 The client may wish to verify the validity of certificates during the 800 initial association phase. Since it generally has no reliable time 801 during this initial communication phase, it is impossible to verify 802 the period of validity of the certificates. To solve this chicken- 803 and-egg problem, the client has to rely on external means. 805 9.3. Revocation of Server Certificates 807 According to Section 7, it is the client's responsibility to initiate 808 a new association with the server after the server's certificate 809 expires. To this end, the client reads the expiration date of the 810 certificate during the certificate message exchange (Appendix B.3.3). 811 Furthermore, certificates may also be revoked prior to the normal 812 expiration date. To increase security the client MAY periodically 813 verify the state of the server's certificate via Online Certificate 814 Status Protocol (OCSP) Online Certificate Status Protocol (OCSP) 815 [RFC6960]. 817 9.4. Mitigating Denial-of-Service for broadcast packets 819 TESLA authentication buffers packets for delayed authentication. 820 This makes the protocol vulnerable to flooding attacks, causing the 821 client to buffer excessive numbers of packets. To add stronger DoS 822 protection to the protocol, the client and the server use the "not 823 re-using keys" scheme of TESLA as pointed out in Section 3.7.2 of RFC 824 4082 [RFC4082]. In this scheme the server never uses a key for the 825 MAC generation more than once. Therefore, the client can discard any 826 packet that contains a disclosed key it already knows, thus 827 preventing memory flooding attacks. 829 Discussion: Note that an alternative approach to enhance TESLA's 830 resistance against DoS attacks involves the addition of a group 831 MAC to each packet. This requires the exchange of an additional 832 shared key common to the whole group. This adds additional 833 complexity to the protocol and hence is currently not considered 834 in this document. 836 9.5. Delay Attack 838 In a packet delay attack, an adversary with the ability to act as a 839 MITM delays time synchronization packets between client and server 840 asymmetrically [RFC7384]. This prevents the client from accurately 841 measuring the network delay, and hence its time offset to the server 842 [Mizrahi]. The delay attack does not modify the content of the 843 exchanged synchronization packets. Therefore, cryptographic means do 844 not provide a feasible way to mitigate this attack. However, several 845 non-cryptographic precautions can be taken in order to detect this 846 attack. 848 1. Usage of multiple time servers: this enables the client to detect 849 the attack, provided that the adversary is unable to delay the 850 synchronization packets between the majority of servers. This 851 approach is commonly used in NTP to exclude incorrect time 852 servers [RFC5905]. 854 2. Multiple communication paths: The client and server utilize 855 different paths for packet exchange as described in the I-D 856 [I-D.ietf-tictoc-multi-path-synchronization]. The client can 857 detect the attack, provided that the adversary is unable to 858 manipulate the majority of the available paths [Shpiner]. Note 859 that this approach is not yet available, neither for NTP nor for 860 PTP. 862 3. Usage of an encrypted connection: the client exchanges all 863 packets with the time server over an encrypted connection (e.g. 864 IPsec). This measure does not mitigate the delay attack, but it 865 makes it more difficult for the adversary to identify the time 866 synchronization packets. 868 4. For unicast-type messages: Introduction of a threshold value for 869 the delay time of the synchronization packets. The client can 870 discard a time server if the packet delay time of this time 871 server is larger than the threshold value. 873 Additional provision against delay attacks has to be taken for 874 broadcast-type messages. This mode relies on the TESLA scheme which 875 is based on the requirement that a client and the broadcast server 876 are loosely time synchronized. Therefore, a broadcast client has to 877 establish time synchronization with its broadcast server before it 878 starts utilizing broadcast messages for time synchronization. 880 One possible way to achieve this initial synchronization is to 881 establish a unicast association with its broadcast server until time 882 synchronization and calibration of the packet delay time is achieved. 883 After that, the client can establish a broadcast association with the 884 broadcast server and utilizes TESLA to verify integrity and 885 authenticity of any received broadcast packets. 887 An adversary who is able to delay broadcast packets can cause a time 888 adjustment at the receiving broadcast clients. If the adversary 889 delays broadcast packets continuously, then the time adjustment will 890 accumulate until the loose time synchronization requirement is 891 violated, which breaks the TESLA scheme. To mitigate this 892 vulnerability the security condition in TESLA has to be supplemented 893 by an additional check in which the client, upon receipt of a 894 broadcast message, verifies the status of the corresponding key via a 895 unicast message exchange with the broadcast server (see Appendix C.4 896 for a detailed description of this check). Note that a broadcast 897 client should also apply the above-mentioned precautions as far as 898 possible. 900 9.6. Random Number Generation 902 At various points of the protocol, the generation of random numbers 903 is required. The employed methods of generation need to be 904 cryptographically secure. See [RFC4086] for guidelines concerning 905 this topic. 907 10. Acknowledgements 909 The authors would like to thank Tal Mizrahi, Russ Housley, Steven 910 Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer 911 and Florian Weimer for discussions and comments on the design of NTS. 912 Also, thanks go to Harlan Stenn and Richard Welty for their technical 913 review and specific text contributions to this document. 915 11. References 917 11.1. Normative References 919 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 920 Hashing for Message Authentication", RFC 2104, 921 DOI 10.17487/RFC2104, February 1997, 922 . 924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 925 Requirement Levels", BCP 14, RFC 2119, 926 DOI 10.17487/RFC2119, March 1997, 927 . 929 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 930 Briscoe, "Timed Efficient Stream Loss-Tolerant 931 Authentication (TESLA): Multicast Source Authentication 932 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 933 June 2005, . 935 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 936 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 937 October 2014, . 939 11.2. Informative References 941 [I-D.ietf-ntp-cms-for-nts-message] 942 Sibold, D., Teichel, K., Roettger, S., and R. Housley, 943 "Protecting Network Time Security Messages with the 944 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 945 for-nts-message-04 (work in progress), July 2015. 947 [I-D.ietf-tictoc-multi-path-synchronization] 948 Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- 949 Path Time Synchronization", draft-ietf-tictoc-multi-path- 950 synchronization-02 (work in progress), April 2015. 952 [IEEE1588] 953 IEEE Instrumentation and Measurement Society. TC-9 Sensor 954 Technology, "IEEE standard for a precision clock 955 synchronization protocol for networked measurement and 956 control systems", 2008. 958 [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks 959 against time synchronization protocols", in Proceedings 960 of Precision Clock Synchronization for Measurement Control 961 and Communication, ISPCS 2012, pp. 1-6, September 2012. 963 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 964 "Randomness Requirements for Security", BCP 106, RFC 4086, 965 DOI 10.17487/RFC4086, June 2005, 966 . 968 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 969 "Network Time Protocol Version 4: Protocol and Algorithms 970 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 971 . 973 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 974 Galperin, S., and C. Adams, "X.509 Internet Public Key 975 Infrastructure Online Certificate Status Protocol - OCSP", 976 RFC 6960, DOI 10.17487/RFC6960, June 2013, 977 . 979 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 980 Trammell, B., Huitema, C., and D. Borkmann, 981 "Confidentiality in the Face of Pervasive Surveillance: A 982 Threat Model and Problem Statement", RFC 7624, 983 DOI 10.17487/RFC7624, August 2015, 984 . 986 [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time 987 Protocols", in Proceedings of Precision Clock 988 Synchronization for Measurement Control and Communication, 989 ISPCS 2013, pp. 1-6, September 2013. 991 Appendix A. (informative) TICTOC Security Requirements 993 The following table compares the NTS specifications against the 994 TICTOC security requirements [RFC7384]. 996 +---------+------------------------------+-------------+------------+ 997 | Section | Requirement from RFC 7384 | Requirement | NTS | 998 | | | level | | 999 +---------+------------------------------+-------------+------------+ 1000 | 5.1.1 | Authentication of Servers | MUST | OK | 1001 +---------+------------------------------+-------------+------------+ 1002 | 5.1.1 | Authorization of Servers | MUST | OK | 1003 +---------+------------------------------+-------------+------------+ 1004 | 5.1.2 | Recursive Authentication of | MUST | OK | 1005 | | Servers (Stratum 1) | | | 1006 +---------+------------------------------+-------------+------------+ 1007 | 5.1.2 | Recursive Authorization of | MUST | OK | 1008 | | Servers (Stratum 1) | | | 1009 +---------+------------------------------+-------------+------------+ 1010 | 5.1.3 | Authentication and | MAY | Optional, | 1011 | | Authorization of Clients | | Limited | 1012 +---------+------------------------------+-------------+------------+ 1013 | 5.2 | Integrity protection | MUST | OK | 1014 +---------+------------------------------+-------------+------------+ 1015 | 5.3 | Spoofing Prevention | MUST | OK | 1016 +---------+------------------------------+-------------+------------+ 1017 | 5.4 | Protection from DoS attacks | SHOULD | OK | 1018 | | against the time protocol | | | 1019 +---------+------------------------------+-------------+------------+ 1020 | 5.5 | Replay protection | MUST | OK | 1021 +---------+------------------------------+-------------+------------+ 1022 | 5.6 | Key freshness | MUST | OK | 1023 +---------+------------------------------+-------------+------------+ 1024 | | Security association | SHOULD | OK | 1025 +---------+------------------------------+-------------+------------+ 1026 | | Unicast and multicast | SHOULD | OK | 1027 | | associations | | | 1028 +---------+------------------------------+-------------+------------+ 1029 | 5.7 | Performance: no degradation | MUST | OK | 1030 | | in quality of time transfer | | | 1031 +---------+------------------------------+-------------+------------+ 1032 | | Performance: lightweight | SHOULD | OK | 1033 | | computation | | | 1034 +---------+------------------------------+-------------+------------+ 1035 | | Performance: storage | SHOULD | OK | 1036 +---------+------------------------------+-------------+------------+ 1037 | | Performance: bandwidth | SHOULD | OK | 1038 +---------+------------------------------+-------------+------------+ 1039 | 5.8 | Confidentiality protection | MAY | NO | 1040 +---------+------------------------------+-------------+------------+ 1041 | 5.9 | Protection against Packet | MUST | Limited*) | 1042 | | Delay and Interception | | | 1043 | | Attacks | | | 1044 +---------+------------------------------+-------------+------------+ 1045 | 5.10 | Secure mode | MUST | OK | 1046 +---------+------------------------------+-------------+------------+ 1047 | | Hybrid mode | SHOULD | - | 1048 +---------+------------------------------+-------------+------------+ 1050 *) See discussion in Section 9.5. 1052 Comparison of NTS specification against Security Requirements of Time 1053 Protocols in Packet Switched Networks (RFC 7384) 1055 Appendix B. (normative) Inherent Association Protocol Messages 1057 This appendix presents a procedure that performs the association, the 1058 cookie, and also the broadcast parameter message exchanges between a 1059 client and a server. This procedure is one possible way to achieve 1060 the preconditions listed in Sections Section 6.1.1, Section 6.2.1, 1061 and Section 6.3.1 while taking into account the objectives given in 1062 Section Section 4. 1064 B.1. Overview of NTS with Inherent Association Protocol 1066 This inherent association protocol applies X.509 certificates to 1067 verify the authenticity of the time server and to exchange the 1068 cookie. This is done in two separate message exchanges, described 1069 below. An additional required exchange in advance serves to limit 1070 the amplification potential of the association message exchange. 1072 A client needs a public/private key pair for encryption, with the 1073 public key enclosed in a certificate. A server needs a public/ 1074 private key pair for signing, with the public key enclosed in a 1075 certificate. If a participant intends to act as both a client and a 1076 server, it MUST have two different key pairs for these purposes. 1078 If this protocol is employed, the hash value of the client's 1079 certificate is used as the client's key input value, i.e. the cookie 1080 is calculated according to: 1082 cookie = MSB_ (MAC(server seed, H(certificate of client))), 1084 Where the hash function H is the one used in the MAC algorithm. The 1085 client's certificate contains the client's public key and enables the 1086 server to identify the client, if client authorization is desired. 1088 B.2. Access Message Exchange 1090 This message exchange serves only to prevent the next (association) 1091 exchange from being abusable for amplification denial-of-service 1092 attacks. 1094 B.2.1. Goals of the Access Message Exchange 1096 The access message exchange: 1098 o transfers a secret value from the server to the client 1099 (initiator), 1101 o the secret value permits the client to initiate an association 1102 message exchange. 1104 B.2.2. Message Type: "client_access" 1106 This message is sent by a client who intends to perform an 1107 association exchange with the server in the future. It contains: 1109 o the NTS message ID "client_access". 1111 B.2.3. Message Type: "server_access" 1113 This message is sent by the server on receipt of a client_access 1114 message. It contains: 1116 o the NTS message ID "server_access", 1118 o an access key. 1120 B.2.4. Procedure Overview of the Access Exchange 1122 For an access exchange, the following steps are performed: 1124 1. The client sends a client_access message to the server. 1126 2. Upon receipt of a client_access, the server calculates the access 1127 key. It then sends a reply in the form of a server_access 1128 message. The server must either memorize the access key or 1129 alternatively apply a means by which it can reconstruct the 1130 access key. Note that in both cases the access key must be 1131 correlated with the address of the requester. Note also that if 1132 the server memorizes the access key for a requester, it has to 1133 keep state for a certain amount of time. 1135 3. The client waits for a response in the form of a server_access 1136 message. Upon receipt of one, it MUST memorize the included 1137 access key. 1139 B.3. Association Message Exchange 1141 In this message exchange, the participants negotiate the MAC and 1142 encryption algorithms that are used throughout the protocol. In 1143 addition, the client receives the certification chain up to a trusted 1144 anchor. With the established certification chain the client is able 1145 to verify the server's signatures and, hence, the authenticity of 1146 future NTS messages from the server is ensured. 1148 B.3.1. Goals of the Association Exchange 1150 The association exchange: 1152 o enables the client to verify any communication with the server as 1153 authentic, 1155 o lets the participants negotiate NTS version and algorithms, 1157 o guarantees authenticity and integrity of the negotiation result to 1158 the client, 1160 o guarantees to the client that the negotiation result is based on 1161 the client's original, unaltered request. 1163 B.3.2. Message Type: "client_assoc" 1165 This message is sent by the client if it wants to perform association 1166 with a server. It contains 1168 o the NTS message ID "client_assoc", 1170 o a nonce, 1172 o the access key obtained earlier via an access message exchange, 1174 o the version number of NTS that the client wants to use (this 1175 SHOULD be the highest version number that it supports), 1177 o a selection of accepted MAC algorithms, and 1178 o a selection of accepted encryption algorithms. 1180 B.3.3. Message Type: "server_assoc" 1182 This message is sent by the server upon receipt of client_assoc. It 1183 contains 1185 o the NTS message ID "server_assoc", 1187 o the nonce transmitted in client_assoc, 1189 o the client's proposal for the version number, selection of 1190 accepted MAC algorithms and selection of accepted encryption 1191 algorithms, as transmitted in client_assoc, 1193 o the version number used for the rest of the protocol (which SHOULD 1194 be determined as the minimum over the client's suggestion in the 1195 client_assoc message and the highest supported by the server), 1197 o the server's choice of algorithm for encryption and for MAC 1198 creation, all of which MUST be chosen from the client's proposals, 1200 o a signature, calculated over the data listed above, with the 1201 server's private key and according to the signature algorithm 1202 which is also used for the certificates that are included (see 1203 below), and 1205 o a chain of certificates, which starts at the server and goes up to 1206 a trusted authority; each certificate MUST be certified by the one 1207 directly following it. 1209 B.3.4. Procedure Overview of the Association Exchange 1211 For an association exchange, the following steps are performed: 1213 1. The client sends a client_assoc message to the server. It MUST 1214 keep the transmitted values for the version number and algorithms 1215 available for later checks. 1217 2. Upon receipt of a client_assoc message, the server checks the 1218 validity of the included access key. If it is not valid, the 1219 server MUST abort communication. If it is valid, the server 1220 constructs and sends a reply in the form of a server_assoc 1221 message as described in Appendix B.3.3. Upon unsuccessful 1222 negotiation for version number or algorithms the server_assoc 1223 message MUST contain an error code. 1225 3. The client waits for a reply in the form of a server_assoc 1226 message. After receipt of the message it performs the following 1227 checks: 1229 * The client checks that the message contains a conforming 1230 version number. 1232 * It checks that the nonce sent back by the server matches the 1233 one transmitted in client_assoc, 1235 * It also verifies that the server has chosen the encryption and 1236 MAC algorithms from its proposal sent in the client_assoc 1237 message and that this proposal was not altered. 1239 * Furthermore, it performs authenticity checks on the 1240 certificate chain and the signature. 1242 If one of the checks fails, the client MUST abort the run. 1244 +------------------------+ 1245 | o Check access key | 1246 +------------------------+ 1247 | o Choose version | 1248 | o Choose algorithms | 1249 | o Acquire certificates | 1250 | o Assemble response | 1251 | o Create signature | 1252 +-----------+------------+ 1253 | 1254 <-+-> 1256 Server ---------------------------> 1257 /| \ 1258 client_ / \ server_ 1259 assoc / \ assoc 1260 / \| 1261 Client ---------------------------> 1263 <------ Association -----> 1264 exchange 1266 Procedure for association and cookie exchange. 1268 B.4. Cookie Message Exchange 1270 During this message exchange, the server transmits a secret cookie to 1271 the client securely. The cookie will later be used for integrity 1272 protection during unicast time synchronization. 1274 B.4.1. Goals of the Cookie Exchange 1276 The cookie exchange: 1278 o enables the server to check the client's authorization via its 1279 certificate (optional), 1281 o supplies the client with the correct cookie and corresponding KIV 1282 for its association to the server, 1284 o guarantees to the client that the cookie originates from the 1285 server and that it is based on the client's original, unaltered 1286 request. 1288 o guarantees that the received cookie is unknown to anyone but the 1289 server and the client. 1291 B.4.2. Message Type: "client_cook" 1293 This message is sent by the client upon successful authentication of 1294 the server. In this message, the client requests a cookie from the 1295 server. The message contains 1297 o the NTS message ID "client_cook", 1299 o a nonce, 1301 o the negotiated version number, 1303 o the negotiated signature algorithm, 1305 o the negotiated encryption algorithm, 1307 o the negotiated MAC algorithm, 1309 o the client's certificate. 1311 B.4.3. Message Type: "server_cook" 1313 This message is sent by the server upon receipt of a client_cook 1314 message. The server generates the hash (the used hash function is 1315 the one used for the MAC algorithm) of the client's certificate, as 1316 conveyed during client_cook, in order to calculate the cookie 1317 according to Section 5. This message contains 1319 o the NTS message ID "server_cook" 1321 o the version number as transmitted in client_cook, 1322 o a concatenated datum which is encrypted with the client's public 1323 key, according to the encryption algorithm transmitted in the 1324 client_cook message. The concatenated datum contains 1326 * the nonce transmitted in client_cook, and 1328 * the cookie. 1330 o a signature, created with the server's private key, calculated 1331 over all of the data listed above. This signature MUST be 1332 calculated according to the transmitted signature algorithm from 1333 the client_cook message. 1335 B.4.4. Procedure Overview of the Cookie Exchange 1337 For a cookie exchange, the following steps are performed: 1339 1. The client sends a client_cook message to the server. The client 1340 MUST save the included nonce until the reply has been processed. 1342 2. Upon receipt of a client_cook message, the server checks whether 1343 it supports the given cryptographic algorithms. It then 1344 calculates the cookie according to the formula given in 1345 Section 5. The server MAY use the client's certificate to check 1346 that the client is authorized to use the secure time 1347 synchronization service. With this, it MUST construct a 1348 server_cook message as described in Appendix B.4.3. 1350 3. The client awaits a reply in the form of a server_cook message; 1351 upon receipt it executes the following actions: 1353 * It verifies that the received version number matches the one 1354 negotiated beforehand. 1356 * It verifies the signature using the server's public key. The 1357 signature has to authenticate the encrypted data. 1359 * It decrypts the encrypted data with its own private key. 1361 * It checks that the decrypted message is of the expected 1362 format: the concatenation of a nonce and a cookie of the 1363 expected bit lengths. 1365 * It verifies that the received nonce matches the nonce sent in 1366 the client_cook message. 1368 If one of those checks fails, the client MUST abort the run. 1370 +----------------------------+ 1371 | o OPTIONAL: Check client's | 1372 | authorization | 1373 | o Generate cookie | 1374 | o Encrypt inner message | 1375 | o Generate signature | 1376 +-------------+--------------+ 1377 | 1378 <-+-> 1380 Server ---------------------------> 1381 /| \ 1382 client_ / \ server_ 1383 cook / \ cook 1384 / \| 1385 Client ---------------------------> 1387 <--- Cookie exchange --> 1389 Procedure for association and cookie exchange. 1391 B.4.5. Broadcast Parameter Messages 1393 In this message exchange, the client receives the necessary 1394 information to execute the TESLA protocol in a secured broadcast 1395 association. The client can only initiate a secure broadcast 1396 association after successful association and cookie exchanges and 1397 only if it has made sure that its clock is roughly synchronized to 1398 the server's. 1400 See Appendix C for more details on TESLA. 1402 B.4.5.1. Goals of the Broadcast Parameter Exchange 1404 The broadcast parameter exchange 1406 o provides the client with all the information necessary to process 1407 broadcast time synchronization messages from the server, and 1409 o guarantees authenticity, integrity and freshness of the broadcast 1410 parameters to the client. 1412 B.4.5.2. Message Type: "client_bpar" 1414 This message is sent by the client in order to establish a secured 1415 time broadcast association with the server. It contains 1417 o the NTS message ID "client_bpar", 1418 o the NTS version number negotiated during association, 1420 o a nonce, and 1422 o the signature algorithm negotiated during association. 1424 B.4.5.3. Message Type: "server_bpar" 1426 This message is sent by the server upon receipt of a client_bpar 1427 message during the broadcast loop of the server. It contains 1429 o the NTS message ID "server_bpar", 1431 o the version number as transmitted in the client_bpar message, 1433 o the nonce transmitted in client_bpar, 1435 o the one-way functions used for building the key chain, and 1437 o the disclosure schedule of the keys. This contains: 1439 * the last key of the key chain, 1441 * time interval duration, 1443 * the disclosure delay (number of intervals between use and 1444 disclosure of a key), 1446 * the time at which the next time interval will start, and 1448 * the next interval's associated index. 1450 o The message also contains a signature signed by the server with 1451 its private key, verifying all the data listed above. 1453 B.4.5.4. Procedure Overview of the Broadcast Parameter Exchange 1455 A broadcast parameter exchange consists of the following steps: 1457 1. The client sends a client_bpar message to the server. It MUST 1458 remember the transmitted values for the nonce, the version number 1459 and the signature algorithm. 1461 2. Upon receipt of a client_bpar message, the server constructs and 1462 sends a server_bpar message as described in Appendix B.4.5.3. 1464 3. The client waits for a reply in the form of a server_bpar 1465 message, on which it performs the following checks: 1467 * The message must contain all the necessary information for the 1468 TESLA protocol, as listed in Appendix B.4.5.3. 1470 * The message must contain a nonce belonging to a client_bpar 1471 message that the client has previously sent. 1473 * Verification of the message's signature. 1475 If any information is missing or if the server's signature cannot 1476 be verified, the client MUST abort the broadcast run. If all 1477 checks are successful, the client MUST remember all the broadcast 1478 parameters received for later checks. 1480 +---------------------+ 1481 | o Assemble response | 1482 | o Create public-key | 1483 | signature | 1484 +----------+----------+ 1485 | 1486 <-+-> 1488 Server ---------------------------------------------> 1489 /| \ 1490 client_ / \ server_ 1491 bpar / \ bpar 1492 / \| 1493 Client ---------------------------------------------> 1495 <------- Broadcast ------> <- Client-side -> 1496 parameter validity 1497 exchange checks 1499 Procedure for unicast time synchronization exchange. 1501 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 1503 For broadcast-type messages, NTS adopts the TESLA protocol with some 1504 customizations. This appendix provides details on the generation and 1505 usage of the one-way key chain collected and assembled from 1506 [RFC4082]. Note that NTS uses the "not re-using keys" scheme of 1507 TESLA as described in Section 3.7.2. of [RFC4082]. 1509 C.1. Server Preparation 1511 Server setup: 1513 1. The server determines a reasonable upper bound B on the network 1514 delay between itself and an arbitrary client, measured in 1515 milliseconds. 1517 2. It determines the number n+1 of keys in the one-way key chain. 1518 This yields the number n of keys that are usable to authenticate 1519 broadcast packets. This number n is therefore also the number of 1520 time intervals during which the server can send authenticated 1521 broadcast messages before it has to calculate a new key chain. 1523 3. It divides time into n uniform intervals I_1, I_2, ..., I_n. 1524 Each of these time intervals has length L, measured in 1525 milliseconds. In order to fulfill the requirement 3.7.2. of RFC 1526 4082, the time interval L has to be shorter than the time 1527 interval between the broadcast messages. 1529 4. The server generates a random key K_n. 1531 5. Using a one-way function F, the server generates a one-way chain 1532 of n+1 keys K_0, K_1, ..., K_{n} according to 1534 K_i = F(K_{i+1}). 1536 6. Using another one-way function F', it generates a sequence of n 1537 MAC keys K'_0, K'_1, ..., K'_{n-1} according to 1539 K'_i = F'(K_i). 1541 7. Each MAC key K'_i is assigned to the time interval I_i. 1543 8. The server determines the key disclosure delay d, which is the 1544 number of intervals between using a key and disclosing it. Note 1545 that although security is provided for all choices d>0, the 1546 choice still makes a difference: 1548 * If d is chosen too short, the client might discard packets 1549 because it fails to verify that the key used for its MAC has 1550 not yet been disclosed. 1552 * If d is chosen too long, the received packets have to be 1553 buffered for an unnecessarily long time before they can be 1554 verified by the client and be subsequently utilized for time 1555 synchronization. 1557 It is RECOMMENDED that the server calculate d according to 1559 d = ceil( 2*B / L) + 1, 1561 where ceil yields the smallest integer greater than or equal to 1562 its argument. 1564 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1565 Generation of Keys 1567 F F F F 1568 K_0 <-------- K_1 <-------- ... <-------- K_{n-1} <------- K_n 1569 | | | | 1570 | | | | 1571 | F' | F' | F' | F' 1572 | | | | 1573 v v v v 1574 K'_0 K'_1 ... K'_{n-1} K'_n 1575 [______________|____ ____|_________________|_______] 1576 I_1 ... I_{n-1} I_n 1578 Course of Time/Usage of Keys 1579 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -> 1581 A schematic explanation of the TESLA protocol's one-way key chain 1583 C.2. Client Preparation 1585 A client needs the following information in order to participate in a 1586 TESLA broadcast: 1588 o One key K_i from the one-way key chain, which has to be 1589 authenticated as belonging to the server. Typically, this will be 1590 K_0. 1592 o The disclosure schedule of the keys. This consists of: 1594 * the length n of the one-way key chain, 1596 * the length L of the time intervals I_1, I_2, ..., I_n, 1598 * the starting time T_i of an interval I_i. Typically this is 1599 the starting time T_1 of the first interval; 1601 * the disclosure delay d. 1603 o The one-way function F used to recursively derive the keys in the 1604 one-way key chain, 1606 o The second one-way function F' used to derive the MAC keys K'_0, 1607 K'_1, ... , K'_n from the keys in the one-way chain. 1609 o An upper bound D_t on how far its own clock is "behind" that of 1610 the server. 1612 Note that if D_t is greater than (d - 1) * L, then some authentic 1613 packets might be discarded. If D_t is greater than d * L, then all 1614 authentic packets will be discarded. In the latter case, the client 1615 SHOULD NOT participate in the broadcast, since there will be no 1616 benefit in doing so. 1618 C.3. Sending Authenticated Broadcast Packets 1620 During each time interval I_i, the server sends at most one 1621 authenticated broadcast packet P_i. Such a packet consists of: 1623 o a message M_i, 1625 o the index i (in case a packet arrives late), 1627 o a MAC authenticating the message M_i, with K'_i used as key, 1629 o the key K_{i-d}, which is included for disclosure. 1631 C.4. Authentication of Received Packets 1633 When a client receives a packet P_i as described above, it first 1634 checks that it has not already received a packet with the same 1635 disclosed key. This is done to avoid replay/flooding attacks. A 1636 packet that fails this test is discarded. 1638 Next, the client begins to check the packet's timeliness by ensuring 1639 that according to the disclosure schedule and with respect to the 1640 upper bound D_t determined above, the server cannot have disclosed 1641 the key K_i yet. Specifically, it needs to check that the server's 1642 clock cannot read a time that is in time interval I_{i+d} or later. 1643 Since it works under the assumption that the server's clock is not 1644 more than D_t "ahead" of the client's clock, the client can calculate 1645 an upper bound t_i for the server's clock at the time when P_i 1646 arrived. This upper bound t_i is calculated according to 1648 t_i = R + D_t, 1650 where R is the client's clock at the arrival of P_i. This implies 1651 that at the time of arrival of P_i, the server could have been in 1652 interval I_x at most, with 1654 x = floor((t_i - T_1) / L) + 1, 1656 where floor gives the greatest integer less than or equal to its 1657 argument. The client now needs to verify that 1659 x < i+d 1661 is valid (see also Section 3.5 of [RFC4082]). If it is falsified, it 1662 is discarded. 1664 If the check above is successful, the client performs another more 1665 rigorous check: it sends a key check request to the server (in the 1666 form of a client_keycheck message), asking explicitly if K_i has 1667 already been disclosed. It remembers the time stamp t_check of the 1668 sending time of that request as well as the nonce it used correlated 1669 with the interval number i. If it receives an answer from the server 1670 stating that K_i has not yet been disclosed and it is able to verify 1671 the HMAC on that response, then it deduces that K_i was undisclosed 1672 at t_check and therefore also at R. In this case, the client accepts 1673 P_i as timely. 1675 Next the client verifies that a newly disclosed key K_{i-d} belongs 1676 to the one-way key chain. To this end, it applies the one-way 1677 function F to K_{i-d} until it can verify the identity with an 1678 earlier disclosed key (see Clause 3.5 in RFC 4082, item 3). 1680 Next the client verifies that the transmitted time value s_i belongs 1681 to the time interval I_i, by checking 1683 T_i =< s_i, and 1685 s_i < T_{i+1}. 1687 If it is falsified, the packet MUST be discarded and the client MUST 1688 reinitialize its broadcast module by performing time synchronization 1689 by other means than broadcast messages, and it MUST perform a new 1690 broadcast parameter exchange (because a falsification of this check 1691 yields that the packet was not generated according to protocol, which 1692 suggests an attack). 1694 If a packet P_i passes all the tests listed above, it is stored for 1695 later authentication. Also, if at this time there is a package with 1696 index i-d already buffered, then the client uses the disclosed key 1697 K_{i-d} to derive K'_{i-d} and uses that to check the MAC included in 1698 package P_{i-d}. Upon success, it regards M_{i-d} as authenticated. 1700 Appendix D. (informative) Dependencies 1702 +---------+--------------+--------+-------------------------------+ 1703 | Issuer | Type | Owner | Description | 1704 +---------+--------------+--------+-------------------------------+ 1705 | Server | private key | server | Used for server_assoc, | 1706 | PKI | (signature) | | server_cook, server_bpar. | 1707 | +--------------+--------+ The server uses the private | 1708 | | public key | client | key to sign these messages. | 1709 | | (signature) | | The client uses the public | 1710 | +--------------+--------+ key to verify them. | 1711 | | certificate | server | The certificate is used in | 1712 | | | | server_assoc messages, for | 1713 | | | | verifying authentication and | 1714 | | | | (optionally) authorization. | 1715 +---------+--------------+--------+-------------------------------+ 1716 | Client | private key | client | The server uses the client's | 1717 | PKI | (encryption) | | public key to encrypt the | 1718 | +--------------+--------+ content of server_cook | 1719 | | public key | server | messages. The client uses | 1720 | | (encryption) | | the private key to decrypt | 1721 | +--------------+--------+ them. The certificate is | 1722 | | certificate | client | sent in client_cook messages, | 1723 | | | | where it is used for trans- | 1724 | | | | portation of the public key | 1725 | | | | as well as (optionally) for | 1726 | | | | verification of client | 1727 | | | | authorization. | 1728 +---------+--------------+--------+-------------------------------+ 1730 This table shows the kind of cryptographic resources that NTS 1731 participants of server and client role should have ready before NTS 1732 communication starts. 1734 ++===========================================++ 1735 || || 1736 || Secure Authentication and Cookie Exchange || 1737 || || 1738 ++=======_ _=================================++ 1739 | 1740 | At least one 1741 | successful 1742 V 1743 ++=======[ ]=======++ 1744 || Unicast Time |>-----\ As long as further 1745 || Synchronization || | synchronization 1746 || Exchange(s) |<-----/ is desired 1747 ++=======_ _=======++ 1748 | 1749 \ Other (unspecified) 1750 Sufficient \ / methods which give 1751 accuracy \ either or / sufficient accuracy 1752 \----------\ /---------/ 1753 | 1754 | 1755 V 1756 ++========[ ]=========++ 1757 || Broadcast || 1758 || Parameter Exchange || 1759 ++========_ _=========++ 1760 | 1761 | One successful 1762 | per client 1763 V 1764 ++=======[ ]=======++ 1765 || Broadcast Time |>--------\ As long as further 1766 || Synchronization || | synchronization 1767 || Reception |<--------/ is desired 1768 ++=======_ _=======++ 1769 | 1770 / \ 1771 either / \ or 1772 /----------/ \-------------\ 1773 | | 1774 V V 1775 ++========[ ]========++ ++========[ ]========++ 1776 || Keycheck Exchange || || Keycheck Exchange || 1777 ++===================++ || with TimeSync || 1778 ++===================++ 1780 This diagram shows the dependencies between the different message 1781 exchanges and procedures which NTS offers. 1783 Authors' Addresses 1785 Dieter Sibold 1786 Physikalisch-Technische Bundesanstalt 1787 Bundesallee 100 1788 Braunschweig D-38116 1789 Germany 1791 Phone: +49-(0)531-592-8420 1792 Fax: +49-531-592-698420 1793 Email: dieter.sibold@ptb.de 1795 Stephen Roettger 1796 Google Inc. 1798 Email: stephen.roettger@googlemail.com 1800 Kristof Teichel 1801 Physikalisch-Technische Bundesanstalt 1802 Bundesallee 100 1803 Braunschweig D-38116 1804 Germany 1806 Phone: +49-(0)531-592-8421 1807 Email: kristof.teichel@ptb.de