idnits 2.17.1 draft-dfranke-nts-00.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 7, 2016) is 2755 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Franke 3 Internet-Draft Akamai 4 Intended status: Standards Track October 7, 2016 5 Expires: April 10, 2017 7 Network Time Security 8 draft-dfranke-nts-00 10 Abstract 12 This memo specifies Network Time Security (NTS), a mechanism for 13 using Datagram TLS to provide cryptographic security for the Network 14 Time Protocol or other network time synchronization protocols. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 10, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 52 3. DTLS profile for Network Time Security . . . . . . . . . . . 4 53 4. Transport mechanisms for DTLS records . . . . . . . . . . . . 4 54 4.1. Transport via NTS port . . . . . . . . . . . . . . . . . 5 55 4.2. Transport via NTP extension field . . . . . . . . . . . . 5 56 5. The NTS-encapsulated NTPv4 protocol . . . . . . . . . . . . . 7 57 6. The NTS Key Establishment protocol . . . . . . . . . . . . . 7 58 6.1. NTS-KE record types . . . . . . . . . . . . . . . . . . . 9 59 6.1.1. End of Message . . . . . . . . . . . . . . . . . . . 9 60 6.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 9 61 6.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 10 63 6.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 10 64 6.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 11 65 6.2. Key Extraction (generally) . . . . . . . . . . . . . . . 11 66 7. NTS Extensions for NTPv4 . . . . . . . . . . . . . . . . . . 11 67 7.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 11 68 7.2. Packet structure overview . . . . . . . . . . . . . . . . 12 69 7.3. The Unique Identifier extension . . . . . . . . . . . . . 13 70 7.4. The NTS Cookie extension . . . . . . . . . . . . . . . . 13 71 7.5. The NTS Cookie Placeholder extension . . . . . . . . . . 14 72 7.6. The NTS Authenticator and Encrypted Extensions extension 14 73 7.7. Protocol details . . . . . . . . . . . . . . . . . . . . 15 74 8. Recommended format for NTS cookies . . . . . . . . . . . . . 17 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 79 11.2. Informative References . . . . . . . . . . . . . . . . . 24 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 83 1. Introduction 85 [[SEE https://github.com/dfoxfranke/nts FOR AN UP-TO-MINUTE DRAFT OF 86 THIS MEMO, AND https://github.com/dfoxfranke/nts/issues FOR A LIST OF 87 OUTSTANDING ISSUES.]] 89 This memo specifies Network Time Security (NTS), a mechanism for 90 using Datagram Transport Layer Security [RFC6347] (DTLS) to provide 91 cryptographic security for network time synchronization. A complete 92 specification is provided for applying NTS to the Network Time 93 Protocol [RFC5905]. Certain sections, however, are not inherently 94 NTP-specific and include guidance on how future work may apply them 95 to other time synchronization protocols such as the Precision Time 96 Protocol [IEC.61588_2009]. 98 The Network Time Protocol includes many different operating modes to 99 support various network topologies. In addition to its best-known 100 and most-widely-used client/server mode, it also includes modes for 101 synchronization between symmetric peers, a broadcast mode, and a 102 control mode for server monitoring and administration. These various 103 modes have differing and contradictory requirements for security and 104 performance. Symmetric and control modes demand mutual 105 authentication and mutual replay protection, and for certain message 106 types control mode may require confidentiality as well as 107 authentication. Client/server mode places more stringent 108 requirements on resource utilization than other modes, because 109 servers may have vast number of clients and be unable to afford to 110 maintain per-client state. However, client/server mode also has more 111 relaxed security needs, because only the client requires replay 112 protection: it is harmless for servers to process replayed packets. 114 The security demands of symmetric and control modes are in conflict 115 with the resource-utilization demands of client/server mode any 116 scheme which provides replay protection inherently involves 117 maintaining some state to keep track of what messages have already 118 been seen. Since therefore no single approach can simultaneously 119 satisfy the needs of all modes, Network Time Security consists of not 120 one protocol but a suite of them: 122 The "NTS-encapsulated NTPv4" protocol is little more than "NTP 123 over DTLS": the two endpoints perform a DTLS handshake and then 124 exchange NTP packets encapsulated as DTLS Application Data. It is 125 suitable for symmetric and control modes, and is also secure for 126 client/server mode but relatively wasteful of server resources. 128 The "NTS Key Establishment" protocol (NTS-KE) uses DTLS to 129 establish key material and negotiate some additional protocol 130 options, but then quickly closes the DTLS channel and does not use 131 it for the exchange of time packets. NTS-KE is designed to be 132 extensible, and might be extended to support key establishment for 133 other protocols such as PTP. 135 The "NTS extensions for NTPv4" are a collection of NTP extension 136 fields for cryptographically securing NTPv4 using key material 137 previously negotiated using NTS-KE. They are suitable for 138 securing client/server mode because the server can implement them 139 without retaining per-client state, but on the other hand are 140 suitable *only* for client/server mode because only the client, 141 and not the server, is protected from replay. 143 2. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 3. DTLS profile for Network Time Security 151 Since securing time protocols is (as of 2016) a novel application of 152 DTLS, no backward-compatibility concerns exist to justify using 153 obsolete, insecure, or otherwise broken DTLS features or versions. 154 We therefore put forward the following requirements and guidelines, 155 roughly representing 2016's best practices. 157 Implementations MUST NOT negotiate DTLS versions earlier than 1.2. 159 Implementations willing to negotiate more than one possible version 160 of DTLS SHOULD NOT respond to handshake failures by retrying with a 161 downgraded protocol version. If they do, they MUST implement 162 [RFC7507]. 164 DTLS clients MUST NOT offer, and DTLS servers MUST not select, RC4 165 cipher suites. [RFC7465] 167 DTLS clients SHOULD offer, and DTLS servers SHOULD accept, the TLS 168 Renegotiation Indication Extension [RFC5746]. Regardless, they MUST 169 NOT initiate or permit insecure renegotiation. (*) 171 DTLS clients SHOULD offer, and DTLS servers SHOULD accept, the TLS 172 Session Hash and Extended Master Secret Extension [RFC7627]. (*) 174 Use of the Application-Layer Protocol Negotation Extension [RFC7301] 175 is integral to NTS and support for it is REQUIRED for 176 interoperability. 178 (*): Note that DTLS 1.3 or beyond may render the indicated 179 recommendations inapplicable. 181 4. Transport mechanisms for DTLS records 183 This section specifies two mechanisms, one REQUIRED and one OPTIONAL, 184 for exchanging NTS-related DTLS records. It is intended that the 185 choice of transport mechanism be orthogonal to any concerns at the 186 application layer: DTLS records SHOULD receive identical disposition 187 regardless of which mechanism they arrive by. 189 4.1. Transport via NTS port 191 In this transport mechanism, DTLS records, formatted according to RFC 192 6347 [RFC6347] or a subsequent revision thereof, are exchanged 193 directly on UDP port [[TBD]], with one DTLS record per UDP packet and 194 no additional layer of encapsulation between the UDP header and the 195 DTLS record. Servers which implement NTS MUST support this 196 mechanism. 198 4.2. Transport via NTP extension field 200 In this transport mechanism, DTLS records are exchanged within 201 extension fields of specially-formed NTP packets, which are 202 themselves exchanged via the usual NTP service port (123/udp). NTP 203 packets conveying DTLS records SHALL be formatted as in Figure 1. 204 They MUST NOT contain any other extensions or a legacy MAC field. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 . . 211 . NTP Header (48 octets) . 212 . . 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Extension Type | Extension Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 . . 219 . DTLS Record (variable) . 220 . . 221 | | 222 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | | 224 +-+-+-+-+-+-+-+-+ + 225 | | 226 . . 227 . Padding (1-24 octets) . 228 . . 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: Format of NTP packets conveying DTLS records 234 Within the NTP header, 236 The Leap Indicator field SHALL be set to 3 (unsynchronized). 238 The Version Number field SHALL be set to 4. 240 DTLS clients SHALL set the Mode field to 3, and DTLS servers SHALL 241 set the Mode field to 4, even if the DTLS record is being used (in 242 the full-encapsulation protocol) to protect some NTP mode other 243 than client/server. 245 The Stratum field SHALL be set to 0 (unspecified or invalid). 247 The Reference ID field (conveying a kiss code) SHALL be set to 248 "DTLS" 250 DTLS servers SHALL set the origin timestamp field from the 251 transmit timestamp field of the packet most recently received from 252 the client. 254 All other header fields MUST be ignored by the receiver, and MAY 255 contain arbitrary or bogus values. 257 The Extension Type field SHALL be set to [[TBD]]. The Extension 258 Length field SHALL be computed and set as per RFC 7822 [RFC7822]. 260 The DTLS Record field SHALL contain a DTLS Record formatted as per 261 RFC 6347 [RFC6347] or a subsequent revision thereof. 263 The Padding field SHALL contain between 1 and 24 octets of padding, 264 with every octet set to the number of padding octets included, e.g., 265 "01", "02 02", or "03 03 03". The number of padding bytes should be 266 chosen in order to comply with the RFC 7822 [RFC7822] requirement 267 that (in the absence of a legacy MAC) extensions have a total length 268 in octets (including the four octets for the type and length fields) 269 which is at least 28 and divisible by 4. Furthermore, since future 270 revisions of DTLS may employ record formats that are not self- 271 delimiting, at least one octet of padding MUST be included so that 272 receivers can unambiguously determine where the DTLS record ends and 273 the padding begins. If the length of the DTLS record is already at 274 least 24 and a multiple of 4, then the correct amount of padding to 275 include is 4 octets. 277 The NTP header values specified above are selected such that NTP 278 implementations which do not understand NTS will interpret the packet 279 as an innocuous no-op and not attempt to use it for time 280 synchronization. To NTS-aware implementations, however, these 281 packets are best understood as not being NTP packets at all, but 282 simply a means of "smuggling" arbitrary DTLS records across port 123/ 283 udp. Indeed, these records need not be pertinent to NTP at all -- 284 for example, they could be NTS-KE messages eventually intended for 285 securing PTP traffic. 287 This transport mechanism is intended for use as a fallback in 288 situations where firewalls or other middleboxes are preventing 289 communication on the NTS port. Support for it is OPTIONAL. 291 5. The NTS-encapsulated NTPv4 protocol 293 The NTS-encapsulated NTPv4 protocol proceeds in two parts. First, 294 DTLS handshake records are exchanged using one of the two transport 295 mechanisms specified in Section 4. The two endpoints carry out a 296 DTLS handshake in conformance with Section 3, with the client 297 offering (via an ALPN [RFC7301] extension), and the server accepting, 298 an application-layer protocol of "ntp/4". Second, once the handshake 299 is successfully completed, the two endpoints use the established 300 channel to exchange arbitrary NTPv4 packets as DTLS-protected 301 Application Data. 303 In addition to the requirements specified in Section 3, 304 implementations MUST enforce the anti-replay mechanism specified in 305 Section 4.1.2.6 of RFC 6347 [RFC6347] (or an equivalent mechanism 306 specified in a subsequent revision of DTLS). Servers wishing to 307 enforce access control SHOULD either demand a client certificate or 308 use a PSK-based handshake in order to establish the client's 309 identity. 311 The NTS-encapsulated NTPv4 protocol is the RECOMMENDED mechanism for 312 cryptographically securing mode 1 (symmetric active), 2 (symmetric 313 passive), and 6 (control) NTPv4 traffic. It is equally safe for mode 314 3/4 (client/server) traffic, but is NOT RECOMMENDED for this purpose 315 because it scales poorly compared to using NTS Extensions for NTPv4 316 (Section 7). 318 6. The NTS Key Establishment protocol 320 The NTS Key Establishment (NTS-KE) protocol is carried out by 321 exchanging DTLS records using one of the two transport mechanisms 322 specified in Section 4. The two endpoints carry out a DTLS handshake 323 in conformance with Section 3, with the client offering (via an ALPN 324 [RFC7301] extension), and the server accepting, an application-layer 325 protocol of "ntske/1". Immediately following a successful handshake, 326 the client SHALL send a single request (as Application Data 327 encapsulated in the DTLS-protected channel), then the server SHALL 328 send a single response followed by a "Close notify" alert and then 329 discard the channel state. 331 The client's request and the server's response each SHALL consist of 332 a sequence of records formatted according to Figure 2. The sequence 333 SHALL be terminated by a "End of Message" record, which has a Record 334 Type of zero and a zero-length body. Furthermore, requests and non- 335 error responses each SHALL include exactly one NTS Next Protocol 336 Negotiation record. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |C| Record Type | Body Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 . . 345 . Record Body . 346 . . 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 2 352 [[Ed. Note: this ad-hoc binary format should be fine as long as we 353 continue to keep things very simple. However, if we think there's 354 any reasonable probability of wanting to include more complex data 355 structures, we should consider using some semi-structured data format 356 such as JSON, Protocol Buffers, or (ugh) ASN.1]] 358 The requirement that all NTS-KE messages be terminated by an End of 359 Message record makes them self-delimiting. One DTLS record MAY, and 360 typcially will, contain multiple NTS-KE records. NTS-KE records MAY 361 be split across DTLS record boundaries. If, likely due to packet 362 loss, an incomplete NTS-KE message is received, implementations MUST 363 treat this an error, which clients SHOULD handle by restarting with a 364 fresh DTLS handshake and trying again. 366 The fields of an NTS-KE record are defined as follows: 368 C (Critical Bit): Determines the disposition of unrecognized 369 Record Types. Implementations which receive a record with an 370 unrecognized Record Type MUST ignore the record if the Critical 371 Bit is 0, and MUST treat it as an error if the Critical Bit is 1. 373 Record Type: A 15-bit integer in network byte order (from most-to- 374 least significant, its bits are record bits 7-1 and then 15-8). 375 The semantics of record types 0-5 are specified in this memo; 376 additional type numbers SHALL be tracked through the IANA Network 377 Time Security Key Establishment Record Types registry. 379 Body Length: the length of the Record Body field, in octets, as a 380 16-bit integer in network byte order. Record bodies may have any 381 representable length and need not be aligned to a word boundary. 383 Record Body: the syntax and semantics of this field shall be 384 determined by the Record Type. 386 6.1. NTS-KE record types 388 The following NTS-KE Record Types are defined. 390 6.1.1. End of Message 392 The End of Message record has a Record Type number of 0 and an zero- 393 length body. It MUST occur exactly once as the final record of every 394 NTS-KE request and response. The Critical Bit MUST be set. 396 6.1.2. NTS Next Protocol Negotiation 398 The NTS Next Protocol Negotiation record has a record type of 1. It 399 MUST occur exactly once in every NTS-KE request and response. Its 400 body consists of a sequence of 16-octet strings. Each 16-octet 401 string represents a Protocol Name from the IANA Network Time Security 402 Next Protocols registry. The Critical Bit MUST be set. 404 The Protocol Names listed in the client's NTS Next Protocol 405 Negotiation record denote those protocols which the client wishes to 406 speak using the key material established through this NTS-KE session. 407 The Protocol Names listed in the server's response MUST comprise a 408 subset of those listed in the request, and denote those protocols 409 which the server is willing and able to speak using the key material 410 established through this NTS-KE session. The client MAY proceed with 411 one or more of them. The request MUST list at least one protocol, 412 but the response MAY be empty. 414 6.1.3. Error 416 The Error record has a Record Type number of 2. Its body is exactly 417 two octets long, consisting of an unsigned 16-bit integer in network 418 byte order, denoting an error code. The Critical Bit MUST be set. 420 Clients MUST NOT include Error records in their request. If clients 421 receive a server response which includes an Error record, they MUST 422 discard any negotiated key material and MUST NOT proceed to the Next 423 Protocol. 425 The following error code are defined. 427 Error code 0 means "Unrecognized Critical Record". The server 428 MUST respond with this error code if the request included a record 429 which the server did not understand and which had its Critical Bit 430 set. The client SHOULD NOT retry its request without 431 modification. 433 Error code 1 means "Bad Request". The server MUST respond with 434 this error if, upon the expiration of an implementation-defined 435 timeout, it has not yet received a complete and syntactically 436 well-formed request from the client. This error is likely to be 437 the result of a dropped packet, so the client SHOULD start over 438 with a new DTLS handshake and retry its request. 440 6.1.4. Warning 442 The Warning record has a Record Type number of 3. Its body is 443 exactly two octets long, consisting of an unsigned 16-bit integer in 444 network byte order, denoting a warning code. The Critical Bit MUST 445 be set. 447 Clients MUST NOT include Warning records in their request. If 448 clients receive a server response which includes an Warning record, 449 they MAY discard any negotiated key material and abort without 450 proceeding to the Next Protocol. Unrecognized warning codes MUST be 451 treated as errors. 453 This memo defines no warning codes. 455 6.1.5. AEAD Algorithm Negotiation 457 The AEAD Algorithm Negotiation record has a Record Type number of 4. 458 Its body consists of a sequence of unsigned 16-bit integers in 459 network byte order, denoting Numeric Identifiers from the IANA AEAD 460 registry [RFC5116]. The Critical Bit MAY be set. 462 If the NTS Next Protocol Negotiation record offers "ntp/4",this 463 record MUST be included exactly once. Other protocols MAY require it 464 as well. 466 When included in a request, this record denotes which AEAD algorithms 467 the client is willing to use to secure the Next Protocol, in 468 decreasing preference order. When included in a response, this 469 record denotes which algorithm the server chooses to use, or is empty 470 if the server supports none of the algorithms offered.. In requests, 471 the list MUST include at least one algorithm. In responses, it MUST 472 include at most one. Honoring the client's preference order is 473 OPTIONAL: servers may select among any of the client's offered 474 choices, even if they are able to support some other algorithm which 475 the client prefers more. 477 Server implementations of NTS extensions for NTPv4 (Section 7) MUST 478 support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). 479 That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD 480 Algorithm Negotiation record, and the server accepts the "ntp/4" 481 protocol in its NTS Next Protocol Negotiation record, then the 482 server's AEAD Algorithm Negotation record MUST NOT be empty. 484 6.1.6. New Cookie for NTPv4 486 The New Cookie for NTPv4 record has a Record Type number of 5. The 487 contents of its body SHALL be implementation-defined and clients MUST 488 NOT attempt to interpret them. See [[TODO]] for a RECOMMENDED 489 construction. 491 Clients MUST NOT send records of this type. Servers MUST send at 492 least one record of this type, and SHOULD send eight of them, if they 493 accept "ntp/4" as a Next Protocol. The Critical Bit SHOULD NOT be 494 set. 496 [[Ed. Note: the purpose of sending eight cookies is to allow the 497 client to recover from dropped packets without reusing cookies or 498 starting a new handshake. Discussion of cookie management should 499 probably be broken out into its own section.]] 501 6.2. Key Extraction (generally) 503 Following a successful run of the NTS-KE protocol, key material SHALL 504 be extracted according to RFC 5705 [RFC5705]. Inputs to the exporter 505 function are to be constructed in a manner specific to the negotiated 506 Next Protocol. However, all protocols which utilize NTS-KE MUST 507 conform to the following two rules: 509 The disambiguating label string MUST be "EXPORTER-network-time- 510 security/1". 512 The per-association context value MUST be provided, and MUST begin 513 with the 16-octet Protocol Name which was negotiated as a Next 514 Protocol. 516 7. NTS Extensions for NTPv4 518 7.1. Key Extraction (for NTPv4) 520 Following a successful run of the NTS-KE protocol wherein "ntp/4" is 521 selected as a Next Protocol, two AEAD keys SHALL be extracted: a 522 client-to-server (C2S) key and a server-to-client (S2C) key. These 523 keys SHALL be computed according to RFC 5705 [RFC5705], using the 524 following inputs. 526 The disambiguating label string SHALL be "EXPORTER-network-time- 527 security/1". 529 The per-association context value SHALL consist of the following 530 19 octets: 532 The first 16 octets SHALL be (in hexadecimal): 534 6E 74 70 2F 34 00 00 00 00 00 00 00 00 00 00 00 536 The next two octets SHALL be the Numeric Identifier of the 537 negotiated AEAD Algorithm, in network byte order. 539 The final octet SHALL be 0x00 for the C2S key and 0x01 for the 540 S2C key. 542 Implementations wishing to derive additional keys for private or 543 experimental use MUST NOT do so by extending the above-specified 544 syntax for per-association context values. Instead, they SHOULD use 545 their own disambiguating label string. Note that RFC 5705 provides 546 that disambiguating label strings beginning with "EXPERIMENTAL" MAY 547 be used without IANA registration. 549 7.2. Packet structure overview 551 In general, an NTS-protected NTPv4 packet consists of: 553 The usual 48-octet NTP header, which is authenticated but not 554 encrypted. 556 Some extensions which are authenticated but not encrypted. 558 An NTS extension which contains AEAD output (i.e., an 559 authentication tag and possible ciphertext). The corresponding 560 plaintext, if non-empty, consists of some extensions which benefit 561 from both encryption and authentication. 563 Possibly, some additional extensions which are neither encrypted 564 nor authenticated. These are discarded by the receiver. [[Ed. 565 Note: right now there's no good reason for the sender to include 566 anything here, but eventually there might be. We've seen Checksum 567 Complement [RFC7821] and LAST-EF as two examples of semantically- 568 void extensions that are included to satsify constraints imposed 569 lower on the protocol stack, and while there's no reason to use 570 either of these on NTS-protected packets, I think we could see 571 similar examples in the future. So, rejecting packets with 572 unauthenticated extensions could cause interoperability problems, 573 while accepting and processing those extensions would of course be 574 a security risk. Thus, I think "allow and discard" is the correct 575 policy.]] 577 Always included among the authenticated or authenticated-and- 578 encrypted extensions are a cookie extension and a unique-identifier 579 extension. The purpose of the cookie extension is to enable the 580 server to offload storage of session state onto the client. The 581 purpose of the unique-identifier extension is to protect the client 582 from replay attacks. 584 7.3. The Unique Identifier extension 586 The Unique Identifier extension has a Field Type of [[TBD]]. When 587 the extension is included in a client packet (mode 3), its body SHALL 588 consist of a string of octets generated uniformly at random. The 589 string SHOULD be 32 octets long. When the extension is included in a 590 server packet (mode 4), its body SHALL contain the same octet string 591 as was provided in the client packet to which the server is 592 responding. Its use in modes other than client/server is not 593 defined. 595 The Unique Identifier extension provides the client with a 596 cryptographically strong means of detecting replayed packets. It may 597 also be used standalone, without NTS, in which case it provides the 598 client with a means of detecting spoofed packets from off-path 599 attackers. Historically, NTP's origin timestamp field has played 600 both these roles, but for cryptographic purposes this is suboptimal 601 because it is only 64 bits long and, depending on implementation 602 details, most of those bits may be predictable. In contrast, the 603 Unique Identifier extension enables a degree of unpredictability and 604 collision-resistance more consistent with cryptographic best 605 practice. 607 [[TODO: consider using separate extension types for request and 608 response, thus allowing for use in symmetric mode. But proper 609 handling in the presence of dropped packets needs to be documented 610 and involves a lot of subtlety.]] 612 7.4. The NTS Cookie extension 614 The NTS Cookie extension has a Field Type of [[TBD]]. Its purpose is 615 to carry information which enables the server to recompute keys and 616 other session state without having to store any per-client state. 617 The contents of its body SHALL be implementation-defined and clients 618 MUST NOT attempt to interpret them. See [[TODO]] for a RECOMMENDED 619 construction. The NTS Cookie extension MUST NOT be included in NTP 620 packets whose mode is other than 3 (client) or 4 (server). 622 7.5. The NTS Cookie Placeholder extension 624 The NTS Cookie Placeholder extension has a Field Type of [[TBD]]. 625 When this extension is included in a client packet (mode 3), it 626 communicates to the server that the client wishes it to send 627 additional cookies in its response. This extension MUST NOT be 628 included in NTP packets whose mode is other than 3. 630 Whenever an NTS Cookie Placeholder extension is present, it MUST be 631 accompanied by an NTS Cookie extension, and the body length of the 632 NTS Cookie Placeholder extension MUST be the same as the body length 633 of the NTS Cookie Extension. (This length requirement serves to 634 ensure that the response will not be larger than the request, in 635 order to improve timekeeping precision and prevent DDoS 636 amplification). The contents of the NTS Cookie Placeholder 637 extension's body are undefined and, aside from checking its length, 638 MUST be ignored by the server. 640 7.6. The NTS Authenticator and Encrypted Extensions extension 642 The NTS Authenticator and Encrypted Extensions extension is the 643 central cryptographic element of an NTS-protected NTP packet. Its 644 Field Type is [[TBD]] and the format of its body SHALL be as follows: 646 Nonce length: two octets in network byte order, giving the length 647 of the Nonce field. 649 Nonce: a nonce as required by the negotiated AEAD Algorithm. 651 Ciphertext: the output of the negotiated AEAD Algorithm. The 652 structure of this field is determined by the negotiated algorithm, 653 but it typically contains an authentication tag in addition to the 654 actual ciphertext. 656 Padding: between 1 and 24 octets of padding, with every octet set 657 to the number of padding octets included, e.g., "01", "02 02", or 658 "03 03 03". The number of padding bytes should be chosen in order 659 to comply with the RFC 7822 [RFC7822] requirement that (in the 660 absence of a legacy MAC) extensions have a total length in octets 661 (including the four octets for the type and length fields) which 662 is at least 28 and divisible by 4. At least one octet of padding 663 MUST be included, so that implementations can unambiguously 664 delimit the end of the ciphertext from the start of the padding. 666 The Ciphertext field SHALL be formed by providing the following 667 inputs to the negotiated AEAD Algorithm: 669 K: For packets sent from the client to the server, the C2S key 670 SHALL be used. For packets sent from the server to the client, 671 the S2C key SHALL be used. 673 A: The associated data SHALL consist of the portion of the NTP 674 packet beginning from the start of the NTP header and ending at 675 the end of the last extension which precedes the NTS Authenticator 676 and Encrypted Extensions extension. 678 P: The plaintext SHALL consist of all (if any) extensions to be 679 encrypted. 681 N: The nonce SHALL be formed however required by the negotiated 682 AEAD Algorithm. 684 The NTS Authenticator and Encrypted Extensions extension MUST NOT be 685 included in NTP packets whose mode is other than 3 (client) or 4 686 (server). 688 7.7. Protocol details 690 A client sending an NTS-protected request SHALL include the following 691 extensions: 693 Exactly one Unique Identifier extension, which MUST be 694 authenticated and MUST NOT be encrypted [[Ed. Note: so that if 695 the server can't decrypt the request, it can still echo back the 696 Unique Identifier in the NTS NAK it sends]]. MUST NOT duplicate 697 those of any previous request. 699 Exactly one NTS Cookie extension, which MUST be authenticated and 700 MUST NOT be encrypted. The cookie MUST be one which the server 701 previously provided the client; it may have been provided during 702 the NTS-KE handshake or in response to a previous NTS-protected 703 NTP request. To protect client's privacy, the same cookie SHOULD 704 NOT be included in multiple requests. If the client does not have 705 any cookies that it has not already sent, it SHOULD re-run the 706 NTS-KE protocol before continuing. 708 Exactly one NTS Authenticator and Encrypted Extensions extension, 709 generated using an AEAD Algorithm and C2S key established through 710 NTS-KE. 712 The client MAY include one or more NTS Cookie Placeholder extensions, 713 which MUST be authenticated and MAY be encrypted. The number of NTS 714 Cookie Placeholder extensions that the client includes SHOULD be such 715 that if the client includes N placeholders and the server sends back 716 N+1 cookies, the number of unused cookies stored by the client will 717 come to eight. When both the client and server adhere to all cookie- 718 management guidance provided in this memo, the number of placeholder 719 extensions will equal the number of dropped packets since the last 720 successful volley. 722 The client MAY include additional (non-NTS-related) extensions, which 723 MAY appear prior to the NTS Authenticator and Encrypted Extensions 724 extension (therefore authenticated but not encrypted), within it 725 (therefore encrypted and authenticated), or after it (therefore 726 neither encrypted nor authenticated). In general, however, the 727 server MUST discard any unauthenticated extensions and process the 728 packet as though they were not present. Servers MAY implement 729 exceptions to this requirement for particular extensions if their 730 specification explicitly provides for such. 732 Upon receiving an NTS-protected request, the server SHALL (through 733 some implementation-defined mechanism) use the cookie to recover the 734 AEAD Algorithm, C2S key, and S2C key associated with the request, and 735 then use the C2S key to authenticate the packet and decrypt the 736 ciphertext. If the cookie is valid and authentication and decryption 737 succeed, then the server SHALL include the following extensions in 738 its response: 740 Exactly one Unique Identifier extension, which MUST be 741 authenticated, MUST NOT be encrypted, and whose contents SHALL 742 echo those provided by the client. 744 Exactly one NTS Authenticator and Encrypted Extensions extension, 745 generated using the AEAD algorithm and S2C key recovered from the 746 cookie provided by the client. 748 One or more NTS Cookie extensions, which MUST be authenticated and 749 encrypted. The number of NTS Cookie extensions included SHOULD be 750 equal to, and MUST NOT exceed, one plus the number of valid NTS 751 Cookie Placeholder extensions included in the request. 753 The server MAY include additional (non-NTS-related) extensions, which 754 MAY appear prior to the NTS Authenticator and Encrypted Extensions 755 extension (therefore authenticated but not encrypted), within it 756 (therefore encrypted and authenticated), or after it (therefore 757 neither encrypted nor authenticated). In general, however, the 758 client MUST discard any unauthenticated extensions and process the 759 packet as though they were not present. Clients MAY implement 760 exceptions to this requirement for particular extensions if their 761 specification explicitly provides for such. 763 If the server is unable to validate the cookie or authenticate the 764 request, it SHOULD respond with a Kiss-o'-Death packet (see RFC 5905, 765 Section 7.4) [RFC5905]) with kiss code "NTSN" (meaning "NTS NAK"). 766 Such a response MUST include exactly one Unique Identifier extension 767 whose contents SHALL echo those provided by the client. It MUST NOT 768 include any NTS Cookie or NTS Authenticator and Encrypted Extensions 769 extension. [[Ed. Note: RFC 5905 already provides the kiss code 770 "CRYP" meaning "Cryptographic authentication or identification 771 failed" but I think this is meant to be Autokey-specific.]] 773 Upon receiving an NTS-protected response, the client MUST verify that 774 the Unique Identifier matches that of an outstanding request, and 775 that the packet is authentic under the S2C key associated with that 776 request. If either of these checks fails, the packet MUST be 777 discarded without further processing. 779 Upon receiving an NTS NAK, the client MUST verify that the Unique 780 Identifier matches that of an outstanding request. If this check 781 fails, the packet MUST be discarded without further processing. If 782 this check passes, the client SHOULD discard all cookies and AEAD 783 keys associated with the server which sent the NAK and initiate a 784 fresh NTS-KE handshake. 786 8. Recommended format for NTS cookies 788 This section provides a RECOMMENDED way for servers to construct NTS 789 cookies. Clients MUST NOT examine the cookie under the assumption 790 that it is constructed according to this section. 792 The role of cookies in NTS is closely analagous to that of session 793 cookies in TLS. Accordingly, the thematic resemblance of this 794 section to RFC 5077 [RFC5077] is deliberate, and the reader should 795 likewise take heed of its security considerations. 797 Servers should select an AEAD algorithm which they will use to 798 encrypt and authenticate cookies. The chosen algorithm should be one 799 such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidential 800 nonce reuse, and it need not be the same as the one that was 801 negotiated with the client. Servers should randomly generate and 802 store a master AEAD key `K`. Servers should additionally choose a 803 non-secret, unique value `I` as key-identifier for `K`. 805 Servers should periodically (e.g., once daily) generate a new pair 806 (I,K) and immediately switch to using these values for all newly- 807 generated cookies. Immediately following each such key rotation, 808 servers should securely erase any keys generated two or more rotation 809 periods prior. Servers should continue to accept any cookie 810 generated using keys that they have not yet erased, even if those 811 keys are no longer current. Erasing old keys provides for forward 812 secrecy, limiting the scope of what old information can be stolen if 813 a master key is somehow compromised. Holding on to a limited number 814 of old keys allows clients to seamlessly transition from one 815 generation to the next without having to perform a new NTS-KE 816 handshake. 818 [[TODO: discuss key management considerations for load-balanced 819 servers]] 821 To form a cookie, servers should first form a plaintext `P` 822 consisting of the following fields: 824 The AEAD algorithm negotiated during NTS-KE 826 The S2C key 828 The C2S key 830 Servers should the generate a nonce `N` uniformly at random, and form 831 AEAD output `C` by encrypting `P` under key `K` with nonce `N` and no 832 associated data. 834 The cookie should consist of the tuple `(I,N,C)`. 836 [[TODO: explicitly specify how to verify and decrypt a cookie, not 837 just how to form one]] 839 9. Security Considerations 841 [[TODO. Outline follows.]] 843 Cite RFC 7384 [RFC7384] for general considerations. 845 State security goals (authentication (defined in terms of 846 agreement), client privacy) and threat model (active network 847 adversary). 849 Incorporate content from "What Makes NTP Cryptographically 850 Exceptional?" of NTS design essay. 852 Address strategies for management of AEAD nonces and stress 853 importance of avoiding repetition. 855 Give recommendations for validating X.509 certificates during the 856 DTLS handshake. Discuss what to expect for the CN/SANs, and how 857 to deal with verifying the validity period if correct time is not 858 yet known. 860 Caution that NTS will not prevent an adversary from skewing time 861 by up to MAXDIST/2 and discuss why this limitation is fundamental. 863 Possibly include informal security proofs. 865 10. IANA Considerations 867 IANA is requested to allocate an entry in the Service Name and 868 Transport Protocol Port Number Registry as follows: 870 Service Name: nts 872 Transport Protocol: udp 874 Assignee: IESG 876 Contact: IETF Chair 878 Description: Network Time Security 880 Reference: [[this memo]] 882 Port Number: selected by IANA from the user port range 884 IANA is requested to allocate the following two entries in the 885 Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: 887 Protocol: Network Time Security Key Establishment, version 1 889 Identification Sequence: 890 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1") 892 Reference: [[this memo]] 894 Protocol: Network Time Protocol, version 4 896 Identification Sequence: 897 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4") 899 Reference: [[this memo]] 901 IANA is requested to allocate the following entry in the TLS Exporter 902 Label Registry: 904 +----------------------------------+---------+---------------+------+ 905 | Value | DTLS-OK | Reference | Note | 906 +----------------------------------+---------+---------------+------+ 907 | EXPORTER-network-time-security/1 | Y | [[this memo]] | | 908 +----------------------------------+---------+---------------+------+ 910 IANA is requested to allocate the following entries in the registry 911 of NTP Kiss-o'-Death codes: 913 +------+------------------------------+ 914 | Code | Meaning | 915 +------+------------------------------+ 916 | DTLS | Packet conveys a DTLS record | 917 | | | 918 | NTSN | NTS NAK | 919 +------+------------------------------+ 921 IANA is requested to allocate the following entries in the NTP 922 Extensions Field Types registry: 924 +------------+---------------------------------------+--------------+ 925 | Field Type | Meaning | Reference | 926 +------------+---------------------------------------+--------------+ 927 | [[TBD]] | DTLS Record | [[this | 928 | | | memo]] | 929 | | | | 930 | [[TBD]] | Unique Identifier | [[this | 931 | | | memo]] | 932 | | | | 933 | [[TBD]] | NTS Cookie | [[this | 934 | | | memo]] | 935 | | | | 936 | [[TBD]] | NTS Cookie Placeholder | [[this | 937 | | | memo]] | 938 | | | | 939 | [[TBD]] | NTS Authenticator and Encrypted | [[this | 940 | | Extensions | memo]] | 941 +------------+---------------------------------------+--------------+ 943 IANA is requested to create a new registry entitled "Network Time 944 Security Key Establishment Record Types". Entries SHALL have the 945 following fields: 947 Type Number (REQUIRED): An integer in the range 0-32767 inclusive 949 Description (REQUIRED): short text description of the purpose of 950 the field 951 Set Critical Bit (REQUIRED): One of "MUST", "SHOULD", "MAY", 952 "SHOULD NOT", or "MUST NOT" 954 Reference (REQUIRED): A reference to a document specifying the 955 semantics of the record. 957 The policy for allocation of new entries in this registry SHALL vary 958 by the Type Number, as follows: 960 0-1023: Standards Action 962 1024-16383: Specification Required 964 16384-32767: Private and Experimental Use 966 Applications for new entries SHALL specify the contents of the 967 Description, Set Critical Bit and Reference fields and which of the 968 above ranges the Type Number should be allocated from. Applicants 969 MAY request a specific Type Number, and such requests MAY be granted 970 at the registrar's discretion. 972 The initial contents of this registry SHALL be as follows: 974 +-------------+-----------------------------+----------+------------+ 975 | Field | Description | Critical | Reference | 976 | Number | | | | 977 +-------------+-----------------------------+----------+------------+ 978 | 0 | End of message | MUST | [[this | 979 | | | | memo]] | 980 | | | | | 981 | 1 | NTS next protocol | MUST | [[this | 982 | | negotiation | | memo]] | 983 | | | | | 984 | 2 | Error | MUST | [[this | 985 | | | | memo]] | 986 | | | | | 987 | 3 | Warning | MUST | [[this | 988 | | | | memo]] | 989 | | | | | 990 | 4 | AEAD algorithm negotation | MAY | [[this | 991 | | | | memo]] | 992 | | | | | 993 | 5 | New cookie for NTPv4 | SHOULD | [[this | 994 | | | NOT | memo]] | 995 | | | | | 996 | 16384-32767 | Reserved for Private & | MAY | [[this | 997 | | Experimental Use | | memo]] | 998 +-------------+-----------------------------+----------+------------+ 999 IANA is requested to create a new registry entitled "Network Time 1000 Security Next Protocols". Entries SHALL have the following fields: 1002 Protocol Name (REQUIRED): a sequence of 16 octets. Shorter 1003 sequences SHALL implicitly be right-padded with null octets 1004 (0x00). 1006 Human-Readable Name (OPTIONAL): if the sequence of octets making 1007 up the protocol name intentionally represent a valid UTF-8 1008 [RFC3629] string, this field SHALL consist of that string. 1010 Reference (RECOMMENDED): a reference to a relevant specification 1011 document. If no relevant document exists, a point-of-contact for 1012 questions regarding the entry SHOULD be listed here in lieu. 1014 Applications for new entries in this registry SHALL specify all 1015 desired fields, and SHALL be granted on a First Come, First Serve 1016 basis. Protocol Names beginning with 0x78 0x2D ("x-") SHALL be 1017 reserved for Private or Experimental Use, and SHALL NOT be 1018 registered. The reserved entry "ptp/2" may be updated or released by 1019 a future Standards Action. 1021 The initial contents of this registry SHALL be as follows: 1023 +---------------------------+-----------------+---------------------+ 1024 | Protocol Name | Human-Readable | Reference | 1025 | | Name | | 1026 +---------------------------+-----------------+---------------------+ 1027 | 0x6E 0x74 0x70 0x2F 0x34 | ntp/4 | [[this memo]] | 1028 | | | | 1029 | 0x70 0x74 0x70 0x2F 0x32 | ptp/2 | Reserved by [[this | 1030 | | | memo]] | 1031 +---------------------------+-----------------+---------------------+ 1033 IANA is requested to create two new registries entitled "Network Time 1034 Security Error Codes" and "Network Time Security Warning Codes". 1035 Entries in each SHALL have the following fields: 1037 Number (REQUIRED): a 16-bit unsigned integer 1039 Description (REQUIRED): a short text description of the condition. 1041 Reference (REQUIRED): a reference to a relevant specification 1042 document. 1044 The policy for allocation of new entries in these registries SHALL 1045 vary by their Number, as follows: 1047 0-1023: Standards Action 1049 1024-32767: Specification Required 1051 32768-65535: Private and Experimental Use 1053 The initial contents of the Network Time Security Error Codes 1054 Registry SHALL be as follows: 1056 +--------+---------------------------------+---------------+ 1057 | Number | Description | Reference | 1058 +--------+---------------------------------+---------------+ 1059 | 0 | Unrecognized Critical Extension | [[this memo]] | 1060 | | | | 1061 | 1 | Bad Request | [[this memo]] | 1062 +--------+---------------------------------+---------------+ 1064 The Network Time Security Warning Codes Registry SHALL initially be 1065 empty. 1067 11. References 1069 11.1. Normative References 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, 1073 DOI 10.17487/RFC2119, March 1997, 1074 . 1076 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1077 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1078 2003, . 1080 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1081 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1082 . 1084 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1085 Authenticated Encryption Using the Advanced Encryption 1086 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 1087 2008, . 1089 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1090 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1091 March 2010, . 1093 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1094 "Transport Layer Security (TLS) Renegotiation Indication 1095 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 1096 . 1098 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1099 "Network Time Protocol Version 4: Protocol and Algorithms 1100 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1101 . 1103 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1104 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1105 January 2012, . 1107 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 1108 DOI 10.17487/RFC7465, February 2015, 1109 . 1111 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1112 Suite Value (SCSV) for Preventing Protocol Downgrade 1113 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 1114 . 1116 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1117 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1118 Session Hash and Extended Master Secret Extension", 1119 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1120 . 1122 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1123 "Transport Layer Security (TLS) Application-Layer Protocol 1124 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1125 July 2014, . 1127 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 1128 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 1129 March 2016, . 1131 11.2. Informative References 1133 [IEC.61588_2009] 1134 IEEE/IEC, "Precision clock synchronization protocol for 1135 networked measurement and control systems", 1136 IEEE 1588-2008(E), IEC 61588:2009(E), 1137 DOI 10.1109/IEEESTD.2009.4839002, February 2009, 1138 . 1141 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1142 "Transport Layer Security (TLS) Session Resumption without 1143 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1144 January 2008, . 1146 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1147 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1148 October 2014, . 1150 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 1151 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 1152 2016, . 1154 Appendix A. Acknowledgements 1156 The author gratefully acknowledges the following contributors: 1157 Richard Barnes, Prof. Sharon Goldberg, Miroslav Lichvar, Aanchal 1158 Malhotra, Danny Mayer, Karen O'Donoghue, Eric K. Rescorla, Stephen 1159 Roettger, Kyle Rose, Rich Salz, Dieter Sibold, Brian Sniffen, Susan 1160 Sons, Douglas Stebila, Harlan Stenn, Kristof Teichel, and Martin 1161 Thomson. 1163 Author's Address 1165 Daniel Fox Franke 1166 Akamai Technologies, Inc. 1167 150 Broadway 1168 Cambridge, MA 02142 1169 United States 1171 Email: dafranke@akamai.com 1172 URI: https://www.dfranke.us