idnits 2.17.1 draft-ietf-ntp-roughtime-02.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 (June 01, 2020) is 1418 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6234' is defined on line 804, but no explicit reference was found in the text == 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 (~~), 4 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: December 3, 2020 Google 6 W. Ladd 7 Cloudflare 8 June 01, 2020 10 Roughtime 11 draft-ietf-ntp-roughtime-02 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 December 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . 14 76 11. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 14 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 13.1. Service Name and Transport Protocol Port Number Registry 15 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]. It is useful to note that 1 January 1970 is 40,587 306 days after 17 November 1858. 308 Note that, unlike NTP, this representation does not use the full 309 number of bits in the fractional part and that days with leap seconds 310 will have more or fewer than the nominal 86,400,000,000 microseconds. 312 5.2. Header 314 All Roughtime messages start with a header. The first four bytes of 315 the header is the uint32 number of tags N, and hence of (tag, value) 316 pairs. The following 4*(N-1) bytes are offsets, each a uint32. The 317 last 4*N bytes in the header are tags. 319 Offsets refer to the positions of the values in the message values 320 section. All offsets MUST be multiples of four and placed in 321 increasing order. The first post-header byte is at offset 0. The 322 offset array is considered to have a not explicitly encoded value of 323 0 as its zeroth entry. The value associated with the ith tag begins 324 at offset[i] and ends at offset[i+1]-1, with the exception of the 325 last value which ends at the end of the message. Values may have 326 zero length. 328 Tags MUST be listed in the same order as the offsets of their values. 329 A tag MUST NOT appear more than once in a header. Tags MUST also be 330 sorted by numeric value. 332 6. Protocol 334 As described in Section 3, clients initiate time synchronization by 335 sending requests containing a nonce to servers who send signed time 336 responses in return. Roughtime packets can be sent between clients 337 and servers either as UDP datagrams or via TCP streams. Servers 338 SHOULD support the UDP transport mode, while TCP transport is 339 OPTIONAL. 341 A Roughtime packet MUST be formatted according to Figure 2 and as 342 described here. The first field is a uint64 with the value 343 0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a 344 uint32 and contains the length of the third field. The third and 345 last field contains a Roughtime message as specified in Section 5.1. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | 0x4d49544847554f52 (uint64) | 351 | ("ROUGHTIM") | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Message length (uint32) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 . . 357 . Roughtime message . 358 . . 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 2: Roughtime Packet Format 364 Roughtime request and response packets MUST be transmitted in a 365 single datagram when the UDP transport mode is used. Setting the 366 packet's don't fragment bit [RFC0791] is OPTIONAL in IPv4 networks. 368 Multiple requests and responses can be exchanged over an established 369 TCP connection. Clients MAY send multiple requests at once and 370 servers MAY send responses out of order. The connection SHOULD be 371 closed by the client when it has no more requests to send and has 372 received all expected responses. Either side SHOULD close the 373 connection in response to synchronization, format, implementation- 374 defined timeouts, or other errors. 376 All requests and responses MUST contain the VER tag. It contains a 377 list of one or more uint32 version numbers. The version of Roughtime 378 specified by this memo has version number 1. 380 For testing drafts of this memo, a version number of 0x80000000 plus 381 the draft number is used. 383 6.1. Requests 385 A request is a Roughtime message with the tags NONC and VER. Over a 386 UDP connection the size of the request message SHOULD be at least 387 1024 bytes. To attain this size the PAD tag SHOULD be added to the 388 message. Tags other than NONC and VER SHOULD be ignored by the 389 server. Responding to requests shorter than 1024 bytes is OPTIONAL 390 and servers MUST NOT send responses larger than the requests they are 391 replying to. 393 The value of the NONC tag is a 64 byte nonce. It SHOULD be generated 394 by hashing a previous Roughtime response message together with a 395 blind as described in Section 8. If no previous responses are 396 avaiable to the client, the nonce SHOULD be generated at random. 398 In a request, the VER tag contains a list of versions. The VER tag 399 MUST include at least one Roughtime version supported by the client. 400 The client MUST ensure that the version numbers and tags included in 401 the request are not incompatible with each other or the packet 402 contents. 404 The PAD tag SHOULD be used by clients to ensure their request 405 messages are at least 1024 bytes in size. Its value SHOULD be all 406 zeros. 408 6.2. Responses 410 A response MUST contain the tags SREP, SIG, CERT, INDX, PATH and VER. 411 The SIG tag is a signature over the SREP value using the public key 412 contained in CERT, as explained below. 414 The SREP tag contains a time response. Its value is a Roughtime 415 message with the tags ROOT, MIDP, and RADI, and NONC. The server MAY 416 include any of the tags DUT1, DTAI and LEAP in the contents of the 417 SREP tag. 419 The ROOT tag contains a 32 byte value of a Merkle tree root as 420 described in Section 6.3. 422 The MIDP tag value is a timestamp of the moment of processing. 424 The RADI tag value is a uint32 representing the server's estimate of 425 the accuracy of MIDP in microseconds. Servers MUST ensure that the 426 true time is within (MIDP-RADI, MIDP+RADI) at the time they compose 427 the response message. 429 The NONC tag contains the nonce of the message being responded to. 431 The DUT1 tag value is an int32 indicating the predicted difference 432 between UT1 and UTC (UT1 - UTC) in milliseconds as given by the 433 International Earth Rotation and Reference Systems Service (IERS). 435 The DTAI tag value is an int32 indicating the current difference 436 between International Atomic Time (TAI) and UTC (TAI - UTC) in 437 milliseconds as published in the International Bureau of Weights and 438 Measures' (BIPM) Circular T. 440 The LEAP tag contains zero or more int32 values. Each value 441 represents the MJD of a past or future leap second event. Positive 442 values represent the addition of a second at the indicated date and 443 negative values represent the removal of a second at the indicated 444 (negative) date. The first item in the list MUST be the last (past 445 or future) leap second event that the server knows about. The leap 446 second events MUST be sorted in reverse chronological order. A leap 447 tag with zero int32 values indicates that the server does not hold 448 any updated leap second information. 450 The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a 451 signature context concatenated with the entire value of a DELE or 452 SREP tag. Signatures of DELE tags MUST use the ASCII string 453 "RoughTime v1 delegation signature--" and signatures of SREP tags 454 MUST use the ASCII string "RoughTime v1 response signature" as 455 signature context. Both strings MUST include a terminating zero 456 byte. 458 The CERT tag contains a public-key certificate signed with the 459 server's long-term key. Its value is a Roughtime message with the 460 tags DELE and SIG, where SIG is a signature over the DELE value. 462 The DELE tag contains a delegated public-key certificate used by the 463 server to sign the SREP tag. Its value is a Roughtime message with 464 the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to 465 enable separation of a long-term public key from keys on devices 466 exposed to the public Internet. 468 The MINT tag is the minimum timestamp for which the key in PUBK is 469 trusted to sign responses. MIDP MUST be more than or equal to MINT 470 for a response to be considered valid. 472 The MAXT tag is the maximum timestamp for which the key in PUBK is 473 trusted to sign responses. MIDP MUST be less than or equal to MAXT 474 for a response to be considered valid. 476 The PUBK tag contains a temporary 32 byte Ed25519 public key which is 477 used to sign the SREP tag. 479 The INDX tag value is a uint32 determining the position of NONC in 480 the Merkle tree used to generate the ROOT value as described in 481 Section 6.3. 483 The PATH tag value is a multiple of 32 bytes long and represents a 484 path of 32 byte hash values in the Merkle tree used to generate the 485 ROOT value as described in Section 6.3. In the case where a response 486 is prepared for a single request and the Merkle tree contains only 487 the root node, the size of PATH is zero. 489 In a response, the VER tag MUST contain a single version number. It 490 SHOULD be one of the version numbers supplied by the client in its 491 request. The server MUST ensure that the version number corresponds 492 with the rest of the packet contents. 494 6.3. The Merkle Tree 496 A Merkle tree is a binary tree where the value of each non-leaf node 497 is a hash value derived from its two children. The root of the tree 498 is thus dependent on all leaf nodes. 500 In Roughtime, each leaf node in the Merkle tree represents the nonce 501 of one request that a response message is sent in reply to. Leaf 502 nodes are indexed left to right, beginning with zero. 504 The values of all nodes are calculated from the leaf nodes and up 505 towards the root node using the first 32 bytes of the output of the 506 SHA-512/256 hash algorithm [SHS]. For leaf nodes, the byte 0x00 is 507 prepended to the nonce before applying the hash function. For all 508 other nodes, the byte 0x01 is concatenated with first the left and 509 then the right child node value before applying the hash function. 511 The value of the Merkle tree's root node is included in the ROOT tag 512 of the response. 514 The index of a request's nonce node is included in the INDX tag of 515 the response. 517 The values of all sibling nodes in the path between a request's nonce 518 node and the root node is stored in the PATH tag so that the client 519 can reconstruct and validate the value in the ROOT tag using its 520 nonce. 522 6.3.1. Root Value Validity Check Algorithm 524 One starts by computing the hash of the NONC value from the request, 525 with 0x00 prepended. Then one walks from the least significant bit 526 of INDX to the most significant bit, and also walks towards the end 527 of PATH. 529 If PATH ends then the remaining bits of the INDX MUST be all zero. 530 This indicates the termination of the walk, and the current value 531 MUST equal ROOT if the response is valid. 533 If the current bit is 0, one hashes 0x01, the current hash, and the 534 value from PATH to derive the next current value. 536 If the current bit is 1 one hashes 0x01, the value from PATH, and the 537 current hash to derive the next current value. 539 6.4. Validity of Response 541 A client MUST check the following properties when it receives a 542 response. We assume the long-term server public key is known to the 543 client through other means. 545 o The signature in CERT was made with the long-term key of the 546 server. 548 o The DELE timestamps and the MIDP value are consistent. 550 o The INDX and PATH values prove NONC was included in the Merkle 551 tree with value ROOT using the algorithm in Section 6.3.1. 553 o The signature of SREP in SIG validates with the public key in 554 DELE. 556 A response that passes these checks is said to be valid. Validity of 557 a response does not prove the time is correct, but merely that the 558 server signed it, and thus guarantees that it began to compute the 559 signature at a time in the interval (MIDP-RADI, MIDP+RADI). 561 7. Integration into NTP 563 We assume that there is a bound PHI on the frequency error in the 564 clock on the machine. Given a measurement taken at a local time t1, 565 we know the true time is in [ t1-delta-sigma, t1-delta+sigma ]. 566 After d seconds have elapsed we know the true time is within [ t1- 567 delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way 568 to mix with NTP or PTP discipline of the clock is to trim the 569 observed intervals in NTP to fit entirely within this window or 570 reject measurements that fall to far outside. This assumes time has 571 not been stepped. If the NTP process decides to step the time, it 572 MUST use Roughtime to ensure the new truetime estimate that will be 573 stepped to is consistent with the true time. 575 Should this window become too large, another Roughtime measurement is 576 called for. The definition of "too large" is implementation defined. 578 Implementations MAY use other, more sophisticated means of adjusting 579 the clock respecting Roughtime information. 581 8. Cheater Detection 583 A chain of responses is a series of responses where the SHA-512/256 584 hash of the preceding response H, is concatenated with a 64 byte 585 blind X, and then SHA-512/256(H, X) is the nonce used in the 586 subsequent response. These may be represented as an array of objects 587 in JavaScript Object Notation (JSON) format [RFC8259] where each 588 object may have keys "blind" and "response_packet". Packet has the 589 Base64 [RFC4648] encoded bytes of the packet and blind is the Base64 590 encoded blind used for the next nonce. The last packet needs no 591 blind. 593 A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > 594 MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j 595 such that i < j, (r_i, r_j) is an invalid pair. 597 Invalidity of a chain is proof that causality has been violated if 598 all servers were reporting correct time. An invalid chain where all 599 individual responses are valid is cryptographic proof of malfeasance 600 of at least one server: if all servers had the correct time in the 601 chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. 603 In conducting the comparison of timestamps one must know the length 604 of a day and hence have historical leap second data for the days in 605 question. However if violations are greater then a second the loss 606 of leap second data doesn't impede their detection. 608 9. Grease 610 Servers MAY send back a fraction of responses that are syntactically 611 invalid or contain invalid signatures as well as incorrect times. 612 Clients MUST properly reject such responses. Servers MUST NOT send 613 back responses with incorrect times and valid signatures. Either 614 signature MAY be invalid for this application. 616 10. Roughtime Servers 618 The below list contains a list of servers with their public keys in 619 Base64 format. These servers may implement older versions of this 620 specification. 622 address: roughtime.cloudflare.com 623 port: 2002 624 long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= 626 address: roughtime.int08h.com 627 port: 2002 628 long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 630 address: roughtime.sandbox.google.com 631 port: 2002 632 long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 634 address: roughtime.se 635 port: 2002 636 long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= 638 11. Trust Anchors and Policies 640 A trust anchor is any distributor of a list of trusted servers. It 641 is RECOMMENDED that trust anchors subscribe to a common public forum 642 where evidence of malfeasance may be shared and discussed. Trust 643 anchors SHOULD subscribe to a zero-tolerance policy: any generation 644 of incorrect timestamps will result in removal. To enable this trust 645 anchors SHOULD list a wide variety of servers so the removal of a 646 server does not result in operational issues for clients. Clients 647 SHOULD attempt to detect malfeasance and have a way to report it to 648 trust anchors. 650 Because only a single Roughtime server is required for successful 651 synchronization, Roughtime does not have the incentive problems that 652 have prevented effective enforcement of discipline on the web PKI. 653 We expect that some clients will aggressively monitor server 654 behavior. 656 12. Acknowledgements 658 Marcus Dansarie contributed many fruitful ideas. Thomas Peterson 659 corrected multiple nits. Peter Loethberg (Lothberg), Tal Mizrahi, 660 Ragnar Sundblad, Kristof Teichel, and the other members of the NTP 661 working group contributed comments and suggestions. 663 13. IANA Considerations 665 13.1. Service Name and Transport Protocol Port Number Registry 667 IANA is requested to allocate the following entry in the Service Name 668 and Transport Protocol Port Number Registry [RFC6335]: 670 Service Name: Roughtime 672 Transport Protocol: tcp,udp 674 Assignee: IESG 676 Contact: IETF Chair 678 Description: Roughtime time synchronization 680 Reference: [[this memo]] 682 Port Number: [[TBD1]], selected by IANA from the User Port range 684 13.2. Roughtime Version Registry 686 IANA is requested to create a new registry entitled " Roughtime 687 Version Registry " Entries shall have the following fields: 689 Version (REQUIRED): a 32-bit unsigned integer 691 Reference (REQUIRED): the description of the version 693 The policy for allocation of new entries SHOULD be IETF consensus. 694 Versions with the high bit set are reserved. 696 The initial contents of this registry shall be as follows: 698 +---------+---------------+ 699 | Version | Reference | 700 +---------+---------------+ 701 | 1 | [[this memo]] | 702 +---------+---------------+ 704 13.3. Roughtime Tag Registry 706 IANA is requested to create a new registry entitled "Roughtime Tag 707 Registry". Entries SHALL have the following fields: 709 Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. 711 ASCII Representation (OPTIONAL): The ASCII representation of the 712 tag in accordance with Section 5.1.4 of this memo, if applicable. 714 Reference (REQUIRED): A reference to a relevant specification 715 document. 717 The policy for allocation of new entries in this registry SHOULD be: 718 Specification Required. 720 The initial contents of this registry SHALL be as follows: 722 +------------+----------------------+---------------+ 723 | Tag | ASCII Representation | Reference | 724 +------------+----------------------+---------------+ 725 | 0x00444150 | PAD | [[this memo]] | 726 | 0x00474953 | SIG | [[this memo]] | 727 | 0x00524556 | VER | [[this memo]] | 728 | 0x31545544 | DUT1 | [[this memo]] | 729 | 0x434e4f48 | NONC | [[this memo]] | 730 | 0x454c4544 | DELE | [[this memo]] | 731 | 0x48544150 | PATH | [[this memo]] | 732 | 0x49415444 | DTAI | [[this memo]] | 733 | 0x49444152 | RADI | [[this memo]] | 734 | 0x4b425550 | PUBK | [[this memo]] | 735 | 0x5041454c | LEAP | [[this memo]] | 736 | 0x5044494d | MIDP | [[this memo]] | 737 | 0x50455253 | SREP | [[this memo]] | 738 | 0x544e494d | MINT | [[this memo]] | 739 | 0x544f4f52 | ROOT | [[this memo]] | 740 | 0x54524543 | CERT | [[this memo]] | 741 | 0x5458414d | MAXT | [[this memo]] | 742 | 0x58444e49 | INDX | [[this memo]] | 743 +------------+----------------------+---------------+ 745 14. Security Considerations 747 Since the only supported signature scheme, Ed25519, is not quantum 748 resistant, this protocol will not survive the advent of quantum 749 computers. 751 Maintaining a list of trusted servers and adjudicating violations of 752 the rules by servers is not discussed in this document and is 753 essential for security. Roughtime clients MUST update their view of 754 which servers are trustworthy in order to benefit from the detection 755 of misbehavior. 757 Validating timestamps made on different dates requires knowledge of 758 leap seconds in order to calculate time intervals correctly. 760 Servers carry out a significant amount of computation in response to 761 clients, and thus may experience vulnerability to denial of service 762 attacks. 764 This protocol does not provide any confidentiality, and given the 765 nature of timestamps such impact is minor. 767 The compromise of a PUBK's private key, even past MAXT, is a problem 768 as the private key can be used to sign invalid times that are in the 769 range MINT to MAXT, and thus violate the good behavior guarantee of 770 the server. 772 Servers MUST NOT send response packets larger than the request 773 packets sent by clients, in order to prevent amplification attacks. 775 15. Privacy Considerations 777 This protocol is designed to obscure all client identifiers. Servers 778 necessarily have persistent long-term identities essential to 779 enforcing correct behavior. Generating nonces from previous 780 responses without using a blind can enable tracking of clients as 781 they move between networks. 783 16. References 785 16.1. Normative References 787 [ITU-R_TF.457-2] 788 ITU-R, "Use of the Modified Julian Date by the Standard- 789 Frequency and Time-Signal Services", ITU-R 790 Recommendation TF.457-2, October 1997. 792 [ITU-R_TF.460-6] 793 ITU-R, "Standard-Frequency and Time-Signal Emissions", 794 ITU-R Recommendation TF.460-6, February 2002. 796 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 797 RFC 20, DOI 10.17487/RFC0020, October 1969, 798 . 800 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 801 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 802 . 804 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 805 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 806 DOI 10.17487/RFC6234, May 2011, 807 . 809 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 810 Cheshire, "Internet Assigned Numbers Authority (IANA) 811 Procedures for the Management of the Service Name and 812 Transport Protocol Port Number Registry", BCP 165, 813 RFC 6335, DOI 10.17487/RFC6335, August 2011, 814 . 816 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 817 Signature Algorithm (EdDSA)", RFC 8032, 818 DOI 10.17487/RFC8032, January 2017, 819 . 821 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 822 Interchange Format", STD 90, RFC 8259, 823 DOI 10.17487/RFC8259, December 2017, 824 . 826 [SHS] NIST, "Secure Hash Standard", FIPS 180-4, August 2015. 828 16.2. Informative References 830 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 831 2012, . 833 [DelayAttacks] 834 Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks 835 Against Time Synchronization Protocols", 836 DOI 10.1109/ISPCS.2012.6336612, 2012, 837 . 839 [I-D.ietf-ntp-using-nts-for-ntp] 840 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 841 Sundblad, "Network Time Security for the Network Time 842 Protocol", draft-ietf-ntp-using-nts-for-ntp-25 (work in 843 progress), March 2020. 845 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 846 "Attacking the Network Time Protocol", 2015, 847 . 849 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 850 DOI 10.17487/RFC0768, August 1980, 851 . 853 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 854 DOI 10.17487/RFC0791, September 1981, 855 . 857 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 858 RFC 793, DOI 10.17487/RFC0793, September 1981, 859 . 861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 862 Requirement Levels", BCP 14, RFC 2119, 863 DOI 10.17487/RFC2119, March 1997, 864 . 866 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 867 "Network Time Protocol Version 4: Protocol and Algorithms 868 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 869 . 871 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 872 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 873 October 2014, . 875 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 876 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 877 May 2017, . 879 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 880 for the Network Time Protocol", RFC 8573, 881 DOI 10.17487/RFC8573, June 2019, 882 . 884 Appendix A. Terms and Abbreviations 886 ASCII American Standard Code for Information Interchange 888 IANA Internet Assigned Numbers Authority 890 JSON JavaScript Object Notation [RFC8259] 892 MJD Modified Julian Date 894 NTP Network Time Protocol [RFC5905] 896 NTS Network Time Security [I-D.ietf-ntp-using-nts-for-ntp] 898 TAI International Atomic Time (Temps Atomique International) 899 [ITU-R_TF.460-6] 901 TCP Transmission Control Protocol [RFC0793] 903 UDP User Datagram Protocol [RFC0768] 904 UT Universal Time [ITU-R_TF.460-6] 906 UTC Coordinated Universal Time [ITU-R_TF.460-6] 908 Authors' Addresses 910 Aanchal Malhotra 911 Boston University 912 111 Cummington Mall 913 Boston 02215 914 USA 916 Email: aanchal4@bu.edu 918 Adam Langley 919 Google 921 Email: 922 agl@google.com 924 Watson Ladd 925 Cloudflare 926 101 Townsend St 927 San Francisco 928 USA 930 Email: watsonbladd@gmail.com