idnits 2.17.1 draft-ietf-ntp-bcp-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5905]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2706 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 936 -- Looks like a reference, but probably isn't: '2' on line 938 -- Looks like a reference, but probably isn't: '3' on line 940 -- Looks like a reference, but probably isn't: '6' on line 942 -- Looks like a reference, but probably isn't: '7' on line 944 -- Looks like a reference, but probably isn't: '8' on line 947 -- Looks like a reference, but probably isn't: '9' on line 949 -- Looks like a reference, but probably isn't: '12' on line 951 ** Downref: Normative reference to an Informational RFC: RFC 7094 ** Downref: Normative reference to an Informational RFC: RFC 7384 == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-06 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Reilly, Ed. 3 Internet-Draft Spectracom Corporation 4 Intended status: Best Current Practice H. Stenn 5 Expires: May 4, 2017 Network Time Foundation 6 D. Sibold 7 PTB 8 October 31, 2016 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-02 13 Abstract 15 NTP Version 4 (NTPv4) has been widely used since its publication as 16 RFC 5905 [RFC5905]. This documentation is a collection of Best 17 Practices from across the NTP community. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Keeping NTP up to date . . . . . . . . . . . . . . . . . . . 3 56 3. General Network Security Best Practices . . . . . . . . . . . 4 57 3.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 59 4.1. Use enough time sources . . . . . . . . . . . . . . . . . 4 60 4.2. Use a diversity of Reference Clocks . . . . . . . . . . . 5 61 4.3. Mode 6 and 7 . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 64 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 8 65 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9 66 4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 10 67 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10 68 5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11 69 5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.3. Network Time Security . . . . . . . . . . . . . . . . . . 12 71 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12 72 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 12 73 6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13 74 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 14 75 6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 14 76 6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 15 77 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16 78 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16 79 7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 16 80 7.3. Server configuration . . . . . . . . . . . . . . . . . . 17 81 7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 17 82 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 12.2. Informative References . . . . . . . . . . . . . . . . . 20 89 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 NTP Version 4 (NTPv4) has been widely used since its publication as 95 RFC 5905 [RFC5905]. This documentation is a collection of Best 96 Practices from across the NTP community. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. Keeping NTP up to date 106 Many network security mechanisms rely on time as part of their 107 operation. If an attacker can spoof the time, they may be able to 108 bypass or neutralize other security elements. For example, incorrect 109 time can disrupt the ability to reconcile logfile entries on the 110 affected system with events on other systems. The best way to 111 protect computers and networks against undefined behavior and 112 security threats related to time is to keep their NTP implementations 113 current. 115 There are always new ideas about security on the Internet, and an 116 application which is secure today could be insecure tomorrow once an 117 unknown bug (or a known behavior) is exploited in the right way. 118 Even our definition of what is secure has evolved over the years, so 119 code which was considered secure when it was written can be 120 considered insecure after some time. By keeping NTP implementations 121 current, network operators can make sure that older behaviors are not 122 exploited. 124 Thousands of individual bugs have been found and fixed in the NTP 125 Project's ntpd since the first NTPv4 release in 1997. Each version 126 release contains at least a few bug fixes. The best way to stay in 127 front of these issues is to keep your NTP implementation current. 129 There are multiple versions of the NTP protocol in use, and multiple 130 implementations in use, on many different platforms. It is 131 recommended that NTP users actively monitor wherever they get their 132 software to find out if their versions are vulnerable to any known 133 attacks, and deploy updates containing security fixes as soon as 134 practical. 136 The reference implementation of NTP Version 4 from Network Time 137 Foundation (NTF) continues to be actively maintained and developed by 138 NTF's NTP Project, with help from volunteers and NTF's supporters. 140 This NTP software can be downloaded from ntp.org [1] and also from 141 NTF's github page [2]. 143 3. General Network Security Best Practices 145 3.1. BCP 38 147 Many network attacks rely on modifying the IP source address of a 148 packet to point to a different IP address than the computer which 149 originated it. This modification/abuse vector has been known for 150 quite some time, and BCP 38 [RFC2827] was approved in 2000 to address 151 this. BCP 38 [RFC2827] calls for filtering outgoing and incoming 152 traffic to make sure that the source and destination IP addresses are 153 consistent with the expected flow of traffic on each network 154 interface. It is recommended that all networks (and ISP's of any 155 size) implement this. If a machine on a network is sending out 156 packets claiming to be from an address that is not on that network, 157 this could be the first indication that there is a machine that has 158 been compromised, and is being used abusively. If packets are 159 arriving on an external interface with a source address that is 160 normally only seen on an internal network, that's a strong indication 161 that an attacker is trying to inject spoofed packets into the 162 network. More information is available at the BCP38 Info page [3] . 164 4. NTP Configuration Best Practices 166 These Best Practices, while based on the ntpd reference 167 implementation developed and maintained by Network Time Foundation, 168 may be applicable to other implementations as well. 170 4.1. Use enough time sources 172 ntpd takes the available sources of time and submits their timing 173 data to intersection and clustering algorithms, looking for the best 174 idea of the correct time. 176 o If there is only 1 source of time, the answer is obvious. It 177 might not be a good source of time, but it's the only one. 179 o If there are 2 sources of time and they agree well enough, that's 180 good. But if they don't, then ntpd has no way to know which 181 source to believe. 183 o If there are 3 sources of time, you can tolerate one of those 184 sources becoming unreachable or unusable. But at that point, we 185 are back down to 2 sources. 187 o 4 sources of time is better. If one of these sources develops a 188 problem there are still 3 others. 190 But even with 4 or more sources of time, systemic issues can happen. 191 During the leap second of June of 2015, several operators implemented 192 leap smearing while others did not, and some NTP clients follwed 2 193 servers that offered UTC time (with leap second announcements) and 2 194 servers that offered leap smeared time (with no leap second 195 announcements). See Section 4.6.1 for more information. 197 Starting with ntp-4.2.6, the 'pool' directive will spin up "enough" 198 associations to provide robust time service, and will disconnect poor 199 servers and add in new servers as-needed. The default values built 200 in to ntpd should be correct. If you have good reasons, you may use 201 the 'minclock' and 'maxclock' options of the 'tos' command to 202 override the default values of how many servers are discovered and 203 used through the 'pool' directive. 205 Properly monitor your NTP instances. If your time sources do not 206 generally agree, find out why and either correct the problems or stop 207 using defective servers. See Section 4.4 for more information. 209 4.2. Use a diversity of Reference Clocks 211 When using servers with attached hardware reference clocks, it is 212 recommended that several different types of reference clocks be used. 213 Having a diversity of sources means that any one issue is less likely 214 to cause a service interruption. 216 Are all clocks on a network from the same vendor? They might have 217 the same bugs. Are they using the same base chipset, regardless of 218 whether or not the finished products are from different vendors? Are 219 they all running the same version of firmware? Chipset and firmware 220 bugs can happen, but are often more difficult to diagnose than a 221 standard software bug. 223 A systemic problem with time from any satellite navigation service is 224 possible and has happened. Sunspot activity can render satellite or 225 radio-based time source unusable. If the time on your network needs 226 to be correct close to 100% of the time, then even if you are using a 227 satellite-based time source you must plan for those rare instances 228 when the time source is unavailable or wrong. 230 4.3. Mode 6 and 7 232 NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit 233 monitoring and optional authenticated control of ntpd and its 234 configuration. Used properly, these facilities provide vital 235 debugging and performance information, and control facilities. Used 236 improperly, these facilities can be an abuse vector. 238 Mode 7 queries have been disabled by default in ntpd since 4.2.7p230, 239 released on 2011/11/01. Do not enable Mode 7 unless there is a 240 compelling reason to do so. 242 The ability to use Mode 6 beyond its basic monitoring capabilities is 243 limited by default to authenticated sessions that provide and use a 244 'controlkey'. Similarly, if Mode 7 has been explicitly enabled its 245 use for more than basic monitoring is limited by default to 246 authenticated sessions that provide and use a 'requestkey'. 248 Older versions of the reference implementation of NTP likely do not 249 have the protections listed above and could be abused to participate 250 in high-bandwidth DDoS attacks, if the above restrictions are not 251 applied. Starting with ntp-4.2.7p26, released in April of 2010, ntpd 252 requires the use of a nonce before replying with potentially large 253 response packets. 255 As mentioned above, there are two general ways to use Mode 6 and Mode 256 7 requests. One way is to query ntpd for information, and this mode 257 can be disabled with: 259 restrict ... noquery 261 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 262 behavior. Modification of ntpd ordinarily requires an authenticated 263 session. By default, if no authentication keys have been specified 264 no modifications can be made. For additional protection, the ability 265 to perform these modifications can be controlled with: 267 restrict ... nomodify 269 Adminitstrators can prevent their NTP servers from responding to 270 these directive in the general case by adding the following to their 271 ntp.conf file: 273 restrict default -4 nomodify notrap nopeer noquery 275 restrict default -6 nomodify notrap nopeer noquery 277 restrict source nomodify notrap noquery 278 # nopeer is OK if you don't use the 'pool' directive 280 4.4. Monitoring 282 The reference implementation of NTP allows remote monitoring. Access 283 to this service is controlled by the restrict statement in ntpd's 284 configuration file (ntp.conf). The syntax is: 286 restrict address mask address_mask nomodify 288 Monitor ntpd instances so machines that are "out of sync" can be 289 quickly identified. Monitor system logs for messages from ntpd so 290 abuse attempts can be quickly identified. 292 If a system starts getting unexpected time replies from its time 293 servers, that is a likely indication that an abuser is forging your 294 server's IP in time requests to your time server in an attempt to 295 convince your time servers to stop serving time to your system. 297 If a system is a broadcast client and its syslog shows that it is 298 receiving "early" time messages from its server, that is an 299 indication that somebody might be forging packets from a broadcast 300 server. Broadcast time should only be used in trusted networks. 302 If a server's syslog shows messages that indicates it is receiving 303 timestamps that are earlier than the current system time, then either 304 the system clock is unusually fast or somebody is trying to launch a 305 replay attack against that server. 307 If a system is using broadcast mode and is running ntp-4.2.8p6 or 308 later, use the 4th field of the ntp.keys file to specify the IPs of 309 machines that are allowed to serve time to the group. 311 4.5. Using Pool Servers 313 It only takes a small amount of bandwidth and system resources to 314 synchronize one NTP client, but NTP servers that can service tens of 315 thousands of clients take more resources to run. Users who want to 316 synchronize their computers should only synchronize to servers that 317 they have permission to use. 319 The NTP pool project is a collection of volunteers who have donated 320 their computing and bandwidth resources to provide time on the 321 Internet for free. The time is generally of good quality, but comes 322 with no guarantee whatsoever. If you are interested in using the 323 pool, please review their instructions at http://www.pool.ntp.org/en/ 324 use.html . 326 If you want to synchronize many computers using the pool, consider 327 running your own NTP servers, synchronizing them to the pool, and 328 synchronizing your clients to your in-house NTP servers. This 329 reduces the load on the pool. 331 If you would like to contribute a server with a static IP address and 332 a permanent Internet conenction to the pool, please consult the 333 instructions at http://www.pool.ntp.org/en/join.html . 335 4.6. Leap Second Handling 337 UTC is kept in agreement with the astronomical time UT1 [6] to within 338 +/- 0.9 seconds by the insertion or deletion of a leap second. UTC 339 is an atomic time scale whereas UT1 is based on the rotational rate 340 of the earth. Leap seconds are not introduced at a fixed rate. They 341 are announced by the IERS (International Earth rotation and Reference 342 systems Service) in its Bulletin C [7] when necessary to keep UTC and 343 UT1 aligned. 345 NTP time is based on the UTC timescale, and the protocol has the 346 capability to broadcast leap second information. Some GNSS systems 347 (like GPS) or radio transmitters (like DCF77) broadcast leap second 348 information, so if you have a Stratum-1 server synced to GNSS or you 349 are synced to a lower stratum server that is ultimately synced to 350 GNSS, you will get advance notification of impending leap seconds 351 automatically. 353 Since the length of the UT1 day is generally slowly increasing [8], 354 all leap seconds that have been introduced since the practice started 355 in 1972 have been "positive" leap seconds, where a second is added to 356 UTC. NTP also supports a "negative" leap second, where a second is 357 removed from UTC, in the event that the IERS announces one. 359 While earlier versions of NTP contained some ambiguity regarding when 360 a leap second that is broadcast by a server is applied by a client, 361 RFC 5905 is clear that leap seconds are only applied on the last day 362 of a month. However, because some older clients might apply it at 363 the end of the current day, it is recommended that NTP servers wait 364 until the last day of the month before broadcasting leap seconds. 365 Doing this will prevent older clients from applying a leap second at 366 the wrong time. Note well that in NTPv4 the maximum allowed poll 367 interval is 17, or about 1.5 days' time. In this situation, it's 368 possible that a client will miss the leap second announcement. 370 The IETF maintains a leap second list [9]. The use of a leap second 371 list requires ntpd 4.2.6 or later. After fetching the leap seconds 372 file onto the server, add this line to ntpd.conf to apply the file: 374 leapfile "/path/to your/leap-file" 376 You may need to restart ntpd to apply this change. 378 The leap second list file is also available from other sources: 380 NIST: ftp://time.nist.gov/pub/leap-seconds.list 382 US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/ 383 leap-seconds.list 385 IERS (announces leap seconds): 386 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 388 ntpd servers with a manually configured leap second file will ignore 389 leap second information broadcast from upstream NTP servers until the 390 leap second file expires. 392 If no valid leap second file is available then a leap second 393 notification from an attached reference clock is always accepted by 394 ntpd. 396 If no valid leap second file is available, a leap second notification 397 may be accepted from upstream NTP servers. As of ntpd 4.2.6, a 398 majority of servers must provide the notification before it is 399 accepted. Before 4.2.6, a leap second notification would be accepted 400 if only a single upstream server of a group of configured servers 401 provided a leap second notification. While this was useful behavior 402 in the past, when information about pending leap seconds was less 403 available. Now, we have the combination of 1) easy availablilty of 404 the leap second file and software to use it, and 2) a greater 405 awareness of the potential for hostile behavior. In this new light, 406 we have shifted from "believe a single warning" to "follow the best 407 authoritative source". The best authoritative source is the leap 408 seconds list file, The next best source would be an attached refclock 409 that can provide notification of leap second adjustments, and the 410 next best source would be the majority consensus from upstream 411 servers. There is still a risk of misbehavior if a "master" NTP 412 server gets an invalid leap second warning, e.g. due to an incorrect 413 leap second list file, or a faulty GPS receiver. 415 4.6.1. Leap Smearing 417 Some NTP installations may make use of a technique called "Leap 418 Smearing" to propagate a leap second correction. With this method, 419 instead of introducing an extra second (or eliminating a second), NTP 420 time will be slewed in small increments over a comparably large 421 window of time (called the smear interval) around the leap second 422 event. The smear interval should be large enough to make the rate 423 that the time is slewed small, so that clients will follow the 424 smeared time without objecting. A smear interval of 86400 seconds, 425 which is 1 day, has been used sucessfully. During the adjustment 426 window, all the NTP clients' times could be offset from UTC by as 427 much as a full second, depending on the implementation. But at least 428 all clients will agree on what time they think it is! 430 The purpose of Leap Smearing is to enable systems that don't deal 431 with the leap second event properly to function smoothly, at the 432 expense of fidelity to UTC during the smear window. During a 433 standard leap second event, that minute will have 61 (or possibly 59) 434 seconds in it, and some applications (and even some OSes) are known 435 to have problems with that. 437 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47. 438 Support is not availabled by default and has to be specifically added 439 at compile time. In addition, no leap smearing will occur unless a 440 leap smear interval is specified in ntpd.conf . For more 441 information, refer to http://bk1.ntp.org/ntp-stable/ 442 README.leapsmear?PAGE=anno . 444 Clients that are connected to leap smearing servers must not apply 445 the "standard" NTP leap second handling. So if they are using ntpd, 446 these clients must not have a leap second file loaded, and the 447 smearing servers must not advertise that a leap second is pending. 449 Leap Smearing must not be used for public-facing NTP servers, as they 450 will disagree with non-smearing servers (as well as UTC) during the 451 leap smear interval. However, be aware that some public-facing 452 servers might be configured this way anyway in spite of this 453 guidance. 455 System Administrators are advised to be aware of impending leap 456 seconds and how the servers (inside and outside their organization) 457 they are using deal with them. Individual clients must not be 458 configured to use a mixture of smeared and non-smeared servers. If a 459 client uses smeared servers, the servers it uses must all have the 460 same leap smear configuration. 462 4.7. Configuring ntpd 464 See https://support.ntp.org/bin/view/Support/ConfiguringNTP for 465 additional information on configuring ntpd. 467 5. NTP Security Mechanisms 469 In the standard configuration NTP packets are exchanged unprotected 470 between client and server. An adversary that is able to become a 471 Man-In-The-Middle is therefore able to drop, replay or modify the 472 content of the NTP packet, which leads to degradation of the time 473 synchronization or the transmission of false time information. A 474 profound threat analysis for time synchronization protocols are given 475 in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms 476 to protect authenticity and integrity of the NTP packets. Both 477 measures protect the NTP packet by means of a Message Authentication 478 Code (MAC). Neither of them encrypts the NTP's payload, because it 479 is not considered to be confidential. 481 5.1. Pre-Shared Key Approach 483 This approach applies a symmetric key for the calculation of the MAC, 484 which protects authenticity and integrity of the exchanged packets 485 for a association. NTP does not provide a mechanism for the exchange 486 of the keys between the associated nodes. Therefore, for each 487 association, keys have to be exchanged securely by external means. 488 It is recommended that each association be protected by its own 489 unique key. NTP does not provide a mechanism to automatically 490 refresh the applied keys. It is therefore recommended that the 491 participants periodically agree on a fresh key. The calculation of 492 the MAC may always be based on an MD5 hash. If the NTP daemon is 493 built against an OpenSSL library, NTP can also base the calculation 494 of the MAC upon the SHA-1 or any other digest algorithm supported by 495 each side's OpenSSL library. 497 To use this approach the communication partners have to exchange the 498 key, which consists of a keyid with a value between 1 and 65534, 499 inclusive, and a label which indicates the chosen digest algorithm. 500 Each communication partner adds this information to their key file in 501 the form: 503 keyid label key 505 The key file contains the key in clear text. Therefore it should 506 only be readable by the NTP process. Different keys are added line 507 by line to the key file. 509 A NTP client establishes a protected association by appending the 510 option "key keyid" to the server statement in the NTP configuration 511 file: 513 server address key keyid 515 Note that the NTP process has to trust the applied key. An NTP 516 process explicitly has to add each key it want to trust to a list of 517 trusted keys by the "trustedkey" statement in the NTP configuration 518 file. 520 trustedkey keyid_1 keyid_2 ... keyid_n 522 5.2. Autokey 524 Autokey was designed in 2003 to provide a means for clients to 525 authenticate servers. By 2011, security researchers had identified 526 computational areas in the Autokey protocol that, while secure at the 527 time of its original design, were no longer secure. 529 It is recommended that Autokey not be used. Know that as of the fall 530 of 2011, a common(?) laptop computer could crack the security cookie 531 used in the Autokey protocol in 30 minutes' time. If you want to use 532 Autokey, know that your session keys should be set to expire in under 533 30 minutes' time. 535 If you have reason to believe your autokey-protected associations 536 will be attacked, you should read https://lists.ntp.org/pipermail/ 537 ntpwg/2011-August/001714.html and decide what resources your 538 attackers might be using, and adjust the session key expiration time 539 accordingly. 541 5.3. Network Time Security 543 Work has begun on an enhanced replacement for Autokey, which is 544 called Network Time Security (NTS) [NTS]. NTS was first published as 545 an Internet-Draft in the summer of 2013. As of October 2016, this 546 effort was at draft #15, and about to begin 'final call'. The first 547 unicast implementation of NTS was started in the summer of 2015 and 548 is expected to be released in early 2017. 550 6. NTP Security Best Practices 552 6.1. Minimizing Information Leakage 554 The base NTP packet leaks important information (including reference 555 ID and reference time) that can be used in attacks [NDSS16], 556 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 557 information by sending mode 3 queries to a target system and 558 inspecting the fields in the mode 4 response packet. NTP control 559 queries also leak important information (including reference ID, 560 expected origin timestamp, etc.) that can be used in attacks 561 [CVE-2015-8139]. A remote attacker can learn this information by 562 sending control queries to a target system and inspecting the 563 response. 565 As such, access control should be used to prevent the exposure of 566 this information to inappropriate third parties. 568 Hosts should only respond to NTP control queries from authorized 569 parties. One way to do this is to only allow control queries from 570 authorized IP addresses. 572 A host that is not supposed to act as an NTP server that provides 573 timing information to other hosts should additionally drop incoming 574 mode 3 timing queries. 576 A "leaf client" is a host that is using NTP solely for the purpose of 577 adjusting its own time. A leaf client should not be a time server to 578 other hosts. That is, a leaf client sends mode 3 queries to its 579 servers and receives mode 4 responses from these servers containing 580 timing information. To minimize information leakage, leaf clients 581 should drop all incoming NTP packets except for packets coming from 582 trusted monitoring systems and mode 4 response packets that come from 583 its configured time sources. 585 6.2. Avoiding Daemon Restart Attacks 587 [RFC5905] says NTP clients should not accept time shifts greater than 588 the panic threshold. Specifically, RFC5905 says "PANIC means the 589 offset is greater than the panic threshold PANICT (1000 s) and should 590 cause the program to exit with a diagnostic message to the system 591 log." 593 However, this behavior is designed to be used only in cold-start 594 situations. If it is used in more general situations it can be 595 exploited by attackers [NDSS16] when ntpd is restarted with a 596 disabled panic gate check. 598 If your operating system has init scripts, these scripts should not 599 disable panic gate checking on restarts. 601 A growing number of operating systems use process supervisors such as 602 systemd to automatically restart any daemons that quit. This 603 behavior is the default in CoreOS and Arch Linux. It is likely to 604 become the default behavior in other Linux-based systems as they 605 migrate legacy init scripts to systemd. These scripts should not 606 disable panic gate checking on restarts. 608 If, against long-standing recommendations, a system disables panic 609 gate checking on all restarts, an attacker can send the target an 610 offset that exceeds the panic threshold, causing the client to quit. 611 Then, when the client restarts, it ignores the panic threshold and 612 accepts the attacker's large offset. 614 Hosts running with the above two conditions should be aware that the 615 panic threshold does not protect them from attacks. A natural 616 solution is not to run hosts with these conditions. 618 As an alternative, the following steps could be taken to mitigate the 619 risk of attack. 621 o Monitor NTP system log to detect when the NTP daemon has quit due 622 to a panic event, as this could be a sign of an attack. 624 o Request manual intervention when a timestep larger than the panic 625 threshold is detected. 627 o Prevent the NTP daemon from taking time steps that set the clock 628 to a time earlier than the compile date of the NTP daemon. 630 o Modify the NTP daemon so that it "hangs" (ie does not quit, but 631 just waits for a better timing samples but does not modify the 632 local clock) when it receives a large offset. 634 6.3. Detection of Attacks Through Monitoring 636 Users should monitor their NTP instances to detect attacks. Many 637 known attacks on NTP have particular signatures. Common attack 638 signatures include: 640 1. "Bogus packets" - A packet whose origin timestamp does not match 641 the value that expected by the client. 643 2. "Zero origin packet" - A packet with a origin timestamp set to 644 zero [CVE-2015-8138]. 646 3. A packet with an invalid cryptographic MAC [CCR16]. 648 The observation of many such packets could indicate that the client 649 is under attack. 651 Also, Kiss-o'-Death (KoD) packets can be used in denial of service 652 attacks. Thus, the observation of even just one KoD packet with a 653 high poll value (e.g. poll>10) could be sign that the client is under 654 attack. 656 6.4. Broadcast Mode Should Only Be Used On Trusted Networks 658 Per [RFC5905], NTP's broadcast mode is authenticated using symmetric 659 key cryptography. The broadcast server and all of its broadcast 660 clients share a symmetric cryptographic key, and this key is used by 661 the broadcast server to build and by the broadcast clients to 662 authenticate the Message Authentication Code (MAC) that protects NTP 663 broadcast packets. 665 Put another way, all broadcast clients that listen to broadcast 666 servers know and share the same cryptographic key. This mean that 667 any client can use this key to send valid broadcast messages that 668 look like they come from the broadcast server. Thus, a rogue with 669 knowledge of this key cab attack broadcast clients. 671 For this reason, all NTP broadcast servers and clients need to trust 672 each other. Broadcast mode should only be run from within a trusted 673 network. 675 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 676 column, a comma-separated list of IPs that are allowed to serve time. 677 Use this feature. 679 Updated NTP broadcast clients are protected against and detect these 680 attacks by reporting unexpected or inconsistent broadcast packets, 681 and by ignoring broadcast packets that arrive "too early". Monitor 682 your NTP log files. 684 6.5. Symmetric Mode Should Only Be Used With Trusted Peers 686 In symmetric mode, two peers Alice and Bob can both push and pull 687 synchronization to and from each other using either ephemeral 688 symmetric passive (mode 2) or persistent symmetric active (NTP mode 689 1) packets. The persistent association is preconfigured and 690 initiated at the active peer but not preconfigured at the passive 691 peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob 692 mobilizes a new ephemeral association if he does not have one 693 already. This is a security risk for Bob because an arbitrary 694 attacker can attempt to change Bob's time by asking Bob to become its 695 symmetric passive peer. 697 For this reason, a host (Bob) should only allow symmetric passive 698 associations to be established with trusted peers. Specifically, Bob 699 should require each of its symmetric passive association to be 700 cryptographically authenticated. Each symmetric passive association 701 should be authenticated under a different cryptographic key. 703 The use of a different cryptographic key for each peer association 704 prevents a Sybil attack, where a single malicious peer uses the same 705 cryptographic key to set up multiple symmetric associations a target, 706 and thus bias the results of the target's Byzantine fault tolerant 707 peer selection algorithms. 709 7. NTP in Embedded Devices 711 Readers of this BCP likely already understand how important accurate 712 time is for network computing. And as computing becomes more 713 ubiquitous, there will be many "Internet of Things" devices that 714 require accurate time. These embedded devices might not have a 715 traditional user interface, but if they connect to the Internet they 716 will be subject to the same security threats as traditional 717 deployments. 719 7.1. Updating Embedded Devices 721 Vendors of embedded devices have a special responsibility to pay 722 attention to the current state of NTP bugs and security issues and 723 fix them quickly, because their customers don't have the ability to 724 update their NTP implementation on their own. Those devices might 725 have a single firmware upgrade, provided by the manufacturer, that 726 updates all capabilities at once. This means that the vendor assumes 727 the responsibility of making sure their devices have the latest NTP 728 updates applied. 730 This should also include the ability to update any NTP server 731 addresses on these devices. 733 There is a catalog of NTP server abuse incidents, some of which 734 involve embedded devices, on the Wikipedia page for NTP Server Misuse 735 and Abuse [12]. 737 7.2. KISS Packets 739 The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a 740 server can tell a misbehaving client to "back off" its query rate. 741 It is important for all NTP devices to respect these packets and back 742 off when asked to do so by a server. It is even more important for 743 an embedded device, which may not have exposed a control interface 744 for NTP. 746 The KoD mechanism relies on clients behaving properly in order to be 747 effective. Some clients ignore the KoD packet entirely, and other 748 poorly-implemented clients erroneously and destructively increase 749 their poll rate and create a low-level denial of service attack. 750 Server administrators should be prepared for this and take measures 751 outside of the NTP protocol to drop packets from misbehaving clients. 753 7.3. Server configuration 755 Vendors of embedded devices that need time synchronization should 756 also carefully consider where they get their time from. There are 757 several public-facing NTP servers available, but they might not be 758 prepared to service requests from thousands of new devices on the 759 Internet. 761 Vendors are encouraged to invest resources into providing their own 762 time servers for their devices to connect to. 764 7.3.1. Get a vendor subdomain for pool.ntp.org 766 The NTP Pool Project offers a program where vendors can obtain their 767 own subdomain that is part of the NTP Pool. This offers vendors the 768 ability to safely make use of the time distributed by the Pool for 769 their devices. Vendors are encouraged to support the pool if they 770 participate. For more information, visit http://www.pool.ntp.org/en/ 771 vendors.html . 773 8. NTP over Anycast 775 Anycast is described in BCP 126 [RFC4786], with additional 776 information at RFC 7094 [RFC7094]. With anycast, single IP address 777 is assigned to multiple interfaces, and routers direct packets to the 778 closest active interface. 780 Anycast is often used for Internet services at known IP addresses, 781 such as DNS. Anycast could be used in large organizations to 782 simplify configuration of a large number of NTP clients, but note 783 well this simplification comes at the cost of degraded NTP behavior 784 and performance. Each client can be configured with the same NTP 785 server IP address, and a pool of anycast servers can be deployed to 786 service those requests. New servers can be added to or taken from 787 the pool, and other than a possible brief loss of service immediately 788 after server is taken down (and before packets are directed to a new 789 server), these additions are transparent to the clients. 791 If clients are connected to an NTP server via anycast, the client 792 does not know which particular server they are connected to. As 793 anycast servers are allowed to arbitrarily enter and leave the 794 network or as the routing behavior changes, the server a particular 795 client is connected to could change. This can cause a shift in the 796 delay and symmetry between the client and the server. 798 NOTE WELL: Using anycast for NTP is likely to be a bad idea, because 799 it means there is likely to be an apparent single time server source 800 for the client population. A key element of a robust NTP deployment 801 is multiple sources of time. With multiple time servers a client can 802 analyze the various time sources, selecting good ones, and 803 disregarding poor ones. In an Anycast scenario, this analysis is 804 likely impossible. 806 If clients are connected to an NTP server via anycast, the client 807 does not know which particular server they are connected to. As 808 anycast servers are allowed to arbitrarily enter and leave the 809 network, the server any given client is connected to could change. 810 It is recommended that anycast be deployed in environments where 811 these small shifts can be tolerated. 813 Configuration of an anycast interface is independent of NTP. Clients 814 will always connect to the closest anycast server, even if that 815 server is having NTP issues. It is recommended that anycast NTP 816 implementations have an independent method of monitoring the 817 performance of NTP on all servers and clients. If a server is not 818 performing to specification, it should remove itself from the Anycast 819 network. It is also recommended that each Anycast NTP server have at 820 least one Unicast interface so its performance can be checked 821 independently of the anycast routing scheme. 823 One useful application in large networks is to use a hybrid unicast/ 824 anycast approach. Stratum 1 NTP servers can be deployed with unicast 825 interfaces at several sites. Each site could have several Stratum 2 826 servers with two ethernet interfaces. One interface has a unique 827 unicast IP address. The second has an anycast IP interface (with a 828 shared IP address per location). The unicast interfaces can be used 829 to obtain time from the Stratum 1 servers globally (and perhaps peer 830 with the other Stratum 2 servers at their site). Clients at each 831 site can be configured to use the shared anycast address for their 832 site, simplifying their configuration. Keeping the anycast routing 833 restricted on a per-site basis will minimize the disruption at the 834 client if its closest anycast server changes. Each Stratum 2 server 835 can be uniquely identified on their unicast interface, to make 836 monitoring easier. 838 9. Acknowledgements 840 The authors wish to acknowledge the contributions of Sue Graves, 841 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 842 Goldberg, Martin Burnicki, and Miroslav Lichvar. 844 10. IANA Considerations 846 This memo includes no request to IANA. 848 11. Security Considerations 850 Time is a fundamental component of security on the internet. 851 Credentials and certificates can expire. Logins and other forms of 852 access can be revoked after a period of time, or at a scheduled time. 853 And some applications might assume that system time cannot be changed 854 and is always monotonic, and vulnerabilites could be exposed if a 855 time in the past is forced into a system. Therefore, any system 856 adminstrator concerned with security should be concerned with how the 857 current time gets into their system. 859 [NTS] is an Internet-Draft of a collection of methods to secure time 860 transfer over networks. [NTSFORNTP] is an Internet-Draft that 861 applies the methods in [NTS] specifically to NTP. At the time of 862 this writing, these are still drafts. Readers are encouraged to 863 check the status of these drafts, and make use of the methods they 864 describe. 866 12. References 868 12.1. Normative References 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, 872 DOI 10.17487/RFC2119, March 1997, 873 . 875 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 876 Defeating Denial of Service Attacks which employ IP Source 877 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 878 May 2000, . 880 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 881 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 882 December 2006, . 884 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 885 "Network Time Protocol Version 4: Protocol and Algorithms 886 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 887 . 889 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 890 "Architectural Considerations of IP Anycast", RFC 7094, 891 DOI 10.17487/RFC7094, January 2014, 892 . 894 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 895 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 896 October 2014, . 898 12.2. Informative References 900 [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's 901 Authenticated Broadcast Mode", SIGCOMM Computer 902 Communications Review (CCR) , 2016. 904 [CVE-2015-8138] 905 Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL 906 ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 907 . 909 [CVE-2015-8139] 910 Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC 911 ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 912 . 914 [CVE-2016-1548] 915 Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode 916 to Interleaved", 2016, 917 . 920 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 921 "Attacking the Network Time Protocol", NDSS'16, San Diego, 922 CA. , 2016, . 924 [NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time 925 Security", draft-ietf-ntp-network-time-security-15 (work 926 in progress), September 2016. 928 [NTSFORNTP] 929 Sibold, D., Roettger, S., and K. Teichel, "Using the 930 Network Time Security Specification to Secure the Network 931 Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work 932 in progress), September 2016. 934 12.3. URIs 936 [1] http://www.ntp.org/downloads.html 938 [2] https://github.com/ntp-project/ntp 940 [3] http://www.bcp38.info 942 [6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 944 [7] https://www.iers.org/IERS/EN/Publications/Bulletins/ 945 bulletins.html 947 [8] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 949 [9] https://www.ietf.org/timezones/data/leap-seconds.list 951 [12] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 953 Authors' Addresses 955 Denis Reilly (editor) 956 Spectracom Corporation 957 1565 Jefferson Road, Suite 460 958 Rochester, NY 14623 959 US 961 Email: denis.reilly@spectracom.orolia.com 963 Harlan Stenn 964 Network Time Foundation 965 P.O. Box 918 966 Talent, OR 97540 967 US 969 Email: stenn@nwtime.org 971 Dieter Sibold 972 Physikalisch-Technische Bundesanstalt 973 Bundesallee 100 974 Braunschweig D-38116 975 Germany 977 Phone: +49-(0)531-592-8420 978 Fax: +49-531-592-698420 979 Email: dieter.sibold@ptb.de