idnits 2.17.1 draft-ietf-ntp-roughtime-01.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 (April 1, 2020) is 1480 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-25 -- 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: October 3, 2020 Google 6 W. Ladd 7 Cloudflare 8 April 1, 2020 10 Roughtime 11 draft-ietf-ntp-roughtime-01 13 Abstract 15 This document specifies Roughtime - a protocol that aims to achieve 16 rough time synchronization while detecting servers that provide 17 inaccurate time and providing cryptographic proof of their 18 malfeasance. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 3, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 11 70 6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 11 71 6.4. Validity of Response . . . . . . . . . . . . . . . . . . 12 72 7. Integration into NTP . . . . . . . . . . . . . . . . . . . . 12 73 8. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 13 74 9. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 10. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 13 76 11. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 14 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 13.1. Service Name and Transport Protocol Port Number Registry 14 80 13.2. Roughtime Version Registry . . . . . . . . . . . . . . . 15 81 13.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 15 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 84 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 16.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 16.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 Time synchronization is essential to Internet security as many 93 security protocols and other applications require synchronization 94 [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as 95 the Network Time Protocol (NTP) [RFC5905] lack essential security 96 features, and even newer protocols like Network Time Security (NTS) 98 [I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers 99 behave correctly. Authenticating time servers prevents network 100 adversaries from modifying time packets, but an authenticated time 101 server still has full control over the contents of the time packet 102 and may go rogue. The Roughtime protocol provides cryptographic 103 proof of malfeasance, enabling clients to detect and prove to a third 104 party a server's attempts to influence the time a client computes. 106 +--------------+----------------------+-----------------------------+ 107 | Protocol | Authenticated Server | Server Malfeasance Evidence | 108 +--------------+----------------------+-----------------------------+ 109 | NTP, Chronos | N | N | 110 | NTP-MD5 | Y* | N | 111 | NTP-Autokey | Y** | N | 112 | NTS | Y | N | 113 | Roughtime | Y | Y | 114 +--------------+----------------------+-----------------------------+ 116 Security Properties of current protocols 118 Table 1 120 Y* For security issues with symmetric-key based NTP-MD5 121 authentication, please refer to RFC 8573 [RFC8573]. 123 Y** For security issues with Autokey Public Key Authentication, refer 124 to [Autokey]. 126 More specifically, 128 o If a server's timestamps do not fit into the time context of other 129 servers' responses, then a Roughtime client can cryptographically 130 prove this misbehavior to third parties. This helps detect "bad" 131 servers. 133 o A Roughtime client can roughly detect (with no absolute guarantee) 134 a delay attack [DelayAttacks] but can not cryptographically prove 135 this to a third party. However, the absence of proof of 136 malfeasance should not be considered a proof of absence of 137 malfeasance. So Roughtime should not be used as a witness that a 138 server is overall "good". 140 o Note that delay attacks cannot be detected/stopped by any 141 protocol. Delay attacks can not, however, undermine the security 142 guarantees provided by Roughtime. 144 o Although delay attacks cannot be prevented, they can be limited to 145 a predetermined upper bound. This can be done by defining a 146 maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a 147 Roughtime client is willing to accept. A Roughtime client can 148 measure the RTT of every request-response handshake and compare it 149 to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding server 150 is assumed to be a falseticker. When this approach is used the 151 maximal time error that can be caused by a delay attack is MAX- 152 RTT/2. It should be noted that this approach assumes that the 153 nature of the system is known to the client, including reasonable 154 upper bounds on the RTT value. 156 2. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 3. Protocol Overview 166 Roughtime is a protocol for rough time synchronization that enables 167 clients to provide cryptographic proof of server malfeasance. It 168 does so by having responses from servers include a signature with a 169 certificate rooted in a long-term public/private key pair over a 170 value derived from a nonce provided by the client in its request. 171 This provides cryptographic proof that the timestamp was issued after 172 the server received the client's request. The derived value included 173 in the server's response is the root of a Merkle tree which includes 174 the hash of the client's nonce as the value of one of its leaf nodes. 175 This enables the server to amortize the relatively costly signing 176 operation over a number of client requests. 178 Single server mode: At its most basic level, Roughtime is a one round 179 protocol in which a completely fresh client requests the current time 180 and the server sends a signed response. The response includes a 181 timestamp and a radius used to indicate the server's certainty about 182 the reported time. For example, a radius of 1,000,000 microseconds 183 means the server is absolutely confident that the true time is within 184 one second of the reported time. 186 The server proves freshness of its response as follows: The client's 187 request contains a nonce. The server incorporates the nonce into its 188 signed response so that the client can verify the server's signatures 189 covering the nonce issued by the client. Provided that the nonce has 190 sufficient entropy, this proves that the signed response could only 191 have been generated after the nonce. 193 Chaining multiple servers: For subsequent requests, the client 194 generates a new nonce by hashing the reply from the previous server 195 with a random value (a blind). This proves that the nonce was 196 created after the reply from the previous server. It sends the new 197 nonce in a request to the next server and receives a response that 198 includes a signature covering the nonce. 200 Cryptographic proof of misbehavior: If the time from the second 201 server is before the first, then the client has proof that at least 202 one of the servers is misbehaving; the reply from the second server 203 implicitly shows that it was created later because of the way that 204 the client constructed the nonce. If the time from the second server 205 is too far in the future, the client can contact the first server 206 again with a new nonce generated from the second server's response 207 and get a signature that was provably created afterwards, but with an 208 earlier timestamp. 210 With only two servers, the client can end up with proof that 211 something is wrong, but no idea what the correct time is. But with 212 half a dozen or more independent servers, the client will end up with 213 chain of proof of any server's misbehavior, signed by several others, 214 and (presumably) enough accurate replies to establish what the 215 correct time is. Furthermore, this proof may be validated by third 216 parties ultimately leading to a revocation of trust in the 217 misbehaving server. 219 4. The Guarantee 221 A Roughtime server guarantees that a response to a query sent at t_1, 222 received at t_2, and with timestamp t_3 has been created between the 223 transmission of the query and its reception. If t_3 is not within 224 that interval, a server inconsistency may be detected and used to 225 impeach the server. The propagation of such a guarantee and its use 226 of type synchronization is discussed in Section 7. No delay attacker 227 may affect this: they may only expand the interval between t_1 and 228 t_2, or of course stop the measurement in the first place. 230 5. Message Format 232 Roughtime messages are maps consisting of one or more (tag, value) 233 pairs. They start with a header, which contains the number of pairs, 234 the tags, and value offsets. The header is followed by a message 235 values section which contains the values associated with the tags in 236 the header. Messages MUST be formatted according to Figure 1 as 237 described in the following sections. 239 Messages may be recursive, i.e. the value of a tag can itself be a 240 Roughtime message. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Number of pairs (uint32) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 . . 249 . N-1 offsets (uint32) . 250 . . 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 . . 255 . N tags (uint32) . 256 . . 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 . . 261 . Values . 262 . . 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1: Roughtime Message Format 268 5.1. Data Types 270 5.1.1. int32 272 An int32 is a 32 bit signed integer. It is serialized in sign- 273 magitude representation with the sign bit in the most significant 274 bit. It is serialized least significant byte first. The negative 275 zero value (0x80000000) MUST NOT be used. 277 5.1.2. uint32 279 A uint32 is a 32 bit unsigned integer. It is serialized with the 280 least significant byte first. 282 5.1.3. uint64 284 A uint64 is a 64 bit unsigned integer. It is serialized with the 285 least significant byte first. 287 5.1.4. Tag 289 Tags are used to identify values in Roughtime messages. A tag is a 290 uint32 but may also be listed as a sequence of up to four ASCII 291 characters [RFC0020]. ASCII strings shorter than four characters can 292 be unambiguously converted to tags by padding them with zero bytes. 293 For example, the ASCII string "NONC" would correspond to the tag 294 0x434e4f4e and "PAD" would correspond to 0x00444150. 296 5.1.5. Timestamp 298 A timestamp is a uint64 interpreted in the following way. The most 299 significant 3 bytes contain the integer part of a Modified Julian 300 Date (MJD). The least significant 5 bytes is a count of the number 301 of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6] 302 since midnight on that day. 304 The MJD is the number of UTC days since 17 November 1858 305 [ITU-R_TF.457-2]. 307 Note that, unlike NTP, this representation does not use the full 308 number of bits in the fractional part and that days with leap seconds 309 will have more or fewer than the nominal 86,400,000,000 microseconds. 311 5.2. Header 313 All Roughtime messages start with a header. The first four bytes of 314 the header is the uint32 number of tags N, and hence of (tag, value) 315 pairs. The following 4*(N-1) bytes are offsets, each a uint32. The 316 last 4*N bytes in the header are tags. 318 Offsets refer to the positions of the values in the message values 319 section. All offsets MUST be multiples of four and placed in 320 increasing order. The first post-header byte is at offset 0. The 321 offset array is considered to have a not explicitly encoded value of 322 0 as its zeroth entry. The value associated with the ith tag begins 323 at offset[i] and ends at offset[i+1]-1, with the exception of the 324 last value which ends at the end of the message. Values may have 325 zero length. 327 Tags MUST be listed in the same order as the offsets of their values. 328 A tag MUST NOT appear more than once in a header. 330 6. Protocol 332 As described in Section 3, clients initiate time synchronization by 333 sending requests containing a nonce to servers who send signed time 334 responses in return. Roughtime packets can be sent between clients 335 and servers either as UDP datagrams or via TCP streams. Servers 336 SHOULD support the UDP transport mode, while TCP transport is 337 OPTIONAL. 339 A Roughtime packet MUST be formatted according to Figure 2 and as 340 described here. The first field is a uint64 with the value 341 0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a 342 uint32 and contains the length of the third field. The third and 343 last field contains a Roughtime message as specified in Section 5.1. 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | 0x4d49544847554f52 (uint32) | 349 | ("ROUGHTIM") | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Message length (uint32) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 . . 355 . Roughtime message . 356 . . 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 2: Roughtime Packet Format 362 Roughtime request and response packets MUST be transmitted in a 363 single datagram when the UDP transport mode is used. Setting the 364 packet's don't fragment bit [RFC0791] is OPTIONAL in IPv4 networks. 366 Multiple requests and responses can be exchanged over an established 367 TCP connection. Clients MAY send multiple requests at once and 368 servers MAY send responses out of order. The connection SHOULD be 369 closed by the client when it has no more requests to send and has 370 received all expected responses. Either side SHOULD close the 371 connection in response to synchronization, format, implementation- 372 defined timeouts, or other errors. 374 All requests and responses MUST contain the VER tag. It contains a 375 list of one or more uint32 version numbers. The version of Roughtime 376 specified by this memo has version number 1. 378 For testing drafts of this memo, a version number of 0x80000000 plus 379 the draft number is used. 381 6.1. Requests 383 A request is a Roughtime message with the tags NONC and VER. Over a 384 UDP connection the size of the request message SHOULD be at least 385 1024 bytes. To attain this size the PAD tag SHOULD be added to the 386 message. Tags other than NONC and VER SHOULD be ignored by the 387 server. Responding to requests shorter than 1024 bytes is OPTIONAL 388 and servers MUST NOT send responses larger than the requests they are 389 replying to. 391 The value of the NONC tag is a 64 byte nonce. It SHOULD be generated 392 by hashing a previous Roughtime response message together with a 393 blind as described in Section 8. If no previous responses are 394 avaiable to the client, the nonce SHOULD be generated at random. 396 In a request, the VER tag contains a list of versions. The VER tag 397 MUST include at least one Roughtime version supported by the client. 398 The client MUST ensure that the version numbers and tags included in 399 the request are not incompatible with each other or the packet 400 contents. 402 The PAD tag SHOULD be used by clients to ensure their request 403 messages are at least 1024 bytes in size. Its value SHOULD be all 404 zeros. 406 6.2. Responses 408 A response MUST contain the tags SREP, SIG, CERT, INDX, PATH and VER. 409 The SIG tag is a signature over the SREP value using the public key 410 contained in CERT, as explained below. 412 The SREP tag contains a time response. Its value is a Roughtime 413 message with the tags ROOT, MIDP, and RADI, and NONC. The server MAY 414 include any of the tags DUT1, DTAI and LEAP in the contents of the 415 SREP tag. 417 The ROOT tag contains a 32 byte value of a Merkle tree root as 418 described in Section 6.3. 420 The MIDP tag value is a timestamp of the moment of processing. 422 The RADI tag value is a uint32 representing the server's estimate of 423 the accuracy of MIDP in microseconds. Servers MUST ensure that the 424 true time is within (MIDP-RADI, MIDP+RADI) at the time they compose 425 the response message. 427 The NONC tag contains the nonce of the message being responded to. 429 The DUT1 tag value is an int32 indicating the predicted difference 430 between UT1 and UTC (UT1 - UTC) in milliseconds as given by the 431 International Earth Rotation and Reference Systems Service (IERS). 433 The DTAI tag value is an int32 indicating the current difference 434 between International Atomic Time (TAI) and UTC (TAI - UTC) in 435 milliseconds as published in the International Bureau of Weights and 436 Measures' (BIPM) Circular T. 438 The LEAP tag contains zero or more int32 values. Each value 439 represents the MJD of a past or future leap second event. Positive 440 values represent the addition of a second at the indicated date and 441 negative values represent the removal of a second at the indicated 442 (negative) date. The first item in the list MUST be the last (past 443 or future) leap second event that the server knows about. The leap 444 second events MUST be sorted in reverse chronological order. A leap 445 tag with zero int32 values indicates that the server does not hold 446 any updated leap second information. 448 The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a 449 signature context concatenated with the entire value of a DELE or 450 SREP tag. Signatures of DELE tags MUST use the ASCII string 451 "RoughTime v1 delegation signature--" and signatures of SREP tags 452 MUST use the ASCII string "RoughTime v1 response signature" as 453 signature context. Both strings MUST include a terminating zero 454 byte. 456 The CERT tag contains a public-key certificate signed with the 457 server's long-term key. Its value is a Roughtime message with the 458 tags DELE and SIG, where SIG is a signature over the DELE value. 460 The DELE tag contains a delegated public-key certificate used by the 461 server to sign the SREP tag. Its value is a Roughtime message with 462 the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to 463 enable separation of a long-term public key from keys on devices 464 exposed to the public Internet. 466 The MINT tag is the minimum timestamp for which the key in PUBK is 467 trusted to sign responses. MIDP MUST be more than or equal to MINT 468 for a response to be considered valid. 470 The MAXT tag is the maximum timestamp for which the key in PUBK is 471 trusted to sign responses. MIDP MUST be less than or equal to MAXT 472 for a response to be considered valid. 474 The PUBK tag contains a temporary 32 byte Ed25519 public key which is 475 used to sign the SREP tag. 477 The INDX tag value is a uint32 determining the position of NONC in 478 the Merkle tree used to generate the ROOT value as described in 479 Section 6.3. 481 The PATH tag value is a multiple of 32 bytes long and represents a 482 path of 32 byte hash values in the Merkle tree used to generate the 483 ROOT value as described in Section 6.3. In the case where a response 484 is prepared for a single request and the Merkle tree contains only 485 the root node, the size of PATH is zero. 487 In a response, the VER tag MUST contain a single version number. It 488 SHOULD be one of the version numbers supplied by the client in its 489 request. The server MUST ensure that the version number corresponds 490 with the rest of the packet contents. 492 6.3. The Merkle Tree 494 A Merkle tree is a binary tree where the value of each non-leaf node 495 is a hash value derived from its two children. The root of the tree 496 is thus dependent on all leaf nodes. 498 In Roughtime, each leaf node in the Merkle tree represents the nonce 499 of one request that a response message is sent in reply to. Leaf 500 nodes are indexed left to right, beginning with zero. 502 The values of all nodes are calculated from the leaf nodes and up 503 towards the root node using the first 32 bytes of the output of the 504 SHA-512 hash algorithm [RFC6234]. For leaf nodes, the byte 0x00 is 505 prepended to the nonce before applying the hash function. For all 506 other nodes, the byte 0x01 is concatenated with first the left and 507 then the right child node value before applying the hash function. 509 The value of the Merkle tree's root node is included in the ROOT tag 510 of the response. 512 The index of a request's nonce node is included in the INDX tag of 513 the response. 515 The values of all sibling nodes in the path between a request's nonce 516 node and the root node is stored in the PATH tag so that the client 517 can reconstruct and validate the value in the ROOT tag using its 518 nonce. 520 6.3.1. Root Value Validity Check Algorithm 522 One starts by computing the hash of the NONC value from the request, 523 with 0x00 prepended. Then one walks from the least significant bit 524 of INDX to the most significant bit, and also walks towards the end 525 of PATH. 527 If PATH ends then the remaining bits of the INDX MUST be all zero. 528 This indicates the termination of the walk, and the current value 529 MUST equal ROOT if the response is valid. 531 If the current bit is 0, one hashes 0x01, the current hash, and the 532 value from PATH to derive the next current value. 534 If the current bit is 1 one hashes 0x01, the value from PATH, and the 535 current hash to derive the next current value. 537 6.4. Validity of Response 539 A client MUST check the following properties when it receives a 540 response. We assume the long-term server public key is known to the 541 client through other means. 543 o The signature in CERT was made with the long-term key of the 544 server. 546 o The DELE timestamps and the MIDP value are consistent. 548 o The INDX and PATH values prove NONC was included in the Merkle 549 tree with value ROOT using the algorithm in Section 6.3.1. 551 o The signature of SREP in SIG validates with the public key in 552 DELE. 554 A response that passes these checks is said to be valid. Validity of 555 a response does not prove the time is correct, but merely that the 556 server signed it, and thus guarantees that it began to compute the 557 signature at a time in the interval (MIDP-RADI, MIDP+RADI). 559 7. Integration into NTP 561 We assume that there is a bound PHI on the frequency error in the 562 clock on the machine. Given a measurement taken at a local time t1, 563 we know the true time is in [ t1-delta-sigma, t1-delta+sigma ]. 564 After d seconds have elapsed we know the true time is within [ t1- 565 delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way 566 to mix with NTP or PTP discipline of the clock is to trim the 567 observed intervals in NTP to fit entirely within this window or 568 reject measurements that fall to far outside. This assumes time has 569 not been stepped. If the NTP process decides to step the time, it 570 MUST use Roughtime to ensure the new truetime estimate that will be 571 stepped to is consistent with the true time. 573 Should this window become too large, another Roughtime measurement is 574 called for. The definition of "too large" is implementation defined. 576 Implementations MAY use other, more sophisticated means of adjusting 577 the clock respecting Roughtime information. 579 8. Cheater Detection 581 A chain of responses is a series of responses where the SHA-512 hash 582 of the preceding response H, is concatenated with a 64 byte blind X, 583 and then SHA-512(H, X) is the nonce used in the subsequent response. 584 These may be represented as an array of objects in JavaScript Object 585 Notation (JSON) format [RFC8259] where each object may have keys 586 "blind" and "response_packet". Packet has the Base64 [RFC4648] 587 encoded bytes of the packet and blind is the Base64 encoded blind 588 used for the next nonce. The last packet needs no blind. 590 A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > 591 MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j 592 such that i < j, (r_i, r_j) is an invalid pair. 594 Invalidity of a chain is proof that causality has been violated if 595 all servers were reporting correct time. An invalid chain where all 596 individual responses are valid is cryptographic proof of malfeasance 597 of at least one server: if all servers had the correct time in the 598 chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. 600 In conducting the comparison of timestamps one must know the length 601 of a day and hence have historical leap second data for the days in 602 question. However if violations are greater then a second the loss 603 of leap second data doesn't impede their detection. 605 9. Grease 607 Servers MAY send back a fraction of responses that are syntactically 608 invalid or contain invalid signatures as well as incorrect times. 609 Clients MUST properly reject such responses. Servers MUST NOT send 610 back responses with incorrect times and valid signatures. Either 611 signature MAY be invalid for this application. 613 10. Roughtime Servers 615 The below list contains a list of servers with their public keys in 616 Base64 format. These servers may implement older versions of this 617 specification. 619 address: roughtime.cloudflare.com 620 port: 2002 621 long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= 623 address: roughtime.int08h.com 624 port: 2002 625 long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 627 address: roughtime.sandbox.google.com 628 port: 2002 629 long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 631 address: roughtime.se 632 port: 2002 633 long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= 635 11. Trust Anchors and Policies 637 A trust anchor is any distributor of a list of trusted servers. It 638 is RECOMMENDED that trust anchors subscribe to a common public forum 639 where evidence of malfeasance may be shared and discussed. Trust 640 anchors SHOULD subscribe to a zero-tolerance policy: any generation 641 of incorrect timestamps will result in removal. To enable this trust 642 anchors SHOULD list a wide variety of servers so the removal of a 643 server does not result in operational issues for clients. Clients 644 SHOULD attempt to detect malfeasance and have a way to report it to 645 trust anchors. 647 Because only a single Roughtime server is required for successful 648 synchronization, Roughtime does not have the incentive problems that 649 have prevented effective enforcement of discipline on the web PKI. 650 We expect that some clients will aggressively monitor server 651 behavior. 653 12. Acknowledgements 655 Marcus Dansarie contributed many fruitful ideas. Thomas Peterson 656 corrected multiple nits. Peter Loethberg (Lothberg), Tal Mizrahi, 657 Ragnar Sundblad, Kristof Teichel, and the other members of the NTP 658 working group contributed comments and suggestions. 660 13. IANA Considerations 662 13.1. Service Name and Transport Protocol Port Number Registry 664 IANA is requested to allocate the following entry in the Service Name 665 and Transport Protocol Port Number Registry [RFC6335]: 667 Service Name: Roughtime 669 Transport Protocol: tcp,udp 671 Assignee: IESG 673 Contact: IETF Chair 675 Description: Roughtime time synchronization 677 Reference: [[this memo]] 679 Port Number: [[TBD1]], selected by IANA from the User Port range 681 13.2. Roughtime Version Registry 683 IANA is requested to create a new registry entitled " Roughtime 684 Version Registry " Entries shall have the following fields: 686 Version (REQUIRED): a 32-bit unsigned integer 688 Reference (REQUIRED): the description of the version 690 The policy for allocation of new entries SHOULD be IETF consensus. 691 Versions with the high bit set are reserved. 693 The initial contents of this registry shall be as follows: 695 +---------+---------------+ 696 | Version | Reference | 697 +---------+---------------+ 698 | 1 | [[this memo]] | 699 +---------+---------------+ 701 13.3. Roughtime Tag Registry 703 IANA is requested to create a new registry entitled "Roughtime Tag 704 Registry". Entries SHALL have the following fields: 706 Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. 708 ASCII Representation (OPTIONAL): The ASCII representation of the 709 tag in accordance with Section 5.1.4 of this memo, if applicable. 711 Reference (REQUIRED): A reference to a relevant specification 712 document. 714 The policy for allocation of new entries in this registry SHOULD be: 715 Specification Required. 717 The initial contents of this registry SHALL be as follows: 719 +------------+----------------------+---------------+ 720 | Tag | ASCII Representation | Reference | 721 +------------+----------------------+---------------+ 722 | 0x00444150 | PAD | [[this memo]] | 723 | 0x00474953 | SIG | [[this memo]] | 724 | 0x00524556 | VER | [[this memo]] | 725 | 0x31545544 | DUT1 | [[this memo]] | 726 | 0x434e4f48 | NONC | [[this memo]] | 727 | 0x454c4544 | DELE | [[this memo]] | 728 | 0x48544150 | PATH | [[this memo]] | 729 | 0x49415444 | DTAI | [[this memo]] | 730 | 0x49444152 | RADI | [[this memo]] | 731 | 0x4b425550 | PUBK | [[this memo]] | 732 | 0x5041454c | LEAP | [[this memo]] | 733 | 0x5044494d | MIDP | [[this memo]] | 734 | 0x50455253 | SREP | [[this memo]] | 735 | 0x544e494d | MINT | [[this memo]] | 736 | 0x544f4f52 | ROOT | [[this memo]] | 737 | 0x54524543 | CERT | [[this memo]] | 738 | 0x5458414d | MAXT | [[this memo]] | 739 | 0x58444e49 | INDX | [[this memo]] | 740 +------------+----------------------+---------------+ 742 14. Security Considerations 744 Since the only supported signature scheme, Ed25519, is not quantum 745 resistant, this protocol will not survive the advent of quantum 746 computers. 748 Maintaining a list of trusted servers and adjudicating violations of 749 the rules by servers is not discussed in this document and is 750 essential for security. Roughtime clients MUST update their view of 751 which servers are trustworthy in order to benefit from the detection 752 of misbehavior. 754 Validating timestamps made on different dates requires knowledge of 755 leap seconds in order to calculate time intervals correctly. 757 Servers carry out a significant amount of computation in response to 758 clients, and thus may experience vulnerability to denial of service 759 attacks. 761 This protocol does not provide any confidentiality, and given the 762 nature of timestamps such impact is minor. 764 The compromise of a PUBK's private key, even past MAXT, is a problem 765 as the private key can be used to sign invalid times that are in the 766 range MINT to MAXT, and thus violate the good behavior guarantee of 767 the server. 769 Servers MUST NOT send response packets larger than the request 770 packets sent by clients, in order to prevent amplification attacks. 772 15. Privacy Considerations 774 This protocol is designed to obscure all client identifiers. Servers 775 necessarily have persistent long-term identities essential to 776 enforcing correct behavior. Generating nonces from previous 777 responses without using a blind can enable tracking of clients as 778 they move between networks. 780 16. References 782 16.1. Normative References 784 [ITU-R_TF.457-2] 785 ITU-R, "Use of the Modified Julian Date by the Standard- 786 Frequency and Time-Signal Services", ITU-R 787 Recommendation TF.457-2, October 1997. 789 [ITU-R_TF.460-6] 790 ITU-R, "Standard-Frequency and Time-Signal Emissions", 791 ITU-R Recommendation TF.460-6, February 2002. 793 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 794 RFC 20, DOI 10.17487/RFC0020, October 1969, 795 . 797 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 798 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 799 . 801 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 802 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 803 DOI 10.17487/RFC6234, May 2011, 804 . 806 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 807 Cheshire, "Internet Assigned Numbers Authority (IANA) 808 Procedures for the Management of the Service Name and 809 Transport Protocol Port Number Registry", BCP 165, 810 RFC 6335, DOI 10.17487/RFC6335, August 2011, 811 . 813 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 814 Signature Algorithm (EdDSA)", RFC 8032, 815 DOI 10.17487/RFC8032, January 2017, 816 . 818 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 819 Interchange Format", STD 90, RFC 8259, 820 DOI 10.17487/RFC8259, December 2017, 821 . 823 16.2. Informative References 825 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 826 2012, . 828 [DelayAttacks] 829 Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks 830 Against Time Synchronization Protocols", 831 DOI 10.1109/ISPCS.2012.6336612, 2012, 832 . 834 [I-D.ietf-ntp-using-nts-for-ntp] 835 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 836 Sundblad, "Network Time Security for the Network Time 837 Protocol", draft-ietf-ntp-using-nts-for-ntp-25 (work in 838 progress), March 2020. 840 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 841 "Attacking the Network Time Protocol", 2015, 842 . 844 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 845 DOI 10.17487/RFC0768, August 1980, 846 . 848 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 849 DOI 10.17487/RFC0791, September 1981, 850 . 852 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 853 RFC 793, DOI 10.17487/RFC0793, September 1981, 854 . 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, 858 DOI 10.17487/RFC2119, March 1997, 859 . 861 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 862 "Network Time Protocol Version 4: Protocol and Algorithms 863 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 864 . 866 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 867 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 868 October 2014, . 870 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 871 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 872 May 2017, . 874 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 875 for the Network Time Protocol", RFC 8573, 876 DOI 10.17487/RFC8573, June 2019, 877 . 879 Appendix A. Terms and Abbreviations 881 ASCII American Standard Code for Information Interchange 883 IANA Internet Assigned Numbers Authority 885 JSON JavaScript Object Notation [RFC8259] 887 MJD Modified Julian Date 889 NTP Network Time Protocol [RFC5905] 891 NTS Network Time Security [I-D.ietf-ntp-using-nts-for-ntp] 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] 899 UT Universal Time [ITU-R_TF.460-6] 901 UTC Coordinated Universal Time [ITU-R_TF.460-6] 903 Authors' Addresses 905 Aanchal Malhotra 906 Boston University 907 111 Cummington Mall 908 Boston 02215 909 USA 911 Email: aanchal4@bu.edu 913 Adam Langley 914 Google 916 Email: 917 agl@google.com 919 Watson Ladd 920 Cloudflare 921 101 Townsend St 922 San Francisco 923 USA 925 Email: watsonbladd@gmail.com