idnits 2.17.1 draft-aanchal-time-implementation-guidance-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group A. Malhotra 3 Internet-Draft Boston University 4 Intended status: Informational K. Teichel 5 Expires: January 9, 2020 PTB 6 M. Hoffmann 7 W. Toorop 8 NLnet Labs 9 July 8, 2019 11 On Implementing Time 12 draft-aanchal-time-implementation-guidance-02 14 Abstract 16 This document describes the properties of different types of clocks 17 available on digital systems. It provides implementors of 18 applications with guidance on choices they have to make when working 19 with time to provide basic functionality and security guarantees. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 9, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Scope of the document . . . . . . . . . . . . . . . . . . . . 3 57 3. Expressing Time . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Absolute Time . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Relative Time . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Keeping Time: Different Clocks . . . . . . . . . . . . . . . 4 61 4.1. Native Clock . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. World Clock . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Implementation Approaches . . . . . . . . . . . . . . . . . . 6 64 6. Accessing the Native Clock on Selected Operating Systems . . 7 65 6.1. POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Microsoft Window . . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 It is hard to overstate the importance of time in modern digital 78 systems. The functionality and security of applications (distributed 79 or local to one system) and that of network protocols generally hinge 80 on some notion of time. For implementation, these applications and 81 protocols have to choose one of the types of clocks available on 82 their system, each of which has its own specific properties. 83 However, currently many of these applications seem to be oblivious to 84 the implications of choosing one or the other clock for 85 implementation. This behavior can be attributed to: 87 a. the lack of clear understanding of the distinct properties of 88 these clocks, 90 b. trade-offs of using one or the other for an application, and 92 c. availability and compatibility of these clocks on different 93 systems. 95 This document discusses a) and b). 97 More specifically, in this document we first define different methods 98 used by protocols and applications to express time. We then define 99 properties of clocks maintained by modern digital systems. Next we 100 describe how systems obtain these values from these clocks and the 101 security considerations of using these values to implement protocols 102 and applications that use time. Finally we discuss trade-offs 103 between security and precision of choosing a clock. The document 104 aims to provide guidance to the implementors make an informed choice 105 with an example of POSIX system. 107 2. Scope of the document 109 This document aims to provide software developers implementing 110 protocols and applications that have to deal with time with the 111 knowledge and understanding to make informed decisions regarding the 112 available clocks and their respective trade-offs. 114 It does not describe functionality that is specific to the 115 architecture of a PC, or other devices such as phones, IoT devices, 116 switches, routers, base stations, or synchrophasors. Nor is the 117 document applicable to a specific operating system. Throughout the 118 document we assume that one or the other clock is available on most 119 devices. How these clocks are available on different PCs or other 120 devices is out of scope of this document. 122 We do not exactly recommend which clock should be used. We discuss 123 the available options and trade-offs. The final decision would vary 124 depending on the availability of clocks and the security requirements 125 of the specific application under implementation. 127 Note: Since there is a lack of standards on terminology related to 128 time, we define some terms in the following section. Also, 129 throughout the document, we define the terms as they become relevant. 130 Different systems, depending on their OS, may use different terms for 131 the same types of clocks. A survey on this is not in the scope of 132 this document. We provide a discussion on how to access these values 133 on POSIX and Windows systems. On other systems, implementors will 134 have to determine themselves which of these values are available. 136 3. Expressing Time 138 Protocols and applications can express time in several forms, 139 depending on whether they need to express a point in time or a time 140 interval. 142 3.1. Absolute Time 144 Absolute time expresses a universally agreed upon reference to a 145 specific point in time. Such a reference can be expressed in 146 different ways. For instance, Unix Time refers to the number of 147 seconds since midnight UTC, January 1st, 1970, while in everyday 148 life, we referenced such a point through year, month, day, and so on. 150 Because absolute time expresses a shared view of time, a system needs 151 to synchronize its clock with a common reference clock, for instance 152 one base on UTC. 154 Absolute time is often used to express the start or end of the 155 validity of objects with a limited lifetime that are shared over the 156 network. 158 3.2. Relative Time 160 Relative time measures the time interval that has elapsed from some 161 well-defined reference point (e.g., 20 minutes from the time of your 162 query). 164 Relative time is commonly used in network protocols, for instance to 165 determine when a packet should be considered dropped or to express 166 Time To Live (TTL) values that govern the length of time for which an 167 object is valid or usable. 169 Since relative time does not express a point in time, it does not 170 rely on synchronized clocks between systems but only on a shared 171 clock rate. 173 4. Keeping Time: Different Clocks 175 In this section, we will have a look at the different clocks a system 176 uses and how it maintains these clocks 178 4.1. Native Clock 180 Each system has its own perception of time. It gains access it via 181 its native clock. Typcially, this clock counts cycles of an 182 oscillator but some systems use process CPU times or thread CPU 183 timers (via timers provided by the CPU). The quality of the native 184 clock therefore dependends on either the stability of the oscillator 185 or the CPU timer. 187 The timescale of the native clock is a purely subjective -- no 188 general meaning can be attached to any specific clock value. One can 189 only obtain relative time by comparing two values. Because the value 190 of the native clock always grows at a steady pace, never decreases, 191 never make unexpected jumps, and never skips, the difference between 192 two clock values provides the time intervall between the two 193 measurements. 195 The independence of the native clock from any external time sources 196 renders it resistant to any manipulation but in return there is no 197 guarantee that its clock rate is similar to that of any other system. 198 This difference in rate, especially when compared to a reference 199 clock, is called clock drift. 201 Clock drift depends on the quality of the clock itself but also on 202 factors such as system load or ambient temperatur which makes it hard 203 to predict. 205 4.2. World Clock 207 The native clock only provides means to measure relative time. In 208 order to be able to also process absolute time, it needs to be 209 synchronized with a global reference clock. Since this clock strives 210 to be the same on all systems, we call it the world clock. 212 There are a number of ways to maintain the world clock based on the 213 system's native clock. 215 o The first is to manually maintain an offset between values of the 216 native clock and the reference world clock. Because of the clock 217 drift of the native clock, this offset needs to be updated from 218 time to time if a minimal divergence from the reference clock is 219 to be maintained. 221 o Secondly, a hardware clock provided by the system and set to be 222 equivalent to the reference time can be used, allowing the system 223 to retain the offset across reboots. 225 o Finally, the reference clock can be obtained from an external time 226 source. Typically, the Internet is used through a variety of 227 timing protocols including the Network Time Protocol2 (NTP), 228 Chrony, SNTP, OpenNTP and others. 230 Each of these approaches has own problems attached to it. 232 o Manual configurations can be subject to errors and 233 misconfiguration. 235 o Accessing the hardware clock requires an I/O operation which is 236 resource intensive, therefore many systems use the hardware clock 237 only upon reboot, to initialize the clock offset; subsequent 238 updates are made either manually or through timing protocols. 240 Further, on many systems the quality of the hardware clock isn't 241 very high, leading to a large clock drift if solely relying on it. 242 Worse, systems like microcontrollers that operate within embedded 243 systems (e.g., Raspberry Pi, Arduino, etc.) often lack hardware 244 clocks altogether. These systems rely on external time sources 245 upon reboot and have no means to process absolute time until 246 synchronization with these sources has completed. 248 o Relying on Internet timing protocols opens up the system time to 249 attack. Recent papers show vulnerabilities in NTP 250 [ANTP][ANABM][SECNTP] and SNTP [BPHSTS] that allow attackers to 251 maliciously alter system's world clock -- pushing it into the past 252 or even into the future. Moreover, many of these time-shifting 253 attacks can be performed by off-path attackers, who do not occupy 254 a privileged position on the network between the victim system and 255 its time sources on the Internet. Researchers have also 256 demonstrated off-path denial of service attacks on timing 257 protocols that prevent systems from synchronizing their clocks. 259 In other words, the process of obtaining the offset necessary to 260 provide a world clock creates dependencies that can be exploited. 262 5. Implementation Approaches 264 Because absolute time relies on a shared interpretation of a value 265 expressing time, the world clock is necessary when processing such 266 values. 268 For relative time, however, where only the rate of passage of time 269 needs to be close enough to that of the other systems involved, there 270 is no need to rely on the world clock when determining whether an 271 interval has passed. 273 Instead, by obtaining a value from the native clock when the interval 274 has started only the native clock is necessary to determine when this 275 interval ends. As the native clock does not rely on any external 276 time sources, the implementation becomes resistant to the 277 difficulties of coordinating with these sources. 279 However, using the native clock in this way comes with a caveat. 280 Since the native clock is not subject to any adjustments by timing 281 protocols, it is not adjusted for the error introduced by clock 282 drift. While this is likely of little consequence for short 283 intervals, it may become significant for intervals that span long 284 periods of time. 286 The choice of clock to be used is situation-specific. If a certain 287 amount of clock drift can be tolerated or if time intervals are 288 short, implementors may prefer to use the native clock. However, if 289 precise timing over long periods is required, then the implementors 290 have no choice but to fall back to world clock 292 6. Accessing the Native Clock on Selected Operating Systems 294 In most operating systems, the standard functions to access time use 295 the world clock since that is normally what users would expect. This 296 section provides an overview how the native clock can be accesses on 297 some common operating systems. 299 6.1. POSIX 301 POSIX defines a system C API function which may provide native time: 302 "clock_gettime()", when used with a "clock_id" of "CLOCK_MONOTONIC". 304 Note that on some systems "CLOCK_MONOTONIC" is still influenced by an 305 external time source (for syntonizing the clock rate) and the non- 306 standard "CLOCK_MONITONIC_RAW" needs to be used for clock values not 307 influenced by an external time source and not susceptible for time- 308 shifting attacks. 310 6.2. Microsoft Window 312 In the Microsoft Windows operating system, native time is called 313 'Windows Time' and can be accessed through the "GetTickCount" and 314 "GetTickCount64" API functions. The returned value is nomially the 315 number of milliseconds since system start. "GetTickCount" will 316 return a 32 bit value while "GetTickCount64" returns a value 64 bits 317 wide that will wrap around less 319 7. IANA Considerations 321 This memo includes no request to IANA. 323 8. Security Considerations 325 Time is a fundamental component for the security guarantees claimed 326 by various applications. A system that uses a time distribution 327 protocol may be affected by the security aspects of the time 328 protocol. The security considerations of time protocols in general 329 are discussed in [RFC7384]. This document discusses the security 330 considerations with respect to implementing time values in 331 applications in various sections. 333 9. References 335 9.1. Normative References 337 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 338 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 339 October 2014, . 341 9.2. Informative References 343 [ANABM] Malhotra, A. and S. Goldberg, "Attacking NTP's 344 Authenticated Broadcast Mode", 2016, 345 . 347 [ANTP] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 348 "Attacking the Network Time Protocol", 2015, 349 . 351 [BPHSTS] Jose, J., "Bypassing HTTP Strict Transport Security", 352 2014, . 355 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 356 J., and S. Goldberg, "The Security of NTP's Datagram 357 Protocol", 2016, . 359 Appendix A. Acknowledgements 361 We are thankful to Sharon Goldberg and Benno Overreinder for useful 362 discussions. Thanks to Dieter Sibold, Joachim Fabini and Denis 363 Reilly, for value input and suggestions. 365 Authors' Addresses 367 Aanchal Malhotra 368 Boston University 369 111 Cummington Mall 370 Boston 02215 371 USA 373 Email: aanchal4@bu.edu 374 Kristof Teichel 375 Physikalisch-Technische Bundesanstalt 376 Bundesallee 100 377 Braunschweig D-38116 378 Germany 380 Email: kristof.teichel@ptb.de 382 Martin Hoffmann 383 NLnet Labs 384 Science Park 400 385 Amsterdam 1098 XH 386 Netherlands 388 Email: martin@nlnetlabs.nl 390 Willem Toorop 391 NLnet Labs 392 Science Park 400 393 Amsterdam 1098 XH 394 Netherlands 396 Email: willem@nlnetlabs.nl