idnits 2.17.1 draft-ietf-ntp-using-nts-for-ntp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 2766 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) == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-13 ** Downref: Normative reference to an Informational RFC: RFC 4082 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group D. Sibold 3 Internet-Draft PTB 4 Intended status: Standards Track S. Roettger 5 Expires: March 26, 2017 Google Inc 6 K. Teichel 7 PTB 8 September 22, 2016 10 Using the Network Time Security Specification to Secure the Network Time 11 Protocol 12 draft-ietf-ntp-using-nts-for-ntp-06 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 March 26, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 10 73 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 11 74 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 13 75 6.1.1. Access Messages . . . . . . . . . . . . . . . . . . . 13 76 6.1.2. Association Messages . . . . . . . . . . . . . . . . 14 77 6.1.3. Cookie Messages . . . . . . . . . . . . . . . . . . . 14 78 6.1.4. Time Synchronization Messages . . . . . . . . . . . . 14 79 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 15 80 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 15 81 6.2.2. Broadcast Time Synchronization Message . . . . . . . 15 82 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 16 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 7.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 16 85 7.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 8.1. Employing Alternative Means for Access, Association and 88 Cookie Exchange . . . . . . . . . . . . . . . . . . . . . 17 89 8.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 17 90 8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 17 91 8.4. Supported MAC Algorithms . . . . . . . . . . . . . . . . 17 92 8.5. Protection for Initial Messages . . . . . . . . . . . . . 18 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 96 10.2. Informative References . . . . . . . . . . . . . . . . . 19 97 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 19 98 Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 22 99 Appendix C. Error Codes . . . . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 One of the most popular time synchronization protocols, the Network 105 Time Protocol (NTP) [RFC5905], currently does not provide adequate 106 intrinsic security precautions. The Network Time Security draft 107 [I-D.ietf-ntp-network-time-security] specifies security measures 108 which can be used to enable time synchronization protocols to verify 109 authenticity of the time server and integrity of the time 110 synchronization protocol packets. 112 This document provides detail on how to specifically use those 113 measures to secure time synchronization between NTP clients and 114 servers. 116 2. Objectives 118 The objectives of the Network Time Security (NTS) specification are 119 as follows: 121 o Authenticity: NTS enables an NTP client to authenticate its time 122 server(s). 124 o Integrity: NTS protects the integrity of NTP time synchronization 125 protocol packets via a message authentication code (MAC). 127 o Confidentiality: NTS does not provide confidentiality protection 128 of the time synchronization packets. 130 o Authorization: NTS optionally enables the server to verify the 131 client's authorization. 133 o Request-Response-Consistency: NTS enables a client to match an 134 incoming response to a request it has sent. NTS also enables the 135 client to deduce from the response whether its request to the 136 server has arrived without alteration. 138 o Modes of operation: Both the unicast and the broadcast mode of NTP 139 are supported. 141 o Hybrid mode: Both secure and insecure communication modes are 142 possible for both NTP servers and clients. 144 o Compatibility: 146 * NTP associations which are not secured by NTS are not affected 147 by NTS-secured communication. 149 * An NTP server that does not support NTS is not affected by NTS- 150 secured authentication requests. 152 3. Terms and Abbreviations 154 CMS Cryptographic Message Syntax [RFC5652] 156 MAC Message Authentication Code 158 MITM Man In The Middle 160 NTP Network Time Protocol [RFC5905] 162 NTS Network Time Security 164 TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082] 166 4. Overview of NTS-Secured NTP 168 4.1. Symmetric and Client/Server Mode 170 The server does not keep a state of the client. NTS initially 171 verifies the authenticity of the time server and exchanges a 172 symmetric key, the so-called cookie and a key input value (KIV). The 173 "access", "association", and "cookie" message exchanges described in 174 [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized 175 for the exchange of the cookie and KIV. An implementation MUST 176 support the use of these exchanges. It MAY additionally support the 177 use of any alternative secure communication for this purpose, as long 178 as it fulfills the preconditions given in 179 [I-D.ietf-ntp-network-time-security], Section 6.1.1. 181 After the cookie and KIV are exchanged, the participants then use 182 them to protect the authenticity and the integrity of subsequent 183 unicast-type time synchronization packets. In order to do this, the 184 server attaches a Message Authentication Code (MAC) to each time 185 synchronization packet. The calculation of the MAC includes the 186 whole time synchronization packet and the cookie which is shared 187 between client and server. Therefore, the client can perform a 188 validity check for this MAC on reception of a time synchronization 189 packet. 191 4.2. Broadcast Mode 193 After the client has accomplished the necessary initial time 194 synchronization via client-server mode, the necessary broadcast 195 parameters are communicated from the server to the client. The 196 "broadcast parameter" message exchange described in 197 [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized 198 for this communication. An implementation MUST support the use of 199 this exchange. It MAY additionally support the use of any 200 alternative secure communication for this purpose, as long as it 201 fulfills the necessary security goals (given in 202 [I-D.ietf-ntp-network-time-security], Section 6.2.1.). 204 After the client has received the necessary broadcast parameters, 205 "broadcast time synchronization" message exchanges are utilized in 206 combination with optional "broadcast keycheck" exchanges to protect 207 authenticity and integrity of NTP broadcast time synchronization 208 packets. As in the case of unicast time synchronization messages, 209 this is also achieved by MACs. 211 5. Protocol Sequence 213 Throughout this section, the access key, server seed, the nonces, 214 cookies and MACs mentioned have bit lengths of B_accesskey, B_seed, 215 B_nonce, B_cookie and B_mac, respectively. These bit lengths are 216 defined in Appendix B (Appendix B). If a message requires a MAC to 217 cover its contents, this MAC MUST be calculated according to: 219 mac = MSB_ (HMAC(key, content)), 221 where the application of the function MSB_ returns only the 222 B_mac most significant bits, where content is composed of the NTP 223 header and all extension fields prior to the MAC-carrying extension 224 field (see Section 6), and where key is the cookie for the given 225 association. 227 Note for clarification that different message exchanges use different 228 nonces. A nonce is always generated by the client for a request 229 message, and then used by the server in its response. After this, it 230 is not to be used again. 232 5.1. The Client 234 5.1.1. The Client in Unicast Mode 236 For a unicast run, the client performs the following steps: 238 NOTE: Steps 1 through 6 MAY alternatively be replaced by an 239 alternative secure mechanism for access, association and cookie 240 exchange. 242 Step 1: It sends a client_access message to the server. 244 Step 2: It waits for a reply in the form of a server_access message. 246 Step 3: It sends a client_assoc message to the server. It MUST 247 include the access key from the previously received server_access 248 message. It MUST keep the transmitted nonce as well as the values 249 for the version number and algorithms available for later checks. 251 Step 4: It waits for a reply in the form of a server_assoc message. 252 After receipt of the message it performs the following checks: 254 * The client checks that the message contains a conforming 255 version number. 257 * It checks that the nonce sent back by the server matches the 258 one transmitted in client_assoc, 260 * It also verifies that the server has chosen the encryption and 261 MAC algorithms from its proposal sent in the client_assoc 262 message and that this proposal was not altered. 264 * Furthermore, it performs authenticity checks on the certificate 265 chain and the signature. 267 If one of the checks fails, the client MUST abort the run. 269 Discussion: Note that by performing the above message exchange 270 and checks, the client validates the authenticity of its 271 immediate NTP server only. It does not recursively validate 272 the authenticity of each NTP server on the time synchronization 273 chain. Recursive authentication (and authorization) as 274 formulated in RFC 7384 [RFC7384] depends on the chosen trust 275 anchor. 277 Step 5: Next it sends a client_cook message to the server. The 278 client MUST save the included nonce until the reply has been 279 processed. 281 Step 6: It awaits a reply in the form of a server_cook message; upon 282 receipt it executes the following actions: 284 * It verifies that the received version number matches the one 285 negotiated beforehand. 287 * It verifies the signature using the server's public key. The 288 signature has to authenticate the encrypted data. 290 * It decrypts the encrypted data with its own private key. 292 * It checks that the decrypted message is of the expected format: 293 the concatenation of a B_nonce bit nonce and a B_cookie bit 294 cookie. 296 * It verifies that the received nonce matches the nonce sent in 297 the client_cook message. 299 If one of those checks fails, the client MUST abort the run. 301 Step 7: The client sends a time_request message to the server. The 302 client MUST append a MAC to the time_request message. The client 303 MUST save the included nonce and the transmit_timestamp (from the 304 time synchronization data) as a correlated pair for later 305 verification steps. 307 Step 8: It awaits a reply in the form of a time_response message. 308 Upon receipt, it checks: 310 * that the transmitted version number matches the one negotiated 311 previously, 313 * that the transmitted nonce belongs to a previous time_request 314 message, 316 * that the transmit_timestamp in that time_request message 317 matches the corresponding time stamp from the synchronization 318 data received in the time_response, and 320 * that the appended MAC verifies the received synchronization 321 data, version number and nonce. 323 If at least one of the first three checks fails (i.e. if the 324 version number does not match, if the client has never used the 325 nonce transmitted in the time_response message, or if it has used 326 the nonce with initial time synchronization data different from 327 that in the response), then the client MUST ignore this 328 time_response message. If the MAC is invalid, the client MUST do 329 one of the following: abort the run or go back to step 5 (because 330 the cookie might have changed due to a server seed refresh). If 331 both checks are successful, the client SHOULD continue time 332 synchronization by repeating the exchange of time_request and 333 time_response messages. 335 The client's behavior in unicast mode is also expressed in Figure 1. 337 5.1.2. The Client in Broadcast Mode 339 To establish a secure broadcast association with a broadcast server, 340 the client MUST initially authenticate the broadcast server and 341 securely synchronize its time with it up to an upper bound for its 342 time offset in unicast mode. After that, the client performs the 343 following steps: 345 NOTE: Steps 1 and 2 MAY be replaced by an alternative security 346 mechanism for the broadcast parameter exchange. 348 Step 1: It sends a client_bpar message to the server. It MUST 349 remember the transmitted values for the nonce, the version number 350 and the signature algorithm. 352 Step 2: It waits for a reply in the form of a server_bpar message 353 after which it performs the following checks: 355 * The message must contain all the necessary information for the 356 TESLA protocol, as specified for a server_bpar message. 358 * The message must contain a nonce belonging to a client_bpar 359 message that the client has previously sent. 361 * Verification of the message's signature. 363 If any information is missing or if the server's signature cannot 364 be verified, the client MUST abort the broadcast run. If all 365 checks are successful, the client MUST remember all the broadcast 366 parameters received for later checks. 368 Step 3: The client awaits time synchronization data in the form of a 369 server_broadcast message. Upon receipt, it performs the following 370 checks: 372 1. Proof that the MAC is based on a key that is not yet disclosed 373 (packet timeliness). This is achieved via a combination of 374 checks. First, the disclosure schedule is used, which 375 requires loose time synchronization. If this is successful, 376 the client obtains a stronger guarantee via a key check 377 exchange: it sends a client_keycheck message and waits for the 378 appropriate response. Note that it needs to memorize the 379 nonce and the time interval number that it sends as a 380 correlated pair. For more detail on both of the mentioned 381 timeliness checks, see [I-D.ietf-ntp-network-time-security]. 382 If its timeliness is verified, the packet will be buffered for 383 later authentication. Otherwise, the client MUST discard it. 384 Note that the time information included in the packet will not 385 be used for synchronization until its authenticity could also 386 be verified. 388 2. The client checks that it does not already know the disclosed 389 key. Otherwise, the client SHOULD discard the packet to avoid 390 a buffer overrun. If verified, the client ensures that the 391 disclosed key belongs to the one-way key chain by applying the 392 one-way function until equality with a previous disclosed key 393 is shown. If it is falsified, the client MUST discard the 394 packet. 396 3. If the disclosed key is legitimate, then the client verifies 397 the authenticity of any packet that it has received during the 398 corresponding time interval. If authenticity of a packet is 399 verified it is released from the buffer and the packet's time 400 information can be utilized. If the verification fails, then 401 authenticity is no longer given. In this case, the client 402 MUST request authentic time from the server by means of a 403 unicast time request message. Also, the client MUST re- 404 initialize the broadcast sequence with a "client_bpar" message 405 if the one-way key chain expires, which it can check via the 406 disclosure schedule. 408 See RFC 4082 [RFC4082] for a detailed description of the packet 409 verification process. 411 The client MUST restart the broadcast sequence with a client_bpar 412 message ([I-D.ietf-ntp-network-time-security]) if the one-way key 413 chain expires. 415 The client's behavior in broadcast mode can also be seen in Figure 2. 417 5.2. The Server 419 5.2.1. The Server in Unicast Mode 421 To support unicast mode, the server MUST be ready to perform the 422 following actions: 424 o Upon receipt of a client_access message, the server constructs and 425 sends a reply in the form of a server_access message as described 426 in Appendix B of[I-D.ietf-ntp-network-time-security]. The server 427 MUST construct the access key according to: 429 access_key = MSB _ (MAC(server seed; Client's IP 430 address)). 432 o Upon receipt of a client_assoc message, the server checks the 433 included access key. To this end it reconstructs the access key 434 and compares it against the received one. If they match, the 435 server constructs and sends a reply in the form of a server_assoc 436 message as described in [I-D.ietf-ntp-network-time-security]. In 437 the case where the validity of the included access key can not be 438 verified, the server MUST NOT reply to the received request. 440 o Upon receipt of a client_cook message, the server checks whether 441 it supports the given cryptographic algorithms. It then 442 calculates the cookie according to the formula given in 443 [I-D.ietf-ntp-network-time-security]. With this, it MUST 444 construct a server_cook message as described in 445 [I-D.ietf-ntp-network-time-security]. 447 o Upon receipt of a time_request message, the server re-calculates 448 the cookie and the MAC for that time_request packet and compares 449 this value with the MAC in the received data. 451 * If the re-calculated MAC does not match the MAC in the received 452 data the server MUST stop the processing of the request. 454 * If the re-calculated MAC matches the MAC in the received data 455 the server computes the necessary time synchronization data and 456 constructs a time_response message as given in 457 [I-D.ietf-ntp-network-time-security]. 459 If the time_request message was received in the context of an NTP 460 peer association, the server MUST look up whether it has information 461 about the authentication and authorization status for the given hash 462 value of the client's certificate. If it does not, it MUST NOT use 463 the NTP message contents for adjusting its own clock. 465 In addition to items above, the server MAY be ready to perform the 466 following action: 468 o If an external mechanism for association and key exchange is used, 469 the server has to react accordingly. 471 5.2.2. The Server in Broadcast Mode 473 A broadcast server MUST also support unicast mode in order to provide 474 the initial time synchronization, which is a precondition for any 475 broadcast association. To support NTS broadcast, the server MUST 476 additionally be ready to perform the following actions: 478 o Upon receipt of a client_bpar message, the server constructs and 479 sends a server_bpar message as described in 480 [I-D.ietf-ntp-network-time-security]. 482 o Upon receipt of a client_keycheck message, the server re- 483 calculates the cookie and the MAC for that client_keycheck packet 484 and compares this value with the MAC in the received data. 486 * If the re-calculated MAC does not match the MAC in the received 487 data the server MUST stop the processing of the request. 489 * If the re-calculated MAC matches the MAC in the received data 490 the server looks up whether it has already disclosed the key 491 associated with the interval number transmitted in that 492 message. If it has not disclosed it, it constructs and sends 493 the appropriate server_keycheck message as described in 494 [I-D.ietf-ntp-network-time-security]. 496 o The server follows the TESLA protocol in all other aspects, by 497 regularly sending server_broad messages as described in 498 [I-D.ietf-ntp-network-time-security], adhering to its own 499 disclosure schedule. 501 The server is responsible to watch for the expiration date of the 502 one-way key chain and generate a new key chain accordingly. 504 In addition to the items above, the server MAY be ready to perform 505 the following action: 507 o Upon receipt of external communication for the purpose of 508 broadcast parameter exchange, the server reacts according to the 509 way the external communication is specified. 511 6. Implementation Notes: ASN.1 Structures and Use of the CMS 513 This section presents some hints about the structures of the 514 communication packets for the different message types when one wishes 515 to implement NTS for NTP. See document 516 [I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes 517 for CMS structures as well as for the ASN.1 structures that are 518 referenced here. 520 The NTP extension field structure is defined in RFC 5905 [RFC5905] 521 and clarified in [I-D.ietf-ntp-extension-field]. It looks as 522 follows: 524 0 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Field Type | Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 . . 530 . Value . 531 . . 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Padding (as needed) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 All extension fields mentioned in the rest of this section do not 537 require an NTP MAC field. If nothing else is explicitly stated, all 538 of those extension fields MUST have a length of at least 28 octets. 540 Furthermore, all extension fields mentioned in the rest of this 541 section are notified by one of three Field Type identifiers, 542 signaling content related to NTS: 544 +------------+------------------------------------------------------+ 545 | Field Type | ASN.1 Object of NTS Message | 546 +------------+------------------------------------------------------+ 547 | TBD1 | ClientAccessData, ServerAccessData | 548 | TBD1 | ClientAssocData, ServerAssocData | 549 | TBD1 | ClientCookieData, ServerCookieData | 550 | TBD1 | BroadcastParameterRequest, | 551 | | BroadcastParameterResponse | 552 | TBD2 | TimeRequestSecurityData, TimeResponseSecurityData | 553 | TBD2 | BroadcastTime | 554 | TBD2 | ClientKeyCheckSecurityData, | 555 | | ServerKeyCheckSecurityData | 556 | TBD3 | NTSMessageAuthenticationCode | 557 +------------+------------------------------------------------------+ 559 (see IANA considerations (Section 7)). 561 The outermost structure of the extension field's Value field MUST be 562 an ASN.1 object that is structured as follows: 564 NTSExtensionFieldContent := SEQUENCE { 565 oid OBJECT IDENTIFIER, 566 errnum OCTET STRING (SIZE(2)), 567 content ANY DEFINED BY oid 568 } 570 The field errnum represents the error code of any message. The 571 client and server MAY ignore this field in any incoming message. The 572 server MUST set this to zero if the response to the request was 573 generated successfully. If it could not successfully generate a 574 response, the field errnum MUST be set to a non-zero value. The 575 different values of this field is defined in the Appendix C. 577 Whenever NTS requires a MAC for protection of a message, this MAC 578 MUST be included in an additional extension field. This MAC-carrying 579 extension field MUST be placed after the other NTS-related extension 580 field, and it SHOULD be the last extension field of the message. Any 581 MAC supplied by NTS in a MAC-carrying extension field MUST be 582 generated over the NTP header and all extension fields prior to the 583 MAC-carrying extension field. 585 Content MAY be added to an NTS-protected NTP message after the MAC 586 provided by NTS. However, it is RECOMMENDED to not make use of this 587 option and to apply the MAC protection of NTS to the whole of an NTP 588 message. 590 The MAC-carrying extension field contains an NTSExtensionFieldContent 591 object, whose content field is structured according to NTS-Plain. 592 The included NTS message object is as follows: 594 NTSMessageAuthenticationCode := SEQUENCE { 595 mac OCTET STRING (SIZE(16)) 596 } 598 It is identified by the following object identifier: 600 id-ct-nts-ntsForNtpMessageAuthenticationCode OBJECT IDENTIFIER ::= TBD4 602 Note: In the following sections the word MAC is always used as 603 described above. In particular it is not to be confused with 604 NTP's MAC field. 606 6.1. Unicast Messages 608 6.1.1. Access Messages 610 6.1.1.1. Message Type: "client_access" 612 This message is realized as an NTP packet with an extension field 613 which holds an "NTS-Plain" archetype structure. This structure 614 consists only of an NTS message object of the type 615 "ClientAccessData". 617 6.1.1.2. Message Type: "server_access" 619 Like "client_access", this message is realized as an NTP packet with 620 an extension field which holds an "NTS-Plain" archetype structure, 621 i.e. just an NTS message object of the type "ServerAccessData". The 622 latter holds all the data necessary for NTS. 624 6.1.2. Association Messages 626 6.1.2.1. Message Type: "client_assoc" 628 This message is realized as an NTP packet with an extension field 629 which holds an "NTS-Plain" archetype structure. This structure 630 consists only of an NTS message object of the type "ClientAssocData", 631 which holds all the data necessary for the NTS security mechanisms. 633 6.1.2.2. Message Type: "server_assoc" 635 Like "client_assoc", this message is realized as an NTP packet with 636 an extension field which holds an "NTS-Plain" archetype structure, 637 i.e. just an NTS message object of the type "ServerAssocData". The 638 latter holds all the data necessary for NTS. 640 6.1.3. Cookie Messages 642 6.1.3.1. Message Type: "client_cook" 644 This message type is realized as an NTP packet with an extension 645 field which holds a CMS structure of archetype "NTS-Plain", 646 containing in its core an NTS message object of the type 647 "ClientCookieData". The latter holds all the data necessary for the 648 NTS security mechanisms. 650 6.1.3.2. Message Type: "server_cook" 652 This message type is realized as an NTP packet with an extension 653 field containing a CMS structure of archetype "NTS-Encrypted-and- 654 Signed". The NTS message object in that structure is a 655 "ServerCookieData" object, which holds all data required by NTS for 656 this message type. 658 6.1.4. Time Synchronization Messages 660 6.1.4.1. Message Type: "time_request" 662 This message type is realized as an NTP packet with regular NTP time 663 synchronization data. Furthermore, the packet has an extension field 664 which contains an ASN.1 object of type "TimeRequestSecurityData" 665 (packed in a CMS structure of archetype "NTS-Plain"). Finally, this 666 message MUST be protected by a MAC. 668 6.1.4.2. Message Type: "time_response" 670 This message is also realized as an NTP packet with regular NTP time 671 synchronization data. The packet also has an extension field which 672 contains an ASN.1 object of type "TimeResponseSecurityData". 673 Finally, this message MUST be protected by a MAC. 675 Note: In these two messages, where two extension fields are present, 676 the respective first extension field (the one not containing the 677 MAC) only needs to have a length of at least 16 octets. The 678 extension fields holding the MACs need to have the usual length of 679 at least 28 octets. 681 6.2. Broadcast Messages 683 6.2.1. Broadcast Parameter Messages 685 6.2.1.1. Message Type: "client_bpar" 687 This first broadcast message is realized as an NTP packet which is 688 empty except for an extension field which contains an ASN.1 object of 689 type "BroadcastParameterRequest" (packed in a CMS structure of 690 archetype "NTS-Plain"). This is sufficient to transport all data 691 specified by NTS. 693 6.2.1.2. Message Type: "server_bpar" 695 This message type is realized as an NTP packet whose extension field 696 carries the necessary CMS structure (archetype: "NTS-Signed"). The 697 NTS message object in this case is an ASN.1 object of type 698 "BroadcastParameterResponse". 700 6.2.2. Broadcast Time Synchronization Message 702 6.2.2.1. Message Type: "server_broad" 704 This message's realization works via an NTP packet which carries 705 regular NTP broadcast time data as well as an extension field, which 706 contains an ASN.1 object of type "BroadcastTime" (packed in a CMS 707 structure with archetype "NTS-Plain"). Finally, this message MUST be 708 protected by a MAC. 710 Note: In this message, the first extension field (the one not 711 containing the MAC) only needs to have a length of at least 16 712 octets. The extension field holding the MACs needs to have the 713 usual length of at least 28 octets. 715 6.2.3. Broadcast Keycheck 717 6.2.3.1. Message Type: "client_keycheck" 719 This message is realized as an NTP packet with an extension field, 720 which transports a CMS structure of archetype "NTS-Plain", containing 721 an ASN.1 object of type "ClientKeyCheckSecurityData". Finally, this 722 message MUST be protected by a MAC. 724 6.2.3.2. Message Type: "server_keycheck" 726 This message is also realized as an NTP packet with an extension 727 field, which contains an ASN.1 object of type 728 "ServerKeyCheckSecurityData" (packed in a CMS structure of archetype 729 "NTS-Plain"). Finally, this message MUST be protected by a MAC. 731 Note: In this message, the first extension field (the one not 732 containing the MAC) only needs to have a length of at least 16 733 octets. The extension field holding the MACs needs to have the 734 usual length of at least 28 octets. 736 7. IANA Considerations 738 7.1. Field Type Registry 740 Within the "NTP Extensions Field Types" registry table, add the field 741 types: 743 Field Type Meaning References 744 ---------- ------------------------------------ ---------- 745 TBD1 NTS-Related Content [this doc] 746 TBD2 NTS-Related Content [this doc] 747 TBD3 NTS-Related Content [this doc] 749 7.2. SMI Security for S/MIME CMS Content Type Registry 751 Within the "SMI Security for S/MIME CMS Content Type 752 (1.2.840.113549.1.9.16.1)" table, add one content type identifier: 754 Decimal Description References 755 ------- -------------------------------------------- ---------- 756 TBD4 id-ct-nts-ntsForNtpMessageAuthenticationCode [this doc] 758 8. Security Considerations 760 All security considerations described in 761 [I-D.ietf-ntp-network-time-security] have to be taken into account. 762 The application of NTS to NTP requires the following additional 763 considerations. 765 8.1. Employing Alternative Means for Access, Association and Cookie 766 Exchange 768 If an implementation uses alternative means to perform access, 769 association and cookie exchange, it MUST make sure that an adversary 770 cannot abuse the server to obtain a cookie belonging to a chosen KIV. 772 8.2. Usage of NTP Pools 774 The certification-based authentication scheme described in 775 [I-D.ietf-ntp-network-time-security] is not applicable to the concept 776 of NTP pools. Therefore, NTS is unable to provide secure usage of 777 NTP pools. 779 8.3. Server Seed Lifetime 781 According to Clause 5.6.1 in RFC 7384 [RFC7384] the server MUST 782 provide a means to refresh the value of its server seed from time to 783 time. A generally valid value for the server seed lifetime cannot be 784 given. The value depends on the required security level, the current 785 threat situation, and the chosen MAC mechanisms. 787 As guidance, a value for the lifetime can be determined by 788 stipulating a maximum number of time requests for which the exchanged 789 cookie remains unchanged. For example, if this value is 1000 and the 790 client sends a time request every 64 seconds, the server seed 791 lifetime should be no longer than 64000 seconds. Corresponding 792 considerations can be made for a minimum number of requests. 794 8.4. Supported MAC Algorithms 796 The list of the MAC algorithms supported by the server has to fulfill 797 the following requirements: 799 o it MUST NOT include HMAC with SHA-1 or weaker algorithms, 801 o it MUST include HMAC with SHA-256 or stronger algorithms. 803 8.5. Protection for Initial Messages 805 Any NTS message providing access, association, or cookie exchange can 806 be encapsulated in NTP an extension field which is piggybacked onto 807 an NTP packet. NTS does not itself provide MAC protection to the NTP 808 header of such a packet, because it only offers MAC protection to the 809 NTP header once the cookie has been successfully exchanged. 811 9. Acknowledgements 813 The authors would like to thank Russ Housley, Steven Bellovin, David 814 Mills and Kurt Roeckx for discussions and comments on the design of 815 NTS. Also, thanks to Harlan Stenn, Danny Mayer, Richard Welty and 816 Martin Langer for their technical review and specific text 817 contributions to this document. 819 10. References 821 10.1. Normative References 823 [I-D.ietf-ntp-cms-for-nts-message] 824 Sibold, D., Teichel, K., Roettger, S., and R. Housley, 825 "Protecting Network Time Security Messages with the 826 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 827 for-nts-message-06 (work in progress), February 2016. 829 [I-D.ietf-ntp-extension-field] 830 Mizrahi, T. and D. Mayer, "The Network Time Protocol 831 Version 4 (NTPv4) Extension Fields", draft-ietf-ntp- 832 extension-field-07 (work in progress), February 2016. 834 [I-D.ietf-ntp-network-time-security] 835 Sibold, D., Roettger, S., and K. Teichel, "Network Time 836 Security", draft-ietf-ntp-network-time-security-13 (work 837 in progress), February 2016. 839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, 841 DOI 10.17487/RFC2119, March 1997, 842 . 844 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 845 Briscoe, "Timed Efficient Stream Loss-Tolerant 846 Authentication (TESLA): Multicast Source Authentication 847 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 848 June 2005, . 850 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 851 RFC 5652, DOI 10.17487/RFC5652, September 2009, 852 . 854 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 855 "Network Time Protocol Version 4: Protocol and Algorithms 856 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 857 . 859 10.2. Informative References 861 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 862 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 863 October 2014, . 865 Appendix A. Flow Diagrams of Client Behaviour 866 +---------------+ 867 |Access Messages| 868 +-------+-------+ 869 | 870 v 871 +---------------------+ 872 |Association Messages | 873 +----------+----------+ 874 | 875 +------------------------------>o 876 | | 877 | v 878 | +---------------+ 879 | |Cookie Messages| 880 | +-------+-------+ 881 | | 882 | o<------------------------------+ 883 | | | 884 | v | 885 | +-------------------+ | 886 | |Time Sync. Messages| | 887 | +---------+---------+ | 888 | | | 889 | v | 890 | +-----+ | 891 | |Check| | 892 | +--+--+ | 893 | | | 894 | /------------------+------------------\ | 895 | v v v | 896 | .-----------. .-------------. .-------. | 897 | ( MAC Failure ) ( Nonce Failure ) ( Success ) | 898 | '-----+-----' '------+------' '---+---' | 899 | | | | | 900 | v v v | 901 | +-------------+ +-------------+ +--------------+ | 902 | |Discard Data | |Discard Data | |Sync. Process | | 903 | +-------------+ +------+------+ +------+-------+ | 904 | | | | | 905 | | | v | 906 +-----------+ +------------------>o-----------+ 908 Figure 1: The client's behavior in NTS unicast mode. 910 +-----------------------------+ 911 |Broadcast Parameter Messages | 912 +--------------+--------------+ 913 | 914 o<--------------------------+ 915 | | 916 v | 917 +-----------------------------+ | 918 |Broadcast Time Sync. Message | | 919 +--------------+--------------+ | 920 | | 921 +-------------------------------------->o | 922 | | | 923 | v | 924 | +-------------------+ | 925 | |Key and Auth. Check| | 926 | +---------+---------+ | 927 | | | 928 | /----------------*----------------\ | 929 | v v | 930 | .---------. .---------. | 931 | ( Verified ) ( Falsified ) | 932 | '----+----' '----+----' | 933 | | | | 934 | v v | 935 | +-------------+ +-------+ | 936 | |Store Message| |Discard| | 937 | +------+------+ +---+---+ | 938 | | | | 939 | v +---------o 940 | +---------------+ | 941 | |Check Previous | | 942 | +-------+-------+ | 943 | | | 944 | /--------*--------\ | 945 | v v | 946 | .---------. .---------. | 947 | ( Verified ) ( Falsified ) | 948 | '----+----' '----+----' | 949 | | | | 950 | v v | 951 | +-------------+ +-----------------+ | 952 | |Sync. Process| |Discard Previous | | 953 | +------+------+ +--------+--------+ | 954 | | | | 955 +-----------+ +-----------------------------------+ 957 Figure 2: The client's behaviour in NTS broadcast mode. 959 Appendix B. Bit Lengths for Employed Primitives 961 Define the following bit lengths for server seed, nonces, cookies and 962 MACs: 964 B_accesskey = 128, 966 B_seed = 128, 968 B_nonce = 128, 970 B_cookie = 128, and 972 B_mac = 128. 974 Appendix C. Error Codes 976 +-----+---------+ 977 | Bit | Meaning | 978 +-----+---------+ 979 | 1 | D2 | 980 +-----+---------+ 982 Authors' Addresses 984 Dieter Sibold 985 Physikalisch-Technische Bundesanstalt 986 Bundesallee 100 987 Braunschweig D-38116 988 Germany 990 Phone: +49-(0)531-592-8420 991 Fax: +49-531-592-698420 992 Email: dieter.sibold@ptb.de 994 Stephen Roettger 995 Google Inc 997 Email: stephen.roettger@googlemail.com 998 Kristof Teichel 999 Physikalisch-Technische Bundesanstalt 1000 Bundesallee 100 1001 Braunschweig D-38116 1002 Germany 1004 Phone: +49-(0)531-592-8421 1005 Email: kristof.teichel@ptb.de