idnits 2.17.1 draft-ietf-ntp-using-nts-for-ntp-02.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 05, 2015) is 3125 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 4082 == Outdated reference: A later version (-06) exists of draft-ietf-ntp-cms-for-nts-message-04 == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-09 Summary: 2 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: April 7, 2016 Google Inc 6 K. Teichel 7 PTB 8 October 05, 2015 10 Using the Network Time Security Specification to Secure the Network Time 11 Protocol 12 draft-ietf-ntp-using-nts-for-ntp-02 14 Abstract 16 This document describes how to use the measures described in the 17 Network Time Security (NTS) specification to secure time 18 synchronization with servers using the Network Time Protocol (NTP). 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 7, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 63 4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4 64 4.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 4 65 4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 4 66 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5 69 5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 7 70 5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9 72 5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 9 73 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 10 74 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 10 75 6.1.1. Association Messages . . . . . . . . . . . . . . . . 10 76 6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 11 77 6.1.3. Time Synchronization Messages . . . . . . . . . . . . 11 78 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 79 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 80 6.2.2. Broadcast Time Synchronization Message . . . . . . . 12 81 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 7.1. Employing Alternative Means for Association and Cookie 84 Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 13 86 7.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 13 87 7.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 13 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 9.2. Informative References . . . . . . . . . . . . . . . . . 14 92 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 14 93 Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 One of the most popular time synchronization protocols, the Network 99 Time Protocol (NTP) [RFC5905], currently does not provide adequate 100 intrinsic security precautions. The Network Time Security draft 101 [I-D.ietf-ntp-network-time-security] specifies security measures 102 which can be used to enable time synchronization protocols to verify 103 authenticity of the time server and integrity of the time 104 synchronization protocol packets. 106 This document provides detail on how to specifically use those 107 measures to secure time synchronization between NTP clients and 108 servers. 110 2. Objectives 112 The objectives of the NTS specification are as follows: 114 o Authenticity: NTS enables an NTP client to authenticate its time 115 server(s). 117 o Integrity: NTS protects the integrity of NTP time synchronization 118 protocol packets via a message authentication code (MAC). 120 o Confidentiality: NTS does not provide confidentiality protection 121 of the time synchronization packets. 123 o Authorization: NTS optionally enables the server to verify the 124 client's authorization. 126 o Request-Response-Consistency: NTS enables a client to match an 127 incoming response to a request it has sent. NTS also enables the 128 client to deduce from the response whether its request to the 129 server has arrived without alteration. 131 o Modes of operation: Both the unicast and the broadcast mode of NTP 132 are supported. 134 o Hybrid mode: Both secure and insecure communication modes are 135 possible for both NTP servers and clients. 137 o Compatibility: 139 * Unsecured NTP associations are not affected. 141 * An NTP server that does not support NTS is not affected by NTS- 142 secured authentication requests. 144 3. Terms and Abbreviations 146 CMS Cryptographic Message Syntax [RFC5652] 148 HMAC Keyed-Hash Message Authentication Code 150 MAC Message Authentication Code 152 MITM Man In The Middle 154 NTP Network Time Protocol [RFC5905] 156 NTS Network Time Security 158 TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082] 160 4. Overview of NTS-Secured NTP 162 4.1. Symmetric and Client/Server Mode 164 The server does not keep a state of the client. NTS initially 165 verifies the authenticity of the time server and exchanges a 166 symmetric key, the so-called cookie and a key input value (KIV). The 167 "association" and "cookie" message exchanges described in 168 [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized 169 for the exchange of the cookie and KIV. An implementation MUST 170 support the use of these exchanges. It MAY additionally support the 171 use of any alternative secure communication for this purpose, as long 172 as it fulfills the preconditions given in 173 [I-D.ietf-ntp-network-time-security], Section 6.1.1. 175 After the cookie and KIV are exchanged, the participants then use 176 them to protect the authenticity and the integrity of subsequent 177 unicast-type time synchronization packets. In order to do this, the 178 server attaches a Message Authentication Code (MAC) to each time 179 synchronization packet. The calculation of the MAC includes the 180 whole time synchronization packet and the cookie which is shared 181 between client and server. Therefore, the client can perform a 182 validity check for this MAC on reception of a time synchronization 183 packet. 185 4.2. Broadcast Mode 187 After the client has accomplished the necessary initial time 188 synchronization via client-server mode, the necessary broadcast 189 parameters are communicated from the server to the client. The 190 "broadcast parameter" message exchange described in 191 [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized 192 for this communication. An implementation MUST support the use of 193 this exchange. It MAY additionally support the use of any 194 alternative secure communication for this purpose, as long as it 195 fulfills the necessary security goals (given in 196 [I-D.ietf-ntp-network-time-security], Section 6.2.1.). 198 After the client has received the necessry broadcast parameters, 199 "broadcast time synchronization" message exchanges are utilized in 200 combination with optional "broadcast keycheck" exchanges to protect 201 authenticity and integrity of NTP broadcast time synchronization 202 packets. As in the case of unicast time synchronization messages, 203 this is also achieved by MACs. 205 5. Protocol Sequence 207 Throughout this section, the nonces, cookies and MACs mentioned have 208 bit lengths of B_nonce, B_cookie and B_mac, respectively. These bit 209 lengths are defined in Appendix B (Appendix B). 211 5.1. The Client 213 5.1.1. The Client in Unicast Mode 215 For a unicast run, the client performs the following steps: 217 NOTE: Steps 1 through 4 MAY alternatively be replaced an alternative 218 secure mechanism for association and cookie exchange. An 219 implementation MAY choose to replace either steps 1 and 2 or all 220 of the steps 1 through 4 by alternative secure communication. 222 Step 1: It sends a client_assoc message to the server. It MUST keep 223 the transmitted nonce as well as the values for the version number 224 and algorithms available for later checks. 226 Step 2: It waits for a reply in the form of a server_assoc message. 227 After receipt of the message it performs the following checks: 229 * The client checks that the message contains a conforming 230 version number. 232 * It checks that the nonce sent back by the server matches the 233 one transmitted in client_assoc, 235 * It also verifies that the server has chosen the encryption and 236 hash algorithms from its proposal sent in the client_assoc 237 message and that this proposal was not altered. 239 * Furthermore, it performs authenticity checks on the certificate 240 chain and the signature. 242 If one of the checks fails, the client MUST abort the run. 244 Discussion: Note that by performing the above message exchange 245 and checks, the client validates the authenticity of its 246 immediate NTP server only. It does not recursively validate 247 the authenticity of each NTP server on the time synchronization 248 chain. Recursive authentication (and authorization) as 249 formulated in RFC 7384 [RFC7384] depends on the chosen trust 250 anchor. 252 Step 3: Next it sends a client_cook message to the server. The 253 client MUST save the included nonce until the reply has been 254 processed. 256 Step 4: It awaits a reply in the form of a server_cook message; upon 257 receipt it executes the following actions: 259 * It verifies that the received version number matches the one 260 negotiated beforehand. 262 * It verifies the signature using the server's public key. The 263 signature has to authenticate the encrypted data. 265 * It decrypts the encrypted data with its own private key. 267 * It checks that the decrypted message is of the expected format: 268 the concatenation of a B_nonce bit nonce and a B_cookie bit 269 cookie. 271 * It verifies that the received nonce matches the nonce sent in 272 the client_cook message. 274 If one of those checks fails, the client MUST abort the run. 276 Step 5: The client sends a time_request message to the server. The 277 client MUST save the included nonce and the transmit_timestamp 278 (from the time synchronization data) as a correlated pair for 279 later verification steps. 281 Step 6: It awaits a reply in the form of a time_response message. 282 Upon receipt, it checks: 284 * that the transmitted version number matches the one negotiated 285 previously, 287 * that the transmitted nonce belongs to a previous time_request 288 message, 290 * that the transmit_timestamp in that time_request message 291 matches the corresponding time stamp from the synchronization 292 data received in the time_response, and 294 * that the appended MAC verifies the received synchronization 295 data, version number and nonce. 297 If at least one of the first three checks fails (i.e. if the 298 version number does not match, if the client has never used the 299 nonce transmitted in the time_response message, or if it has used 300 the nonce with initial time synchronization data different from 301 that in the response), then the client MUST ignore this 302 time_response message. If the MAC is invalid, the client MUST do 303 one of the following: abort the run or go back to step 3 (because 304 the cookie might have changed due to a server seed refresh). If 305 both checks are successful, the client SHOULD continue time 306 synchronization by repeating the exchange of time_request and 307 time_response messages. 309 The client's behavior in unicast mode is also expressed in Figure 1. 311 5.1.2. The Client in Broadcast Mode 313 To establish a secure broadcast association with a broadcast server, 314 the client MUST initially authenticate the broadcast server and 315 securely synchronize its time with it up to an upper bound for its 316 time offset in unicast mode. After that, the client performs the 317 following steps: 319 NOTE: Steps 1 and 2 MAY be replaced by an alternative security 320 mechanism for the broadcast parameter exchange. 322 Step 1: It sends a client_bpar message to the server. It MUST 323 remember the transmitted values for the nonce, the version number 324 and the signature algorithm. 326 Step 2: It waits for a reply in the form of a server_bpar message 327 after which it performs the following checks: 329 * The message must contain all the necessary information for the 330 TESLA protocol, as specified for a server_bpar message. 332 * The message must contain a nonce belonging to a client_bpar 333 message that the client has previously sent. 335 * Verification of the message's signature. 337 If any information is missing or if the server's signature cannot 338 be verified, the client MUST abort the broadcast run. If all 339 checks are successful, the client MUST remember all the broadcast 340 parameters received for later checks. 342 Step 3: The client awaits time synchronization data in the form of a 343 server_broadcast message. Upon receipt, it performs the following 344 checks: 346 1. Proof that the MAC is based on a key that is not yet disclosed 347 (packet timeliness). This is achieved via a combination of 348 checks. First, the disclosure schedule is used, which 349 requires loose time synchronization. If this is successful, 350 the client obtains a stronger guarantee via a key check 351 exchange: it sends a client_keycheck message and waits for the 352 appropriate response. Note that it needs to memorize the 353 nonce and the time interval number that it sends as a 354 correlated pair. For more detail on both of the mentioned 355 timeliness checks, see [I-D.ietf-ntp-network-time-security]. 356 If its timeliness is verified, the packet will be buffered for 357 later authentication. Otherwise, the client MUST discard it. 358 Note that the time information included in the packet will not 359 be used for synchronization until its authenticity could also 360 be verified. 362 2. The client checks that it does not already know the disclosed 363 key. Otherwise, the client SHOULD discard the packet to avoid 364 a buffer overrun. If verified, the client ensures that the 365 disclosed key belongs to the one-way key chain by applying the 366 one-way function until equality with a previous disclosed key 367 is shown. If it is falsified, the client MUST discard the 368 packet. 370 3. If the disclosed key is legitimate, then the client verifies 371 the authenticity of any packet that it has received during the 372 corresponding time interval. If authenticity of a packet is 373 verified it is released from the buffer and the packet's time 374 information can be utilized. If the verification fails, then 375 authenticity is no longer given. In this case, the client 376 MUST request authentic time from the server by means of a 377 unicast time request message. Also, the client MUST re- 378 initialize the broadcast sequence with a "client_bpar" message 379 if the one-way key chain expires, which it can check via the 380 disclosure schedule. 382 See RFC 4082 [RFC4082] for a detailed description of the packet 383 verification process. 385 The client MUST restart the broadcast sequence with a client_bpar 386 message ([I-D.ietf-ntp-network-time-security]) if the one-way key 387 chain expires. 389 The client's behavior in broadcast mode can also be seen in Figure 2. 391 5.2. The Server 393 5.2.1. The Server in Unicast Mode 395 To support unicast mode, the server MUST be ready to perform the 396 following actions: 398 o Upon receipt of a client_assoc message, the server constructs and 399 sends a reply in the form of a server_assoc message as described 400 in [I-D.ietf-ntp-network-time-security]. 402 o Upon receipt of a client_cook message, the server checks whether 403 it supports the given cryptographic algorithms. It then 404 calculates the cookie according to the formula given in 405 [I-D.ietf-ntp-network-time-security]. With this, it MUST 406 construct a server_cook message as described in 407 [I-D.ietf-ntp-network-time-security]. 409 o Upon receipt of a time_request message, the server re-calculates 410 the cookie, then computes the necessary time synchronization data 411 and constructs a time_response message as given in 412 [I-D.ietf-ntp-network-time-security]. 414 The server MUST refresh its server seed periodically (see 415 [I-D.ietf-ntp-network-time-security]). 417 In addition to the server MAY be ready to perform the following 418 action: 420 o If an external mechanism for association and key exchange is used, 421 the server has to react accordingly. 423 5.2.2. The Server in Broadcast Mode 425 A broadcast server MUST also support unicast mode in order to provide 426 the initial time synchronization, which is a precondition for any 427 broadcast association. To support NTS broadcast, the server MUST 428 additionally be ready to perform the following actions: 430 o Upon receipt of a client_bpar message, the server constructs and 431 sends a server_bpar message as described in 432 [I-D.ietf-ntp-network-time-security]. 434 o Upon receipt of a client_keycheck message, the server looks up 435 whether it has already disclosed the key associated with the 436 interval number transmitted in that message. If it has not 437 disclosed it, it constructs and sends the appropriate 438 server_keycheck message as described in 439 [I-D.ietf-ntp-network-time-security]. For more details, see also 440 [I-D.ietf-ntp-network-time-security]. 442 o The server follows the TESLA protocol in all other aspects, by 443 regularly sending server_broad messages as described in 444 [I-D.ietf-ntp-network-time-security], adhering to its own 445 disclosure schedule. 447 The server is responsible to watch for the expiration date of the 448 one-way key chain and generate a new key chain accordingly. 450 In addition to the items above, the server MAY be ready to perform 451 the following action: 453 o Upon receipt of external communication for the purpose of 454 broadcast parameter exchange, the server reacts according to the 455 way the external communication is specified. 457 6. Implementation Notes: ASN.1 Structures and Use of the CMS 459 This section presents some hints about the structures of the 460 communication packets for the different message types when one wishes 461 to implement NTS for NTP. See document 462 [I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes 463 for CMS structures as well as for the ASN.1 structures that are 464 referenced here. 466 All extension fields mentioned in the following list are notified by 467 a field type value signalling content related to NTS version 1.0. 469 6.1. Unicast Messages 471 6.1.1. Association Messages 473 6.1.1.1. Message Type: "client_assoc" 475 This message is realized as an NTP packet with an extension field 476 which holds an "NTS-Plain" archetype structure. This structure 477 consists only of an NTS message object of the type "ClientAssocData", 478 which holds all the data necessary for the NTS security mechanisms. 480 6.1.1.2. Message Type: "server_assoc" 482 Like "client_assoc", this message is realized as an NTP packet with 483 an extension field which holds an "NTS-Plain" archetype structure, 484 i.e. just an NTS message object of the type "ServerAssocData". The 485 latter holds all the data necessary for NTS. 487 6.1.2. Cookie Messages 489 6.1.2.1. Message Type: "client_cook" 491 This message type is realized as an NTP packet with an extension 492 field which holds a CMS structure of archetype "NTS-Certified", 493 containing in its core an NTS message object of the type 494 "ClientCookieData". The latter holds all the data necessary for the 495 NTS security mechanisms. 497 6.1.2.2. Message Type: "server_cook" 499 This message type is realized as an NTP packet with an extension 500 field containing a CMS structure of archetype "NTS-Encrypted-and- 501 Signed". The NTS message object in that structure is a 502 "ServerCookieData" object, which holds all data required by NTS for 503 this message type. 505 6.1.3. Time Synchronization Messages 507 6.1.3.1. Message Type: "time_request" 509 This message type is realized as an NTP packet which actually 510 contains regular NTP time synchronization data, as an unsecured NTP 511 packet from a client to a server would. Furthermore, the packet has 512 an extension field which contains an ASN.1 object of type 513 "TimeRequestSecurityData" (packed in a CMS structure of archetype 514 "NTS-Plain"). 516 6.1.3.2. Message Type: "time_response" 518 This message is also realized as an NTP packet with regular NTP time 519 synchronization data. The packet also has an extension field which 520 contains an ASN.1 object of type "TimeResponseSecurityData". 521 Finally, this NTP packet has another extension field which contains a 522 Message Authentication Code generated over the whole packet 523 (including the extension field). 525 6.2. Broadcast Messages 527 6.2.1. Broadcast Parameter Messages 529 6.2.1.1. Message Type: "client_bpar" 531 This first broadcast message is realized as an NTP packet which is 532 empty except for an extension field which contains an ASN.1 object of 533 type "BroadcastParameterRequest" (packed in a CMS structure of 534 archetype "CMS-Plain"). This is sufficient to transport all data 535 specified by NTS. 537 6.2.1.2. Message Type: "server_bpar" 539 This message type is realized as an NTP packet whose extension field 540 carries the necessary CMS structure (archetype: "NTS-Signed"). The 541 NTS message object in this case is an ASN.1 object of type 542 "BroadcastParameterResponse". 544 6.2.2. Broadcast Time Synchronization Message 546 6.2.2.1. Message Type: "server_broad" 548 This message's realization works via an NTP packet which carries 549 regular NTP broadcast time data as well as an extension field, which 550 contains an ASN.1 object of type "BroadcastTime" (packed in a CMS 551 structure with archetype "NTS-Plain"). In addition to all this, this 552 packet has another extension field which contains a Message 553 Authentication Code generated over the whole packet (including the 554 extension field). 556 6.2.3. Broadcast Keycheck 558 6.2.3.1. Message Type: "client_keycheck" 560 This message is realized as an NTP packet with an extension field, 561 which transports a CMS structure of archetype "NTS-Plain", containing 562 an ASN.1 object of type "ClientKeyCheckSecurityData". 564 6.2.3.2. Message Type: "server_keycheck" 566 This message is also realized as an NTP packet with an extension 567 field, which contains an ASN.1 object of type 568 "ServerKeyCheckSecurityData" (packed in a CMS structure of archetype 569 "NTS-Plain"). Additionally, this NTP packet has another extension 570 field which contains a Message Authentication Code generated over the 571 whole packet (including the extension field). 573 7. Security Considerations 575 7.1. Employing Alternative Means for Association and Cookie Exchange 577 If an implementation uses alternative means to perform association 578 and cookie exchange, it MUST make sure that an adversary cannot abuse 579 the server to obtain a cookie belonging to a chosen KIV. 581 7.2. Usage of NTP Pools 583 The certification-based authentication scheme described in 584 [I-D.ietf-ntp-network-time-security] is not applicable to the concept 585 of NTP pools. Therefore, NTS is unable to provide secure usage of 586 NTP pools. 588 7.3. Server Seed Lifetime 590 tbd 592 7.4. Supported Hash Algorithms 594 The list of the hash algorithms supported by the server has to 595 fulfill the following requirements: 597 o it MUST NOT include SHA-1 or weaker algorithms, 599 o it MUST include SHA-256 or stronger algorithms. 601 8. Acknowledgements 603 The authors would like to thank Russ Housley, Steven Bellovin, David 604 Mills and Kurt Roeckx for discussions and comments on the design of 605 NTS. Also, thanks to Harlan Stenn for his technical review and 606 specific text contributions to this document. 608 9. References 610 9.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 614 RFC2119, March 1997, 615 . 617 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 618 Briscoe, "Timed Efficient Stream Loss-Tolerant 619 Authentication (TESLA): Multicast Source Authentication 620 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 621 June 2005, . 623 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 624 RFC 5652, DOI 10.17487/RFC5652, September 2009, 625 . 627 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 628 "Network Time Protocol Version 4: Protocol and Algorithms 629 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 630 . 632 9.2. Informative References 634 [I-D.ietf-ntp-cms-for-nts-message] 635 Sibold, D., Teichel, K., Roettger, S., and R. Housley, 636 "Protecting Network Time Security Messages with the 637 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 638 for-nts-message-04 (work in progress), July 2015. 640 [I-D.ietf-ntp-network-time-security] 641 Sibold, D., Roettger, S., and K. Teichel, "Network Time 642 Security", draft-ietf-ntp-network-time-security-09 (work 643 in progress), July 2015. 645 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 646 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 647 October 2014, . 649 Appendix A. Flow Diagrams of Client Behaviour 650 +---------------------+ 651 |Association Messages | 652 +----------+----------+ 653 | 654 +------------------------------>o 655 | | 656 | v 657 | +---------------+ 658 | |Cookie Messages| 659 | +-------+-------+ 660 | | 661 | o<------------------------------+ 662 | | | 663 | v | 664 | +-------------------+ | 665 | |Time Sync. Messages| | 666 | +---------+---------+ | 667 | | | 668 | v | 669 | +-----+ | 670 | |Check| | 671 | +--+--+ | 672 | | | 673 | /------------------+------------------\ | 674 | v v v | 675 | .-----------. .-------------. .-------. | 676 | ( MAC Failure ) ( Nonce Failure ) ( Success ) | 677 | '-----+-----' '------+------' '---+---' | 678 | | | | | 679 | v v v | 680 | +-------------+ +-------------+ +--------------+ | 681 | |Discard Data | |Discard Data | |Sync. Process | | 682 | +-------------+ +------+------+ +------+-------+ | 683 | | | | | 684 | | | v | 685 +-----------+ +------------------>o-----------+ 687 Figure 1: The client's behavior in NTS unicast mode. 689 +-----------------------------+ 690 |Broadcast Parameter Messages | 691 +--------------+--------------+ 692 | 693 o<--------------------------+ 694 | | 695 v | 696 +-----------------------------+ | 697 |Broadcast Time Sync. Message | | 698 +--------------+--------------+ | 699 | | 700 +-------------------------------------->o | 701 | | | 702 | v | 703 | +-------------------+ | 704 | |Key and Auth. Check| | 705 | +---------+---------+ | 706 | | | 707 | /----------------*----------------\ | 708 | v v | 709 | .---------. .---------. | 710 | ( Verified ) ( Falsified ) | 711 | '----+----' '----+----' | 712 | | | | 713 | v v | 714 | +-------------+ +-------+ | 715 | |Store Message| |Discard| | 716 | +------+------+ +---+---+ | 717 | | | | 718 | v +---------o 719 | +---------------+ | 720 | |Check Previous | | 721 | +-------+-------+ | 722 | | | 723 | /--------*--------\ | 724 | v v | 725 | .---------. .---------. | 726 | ( Verified ) ( Falsified ) | 727 | '----+----' '----+----' | 728 | | | | 729 | v v | 730 | +-------------+ +-----------------+ | 731 | |Sync. Process| |Discard Previous | | 732 | +------+------+ +--------+--------+ | 733 | | | | 734 +-----------+ +-----------------------------------+ 736 Figure 2: The client's behaviour in NTS broadcast mode. 738 Appendix B. Bit Lengths for Employed Primitives 740 Define the following bit lengths for nonces, cookies and MACs: 742 B_nonce = 128, 744 B_cookie = 128, and 746 B_mac = 128. 748 Authors' Addresses 750 Dieter Sibold 751 Physikalisch-Technische Bundesanstalt 752 Bundesallee 100 753 Braunschweig D-38116 754 Germany 756 Phone: +49-(0)531-592-8420 757 Fax: +49-531-592-698420 758 Email: dieter.sibold@ptb.de 760 Stephen Roettger 761 Google Inc 763 Email: stephen.roettger@googlemail.com 765 Kristof Teichel 766 Physikalisch-Technische Bundesanstalt 767 Bundesallee 100 768 Braunschweig D-38116 769 Germany 771 Phone: +49-(0)531-592-8421 772 Email: kristof.teichel@ptb.de