idnits 2.17.00 (12 Aug 2021) /tmp/idnits26139/draft-ietf-ntp-bcp-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2019) is 1145 days in the past. Is this intentional? 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 963 -- Looks like a reference, but probably isn't: '2' on line 966 -- Looks like a reference, but probably isn't: '3' on line 968 -- Looks like a reference, but probably isn't: '4' on line 970 -- Looks like a reference, but probably isn't: '5' on line 972 -- Looks like a reference, but probably isn't: '6' on line 974 -- Looks like a reference, but probably isn't: '7' on line 977 -- Looks like a reference, but probably isn't: '8' on line 979 -- Looks like a reference, but probably isn't: '9' on line 981 -- Looks like a reference, but probably isn't: '10' on line 993 -- Looks like a reference, but probably isn't: '11' on line 1091 -- Looks like a reference, but probably isn't: '12' on line 1095 == Outdated reference: draft-ietf-ntp-mac has been published as RFC 8573 == Outdated reference: A later version (-11) exists of draft-ietf-ntp-mode-6-cmds-06 == Outdated reference: draft-ietf-ntp-using-nts-for-ntp has been published as RFC 8915 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 14 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 Orolia USA 4 Intended status: Best Current Practice H. Stenn 5 Expires: September 27, 2019 Network Time Foundation 6 D. Sibold 7 PTB 8 March 26, 2019 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-13 13 Abstract 15 The Network Time Protocol (NTP) is one of the oldest protocols on the 16 Internet and has been widely used since its initial publication. 17 This document is a collection of Best Practices for general operation 18 of NTP servers and clients on the Internet. It includes 19 recommendations for stable, accurate and secure operation of NTP 20 infrastructure. This document is targeted at NTP version 4 as 21 described in RFC 5905. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 27, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. General Network Security Best Practices . . . . . . . . . . . 3 60 2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 62 3.1. Keeping NTP up to date . . . . . . . . . . . . . . . . . 4 63 3.2. Use enough time sources . . . . . . . . . . . . . . . . . 4 64 3.3. Use a diversity of Reference Clocks . . . . . . . . . . . 5 65 3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 6 66 3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 68 3.7. Leap Second Handling . . . . . . . . . . . . . . . . . . 8 69 3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9 70 4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10 71 4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10 72 4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11 74 4.4. External Security Protocols . . . . . . . . . . . . . . . 11 75 5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 11 76 5.1. Minimizing Information Leakage . . . . . . . . . . . . . 11 77 5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12 78 5.3. Detection of Attacks Through Monitoring . . . . . . . . . 14 79 5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 14 80 5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 15 81 5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 15 82 6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 83 6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16 84 6.2. Server configuration . . . . . . . . . . . . . . . . . . 16 85 7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 11.2. Informative References . . . . . . . . . . . . . . . . . 19 92 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 Appendix A. Best Practices specific to the Network Time 94 Foundation implementation . . . . . . . . . . . . . 21 95 A.1. Use enough time sources . . . . . . . . . . . . . . . . . 22 96 A.2. NTP Control and Facility Messages . . . . . . . . . . . . 22 97 A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 23 98 A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 23 99 A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 23 100 A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 24 101 A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 24 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 104 1. Introduction 106 NTP version 4 (NTPv4) has been widely used since its publication as 107 [RFC5905]. This document is a collection of best practices for the 108 operation of NTP clients and servers. 110 The recommendations in this document are intended to help operators 111 distribute time on their networks more accurately and more securely. 112 It is intended to apply generally to a broad range of networks. Some 113 specific networks may have higher accuracy requirements that require 114 additional techniques beyond what is documented here. 116 Among the best practices covered are recommendations for general 117 network security, time protocol specific security, and NTP server and 118 client configuration. NTP operation in embedded devices is also 119 covered. 121 This document also contains information for protocol implementors who 122 want to develop their own implementations that are compliant to RFC 123 5905. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. General Network Security Best Practices 135 2.1. BCP 38 137 Many network attacks rely on modifying the IP source address of a 138 packet to point to a different IP address than the computer which 139 originated it. UDP-based protocols such as NTP are generally more 140 susceptible to spoofing attacks than connection-oriented protocols. 141 NTP control messages can generate a lot of data in response to a 142 small query, which makes it attractive as a vector for distributed 143 denial-of-service attacks. (NTP Control messages are discussed 144 further in Section 3.4). One documented instance of such an attack 145 can be found here [1], and further discussion in [IMC14] and 146 [NDSS14]. 148 BCP 38 [RFC2827] was published in 2000 to to provide some level of 149 remediation against address-spoofing attacks. BCP 38 calls for 150 filtering outgoing and incoming traffic to make sure that the source 151 and destination IP addresses are consistent with the expected flow of 152 traffic on each network interface. It is RECOMMENDED that ISP's and 153 large corporate networks implement ingress and egress filtering. 154 More information is available at the BCP38 Info Web page [2] . 156 3. NTP Configuration Best Practices 158 This section provides Best Practices for NTP configuration and 159 operation. Application of these best practices that are specific to 160 the Network Time Foundation implementation, including example 161 configuration directives valid at the time of this writing, are 162 compiled in Appendix A. 164 3.1. Keeping NTP up to date 166 There are multiple versions of the NTP protocol in use, and multiple 167 implementations, on many different platforms. The practices in this 168 document are meant to apply generally to any implementation of 169 [RFC5905]. NTP users should select an implementation that is 170 actively maintained. Users should keep up to date on any known 171 attacks on their selected implementation, and deploy updates 172 containing security fixes as soon as practical. 174 3.2. Use enough time sources 176 An NTP implementation that is compliant with [RFC5905] takes the 177 available sources of time and submits this timing data to 178 sophisticated intersection, clustering, and combining algorithms to 179 get the best estimate of the correct time. The description of these 180 algorithms is beyond the scope of this document. Interested readers 181 should read [RFC5905] or the detailed description of NTP in 182 [MILLS2006]. 184 o If there is only 1 source of time, the answer is obvious. It may 185 not be a good source of time, but it's the only source of time 186 that can be considered. Any issue with the time at the source 187 will be passed on to the client. 189 o If there are 2 sources of time and they agree well enough, then 190 the best time can be calculated easily. But if one source fails, 191 then the solution degrades to the single-source solution outlined 192 above. And if the two sources don't agree, it will be difficult 193 to know which one is correct without making use of information 194 from outside of the protocol. 196 o If there are 3 sources of time, there is more data available to 197 converge on the best calculated time, and this time is more likely 198 to be accurate. And the loss of one of the sources (by becoming 199 unreachable or unusable) can be tolerated. But at that point, the 200 solution degrades to the 2 source solution. 202 o 4 or more sources of time is better, as long as the sources are 203 diverse (Section 3.3). If one of these sources develops a problem 204 there are still at least 3 other time sources. 206 This analysis assumes that a majority of the servers used in the 207 solution are honest, even if some may be inaccurate. Operators 208 should be aware of the possibility that if an attacker is in control 209 of the network, the time coming from all servers could be 210 compromised. 212 Operators who are concerned with maintaining accurate time SHOULD use 213 at least 4 independent, diverse sources of time. Four sources will 214 provide sufficient backup in case one source goes down. If four 215 sources are not available, operators MAY use fewer sources, subject 216 to the risks outlined above. 218 But even with 4 or more sources of time, systemic problems can 219 happen. One example involves the leap smearing concept detailed in 220 Section 3.7.1. For several hours before and after the June 2015 leap 221 second, several operators configured their NTP servers with leap 222 smearing while others did not. Many NTP end nodes could not 223 determine an accurate time source because 2 of their 4 sources of 224 time gave them consistent UTC/POSIX time, while the other 2 gave them 225 consistent leap-smeared time. This is just one of many potential 226 causes of disagreement among time sources. 228 Operators are advised to monitor all time sources that are in use. 229 If time sources do not generally agree, operators are encouraged to 230 investigate the cause of this and either correct the problems or stop 231 using defective servers. See Section 3.5 for more information. 233 3.3. Use a diversity of Reference Clocks 235 When using servers with attached hardware reference clocks, it is 236 suggested that different types of reference clocks be used. Having a 237 diversity of sources with independent implementations means that any 238 one issue is less likely to cause a service interruption. 240 Are all clocks on a network from the same vendor? They may have the 241 same bugs. Even devices from different vendors may not be truly 242 independent if they share common elements. Are they using the same 243 base chipset? Are they all running the same version of firmware? 244 Chipset and firmware bugs can happen, but they can be more difficult 245 to diagnose than application software bugs. When having the correct 246 time is of critical importance, it's ultimately up to operators to 247 ensure that their sources are sufficiently independent, even if they 248 are not under the operator's control. 250 A systemic problem with time from any satellite navigation service is 251 possible and has happened. Sunspot activity can render satellite or 252 radio-based time source unusable. Depending on the application 253 requirements, operators may need to consider backup scenarios in the 254 rare circumstance when the satellite system is faulty or unavailable. 256 3.4. Control Messages 258 Some implementations of NTPv4 provide the NTP Control Messages (also 259 known as Mode 6 messages) that were originally specified in 260 Appendix B of [RFC1305] which defined NTPv3. These messages were 261 never included the NTPv4 specification, but they are still used. At 262 the time of this writing, work is being done to formally document the 263 structure of these control messages in [I-D.ietf-ntp-mode-6-cmds]. 265 The NTP Control Messages are designed to permit monitoring and 266 optionally authenticated control of NTP and its configuration. Used 267 properly, these facilities provide vital debugging and performance 268 information and control. But these facilities can be a vector for 269 amplification attacks when abused. For this reason, it is 270 RECOMMENDED that publicly-facing NTP servers should block NTP Control 271 Message queries from outside their organization. 273 The ability to use NTP Control Messages beyond their basic monitoring 274 capabilities SHOULD be limited to authenticated sessions that provide 275 a 'controlkey'. It can also be limited through mechanisms outside of 276 the NTP specification, such as Access Control Lists, that only allow 277 access from approved IP addresses. 279 The NTP Control Messages responses are much larger than the 280 corresponding queries. Thus, they can be abused in high-bandwidth 281 DDoS attacks. Section 2.1 gives more information on how to provide 282 protection for this abuse by implementing BCP 38. 284 3.5. Monitoring 286 Operators SHOULD use their NTP implementation's remote monitoring 287 capabilities to quickly identify servers which are out of sync, and 288 ensure correctness of the service. Operators SHOULD also monitor 289 system logs for messages so problems and abuse attempts can be 290 quickly identified. 292 If a system starts to receive NTP Reply packets from a remote time 293 server that do not correspond to any requests sent by the system, 294 that can be an indication that an attacker is forging that system's 295 IP address in requests to the remote time server. The goal of this 296 attack is to adversely impact the availability of time to the 297 targeted system whose address is being forged. Based on these forged 298 packets, the remote time server might decide to throttle or rate 299 limit packets, or even stop sending packets to the targeted system. 301 If a system is a broadcast client and its system log shows that it is 302 receiving early time messages from its server, that is an indication 303 that somebody may be forging packets from a broadcast server. 304 (Broadcast client and server modes are defined in Section 3 of 305 [RFC5905]) 307 If a server's system log shows messages that indicates it is 308 receiving NTP timestamps that are much earlier than the current 309 system time, then either the system clock is unusually fast or 310 somebody is trying to launch a replay attack against that server. 312 3.6. Using Pool Servers 314 It only takes a small amount of bandwidth and system resources to 315 synchronize one NTP client, but NTP servers that can service tens of 316 thousands of clients take more resources to run. Network operators 317 and advanced users who want to synchronize their computers MUST only 318 synchronize to servers that they have permission to use. 320 The NTP Pool Project is a group of volunteers who have donated their 321 computing and bandwidth resources to freely distribute time from 322 primary time sources to others on the Internet. The time is 323 generally of good quality but comes with no guarantee whatsoever. If 324 you are interested in using this pool, please review their 325 instructions at http://www.pool.ntp.org/en/use.html [3]. 327 Vendors can obtain their own subdomain that is part of the NTP Pool 328 Project. This offers vendors the ability to safely make use of the 329 time distributed by the pool for their devices. Details are 330 available at http://www.pool.ntp.org/en/vendors.html [4] . 332 If there is a need to synchronize many computers, an operator may 333 want to run local NTP servers that are synchronized to the NTP Pool 334 Project. NTP users on that operator's networks can then be 335 synchronized to local NTP servers. 337 3.7. Leap Second Handling 339 UTC is kept in agreement with the astronomical time UT1 [5] to within 340 +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap 341 second. UTC is an atomic time scale whereas UT1 is based on the 342 rotational rate of the earth. Leap seconds are not introduced at a 343 fixed rate. They are announced by the International Earth Rotation 344 and Reference Systems Service (IERS) in its Bulletin C [6] when 345 necessary to keep UTC and UT1 aligned. 347 NTP time is based on the UTC timescale, and the protocol has the 348 capability to broadcast leap second information. Some Global 349 Navigation Satellite Systems (like GPS) or radio transmitters (like 350 DCF77) broadcast leap second information. If an NTP client is synced 351 to an NTP server that provides leap second notification, the client 352 will get advance notification of impending leap seconds 353 automatically. 355 Since the length of the UT1 day is generally slowly increasing [7], 356 all leap seconds that have been introduced since the practice started 357 in 1972 have been positive leap seconds, where a second is added to 358 UTC. NTP also supports a negative leap second, where a second is 359 removed from UTC, if that ever becomes necessary. 361 While earlier versions of NTP contained some ambiguity regarding when 362 a leap second that is broadcast by a server should be applied by a 363 client, RFC 5905 is clear that leap seconds are only applied on the 364 last day of a month. However, because some older clients may apply 365 it at the end of the current day, it is RECOMMENDED that NTP servers 366 wait until the last day of the month before broadcasting leap 367 seconds. Doing this will prevent older clients from applying a leap 368 second at the wrong time. When implementing this recommendation, 369 operators should ensure that clients are not configured to use 370 polling intervals greater than 24 hours, so the leap second 371 notification is not missed. 373 In circumstances where an NTP server is not receiving leap second 374 information from an automated source, certain organizations maintain 375 files which are updated every time a new leap second is announced: 377 NIST: ftp://time.nist.gov/pub/leap-seconds.list 378 US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap- 379 seconds.list 381 IERS (announces leap seconds): 382 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 384 3.7.1. Leap Smearing 386 Some NTP installations make use of a technique called Leap Smearing. 387 With this method, instead of introducing an extra second (or 388 eliminating a second) on a leap second event, NTP time will be slewed 389 in small increments over a comparably large window of time (called 390 the smear interval) around the leap second event. The smear interval 391 should be large enough to make the rate that the time is slewed 392 small, so that clients will follow the smeared time without 393 objecting. Periods ranging from 2 to 24 hours have been used 394 successfully. During the adjustment window, all the NTP clients' 395 times may be offset from UTC by as much as a full second, depending 396 on the implementation. But at least all clients will generally agree 397 on what time they think it is. 399 The purpose of Leap Smearing is to enable systems that don't deal 400 with the leap second event properly to function consistently, at the 401 expense of fidelity to UTC during the smear window. During a 402 standard leap second event, that minute will have 61 (or possibly 59) 403 seconds in it, and some applications (and even some OS's) are known 404 to have problems with that. 406 Operators who have legal obligations or other strong requirements to 407 be synchronized with UTC or civil time SHOULD NOT use leap smearing, 408 because the distributed time cannot be guaranteed to be traceable to 409 UTC during the smear interval. 411 Clients that are connected to leap smearing servers MUST NOT apply 412 the standard NTP leap second handling. These clients must never have 413 a leap second file loaded, and the smearing servers must never 414 advertise to clients that a leap second is pending. 416 Any use of leap smearing servers should be limited to within a 417 single, well-controlled environment. Leap Smearing MUST NOT be used 418 for public-facing NTP servers, as they will disagree with non- 419 smearing servers (as well as UTC) during the leap smear interval, and 420 there is no standardized way for a client to detect that a server is 421 using leap smearing. However, be aware that some public-facing 422 servers may be configured this way anyway in spite of this guidance. 424 System Administrators are advised to be aware of impending leap 425 seconds and how the servers (inside and outside their organization) 426 they are using deal with them. Individual clients MUST NOT be 427 configured to use a mixture of smeared and non-smeared servers. If a 428 client uses smeared servers, the servers it uses must all have the 429 same leap smear configuration. 431 4. NTP Security Mechanisms 433 In the standard configuration NTP packets are exchanged unprotected 434 between client and server. An adversary that is able to become a 435 Man-In-The-Middle is therefore able to drop, replay or modify the 436 content of the NTP packet, which leads to degradation of the time 437 synchronization or the transmission of false time information. A 438 threat analysis for time synchronization protocols is given in 439 [RFC7384]. NTP provides two internal security mechanisms to protect 440 authenticity and integrity of the NTP packets. Both measures protect 441 the NTP packet by means of a Message Authentication Code (MAC). 442 Neither of them encrypts the NTP's payload, because this payload 443 information is not considered to be confidential. 445 4.1. Pre-Shared Key Approach 447 This approach applies a symmetric key for the calculation of the MAC, 448 which protects authenticity and integrity of the exchanged packets 449 for an association. NTP does not provide a mechanism for the 450 exchange of the keys between the associated nodes. Therefore, for 451 each association, keys MUST be exchanged securely by external means, 452 and they MUST be protected from disclosure. It is RECOMMENDED that 453 each association be protected by its own unique key. It is 454 RECOMMENDED that participants agree to refresh keys periodically. 455 However, NTP does not provide a mechanism to assist in doing so. 456 Each communication partner will need to keep track of its keys in its 457 own local key storage. 459 [RFC5905] specifies using the MD5 hash algorithm for calculation of 460 the MAC, but other algorithms may be supported as well. The MD5 hash 461 is now considered to be too weak and unsuitable for cryptographic 462 usage. [RFC6151] has more information on the algorithm's weaknesses. 463 Implementations will soon be available based on AES-128-CMAC 464 [I-D.ietf-ntp-mac], and users SHOULD use that when it is available. 466 Some implementations store the key in clear text. Therefore it MUST 467 only be readable by the NTP process. 469 An NTP client has to be able to link a key to a particular server in 470 order to establish a protected association. This linkage is 471 implementation specific. Once applied, a key will be trusted until 472 the link is removed. 474 4.2. Autokey 476 [RFC5906] specifies the Autokey protocol. It was published in 2010 477 to provide automated key management and authentication of NTP 478 servers. However, security researchers have identified 479 vulnerabilities [8] in the Autokey protocol. 481 Autokey SHOULD NOT be used. 483 4.3. Network Time Security 485 Work is in progress on an enhanced replacement for Autokey. Refer to 486 [I-D.ietf-ntp-using-nts-for-ntp] for more information. 488 4.4. External Security Protocols 490 If applicable, external security protocols such as IPsec and MACsec 491 can be applied to enhance integrity and authenticity protection of 492 NTP time synchronization packets. Usage of such external security 493 protocols can decrease time synchronization performance [RFC7384]. 494 Therefore, operators are advised to carefully evaluate if the 495 decreased time synchronization performance meets their specific 496 timing requirements. 498 Note that none of the security measures described in Section 4 can 499 prevent packet delay manipulation attacks on NTP. Such delay attacks 500 can target time synchronization packets sent as clear-text or even 501 within an encrypted tunnel. These attacks are described further in 502 Section 3.2.6 of [RFC7384]. 504 5. NTP Security Best Practices 506 This section lists some general NTP security practices, but these 507 issues may (or may not) have been mitigated in particular versions of 508 particular implementations. Contact the maintainers of the relevant 509 implementation for more information. 511 5.1. Minimizing Information Leakage 513 The base NTP packet leaks important information (including reference 514 ID and reference time) that may be used in attacks [NDSS16], 515 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 516 information by sending mode 3 queries to a target system and 517 inspecting the fields in the mode 4 response packet. NTP control 518 queries also leak important information (including reference ID, 519 expected origin timestamp, etc.) that may be used in attacks 520 [CVE-2015-8139]. A remote attacker can learn this information by 521 sending control queries to a target system and inspecting the leaked 522 information in the response. 524 As such, mechanisms outside of the NTP protocol, such as Access 525 Control Lists, SHOULD be used to limit the exposure of this 526 information to allowed IP addresses, and keep it from remote 527 attackers not on the list. Hosts SHOULD only respond to NTP control 528 queries from authorized parties. 530 An NTP client that does not provide time on the network can 531 additionally log and drop incoming mode 3 timing queries from 532 unexpected sources. Note well that the easiest way to monitor the 533 status of an NTP instance is to send it a mode 3 query, so it may not 534 be desirable to drop all mode 3 queries. As an alternative, 535 operators SHOULD either filter mode 3 queries from outside their 536 networks, or make sure mode 3 queries are allowed only from trusted 537 systems or networks. 539 A "leaf-node host" is a host that is using NTP solely for the purpose 540 of adjusting its own system time. Such a host is not expected to 541 provide time to other hosts, and relies exclusively on NTP's basic 542 mode to take time from a set of servers. (That is, the host sends 543 mode 3 queries to its servers and receives mode 4 responses from 544 these servers containing timing information.) To minimize 545 information leakage, leaf-node hosts SHOULD drop all incoming NTP 546 packets except mode 4 response packets that come from known sources. 547 An exception to this can be made if a leaf-node host is being 548 actively monitored, in which case incoming packets from the 549 monitoring server can be allowed. 551 Please refer to [I-D.ietf-ntp-data-minimization] for more 552 information. 554 5.2. Avoiding Daemon Restart Attacks 556 [RFC5905] says NTP clients should not accept time shifts greater than 557 the panic threshold. Specifically, RFC 5905 says "PANIC means the 558 offset is greater than the panic threshold PANICT (1000 s) and SHOULD 559 cause the program to exit with a diagnostic message to the system 560 log." 562 However, this behavior can be exploited by attackers as described in 563 [NDSS16], when the following two conditions hold: 565 1. The operating system automatically restarts the NTP client when 566 it quits. (Modern *NIX operating systems are replacing 567 traditional init systems with process supervisors, such as 568 systemd, which can be configured to automatically restart any 569 daemons that quit. This behavior is the default in CoreOS and 570 Arch Linux. As of the time of this writing, it appears likely to 571 become the default behavior in other systems as they migrate 572 legacy init scripts to process supervisors such as systemd.) 574 2. The NTP client is configured to ignore the panic threshold on all 575 restarts. 577 In such cases, if the attacker can send the target an offset that 578 exceeds the panic threshold, the client will quit. Then, when it 579 restarts, it ignores the panic threshold and accepts the attacker's 580 large offset. 582 Operators need to be aware that when operating with the above two 583 conditions, the panic threshold offers no protection from attacks. 584 The natural solution is not to run hosts with these conditions. 585 Specifically, operators SHOULD NOT ignore the panic threshold in all 586 cold-start situations unless sufficient oversight and checking is in 587 place to make sure that this type of attack cannot happen. 589 As an alternative, the following steps MAY be taken by operators to 590 mitigate the risk of attack: 592 o Monitor the NTP system log to detect when the NTP daemon has quit 593 due to a panic event, as this could be a sign of an attack. 595 o Request manual intervention when a timestep larger than the panic 596 threshold is detected. 598 o Configure the ntp client to only ignore the panic threshold in a 599 cold start situation. 601 o Increase the minimum number of servers required before the NTP 602 client adjusts the system clock. This will make the NTP client 603 wait until enough trusted sources of time agree before declaring 604 the time to be correct. 606 In addition, the following steps SHOULD be taken by those who 607 implement the NTP protocol: 609 o Prevent the NTP daemon from taking time steps that set the clock 610 to a time earlier than the compile date of the NTP daemon. 612 o Prevent the NTP daemon from putting 'INIT' in the reference ID of 613 its NTP packets upon initializing. This will make it more 614 difficult for attackers to know when the daemon reboots. 616 5.3. Detection of Attacks Through Monitoring 618 Operators SHOULD monitor their NTP instances to detect attacks. Many 619 known attacks on NTP have particular signatures. Common attack 620 signatures include: 622 1. Bogus packets - A packet whose origin timestamp does not match 623 the value that expected by the client. 625 2. Zero origin packet - A packet with an origin timestamp set to 626 zero [CVE-2015-8138]. 628 3. A packet with an invalid cryptographic MAC [CCR16]. 630 The observation of many such packets could indicate that the client 631 is under attack. 633 5.4. Kiss-o'-Death Packets 635 The "Kiss-o'-Death" (KoD) packet includes a rate management mechanism 636 where a server can tell a misbehaving client to reduce its query 637 rate. KoD packets in general (and the RATE packet in particular) are 638 defined in Section 7.4 of [RFC5905]. It is RECOMMENDED that all NTP 639 devices respect these packets and back off when asked to do so by a 640 server. It is even more important for an embedded device, which may 641 not have an exposed control interface for NTP. 643 That said, a client MUST only accept a KoD packet if it has a valid 644 origin timestamp. Once a RATE packet is accepted, the client should 645 increase its poll interval value (thus decreasing its polling rate) 646 up to a reasonable maximum. This maximum can vary by implementation 647 but should not exceed a poll interval value of 13 (2 hours). The 648 mechanism to determine how much to increase the poll interval value 649 is undefined in [RFC5905]. If the client uses the poll interval 650 value sent by the server in the RATE packet, it MUST NOT simply 651 accept any value. Using large interval values may open a vector for 652 a denial-of-service attack that causes the client to stop querying 653 its server [NDSS16]. 655 The KoD rate management mechanism relies on clients behaving properly 656 in order to be effective. Some clients ignore the RATE packet 657 entirely, and other poorly-implemented clients might unintentionally 658 increase their poll rate and simulate a denial of service attack. 659 Server administrators are advised to be prepared for this and take 660 measures outside of the NTP protocol to drop packets from misbehaving 661 clients when these clients are detected. 663 Kiss-o'-Death (KoD) packets can be used in denial of service attacks. 664 Thus, the observation of even just one RATE packet with a high poll 665 value could be sign that the client is under attack. And KoD packets 666 are commonly accepted even when not cryptographically authenticated, 667 which increases the risk of denial of service attacks. 669 5.5. Broadcast Mode Should Only Be Used On Trusted Networks 671 Per [RFC5905], NTP's broadcast mode is authenticated using symmetric 672 key cryptography. The broadcast server and all its broadcast clients 673 share a symmetric cryptographic key, and the broadcast server uses 674 this key to append a message authentication code (MAC) to the 675 broadcast packets it sends. 677 Importantly, all broadcast clients that listen to this server have to 678 know the cryptographic key. This mean that any client can use this 679 key to send valid broadcast messages that look like they come from 680 the broadcast server. Thus, a rogue broadcast client can use its 681 knowledge of this key to attack the other broadcast clients. 683 For this reason, an NTP broadcast server and all its clients have to 684 trust each other. Broadcast mode SHOULD only be run from within a 685 trusted network. 687 5.6. Symmetric Mode Should Only Be Used With Trusted Peers 689 In symmetric mode, two peers Alice and Bob can both push and pull 690 synchronization to and from each other using either ephemeral 691 symmetric passive (mode 2) or persistent symmetric active (NTP mode 692 1) packets. The persistent association is preconfigured and 693 initiated at the active peer but not preconfigured at the passive 694 peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob 695 mobilizes a new ephemeral association if he does not have one 696 already. This is a security risk for Bob because an arbitrary 697 attacker can attempt to change Bob's time by asking Bob to become its 698 symmetric passive peer. 700 For this reason, a host SHOULD only allow symmetric passive 701 associations to be established with trusted peers. Specifically, a 702 host SHOULD require each of its symmetric passive association to be 703 cryptographically authenticated. Each symmetric passive association 704 SHOULD be authenticated under a different cryptographic key. 706 6. NTP in Embedded Devices 708 As computing becomes more ubiquitous, there will be many small 709 embedded devices that require accurate time. These devices may not 710 have a persistent battery-backed clock, so using NTP to set the 711 correct time on power-up may be critical for proper operation. These 712 devices may not have a traditional user interface, but if they 713 connect to the Internet they will be subject to the same security 714 threats as traditional deployments. 716 6.1. Updating Embedded Devices 718 Vendors of embedded devices are advised to pay attention to the 719 current state of protocol security issues and bugs in their chosen 720 implementation, because their customers don't have the ability to 721 update their NTP implementation on their own. Those devices may have 722 a single firmware upgrade, provided by the manufacturer, that updates 723 all capabilities at once. This means that the vendor assumes the 724 responsibility of making sure their devices have an up-to-date and 725 secure NTP implementation. 727 Vendors of embedded devices SHOULD include the ability to update the 728 list of NTP servers used by the device. 730 There is a catalog of NTP server abuse incidents, some of which 731 involve embedded devices, on the Wikipedia page for NTP Server Misuse 732 and Abuse [9]. 734 6.2. Server configuration 736 Vendors of embedded devices with preconfigured NTP servers need to 737 carefully consider which servers to use. There are several public- 738 facing NTP servers available, but they may not be prepared to service 739 requests from thousands of new devices on the Internet. Vendors MUST 740 only preconfigure NTP servers that they have permission to use. 742 Vendors are encouraged to invest resources into providing their own 743 time servers for their devices to connect to. This may be done 744 through the NTP Pool Project, as documented in Section 3.6. 746 Vendors should read [RFC4085], which advises against embedding 747 globally-routable IP addresses in products, and offers several better 748 alternatives. 750 7. NTP over Anycast 752 Anycast is described in BCP 126 [RFC4786]. (Also see [RFC7094]). 753 With anycast, a single IP address is assigned to multiple servers, 754 and routers direct packets to the closest active server. 756 Anycast is often used for Internet services at known IP addresses, 757 such as DNS. Anycast can also be used in large organizations to 758 simplify configuration of many NTP clients. Each client can be 759 configured with the same NTP server IP address, and a pool of anycast 760 servers can be deployed to service those requests. New servers can 761 be added to or taken from the pool, and other than a temporary loss 762 of service while a server is taken down, these additions can be 763 transparent to the clients. 765 Note well that using a single anycast address for NTP presents its 766 own potential issues. It means each client will likely use a single 767 time server source. A key element of a robust NTP deployment is each 768 client using multiple sources of time. With multiple time sources, a 769 client will analyze the various time sources, selecting good ones, 770 and disregarding poor ones. If a single Anycast address is used, 771 this analysis will not happen. This can be mitigated by creating 772 multiple, separate anycast pools so clients can have multiple sources 773 of time while still gaining the configuration benefits of the anycast 774 pools. 776 If clients are connected to an NTP server via anycast, the client 777 does not know which particular server they are connected to. As 778 anycast servers enter and leave the network, or the network topology 779 changes, the server a particular client is connected to may change. 780 This may cause a small shift in time from the perspective of the 781 client when the server it is connected to changes. In extreme cases 782 where the network topology is changing rapidly, this could cause the 783 server seen by a client to rapidly change as well, which can lead to 784 larger time inaccuracies. It is RECOMMENDED that network operators 785 only deploy anycast NTP in environments where operators know these 786 small shifts can be tolerated by the applications running on the 787 clients being synchronized in this manner. 789 Configuration of an anycast interface is independent of NTP. Clients 790 will always connect to the closest server, even if that server is 791 having NTP issues. It is RECOMMENDED that anycast NTP 792 implementations have an independent method of monitoring the 793 performance of NTP on a server. If the server is not performing to 794 specification, it should remove itself from the Anycast network. It 795 is also RECOMMENDED that each Anycast NTP server have an alternative 796 method of access, such as an alternate Unicast IP address, so its 797 performance can be checked independently of the anycast routing 798 scheme. 800 One useful application in large networks is to use a hybrid unicast/ 801 anycast approach. Stratum 1 NTP servers can be deployed with unicast 802 interfaces at several sites. Each site may have several Stratum 2 803 servers with two ethernet interfaces, or a single interface which can 804 support multiple addresses. One interface has a unique unicast IP 805 address. The second has an anycast IP interface (with a shared IP 806 address per location). The unicast interfaces can be used to obtain 807 time from the Stratum 1 servers globally (and perhaps peer with the 808 other Stratum 2 servers at their site). Clients at each site can be 809 configured to use the shared anycast address for their site, 810 simplifying their configuration. Keeping the anycast routing 811 restricted on a per-site basis will minimize the disruption at the 812 client if its closest anycast server changes. Each Stratum 2 server 813 can be uniquely identified on their unicast interface, to make 814 monitoring easier. 816 8. Acknowledgments 818 The authors wish to acknowledge the contributions of Sue Graves, 819 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 820 Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, 821 Robert Nagy, and Brian Haberman. 823 9. IANA Considerations 825 This memo includes no request to IANA. 827 10. Security Considerations 829 Time is a fundamental component of security on the internet. The 830 absence of a reliable source of current time subverts many common web 831 authentication schemes, e.g., by allowing the use of expired 832 credentials or by allowing for replay of messages only intended to be 833 processed once. 835 Much of this document directly addresses how to secure NTP servers. 836 In particular, see Section 2, Section 4, and Section 5. 838 There are several general threats to time synchronization protocols 839 which are discussed in [RFC7384]. 841 [I-D.ietf-ntp-using-nts-for-ntp] specifies the Network Time Security 842 (NTS) mechanism and applies it to NTP. Readers are encouraged to 843 check the status of the draft, and make use of the methods it 844 describes. 846 11. References 848 11.1. Normative References 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, 852 DOI 10.17487/RFC2119, March 1997, 853 . 855 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 856 Defeating Denial of Service Attacks which employ IP Source 857 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 858 May 2000, . 860 [RFC4085] Plonka, D., "Embedding Globally-Routable Internet 861 Addresses Considered Harmful", BCP 105, RFC 4085, 862 DOI 10.17487/RFC4085, June 2005, 863 . 865 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 866 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 867 December 2006, . 869 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 870 "Network Time Protocol Version 4: Protocol and Algorithms 871 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 872 . 874 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 875 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 876 May 2017, . 878 11.2. Informative References 880 [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's 881 Authenticated Broadcast Mode", SIGCOMM Computer 882 Communications Review (CCR) , 2016. 884 [CVE-2015-8138] 885 Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL 886 ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 887 . 889 [CVE-2015-8139] 890 Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC 891 ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 892 . 894 [CVE-2016-1548] 895 Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode 896 to Interleaved", 2016, 897 . 900 [I-D.ietf-ntp-data-minimization] 901 Franke, D. and A. Malhotra, "NTP Client Data 902 Minimization", draft-ietf-ntp-data-minimization-04 (work 903 in progress), March 2019. 905 [I-D.ietf-ntp-mac] 906 Malhotra, A. and S. Goldberg, "Message Authentication Code 907 for the Network Time Protocol", draft-ietf-ntp-mac-06 908 (work in progress), January 2019. 910 [I-D.ietf-ntp-mode-6-cmds] 911 Haberman, B., "Control Messages Protocol for Use with 912 Network Time Protocol Version 4", draft-ietf-ntp-mode- 913 6-cmds-06 (work in progress), September 2018. 915 [I-D.ietf-ntp-using-nts-for-ntp] 916 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 917 Sundblad, "Network Time Security for the Network Time 918 Protocol", draft-ietf-ntp-using-nts-for-ntp-17 (work in 919 progress), February 2019. 921 [IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C., 922 Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla: 923 The Rise and Decline of NTP DDoS Attacks", Internet 924 Measurement Conference , 2014. 926 [MILLS2006] 927 Mills, D., "Computer network time synchronization: the 928 Network Time Protocol", CRC Press , 2006. 930 [NDSS14] Rossow, C., "Amplification Hell: Revisiting Network 931 Protocols for DDoS Abuse", NDSS'14, San Diego, CA. , 2014. 933 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 934 "Attacking the Network Time Protocol", NDSS'16, San Diego, 935 CA. , 2016, . 937 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 938 Specification, Implementation and Analysis", RFC 1305, 939 DOI 10.17487/RFC1305, March 1992, 940 . 942 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 943 Version 4: Autokey Specification", RFC 5906, 944 DOI 10.17487/RFC5906, June 2010, 945 . 947 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 948 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 949 RFC 6151, DOI 10.17487/RFC6151, March 2011, 950 . 952 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 953 "Architectural Considerations of IP Anycast", RFC 7094, 954 DOI 10.17487/RFC7094, January 2014, 955 . 957 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 958 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 959 October 2014, . 961 11.3. URIs 963 [1] https://blog.cloudflare.com/technical-details-behind-a-400gbps- 964 ntp-amplification-ddos-attack/ 966 [2] http://www.bcp38.info 968 [3] http://www.pool.ntp.org/en/use.html 970 [4] http://www.pool.ntp.org/en/vendors.html 972 [5] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 974 [6] https://www.iers.org/IERS/EN/Publications/Bulletins/ 975 bulletins.html 977 [7] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 979 [8] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html 981 [9] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 983 [10] http://www.ntp.org/downloads.html 985 [11] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno 987 [12] https://support.ntp.org/bin/view/Support/ConfiguringNTP 989 Appendix A. Best Practices specific to the Network Time Foundation 990 implementation 992 The Network Time Foundation (NTF) provides a widely used 993 implementation of NTP, known as ntpd [10]. It is an evolution of the 994 first NTP implementations developed by David Mills at the University 995 of Delaware. This appendix contains additional recommendations 996 specific to this implementation that are valid at the time of this 997 writing. 999 A.1. Use enough time sources 1001 In addition to the recommendation given in Section 3.2 the ntpd 1002 implementation provides the 'pool' directive. Starting with ntp- 1003 4.2.6, using this directive in the ntp.conf file will spin up enough 1004 associations to provide robust time service, and will disconnect poor 1005 servers and add in new servers as-needed. The 'minclock' and 1006 'maxclock' options of the 'tos' command may be used to override the 1007 default values of how many servers are discovered through the 'pool' 1008 directive. 1010 A.2. NTP Control and Facility Messages 1012 In addition to NTP Control Messages the ntpd implementation also 1013 offers the Mode 7 commands for monitoring and configuration. 1015 If Mode 7 has been explicitly enabled to be used for more than basic 1016 monitoring it should be limited to authenticated sessions that 1017 provide a 'requestkey'. 1019 As mentioned above, there are two general ways to use Mode 6 and Mode 1020 7 requests. One way is to query ntpd for information, and this mode 1021 can be disabled with: 1023 restrict ... noquery 1025 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 1026 behavior. Modification of ntpd's configuration requires an 1027 authenticated session by default. If no authentication keys have 1028 been specified no modifications can be made. For additional 1029 protection, the ability to perform these modifications can be 1030 controlled with: 1032 restrict ... nomodify 1034 Users can prevent their NTP servers from considering query/ 1035 configuration traffic by default by adding the following to their 1036 ntp.conf file: 1038 restrict default -4 nomodify notrap nopeer noquery 1040 restrict default -6 nomodify notrap nopeer noquery 1042 restrict source nomodify notrap noquery 1044 A.3. Monitoring 1046 The ntpd implementation allows remote monitoring. Access to this 1047 service is generally controlled by the "noquery" directive in NTP's 1048 configuration file (ntp.conf) via a "restrict" statement. The syntax 1049 reads: 1051 restrict address mask address_mask noquery 1053 If a system is using broadcast mode and is running ntp-4.2.8p6 or 1054 later, use the 4th field of the ntp.keys file to specify the IPs of 1055 machines that are allowed to serve time to the group. 1057 A.4. Leap Second File 1059 The use of leap second files requires ntpd 4.2.6 or later. After 1060 fetching the leap seconds file onto the server, add this line to 1061 ntpd.conf to apply and use the file, substituting the proper path: 1063 leapfile "/path/to/leap-file" 1065 There may need to restart ntpd to apply this change. 1067 ntpd servers with a manually configured leap second file will ignore 1068 leap second information broadcast from upstream NTP servers until the 1069 leap second file expires. If no valid leap second file is available 1070 then a leap second notification from an attached reference clock is 1071 always accepted by ntpd. 1073 If no valid leap second file is available, a leap second notification 1074 may be accepted from upstream NTP servers. As of ntp-4.2.6, a 1075 majority of servers must provide the notification before it is 1076 accepted. Before 4.2.6, a leap second notification would be accepted 1077 if a single upstream server of a group of configured servers provided 1078 a leap second notification. This would lead to misbehavior if single 1079 NTP servers sent an invalid leap second warning, e.g. due to a faulty 1080 GPS receiver in one server, but this behavior was once chosen because 1081 in the "early days" there was a greater chance that leap second 1082 information would be available from a very limited number of sources. 1084 A.5. Leap Smearing 1086 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in 1087 response to client requests. Support for leap smearing is not 1088 configured by default and must be added at compile time. In 1089 addition, no leap smearing will occur unless a leap smear interval is 1090 specified in ntpd.conf . For more information, refer to 1091 http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [11]. 1093 A.6. Configuring ntpd 1095 See https://support.ntp.org/bin/view/Support/ConfiguringNTP [12] for 1096 additional information on configuring ntpd. 1098 A.7. Pre-Shared Keys 1100 Each communication partner must add the key information to their key 1101 file in the form: 1103 keyid type key 1105 where "keyid" is a number between 1 and 65534, inclusive, "type" is 1106 an ASCII character which defines the key format, and "key" is the key 1107 itself. 1109 An ntpd client establishes a protected association by appending the 1110 option "key keyid" to the server statement in ntp.conf: 1112 server address key keyid 1114 substituting the server address in the "address" field and the 1115 numerical keyid to use with that server in the "keyid" field. 1117 A key is deemed trusted when its keyid is added to the list of 1118 trusted keys by the "trustedkey" statement in ntp.conf. 1120 trustedkey keyid_1 keyid_2 ... keyid_n 1122 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 1123 column, a comma-separated list of IPs that are allowed to serve time. 1124 Use this feature. Note, however, that an adversarial client that 1125 knows the symmetric broadcast key could still easily spoof its source 1126 IP to an IP that is allowed to serve time. (This is easy to do 1127 because the origin timestamp on broadcast mode packets is not 1128 validated by the client. By contrast, client/server and symmetric 1129 modes do require origin timestamp validation, making it more 1130 difficult to spoof packets [CCR16]). 1132 Authors' Addresses 1134 Denis Reilly (editor) 1135 Orolia USA 1136 1565 Jefferson Road, Suite 460 1137 Rochester, NY 14623 1138 US 1140 Email: denis.reilly@orolia.com 1141 Harlan Stenn 1142 Network Time Foundation 1143 P.O. Box 918 1144 Talent, OR 97540 1145 US 1147 Email: stenn@nwtime.org 1149 Dieter Sibold 1150 Physikalisch-Technische Bundesanstalt 1151 Bundesallee 100 1152 Braunschweig D-38116 1153 Germany 1155 Phone: +49-(0)531-592-8420 1156 Fax: +49-531-592-698420 1157 Email: dieter.sibold@ptb.de