idnits 2.17.1 draft-ietf-ntp-roughtime-04.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 (February 21, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4648' is defined on line 732, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 3 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: August 25, 2021 Google 6 W. Ladd 7 Cloudflare 8 M. Dansarie 9 February 21, 2021 11 Roughtime 12 draft-ietf-ntp-roughtime-04 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 August 25, 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 4. The Guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1.1. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 6 66 5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 11 71 6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 11 72 6.4. Validity of Response . . . . . . . . . . . . . . . . . . 12 73 7. Integration into NTP . . . . . . . . . . . . . . . . . . . . 12 74 8. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 9. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 13 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 11.1. Service Name and Transport Protocol Port Number Registry 13 79 11.2. Roughtime Version Registry . . . . . . . . . . . . . . . 14 80 11.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 14 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 14.2. Informative References . . . . . . . . . . . . . . . . . 17 86 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Time synchronization is essential to Internet security as many 92 security protocols and other applications require synchronization 93 [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as 94 the Network Time Protocol (NTP) [RFC5905] lack essential security 95 features, and even newer protocols like Network Time Security (NTS) 96 [RFC8915] lack mechanisms to ensure that the servers behave 97 correctly. Authenticating time servers prevents network adversaries 98 from modifying time packets, but an authenticated time server still 99 has full control over the contents of the time packet and may go 100 rogue. The Roughtime protocol provides cryptographic proof of 101 malfeasance, enabling clients to detect and prove to a third party a 102 server's attempts to influence the time a client computes. 104 +--------------+----------------------+-----------------------------+ 105 | Protocol | Authenticated Server | Server Malfeasance Evidence | 106 +--------------+----------------------+-----------------------------+ 107 | NTP, Chronos | N | N | 108 | NTP-MD5 | Y* | N | 109 | NTP-Autokey | Y** | N | 110 | NTS | Y | N | 111 | Roughtime | Y | Y | 112 +--------------+----------------------+-----------------------------+ 114 Security Properties of current protocols 116 Table 1 118 Y* For security issues with symmetric-key based NTP-MD5 119 authentication, please refer to RFC 8573 [RFC8573]. 121 Y** For security issues with Autokey Public Key Authentication, refer 122 to [Autokey]. 124 o If a server's timestamps do not fit into the time context of other 125 servers' responses, then a Roughtime client can cryptographically 126 prove this misbehavior to third parties. This helps detect "bad" 127 servers. 129 o A Roughtime client can roughly detect (with no absolute guarantee) 130 a delay attack [DelayAttacks] but can not cryptographically prove 131 this to a third party. However, the absence of proof of 132 malfeasance should not be considered a proof of absence of 133 malfeasance. So Roughtime should not be used as a witness that a 134 server is overall "good". 136 o Note that delay attacks cannot be detected/stopped by any 137 protocol. Delay attacks can not, however, undermine the security 138 guarantees provided by Roughtime. 140 o Although delay attacks cannot be prevented, they can be limited to 141 a predetermined upper bound. This can be done by defining a 142 maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a 143 Roughtime client is willing to accept. A Roughtime client can 144 measure the RTT of every request-response handshake and compare it 145 to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding server 146 is assumed to be a falseticker. When this approach is used the 147 maximal time error that can be caused by a delay attack is MAX- 148 RTT/2. It should be noted that this approach assumes that the 149 nature of the system is known to the client, including reasonable 150 upper bounds on the RTT value. 152 2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Protocol Overview 162 Roughtime is a protocol for rough time synchronization that enables 163 clients to provide cryptographic proof of server malfeasance. It 164 does so by having responses from servers include a signature with a 165 certificate rooted in a long-term public/private key pair over a 166 value derived from a nonce provided by the client in its request. 167 This provides cryptographic proof that the timestamp was issued after 168 the server received the client's request. The derived value included 169 in the server's response is the root of a Merkle tree which includes 170 the hash of the client's nonce as the value of one of its leaf nodes. 171 This enables the server to amortize the relatively costly signing 172 operation over a number of client requests. 174 Single server mode: At its most basic level, Roughtime is a one round 175 protocol in which a completely fresh client requests the current time 176 and the server sends a signed response. The response includes a 177 timestamp and a radius used to indicate the server's certainty about 178 the reported time. For example, a radius of 1,000,000 microseconds 179 means the server is absolutely confident that the true time is within 180 one second of the reported time. 182 The server proves freshness of its response as follows: The client's 183 request contains a nonce. The server incorporates the nonce into its 184 signed response so that the client can verify the server's signatures 185 covering the nonce issued by the client. Provided that the nonce has 186 sufficient entropy, this proves that the signed response could only 187 have been generated after the nonce. 189 4. The Guarantee 191 A Roughtime server guarantees that a response to a query sent at t_1, 192 received at t_2, and with timestamp t_3 has been created between the 193 transmission of the query and its reception. If t_3 is not within 194 that interval, a server inconsistency may be detected and used to 195 impeach the server. The propagation of such a guarantee and its use 196 of type synchronization is discussed in Section 7. No delay attacker 197 may affect this: they may only expand the interval between t_1 and 198 t_2, or of course stop the measurement in the first place. 200 5. Message Format 202 Roughtime messages are maps consisting of one or more (tag, value) 203 pairs. They start with a header, which contains the number of pairs, 204 the tags, and value offsets. The header is followed by a message 205 values section which contains the values associated with the tags in 206 the header. Messages MUST be formatted according to Figure 1 as 207 described in the following sections. 209 Messages may be recursive, i.e. the value of a tag can itself be a 210 Roughtime message. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Number of pairs (uint32) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 . . 219 . N-1 offsets (uint32) . 220 . . 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 . . 225 . N tags (uint32) . 226 . . 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 . . 231 . Values . 232 . . 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 1: Roughtime Message Format 238 5.1. Data Types 240 5.1.1. int32 242 An int32 is a 32 bit signed integer. It is serialized in sign- 243 magnitude representation with the sign bit in the most significant 244 bit. It is serialized least significant byte first. The negative 245 zero value (0x80000000) MUST NOT be used. 247 5.1.2. uint32 249 A uint32 is a 32 bit unsigned integer. It is serialized with the 250 least significant byte first. 252 5.1.3. uint64 254 A uint64 is a 64 bit unsigned integer. It is serialized with the 255 least significant byte first. 257 5.1.4. Tag 259 Tags are used to identify values in Roughtime messages. A tag is a 260 uint32 but may also be listed as a sequence of up to four ASCII 261 characters [RFC0020]. ASCII strings shorter than four characters can 262 be unambiguously converted to tags by padding them with zero bytes. 263 For example, the ASCII string "NONC" would correspond to the tag 264 0x434e4f4e and "PAD" would correspond to 0x00444150. 266 5.1.5. Timestamp 268 A timestamp is a uint64 interpreted in the following way. The most 269 significant 3 bytes contain the integer part of a Modified Julian 270 Date (MJD). The least significant 5 bytes is a count of the number 271 of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6] 272 since midnight on that day. 274 The MJD is the number of UTC days since 17 November 1858 275 [ITU-R_TF.457-2]. It is useful to note that 1 January 1970 is 40,587 276 days after 17 November 1858. 278 Note that, unlike NTP, this representation does not use the full 279 number of bits in the fractional part and that days with leap seconds 280 will have more or fewer than the nominal 86,400,000,000 microseconds. 282 5.2. Header 284 All Roughtime messages start with a header. The first four bytes of 285 the header is the uint32 number of tags N, and hence of (tag, value) 286 pairs. The following 4*(N-1) bytes are offsets, each a uint32. The 287 last 4*N bytes in the header are tags. 289 Offsets refer to the positions of the values in the message values 290 section. All offsets MUST be multiples of four and placed in 291 increasing order. The first post-header byte is at offset 0. The 292 offset array is considered to have a not explicitly encoded value of 293 0 as its zeroth entry. The value associated with the ith tag begins 294 at offset[i] and ends at offset[i+1]-1, with the exception of the 295 last value which ends at the end of the message. Values may have 296 zero length. 298 Tags MUST be listed in the same order as the offsets of their values. 299 A tag MUST NOT appear more than once in a header. Tags MUST also be 300 sorted in ascending order by numeric value. 302 6. Protocol 304 As described in Section 3, clients initiate time synchronization by 305 sending requests containing a nonce to servers who send signed time 306 responses in return. Roughtime packets can be sent between clients 307 and servers either as UDP datagrams or via TCP streams. Servers 308 SHOULD support the UDP transport mode, while TCP transport is 309 OPTIONAL. 311 A Roughtime packet MUST be formatted according to Figure 2 and as 312 described here. The first field is a uint64 with the value 313 0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a 314 uint32 and contains the length of the third field. The third and 315 last field contains a Roughtime message as specified in Section 5.1. 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | 0x4d49544847554f52 (uint64) | 321 | ("ROUGHTIM") | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Message length (uint32) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 . . 327 . Roughtime message . 328 . . 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 2: Roughtime Packet Format 334 Roughtime request and response packets MUST be transmitted in a 335 single datagram when the UDP transport mode is used. Setting the 336 packet's don't fragment bit [RFC0791] is OPTIONAL in IPv4 networks. 338 Multiple requests and responses can be exchanged over an established 339 TCP connection. Clients MAY send multiple requests at once and 340 servers MAY send responses out of order. The connection SHOULD be 341 closed by the client when it has no more requests to send and has 342 received all expected responses. Either side SHOULD close the 343 connection in response to synchronization, format, implementation- 344 defined timeouts, or other errors. 346 All requests and responses MUST contain the VER tag. It contains a 347 list of one or more uint32 version numbers. The version of Roughtime 348 specified by this memo has version number 1. 350 For testing drafts of this memo, a version number of 0x80000000 plus 351 the draft number is used. 353 6.1. Requests 355 A request MUST contain the tags NONC and VER. 357 The value of the NONC tag is a 64 byte nonce. It SHOULD be generated 358 in a manner indistinguishable from random. 360 In a request, the VER tag contains a list of versions. The VER tag 361 MUST include at least one Roughtime version supported by the client. 362 The client MUST ensure that the version numbers and tags included in 363 the request are not incompatible with each other or the packet 364 contents. 366 Tags other than NONC and VER SHOULD be ignored by the server. 368 The size of the request message SHOULD be at least 1024 bytes when 369 the UDP transport mode is used. To attain this size the PAD tag 370 SHOULD be added to the message. Its value SHOULD be all zeros. 371 Responding to requests shorter than 1024 bytes is OPTIONAL and 372 servers MUST NOT send responses larger than the requests they are 373 replying to. 375 6.2. Responses 377 A response MUST contain the tags CERT, INDX, NONC, PATH, SIG, SREP, 378 and VER. 380 The SIG tag is a signature over the SREP value using the public key 381 contained in CERT, as explained below. 383 The SREP tag contains a time response. Its value is a Roughtime 384 message with the tags ROOT, MIDP, and RADI. The server MAY include 385 any of the tags DUT1, DTAI and LEAP in the contents of the SREP tag. 387 The NONC tag contains the nonce of the message being responded to. 389 The ROOT tag contains a 32 byte value of a Merkle tree root as 390 described in Section 6.3. 392 The MIDP tag value is a timestamp of the moment of processing. 394 The RADI tag value is a uint32 representing the server's estimate of 395 the accuracy of MIDP in microseconds. Servers MUST ensure that the 396 true time is within (MIDP-RADI, MIDP+RADI) at the time they compose 397 the response message. 399 The DUT1 tag value is an int32 indicating the predicted difference 400 between UT1 and UTC (UT1 - UTC) in milliseconds as given by the 401 International Earth Rotation and Reference Systems Service (IERS). 403 The DTAI tag value is an int32 indicating the current difference 404 between International Atomic Time (TAI) and UTC (TAI - UTC) in 405 milliseconds as published in the International Bureau of Weights and 406 Measures' (BIPM) Circular T. 408 The LEAP tag contains zero or more int32 values, each representing a 409 past or future leap second event. Positive values represent the 410 addition of a second and negative values represent the removal of a 411 second. The absolute value represents the MJD of the second after 412 the leap second event, i.e., the first second with a new UTC - TAI 413 difference. The leap second events MUST be sorted in reverse 414 chronological order and the first item MUST be the last (past or 415 future) leap second event that the server knows about. A LEAP tag 416 with zero int32 values indicates that the server does not hold any 417 updated leap second information. 419 The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a 420 signature context concatenated with the entire value of a DELE or 421 SREP tag. Signatures of DELE tags MUST use the ASCII string 422 "RoughTime v1 delegation signature--" and signatures of SREP tags 423 MUST use the ASCII string "RoughTime v1 response signature" as 424 signature context. Both strings MUST include a terminating zero 425 byte. 427 The CERT tag contains a public-key certificate signed with the 428 server's long-term key. Its value is a Roughtime message with the 429 tags DELE and SIG, where SIG is a signature over the DELE value. 431 The DELE tag contains a delegated public-key certificate used by the 432 server to sign the SREP tag. Its value is a Roughtime message with 433 the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to 434 enable separation of a long-term public key from keys on devices 435 exposed to the public Internet. 437 The MINT tag is the minimum timestamp for which the key in PUBK is 438 trusted to sign responses. MIDP MUST be more than or equal to MINT 439 for a response to be considered valid. 441 The MAXT tag is the maximum timestamp for which the key in PUBK is 442 trusted to sign responses. MIDP MUST be less than or equal to MAXT 443 for a response to be considered valid. 445 The PUBK tag contains a temporary 32 byte Ed25519 public key which is 446 used to sign the SREP tag. 448 The INDX tag value is a uint32 determining the position of NONC in 449 the Merkle tree used to generate the ROOT value as described in 450 Section 6.3. 452 The PATH tag value is a multiple of 32 bytes long and represents a 453 path of 32 byte hash values in the Merkle tree used to generate the 454 ROOT value as described in Section 6.3. In the case where a response 455 is prepared for a single request and the Merkle tree contains only 456 the root node, the size of PATH is zero. 458 In a response, the VER tag MUST contain a single version number. It 459 SHOULD be one of the version numbers supplied by the client in its 460 request. The server MUST ensure that the version number corresponds 461 with the rest of the packet contents. 463 6.3. The Merkle Tree 465 A Merkle tree is a binary tree where the value of each non-leaf node 466 is a hash value derived from its two children. The root of the tree 467 is thus dependent on all leaf nodes. 469 In Roughtime, each leaf node in the Merkle tree represents the nonce 470 of one request that a response message is sent in reply to. Leaf 471 nodes are indexed left to right, beginning with zero. 473 The values of all nodes are calculated from the leaf nodes and up 474 towards the root node using the first 32 bytes of the output of the 475 SHA-512 hash algorithm [SHS]. For leaf nodes, the byte 0x00 is 476 prepended to the nonce before applying the hash function. For all 477 other nodes, the byte 0x01 is concatenated with first the left and 478 then the right child node value before applying the hash function. 480 The value of the Merkle tree's root node is included in the ROOT tag 481 of the response. 483 The index of a request's nonce node is included in the INDX tag of 484 the response. 486 The values of all sibling nodes in the path between a request's nonce 487 node and the root node is stored in the PATH tag so that the client 488 can reconstruct and validate the value in the ROOT tag using its 489 nonce. 491 6.3.1. Root Value Validity Check Algorithm 493 One starts by computing the hash of the NONC value from the request, 494 with 0x00 prepended. Then one walks from the least significant bit 495 of INDX to the most significant bit, and also walks towards the end 496 of PATH. 498 If PATH ends then the remaining bits of the INDX MUST be all zero. 499 This indicates the termination of the walk, and the current value 500 MUST equal ROOT if the response is valid. 502 If the current bit is 0, one hashes 0x01, the current hash, and the 503 value from PATH to derive the next current value. 505 If the current bit is 1 one hashes 0x01, the value from PATH, and the 506 current hash to derive the next current value. 508 6.4. Validity of Response 510 A client MUST check the following properties when it receives a 511 response. We assume the long-term server public key is known to the 512 client through other means. 514 o The signature in CERT was made with the long-term key of the 515 server. 517 o The DELE timestamps and the MIDP value are consistent. 519 o The INDX and PATH values prove NONC was included in the Merkle 520 tree with value ROOT using the algorithm in Section 6.3.1. 522 o The signature of SREP in SIG validates with the public key in 523 DELE. 525 A response that passes these checks is said to be valid. Validity of 526 a response does not prove the time is correct, but merely that the 527 server signed it, and thus guarantees that it began to compute the 528 signature at a time in the interval (MIDP-RADI, MIDP+RADI). 530 7. Integration into NTP 532 We assume that there is a bound PHI on the frequency error in the 533 clock on the machine. Given a measurement taken at a local time t1, 534 we know the true time is in [ t1-delta-sigma, t1-delta+sigma ]. 535 After d seconds have elapsed we know the true time is within [ t1- 536 delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way 537 to mix with NTP or PTP discipline of the clock is to trim the 538 observed intervals in NTP to fit entirely within this window or 539 reject measurements that fall to far outside. This assumes time has 540 not been stepped. If the NTP process decides to step the time, it 541 MUST use Roughtime to ensure the new truetime estimate that will be 542 stepped to is consistent with the true time. 544 Should this window become too large, another Roughtime measurement is 545 called for. The definition of "too large" is implementation defined. 547 Implementations MAY use other, more sophisticated means of adjusting 548 the clock respecting Roughtime information. 550 8. Grease 552 Servers MAY send back a fraction of responses that are syntactically 553 invalid or contain invalid signatures as well as incorrect times. 554 Clients MUST properly reject such responses. Servers MUST NOT send 555 back responses with incorrect times and valid signatures. Either 556 signature MAY be invalid for this application. 558 9. Roughtime Servers 560 The below list contains a list of servers with their public keys in 561 Base64 format. These servers may implement older versions of this 562 specification. 564 address: roughtime.cloudflare.com 565 port: 2002 566 long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= 568 address: roughtime.int08h.com 569 port: 2002 570 long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 572 address: roughtime.sandbox.google.com 573 port: 2002 574 long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 576 address: roughtime.se 577 port: 2002 578 long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= 580 10. Acknowledgements 582 Thomas Peterson corrected multiple nits. Peter Loethberg (Lothberg), 583 Tal Mizrahi, Ragnar Sundblad, Kristof Teichel, and the other members 584 of the NTP working group contributed comments and suggestions. 586 11. IANA Considerations 588 11.1. Service Name and Transport Protocol Port Number Registry 590 IANA is requested to allocate the following entry in the Service Name 591 and Transport Protocol Port Number Registry [RFC6335]: 593 Service Name: Roughtime 595 Transport Protocol: tcp,udp 597 Assignee: IESG 599 Contact: IETF Chair 601 Description: Roughtime time synchronization 602 Reference: [[this memo]] 604 Port Number: [[TBD1]], selected by IANA from the User Port range 606 11.2. Roughtime Version Registry 608 IANA is requested to create a new registry entitled " Roughtime 609 Version Registry " Entries shall have the following fields: 611 Version ID (REQUIRED): a 32-bit unsigned integer 613 Version name (REQUIRED): A short text string naming the version 614 being identified. 616 Reference (REQUIRED): A reference to a relevant specification 617 document. 619 The policy for allocation of new entries SHOULD be: IETF Review. 621 The initial contents of this registry shall be as follows: 623 +-----------------------+------------------------------+------------+ 624 | Version ID | Version name | Reference | 625 +-----------------------+------------------------------+------------+ 626 | 0x0 | Reserved | [[this | 627 | | | memo]] | 628 | 0x1 | Roughtime version 1 | [[this | 629 | | | memo]] | 630 | 0x2-0x7fffffff | Unassigned | | 631 | 0x80000000-0xffffffff | Reserved for Private or | [[this | 632 | | Experimental use | memo]] | 633 +-----------------------+------------------------------+------------+ 635 11.3. Roughtime Tag Registry 637 IANA is requested to create a new registry entitled "Roughtime Tag 638 Registry". Entries SHALL have the following fields: 640 Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. 642 ASCII Representation (OPTIONAL): The ASCII representation of the 643 tag in accordance with Section 5.1.4 of this memo, if applicable. 645 Reference (REQUIRED): A reference to a relevant specification 646 document. 648 The policy for allocation of new entries in this registry SHOULD be: 649 Specification Required. 651 The initial contents of this registry SHALL be as follows: 653 +------------+----------------------+---------------+ 654 | Tag | ASCII Representation | Reference | 655 +------------+----------------------+---------------+ 656 | 0x00444150 | PAD | [[this memo]] | 657 | 0x00474953 | SIG | [[this memo]] | 658 | 0x00524556 | VER | [[this memo]] | 659 | 0x31545544 | DUT1 | [[this memo]] | 660 | 0x434e4f4e | NONC | [[this memo]] | 661 | 0x454c4544 | DELE | [[this memo]] | 662 | 0x48544150 | PATH | [[this memo]] | 663 | 0x49415444 | DTAI | [[this memo]] | 664 | 0x49444152 | RADI | [[this memo]] | 665 | 0x4b425550 | PUBK | [[this memo]] | 666 | 0x5041454c | LEAP | [[this memo]] | 667 | 0x5044494d | MIDP | [[this memo]] | 668 | 0x50455253 | SREP | [[this memo]] | 669 | 0x544e494d | MINT | [[this memo]] | 670 | 0x544f4f52 | ROOT | [[this memo]] | 671 | 0x54524543 | CERT | [[this memo]] | 672 | 0x5458414d | MAXT | [[this memo]] | 673 | 0x58444e49 | INDX | [[this memo]] | 674 +------------+----------------------+---------------+ 676 12. Security Considerations 678 Since the only supported signature scheme, Ed25519, is not quantum 679 resistant, the Roughtime version described in this memo will not 680 survive the advent of quantum computers. 682 Maintaining a list of trusted servers and adjudicating violations of 683 the rules by servers is not discussed in this document and is 684 essential for security. Roughtime clients MUST update their view of 685 which servers are trustworthy in order to benefit from the detection 686 of misbehavior. 688 Validating timestamps made on different dates requires knowledge of 689 leap seconds in order to calculate time intervals correctly. 691 Servers carry out a significant amount of computation in response to 692 clients, and thus may experience vulnerability to denial of service 693 attacks. 695 This protocol does not provide any confidentiality, and given the 696 nature of timestamps such impact is minor. 698 The compromise of a PUBK's private key, even past MAXT, is a problem 699 as the private key can be used to sign invalid times that are in the 700 range MINT to MAXT, and thus violate the good behavior guarantee of 701 the server. 703 Servers MUST NOT send response packets larger than the request 704 packets sent by clients, in order to prevent amplification attacks. 706 13. Privacy Considerations 708 This protocol is designed to obscure all client identifiers. Servers 709 necessarily have persistent long-term identities essential to 710 enforcing correct behavior. 712 Generating nonces in a nonrandom manner can cause leaks of private 713 data or enable tracking of clients as they move between networks. 715 14. References 717 14.1. Normative References 719 [ITU-R_TF.457-2] 720 ITU-R, "Use of the Modified Julian Date by the Standard- 721 Frequency and Time-Signal Services", ITU-R 722 Recommendation TF.457-2, October 1997. 724 [ITU-R_TF.460-6] 725 ITU-R, "Standard-Frequency and Time-Signal Emissions", 726 ITU-R Recommendation TF.460-6, February 2002. 728 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 729 RFC 20, DOI 10.17487/RFC0020, October 1969, 730 . 732 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 733 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 734 . 736 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 737 Cheshire, "Internet Assigned Numbers Authority (IANA) 738 Procedures for the Management of the Service Name and 739 Transport Protocol Port Number Registry", BCP 165, 740 RFC 6335, DOI 10.17487/RFC6335, August 2011, 741 . 743 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 744 Signature Algorithm (EdDSA)", RFC 8032, 745 DOI 10.17487/RFC8032, January 2017, 746 . 748 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 749 Interchange Format", STD 90, RFC 8259, 750 DOI 10.17487/RFC8259, December 2017, 751 . 753 [SHS] National Institute of Standards and Technology, "Secure 754 Hash Standard", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4, 755 August 2015. 757 14.2. Informative References 759 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 760 2012, . 762 [DelayAttacks] 763 Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks 764 Against Time Synchronization Protocols", 765 DOI 10.1109/ISPCS.2012.6336612, 2012, 766 . 768 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 769 "Attacking the Network Time Protocol", 2015, 770 . 772 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 773 DOI 10.17487/RFC0768, August 1980, 774 . 776 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 777 DOI 10.17487/RFC0791, September 1981, 778 . 780 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 781 RFC 793, DOI 10.17487/RFC0793, September 1981, 782 . 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 790 "Network Time Protocol Version 4: Protocol and Algorithms 791 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 792 . 794 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 795 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 796 October 2014, . 798 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 799 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 800 May 2017, . 802 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 803 for the Network Time Protocol", RFC 8573, 804 DOI 10.17487/RFC8573, June 2019, 805 . 807 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 808 Sundblad, "Network Time Security for the Network Time 809 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 810 . 812 Appendix A. Terms and Abbreviations 814 ASCII American Standard Code for Information Interchange 816 IANA Internet Assigned Numbers Authority 818 JSON JavaScript Object Notation [RFC8259] 820 MJD Modified Julian Date 822 NTP Network Time Protocol [RFC5905] 824 NTS Network Time Security [RFC8915] 826 TAI International Atomic Time (Temps Atomique International) 827 [ITU-R_TF.460-6] 829 TCP Transmission Control Protocol [RFC0793] 831 UDP User Datagram Protocol [RFC0768] 833 UT Universal Time [ITU-R_TF.460-6] 835 UTC Coordinated Universal Time [ITU-R_TF.460-6] 837 Authors' Addresses 839 Aanchal Malhotra 840 Boston University 841 111 Cummington Mall 842 Boston 02215 843 USA 845 Email: aanchal4@bu.edu 847 Adam Langley 848 Google 850 Email: 851 agl@google.com 853 Watson Ladd 854 Cloudflare 855 101 Townsend St 856 San Francisco 857 USA 859 Email: watsonbladd@gmail.com 861 Marcus Dansarie 862 Sweden 864 Email: marcus@dansarie.se 865 URI: https://orcid.org/0000-0001-9246-0263