idnits 2.17.1 draft-roughtime-aanchal-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5280' is defined on line 428, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-17 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: September 12, 2019 Google 6 W. Ladd 7 Cloudflare 8 March 11, 2019 10 Roughtime 11 draft-roughtime-aanchal-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 September 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 1. Motivation 54 Time synchronization is essential to Internet security as many 55 security protocols and other applications require synchronization 56 [RFC7384][MCBG]. Unfortunately widely deployed protocols such as the 57 Network Time Protocol (NTP) [RFC5905] lack essential security 58 features, and even newer protocols like Network Time Security (NTS) 59 [I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers 60 behave correctly. Authenticating time servers prevents network 61 adversaries from modifying time packets, but an authenticated time 62 server still has full control over the contents of time packet and 63 may go rogue. The Roughtime protocol provides cryptographic proof of 64 malfeasance, enabling clients to detect and prove to a third party 65 server's attempts to influence the time a client computes. 67 +--------------+----------------------+-----------------------------+ 68 | Protocol | Authenticated Server | Server Malfeasance Evidence | 69 +--------------+----------------------+-----------------------------+ 70 | NTP, Chronos | N | N | 71 | NTP-MD5 | Y* | N | 72 | NTP-Autokey | Y** | N | 73 | NTS | Y | N | 74 | Roughtime | Y | Y | 75 +--------------+----------------------+-----------------------------+ 77 Security Properties of current protocols 79 Table 1 81 Y* For security issues with symmetric-key based NTP-MD5 82 authentication, please refer to Message Authentication Code for the 83 Network Time Protocol draft [I-D.ietf-ntp-mac] 85 Y** For security issues with Autokey Public Key Authentication, refer 86 to [Autokey] 88 2. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 3. Protocol Overview 98 Roughtime is a protocol for rough time synchronization that enables 99 clients to provide cryptographic proof of server malfeasance. It 100 does so by having responses from servers include a signature with a 101 certificate rooted in long term public/private key pair over a 102 portion of the initial request, thus providing cryptographic proof 103 that the timestamp was issued after previous responses and before 104 future ones. 106 Single server mode: At its most basic level, Roughtime is a one round 107 protocol in which a completely fresh client requests the current time 108 and the server sends a signed response. The response includes a 109 timestamp (the number of microseconds since the Unix epoch) and a 110 radius (in microseconds) used to indicate the server's certainty 111 about the reported time. For example, a radius of 1,000,000 112 microseconds means the server is absolutely confident that the true 113 time is within one second of the reported time. 115 The server proves freshness of its response as follows: The request 116 contains a random challenge. The server incorporates the challenge 117 into its signed response so that its needed to verify the signature. 118 This proves that the signed response could only have been generated 119 after the challenge was issued if the challenge has sufficient 120 entropy. 122 Chaining multiple servers: For subsequent requests, the client 123 generates its nonce by hashing the reply from the first server with a 124 random value. This proves that the nonce was created after the reply 125 from the first server. It sends that to the second server and 126 receives a signature from it covering that nonce and the time from 127 the second server. 129 Cryptographic proof of misbehavior: If the time from the second 130 server is before the first, then the client has proof of misbehavior; 131 the reply from the second server implicitly shows that it was created 132 later because of the way that the client constructed the nonce. If 133 the time from the second server is after, then the client can contact 134 the first server again and get a signature that was provably created 135 afterwards, but with an earlier timestamp. 137 With only two servers, the client can end up with proof that 138 something is wrong, but no idea what the correct time is. But with 139 half a dozen or more independent servers, the client will end up with 140 chain of proof of any server's misbehavior, signed by several others, 141 and (presumably) enough accurate replies to establish what the 142 correct time is. Furthermore this proof may be validated by third 143 parties ultimately leading to a revocation of trust in the 144 misbehaving server. 146 4. Message Format 148 A uint32 is a 32 bit unsigned integer. It is serialized in bytes 149 with the least significant byte first. A uint64 is a 64 bit unsigned 150 integer. It is also seralized with the least significant byte first. 152 A Roughtime packet is a UDP packet whose contents are interpreted as 153 a map from uint32s to strings of bytes. The byte strings must all 154 have lengths a multiple of four. All uint32 are encoded with the 155 least significant byte first. The keys of this map are called tags, 156 and we speak of the value of a tag as the string of bytes it is 157 mapped to. 159 A Roughtime packet is serialized as follows: First there is a header, 160 The first four bytes in the header are the uint32 number of tags N, 161 and hence of (tag, value) pairs. 4*(N-1) bytes are offsets, each 162 offset a uint32. The last 4*N bytes are the tags. 164 Tags are in ascending order, and no tag can be repeated. Offsets are 165 all a multiple of four and MUST be strictly increasing. The offset 166 array is considered to have a not explicitly encoded value of 0 as 167 its zeroeth entry. 169 Immediately following the header is a concatenation of all the 170 strings. The first post-header byte is at offset 0, and the end of 171 the final byte string is indicated by the end of the packet. The ith 172 byte string ends at offset[i+1]-1, counting of course from 0, and 173 begins at offset[i]. It is the value associated to the ith tag. 175 This encoding may be recursive: a value may be said to be in 176 Roughtime format and thus have a header, etc. Tags may be listed as 177 four ASCII characters [RFC0020]. In this case the tag when 178 serialized will be those four ASCII characters. For example NONC 179 would be the numeric value 0x434e4f4e. They may also be listed as 180 fewer then four ASCII characters with hex escape codes at the end. 182 5. Protocol 184 5.1. Queries 186 A query is a Roughtime packet with the tag NONC. The contents of 187 NONC are 64 bytes. The request packet MUST be a minimum of 1024 188 bytes. To attain this size the tag PAD\xff MAY be added at the end 189 of the packet with a conent of all zeros. Other tags MUST be ignored 190 by the server. Future versions may specify additional tags and their 191 semantics, so clients MUST NOT add other tags. 193 5.2. Responses 195 A response contains the following tags: SREP, SIG\x00, CERT, INDX, 196 PATH, SREP value is itself in Roughtime format that contains the 197 folowing tags: ROOT, MIDP, RADI. SIG\x00 is an Ed25519 signature 198 [RFC8032] over the SREP value using the public key contained in CERT 199 as explained later. 201 CERT in Roughtime format and contains the following tags: DELE, 202 SIG\x00. This SIG\x00 is an Ed25519 signature over DELE that can be 203 verified using the long term public key of the server. DELE is 204 itself in Roughtime format containing tags MINT, MAXT, PUBK. 206 5.2.1. SREP 208 ROOT contains the root hash value of a Merkle tree using SHA512 as 209 described when we reach the PATH and INDX blocks 211 MIDP contains an uint64 value consisting of the number of 212 microseconds since the Unix epoch. 214 RADI contains the server's estimate of the accuracy of MIDP. 215 Servers MUST ensure the true time is within (MIDP-RADI, MIDP+RADI) 216 at the time they compose the response packet. 218 LEAP contains the TAI-UTC offset at MIDP as a signed 32 bit 219 integer in two's complement. In cases of ambiguity due to leap 220 seconds either acceptable offset result is acceptable. 222 5.2.2. DELE 224 MINT is the minimum uint64 timestamp at which the key in PUBK is 225 trusted to begin signing time. MIDP > MINT for validity. 227 MAXT is the maximum uint64 timestamp at which PUBK may sign. MIDP 228 < MAXT for validity. 230 PUBK is a temporary Ed25519 public key. The use of this field is 231 to enable seperation of a root public key from keys on devices 232 exposed to the public Internet. 234 5.2.3. INDX and PATH 236 INDX is a uint32 determining the position of NONC in a Merkle tree. 237 PATH contains the values to be hashed with the running hash as one 238 ascends the tree. PATH is a multiple of 64 bytes long. The 239 following algorithm verifies inclusion in the Merkle tree: 241 One starts by computing the hash of the NONC value from the request, 242 with \x00 preappended. Then one walks from the least significant bit 243 of INDX to the most significant bit, and also walks towards the end 244 of PATH. 246 If PATH ends then the remaining bits of the INDX MUST be all zero. 247 This indicates the termination of the walk, and the current value 248 MUST equal ROOT if the response is valid. 250 If the current bit is 0, one hashes \x01, the current hash, and the 251 value from PATH. 253 If the current bit is 1 one hashes \x01, the value from PATH, and the 254 current hash. 256 5.3. Validity of response 258 A client MUST check the following properties when it receives a 259 response. We assume the long term server public key is known to the 260 client through other means. 262 The signature in CERT was made with the long-term key of the 263 server 265 The DELE timestamps and the MIDP value are consistent 267 The INDX and PATH values prove NONC was included in the Merkle 268 tree with value ROOT 270 The signature of SREP in SIG\x00 validates with the public key in 271 DELE 273 A response that passes these checks is said to be valid. Validity of 274 a response does not prove the time is correct, but merely that the 275 server signed it, and more specifically began to compute the 276 signature at a time in between (MIDP-RADI, MIDP+RADI). 278 6. Time 280 All times in Roughtime are the number of seconds since the Unix 281 epoch. The Unix epoch is midnight, 1 January, 1970. This is a 282 constant offset from TAI. Servers SHOULD use GPS or other 283 realizations of TAI that have been highly accurate in the past for 284 Roughtime to meet their accuracy promises. 286 7. Cheater detection 288 A chain of responses is a series of responses where the SHA-512 hash 289 of the preceding response H, is concatenated with a 64 byte blind X, 290 and then SHA-512(H, X) is the NONC used in the subsequent response. 291 These may be represented as an array of objects in JSON where each 292 object may have keys "blind" and "packet". Packet has the base64 293 encoded bytes of the packet and blind is the blind used for the next 294 nonce. The last packet needs no blind. 296 A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > 297 MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j 298 such that i < j, (r_i, r_j) is an invalid pair. 300 Invalidity of a chain is proof that causality has been violated if 301 all servers were reporting correct time. An invalid chain where all 302 individual responses are valid is cryptographic proof of malfeasance 303 of at least one server: if all servers had the correct time in the 304 chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. 306 8. Grease 308 Servers MAY send back a fraction of responses that are syntactically 309 invalid or contain invalid signatures as well as incorrect times. 310 Clients MUST properly reject such responses. Servers MUST NOT send 311 back responses with incorrect times and valid signatures. Either 312 signature MAY be invalid for this application. 314 9. Roughtime Servers 316 The below list contains a list of servers with their public keys in 317 Base64 format. 319 roughtime.int08h.com:2002; 320 AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 322 roughtime.cloudflare.com:2002; gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/ 323 S+T7MNTjxo= 324 roughtime.sandbox.google.com:2002; 325 etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 327 10. Trust anchors and policies 329 A trust anchor is any distributor of a list of trusted servers. It 330 is RECOMMENDED that trust anchors subscribe to TBD where evidence of 331 malfeasance may be shared and discussed. Trust anchors SHOULD 332 subscribe to a zero-tolerance policy: any generation of incorrect 333 timestamps will result in removal. To enable this trust anchors 334 SHOULD list a wide variety of servers so the removal of a server does 335 not result in operational issues for clients. Clients SHOULD attempt 336 to detect malfeasance and have a way to report it to trust anchors. 338 Trust anchors SHOULD include any roughtime server with an uptime 339 greater then 99.9% over the past 6 months and with no malfeasance. 340 They SHOULD also aggressively collect evidence of such malfeasance. 342 Because only a single roughtime server is required for successful 343 synchronization, Roughtime does not have the incentive problems that 344 have prevented effective enforcement of discipline on the web PKI. 345 We expect that some clients will aggressively monitor server 346 behavior. 348 11. Acknowledgements 350 Thomas Peterson corrected multiple nits. Marcus Dansarie, Tal 351 Mizrahi, and the other members of the NTP working group contributed 352 comments and suggestions. 354 12. IANA Considerations 356 We request IANA assign a UDP port and create a new registry for 357 Roughtime tags. 359 13. Security Considerations 361 This protocol will not survive the advent of quantum computers. 362 Currently only one signature scheme is supported. Maintaining a list 363 of trusted servers and adjudicating violations of the rules by 364 servers are not discussed in this document and are essential for 365 security. Arithmetic on the adjusted timescale is interesting with 366 intervals, and this may impact the interpretation of the MAXT and 367 MINT fields. Servers carry out a significant amount of computation 368 in response to clients, and thus may experience vulnerability to 369 denial of service attacks. 371 This protocol does not provide any confidentiality, and given the 372 nature of timestamps such impact is minor. The compromise of a 373 PUBK's private key, even past MAXT, is a problem as the private key 374 can be used to sign invalid times that are in the range MINT to MAXT, 375 and thus violate the good behavior guarantee of the server. 377 Roughtime clients MUST update their view of which servers are 378 trustworthy in order to benefit from the detection of misbehavior. 380 Packets sent by the client MUST be at least 1024 bytes in length in 381 order to mitigate amplification attacks, and servers MUST ignore 382 request packets that are smaller than this length. 384 14. Privacy Considerations 386 This protocol is designed to obscure all client identifiers. Servers 387 necessarily have persistent long term identities essential to 388 enforcing correct behavior. 390 15. References 392 15.1. Normative References 394 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 395 RFC 20, DOI 10.17487/RFC0020, October 1969, 396 . 398 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 399 Signature Algorithm (EdDSA)", RFC 8032, 400 DOI 10.17487/RFC8032, January 2017, 401 . 403 15.2. Informative References 405 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 406 2012, . 408 [I-D.ietf-ntp-mac] 409 Malhotra, A. and S. Goldberg, "Message Authentication Code 410 for the Network Time Protocol", draft-ietf-ntp-mac-06 411 (work in progress), January 2019. 413 [I-D.ietf-ntp-using-nts-for-ntp] 414 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 415 Sundblad, "Network Time Security for the Network Time 416 Protocol", draft-ietf-ntp-using-nts-for-ntp-17 (work in 417 progress), February 2019. 419 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 420 "Attacking the Network Time Protocol", 2015, 421 . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 429 Housley, R., and W. Polk, "Internet X.509 Public Key 430 Infrastructure Certificate and Certificate Revocation List 431 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 432 . 434 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 435 "Network Time Protocol Version 4: Protocol and Algorithms 436 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 437 . 439 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 440 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 441 October 2014, . 443 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 444 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 445 May 2017, . 447 Authors' Addresses 449 Aanchal Malhotra 450 Boston University 451 111 Cummington Mall 452 Boston 02215 453 USA 455 Email: aanchal4@bu.edu 457 Adam Langley 458 Google 459 Watson Ladd 460 Cloudflare 461 101 Townsend St 462 San Francisco 463 USA 465 Email: watson@cloudflare.com