idnits 2.17.1 draft-ietf-ntp-roughtime-05.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 May 2021) is 1071 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Malhotra 3 Internet-Draft Boston University 4 Intended status: Informational A. Langley 5 Expires: 21 November 2021 Google 6 W. Ladd 7 Cloudflare 8 M. Dansarie 9 20 May 2021 11 Roughtime 12 draft-ietf-ntp-roughtime-05 14 Abstract 16 This document specifies Roughtime - a protocol that aims to achieve 17 rough time synchronization while detecting servers that provide 18 inaccurate time and providing cryptographic proof of their 19 malfeasance. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 21 November 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 57 4. The Guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1.1. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1.1. VER . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1.2. NONC . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.2.1. SIG . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.2.2. VER . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6.2.3. NONC . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2.4. PATH . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2.5. SREP . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.2.6. CERT . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.2.7. INDX . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 12 79 6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 12 80 6.4. Validity of Response . . . . . . . . . . . . . . . . . . 13 81 7. Integration Into NTP . . . . . . . . . . . . . . . . . . . . 13 82 8. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 14 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 11.1. Service Name and Transport Protocol Port Number 87 Registry . . . . . . . . . . . . . . . . . . . . . . . . 14 88 11.2. Roughtime Version Registry . . . . . . . . . . . . . . . 15 89 11.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 15 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 14.2. Informative References . . . . . . . . . . . . . . . . . 19 95 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 Time synchronization is essential to Internet security as many 101 security protocols and other applications require synchronization 102 [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as 103 the Network Time Protocol (NTP) [RFC5905] lack essential security 104 features, and even newer protocols like Network Time Security (NTS) 105 [RFC8915] lack mechanisms to ensure that the servers behave 106 correctly. Authenticating time servers prevents network adversaries 107 from modifying time packets, but an authenticated time server still 108 has full control over the contents of the time packet and may 109 transmit incorrect time. The Roughtime protocol provides 110 cryptographic proof of malfeasance, enabling clients to detect and 111 prove to a third party a server's attempts to influence the time a 112 client computes. 114 +==============+======================+=============================+ 115 | Protocol | Authenticated Server | Server Malfeasance Evidence | 116 +==============+======================+=============================+ 117 | NTP, | N | N | 118 | Chronos | | | 119 +--------------+----------------------+-----------------------------+ 120 | NTP-MAC | Y* | N | 121 +--------------+----------------------+-----------------------------+ 122 | NTP-Autokey | Y** | N | 123 +--------------+----------------------+-----------------------------+ 124 | NTS | Y | N | 125 +--------------+----------------------+-----------------------------+ 126 | Roughtime | Y | Y | 127 +--------------+----------------------+-----------------------------+ 129 Table 1: Security Properties of current protocols. 131 Y* For security issues with symmetric-key based NTP-MAC 132 authentication, please refer to RFC 8573 [RFC8573]. 134 Y** For security issues with Autokey Public Key Authentication, refer 135 to [Autokey]. 137 * If a server's timestamps do not fit into the time context of other 138 servers' responses, then a Roughtime client can cryptographically 139 prove this misbehavior to third parties. This helps detect 140 dishonest or malfunctioning servers. 142 * A Roughtime client can roughly detect (with no absolute guarantee) 143 a delay attack [DelayAttacks] but can not cryptographically prove 144 this to a third party. However such attacks expand the round trip 145 time between request and response. 147 * Note that delay attacks cannot be detected/stopped by any 148 protocol. Delay attacks can not, however, undermine the security 149 guarantees provided by Roughtime. 151 * Although delay attacks cannot be prevented, they can be limited to 152 a predetermined upper bound. This can be done by defining a 153 maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a 154 Roughtime client is willing to accept. A Roughtime client can 155 measure the RTT of every request-response handshake and compare it 156 to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding 157 measurement is discarded. When this approach is used, the maximal 158 time error that can be caused by a delay attack is MAX-RTT/2. It 159 should be noted that this approach assumes that the nature of the 160 system is known to the client, including reasonable upper bounds 161 on the RTT value. 163 2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in 168 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 3. Protocol Overview 173 Roughtime is a protocol for rough time synchronization that enables 174 clients to provide cryptographic proof of server malfeasance. It 175 does so by having responses from servers include a signature over a 176 value derived from a nonce in the client request. This provides 177 cryptographic proof that the timestamp was issued after the server 178 received the client's request. The derived value included in the 179 server's response is the root of a Merkle tree which includes the 180 hash of the client's nonce as the value of one of its leaf nodes. 181 This enables the server to amortize the relatively costly signing 182 operation over a number of client requests. 184 Single server mode: At its most basic level, Roughtime is a one round 185 protocol in which a completely fresh client requests the current time 186 and the server sends a signed response. The response includes a 187 timestamp and a radius used to indicate the server's certainty about 188 the reported time. For example, a radius of 1,000,000 microseconds 189 means the server is absolutely confident that the true time is within 190 one second of the reported time. 192 The server proves freshness of its response as follows. The client's 193 request contains a nonce which the server incorporates into its 194 signed response. The client can verify the server's signatures and - 195 provided that the nonce has sufficient entropy - this proves that the 196 signed response could only have been generated after the nonce. 198 4. The Guarantee 200 A Roughtime server guarantees that a response to a query sent at t_1, 201 received at t_2, and with timestamp t_3 has been created between the 202 transmission of the query and its reception. If t_3 is not within 203 that interval, a server inconsistency may be detected and used to 204 impeach the server. The propagation of such a guarantee and its use 205 of type synchronization is discussed in Section 7. No delay attacker 206 may affect this: they may only expand the interval between t_1 and 207 t_2, or of course stop the measurement in the first place. 209 5. Message Format 211 Roughtime messages are maps consisting of one or more (tag, value) 212 pairs. They start with a header, which contains the number of pairs, 213 the tags, and value offsets. The header is followed by a message 214 values section which contains the values associated with the tags in 215 the header. Messages MUST be formatted according to Figure 1 as 216 described in the following sections. 218 Messages MAY be recursive, i.e. the value of a tag can itself be a 219 Roughtime message. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Number of pairs (uint32) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 . . 228 . N-1 offsets (uint32) . 229 . . 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 . . 234 . N tags (uint32) . 235 . . 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 . . 240 . Values . 241 . . 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1: Roughtime Message Format 247 5.1. Data Types 249 5.1.1. int32 251 An int32 is a 32 bit signed integer. It is serialized least 252 significant byte first in sign-magnitude representation with the sign 253 bit in the most significant bit. The negative zero value 254 (0x80000000) MUST NOT be used and any message with it is 255 syntactically invalid and MUST be ignored. 257 5.1.2. uint32 259 A uint32 is a 32 bit unsigned integer. It is serialized with the 260 least significant byte first. 262 5.1.3. uint64 264 A uint64 is a 64 bit unsigned integer. It is serialized with the 265 least significant byte first. 267 5.1.4. Tag 269 Tags are used to identify values in Roughtime messages. A tag is a 270 uint32 but may also be listed in this document as a sequence of up to 271 four ASCII characters [RFC0020]. ASCII strings shorter than four 272 characters can be unambiguously converted to tags by padding them 273 with zero bytes. For example, the ASCII string "NONC" would 274 correspond to the tag 0x434e4f4e and "PAD" would correspond to 275 0x00444150. Note that when encoded into a message the ASCII values 276 will be in the corresponding order. 278 5.1.5. Timestamp 280 A timestamp is a uint64 interpreted in the following way. The most 281 significant 3 bytes contain the integer part of a Modified Julian 282 Date (MJD). The least significant 5 bytes is a count of the number 283 of microseconds since midnight on that day. 285 The MJD is the number of UTC days since 17 November 1858 286 [ITU-R_TF.457-2]. It is useful to note that 1 January 1970 is 40,587 287 days after 17 November 1858. 289 Note that, unlike NTP, this representation does not use the full 290 number of bits in the fractional part and that days with leap seconds 291 will have more or fewer than the nominal 86,400,000,000 microseconds. 293 5.2. Header 295 All Roughtime messages start with a header. The first four bytes of 296 the header is the uint32 number of tags N, and hence of (tag, value) 297 pairs. The following 4*(N-1) bytes are offsets, each a uint32. The 298 last 4*N bytes in the header are tags. 300 Offsets refer to the positions of the values in the message values 301 section. All offsets MUST be multiples of four and placed in 302 increasing order. The first post-header byte is at offset 0. The 303 offset array is considered to have a not explicitly encoded value of 304 0 as its zeroth entry. The value associated with the ith tag begins 305 at offset[i] and ends at offset[i+1]-1, with the exception of the 306 last value which ends at the end of the message. Values may have 307 zero length. 309 Tags MUST be listed in the same order as the offsets of their values 310 and MUST also be sorted in ascending order by numeric value. A tag 311 MUST NOT appear more than once in a header. 313 6. Protocol Details 315 As described in Section 3, clients initiate time synchronization by 316 sending requests containing a nonce to servers who send signed time 317 responses in return. Roughtime packets can be sent between clients 318 and servers either as UDP datagrams or via TCP streams. Servers 319 SHOULD support the UDP transport mode, while TCP transport is 320 OPTIONAL. 322 A Roughtime packet MUST be formatted according to Figure 2 and as 323 described here. The first field is a uint64 with the value 324 0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a 325 uint32 and contains the length of the third field. The third and 326 last field contains a Roughtime message as specified in Section 5.1. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | 0x4d49544847554f52 (uint64) | 332 | ("ROUGHTIM") | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Message length (uint32) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 . . 338 . Roughtime message . 339 . . 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 2: Roughtime Packet Format 345 Roughtime request and response packets MUST be transmitted in a 346 single datagram when the UDP transport mode is used. Setting the 347 packet's don't fragment bit [RFC0791] is OPTIONAL in IPv4 networks. 349 Multiple requests and responses can be exchanged over an established 350 TCP connection. Clients MAY send multiple requests at once and 351 servers MAY send responses out of order. The connection SHOULD be 352 closed by the client when it has no more requests to send and has 353 received all expected responses. Either side SHOULD close the 354 connection in response to synchronization, format, implementation- 355 defined timeouts, or other errors. 357 All requests and responses MUST contain the VER tag. It contains a 358 list of one or more uint32 version numbers. The version of Roughtime 359 specified by this memo has version number 1. 361 NOTE TO RFC EDITOR: remove this paragraph before publication. For 362 testing drafts of this memo, a version number of 0x80000000 plus the 363 draft number is used. 365 6.1. Requests 367 A request MUST contain the tags VER and NONC. Tags other than NONC 368 and VER SHOULD be ignored by the server. A future version of this 369 protocol may mandate additional tags in the message and asign them 370 semantic meaning. 372 The size of the request message SHOULD be at least 1024 bytes when 373 the UDP transport mode is used. To attain this size the PAD tag 374 SHOULD be added to the message. Its value SHOULD be all zeros. 375 Responding to requests shorter than 1024 bytes is OPTIONAL and 376 servers MUST NOT send responses larger than the requests they are 377 replying to. 379 6.1.1. VER 381 In a request, the VER tag contains a list of versions. The VER tag 382 MUST include at least one Roughtime version supported by the client. 383 The client MUST ensure that the version numbers and tags included in 384 the request are not incompatible with each other or the packet 385 contents. 387 6.1.2. NONC 389 The value of the NONC tag is a 32 byte nonce. It SHOULD be generated 390 in a manner indistinguishable from random. BCP 106 contains specific 391 guidelines regarding this [RFC4086]. 393 6.2. Responses 395 A response MUST contain the tags SIG, VER, NONC, PATH, SREP, CERT, 396 and INDX. 398 6.2.1. SIG 400 In general, a SIG tag value is a 64 byte Ed25519 signature [RFC8032] 401 over a concatenation of a signature context ASCII string and the 402 entire value of a tag. All context strings MUST include a 403 terminating zero byte. 405 The SIG tag in the root of a response MUST be a signature over the 406 SREP value using the public key contained in CERT. The context 407 string MUST be "RoughTime v1 response signature". 409 6.2.2. VER 411 In a response, the VER tag MUST contain a single version number. It 412 SHOULD be one of the version numbers supplied by the client in its 413 request. The server MUST ensure that the version number corresponds 414 with the rest of the packet contents. 416 6.2.3. NONC 418 The NONC tag MUST contain the nonce of the message being responded 419 to. 421 6.2.4. PATH 423 The PATH tag value MUST be a multiple of 32 bytes long and represent 424 a path of 32 byte hash values in the Merkle tree used to generate the 425 ROOT value as described in Section 6.3. In the case where a response 426 is prepared for a single request and the Merkle tree contains only 427 the root node, the size of PATH MUST be zero. 429 6.2.5. SREP 431 The SREP tag contains a time response. Its value MUST be a Roughtime 432 message with the tags ROOT, MIDP, and RADI. The server MAY include 433 any of the tags DUT1, DTAI, and LEAP in the contents of the SREP tag. 435 The ROOT tag MUST contain a 32 byte value of a Merkle tree root as 436 described in Section 6.3. 438 The MIDP tag value MUST be timestamp of the moment of processing. 440 The RADI tag value MUST be a uint32 representing the server's 441 estimate of the accuracy of MIDP in microseconds. Servers MUST 442 ensure that the true time is within (MIDP-RADI, MIDP+RADI) at the 443 time they transmit the response message. 445 The DUT1 tag value MUST be an int32 indicating the predicted 446 difference between UT1 and UTC (UT1 - UTC) in milliseconds as given 447 by the International Earth Rotation and Reference Systems Service 448 (IERS). 450 The DTAI tag value MUST be an int32 indicating the current difference 451 between International Atomic Time (TAI) and UTC (TAI - UTC) in 452 milliseconds as published in the International Bureau of Weights and 453 Measures' (BIPM) Circular T. 455 The LEAP tag MUST contain zero or more int32 values, each 456 representing a past or future leap second event. Positive values 457 represent the addition of a second and negative values represent the 458 removal of a second. The absolute value represents the MJD of the 459 day that begins immediately after the leap second event. 461 By way of illustration, there was a leap second 31 December 2016 462 23:59:60. This event would be represented by the tag with numeric 463 value 57754. The positive sign represents that there was an 464 additional second inserted, the numeric value indicates 1 January 465 2017, the following day that began at midnight after the addition. 467 The leap second events MUST be sorted in reverse chronological order 468 and the first item MUST be the last (past or future) leap second 469 event that the server knows about. A LEAP tag with zero int32 values 470 indicates that the server does not hold any updated leap second 471 information. 473 6.2.6. CERT 475 The CERT tag contains a public-key certificate signed with the 476 server's long-term key. Its value is a Roughtime message with the 477 tags DELE and SIG, where SIG is a signature over the DELE value. The 478 context string used to generate SIG MUST be "RoughTime v1 delegation 479 signature--". 481 The DELE tag contains a delegated public-key certificate used by the 482 server to sign the SREP tag. Its value is a Roughtime message with 483 the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to 484 enable separation of a long-term public key from keys on devices 485 exposed to the public Internet. 487 The MINT tag is the minimum timestamp for which the key in PUBK is 488 trusted to sign responses. MIDP MUST be more than or equal to MINT 489 for a response to be considered valid. 491 The MAXT tag is the maximum timestamp for which the key in PUBK is 492 trusted to sign responses. MIDP MUST be less than or equal to MAXT 493 for a response to be considered valid. 495 The PUBK tag contains a temporary 32 byte Ed25519 public key which is 496 used to sign the SREP tag. 498 6.2.7. INDX 500 The INDX tag value is a uint32 determining the position of NONC in 501 the Merkle tree used to generate the ROOT value as described in 502 Section 6.3. 504 6.3. The Merkle Tree 506 A Merkle tree is a binary tree where the value of each non-leaf node 507 is a hash value derived from its two children. The root of the tree 508 is thus dependent on all leaf nodes. 510 In Roughtime, each leaf node in the Merkle tree represents the nonce 511 in one request. Leaf nodes are indexed left to right, beginning with 512 zero. 514 The values of all nodes are calculated from the leaf nodes and up 515 towards the root node using the first 32 bytes of the output of the 516 SHA-512 hash algorithm [SHS]. For leaf nodes, the byte 0x00 is 517 prepended to the nonce before applying the hash function. For all 518 other nodes, the byte 0x01 is concatenated with first the left and 519 then the right child node value before applying the hash function. 521 The value of the Merkle tree's root node is included in the ROOT tag 522 of the response. 524 The index of a request's nonce node is included in the INDX tag of 525 the response. 527 The values of all sibling nodes in the path between a request's nonce 528 node and the root node is stored in the PATH tag so that the client 529 can reconstruct and validate the value in the ROOT tag using its 530 nonce. These values are each 32 bytes and are stored one after the 531 other with no additional padding or structure. The order in which 532 they are stored is described in Section 6.3.1 534 6.3.1. Root Value Validity Check Algorithm 536 We describe how to compute the hash of the Merkel tree from the 537 values in the tags PATH, INDX, and NONC. Our algorithm maintains a 538 current hash value. The bits of INDX are ordered from least to most 539 significant in this algorithm. 541 At initialization hash is set to H(0x00 || nonce). 543 If no more entries remain in PATH the current hash is the hash of the 544 Merkel tree. All remaining bits of INDX must be zero. 546 Otherwise let node be the next 32 bytes in PATH. If the current bit 547 in INDX is 0 then hash = H(0x01 || node || hash), else hash = 548 H(0x01 || hash || node). 550 6.4. Validity of Response 552 A client MUST check the following properties when it receives a 553 response. We assume the long-term server public key is known to the 554 client through other means. 556 * The signature in CERT was made with the long-term key of the 557 server. 559 * The DELE timestamps and the MIDP value are consistent. 561 * The INDX and PATH values prove NONC was included in the Merkle 562 tree with value ROOT using the algorithm in Section 6.3.1. 564 * The signature of SREP in SIG validates with the public key in 565 DELE. 567 A response that passes these checks is said to be valid. Validity of 568 a response does not prove the time is correct, but merely that the 569 server signed it, and thus promises that it began to compute the 570 signature at a time in the interval (MIDP-RADI, MIDP+RADI). 572 7. Integration Into NTP 574 We assume that there is a bound PHI on the frequency error in the 575 clock on the machine. Given a measurement taken at a local time t, 576 we know the true time is in (t-delta-sigma, t-delta+sigma). After d 577 seconds have elapsed we know the true time is within (t-delta-sigma- 578 d*PHI, t-delta+sigma+d*PHI). A simple and effective way to mix with 579 NTP or PTP discipline of the clock is to trim the observed intervals 580 in NTP to fit entirely within this window or reject measurements that 581 fall to far outside. This assumes time has not been stepped. If the 582 NTP process decides to step the time, it MUST use Roughtime to ensure 583 the new truetime estimate that will be stepped to is consistent with 584 the true time. 586 Should this window become too large, another Roughtime measurement is 587 called for. The definition of "too large" is implementation defined. 589 Implementations MAY use other, more sophisticated means of adjusting 590 the clock respecting Roughtime information. Other applications such 591 as X.509 verification may wish to 593 8. Grease 595 Servers MAY send back a fraction of responses that are syntactically 596 invalid or contain invalid signatures as well as incorrect times. 597 Clients MUST properly reject such responses. Servers MUST NOT send 598 back responses with incorrect times and valid signatures. Either 599 signature MAY be invalid for this application. 601 9. Roughtime Servers 603 NOTE TO RFC EDITOR: remove this section before publication. 605 The below list contains a list of servers with their public keys in 606 Base64 format. These servers may implement older versions of this 607 specification. 609 address: roughtime.cloudflare.com 610 port: 2002 611 long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= 613 address: roughtime.int08h.com 614 port: 2002 615 long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 617 address: roughtime.sandbox.google.com 618 port: 2002 619 long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 621 address: roughtime.se 622 port: 2002 623 long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= 625 10. Acknowledgements 627 Thomas Peterson corrected multiple nits. Peter Loethberg, Tal 628 Mizrahi, Ragnar Sundblad, Kristof Teichel, and the other members of 629 the NTP working group contributed comments and suggestions. 631 11. IANA Considerations 633 11.1. Service Name and Transport Protocol Port Number Registry 635 IANA is requested to allocate the following entry in the Service Name 636 and Transport Protocol Port Number Registry [RFC6335]: 638 Service Name: Roughtime 640 Transport Protocol: tcp,udp 641 Assignee: IESG 643 Contact: IETF Chair 645 Description: Roughtime time synchronization 647 Reference: [[this memo]] 649 Port Number: [[TBD1]], selected by IANA from the User Port range 651 11.2. Roughtime Version Registry 653 IANA is requested to create a new registry entitled "Roughtime 654 Version Registry". Entries shall have the following fields: 656 Version ID (REQUIRED): a 32-bit unsigned integer 658 Version name (REQUIRED): A short text string naming the version 659 being identified. 661 Reference (REQUIRED): A reference to a relevant specification 662 document. 664 The policy for allocation of new entries SHOULD be: IETF Review. 666 The initial contents of this registry shall be as follows: 668 +=======================+======================+===============+ 669 | Version ID | Version name | Reference | 670 +=======================+======================+===============+ 671 | 0x0 | Reserved | [[this memo]] | 672 +-----------------------+----------------------+---------------+ 673 | 0x1 | Roughtime version 1 | [[this memo]] | 674 +-----------------------+----------------------+---------------+ 675 | 0x2-0x7fffffff | Unassigned | | 676 +-----------------------+----------------------+---------------+ 677 | 0x80000000-0xffffffff | Reserved for Private | [[this memo]] | 678 | | or Experimental use | | 679 +-----------------------+----------------------+---------------+ 681 Table 2: Roughtime version assignments. 683 11.3. Roughtime Tag Registry 685 IANA is requested to create a new registry entitled "Roughtime Tag 686 Registry". Entries SHALL have the following fields: 688 Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. 690 ASCII Representation (OPTIONAL): The ASCII representation of the 691 tag in accordance with Section 5.1.4 of this memo, if applicable. 693 Reference (REQUIRED): A reference to a relevant specification 694 document. 696 The policy for allocation of new entries in this registry SHOULD be: 697 Specification Required. 699 The initial contents of this registry SHALL be as follows: 701 +============+======================+===============+ 702 | Tag | ASCII Representation | Reference | 703 +============+======================+===============+ 704 | 0x00444150 | PAD | [[this memo]] | 705 +------------+----------------------+---------------+ 706 | 0x00474953 | SIG | [[this memo]] | 707 +------------+----------------------+---------------+ 708 | 0x00524556 | VER | [[this memo]] | 709 +------------+----------------------+---------------+ 710 | 0x31545544 | DUT1 | [[this memo]] | 711 +------------+----------------------+---------------+ 712 | 0x434e4f4e | NONC | [[this memo]] | 713 +------------+----------------------+---------------+ 714 | 0x454c4544 | DELE | [[this memo]] | 715 +------------+----------------------+---------------+ 716 | 0x48544150 | PATH | [[this memo]] | 717 +------------+----------------------+---------------+ 718 | 0x49415444 | DTAI | [[this memo]] | 719 +------------+----------------------+---------------+ 720 | 0x49444152 | RADI | [[this memo]] | 721 +------------+----------------------+---------------+ 722 | 0x4b425550 | PUBK | [[this memo]] | 723 +------------+----------------------+---------------+ 724 | 0x5041454c | LEAP | [[this memo]] | 725 +------------+----------------------+---------------+ 726 | 0x5044494d | MIDP | [[this memo]] | 727 +------------+----------------------+---------------+ 728 | 0x50455253 | SREP | [[this memo]] | 729 +------------+----------------------+---------------+ 730 | 0x544e494d | MINT | [[this memo]] | 731 +------------+----------------------+---------------+ 732 | 0x544f4f52 | ROOT | [[this memo]] | 733 +------------+----------------------+---------------+ 734 | 0x54524543 | CERT | [[this memo]] | 735 +------------+----------------------+---------------+ 736 | 0x5458414d | MAXT | [[this memo]] | 737 +------------+----------------------+---------------+ 738 | 0x58444e49 | INDX | [[this memo]] | 739 +------------+----------------------+---------------+ 741 Table 3: Roughtime tags. 743 12. Security Considerations 745 Since the only supported signature scheme, Ed25519, is not quantum 746 resistant, the Roughtime version described in this memo will not 747 survive the advent of quantum computers. 749 Maintaining a list of trusted servers and adjudicating violations of 750 the rules by servers is not discussed in this document and is 751 essential for security. Roughtime clients MUST regularly update 752 their view of which servers are trustworthy in order to benefit from 753 the detection of misbehavior. 755 Validating timestamps made on different dates requires knowledge of 756 leap seconds in order to calculate time intervals correctly. 758 Servers carry out a significant amount of computation in response to 759 clients, and thus may experience vulnerability to denial of service 760 attacks. 762 This protocol does not provide any confidentiality. Given the nature 763 of timestamps such impact is minor. 765 The compromise of a PUBK's private key, even past MAXT, is a problem 766 as the private key can be used to sign invalid times that are in the 767 range MINT to MAXT, and thus violate the good behavior guarantee of 768 the server. 770 Servers MUST NOT send response packets larger than the request 771 packets sent by clients, in order to prevent amplification attacks. 773 13. Privacy Considerations 775 This protocol is designed to obscure all client identifiers. Servers 776 necessarily have persistent long-term identities essential to 777 enforcing correct behavior. 779 Generating nonces in a nonrandom manner can cause leaks of private 780 data or enable tracking of clients as they move between networks. 782 14. References 784 14.1. Normative References 786 [ITU-R_TF.457-2] 787 ITU-R, "Use of the Modified Julian Date by the Standard- 788 Frequency and Time-Signal Services", ITU-R 789 Recommendation TF.457-2, October 1997. 791 [ITU-R_TF.460-6] 792 ITU-R, "Standard-Frequency and Time-Signal Emissions", 793 ITU-R Recommendation TF.460-6, February 2002. 795 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 796 RFC 20, DOI 10.17487/RFC0020, October 1969, 797 . 799 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 800 Cheshire, "Internet Assigned Numbers Authority (IANA) 801 Procedures for the Management of the Service Name and 802 Transport Protocol Port Number Registry", BCP 165, 803 RFC 6335, DOI 10.17487/RFC6335, August 2011, 804 . 806 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 807 Signature Algorithm (EdDSA)", RFC 8032, 808 DOI 10.17487/RFC8032, January 2017, 809 . 811 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 812 Interchange Format", STD 90, RFC 8259, 813 DOI 10.17487/RFC8259, December 2017, 814 . 816 [SHS] National Institute of Standards and Technology, "Secure 817 Hash Standard", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4, 818 August 2015, . 820 14.2. Informative References 822 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 823 2012, . 825 [DelayAttacks] 826 Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks 827 Against Time Synchronization Protocols", 828 DOI 10.1109/ISPCS.2012.6336612, 2012, 829 . 831 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 832 "Attacking the Network Time Protocol", 2015, 833 . 835 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 836 DOI 10.17487/RFC0768, August 1980, 837 . 839 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 840 DOI 10.17487/RFC0791, September 1981, 841 . 843 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 844 RFC 793, DOI 10.17487/RFC0793, September 1981, 845 . 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, 849 DOI 10.17487/RFC2119, March 1997, 850 . 852 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 853 "Randomness Requirements for Security", BCP 106, RFC 4086, 854 DOI 10.17487/RFC4086, June 2005, 855 . 857 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 858 "Network Time Protocol Version 4: Protocol and Algorithms 859 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 860 . 862 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 863 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 864 October 2014, . 866 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 867 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 868 May 2017, . 870 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 871 for the Network Time Protocol", RFC 8573, 872 DOI 10.17487/RFC8573, June 2019, 873 . 875 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 876 Sundblad, "Network Time Security for the Network Time 877 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 878 . 880 Appendix A. Terms and Abbreviations 882 ASCII American Standard Code for Information Interchange 884 IANA Internet Assigned Numbers Authority 886 JSON JavaScript Object Notation [RFC8259] 888 MJD Modified Julian Date 890 NTP Network Time Protocol [RFC5905] 891 NTS Network Time Security [RFC8915] 893 TAI International Atomic Time (Temps Atomique International) 894 [ITU-R_TF.460-6] 896 TCP Transmission Control Protocol [RFC0793] 898 UDP User Datagram Protocol [RFC0768] 900 UT Universal Time [ITU-R_TF.460-6] 902 UTC Coordinated Universal Time [ITU-R_TF.460-6] 904 Authors' Addresses 906 Aanchal Malhotra 907 Boston University 908 111 Cummington Mall 909 Boston, MA 02215 910 United States of America 912 Email: aanchal4@bu.edu 914 Adam Langley 915 Google 917 Email: agl@google.com 919 Watson Ladd 920 Cloudflare 921 101 Townsend St 922 San Francisco, CA 94107 923 United States of America 925 Email: watsonbladd@gmail.com 927 Marcus Dansarie 929 Email: marcus@dansarie.se 930 URI: https://orcid.org/0000-0001-9246-0263