idnits 2.17.1 draft-ietf-ntp-bcp-05.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 date (June 13, 2017) is 2503 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 967 -- Looks like a reference, but probably isn't: '2' on line 969 -- Looks like a reference, but probably isn't: '3' on line 971 -- Looks like a reference, but probably isn't: '4' on line 973 -- Looks like a reference, but probably isn't: '7' on line 975 -- Looks like a reference, but probably isn't: '8' on line 977 -- Looks like a reference, but probably isn't: '9' on line 980 -- Looks like a reference, but probably isn't: '10' on line 982 -- Looks like a reference, but probably isn't: '11' on line 984 -- Looks like a reference, but probably isn't: '13' on line 986 -- Looks like a reference, but probably isn't: '14' on line 988 ** 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 (~~), 3 warnings (==), 13 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 4 Intended status: Best Current Practice H. Stenn 5 Expires: December 15, 2017 Network Time Foundation 6 D. Sibold 7 PTB 8 June 13, 2017 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-05 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 December 15, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . 6 62 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8 64 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 8 65 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 10 66 4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 11 67 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 11 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. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 15 76 6.5. Broadcast Mode Should Only Be Used On Trusted Networks . 15 77 6.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 16 78 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 17 79 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 17 80 7.2. Server configuration . . . . . . . . . . . . . . . . . . 17 81 7.2.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 17 82 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 18 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 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 detect 111 and protect computers and networks against undefined behavior and 112 security threats related to time is to keep their NTP implementations 113 current, use an appropriate number of trustworthy time sources, and 114 properly monitor their time infrastructure. 116 There are always new ideas about security on the Internet, and an 117 application which is secure today could be insecure tomorrow once an 118 unknown bug (or a known behavior) is exploited in the right way. 119 Even our definition of what is secure has evolved over the years, so 120 code which was considered secure when it was written may turn out to 121 be insecure after some time. By keeping NTP implementations current, 122 having "enough" trustworthy time sources, and properly monitoring 123 their time infrastructure, network operators can make sure that their 124 time infrastructure is operating correctly and within specification, 125 and is not being attacked or misused. 127 Thousands of individual bugs have been found and fixed in the NTP 128 Project's ntpd since the first NTPv4 release in 1997. Each version 129 release contains at least a few bug fixes. The best way to stay in 130 front of these issues is to keep your NTP implementation current. 132 There are multiple versions of the NTP protocol in use, and multiple 133 implementations in use, on many different platforms. It is 134 recommended that NTP users actively monitor wherever they get their 135 software to find out if their versions are vulnerable to any known 136 attacks, and deploy updates containing security fixes as soon as 137 practical. 139 The reference implementation of NTP Version 4 from Network Time 140 Foundation (NTF) continues to be actively maintained and developed by 141 NTF's NTP Project, with help from volunteers and NTF's supporters. 142 This NTP software can be downloaded from ntp.org [1] and also from 143 NTF's NTP Project's BitKeeper repository [2] or github page [3]. 145 3. General Network Security Best Practices 147 3.1. BCP 38 149 Many network attacks rely on modifying the IP source address of a 150 packet to point to a different IP address than the computer which 151 originated it. This modification/abuse vector has been known for 152 quite some time, and BCP 38 [RFC2827] was approved in 2000 to address 153 this. BCP 38 [RFC2827] calls for filtering outgoing and incoming 154 traffic to make sure that the source and destination IP addresses are 155 consistent with the expected flow of traffic on each network 156 interface. It is recommended that all networks (and ISP's of any 157 size) implement ingress and egress filtering. If a machine on a 158 network is sending out packets claiming to be from an address that is 159 not on that network, this could be the first indication that there is 160 a machine that has been compromised, and is being used abusively. If 161 packets are arriving on an external interface with a source address 162 that should only be seen on an internal network, that's a strong 163 indication that an attacker is trying to inject spoofed packets into 164 the network. More information is available at the BCP38 Info page 165 [4] . 167 4. NTP Configuration Best Practices 169 These Best Practices, while based on the ntpd reference 170 implementation maintained by Network Time Foundation, may be 171 applicable to other implementations as well. 173 4.1. Use enough time sources 175 An NTP implementation (as opposed to an SNTP implementation) takes 176 the available sources of time and submits this timing data to 177 sophisticated intersection, clustering, and combing algorithms to get 178 the best estimate of the correct time. The description of these 179 algorithms is beyond the scope of this document. Interested readers 180 should read RFC 5905 [RFC5905] or the detailed description of NTP in 181 MILLS 2006 [MILLS2006] 183 o If there is only 1 source of time, the answer is obvious. It may 184 not be a good source of time, but it's the only source of time 185 that can be considered. Any issue with the time at the source 186 will be passed on to the client. 188 o If there are 2 sources of time and they agree well enough, then 189 the best "time" can be calculated easily. But if one source 190 fails, then your solution degrades to the single-source solution 191 outlined above. And if the two sources don't agree, then it's 192 impossible to know which one is correct by simply looking at the 193 time. 195 o If there are 3 sources of time, there is more data available to 196 converge on a "best" time, and this time is more likely to be 197 accurate. And you can tolerate one of the sources becoming 198 unreachable or unusable. But at that point, you are back down to 199 2 sources. 201 o 4 or more sources of time is better. If one of these sources 202 develops a problem there are still at least 3 other time sources. 204 But even with 4 or more sources of time, systemic problems can 205 happen. During the leap second of June of 2015, several operators 206 implemented leap smearing while others did not, and many NTP end 207 nodes could not determine an accurate time source because 2 of their 208 4 sources of time gave them consistent UTC/POSIX time, while the 209 other 2 gave them consistent leap-smeared time. See Section 4.6.1 210 for more information. 212 Starting with ntp-4.2.6, the 'pool' directive will spin up "enough" 213 associations to provide robust time service, and will disconnect poor 214 servers and add in new servers as-needed. If you have good reason, 215 you may use the 'minclock' and 'maxclock' options of the 'tos' 216 command to override the default values of how many servers are 217 discovered through the 'pool' directive. 219 Monitor your ntpd instances. If your time sources do not generally 220 agree, find out why and either correct the problems or stop using 221 defective servers. See Section 4.4 for more information. 223 4.2. Use a diversity of Reference Clocks 225 When using servers with attached hardware reference clocks, it is 226 recommended that several different types of reference clocks be used. 227 Having a diversity of sources means that any one issue is less likely 228 to cause a service interruption. 230 Are all clocks on a network from the same vendor? They may have the 231 same bugs. Are they using the same base chipset, regardless of 232 whether or not the finished products are from different vendors? Are 233 they all running the same version of firmware? Chipset and firmware 234 bugs can happen, but is often more difficult to diagnose than a 235 standard software bug. 237 A systemic problem with time from any satellite navigation service is 238 possible and has happened. Sunspot activity can render satellite or 239 radio-based time source unusable. If the time on your network must 240 be correct close to 100% of the time, then even if you are using a 241 satellite-based system, you must plan for those rare instances when 242 the system is unavailable (or wrong!). 244 4.3. Mode 6 and 7 246 NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit 247 monitoring and optional authenticated control of ntpd and its 248 configuration. Used properly, these facilities provide vital 249 debugging and performance information and control. Used improperly, 250 these facilities can be an abuse vector. 252 Mode 7 queries have been disabled by default in ntpd since 4.2.7p230, 253 released on 2011/11/01. Do not enable Mode 7 unless there is a 254 compelling reason to do so. 256 The ability to use Mode 6 beyond its basic monitoring capabilities 257 can be limited to authenticated sessions that provide a 'controlkey'. 258 Similarly, if Mode 7 has been explicitly enabled its use for more 259 than basic monitoring can be limited to authenticated sessions that 260 provide a 'requestkey'. 262 Older versions of the reference implementation of NTP could be abused 263 to participate in high-bandwidth DDoS attacks, if the above 264 restrictions are not applied. Starting with ntp-4.2.7p26, released 265 in April of 2010, ntpd requires the use of a nonce before replying 266 with potentially large response packets. 268 As mentioned above, there are two general ways to use Mode 6 and Mode 269 7 requests. One way is to query ntpd for information, and this mode 270 can be disabled with: 272 restrict ... noquery 274 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 275 behavior. Modification of ntpd's configuration requires an 276 authenticated session BY default. If no authentication keys have 277 been specified no modifications can be made. For additional 278 protection, the ability to perform these modifications can be 279 controlled with: 281 restrict ... nomodify 282 Users can prevent their NTP servers from considering query/ 283 configuration traffic by default by adding the following to their 284 ntp.conf file: 286 restrict default -4 nomodify notrap nopeer noquery 288 restrict default -6 nomodify notrap nopeer noquery 290 restrict source nomodify notrap noquery 291 # nopeer is OK if you don't use the 'pool' directive 293 4.4. Monitoring 295 The reference implementation of NTP allows remote monitoring. Access 296 to this service is generally controlled by the "noquery" directive in 297 NTP's configuration file (ntp.conf) via a "restrict" statement. The 298 syntax reads: 300 restrict address mask address_mask noquery 302 Monitor ntpd instances so machines that are "out of sync" can be 303 quickly identified. Monitor system logs for messages from ntpd so 304 problems and abuse attempts can be quickly identified. 306 If a system starts getting unexpected time replies from its time 307 servers, that can be an indication that the IP address of the system 308 is being forged in requests to its time server, and these abusers are 309 trying to convince that time server to stop serving time to that 310 system. 312 If a system is a broadcast client and its syslog shows that it is 313 receiving "early" time messages from its server, that is an 314 indication that somebody may be forging packets from a broadcast 315 server. 317 If a server's syslog shows messages that indicates it is receiving 318 timestamps that are earlier than the current system time, then either 319 the system clock is unusually fast or somebody is trying to launch a 320 replay attack against that server. 322 If a system is using broadcast mode and is running ntp-4.2.8p6 or 323 later, use the 4th field of the ntp.keys file to specify the IPs of 324 machines that are allowed to serve time to the group. 326 4.5. Using Pool Servers 328 It only takes a small amount of bandwidth and system resources to 329 synchronize one NTP client, but NTP servers that can service tens of 330 thousands of clients take more resources to run. Users who want to 331 synchronize their computers should only synchronize to servers that 332 they have permission to use. 334 The NTP pool project is a group of volunteers who have donated their 335 computing and bandwidth resources to freely distribute time from 336 primary time sources to others on the Internet. The time is 337 generally of good quality, but comes with no guarantee whatsoever. 338 If you are interested in using the pool, please review their 339 instructions at http://www.pool.ntp.org/en/use.html. 341 If you are a vendor who wishes to provide time service to your 342 customers or clients, consider joining the pool and providing a 343 "vendor zone" thru the pool project. 345 If you want to synchronize many computers, consider running your own 346 NTP servers that are synchronized by the pool, and synchronizing your 347 clients to your in-house NTP servers. This reduces the load on the 348 pool. 350 If you would like to contribute a server with a static IP address and 351 a permanent Internet conenction to the pool, please consult the 352 instructions at http://www.pool.ntp.org/en/join.html . 354 4.6. Leap Second Handling 356 UTC is kept in agreement with the astronomical time UT1 [7] to within 357 +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap 358 second. UTC is an atomic time scale whereas UT1 is based on the 359 rotational rate of the earth. Leap seconds are not introduced at a 360 fixed rate. They are announced by the IERS (International Earth 361 rotation and Reference systems Service) in its Bulletin C [8] when 362 necessary to keep UTC and UT1 aligned. 364 NTP time is based on the UTC timescale, and the protocol has the 365 capability to broadcast leap second information. Some GNSS systems 366 (like GPS) or radio transmitters (like DCF77) broadcast leap second 367 information, so if you are synced to an ntp server that is ultimately 368 synced to a source that provides leap second notification you will 369 get advance notification of impending leap seconds automatically. 371 Since the length of the UT1 day is generally slowly increasing [9], 372 all leap seconds that have been introduced since the practice started 373 in 1972 have been "positive" leap seconds, where a second is added to 374 UTC. NTP also supports a "negative" leap second, where a second is 375 removed from UTC, should that ever become necessary (or useful). 377 While earlier versions of NTP contained some ambiguity regarding when 378 a leap second that is broadcast by a server should be applied by a 379 client, RFC 5905 is clear that leap seconds are only applied on the 380 last day of a month. However, because some older clients may apply 381 it at the end of the current day, it is recommended that NTP servers 382 wait until the last day of the month before broadcasting leap 383 seconds. Doing this will prevent older clients from applying a leap 384 second at the wrong time. Note well that NTPv4 allows a maximum poll 385 interval of 17, or 131,072 seconds, which is longer than a day. 387 The IETF maintains a leap second list [10] for NTP users who are not 388 receiving leap second information through an automatic source. The 389 use of leap second files requires ntpd 4.2.6 or later. After 390 fetching the leap seconds file onto the server, add this line to 391 ntpd.conf to apply and use the file: 393 leapfile "/path/to your/leap-file" 395 You may need to restart ntpd to apply this change. 397 Files are also available from other sources: 399 NIST: ftp://time.nist.gov/pub/leap-seconds.list 401 US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap- 402 seconds.list 404 IERS (announces leap seconds): 405 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 407 ntpd servers with a manually configured leap second file will ignore 408 leap second information broadcast from upstream NTP servers until the 409 leap second file expires. If no valid leap second file is available 410 then a leap second notification from an attached reference clock is 411 always accepted by ntpd. 413 If no valid leap second file is available, a leap second notification 414 may be accepted from upstream NTP servers. As of ntp-4.2.6, a 415 majority of servers must provide the notification before it is 416 accepted. Before 4.2.6, a leap second notification would be accepted 417 if a single upstream server of a group of configured servers provided 418 a leap second notification. This would lead to misbehavior if single 419 NTP servers sent an invalid leap second warning, e.g. due to a faulty 420 GPS receiver in one server, but this behavior was once chosen because 421 in the "early days" there was a greater chance that leap second 422 information would be available from a very limited number of sources. 424 4.6.1. Leap Smearing 426 Some NTP installations may instead make use of a technique called 427 "Leap Smearing". With this method, instead of introducing an extra 428 second (or eliminating a second), NTP time will be slewed in small 429 increments over a comparably large window of time (called the smear 430 interval) around the leap second event. The smear interval should be 431 large enough to make the rate that the time is slewed small, so that 432 clients will follow the smeared time without objecting. Periods 433 ranging from 2 to 24 hours have been used sucessfully. During the 434 adjustment window, all the NTP clients' times may be offset from UTC 435 by as much as a full second, depending on the implementation. But at 436 least all clients will generally agree on what time they think it is! 438 NOTE WELL that using a leap-smear can cause your reported time to be 439 "legally indefensible" and/or be a breach of compliance regulations. 441 The purpose of Leap Smearing is to enable systems that don't deal 442 with the leap second event properly to function consistently, at the 443 expense of fidelity to UTC during the smear window. During a 444 standard leap second event, that minute will have 61 (or possibly 59) 445 seconds in it, and some applications (and even some OS's) are known 446 to have problems with that. 448 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in 449 response to CLIENT requests. Support for leap smearing is not 450 configured by default and must be added at compile time. In 451 addition, no leap smearing will occur unless a leap smear interval is 452 specified in ntpd.conf . For more information, refer to 453 http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [11]. 455 Clients that are connected to leap smearing servers MUST NOT apply 456 the "standard" NTP leap second handling. So if they are using ntpd, 457 these clients must never have a leap second file loaded, and the 458 smearing servers must never advertise to clients that a leap second 459 is pending. 461 Leap Smearing MUST NOT be used for public-facing NTP servers, as they 462 will disagree with non-smearing servers (as well as UTC) during the 463 leap smear interval. However, be aware that some public-facing 464 servers may be configured this way anyway in spite of this guidance. 466 System Administrators are advised to be aware of impending leap 467 seconds and how the servers (inside and outside their organization) 468 they are using deal with them. Individual clients must never be 469 configured to use a mixture of smeared and non-smeared servers. If a 470 client uses smeared servers, the servers it uses must all have the 471 same leap smear configuration. 473 4.7. Configuring ntpd 475 Configuration access to ntpd is controlled by the "modify" status in 476 NTP's configuration file (ntp.conf), which is controlled by a 477 "restrict" statement. The syntax is: 479 restrict address mask address_mask nomodify 481 See https://support.ntp.org/bin/view/Support/ConfiguringNTP for 482 additional information on configuring ntpd. 484 5. NTP Security Mechanisms 486 In the standard configuration NTP packets are exchanged unprotected 487 between client and server. An adversary that is able to become a 488 Man-In-The-Middle is therefore able to drop, replay or modify the 489 content of the NTP packet, which leads to degradation of the time 490 synchronization or the transmission of false time information. A 491 profound threat analysis for time synchronization protocols are given 492 in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms 493 to protect authenticity and integrity of the NTP packets. Both 494 measures protect the NTP packet by means of a Message Authentication 495 Code (MAC). Neither of them encrypts the NTP's payload, because this 496 payload information is not considered to be confidential. 498 5.1. Pre-Shared Key Approach 500 This approach applies a symmetric key for the calculation of the MAC, 501 which protects authenticity and integrity of the exchanged packets 502 for a association. NTP does not provide a mechanism for the exchange 503 of the keys between the associated nodes. Therefore, for each 504 association, keys have to be exchanged securely by external means. 505 It is recommended that each association be protected by its own 506 unique key. NTP does not provide a mechanism to automatically 507 refresh the applied keys. It is therefore recommended that the 508 participants periodically agree on a fresh key. The calculation of 509 the MAC may always be based on an MD5 hash, and an AES-128-CMAC hash 510 is expected to soon be allowed as well. If the NTP daemon is built 511 against an OpenSSL library, NTP can also base the calculation of the 512 MAC upon any other digest algorithm supported by each side's OpenSSL 513 library. 515 To use this approach the communication partners have to exchange the 516 key, which consists of a keyid with a value between 1 and 65534, 517 inclusive, and a label which indicates the chosen digest algorithm. 518 Each communication partner adds this information to their key file in 519 the form: 521 keyid label key 523 The key file contains the key in clear text. Therefore it should 524 only be readable by the NTP process. Different keys are added line 525 by line to the key file. 527 A NTP client establishes a protected association by appending the 528 option "key keyid" to the server statement in the NTP configuration 529 file: 531 server address key keyid 533 Note that the NTP process has to trust the applied key. A key is 534 deemed trusted when its keyid is added to the list of trusted keys by 535 the "trustedkey" statement in the NTP configuration file. 537 trustedkey keyid_1 keyid_2 ... keyid_n 539 5.2. Autokey 541 Autokey was designed in 2003 to provide a means for clients to 542 authenticate servers. However, security researchers have identified 543 vulnerabilities in the Autokey protocol, which make the protocol 544 "useless". [13] 546 Autokey SHOULD NOT BE USED. 548 5.3. Network Time Security 550 Work has begun on an enhanced replacement for Autokey, which is 551 called Network Time Security (NTS) [NTS]. NTS was published in the 552 summer of 2013. As of October 2016, this effort was at draft #15, 553 and about to begin 'final call'. The first unicast implementation of 554 NTS was started in the summer of 2015 and is expected to be released 555 in early 2017. 557 6. NTP Security Best Practices 559 6.1. Minimizing Information Leakage 561 The base NTP packet leaks important information (including reference 562 ID and reference time) that may be used in attacks [NDSS16], 563 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 564 information by sending mode 3 queries to a target system and 565 inspecting the fields in the mode 4 response packet. NTP control 566 queries also leak important information (including reference ID, 567 expected origin timestamp, etc.) that may be used in attacks 568 [CVE-2015-8139]. A remote attacker can learn this information by 569 sending control queries to a target system and inspecting the 570 response. 572 As such, access control should be used to limit the exposure of this 573 information to inappropriate third parties. 575 Hosts should only respond to NTP control queries from authorized 576 parties. One way to do this is to only allow control queries from 577 authenticated sources via authorized IP addresses. 579 A host that is not supposed to act as an NTP server that provides 580 timing information to other hosts may additionally log and drop 581 incoming mode 3 timing queries from unexpected sources. Note well 582 that the easiest way to monitor ntpd's status is to send it a mode 3 583 query. A much better appropach might be to filter mode 3 queries at 584 the edge, or make sure mode 3 queries are allowed from trusted 585 systems or networks. 587 An "leaf-node host" is host that is using NTP solely for the purpose 588 of adjusting its own system time. Such a host is not expected to 589 provide time to other hosts, and relies exclusively on NTP's basic 590 mode to take time from a set of servers. (That is, the host sends 591 mode 3 queries to its servers and receives mode 4 responses from 592 these servers containing timing information.) To minimize 593 information leakage, leaf-node hosts should drop all incoming NTP 594 packets except mode 4 response packets that come from unknown 595 sources. Note well that proper monitoring of an ntpd instance 596 includes checking the time of that ntpd instance. 598 6.2. Avoiding Daemon Restart Attacks 600 RFC 5905 [RFC5905] says NTP clients should not accept time shifts 601 greater than the panic threshold. Specifically, RFC 5905 says "PANIC 602 means the offset is greater than the panic threshold PANICT (1000 s) 603 and SHOULD cause the program to exit with a diagnostic message to the 604 system log." 606 However, this behavior can be exploited by attackers [NDSS16], when 607 the following two conditions hold: 609 1. The operating system automatically restarts the NTP daemon when 610 it quits. (Modern *NIX operating systems are replacing 611 traditional init systems with process supervisors, such as 612 systemd, which can be configured to automatically restart any 613 daemons that quit. This behavior is the default in CoreOS and 614 Arch Linux. It is likely to become the default behavior in other 615 systems as they migrate legacy init scripts to process 616 supervisors such as systemd.) 618 2. If, against long-standing recommendation, ntpd is always started 619 with the -g option, it will ignore the panic threshold when it is 620 restarted. The -g option SHOULD only be provided in cold-start 621 situations. 623 In such cases, if the attacker can send the target an offset that 624 exceeds the panic threshold, the client will quit. Then, when the 625 client restarts, it ignores the panic threshold and accepts the 626 attacker's large offset. 628 Hosts running with the above two conditions should be aware that the 629 panic threshold does not protect them from attacks. The recommended 630 and natural solution is not to run hosts with these conditions. 631 Specifically, only use the -g flag in cold-start situations, or when 632 sufficient oversight and checking is in place to make sure that the 633 use of -g is appropriate. 635 As an alternative, the following steps could be taken to mitigate the 636 risk of attack. 638 o Monitor NTP system log to detect when the NTP daemon has quit due 639 to a panic event, as this could be a sign of an attack. 641 o Request manual intervention when a timestep larger than the panic 642 threshold is detected. 644 o Prevent the NTP daemon from taking time steps that set the clock 645 to a time earlier than the compile date of the NTP daemon. 647 o Add "minsane" and "minclock" parameters to the ntp.conf file so 648 ntpd waits until "enough" trusted sources of time agree on the 649 correct time. 651 6.3. Detection of Attacks Through Monitoring 653 Users should monitor their NTP instances to detect attacks. Many 654 known attacks on NTP have particular signatures. Common attack 655 signatures include: 657 1. "Bogus packets" - A packet whose origin timestamp does not match 658 the value that expected by the client. 660 2. "Zero origin packet" - A packet with a origin timestamp set to 661 zero [CVE-2015-8138]. 663 3. A packet with an invalid cryptographic MAC [CCR16]. 665 The observation of many such packets could indicate that the client 666 is under attack. 668 Also, Kiss-o'-Death (KoD) packets can be used in denial of service 669 attacks. Thus, the observation of even just one KoD packet with a 670 high poll value could be sign that the client is under attack. See 671 Section 6.4 for more information. 673 6.4. KISS Packets 675 The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a 676 server can tell a misbehaving client to "back off" its query rate. 677 It is important for all NTP devices to respect these packets and back 678 off when asked to do so by a server. It is even more important for 679 an embedded device, which may not have exposed a control interface 680 for NTP. 682 That said, a client must only accept a KoD packet if it has a valid 683 origin timestamp. Once a RATE packet is accepted, the client should 684 increase its poll interval value (thus decreasing its polling rate) 685 up to a reasonable maximum. This maximum can vary by implementation 686 but should not exceed a poll interval value of 13 (2 hours). The 687 mechanism to determine how much to increase the poll interval value 688 is undefined in RFC 5905 [RFC5905]. If the client uses the poll 689 interval value sent by the server in the KoD packet, it must not 690 simply accept any value. Using large interval values may open a 691 vector for a denial-of-service attack that causes the client to stop 692 querying its server [NDSS16]. 694 The KoD mechanism relies on clients behaving properly in order to be 695 effective. Some clients ignore the KoD packet entirely, and other 696 poorly-implemented clients might unintentionally increase their poll 697 rate and simulate a denial of service attack. Server administrators 698 should be prepared for this and take measures outside of the NTP 699 protocol to drop packets from misbehaving clients. 701 6.5. Broadcast Mode Should Only Be Used On Trusted Networks 703 Per RFC 5905 [RFC5905], NTP's broadcast mode is authenticated using 704 symmetric key cryptography. The broadcast server and all of its 705 broadcast clients share a symmetric cryptographic key, and the 706 broadcast server uses this key to append a message authentication 707 code (MAC) to the broadcast packets it sends. 709 Importantly, all broadcast clients that listen to this server must 710 know the cryptographic key. This mean that any client can use this 711 key to send valid broadcast messages that look like they come from 712 the broadcast server. Thus, a rogue broadcast client can use its 713 knowledge of this key to attack the other broadcast clients. 715 For this reason, an NTP broadcast server and all its client must 716 trust each other. Broadcast mode should only be run from within a 717 trusted network. 719 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 720 column, a comma-separated list of IPs that are allowed to serve time. 721 Use this feature. Note, however, that an adversarial client that 722 knows the symmetric broadcast key could still easily spoof its source 723 IP to an IP that is allowed to serve time. (This is easy to do 724 because the origin timestamp on broadcast mode packets is not 725 validated by the client. By contrast, client/server and symmetric 726 modes do require origin timestamp validation, making it more 727 difficult to spoof packets [CCR16]. 729 6.6. Symmetric Mode Should Only Be Used With Trusted Peers 731 In symmetric mode, two peers Alice and Bob can both push and pull 732 synchronization to and from each other using either ephemeral 733 symmetric passive (mode 2) or persistent symmetric active (NTP mode 734 1) packets. The persistent association is preconfigured and 735 initiated at the active peer but not preconfigured at the passive 736 peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob 737 mobilizes a new ephemeral association if he does not have one 738 already. This is a security risk for Bob because an arbitrary 739 attacker can attempt to change Bob's time by asking Bob to become its 740 symmetric passive peer. 742 For this reason, a host (Bob) should only allow symmetric passive 743 associations to be established with trusted peers. Specifically, Bob 744 should require each of its symmetric passive association to be 745 cryptographically authenticated. Each symmetric passive association 746 should be authenticated under a different cryptographic key. 748 The use of a different cryptographic key per peer prevents a Sybil 749 attack, where a single malicious peer uses the same cryptographic key 750 to set up multiple symmetric associations a target, and thus bias the 751 results of the target's Byzantine fault tolerant peer selection 752 algorithms. 754 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 755 column, a comma-separated list of IPs that are allowed to serve time. 756 Use this feature. 758 7. NTP in Embedded Devices 760 Readers of this BCP likely already understand how important accurate 761 time is for network computing. And as computing becomes more 762 ubiquitous, there will be many small "Internet of Things" devices 763 that require accurate time. These embedded devices may not have a 764 traditional user interface, but if they connect to the Internet they 765 will be subject to the same security threats as traditional 766 deployments. 768 7.1. Updating Embedded Devices 770 Vendors of embedded devices have a special responsibility to pay 771 attention to the current state of NTP bugs and security issues, 772 because their customers don't have the ability to update their NTP 773 implementation on their own. Those devices may have a single 774 firmware upgrade, provided by the manufacturer, that updates all 775 capabilities at once. This means that the vendor assumes the 776 responsibility of making sure their devices have the latest NTP 777 updates applied. 779 This should also include the ability to update any NTP server 780 addresses on these devices. 782 There is a catalog of NTP server abuse incidents, some of which 783 involve embedded devices, on the Wikipedia page for NTP Server Misuse 784 and Abuse [14]. 786 7.2. Server configuration 788 Vendors of embedded devices that need time synchronization should 789 also carefully consider where they get their time from. There are 790 several public-facing NTP servers available, but they may not be 791 prepared to service requests from thousands of new devices on the 792 Internet. 794 Vendors are encouraged to invest resources into providing their own 795 time servers for their devices to connect to. 797 7.2.1. Get a vendor subdomain for pool.ntp.org 799 The NTP Pool Project offers a program where vendors can obtain their 800 own subdomain that is part of the NTP Pool. This offers vendors the 801 ability to safely make use of the time distributed by the Pool for 802 their devices. Vendors are encouraged to support the pool if they 803 participate. For more information, visit http://www.pool.ntp.org/en/ 804 vendors.html . 806 8. NTP over Anycast 808 Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 809 [RFC7094]). With anycast, a single IP address is assigned to 810 multiple interfaces, and routers direct packets to the closest active 811 interface. 813 Anycast is often used for Internet services at known IP addresses, 814 such as DNS. Anycast can also be used in large organizations to 815 simplify configuration of a large number of NTP clients. Each client 816 can be configured with the same NTP server IP address, and a pool of 817 anycast servers can be deployed to service those requests. New 818 servers can be added to or taken from the pool, and other than a 819 temporary loss of service while a server is taken down, these 820 additions can be transparent to the clients. 822 NOTE WELL: Using a single anycast address for NTP should be done with 823 care. It means each client will likely use a single time server 824 source. A key element of a robust NTP deployment is each client 825 using multiple sources of time. With multiple time sources, a client 826 will analyze the various time sources, selecting good ones, and 827 disregarding poor ones. If a single Anycast address is used, this 828 analysis will not happen. 830 If clients are connected to an NTP server via anycast, the client 831 does not know which particular server they are connected to. As 832 anycast servers may arbitrarily enter and leave the network, the 833 server a particular client is connected to may change. This may 834 cause a small shift in time from the perspective of the client when 835 the server it is connected to changes. It is recommended that 836 anycast only be deployed in environments where these small shifts can 837 be tolerated. 839 Configuration of an anycast interface is independent of NTP. Clients 840 will always connect to the closest server, even if that server is 841 having NTP issues. It is recommended that anycast NTP 842 implementations have an independent method of monitoring the 843 performance of NTP on a server. If the server is not performing to 844 specification, it should remove itself from the Anycast network. It 845 is also recommended that each Anycast NTP server have at least one 846 Unicast interface, so its performance can be checked independently of 847 the anycast routing scheme. 849 One useful application in large networks is to use a hybrid unicast/ 850 anycast approach. Stratum 1 NTP servers can be deployed with unicast 851 interfaces at several sites. Each site may have several Stratum 2 852 servers with two ethernet interfaces. One interface has a unique 853 unicast IP address. The second has an anycast IP interface (with a 854 shared IP address per location). The unicast interfaces can be used 855 to obtain time from the Stratum 1 servers globally (and perhaps peer 856 with the other Stratum 2 servers at their site). Clients at each 857 site can be configured to use the shared anycast address for their 858 site, simplifying their configuration. Keeping the anycast routing 859 restricted on a per-site basis will minimize the disruption at the 860 client if its closest anycast server changes. Each Stratum 2 server 861 can be uniquely identified on their unicast interface, to make 862 monitoring easier. 864 9. Acknowledgements 866 The authors wish to acknowledge the contributions of Sue Graves, 867 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 868 Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, and 869 Robert Nagy. 871 10. IANA Considerations 873 This memo includes no request to IANA. 875 11. Security Considerations 877 Time is a fundamental component of security on the internet. 878 Credentials and certificates can expire. Logins and other forms of 879 access can be revoked after a period of time, or at a scheduled time. 880 And some applications may assume that system time cannot be changed 881 and is always monotonic, and vulnerabilites may be exposed if a time 882 in the past is forced into a system. Therefore, any system 883 adminstrator concerned with security should be concerned with how the 884 current time gets into their system. 886 [NTS] is an Internet-Draft of a collection of methods to secure time 887 transfer over networks. [NTSFORNTP] is an Internet-Draft that 888 applies the methods in [NTS] specifically to NTP. At the time of 889 this writing, these are still drafts. Readers are encourages to 890 check the status of these drafts, and make use of the methods they 891 describe. 893 12. References 895 12.1. Normative References 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, 899 DOI 10.17487/RFC2119, March 1997, 900 . 902 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 903 Defeating Denial of Service Attacks which employ IP Source 904 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 905 May 2000, . 907 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 908 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 909 December 2006, . 911 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 912 "Network Time Protocol Version 4: Protocol and Algorithms 913 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 914 . 916 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 917 "Architectural Considerations of IP Anycast", RFC 7094, 918 DOI 10.17487/RFC7094, January 2014, 919 . 921 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 922 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 923 October 2014, . 925 12.2. Informative References 927 [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's 928 Authenticated Broadcast Mode", SIGCOMM Computer 929 Communications Review (CCR) , 2016. 931 [CVE-2015-8138] 932 Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL 933 ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 934 . 936 [CVE-2015-8139] 937 Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC 938 ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 939 . 941 [CVE-2016-1548] 942 Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode 943 to Interleaved", 2016, 944 . 947 [MILLS2006] 948 Mills, D., "Computer network time synchronization: the 949 Network Time Protocol", CRC Press , 2006. 951 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 952 "Attacking the Network Time Protocol", NDSS'16, San Diego, 953 CA. , 2016, . 955 [NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time 956 Security", draft-ietf-ntp-network-time-security-15 (work 957 in progress), September 2016. 959 [NTSFORNTP] 960 Sibold, D., Roettger, S., and K. Teichel, "Using the 961 Network Time Security Specification to Secure the Network 962 Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work 963 in progress), September 2016. 965 12.3. URIs 967 [1] http://www.ntp.org/downloads.html 969 [2] http://bk.ntp.org/ 971 [3] https://github.com/ntp-project/ntp 973 [4] http://www.bcp38.info 975 [7] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 977 [8] https://www.iers.org/IERS/EN/Publications/Bulletins/ 978 bulletins.html 980 [9] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 982 [10] https://www.ietf.org/timezones/data/leap-seconds.list 984 [11] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno 986 [13] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html 988 [14] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 990 Authors' Addresses 992 Denis Reilly (editor) 993 Spectracom 994 1565 Jefferson Road, Suite 460 995 Rochester, NY 14623 996 US 998 Email: denis.reilly@spectracom.orolia.com 999 Harlan Stenn 1000 Network Time Foundation 1001 P.O. Box 918 1002 Talent, OR 97540 1003 US 1005 Email: stenn@nwtime.org 1007 Dieter Sibold 1008 Physikalisch-Technische Bundesanstalt 1009 Bundesallee 100 1010 Braunschweig D-38116 1011 Germany 1013 Phone: +49-(0)531-592-8420 1014 Fax: +49-531-592-698420 1015 Email: dieter.sibold@ptb.de