idnits 2.17.1 draft-ietf-ntp-using-nts-for-ntp-07.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: DTLS clients MUST NOT offer, and DTLS servers MUST not select, RC4 cipher suites. [RFC7465] -- The document date (October 31, 2016) is 2727 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: 'I-D.ietf-ntp-cms-for-nts-message' is defined on line 1276, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ntp-extension-field' is defined on line 1282, but no explicit reference was found in the text == Unused Reference: 'RFC3394' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: 'RFC4082' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 1316, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1329, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-13 == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-multi-path-synchronization-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-tictoc-multi-path-synchronization (ref. 'I-D.ietf-tictoc-multi-path-synchronization') ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 4082 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Downref: Normative reference to an Informational RFC: RFC 5297 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7507 (Obsoleted by RFC 8996) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NTP Working Group D. Franke 2 Internet-Draft Akamai 3 Intended status: Standards Track D. Sibold 4 Expires: May 4, 2017 K. Teichel 5 PTB 6 October 31, 2016 8 Using the Network Time Security Specification to Secure the Network Time 9 Protocol 10 draft-ietf-ntp-using-nts-for-ntp-07 12 Abstract 14 This document describes how to reach the objectives described in the 15 Network Time Security (NTS) specification when securing time 16 synchronization with servers using the Network Time Protocol (NTP). 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 4, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 61 4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4 62 4.1. Client-Server Mode . . . . . . . . . . . . . . . . . . . 5 63 4.2. Symmetric/Peer Mode and Control Modes . . . . . . . . . . 5 64 5. Employing DTLS for NTP Security . . . . . . . . . . . . . . . 5 65 5.1. DTLS profile for Network Time Security . . . . . . . . . 6 66 5.2. Transport mechanisms for DTLS records . . . . . . . . . . 7 67 5.2.1. Transport via NTS port . . . . . . . . . . . . . . . 7 68 5.2.2. Transport via NTP extension field . . . . . . . . . . 7 69 5.3. The NTS-encapsulated NTPv4 protocol . . . . . . . . . . . 9 70 5.4. The NTS Key Establishment protocol . . . . . . . . . . . 10 71 5.4.1. NTS-KE record types . . . . . . . . . . . . . . . . . 11 72 5.4.2. Key Extraction (generally) . . . . . . . . . . . . . 14 73 5.5. NTS Extensions for NTPv4 . . . . . . . . . . . . . . . . 14 74 5.5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . 14 75 5.5.2. Packet structure overview . . . . . . . . . . . . . . 15 76 5.5.3. The Unique Identifier extension . . . . . . . . . . . 16 77 5.5.4. The NTS Cookie extension . . . . . . . . . . . . . . 16 78 5.5.5. The NTS Cookie Placeholder extension . . . . . . . . 16 79 5.5.6. The NTS Authenticator and Encrypted Extensions 80 extension . . . . . . . . . . . . . . . . . . . . . . 17 81 5.5.7. Protocol details . . . . . . . . . . . . . . . . . . 18 82 5.6. Recommended format for NTS cookies . . . . . . . . . . . 20 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 6.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 21 85 6.2. SMI Security for S/MIME CMS Content Type Registry . . . . 21 86 6.3. DTLS-Based Key Exchange . . . . . . . . . . . . . . . . . 21 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 88 7.1. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 26 89 7.2. Initial Verification of the Server Certificates . . . . . 26 90 7.3. Treatment of Initial Messages . . . . . . . . . . . . . . 26 91 7.4. DTLS-Related Issues . . . . . . . . . . . . . . . . . . . 26 92 7.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 26 93 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 94 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 27 95 8.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 27 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 100 10.2. Informative References . . . . . . . . . . . . . . . . . 30 101 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 104 1. Introduction 106 The Network Time Security (NTS) 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. In particular, it describes a mechanism for using Datagram 115 Transport Layer Security [RFC6347] (DTLS) to provide cryptographic 116 security for NTP. Certain sections, are not inherently NTP-specific 117 and can be taken as guidance on how future work may apply the 118 described techniques to other time synchronization protocols such as 119 the Precision Time Protocol [IEC.61588_2009]. 121 2. Objectives 123 The specific objectives for applying the NTS specification to the NTP 124 are as follows: 126 o Authenticity: NTS enables an NTP client to authenticate its time 127 server(s). 129 o Integrity: NTS protects the integrity of NTP time synchronization 130 protocol packets via a message authentication code (MAC). 132 o Authorization: NTS optionally enables the server to verify the 133 client's authorization. 135 o Confidentiality: NTS does not provide confidentiality protection 136 of the time synchronization data. 138 o Privacy: NTS preserves unlinkability, i. e. it does not leak data 139 that would allow a passive attacker to track mobile NTP clients 140 when they move between networks. 142 o Request-Response-Consistency: NTS enables a client to match an 143 incoming response to a request it has sent. NTS also enables the 144 client to deduce from the response whether its request to the 145 server has arrived without alteration. 147 o Modes of operation: Both the client-server mode and the symmetric 148 peer mode of NTP are supported. The broadcast mode of NTP can NOT 149 be secured with measures within this document. 151 o Hybrid mode: Both secure and insecure communication modes are 152 possible for both NTP servers and clients. 154 o Compatibility: 156 * NTP associations which are not secured by NTS are not affected 157 by NTS-secured communication. 159 * An NTP server that does not support NTS is not affected by NTS- 160 secured authentication requests. 162 3. Terms and Abbreviations 164 MAC Message Authentication Code 166 NTP Network Time Protocol (RFC 5905 [RFC5905]) 168 NTS Network Time Security 170 DTLS Datagram Transport Layer Security 172 AEAD Authenticated Encryption with Associated Data (RFC 5116 173 [RFC5116]) 175 4. Overview of NTS-Secured NTP 177 The Network Time Protocol includes many different operating modes to 178 support various network topologies. In addition to its best-known 179 and most-widely-used client-server mode, it also includes modes for 180 synchronization between symmetric peers, a control mode for server 181 monitoring and administration and a broadcast mode. These various 182 modes have differing and contradictory requirements for security and 183 performance. Symmetric and control modes demand mutual 184 authentication and mutual replay protection, and for certain message 185 types control mode may require confidentiality as well as 186 authentication. Client-server mode places more stringent 187 requirements on resource utilization than other modes, because 188 servers may have vast number of clients and be unable to afford to 189 maintain per-client state. However, client-server mode also has more 190 relaxed security needs, because only the client requires replay 191 protection: it is harmless for servers to process replayed packets. 193 The security demands of symmetric and control modes, on the other 194 hand, are in conflict with the resource-utilization demands of 195 client-server mode: any scheme which provides replay protection 196 inherently involves maintaining some state to keep track of what 197 messages have already been seen. 199 This document does not discuss how to add security to NTP's broadcast 200 mode. 202 4.1. Client-Server Mode 204 The server does not keep a long-term state of the client. NTS 205 initially verifies the authenticity of the time server and exchanges 206 one or more symmetric keys. The DTLS-based key exchange procedure 207 described in Section 5 can be used for this exchange. An 208 implementation MUST support the use of this procedure. It MAY 209 additionally support the use of any alternative secure communication 210 for this purpose, as long as it fulfills the preconditions given in 211 [I-D.ietf-ntp-network-time-security], Section 6.1.1. 213 After the keys have been exchanged, the participants then use them to 214 protect the authenticity and the integrity of subsequent unicast-type 215 time synchronization packets. In order to do this, the server 216 attaches a Message Authentication Code (MAC) to each time 217 synchronization packet. The calculation of the MAC includes the 218 whole time synchronization packet and the symmetric key which is 219 stored on the client side. Therefore, the client can perform a 220 validity check for this MAC on reception of a time synchronization 221 packet. 223 4.2. Symmetric/Peer Mode and Control Modes 225 In the symmetric ("peer") mode as well as in control modes, there is 226 no requirement for statelessness on either side. Both sides exchange 227 and memorize one or more shared secrets. The shared secrets 228 exchanged are then used to secure NTP peer mode or control packets by 229 providing at least authenticity and integrity protection and possibly 230 also confidentiality. The DTLS-based key exchange procedure 231 described in Section 5.3 can be used for such communication. An 232 implementation MUST support the use of this procedure. 234 5. Employing DTLS for NTP Security 236 Since (as discussed in Section 4.1) no single approach can 237 simultaneously satisfy the needs of all modes, this specification 238 consists of not one protocol but a suite of them: 240 o The "NTS-encapsulated NTPv4" protocol is little more than "NTP 241 over DTLS": the two endpoints perform a DTLS handshake and then 242 exchange NTP packets encapsulated as DTLS Application Data. It is 243 suitable for symmetric and control modes, and is also secure for 244 client/server mode but relatively wasteful of server resources. 246 o The "NTS Key Establishment" protocol (NTS-KE) uses DTLS to 247 establish key material and negotiate some additional protocol 248 options, but then quickly closes the DTLS channel and does not use 249 it for the exchange of time packets. NTS-KE is designed to be 250 extensible, and might be extended to support key establishment for 251 other protocols such as PTP. 253 o The "NTS extensions for NTPv4" are a collection of NTP extension 254 fields for cryptographically securing NTPv4 using key material 255 previously negotiated using NTS-KE. They are suitable for 256 securing client/server mode because the server can implement them 257 without retaining per-client state, but on the other hand are 258 suitable *only* for client/server mode because only the client, 259 and not the server, is protected from replay. 261 5.1. DTLS profile for Network Time Security 263 Since securing time protocols is (as of 2016) a novel application of 264 DTLS, no backward-compatibility concerns exist to justify using 265 obsolete, insecure, or otherwise broken DTLS features or versions. 266 We therefore put forward the following requirements and guidelines, 267 roughly representing 2016's best practices. 269 Implementations MUST NOT negotiate DTLS versions earlier than 1.2. 271 Implementations willing to negotiate more than one possible version 272 of DTLS SHOULD NOT respond to handshake failures by retrying with a 273 downgraded protocol version. If they do, they MUST implement 274 [RFC7507]. 276 DTLS clients MUST NOT offer, and DTLS servers MUST not select, RC4 277 cipher suites. [RFC7465] 279 DTLS clients SHOULD offer, and DTLS servers SHOULD accept, the TLS 280 Renegotiation Indication Extension [RFC5746]. Regardless, they MUST 281 NOT initiate or permit insecure renegotiation. (*) 283 DTLS clients SHOULD offer, and DTLS servers SHOULD accept, the TLS 284 Session Hash and Extended Master Secret Extension [RFC7627]. (*) 285 Use of the Application-Layer Protocol Negotiation Extension [RFC7301] 286 is integral to NTS and support for it is REQUIRED for 287 interoperability. 289 (*): Note that DTLS 1.3 or beyond may render the indicated 290 recommendations inapplicable. 292 5.2. Transport mechanisms for DTLS records 294 This section specifies two mechanisms, one REQUIRED and one OPTIONAL, 295 for exchanging NTS-related DTLS records. It is intended that the 296 choice of transport mechanism be orthogonal to any concerns at the 297 application layer: DTLS records SHOULD receive identical disposition 298 regardless of which mechanism they arrive by. 300 5.2.1. Transport via NTS port 302 In this transport mechanism, DTLS records, formatted according to RFC 303 6347 [RFC6347] or a subsequent revision thereof, are exchanged 304 directly on UDP port [[TBD]], with one DTLS record per UDP packet and 305 no additional layer of encapsulation between the UDP header and the 306 DTLS record. Servers which implement NTS MUST support this 307 mechanism. 309 5.2.2. Transport via NTP extension field 311 In this transport mechanism, DTLS records are exchanged within 312 extension fields of specially-formed NTP packets, which are 313 themselves exchanged via the usual NTP service port (123/udp). NTP 314 packets conveying DTLS records SHALL be formatted as in Figure 1. 315 They MUST NOT contain any other extensions or a legacy MAC field. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 . . 322 . NTP Header (48 octets) . 323 . . 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Extension Type | Extension Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 . . 330 . DTLS Record (variable) . 331 . . 332 | | 333 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | | 335 +-+-+-+-+-+-+-+-+ + 336 | | 337 . . 338 . Padding (1-24 octets) . 339 . . 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 1: Format of NTP packets conveying DTLS records 345 Within the NTP header, 347 o The Leap Indicator field SHALL be set to 3 (unsynchronized). 349 o The Version Number field SHALL be set to 4. 351 o DTLS clients SHALL set the Mode field to 3, and DTLS servers SHALL 352 set the Mode field to 4, even if the DTLS record is being used (in 353 the full-encapsulation protocol) to protect some NTP mode other 354 than client/server. 356 o The Stratum field SHALL be set to 0 (unspecified or invalid). 358 o The Reference ID field (conveying a kiss code) SHALL be set to 359 "DTLS" 361 o DTLS servers SHALL set the origin timestamp field from the 362 transmit timestamp field of the packet most recently received from 363 the client. 365 o All other header fields MUST be ignored by the receiver, and MAY 366 contain arbitrary or bogus values. 368 The Extension Type field SHALL be set to [[TBD]]. The Extension 369 Length field SHALL be computed and set as per RFC 7822 [RFC7822]. 371 The DTLS Record field SHALL contain a DTLS Record formatted as per 372 RFC 6347 [RFC6347] or a subsequent revision thereof. 374 The Padding field SHALL contain between 1 and 24 octets of padding, 375 with every octet set to the number of padding octets included, e.g., 376 "01", "02 02", or "03 03 03". The number of padding bytes should be 377 chosen in order to comply with the RFC 7822 [RFC7822] requirement 378 that (in the absence of a legacy MAC) extensions have a total length 379 in octets (including the four octets for the type and length fields) 380 which is at least 28 and divisible by 4. Furthermore, since future 381 revisions of DTLS may employ record formats that are not self- 382 delimiting, at least one octet of padding MUST be included so that 383 receivers can unambiguously determine where the DTLS record ends and 384 the padding begins. If the length of the DTLS record is already at 385 least 24 and a multiple of 4, then the correct amount of padding to 386 include is 4 octets. 388 The NTP header values specified above are selected such that NTP 389 implementations which do not understand NTS will interpret the packet 390 as an innocuous no-op and not attempt to use it for time 391 synchronization. To NTS-aware implementations, however, these 392 packets are best understood as not being NTP packets at all, but 393 simply a means of "smuggling" arbitrary DTLS records across port 123/ 394 udp. Indeed, these records need not be pertinent to NTP at all -- 395 for example, they could be NTS-KE messages eventually intended for 396 securing PTP traffic. 398 This transport mechanism is intended for use as a fallback in 399 situations where firewalls or other middleboxes are preventing 400 communication on the NTS port. Support for it is OPTIONAL. 402 5.3. The NTS-encapsulated NTPv4 protocol 404 The NTS-encapsulated NTPv4 protocol proceeds in two parts. First, 405 DTLS handshake records are exchanged using one of the two transport 406 mechanisms specified in Section 5.2. The two endpoints carry out a 407 DTLS handshake in conformance with Section 5.1, with the client 408 offering (via an ALPN [RFC7301] extension), and the server accepting, 409 an application-layer protocol of "ntp/4". Second, once the handshake 410 is successfully completed, the two endpoints use the established 411 channel to exchange arbitrary NTPv4 packets as DTLS-protected 412 Application Data. 414 In addition to the requirements specified in Section 5.1, 415 implementations MUST enforce the anti-replay mechanism specified in 416 Section 4.1.2.6 of RFC 6347 [RFC6347] (or an equivalent mechanism 417 specified in a subsequent revision of DTLS). Servers wishing to 418 enforce access control SHOULD either demand a client certificate or 419 use a PSK-based handshake in order to establish the client's 420 identity. 422 The NTS-encapsulated NTPv4 protocol is the RECOMMENDED mechanism for 423 cryptographically securing mode 1 (symmetric active), 2 (symmetric 424 passive), and 6 (control) NTPv4 traffic. It is equally safe for mode 425 3/4 (client/server) traffic, but is NOT RECOMMENDED for this purpose 426 because it scales poorly compared to using NTS Extensions for NTPv4 427 (Section 5.5). 429 5.4. The NTS Key Establishment protocol 431 The NTS Key Establishment (NTS-KE) protocol is carried out by 432 exchanging DTLS records using one of the two transport mechanisms 433 specified in Section 5.2. The two endpoints carry out a DTLS 434 handshake in conformance with Section 5.1, with the client offering 435 (via an ALPN [RFC7301] extension), and the server accepting, an 436 application-layer protocol of "ntske/1". Immediately following a 437 successful handshake, the client SHALL send a single request (as 438 Application Data encapsulated in the DTLS-protected channel), then 439 the server SHALL send a single response followed by a "Close notify" 440 alert and then discard the channel state. 442 The client's request and the server's response each SHALL consist of 443 a sequence of records formatted according to Figure 2. The sequence 444 SHALL be terminated by a "End of Message" record, which has a Record 445 Type of zero and a zero-length body. Furthermore, requests and non- 446 error responses each SHALL include exactly one NTS Next Protocol 447 Negotiation record. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |C| Record Type | Body Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 . . 456 . Record Body . 457 . . 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 2 463 [[Ed. Note: this ad-hoc binary format should be fine as long as we 464 continue to keep things very simple. However, if we think there's 465 any reasonable probability of wanting to include more complex data 466 structures, we should consider using some semi-structured data format 467 such as JSON, Protocol Buffers, or (ugh) ASN.1]] 469 The requirement that all NTS-KE messages be terminated by an End of 470 Message record makes them self-delimiting. One DTLS record MAY, and 471 typically will, contain multiple NTS-KE records. NTS-KE records MAY 472 be split across DTLS record boundaries. If, likely due to packet 473 loss, an incomplete NTS-KE message is received, implementations MUST 474 treat this an error, which clients SHOULD handle by restarting with a 475 fresh DTLS handshake and trying again. 477 The fields of an NTS-KE record are defined as follows: 479 o C (Critical Bit): Determines the disposition of unrecognized 480 Record Types. Implementations which receive a record with an 481 unrecognized Record Type MUST ignore the record if the Critical 482 Bit is 0, and MUST treat it as an error if the Critical Bit is 1. 484 o Record Type: A 15-bit integer in network byte order (from most-to- 485 least significant, its bits are record bits 7-1 and then 15-8). 486 The semantics of record types 0-5 are specified in this memo; 487 additional type numbers SHALL be tracked through the IANA Network 488 Time Security Key Establishment Record Types registry. 490 o Body Length: the length of the Record Body field, in octets, as a 491 16-bit integer in network byte order. Record bodies may have any 492 representable length and need not be aligned to a word boundary. 494 o Record Body: the syntax and semantics of this field shall be 495 determined by the Record Type. 497 5.4.1. NTS-KE record types 499 The following NTS-KE Record Types are defined. 501 5.4.1.1. End of Message 503 The End of Message record has a Record Type number of 0 and an zero- 504 length body. It MUST occur exactly once as the final record of every 505 NTS-KE request and response. The Critical Bit MUST be set. 507 5.4.1.2. NTS Next Protocol Negotiation 509 The NTS Next Protocol Negotiation record has a record type of 1. It 510 MUST occur exactly once in every NTS-KE request and response. Its 511 body consists of a sequence of 16-octet strings. Each 16-octet 512 string represents a Protocol Name from the IANA Network Time Security 513 Next Protocols registry. The Critical Bit MUST be set. 515 The Protocol Names listed in the client's NTS Next Protocol 516 Negotiation record denote those protocols which the client wishes to 517 speak using the key material established through this NTS-KE session. 518 The Protocol Names listed in the server's response MUST comprise a 519 subset of those listed in the request, and denote those protocols 520 which the server is willing and able to speak using the key material 521 established through this NTS-KE session. The client MAY proceed with 522 one or more of them. The request MUST list at least one protocol, 523 but the response MAY be empty. 525 5.4.1.3. Error 527 The Error record has a Record Type number of 2. Its body is exactly 528 two octets long, consisting of an unsigned 16-bit integer in network 529 byte order, denoting an error code. The Critical Bit MUST be set. 531 Clients MUST NOT include Error records in their request. If clients 532 receive a server response which includes an Error record, they MUST 533 discard any negotiated key material and MUST NOT proceed to the Next 534 Protocol. 536 The following error code are defined. 538 o Error code 0 means "Unrecognized Critical Record". The server 539 MUST respond with this error code if the request included a record 540 which the server did not understand and which had its Critical Bit 541 set. The client SHOULD NOT retry its request without 542 modification. 544 o Error code 1 means "Bad Request". The server MUST respond with 545 this error if, upon the expiration of an implementation-defined 546 timeout, it has not yet received a complete and syntactically 547 well-formed request from the client. This error is likely to be 548 the result of a dropped packet, so the client SHOULD start over 549 with a new DTLS handshake and retry its request. 551 5.4.1.4. Warning 553 The Warning record has a Record Type number of 3. Its body is 554 exactly two octets long, consisting of an unsigned 16-bit integer in 555 network byte order, denoting a warning code. The Critical Bit MUST 556 be set. 558 Clients MUST NOT include Warning records in their request. If 559 clients receive a server response which includes an Warning record, 560 they MAY discard any negotiated key material and abort without 561 proceeding to the Next Protocol. Unrecognized warning codes MUST be 562 treated as errors. 564 This memo defines no warning codes. 566 5.4.1.5. AEAD Algorithm Negotiation 568 The AEAD Algorithm Negotiation record has a Record Type number of 4. 569 Its body consists of a sequence of unsigned 16-bit integers in 570 network byte order, denoting Numeric Identifiers from the IANA AEAD 571 registry [RFC5116]. The Critical Bit MAY be set. 573 If the NTS Next Protocol Negotiation record offers "ntp/4",this 574 record MUST be included exactly once. Other protocols MAY require it 575 as well. 577 When included in a request, this record denotes which AEAD algorithms 578 the client is willing to use to secure the Next Protocol, in 579 decreasing preference order. When included in a response, this 580 record denotes which algorithm the server chooses to use, or is empty 581 if the server supports none of the algorithms offered.. In requests, 582 the list MUST include at least one algorithm. In responses, it MUST 583 include at most one. Honoring the client's preference order is 584 OPTIONAL: servers may select among any of the client's offered 585 choices, even if they are able to support some other algorithm which 586 the client prefers more. 588 Server implementations of NTS extensions for NTPv4 (Section 5.5) MUST 589 support AEAD_AES_128_GCM (Numeric Identifier 1). That is, if the 590 client includes AEAD_AES_128_GCM in its AEAD Algorithm Negotiation 591 record, and the server accepts the "ntp/4" protocol in its NTS Next 592 Protocol Negotiation record, then the server's AEAD Algorithm 593 Negotiation record MUST NOT be empty. 595 5.4.1.6. New Cookie for NTPv4 597 The New Cookie for NTPv4 record has a Record Type number of 5. The 598 contents of its body SHALL be implementation-defined and clients MUST 599 NOT attempt to interpret them. See [[TODO]] for a RECOMMENDED 600 construction. 602 Clients MUST NOT send records of this type. Servers MUST send at 603 least one record of this type, and SHOULD send eight of them, if they 604 accept "ntp/4" as a Next Protocol. The Critical Bit SHOULD NOT be 605 set. 607 5.4.2. Key Extraction (generally) 609 Following a successful run of the NTS-KE protocol, key material SHALL 610 be extracted according to RFC 5705 [RFC5705]. Inputs to the exporter 611 function are to be constructed in a manner specific to the negotiated 612 Next Protocol. However, all protocols which utilize NTS-KE MUST 613 conform to the following two rules: 615 o The disambiguating label string MUST be "EXPORTER-network-time- 616 security/1". 618 o The per-association context value MUST be provided, and MUST begin 619 with the 16-octet Protocol Name which was negotiated as a Next 620 Protocol. 622 5.5. NTS Extensions for NTPv4 624 5.5.1. Key Extraction (for NTPv4) 626 Following a successful run of the NTS-KE protocol wherein "ntp/4" is 627 selected as a Next Protocol, two AEAD keys SHALL be extracted: a 628 client-to-server (C2S) key and a server-to-client (S2C) key. These 629 keys SHALL be computed according to RFC 5705 [RFC5705], using the 630 following inputs. 632 The disambiguating label string SHALL be "EXPORTER-network-time- 633 security/1". 635 The per-association context value SHALL consist of the following 636 19 octets: 638 The first 16 octets SHALL be (in hexadecimal): 640 6E 74 70 2F 34 00 00 00 00 00 00 00 00 00 00 00 641 The next two octets SHALL be the Numeric Identifier of the 642 negotiated AEAD Algorithm, in network byte order. 644 The final octet SHALL be 0x00 for the C2S key and 0x01 for the 645 S2C key. 647 Implementations wishing to derive additional keys for private or 648 experimental use MUST NOT do so by extending the above-specified 649 syntax for per-association context values. Instead, they SHOULD use 650 their own disambiguating label string. Note that RFC 5705 provides 651 that disambiguating label strings beginning with "EXPERIMENTAL" MAY 652 be used without IANA registration. 654 5.5.2. Packet structure overview 656 In general, an NTS-protected NTPv4 packet consists of: 658 The usual 48-octet NTP header, which is authenticated but not 659 encrypted. 661 Some extensions which are authenticated but not encrypted. 663 An NTS extension which contains AEAD output (i.e., an 664 authentication tag and possible ciphertext). The corresponding 665 plaintext, if non-empty, consists of some extensions which benefit 666 from both encryption and authentication. 668 Possibly, some additional extensions which are neither encrypted 669 nor authenticated. These are discarded by the receiver. [[Ed. 670 Note: right now there's no good reason for the sender to include 671 anything here, but eventually there might be. We've seen Checksum 672 Complement [RFC7821] and LAST-EF as two examples of semantically- 673 void extensions that are included to satsify constraints imposed 674 lower on the protocol stack, and while there's no reason to use 675 either of these on NTS-protected packets, I think we could see 676 similar examples in the future. So, rejecting packets with 677 unauthenticated extensions could cause interoperability problems, 678 while accepting and processing those extensions would of course be 679 a security risk. Thus, I think "allow and discard" is the correct 680 policy.]] 682 Always included among the authenticated or authenticated-and- 683 encrypted extensions are a cookie extension and a unique-identifier 684 extension. The purpose of the cookie extension is to enable the 685 server to offload storage of session state onto the client. The 686 purpose of the unique-identifier extension is to protect the client 687 from replay attacks. 689 5.5.3. The Unique Identifier extension 691 The Unique Identifier extension has a Field Type of [[TBD]]. When 692 the extension is included in a client packet (mode 3), its body SHALL 693 consist of a string of octets generated uniformly at random. The 694 string SHOULD be 32 octets long. When the extension is included in a 695 server packet (mode 4), its body SHALL contain the same octet string 696 as was provided in the client packet to which the server is 697 responding. Its use in modes other than client/server is not 698 defined. 700 The Unique Identifier extension provides the client with a 701 cryptographically strong means of detecting replayed packets. It may 702 also be used standalone, without NTS, in which case it provides the 703 client with a means of detecting spoofed packets from off-path 704 attackers. Historically, NTP's origin timestamp field has played 705 both these roles, but for cryptographic purposes this is suboptimal 706 because it is only 64 bits long and, depending on implementation 707 details, most of those bits may be predictable. In contrast, the 708 Unique Identifier extension enables a degree of unpredictability and 709 collision-resistance more consistent with cryptographic best 710 practice. 712 [[TODO: consider using separate extension types for request and 713 response, thus allowing for use in symmetric mode. But proper 714 handling in the presence of dropped packets needs to be documented 715 and involves a lot of subtlety.]] 717 5.5.4. The NTS Cookie extension 719 The NTS Cookie extension has a Field Type of [[TBD]]. Its purpose is 720 to carry information which enables the server to recompute keys and 721 other session state without having to store any per-client state. 722 The contents of its body SHALL be implementation-defined and clients 723 MUST NOT attempt to interpret them. See [[TODO]] for a RECOMMENDED 724 construction. The NTS Cookie extension MUST NOT be included in NTP 725 packets whose mode is other than 3 (client) or 4 (server). 727 5.5.5. The NTS Cookie Placeholder extension 729 The NTS Cookie Placeholder extension has a Field Type of [[TBD]]. 730 When this extension is included in a client packet (mode 3), it 731 communicates to the server that the client wishes it to send 732 additional cookies in its response. This extension MUST NOT be 733 included in NTP packets whose mode is other than 3. 735 Whenever an NTS Cookie Placeholder extension is present, it MUST be 736 accompanied by an NTS Cookie extension, and the body length of the 737 NTS Cookie Placeholder extension MUST be the same as the body length 738 of the NTS Cookie Extension. (This length requirement serves to 739 ensure that the response will not be larger than the request, in 740 order to improve timekeeping precision and prevent DDoS 741 amplification). The contents of the NTS Cookie Placeholder 742 extension's body are undefined and, aside from checking its length, 743 MUST be ignored by the server. 745 5.5.6. The NTS Authenticator and Encrypted Extensions extension 747 The NTS Authenticator and Encrypted Extensions extension is the 748 central cryptographic element of an NTS-protected NTP packet. Its 749 Field Type is [[TBD]] and the format of its body SHALL be as follows: 751 Nonce length: two octets in network byte order, giving the length 752 of the Nonce field. 754 Nonce: a nonce as required by the negotiated AEAD Algorithm. 756 Ciphertext: the output of the negotiated AEAD Algorithm. The 757 structure of this field is determined by the negotiated algorithm, 758 but it typically contains an authentication tag in addition to the 759 actual ciphertext. 761 Padding: between 1 and 24 octets of padding, with every octet set 762 to the number of padding octets included, e.g., "01", "02 02", or 763 "03 03 03". The number of padding bytes should be chosen in order 764 to comply with the RFC 7822 [RFC7822] requirement that (in the 765 absence of a legacy MAC) extensions have a total length in octets 766 (including the four octets for the type and length fields) which 767 is at least 28 and divisible by 4. At least one octet of padding 768 MUST be included, so that implementations can unambiguously 769 delimit the end of the ciphertext from the start of the padding. 771 The Ciphertext field SHALL be formed by providing the following 772 inputs to the negotiated AEAD Algorithm: 774 K: For packets sent from the client to the server, the C2S key 775 SHALL be used. For packets sent from the server to the client, 776 the S2C key SHALL be used. 778 A: The associated data SHALL consist of the portion of the NTP 779 packet beginning from the start of the NTP header and ending at 780 the end of the last extension which precedes the NTS Authenticator 781 and Encrypted Extensions extension. 783 P: The plaintext SHALL consist of all (if any) extensions to be 784 encrypted. 786 N: The nonce SHALL be formed however required by the negotiated 787 AEAD Algorithm. 789 The NTS Authenticator and Encrypted Extensions extension MUST NOT be 790 included in NTP packets whose mode is other than 3 (client) or 4 791 (server). 793 5.5.7. Protocol details 795 A client sending an NTS-protected request SHALL include the following 796 extensions: 798 Exactly one Unique Identifier extension, which MUST be 799 authenticated and MUST NOT be encrypted [[Ed. Note: so that if 800 the server can't decrypt the request, it can still echo back the 801 Unique Identifier in the NTS NAK it sends]]. MUST NOT duplicate 802 those of any previous request. 804 Exactly one NTS Cookie extension, which MUST be authenticated and 805 MUST NOT be encrypted. The cookie MUST be one which the server 806 previously provided the client; it may have been provided during 807 the NTS-KE handshake or in response to a previous NTS-protected 808 NTP request. To protect client's privacy, the same cookie SHOULD 809 NOT be included in multiple requests. If the client does not have 810 any cookies that it has not already sent, it SHOULD re-run the 811 NTS-KE protocol before continuing. 813 Exactly one NTS Authenticator and Encrypted Extensions extension, 814 generated using an AEAD Algorithm and C2S key established through 815 NTS-KE. 817 The client MAY include one or more NTS Cookie Placeholder extensions, 818 which MUST be authenticated and MAY be encrypted. The number of NTS 819 Cookie Placeholder extensions that the client includes SHOULD be such 820 that if the client includes N placeholders and the server sends back 821 N+1 cookies, the number of unused cookies stored by the client will 822 come to eight. When both the client and server adhere to all cookie- 823 management guidance provided in this memo, the number of placeholder 824 extensions will equal the number of dropped packets since the last 825 successful volley. 827 The client MAY include additional (non-NTS-related) extensions, which 828 MAY appear prior to the NTS Authenticator and Encrypted Extensions 829 extension (therefore authenticated but not encrypted), within it 830 (therefore encrypted and authenticated), or after it (therefore 831 neither encrypted nor authenticated). In general, however, the 832 server MUST discard any unauthenticated extensions and process the 833 packet as though they were not present. Servers MAY implement 834 exceptions to this requirement for particular extensions if their 835 specification explicitly provides for such. 837 Upon receiving an NTS-protected request, the server SHALL (through 838 some implementation-defined mechanism) use the cookie to recover the 839 AEAD Algorithm, C2S key, and S2C key associated with the request, and 840 then use the C2S key to authenticate the packet and decrypt the 841 ciphertext. If the cookie is valid and authentication and decryption 842 succeed, then the server SHALL include the following extensions in 843 its response: 845 Exactly one Unique Identifier extension, which MUST be 846 authenticated, MUST NOT be encrypted, and whose contents SHALL 847 echo those provided by the client. 849 Exactly one NTS Authenticator and Encrypted Extensions extension, 850 generated using the AEAD algorithm and S2C key recovered from the 851 cookie provided by the client. 853 One or more NTS Cookie extensions, which MUST be authenticated and 854 encrypted. The number of NTS Cookie extensions included SHOULD be 855 equal to, and MUST NOT exceed, one plus the number of valid NTS 856 Cookie Placeholder extensions included in the request. 858 The server MAY include additional (non-NTS-related) extensions, which 859 MAY appear prior to the NTS Authenticator and Encrypted Extensions 860 extension (therefore authenticated but not encrypted), within it 861 (therefore encrypted and authenticated), or after it (therefore 862 neither encrypted nor authenticated). In general, however, the 863 client MUST discard any unauthenticated extensions and process the 864 packet as though they were not present. Clients MAY implement 865 exceptions to this requirement for particular extensions if their 866 specification explicitly provides for such. 868 If the server is unable to validate the cookie or authenticate the 869 request, it SHOULD respond with a Kiss-o'-Death packet (see RFC 5905, 870 Section 7.4) [RFC5905]) with kiss code "NTSN" (meaning "NTS NAK"). 871 Such a response MUST include exactly one Unique Identifier extension 872 whose contents SHALL echo those provided by the client. It MUST NOT 873 include any NTS Cookie or NTS Authenticator and Encrypted Extensions 874 extension. [[Ed. Note: RFC 5905 already provides the kiss code 875 "CRYP" meaning "Cryptographic authentication or identification 876 failed" but I think this is meant to be Autokey-specific.]] 878 Upon receiving an NTS-protected response, the client MUST verify that 879 the Unique Identifier matches that of an outstanding request, and 880 that the packet is authentic under the S2C key associated with that 881 request. If either of these checks fails, the packet MUST be 882 discarded without further processing. 884 Upon receiving an NTS NAK, the client MUST verify that the Unique 885 Identifier matches that of an outstanding request. If this check 886 fails, the packet MUST be discarded without further processing. If 887 this check passes, the client SHOULD discard all cookies and AEAD 888 keys associated with the server which sent the NAK and initiate a 889 fresh NTS-KE handshake. 891 5.6. Recommended format for NTS cookies 893 This section provides a RECOMMENDED way for servers to construct NTS 894 cookies. Clients MUST NOT examine the cookie under the assumption 895 that it is constructed according to this section. 897 The role of cookies in NTS is closely analagous to that of session 898 cookies in TLS. Accordingly, the thematic resemblance of this 899 section to RFC 5077 [RFC5077] is deliberate, and the reader should 900 likewise take heed of its security considerations. 902 Servers should select an AEAD algorithm which they will use to 903 encrypt and authenticate cookies. The chosen algorithm should be one 904 such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidential 905 nonce reuse, and it need not be the same as the one that was 906 negotiated with the client. Servers should randomly generate and 907 store a master AEAD key `K`. Servers should additionally choose a 908 non-secret, unique value `I` as key-identifier for `K`. 910 Servers should periodically (e.g., once daily) generate a new pair 911 (I,K) and immediately switch to using these values for all newly- 912 generated cookies. Immediately following each such key rotation, 913 servers should securely erase any keys generated two or more rotation 914 periods prior. Servers should continue to accept any cookie 915 generated using keys that they have not yet erased, even if those 916 keys are no longer current. Erasing old keys provides for forward 917 secrecy, limiting the scope of what old information can be stolen if 918 a master key is somehow compromised. Holding on to a limited number 919 of old keys allows clients to seamlessly transition from one 920 generation to the next without having to perform a new NTS-KE 921 handshake. 923 [[TODO: discuss key management considerations for load-balanced 924 servers]] 926 To form a cookie, servers should first form a plaintext `P` 927 consisting of the following fields: 929 The AEAD algorithm negotiated during NTS-KE 931 The S2C key 933 The C2S key 935 Servers should the generate a nonce `N` uniformly at random, and form 936 AEAD output `C` by encrypting `P` under key `K` with nonce `N` and no 937 associated data. 939 The cookie should consist of the tuple `(I,N,C)`. 941 [[TODO: explicitly specify how to verify and decrypt a cookie, not 942 just how to form one]] 944 6. IANA Considerations 946 6.1. Field Type Registry 948 Within the "NTP Extensions Field Types" registry table, add the field 949 types: 951 Field Type Meaning References 952 ---------- ------------------------------------ ---------- 953 TBD1 NTS-Related Content [this doc] 954 TBD2 NTS-Related Content [this doc] 955 TBD3 NTS-Related Content [this doc] 957 6.2. SMI Security for S/MIME CMS Content Type Registry 959 Within the "SMI Security for S/MIME CMS Content Type 960 (1.2.840.113549.1.9.16.1)" table, add one content type identifier: 962 Decimal Description References 963 ------- -------------------------------------------- ---------- 964 TBD4 id-ct-nts-ntsForNtpMessageAuthenticationCode [this doc] 966 6.3. DTLS-Based Key Exchange 968 IANA is requested to allocate an entry in the Service Name and 969 Transport Protocol Port Number Registry as follows: 971 Service Name: nts 973 Transport Protocol: udp 975 Assignee: IESG 976 Contact: IETF Chair 978 Description: Network Time Security 980 Reference: [[this memo]] 982 Port Number: selected by IANA from the user port range 984 IANA is requested to allocate the following two entries in the 985 Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry: 987 Protocol: Network Time Security Key Establishment, version 1 989 Identification Sequence: 990 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1") 992 Reference: [[this memo]] 994 Protocol: Network Time Protocol, version 4 996 Identification Sequence: 997 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4") 999 Reference: [[this memo]] 1001 IANA is requested to allocate the following entry in the TLS Exporter 1002 Label Registry: 1004 +----------------------------------+---------+---------------+------+ 1005 | Value | DTLS-OK | Reference | Note | 1006 +----------------------------------+---------+---------------+------+ 1007 | EXPORTER-network-time-security/1 | Y | [[this memo]] | | 1008 +----------------------------------+---------+---------------+------+ 1010 IANA is requested to allocate the following entries in the registry 1011 of NTP Kiss-o'-Death codes: 1013 +------+------------------------------+ 1014 | Code | Meaning | 1015 +------+------------------------------+ 1016 | DTLS | Packet conveys a DTLS record | 1017 | NTSN | NTS NAK | 1018 +------+------------------------------+ 1020 IANA is requested to allocate the following entries in the NTP 1021 Extensions Field Types registry: 1023 +------------+---------------------------------------+--------------+ 1024 | Field Type | Meaning | Reference | 1025 +------------+---------------------------------------+--------------+ 1026 | [[TBD]] | DTLS Record | [[this | 1027 | | | memo]] | 1028 | [[TBD]] | Unique Identifier | [[this | 1029 | | | memo]] | 1030 | [[TBD]] | NTS Cookie | [[this | 1031 | | | memo]] | 1032 | [[TBD]] | NTS Authenticator and Encrypted | [[this | 1033 | | Extensions | memo]] | 1034 +------------+---------------------------------------+--------------+ 1036 IANA is requested to create a new registry entitled "Network Time 1037 Security Key Establishment Record Types". Entries SHALL have the 1038 following fields: 1040 Type Number (REQUIRED): An integer in the range 0-32767 inclusive 1042 Description (REQUIRED): short text description of the purpose of 1043 the field 1045 Set Critical Bit (REQUIRED): One of "MUST", "SHOULD", "MAY", 1046 "SHOULD NOT", or "MUST NOT" 1048 Reference (REQUIRED): A reference to a document specifying the 1049 semantics of the record. 1051 The policy for allocation of new entries in this registry SHALL vary 1052 by the Type Number, as follows: 1054 0-1023: Standards Action 1056 1024-16383: Specification Required 1058 16384-32767: Private and Experimental Use 1060 Applications for new entries SHALL specify the contents of the 1061 Description, Set Critical Bit and Reference fields and which of the 1062 above ranges the Type Number should be allocated from. Applicants 1063 MAY request a specific Type Number, and such requests MAY be granted 1064 at the registrar's discretion. 1066 The initial contents of this registry SHALL be as follows: 1068 +-------------+-----------------------------+----------+------------+ 1069 | Field | Description | Critical | Reference | 1070 | Number | | | | 1071 +-------------+-----------------------------+----------+------------+ 1072 | 0 | End of message | MUST | [[this | 1073 | | | | memo]] | 1074 | 1 | NTS next protocol | MUST | [[this | 1075 | | negotiation | | memo]] | 1076 | 2 | Error | MUST | [[this | 1077 | | | | memo]] | 1078 | 3 | Warning | MUST | [[this | 1079 | | | | memo]] | 1080 | 4 | AEAD algorithm negotation | MAY | [[this | 1081 | | | | memo]] | 1082 | 5 | New cookie for NTPv4 | SHOULD | [[this | 1083 | | | NOT | memo]] | 1084 | 16384-32767 | Reserved for Private & | MAY | [[this | 1085 | | Experimental Use | | memo]] | 1086 +-------------+-----------------------------+----------+------------+ 1088 IANA is requested to create a new registry entitled "Network Time 1089 Security Next Protocols". Entries SHALL have the following fields: 1091 Protocol Name (REQUIRED): a sequence of 16 octets. Shorter 1092 sequences SHALL implicitly be right-padded with null octets 1093 (0x00). 1095 Human-Readable Name (OPTIONAL): if the sequence of octets making 1096 up the protocol name intentionally represent a valid UTF-8 1097 [RFC3629] string, this field SHALL consist of that string. 1099 Reference (RECOMMENDED): a reference to a relevant specification 1100 document. If no relevant document exists, a point-of-contact for 1101 questions regarding the entry SHOULD be listed here in lieu. 1103 Applications for new entries in this registry SHALL specify all 1104 desired fields, and SHALL be granted on a First Come, First Serve 1105 basis. Protocol Names beginning with 0x78 0x2D ("x-") SHALL be 1106 reserved for Private or Experimental Use, and SHALL NOT be 1107 registered. The reserved entry "ptp/2" may be updated or released by 1108 a future Standards Action. 1110 The initial contents of this registry SHALL be as follows: 1112 +---------------------------+-----------------+---------------------+ 1113 | Protocol Name | Human-Readable | Reference | 1114 | | Name | | 1115 +---------------------------+-----------------+---------------------+ 1116 | 0x6E 0x74 0x70 0x2F 0x34 | ntp/4 | [[this memo]] | 1117 | 0x70 0x74 0x70 0x2F 0x32 | ptp/2 | Reserved by [[this | 1118 | | | memo]] | 1119 +---------------------------+-----------------+---------------------+ 1121 IANA is requested to create two new registries entitled "Network Time 1122 Security Error Codes" and "Network Time Security Warning Codes". 1123 Entries in each SHALL have the following fields: 1125 Number (REQUIRED): a 16-bit unsigned integer 1127 Description (REQUIRED): a short text description of the condition. 1129 Reference (REQUIRED): a reference to a relevant specification 1130 document. 1132 The policy for allocation of new entries in these registries SHALL 1133 vary by their Number, as follows: 1135 0-1023: Standards Action 1137 1024-32767: Specification Required 1139 32768-65535: Private and Experimental Use 1141 The initial contents of the Network Time Security Error Codes 1142 Registry SHALL be as follows: 1144 +--------+---------------------------------+---------------+ 1145 | Number | Description | Reference | 1146 +--------+---------------------------------+---------------+ 1147 | 0 | Unrecognized Critical Extension | [[this memo]] | 1148 | 1 | Bad Request | [[this memo]] | 1149 +--------+---------------------------------+---------------+ 1151 The Network Time Security Warning Codes Registry SHALL initially be 1152 empty. 1154 7. Security Considerations 1156 All security considerations described in 1157 [I-D.ietf-ntp-network-time-security] have to be taken into account. 1158 The application of NTS to NTP requires the following additional 1159 considerations. 1161 7.1. Usage of NTP Pools 1163 The certification-based authentication scheme described in 1164 [I-D.ietf-ntp-network-time-security] is not applicable to the concept 1165 of NTP pools. Therefore, NTS is unable to provide secure usage of 1166 NTP pools. 1168 7.2. Initial Verification of the Server Certificates 1170 The client may wish to verify the validity of certificates during the 1171 initial association phase. Since it generally has no reliable time 1172 during this initial communication phase, it is impossible to verify 1173 the period of validity of the certificates. 1175 7.3. Treatment of Initial Messages 1177 NTP packets which contains extension fields with key exchange 1178 messages do not provide integrity and authenticity protection of the 1179 included time stamps. Therefore these NTP packets MUST NOT be used 1180 for clock synchronization. Otherwise an initial attack on the 1181 client's clock [attacking-ntp] can potentially circumvent the 1182 employed security measures of later messages [delorean]. 1184 7.4. DTLS-Related Issues 1186 ... TBD 1188 7.5. Delay Attack 1190 In a packet delay attack, an adversary with the ability to act as a 1191 MITM delays time synchronization packets between client and server 1192 asymmetrically [RFC7384]. This prevents the client from accurately 1193 measuring the network delay, and hence its time offset to the server 1194 [Mizrahi]. The delay attack does not modify the content of the 1195 exchanged synchronization packets. Therefore, cryptographic means do 1196 not provide a feasible way to mitigate this attack. However, the 1197 maximum error that an adversary can introduced is bounded by half of 1198 the round trip delay. Also, several non-cryptographic precautions 1199 can be taken in order to detect this attack. 1201 1. Usage of multiple time servers: this enables the client to detect 1202 the attack, provided that the adversary is unable to delay the 1203 synchronization packets between the majority of servers. This 1204 approach is commonly used in NTP to exclude incorrect time 1205 servers [RFC5905]. 1207 2. Multiple communication paths: The client and server utilize 1208 different paths for packet exchange as described in the I-D 1210 [I-D.ietf-tictoc-multi-path-synchronization]. The client can 1211 detect the attack, provided that the adversary is unable to 1212 manipulate the majority of the available paths [Shpiner]. Note 1213 that this approach is not yet available, neither for NTP nor for 1214 PTP. 1216 3. Usage of an encrypted connection: the client exchanges all 1217 packets with the time server over an encrypted connection (e.g. 1218 IPsec). This measure does not mitigate the delay attack, but it 1219 makes it more difficult for the adversary to identify the time 1220 synchronization packets. 1222 4. Introduction of a threshold value for the delay time of the 1223 synchronization packets. The client can discard a time server if 1224 the packet delay time of this time server is larger than the 1225 threshold value. 1227 8. Privacy Considerations 1229 8.1. Confidentiality 1231 The actual time synchronization data in NTP packets does not involve 1232 any information that needs to be kept secret. There also does not 1233 seem to be any necessity to disguise the nature of an NTP 1234 association. This is why content confidentiality is a non-objective 1235 for this document. 1237 8.2. Unlinkability 1239 The scenario that is to be prevented is one where whenever a new 1240 network address is associated with a device (e.g. because said device 1241 moved between different networks), a passive attacker is able to link 1242 said new address with one that was formerly used by the device, 1243 because of recognizable data that the device persistently sends as 1244 part of an NTS-secured NTP association. This is the justification 1245 for continually supplying the client with fresh cookies, so that a 1246 cookie never represents recognizable data in the sense outlined 1247 above. 1249 Note that the objective of NTS regarding unlinkability is merely to 1250 not leak any additional data that would cause linkability. NTS does 1251 not rectify legacy linkability issues that are already present in 1252 NTP. To minimize the risk of being tracked by a passive adversary 1253 the NTP client has to minimize the information it transmits within a 1254 client request (mode 3 packet) as described in the draft "I-D.draft- 1255 dfranke-ntp-data-minimization". 1257 Also note that normal NTP clients should not act as NTP servers. 1258 Otherwise, an active adversary may be able to abuse the client's 1259 server responses (mode 4 packets) for its tracking. This is done by 1260 [tbd]. 1262 9. Acknowledgements 1264 The authors would like to thank Richard Barnes, Steven Bellovin, 1265 Sharon Goldberg, Russ Housley, Martin Langer, Miroslav Lichvar, 1266 Aanchal Malhotra, Dave Mills, Danny Mayer, Karen O'Donoghue, Eric K. 1267 Rescorla, Stephen Roettger, Kurt Roeckx, Kyle Rose, Rich Salz, Brian 1268 Sniffen, Susan Sons, Douglas Stebila, Harlan Stenn, Martin Thomson, 1269 and Richard Welty for contributions to this document. on the design 1270 of NTS. 1272 10. References 1274 10.1. Normative References 1276 [I-D.ietf-ntp-cms-for-nts-message] 1277 Sibold, D., Teichel, K., Roettger, S., and R. Housley, 1278 "Protecting Network Time Security Messages with the 1279 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 1280 for-nts-message-06 (work in progress), February 2016. 1282 [I-D.ietf-ntp-extension-field] 1283 Mizrahi, T. and D. Mayer, "The Network Time Protocol 1284 Version 4 (NTPv4) Extension Fields", draft-ietf-ntp- 1285 extension-field-07 (work in progress), February 2016. 1287 [I-D.ietf-ntp-network-time-security] 1288 Sibold, D., Roettger, S., and K. Teichel, "Network Time 1289 Security", draft-ietf-ntp-network-time-security-13 (work 1290 in progress), February 2016. 1292 [I-D.ietf-tictoc-multi-path-synchronization] 1293 Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- 1294 Path Time Synchronization", draft-ietf-tictoc-multi-path- 1295 synchronization-06 (work in progress), October 2016. 1297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1298 Requirement Levels", BCP 14, RFC 2119, 1299 DOI 10.17487/RFC2119, March 1997, 1300 . 1302 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1303 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1304 September 2002, . 1306 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1307 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1308 2003, . 1310 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1311 Briscoe, "Timed Efficient Stream Loss-Tolerant 1312 Authentication (TESLA): Multicast Source Authentication 1313 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 1314 June 2005, . 1316 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1317 (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 1318 2006, . 1320 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1321 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1322 . 1324 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1325 Authenticated Encryption Using the Advanced Encryption 1326 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 1327 2008, . 1329 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1330 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1331 . 1333 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1334 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1335 March 2010, . 1337 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1338 "Transport Layer Security (TLS) Renegotiation Indication 1339 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 1340 . 1342 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1343 "Network Time Protocol Version 4: Protocol and Algorithms 1344 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1345 . 1347 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1348 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1349 January 2012, . 1351 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1352 "Transport Layer Security (TLS) Application-Layer Protocol 1353 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1354 July 2014, . 1356 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 1357 DOI 10.17487/RFC7465, February 2015, 1358 . 1360 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1361 Suite Value (SCSV) for Preventing Protocol Downgrade 1362 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 1363 . 1365 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1366 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1367 Session Hash and Extended Master Secret Extension", 1368 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1369 . 1371 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 1372 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 1373 March 2016, . 1375 10.2. Informative References 1377 [attacking-ntp] 1378 "Attacking the Network Time Protocol", October 2015. 1380 [delorean] 1381 "Bypassing HTTP Strict Transport Security", 2014. 1383 [IEC.61588_2009] 1384 IEEE/IEC, "Precision clock synchronization protocol for 1385 networked measurement and control systems", 1386 IEEE 1588-2008(E), IEC 61588:2009(E), 1387 DOI 10.1109/IEEESTD.2009.4839002, February 2009, 1388 . 1391 [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks 1392 against time synchronization protocols", in Proceedings 1393 of Precision Clock Synchronization for Measurement Control 1394 and Communication, ISPCS 2012, pp. 1-6, September 2012. 1396 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1397 "Transport Layer Security (TLS) Session Resumption without 1398 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1399 January 2008, . 1401 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1402 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1403 October 2014, . 1405 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 1406 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 1407 2016, . 1409 [Shpiner] "Multi-path Time Protocols", in Proceedings of IEEE 1410 International Symposium on Precision Clock Synchronization 1411 for Measurement, Control and Communication (ISPCS), 1412 September 2013. 1414 Appendix A. Flow Diagrams of Client Behaviour 1415 +------------------------------>o 1416 | | 1417 | v 1418 | +-------------+ 1419 | |Key Exchange | 1420 | +------+------+ 1421 | | 1422 | o<------------------------------+ 1423 | | | 1424 | v | 1425 | +-------------------+ | 1426 | |Time Sync. Messages| | 1427 | +---------+---------+ | 1428 | | | 1429 | v | 1430 | +-----+ | 1431 | |Check| | 1432 | +--+--+ | 1433 | | | 1434 | /------------------+------------------\ | 1435 | v v v | 1436 | .-----------. .-------------. .-------. | 1437 | ( MAC Failure ) ( Nonce Failure ) ( Success ) | 1438 | '-----+-----' '------+------' '---+---' | 1439 | | | | | 1440 | v v v | 1441 | +-------------+ +-------------+ +--------------+ | 1442 | |Discard Data | |Discard Data | |Sync. Process | | 1443 | +-------------+ +------+------+ +------+-------+ | 1444 | | | | | 1445 | | | v | 1446 +-----------+ +------------------>o-----------+ 1448 Figure 3: The client's behavior in NTS unicast mode. 1450 Authors' Addresses 1452 Daniel Fox Franke 1453 Akamai Technologies, Inc. 1454 150 Broadway 1455 Cambridge, MA 02142 1456 United States 1458 Email: dafranke@akamai.com 1459 URI: https://www.dfranke.us 1460 Dieter Sibold 1461 Physikalisch-Technische Bundesanstalt 1462 Bundesallee 100 1463 Braunschweig D-38116 1464 Germany 1466 Phone: +49-(0)531-592-8420 1467 Fax: +49-531-592-698420 1468 Email: dieter.sibold@ptb.de 1470 Kristof Teichel 1471 Physikalisch-Technische Bundesanstalt 1472 Bundesallee 100 1473 Braunschweig D-38116 1474 Germany 1476 Phone: +49-(0)531-592-8421 1477 Email: kristof.teichel@ptb.de