draft-reilly-ntp-bcp-01.txt   draft-reilly-ntp-bcp-02.txt 
Internet Engineering Task Force D. Reilly Internet Engineering Task Force D. Reilly
Internet-Draft Spectracom Corporation Internet-Draft Spectracom Corporation
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: September 10, 2016 Network Time Foundation Expires: December 10, 2016 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
March 9, 2016 June 8, 2016
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-reilly-ntp-bcp-01 draft-reilly-ntp-bcp-02
Abstract Abstract
NTP Version 4 (NTPv4) has been widely used since its publication as NTP Version 4 (NTPv4) has been widely used since its publication as
RFC 5905 [RFC5905]. This documentation is a collection of Best RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community. Practices from across the NTP community.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2016. This Internet-Draft will expire on December 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Keeping NTP up to date . . . . . . . . . . . . . . . . . . . 3 2. Keeping NTP up to date . . . . . . . . . . . . . . . . . . . 3
3. General Network Security Best Practices . . . . . . . . . . . 3 3. General Network Security Best Practices . . . . . . . . . . . 4
3.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 4. NTP Configuration Best Practices . . . . . . . . . . . . . . 4
4.1. Use enough time sources . . . . . . . . . . . . . . . . . 4 4.1. Use enough time sources . . . . . . . . . . . . . . . . . 4
4.2. Use a diversity of Reference Clocks . . . . . . . . . . . 5 4.2. Use a diversity of Reference Clocks . . . . . . . . . . . 5
4.3. Mode 6 and 7 . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Mode 6 and 7 . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7
4.5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . 7 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 7
4.5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . 8 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 8
4.5.3. External Security Means . . . . . . . . . . . . . . . 8 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 9
4.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8 5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 9
4.7. Starting, Cold-Starting, and Re-Starting NTP . . . . . . 9 5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.8. Leap Second Handling . . . . . . . . . . . . . . . . . . 9 5.3. External Security Means . . . . . . . . . . . . . . . . . 10
4.8.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 10
5. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 10 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 10
5.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 10 6.2. Avoiding Reboot Attacks . . . . . . . . . . . . . . . . . 11
5.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 12
5.3. Server configuration . . . . . . . . . . . . . . . . . . 11 6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 13
5.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 11 6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 13
6. NTP Deployment Examples . . . . . . . . . . . . . . . . . . . 11 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 14
6.1. Client-Only configuration . . . . . . . . . . . . . . . . 11 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 14
6.2. Server-Only Configuration . . . . . . . . . . . . . . . . 11 7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. Server configuration . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. NTP Deployment Examples . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Client-Only configuration . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Server-Only Configuration . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
NTP Version 4 (NTPv4) has been widely used since its publication as NTP Version 4 (NTPv4) has been widely used since its publication as
RFC 5905 [RFC5905]. This documentation is a collection of Best RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community. Practices from across the NTP community.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Keeping NTP up to date 2. Keeping NTP up to date
No software (not even NTP) is perfect. Bugs can be present in any The best way to protect your computers and networks against undefined
software. Even if software is thoroughly tested and "all" the bugs behavior and security threats related to time is to keep your NTP
are discovered and fixed, users continuously find new ways to use implementation current.
software that their authors did not conceive of, which can uncover
more bugs. Thousands of individual bugs have been found and fixed in
the NTP Project's reference implementation since the first NTPv4
release in 1997.
There are always new ideas about security on the Internet, and an There are always new ideas about security on the Internet, and an
application which is secure today could be insecure tomorrow once an application which is secure today could be insecure tomorrow once an
unknown bug (or a known behavior) is exploited in the right way. unknown bug (or a known behavior) is exploited in the right way.
Many security mechanisms rely on time, either directly or indirectly, Even our definition of what is secure has evolved over the years, so
as part of their operation. If an attacker can spoof the time, they code which was considered secure when it was written can be
may be able to bypass or neutralize other security elements. For considered insecure after some time.
example, incorrect time can disrupt the ability to reconcile logfile
entries on the affected system with events on other systems.
In general, the best way to protect yourself and your networks Many security mechanisms rely on time as part of their operation. If
against these bugs and security threats is to make sure that you keep an attacker can spoof the time, they may be able to bypass or
your NTP implementation up-to-date. There are multiple versions of neutralize other security elements. For example, incorrect time can
the NTP protocol in use and multiple implementations and versions of disrupt the ability to reconcile logfile entries on the affected
NTP software also in use, on many different platforms. It is system with events on other systems.
Thousands of individual bugs have been found and fixed in the NTP
Project's reference implementation since the first NTPv4 release in
1997. Each version release contains at least a few bug fixes. The
best way to stay in front of these issues is to keep your NTP
implementation current.
There are multiple versions of the NTP protocol in use, and multiple
implementations in use, on many different platforms. It is
recommended that NTP users actively monitor wherever they get their recommended that NTP users actively monitor wherever they get their
software to find out if their versions are vulnerable to any known software to find out if their versions are vulnerable to any known
attacks, and deploy updates containing security fixes as soon as attacks, and deploy updates containing security fixes as soon as
practical. practical.
The reference implementation of NTP Version 4 from Network Time The reference implementation of NTP Version 4 from Network Time
Foundation (NTF) continues to be actively maintained and developed by Foundation (NTF) continues to be actively maintained and developed by
NTF's NTP Project, with help from volunteers and NTF's supporters. NTF's NTP Project, with help from volunteers and NTF's supporters.
The NTP software can be downloaded from ntp.org [1] and also from The NTP software can be downloaded from ntp.org [1] and also from
NTF's github page [2]. NTF's github page [2].
3. General Network Security Best Practices 3. General Network Security Best Practices
NTP deployments are only as secure as the networks they are running
over.
3.1. BCP 38 3.1. BCP 38
Many network attacks rely on modifying the IP source address of a Many network attacks rely on modifying the IP source address of a
packet to point to a different IP address than the computer which packet to point to a different IP address than the computer which
originated it. This modification/abuse vector has been known for originated it. This modification/abuse vector has been known for
quite some time, and BCP 38 [RFC2827] was approved in 2000 to address quite some time, and BCP 38 [RFC2827] was approved in 2000 to address
this. BCP 38 [RFC2827] calls for filtering outgoing and incoming this. BCP 38 [RFC2827] calls for filtering outgoing and incoming
traffic to make sure that the source and destination IP addresses are traffic to make sure that the source and destination IP addresses are
consistent with the expected flow of traffic on each network consistent with the expected flow of traffic on each network
interface. It is recommended that all networks (and ISP's of any interface. It is recommended that all networks (and ISP's of any
size) implement this. If a machine on your network is sending out size) implement this. If a machine on your network is sending out
packets claiming to be from an address that is not on your network, packets claiming to be from an address that is not on your network,
this could be the first indication that you have a machine that has this could be the first indication that you have a machine that has
been cracked, and is being used abusively. If packets are arriving been compromised, and is being used abusively. If packets are
on an external interface with a source address that should only be arriving on an external interface with a source address that should
seen on an internal network, that's a strong indication that an only be seen on an internal network, that's a strong indication that
attacker is trying to inject spoofed packets into your network. More an attacker is trying to inject spoofed packets into your network.
information is available at http://www.bcp38.info . More information is available at http://www.bcp38.info .
4. NTP Configuration Best Practices 4. NTP Configuration Best Practices
NTP can be made more secure by making a few simple changes to the NTP can be made more secure by making a few simple changes to the
ntp.conf file. ntp.conf file.
4.1. Use enough time sources 4.1. Use enough time sources
NTP takes the available sources of time and submits their timing data NTP takes the available sources of time and submits their timing data
to intersection and clustering algorithms, looking for the best idea to intersection and clustering algorithms, looking for the best idea
of the correct time. If there is only 1 source of time, the answer of the correct time. If there is only 1 source of time, the answer
is obvious. It may not be a good source of time, but it's the only is obvious. It may not be a good source of time, but it's the only
one. If there are 2 sources of time and they agree well enough, one. If there are 2 sources of time and they agree well enough,
that's good. But if they don't, then ntpd has no way to know which that's good. But if they don't, then ntpd has no way to know which
source to believe. This gets easier if there are 3 sources of time. source to believe. This gets easier if there are 3 sources of time.
But if one of those 3 sources becomes unreachable or unusable, we're But if one of those 3 sources becomes unreachable or unusable, we're
back to only having 2 time sources. 4 sources of time is another back to only having 2 time sources. 4 sources of time is another
interesting choice, assuming things go well. If one of these sources interesting choice, assuming things go well. If one of these sources
develops a problem there are still 3 others. Seems good. Until the develops a problem there are still 3 others. Seems good. Until the
leap second we had in June of 2015, where several operators leap second we had in June of 2015, where several operators
implemented leap smearing while others did not. See Section 4.8.1 implemented leap smearing while others did not. See Section 4.6.1
for more information. for more information.
Starting with ntp-4.2.6, the 'pool' directive will spin up "enough" Starting with ntp-4.2.6, the 'pool' directive will spin up "enough"
associations to provide robust time service, and will disconnect poor associations to provide robust time service, and will disconnect poor
servers and add in new servers as-needed. servers and add in new servers as-needed.
Monitor your ntpd instances. If your times sources do not generally Monitor your ntpd instances. If your times sources do not generally
agree, find out why and either correct the problems or stop using agree, find out why and either correct the problems or stop using
defective servers. See Section 4.4 for more information. defective servers. See Section 4.4 for more information.
4.2. Use a diversity of Reference Clocks 4.2. Use a diversity of Reference Clocks
If you are using reference clocks, it is recommended that you use If you are using servers with attached hardware reference clocks, it
several different types. Having a diversity of sources means that is recommended that you use several different types of reference
any one issue is less likely to cause a service interruption. clocks. Having a diversity of sources means that any one issue is
less likely to cause a service interruption.
Are all your clocks from the same vendor? Are they using the same Are all your clocks from the same vendor? Are they using the same
base chipset, regardless of whether or not the finished products are base chipset, regardless of whether or not the finished products are
from different vendors? Are they all running the same version of from different vendors? Are they all running the same version of
firmware? A systemic problem with time from any satellite navigation firmware? Chipset and firmware bugs can happen, but is often more
service is possible and has happened. Sunspot activity can render difficult to diagnose than a standard software bug.
satellite or radio-based time source unusable. A chipset problem can
happen. There may be a bug in the vendor's firmware. GA systemic problem with time from any satellite navigation service
is possible and has happened. Sunspot activity can render satellite
or radio-based time source unusable.
4.3. Mode 6 and 7 4.3. Mode 6 and 7
NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit
monitoring and optional authenticated control of ntpd and its monitoring and optional authenticated control of ntpd and its
configuration. Used properly, these facilities provide vital configuration. Used properly, these facilities provide vital
debugging and performance information and control. Used improperly, debugging and performance information and control. Used improperly,
these facilities can be an abuse vector. these facilities can be an abuse vector.
Mode 7 queries have been disabled by default since 4.2.7p230, Mode 7 queries have been disabled by default since 4.2.7p230,
skipping to change at page 6, line 48 skipping to change at page 7, line 11
If your syslog shows messages that indicate you are receiving If your syslog shows messages that indicate you are receiving
timestamps that are earlier than the current system time, then either timestamps that are earlier than the current system time, then either
your system clock is unusually fast or somebody is trying to launch a your system clock is unusually fast or somebody is trying to launch a
replay attack against your server. replay attack against your server.
If you are using broadcast mode and have ntp-4.2.8p6 or later, use If you are using broadcast mode and have ntp-4.2.8p6 or later, use
the 4th field of the ntp.keys file to identify the IPs of machines the 4th field of the ntp.keys file to identify the IPs of machines
that are allowed to serve time to the group. that are allowed to serve time to the group.
4.5. Security 4.5. Using Pool Servers
It only takes a small amount of bandwidth and system resources to
synchronize one NTP client, but NTP servers that can service tens of
thousands of clients take more resources to run. Users who want to
synchronize their computers should only synchronize to servers that
they have permission to use.
The NTP pool project is a collection of volunteers who have donated
their computing and bandwidth resources to provide time on the
Internet for free. The time is generally of good quality, but comes
with no guarantee whatsoever. If you are interested in using the
pool, please review their instructions at http://www.pool.ntp.org/en/
use.html .
If you want to synchronize many computers using the pool, consider
running your own NTP servers, synchronizing them to the pool, and
synchronizing your clients to your in-house NTP servers. This
reduces the load on the pool.
Set up or sponsor one or more pool servers.
4.6. Leap Second Handling
The UTC timescale is kept in sync with the rotation of the earth
through the use of leap seconds. NTP time is based on the UTC
timescale, and the protocol has the capability to broadcast leap
second information. Some GNSS systems (like GPS) broadcast leap
second information, so if you have a Stratum-1 server synced to GNSS
(or you are synced to a lower stratum server that is ultimately
synced to GNSS), you will get advance notification of impending leap
seconds automatically.
While earlier versions of NTP contained some ambiguity regarding when
leap seconds could occur, RFC 5905 is clear that leap seconds are
processed at the end of a month. If an upstream server is
broadcasting that a leap second is pending, RFC5905-compliant servers
should apply it at the end of the last minute of the last day of the
month.
The IETF maintains a leap second list
(https://www.ietf.org/timezones/data/leap-seconds.list) for NTP users
who are not receiving leap second information through an automatic
source. The use of leap second files requires ntpd 4.2.6 or later.
After fetching the leap seconds file onto the server, add this line
to ntpd.conf to apply the file:
leapfile "/path/to your/leap-file"
You will need to restart to apply the changes.
Files are also available from other sources:
NIST: ftp://time.nist.gov/pub/leap-seconds.list
US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap-
seconds.list
IERS (announces leap seconds):
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
Servers with a manually configured leap second file will ignore leap
second information broadcast from upstream NTP servers until the leap
second file expires.
4.6.1. Leap Smearing
Some NTP installations may instead make use of a technique called
"Leap Smearing". With this method, instead of introducing an extra
second (or eliminating a second), NTP time will be slewed in small
increments over a comparably large window of time around the leap
second event. The amount of the slew should be small enough that
clients will follow the smeared time without objecting. During the
adjustment window, the NTP server's time may be offset from UTC by as
much as .5 seconds. This is done to enable software that doesn't
deal with minutes that have more or less than 60 seconds to function
correctly, at the expense of fidelity to UTC during the smear window.
Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47.
Support is not configured by default and must be added at compile
time. In addition, no leap smearing will occur unless a leap smear
interval is specified in ntpd.conf . For more information, refer to
http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno .
Leap Smearing must not be used for public-facing NTP servers, as they
will disagree with non-smearing servers (as well as UTC) during the
leap smear interval. However, be aware that some public-facing
servers may be configured this way anyway in spite of this guidance.
System Administrators are advised to be aware of impending leap
seconds and how the servers (inside and outside their organization)
they are using deal with them. Individual clients must never be
configured to use a mixture of smeared and non-smeared servers.
5. NTP Security Mechanisms
In the standard configuration NTP packets are exchanged unprotected In the standard configuration NTP packets are exchanged unprotected
between client and server. An adversary that is able to become a between client and server. An adversary that is able to become a
Man-In-The-Middle is therefore able to drop, replay or modify the Man-In-The-Middle is therefore able to drop, replay or modify the
content of the NTP packet, which leads to degradation of the time content of the NTP packet, which leads to degradation of the time
synchronization or the transmission of false time information. A synchronization or the transmission of false time information. A
profound threat analysis for time synchronization protocols are given profound threat analysis for time synchronization protocols are given
in RFC 7384 [RFC7384]. NTP provides two security measures to protect in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms
authenticity and integrity of the NTP packets. Both measures protect to protect authenticity and integrity of the NTP packets. Both
the NTP packet by means of a Message Authentication Code (MAC). measures protect the NTP packet by means of a Message Authentication
Neither of them encrypts the NTP's payload, because it is not Code (MAC). Neither of them encrypts the NTP's payload, because it
considered to be confidential. is not considered to be confidential.
4.5.1. Pre-Shared Key Approach 5.1. Pre-Shared Key Approach
This approach applies a symmetric key for the calculation of the MAC, This approach applies a symmetric key for the calculation of the MAC,
which protects authenticity and integrity of the exchanged packets which protects authenticity and integrity of the exchanged packets
for a association. NTP does not provide a mechanism for the exchange for a association. NTP does not provide a mechanism for the exchange
of the keys between the associated nodes. Therefore, for each of the keys between the associated nodes. Therefore, for each
association, keys have to be exchanged securely by external means. association, keys have to be exchanged securely by external means.
It is recommended that each association is protected by its own It is recommended that each association is protected by its own
unique key. NTP does not provide a mechanism to automatically unique key. NTP does not provide a mechanism to automatically
refresh the applied keys. It is therefore recommended that the refresh the applied keys. It is therefore recommended that the
participants periodically agree on a fresh key. The calculation of participants periodically agree on a fresh key. The calculation of
skipping to change at page 8, line 7 skipping to change at page 10, line 18
server address key keyid server address key keyid
Note that the NTP process has to trust the applied key. An NTP Note that the NTP process has to trust the applied key. An NTP
process explicitly has to add each key it want to trust to a list of process explicitly has to add each key it want to trust to a list of
trusted keys by the "trustedkey" statement in the NTP configuration trusted keys by the "trustedkey" statement in the NTP configuration
file. file.
trustedkey keyid_1 keyid_2 ... keyid_n trustedkey keyid_1 keyid_2 ... keyid_n
4.5.2. Autokey 5.2. Autokey
Autokey was designed in 2003 to provide a means for clients to Autokey was designed in 2003 to provide a means for clients to
authenticate servers. By 2011, security researchers had identified authenticate servers. By 2011, security researchers had identified
computational areas in the Autokey protocol that, while secure at the computational areas in the Autokey protocol that, while secure at the
time of its original design, were no longer secure. Work was begun time of its original design, were no longer secure. Work was begun
on an enhanced replacement for Autokey, which was called Network Time on an enhanced replacement for Autokey, which was called Network Time
Security (NTS) [3]. NTS was published in the summer of 2013. As of Security (NTS) [5]. NTS was published in the summer of 2013. As of
February 2016, this effort was at draft #13, and about to begin February 2016, this effort was at draft #13, and about to begin
'final call'. The first unicast implementation of NTS was started in 'final call'. The first unicast implementation of NTS was started in
the summer of 2015 and is expected to be released in the summer of the summer of 2015 and is expected to be released in the summer of
2016. 2016.
We recommend that Autokey NOT BE USED. Know that as of the fall of We recommend that Autokey NOT BE USED. Know that as of the fall of
2011, a common(?) laptop computer could crack the security cookie 2011, a common(?) laptop computer could crack the security cookie
used in the Autokey protocol in 30 minutes' time. If you must use used in the Autokey protocol in 30 minutes' time. If you must use
Autokey, know that your session keys should be set to expire in under Autokey, know that your session keys should be set to expire in under
30 minutes' time. If you have reason to believe your autokey- 30 minutes' time. If you have reason to believe your autokey-
protected associations will be attacked, you should read protected associations will be attacked, you should read
https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html and https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html and
decide what resources your attackers might be using, and adjust the decide what resources your attackers might be using, and adjust the
session key expiration time accordingly. session key expiration time accordingly.
4.5.3. External Security Means 5.3. External Security Means
TBD TBD
4.6. Using Pool Servers 6. NTP Security Best Practices
It only takes a small amount of bandwidth and system resources to 6.1. Minimizing Information Leakage
synchronize one NTP client, but NTP servers that can service tens of
thousands of clients take more resources to run. Users who want to
synchronize their computers should only synchronize to servers that
they have permission to use.
The NTP pool project is a collection of volunteers who have donated The base NTP packet leaks important information (including reference
their computing and bandwidth resources to provide time on the ID and reference time) that can be used in attacks [NDSS16],
Internet for free. The time is generally of good quality, but comes [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this
with no guarantee whatsoever. If you are interested in using the information by sending mode 3 queries to a target system and
pool, please review their instructions at http://www.pool.ntp.org/en/ inspecting the fields in the mode 4 response packet. NTP control
use.html . queries also leak important information (including reference ID,
expected origin timestamp, etc) that can be used in attacks
[CVE-2015-8139]. A remote attacker can learn this information by
sending control queries to a target system and inspecting the
response.
If you want to synchronize many computers using the pool, consider As such, access control should be used to limit the exposure of this
running your own NTP servers, synchronizing them to the pool, and information to third parties.
synchronizing your clients to your in-house NTP servers. This
reduces the load on the pool.
Set up or sponsor one or more pool servers. All hosts should only respond to NTP control queries from authorized
parties. One way to do this is to only allow control queries from
authorized IP addresses.
4.7. Starting, Cold-Starting, and Re-Starting NTP A host that is not supposed to act as an NTP server that provides
timing information to other hosts should additionally drop incoming
mode 3 timing queries.
Only use -g on cold-start. Other things TBD. An "end host" is host that is using NTP solely for the purpose of
setting its own local clock. Such a host is not expected to provide
time to other hosts, and relies exclusively on NTP's basic mode to
take time from a set of servers. (That is, the host sends mode 3
queries to its servers and receives mode 4 responses from these
servers containing timing information.) To minimize information
leakage, end hosts should drop all incoming NTP packets except mode 4
response packets that come from its configured servers.
Editor's Note: I think I'd like to expand this a bit to cover how to 6.2. Avoiding Reboot Attacks
deal with NTP stopping, when to restart it, and under what
circumstances to not restart it!
4.8. Leap Second Handling [RFC5905] says NTP clients should not accept time shifts greater than
the panic threshold. Specifically, RFC5905 says "PANIC means the
offset is greater than the panic threshold PANICT (1000 s) and SHOULD
cause the program to exit with a diagnostic message to the system
log.
The UTC timescale is kept in sync with the rotation of the earth However, this behavior can be exploited by attackers [NDSS16], when
through the use of leap seconds. NTP time is based on the UTC the following two conditions hold:
timescale, and the protocol has the capability to broadcast leap
second information. Some GNSS systems (like GPS) broadcast leap
second information, so if you have a Stratum-1 server synced to GNSS
(or you are synced to a lower stratum server that is ultimately
synced to GNSS), you will get advance notification of impending leap
seconds automatically.
The International Earth Rotation and Reference Systems Service (IERS) 1. The operating system automatically restarts the NTP daemon when
is responsible to announce the introduction of a leap second. It it quits. (Modern *NIX operating systems are replacing
maintains a leap second list at traditional init systems with process supervisors, such as
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list for NTP systemd, which can be configured to automatically restart any
users who are not receiving leap second information through an daemons that quit. This behavior is the default in CoreOS and
automatic source. After fetching the leap seconds file onto the Arch Linux. It is likely to become the default behavior in other
server, add this line to ntpd.conf to apply the file: systems as they migrate legacy init scripts to systemd.)
leapfile "/path/to your/leap-file" 2. The NTP daemon ignores the panic threshold when it first reboots.
(This is sometimes called the -g option.)
You will need to restart to apply the changes. In such cases, the attacker can send the target an offset that
exceeds the panic threshold, causing the client to quit. Then, when
the client reboots, it ignores the panic threshold and accepts the
attacker's large offset.
4.8.1. Leap Smearing Hosts running with the above two conditions should be aware that the
panic threshold does not protect them from attacks. A natural
solution is not to run hosts with these conditions.
Some NTP installations may instead make use of a technique called As an alternative, the following steps could be taken to mitigate he
"Leap Smearing". With this method, instead of introducing an extra risk of attack.
second (or eliminating a second), NTP time will be slewed in small
increments over a comparably large window of time around the leap
second event. The amount of the slew should be small enough that
clients will follow the smeared time without objecting. During the
adjustment window, the NTP server's time may be offset from UTC by as
much as .5 seconds. This is done to enable software that doesn't
deal with minutes that have more or less than 60 seconds to function
correctly, at the expense of fidelity to UTC during the smear window.
Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47. o Monitor NTP system log to detect when the NTP daemon has quit due
Support is not configured by default and must be added at compile to a panic event, as this could be a sign of an attack.
time. In addition, no leap smearing will occur unless a leap smear
interval is specified in ntpd.conf . For more information, refer to
http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno .
Leap Smearing is not recommended for public-facing NTP servers, as o Request manual intervention when a timestep larger than the panic
they will disagree with non-smearing servers during the leap smear threshold is detected.
interval. However, some public-facing servers may be configured this
way anyway. Users are advised to be aware of impending leap seconds
and how the servers (inside and outside their organization) they are
using deal with them.
5. NTP in Embedded Devices o Prevent the NTP daemon from taking time steps that set the clock
to a time earlier than the compile date of the NTP daemon.
o Modify the NTP daemon so that it "hangs" (ie does not quit, but
just waits for a better timing samples but does not modify the
local clock) when it receives a large offset.
6.3. Detection of Attacks Through Monitoring
Users should monitor their NTP instances to detect attacks. Many
known attacks on NTP have particular signatures. Common attack
signatures include:
1. "Bogus packets" - A packet whose origin timestamp does not match
the value that expected by the client.
2. "Zero origin packet" - A packet with a origin timestamp set to
zero [CVE-2015-8138].
3. A packet with an invalid cryptographic MAC [CCR16].
The observation of many such packets could indicate that the client
is under attack.
Also, Kiss-o'-Death (KoD) packets can be used in denial of service
attacks. Thus, the observation of even just one KoD packet with a
high poll value (e.g. poll>10) could be sign that the client is under
attack.
6.4. Broadcast Mode Should Only Be Used On Trusted Networks
Per [RFC5905], NTP's broadcast mode is authenticated using symmetric
key cryptography. The broadcast server and all of its broadcast
clients share a symmetric cryptographic key, and the broadcast server
uses this key to append a message authentication code (MAC) to the
broadcast packets it sends.
Importantly, all broadcast clients that listen to this server must
know the cryptographic key. This mean that any client can use this
key to send valid broadcast messages that look like they come from
the broadcast server. Thus, a rogue broadcast client can use its
knowledge of this key to attack the other broadcast clients.
For this reason, an NTP broadcast server and all its client must
trust each other. Broadcast mode should only be run from within a
trusted network.
6.5. Symmetric Mode Should Only Be Used With Trusted Peers
In symmetric mode, two peers Alice and Bob can both push and pull
synchronization to and from each other using either ephemeral
symmetric passive (mode 2) or persistent symmetric active (NTP mode
1) packets. The persistent association is preconfigured and
initiated at the active peer but not preconfigured at the passive
peer (Bob). Upon arrival of a mode 1 NTP packet from Alice, Bob
mobilizes a new ephemeral association if he does not have one
already. This is a security risk for Bob because an arbitrary
attacker can attempt to change Bob's time by asking Bob to become its
symmetric passive peer.
For this reason, a host (Bob) should only allow symmetric passive
associations to be established with trusted peers. Specifically, Bob
should require each of its symmetric passive association to be
cryptographically authenticated. Each symmetric passive association
should be authenticated under a different cryptographic key.
The use of a different cryptographic key per peer prevents Sybil
attacks. If a target host uses the same key is to authenticate all
symmetric peers, then a malicious peer could attempt to set up
multiple symmetric associations with the target host in order to bias
the result of the target's Byzantine fault tolerant selection
algorithms.
7. NTP in Embedded Devices
Readers of this BCP already understand how important accurate time is Readers of this BCP already understand how important accurate time is
for network computing. And as computing becomes more ubiquitous, for network computing. And as computing becomes more ubiquitous,
there will be many small "Internet of Things" devices that require there will be many small "Internet of Things" devices that require
accurate time. These embedded devices may not have a traditional accurate time. These embedded devices may not have a traditional
user interface, but if they connect to the Internet they will be user interface, but if they connect to the Internet they will be
subject to the same security threats as traditional deployments. subject to the same security threats as traditional deployments.
5.1. Updating Embedded Devices 7.1. Updating Embedded Devices
Vendors of embedded devices have a special responsibility to pay Vendors of embedded devices have a special responsibility to pay
attention to the current state of NTP bugs and security issues, attention to the current state of NTP bugs and security issues,
because their customers usually don't have the ability to update because their customers usually don't have the ability to update
their NTP implementation on their own. Those devices may have a their NTP implementation on their own. Those devices may have a
single firmware upgrade, provided by the manufacturer, that updates single firmware upgrade, provided by the manufacturer, that updates
all capabilities at once. This means that the vendor assumes the all capabilities at once. This means that the vendor assumes the
responsibility of making sure their devices have the latest NTP responsibility of making sure their devices have the latest NTP
updates applied. updates applied.
This should also include the ability to update the NTP server This should also include the ability to update the NTP server
address. address.
(Note: do we find specific historical instances of devices behaving (Note: do we find specific historical instances of devices behaving
badly and cite them here?) badly and cite them here?)
5.2. KISS Packets 7.2. KISS Packets
The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a
server can tell a misbehaving client to "back off" its query rate. server can tell a misbehaving client to "back off" its query rate.
It is important for all NTP devices to respect these packets and back It is important for all NTP devices to respect these packets and back
off when asked to do so by a server. It is even more important for off when asked to do so by a server. It is even more important for
an embedded device, which may not have exposed a control interface an embedded device, which may not have exposed a control interface
for NTP. for NTP.
The KoD mechanism relies on clients behaving properly in order to be The KoD mechanism relies on clients behaving properly in order to be
effective. Some clients ignore the KoD packet entirely, and other effective. Some clients ignore the KoD packet entirely, and other
poorly-implemented clients might unintentionally increase their poll poorly-implemented clients might unintentionally increase their poll
rate and simulate a denial of service attack. Server administrators rate and simulate a denial of service attack. Server administrators
should be prepared for this and take measures outside of the NTP should be prepared for this and take measures outside of the NTP
protocol to drop packets from misbehaving clients. protocol to drop packets from misbehaving clients.
5.3. Server configuration 7.3. Server configuration
Vendors of embedded devices that need time synchronization should Vendors of embedded devices that need time synchronization should
also carefully consider where they get their time from. There are also carefully consider where they get their time from. There are
several public-facing NTP servers available, but they may not be several public-facing NTP servers available, but they may not be
prepared to service requests from thousands of new devices on the prepared to service requests from thousands of new devices on the
Internet. Internet.
Vendors are encouraged to invest resources into providing their own Vendors are encouraged to invest resources into providing their own
time servers for their devices. time servers for their devices.
5.3.1. Get a vendor subdomain for pool.ntp.org 7.3.1. Get a vendor subdomain for pool.ntp.org
The NTP Pool Project offers a program where vendors can obtain their The NTP Pool Project offers a program where vendors can obtain their
own subdomain that is part of the NTP Pool. This offers vendors the own subdomain that is part of the NTP Pool. This offers vendors the
ability to safely make use of the time distributed by the Pool for ability to safely make use of the time distributed by the Pool for
their devices. Vendors are encouraged to support the pool if they their devices. Vendors are encouraged to support the pool if they
participate. For more information, visit http://www.pool.ntp.org/en/ participate. For more information, visit http://www.pool.ntp.org/en/
vendors.html . vendors.html .
6. NTP Deployment Examples 8. NTP Deployment Examples
A few examples of interesting NTP Deployments A few examples of interesting NTP Deployments
6.1. Client-Only configuration 8.1. Client-Only configuration
TBD TBD
6.2. Server-Only Configuration 8.2. Server-Only Configuration
TBD TBD
6.3. Anycast 8.3. Anycast
Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094
[RFC7094]). With anycast, a single IP address is assigned to [RFC7094]). With anycast, a single IP address is assigned to
multiple interfaces, and routers direct packets to the closest active multiple interfaces, and routers direct packets to the closest active
interface. interface.
Anycast is often used for Internet services at known IP addresses, Anycast is often used for Internet services at known IP addresses,
such as DNS. Anycast can also be used in large organizations to such as DNS. Anycast can also be used in large organizations to
simplify configuration of a large number of NTP clients. Each client simplify configuration of a large number of NTP clients. Each client
can be configured with the same NTP server IP address, and a pool of can be configured with the same NTP server IP address, and a pool of
skipping to change at page 12, line 40 skipping to change at page 16, line 30
interfaces at several sites. Each site may have several Stratum 2 interfaces at several sites. Each site may have several Stratum 2
servers with a unicast interface and an anycast interface (with a servers with a unicast interface and an anycast interface (with a
shared IP address per location). The unicast interfaces can be used shared IP address per location). The unicast interfaces can be used
to obtain time from the Stratum 1 servers globally (and perhaps peer to obtain time from the Stratum 1 servers globally (and perhaps peer
with the other Stratum 2 servers at their site). Clients at each with the other Stratum 2 servers at their site). Clients at each
site can be configured to use the shared anycast address for their site can be configured to use the shared anycast address for their
site, simplifying their configuration. Keeping the anycast routing site, simplifying their configuration. Keeping the anycast routing
restricted on a per-site basis will minimize the disruption at the restricted on a per-site basis will minimize the disruption at the
client if its closest anycast server changes. client if its closest anycast server changes.
7. Acknowledgements 9. Acknowledgements
The author wishes to acknowledge the contributions of Sue Graves, The authors wish to acknowledge the contributions of Sue Graves,
Samuel Weiler, Lisa Perdue, and Karen O'Donoghue. Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, and
Sharon Goldberg.
8. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 11. Security Considerations
TBD TBD
10. References 12. References
10.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
skipping to change at page 13, line 41 skipping to change at page 17, line 28
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094, "Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014, DOI 10.17487/RFC7094, January 2014,
<http://www.rfc-editor.org/info/rfc7094>. <http://www.rfc-editor.org/info/rfc7094>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
10.2. URIs 12.2. Informative References
[CCR16] Malhotra, and Goldberg, "Attacking NTP's Authenticated
Broadcast Mode", 2016.
[CVE-2015-8138]
Van Gundy, and Gardner, "NETWORK TIME PROTOCOL ORIGIN
TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016,
<http://www.talosintel.com/reports/TALOS-2016-0077>.
[CVE-2015-8139]
Van Gundy, , "NETWORK TIME PROTOCOL NTPQ AND NTPDC ORIGIN
TIMESTAMP DISCLOSURE VULNERABILITY", 2016,
<http://www.talosintel.com/reports/TALOS-2016-0078>.
[CVE-2016-1548]
Gardner, and Lichvar, "Xleave Pivot: NTP Basic Mode to
Interleaved", 2016, <http://blog.talosintel.com/2016/04/
vulnerability-spotlight-further-ntpd_27.html>.
[NDSS16] Malhotra, , Cohen, , Brakke, , and Goldberg, "Attacking
the Network Time Protocol", 2016,
<https://eprint.iacr.org/2015/1020.pdf>.
12.3. URIs
[1] http://www.ntp.org/downloads.html [1] http://www.ntp.org/downloads.html
[2] https://github.com/ntp-project/ntp [2] https://github.com/ntp-project/ntp
[3] https://tools.ietf.org/html/draft-ietf-ntp-network-time- [5] https://tools.ietf.org/html/draft-ietf-ntp-network-time-
security-00 security-00
Authors' Addresses Authors' Addresses
Denis Reilly Denis Reilly
Spectracom Corporation Spectracom Corporation
1565 Jefferson Road, Suite 460 1565 Jefferson Road, Suite 460
Rochester, NY 14623 Rochester, NY 14623
US US
 End of changes. 56 change blocks. 
153 lines changed or deleted 351 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/