rfc9523xml2.original.xml   rfc9523.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5905.xml">
<!ENTITY RFC7384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7384.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7942.xml">
<!ENTITY RFC8915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8915.xml">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc7749.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-ntp-chronos-25" ipr="trust200902">
<front>
<title abbrev="NTP Extention with Khronos">A Secure Selection and Filtering M
echanism for the Network Time Protocol with Khronos</title>
<author fullname="Neta Rozen-Schiff" initials="N."
surname="Rozen-Schiff">
<organization>Hebrew University of Jerusalem</organization>
<address>
<postal>
<street></street>
<city>Jerusalem</city>
<region></region>
<code></code>
<country>Israel</country>
</postal>
<phone>+972 2 549 4599</phone>
<email>neta.r.schiff@gmail.com</email>
</address>
</author>
<author fullname="Danny Dolev" initials="D."
surname="Dolev">
<organization>Hebrew University of Jerusalem</organization>
<address>
<postal>
<street></street>
<city>Jerusalem</city>
<region></region>
<code></code>
<country>Israel</country>
</postal>
<phone>+972 2 549 4588</phone>
<email>danny.dolev@mail.huji.ac.il</email>
</address>
</author>
<author fullname="Tal Mizrahi" initials="T."
surname="Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Israel</country>
</postal>
<email>tal.mizrahi.phd@gmail.com</email>
</address>
</author>
<author fullname="Michael Schapira" initials="M."
surname="Schapira">
<organization>Hebrew University of Jerusalem</organization>
<address>
<postal>
<street></street>
<city>Jerusalem</city>
<region></region>
<code></code>
<country>Israel</country>
</postal>
<phone>+972 2 549 4570</phone>
<email>schapiram@huji.ac.il</email>
</address>
</author>
<date year="2023" />
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>NTP, NTPv4</keyword>
<abstract>
<t>The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is
the mechanism used by NTP clients to synchronize with NTP servers across the Int
ernet. This document describes a companion application to the NTPv4 client, name
d Khronos, which is used as a "watchdog" alongside NTPv4, and provides improved
security against time shifting attacks. Khronos involves changes to the NTP clie
nt's system process only. Since it does not affect the wire protocol, the Khrono
s mechanism is applicable to current and future time protocols.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>NTPv4, as defined in RFC 5905 <xref
target="RFC5905"/>, is vulnerable to time shifting attacks, in which the attacke
r changes (shifts) the clock of a network device. Time shifting attacks on NTP c
lients can be based on interfering with the communication between the NTP client
s and servers or compromising the servers themselves. Time shifting attacks on N
TP are possible even if NTP communication is encrypted and authenticated. A weak
er machine-in-the-middle (MitM) attacker can shift time simply by dropping or de
laying packets, whereas a powerful attacker, who has full control over an NTP se
rver, can do so by explicitly determining the NTP response content. This documen
t introduces a time shifting mitigation mechanism called Khronos.
Khronos can be integrated as a background monitoring application ("watch
dog") that guard against time shifting attacks in any NTP client. An NTP client
that runs Khronos is interoperable with <xref target="RFC5905"/>-compatible NTPv
4 servers. The Khronos mechanism does not affect the wire mechanism and is there
fore applicable to any current or future time protocol.</t>
<t>Khronos is a mechanism that runs in the background, continuously monitor
ing client clock (which is updated by NTPv4) and calculating an estimated offset
which we refer by "Khronos time offset". When the offset exceeds a predefined t
hreshold (specified in <xref
target="attackDetection"/>), this is interpreted as the client experiencing
a time shifting attack. In this case, Khronos updates the client's clock.</t>
<t>When the client is not under attack, Khronos is passive, allowing NTPv4 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
to control the client's clock and providing the ordinary high precision and accu info" consensus="true" docName="draft-ietf-ntp-chronos-25" number="9523" ipr="tr
racy of NTPv4. When under attack, Khronos takes control over the client's clock, ust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4"
mitigating the time shift, while guaranteeing relatively high accuracy with res symRefs="true" sortRefs="true" version="3">
pect to UTC and precision, as discussed in <xref target="Precision_Security"/>.<
/t>
<t>By leveraging techniques from distributed computing theory for time-sync
hronization, Khronos achieves accurate time even in the presence of powerful att
ackers who are in direct control of a large number of NTP servers. Khronos will
prevent shifting the clock when the ratio of compromised time samples is below 2
/3. In each polling interval, Khronos client randomly selects and samples a few
NTP servers out of a local pool of hundreds of servers. Khronos is carefully eng
ineered to minimize the load on NTP servers and the communication overhead.
In contrast, NTPv4, employs an algorithm which typically relies on a sma
ll subset of the NTP server pool (e.g., 4 servers) for time synchronization, and
is much more vulnerable to time shifting attacks. Configuring NTPv4 to use seve
ral hundreds of servers will increase its security, but will incur very high net
work and computational overhead compared to Khronos and will be bounded by compr
omised ratio of half of the time samples.</t>
<t>A Khronos client iteratively "crowdsources" time queries across NTP serv <!-- xml2rfc v2v3 conversion 3.18.0 -->
ers and applies a provably secure algorithm for eliminating "suspicious" respons <front>
es and for averaging over the remaining responses. In each Khronos poll interval <title abbrev="NTP Extention with Khronos">A Secure Selection and Filtering
, the Khronos client selects, uniformly at random, a small subset (e.g., 10-15 s Mechanism for the Network Time Protocol with Khronos</title>
ervers) of a large server pool (containing hundreds of servers). <seriesInfo name="RFC" value="9523"/>
While Khronos queries around 3 times more servers per polling interval t <author fullname="Neta Rozen-Schiff" initials="N." surname="Rozen-Schiff">
han NTP, Khronos's polling interval can be longer (e.g., 10 times longer) than N <organization>Hebrew University of Jerusalem</organization>
TPv4, thereby, minimizing the load on NTP servers and the communication overhead <address>
. <postal>
<city>Jerusalem</city>
<country>Israel</country>
</postal>
<phone>+972 2 549 4599</phone>
<email>neta.r.schiff@gmail.com</email>
</address>
</author>
<author fullname="Danny Dolev" initials="D." surname="Dolev">
<organization>Hebrew University of Jerusalem</organization>
<address>
<postal>
<city>Jerusalem</city>
<country>Israel</country>
</postal>
<phone>+972 2 549 4588</phone>
<email>danny.dolev@mail.huji.ac.il</email>
</address>
</author>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
<address>
<postal>
<country>Israel</country>
</postal>
<email>tal.mizrahi.phd@gmail.com</email>
</address>
</author>
<author fullname="Michael Schapira" initials="M." surname="Schapira">
<organization>Hebrew University of Jerusalem</organization>
<address>
<postal>
<city>Jerusalem</city>
<country>Israel</country>
</postal>
<phone>+972 2 549 4570</phone>
<email>schapiram@huji.ac.il</email>
</address>
</author>
<date year="2024" month="February"/>
<area>int</area>
<workgroup>ntp</workgroup>
<keyword>NTP</keyword>
<keyword>NTPv4</keyword>
<abstract>
<t>The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is
the mechanism used by NTP clients to synchronize with NTP servers across the In
ternet. This document describes a companion application to the NTPv4 client, nam
ed "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides imp
roved security against time-shifting attacks. Khronos involves changes to the NT
P client's system process only. Since it does not affect the wire protocol, the
Khronos mechanism is applicable to current and future time protocols.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>NTPv4, as defined in <xref target="RFC5905" format="default"/>, is vuln
erable to time-shifting attacks in which the attacker changes (shifts) the clock
of a network device. Time-shifting attacks on NTP clients can be based on inter
fering with the communication between the NTP clients and servers or compromisin
g the servers themselves. Time-shifting attacks on NTP are possible even if NTP
communication is encrypted and authenticated. A weaker machine-in-the-middle (MI
TM) attacker can shift time simply by dropping or delaying packets, whereas a po
werful attacker that has full control over an NTP server can do so by explicitly
determining the NTP response content. This document introduces a time-shifting
mitigation mechanism called "Khronos".
Khronos can be integrated as a background-monitoring application (watchd
og) that guards against time-shifting attacks in any NTP client. An NTP client t
hat runs Khronos is interoperable with NTPv4 servers that are compatible with <x
ref target="RFC5905" format="default"/>. The Khronos mechanism does not affect t
he wire mechanism; therefore, it is applicable to any current or future time pro
tocol.</t>
<t>Khronos is a mechanism that runs in the background, continuously monito
ring the client clock (which is updated by NTPv4) and calculating an estimated o
ffset (referred to as the "Khronos time offset"). When the offset exceeds a pred
efined threshold (specified in <xref target="attackDetection" format="default"/>
), this is interpreted as the client experiencing a time-shifting attack. In thi
s case, Khronos updates the client's clock.</t>
<t>When the client is not under attack, Khronos is passive. This allows N
TPv4 to control the client's clock and provides the ordinary high precision and
accuracy of NTPv4. When under attack, Khronos takes control of the client's clo
ck, mitigating the time shift while guaranteeing relatively high accuracy with r
espect to UTC and precision, as discussed in <xref target="Precision_Security" f
ormat="default"/>.</t>
<t>By leveraging techniques from distributed computing theory for time syn
chronization, Khronos achieves accurate time even in the presence of powerful at
tackers who are in direct control of a large number of NTP servers. Khronos will
prevent shifting the clock when the ratio of compromised time samples is below
2/3. In each polling interval, a Khronos client randomly selects and samples a f
ew NTP servers out of a local pool of hundreds of servers. Khronos is carefully
engineered to minimize the load on NTP servers and the communication overhead.
In contrast, NTPv4 employs an algorithm that typically relies on a small
subset of the NTP server pool (e.g., four servers) for time synchronization and
is much more vulnerable to time-shifting attacks. Configuring NTPv4 to use seve
ral hundreds of servers will increase its security, but will incur very high net
work and computational overhead compared to Khronos and will be bounded by a com
promised ratio of half of the time samples.</t>
<t>A Khronos client iteratively "crowdsources" time queries across NTP ser
vers and applies a provably secure algorithm for eliminating "suspicious" respon
ses and for averaging over the remaining responses. In each Khronos poll interva
l, the Khronos client selects, uniformly at random, a small subset (e.g., 10-15
servers) of a large server pool (containing hundreds of servers).
While Khronos queries around three times more servers per polling interv
al than NTP, Khronos's polling interval can be longer (e.g., 10 times longer) th
an NTPv4, thereby minimizing the load on NTP servers and the communication overh
ead.
Moreover, Khronos's random server selection may even help to distribute queries across the whole pool.</t> Moreover, Khronos's random server selection may even help to distribute queries across the whole pool.</t>
<t> Khronos's security was evaluated both theoretically and experimentally with a prototype implementation. According to this security analysis, if a loca l Khronos pool consists of, for example, 500 servers, one-seventh of whom are co ntrolled by an attacker and Khronos queries 15 servers in each Khronos poll inte rval (around 10 times the NTPv4 poll interval), then over 20 years of effort are required (in expectation) to successfully shift time at a Khronos client by ove r 100 ms from UTC. The full exposition of the formal analysis of this guarantee is available at <xref target="Khronos" format="default"/>. </t>
<t> Khronos's security was evaluated both theoretically and experimentally <t>Khronos maintains a time offset value (the Khronos time offset) and uses it a
with a prototype implementation. According to this security analysis, if a local s a reference for detecting attacks. This time offset value computation differs
Khronos pool consists of, for example, 500 servers, 1/7 of whom are controlled from the current NTPv4 in two key aspects:</t>
by an attacker and Khronos queries 15 servers in each Khronos poll interval (aro
und 10 times the NTPv4 poll interval), then over 20 years of effort are required
(in expectation) to successfully shift time at a Khronos client by over 100 ms
from UTC. The full exposition of the formal analysis of this guarantee is availa
ble at <xref target="Khronos_paper"/>. </t>
<t>Khronos introduces a watchdog mechanism that maintains a time offset val
ue that is used as a reference for detecting attacks. The time offset value
computation differs from the current NTPv4 in two key aspects. First, Khronos pe
riodically communicates, in each Khronos poll interval, with only a few (tens) r
andomly selected servers out of a pool consisting of a large number (e.g., hundr
eds) of NTP servers.
Second, Khronos computes "Khronos time offset" based on an approximate a
greement technique to remove outliers, thus limiting the attacker's ability to c
ontaminate the "time samples" (offsets) derived from the queried NTP servers. T
hese two aspects allow Khronos to minimize the load on the NTP servers and to pr
ovide provable security guarantees against both MITM attackers and attackers cap
able of compromising a large number of NTP servers. </t>
<t>We note that, to some extent, NTS <xref target="RFC8915"/> could make
it more challenging for attackers to perform MITM attacks, but is of little imp
act if the servers themselves are compromised.</t>
</section>
<section title="Conventions Used in This Document">
<section title="Terms and Abbreviations">
<t><list hangIndent="23" style="hanging">
<t hangText="NTPv4">Network Time Protocol version 4 <xref tar
get="RFC5905"/>.</t>
<t hangText="System process">Selection Algorithm and the Clus
ter Algorithm <xref target="RFC5905"/>.</t>
<t hangText="Security Requirements">Security Requirements
of Time Protocols in Packet Switched Networks <xref target="RFC7384"/>.</t>
<t hangText="NTS">Network Time Security for the Network T
ime Protocol <xref target="RFC8915"/>.</t>
</list></t>
</section>
<section title="Notations">
<texttable anchor="table_example" title="Khronos Notations">
<preamble>Describing Khronos algorithm, the following notation is used.
</preamble>
<ttcol align="center">Notation</ttcol>
<ttcol align="left">Meaning</ttcol>
<c>n </c>
<c>The number of candidate servers in Khronos pool (potentially hundred
s). </c>
<c>m </c>
<c>The number of servers that Khronos queries in each poll interval (up
to tens). </c>
<c>w </c>
<c>An upper bound on the distance between any "truechimer" NTP server (
as in <xref target="RFC5905"/>) and UTC.</c>
<c>B </c>
<c>An upper bound on the client's clock error rate (ms/sec). </c>
<c>ERR </c>
<c>An upper bound on the client's clock error between Khronos polls (ms
).</c>
<c>K </c>
<c>The number of Khronos pool re-samplings until reaching "Panic mode".
</c>
<c>H </c>
<c>Predefined threshold for time offset triggering clock update by Khro
nos.</c>
<postamble></postamble>
</texttable>
<t>The recommended values are discussed in <xref target="values"/>.</t>
</section>
</section>
<section title="Khronos Design">
<t>Khronos watchdog periodically queries a set of m (tens) servers from a la
rge (hundreds) server pool in each Khronos poll interval, where the m servers ar
e selected from the server pool at random. Based on empirical analyses, to minim
ize the load on NTP servers while providing high security, the Khronos poll inte
rval should be around 10 times the NTPv4 poll interval (i.e., a Khronos clock up
date occurs once every 10 NTPv4 clock updates). In each Khronos poll interval, i
f the Khronos time offset exceeds a predetermined threshold (denoted as H), an a
ttack is indicated.</t>
<t> Unless an attack is indicated, Khronos uses only one sample from each
server (avoiding "Clock Filter Algorithm" as defined in section 10 in <xref tar
get="RFC5905"/>). When under attack, Khronos uses several samples from each serv
er, and executes the "Clock Filter Algorithm" for choosing the best sample from
each server, with low jitter. Then, given a sample from each server, Khronos dis
cards outliers by executing the procedure described in <xref target="Conditions"
/>.</t>
<t>Between consecutive Khronos polls, Khronos keeps track of clock offset
s, for example by catching clock discipline (as in <xref target="RFC5905"/>) cal
ls. The sum of offsets is referred to as "Khronos inter-poll offset" (denoted as
tk) which is set to zero after each Khronos poll.</t>
<section title="Khronos Calibration - Gathering the Khronos Pool">
<t>Calibration is performed at the first time the Khronos is executed, and
also periodically, once in a long time (every two weeks). The calibration proces
s generates a local Khronos pool of n (up to hundreds) NTP servers the client ca
n synchronize with. To this end, Khronos makes DNS queries to addresses of NTP p
ools collect the union of all received IP addresses. The servers in the Khronos
pool should be scattered across different regions to make it harder for an attac
ker to compromise, or gain machine-in-the-middle capabilities, with respect to a
large fraction of the Khronos pool. Therefore, Khronos calibration queries gene
ral NTP server pools (for example pool.ntp.org), and not only the pool in the cl
ient's state or region. In addition, servers can be selected to Khronos pool man
ually or by using other NTP pools (such as NIST internet time servers).</t>
<t>The first Khronos update requires m servers, which can be found in se
veral minutes. Moreover, it is possible to query several DNS pool names to vastl
y accelerate the calibration and the first update.</t>
<t>The calibration is the only Khronos part where DNS traffic is generat <ul><li>
ed. Around 125 DNS queries are required by Khronos to obtain addresses of 500 NT First, in each Khronos poll interval, Khronos periodically communicates w
P servers which is higher than Khronos pool size (n). Assuming the calibration p ith only a few (tens) randomly selected servers out of a pool consisting of a la
eriod is two weeks, the expected DNS traffic generated by Khronos client is less rge number (e.g., hundreds) of NTP servers.</li>
than 10 DNS queries per day, which is usually several orders of magnitude lower <li>Second, Khronos computes the Khronos time offset based on an approxima
than the total daily number of DNS queries per machine. </t> te agreement technique to remove outliers, thus limiting the attacker's ability
to contaminate the time samples (offsets) derived from the queried NTP servers.
</li>
</ul>
<t>These two aspects allow Khronos to minimize the load on the NTP servers and t
o provide provable security guarantees against both MITM attackers and attackers
capable of compromising a large number of NTP servers. </t>
<t>We note that, to some extent, Network Time Security (NTS) <xref target=
"RFC8915" format="default"/> could make it more challenging for attackers to per
form MITM attacks, but is of little impact if the servers themselves are comprom
ised.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<section numbered="true" toc="default">
<name>Terms and Abbreviations</name>
<section anchor="Conditions" title="Khronos's Poll and System Processes"> <dl newline="false" spacing="normal">
<t>In each Khronos poll interval the Khronos system process randomly choose <dt>NTPv4:</dt>
s a set of m (tens) servers out of the Khronos pool of n (hundreds) servers and <dd>Network Time Protocol version 4. See <xref target="RFC5905" format
samples them. Note that the randomness of the server selection is crucial for th ="default"/>.</dd>
e security of the scheme and therefore any Khronos implementation must use secur <dt>System process:</dt>
e randomness implementation such as used for encryption key generation. </t> <dd>See the "Selection Algorithm" and the "Cluster Algorithm" sections
of <xref target="RFC5905" format="default"/>.</dd>
<t> Khronos's polling times of different servers may spread uniformly wi <dt>Security Requirements:</dt>
thin its poll interval, similar to NTPv4. Servers which do not respond during th <dd>See "<xref target="RFC7384" format="title"/>" <xref target="RFC738
e Khronos poll interval are filtered out. If less than 1/3 of the m servers are 4" format="default"/>.</dd>
left, a new subset of servers is immediately sampled, in the exact same manner ( <dt>NTS:</dt>
called "resampling" process).</t> <dd>Network Time Security. See "<xref target="RFC8915" format="title"
/>" <xref target="RFC8915" format="default"/>.</dd>
<t>Next, out of the time-samples received from this chosen subset of ser </dl>
vers, the lowest third of the samples' offset values and highest third of the sa </section>
mples' offset values are discarded.</t> <section numbered="true" toc="default">
<name>Notations</name>
<t keepWithNext="true">When describing the Khronos algorithm, the follow
ing notation is used:</t>
<t>Khronos checks that the following two conditions hold for the remaining <table anchor="table_example" align="center">
sampled offsets: </t> <name>Khronos Notation</name>
<t><list style="symbols"> <thead>
<t>The maximal distance between every two offsets does not exceed 2w <tr>
(can be verified by considering just the minimum and the maximum offsets).</t> <th align="center">Notation</th>
<t>The distance between the offsets average and Khronos inter-poll o <th align="left">Meaning</th>
ffset is at most ERR+2w.</t> </tr>
</list> </t> </thead>
<t> (where w and ERR are as described in <xref target="table_example"/>) <tbody>
.</t> <tr>
<td align="center">n </td>
<td align="left">The number of candidate servers in a Khronos pool
(potentially hundreds). </td>
</tr>
<tr>
<td align="center">m </td>
<td align="left">The number of servers that Khronos queries in eac
h poll interval (up to tens). </td>
</tr>
<tr>
<td align="center">w </td>
<td align="left">An upper bound on the distance between any "truec
himer" NTP server (as in <xref target="RFC5905" format="default"/>) and UTC.</td
>
</tr>
<tr>
<td align="center">B </td>
<td align="left">An upper bound on the client's clock error rate (
ms/sec). </td>
</tr>
<tr>
<td align="center">ERR </td>
<td align="left">An upper bound on the client's clock error betwee
n Khronos polls (ms).</td>
</tr>
<tr>
<td align="center">K </td>
<td align="left">The number of Khronos pool resamplings until reac
hing "panic mode".</td>
</tr>
<tr>
<td align="center">H </td>
<td align="left">Predefined threshold for a Khronos time offset tr
iggering clock update by Khronos.</td>
</tr>
</tbody>
</table>
<t keepWithPrevious="true"/>
<t>The recommended values are discussed in <xref target="values" format=
"default"/>.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Khronos Design</name>
<t>Khronos periodically queries a set of m (tens) servers from a large (hu
ndreds) server pool in each Khronos poll interval, where the m servers are selec
ted from the server pool at random. Based on empirical analyses, to minimize the
load on NTP servers while providing high security, the Khronos poll interval sh
ould be around 10 times the NTPv4 poll interval (i.e., a Khronos clock update oc
curs once every 10 NTPv4 clock updates). In each Khronos poll interval, if the K
hronos time offset exceeds a predetermined threshold (denoted as H), an attack i
s indicated.</t>
<t> Unless an attack is indicated, Khronos uses only one sample from each
server (avoiding the "Clock Filter Algorithm" as defined in <xref target="RFC590
5" sectionFormat="of" section="10"/>). When under attack, Khronos uses several s
amples from each server and executes the "Clock Filter Algorithm" for choosing t
he best sample from each server with low jitter. Then, given a sample from each
server, Khronos discards outliers by executing the procedure described in <xref
target="Conditions" format="default"/>.</t>
<t>Between consecutive Khronos polls, Khronos keeps track of clock offsets
, e.g., by catching clock discipline (as in <xref target="RFC5905" format="defau
lt"/>) calls. The sum of offsets is referred to as the "Khronos inter-poll offse
t" (denoted as tk), which is set to zero after each Khronos poll.</t>
<section numbered="true" toc="default">
<name>Khronos Calibration - Gathering the Khronos Pool</name>
<t>In the event that both of these conditions are satisfied, the average of <t>Calibration is performed the first time Khronos is executed and periodically
the offsets is set to be the "Khronos time offset". Otherwise, resampling is pe thereafter (once every two weeks). The calibration process generates a local Khr
rformed. This process spreads Khronos client's queries across servers thereby im onos pool of n (up to hundreds) NTP servers that the client can synchronize with
proving security against powerful attackers (as discussed in <xref target="Secur .
ity_analysis"/>) and mitigating the effect of a DoS attack on NTP servers that r To this end, Khronos makes multiple DNS queries to the NTP pools. Each query ret
enders them non-responsive. This resampling process continues in subsequent Khro urns a few NTP server IPs that Khronos combines into one set of IPs considered a
nos poll intervals until the two conditions are both satisfied or the number of s the Khronos pool.
times the servers are re-sampled exceeds a "Panic Trigger" (K in <xref target="t The servers in the Khronos pool should be scattered across different regions to
able_example"/>), in which case Khronos enters a "Panic Mode".</t> make it harder for an attacker to compromise or gain MITM capabilities with resp
ect to a large fraction of the Khronos pool. Therefore, Khronos calibration quer
ies general NTP server pools (e.g., pool.ntp.org) and not just the pool in the c
lient's state or region.
<t>In panic mode, Khronos queries all the servers in its local Khronos pool In addition, servers can be selected to be part of the Khronos pool manually or
, orders the collected time samples from lowest to highest and eliminates the lo by using other NTP pools (such as NIST Internet time servers).</t>
west third and the highest third of the samples. The client then averages over t <t>The first Khronos update requires m servers, which can be found in se
he remaining samples, and sets this average to be the new "Khronos time offset". veral minutes. Moreover, it is possible to query several DNS pool names to vastl
</t> y accelerate the calibration and the first update.</t>
<t>The calibration is the only Khronos part where DNS traffic is generat
ed. Around 125 DNS queries are required by Khronos to obtain addresses of 500 NT
P servers, which is higher than Khronos pool size (n). Assuming the calibration
period is two weeks, the expected DNS traffic generated by the Khronos client is
less than 10 DNS queries per day, which is usually several orders of magnitude
lower than the total daily number of DNS queries per machine. </t>
</section>
<section anchor="Conditions" numbered="true" toc="default">
<name>Khronos's Poll and System Processes</name>
<t>In each Khronos poll interval, the Khronos system process randomly ch
ooses a set of m (tens) servers out of the Khronos pool of n (hundreds) servers
and samples them. Note that the randomness of the server selection is crucial fo
r the security of the scheme; therefore, any Khronos implementation must use a s
ecure randomness implementation such as what is used for encryption key generati
on. </t>
<t> Khronos's polling times of different servers may spread uniformly wi
thin its poll interval, which is similar to NTPv4. Servers that do not respond d
uring the Khronos poll interval are filtered out. If less than one-third of the
m servers are left, a new subset of servers is immediately sampled in the exact
same manner (which is called the "resampling" process).</t>
<t>Next, out of the time samples received from this chosen subset of ser
vers, the lowest third of the samples' offset values and the highest third of th
e samples' offset values are discarded.</t>
<t>Khronos checks that the following two conditions hold for the remaini
ng sampled offsets (considering w and ERR defined in <xref target="table_example
" format="default"/>): </t>
<ul spacing="normal">
<li>The maximal distance between every two offsets does not exceed 2w
(can be verified by considering just the minimum and the maximum offsets).</li>
<li>The distance between the offset's average and the Khronos inter-po
ll offset is ERR+2w at most.</li>
</ul>
<t>
In the event that both of these conditions are satisfied, the average of
the offsets is set to be the Khronos time offset. Otherwise, resampling is
performed. This process spreads the Khronos client's queries across
servers, thereby improving security against powerful attackers (as
discussed in <xref target="Security_analysis" format="default"/>) and
mitigating the effect of a DoS attack on NTP servers that renders them
non-responsive. This resampling process continues in subsequent Khronos
poll intervals until the two conditions are both satisfied or the number of
times the servers are resampled exceeds a "panic trigger" (K in <xref
target="table_example" format="default"/>). In this case, Khronos enters
panic mode.</t>
<t>If the Khronos time offset exceeds a predetermined threshold (H) it is p <t>In panic mode, Khronos queries all the servers in its local Khronos p
assed on to the clock discipline algorithm in order to steer the system time (as ool, orders the collected time samples from lowest to highest, and eliminates th
in <xref target="RFC5905"/>). In this case the user and/or admin of the client e lowest third and the highest third of the samples. The client then calculates
machine should be notified about the detected time shifting attack, for example the average of the remaining samples and sets this average to be the new Khronos
by a message written to a relevant event log or displayed on screen.</t> time offset.</t>
<t>If the Khronos time offset exceeds a predetermined threshold (H), it
is passed on to the clock discipline algorithm in order to steer the system time
(as in <xref target="RFC5905" format="default"/>). In this case, the user and/o
r admin of the client machine should be notified about the detected time-shiftin
g attack, e.g., by a message written to a relevant event log or displayed on scr
een.</t>
<t> Note that resampling follows immediately the previous sampling sinc <t> Note that resampling immediately follows the previous sampling
e waiting until the next polling interval may increase the time shift in face of since waiting until the next polling interval may increase the time
attack. This shouldn't generate high overhead since the number of resamples is shift in face of an attack. This shouldn't generate high overhead
bounded by K (after K resamplings, "Panic mode" is in place) and the chances to since the number of resamples is bounded by K (after K resamplings,
arrive to repeated resampling are low (see <xref target="Security"/> for more de panic mode is in place) and the chances of ending up with repeated
tails). Moreover, in an interval following a panic mode, Khronos executes the sa resampling are low (see <xref target="Security" format="default"/> for
me system process which starts by querying only m servers (regardless of previou more details). Moreover, in an interval following a panic mode,
s panic).</t> Khronos executes the same system process that starts by querying only
m servers (regardless of previous panic).</t>
</section>
<section anchor="values" numbered="true" toc="default">
<name>Khronos's Recommended Parameters</name>
<t>According to empirical observations (presented in <xref target="Khron
os" format="default"/>), querying 15 servers at each poll interval (i.e., m=15)
out of 500 servers (i.e., n=500) and setting w to be around 25 ms provides both
high time accuracy and good security. Specifically, when selecting w=25 ms, appr
oximately 83% of the servers' clocks are, at most, w away from UTC and within 2w
from each other, satisfying the first condition of Khronos's system process. Fo
r a similar reason, the threshold for a Khronos time offset triggering a clock u
pdate by Khronos (H) should be between w and 2w; the default is 30 ms. Note that
in order to support scenarios with congested links, using a higher w value, suc
h as 1 second, is recommended.</t>
<t>Furthermore, according to Khronos security analysis, setting K to be 3 (i.e.,
if the two conditions are not satisfied after three resamplings, then Khronos
enters panic mode) is safe when facing time-shifting attacks. In addition, the
probability of an attacker forcing a panic mode on a client when K=3 is negligib
le (less than 0.000002 for each polling interval).</t>
<t>Khronos's effect on precision and accuracy are discussed in Sections
<xref target="Security" format="counter"/> and <xref target="Precision_Security"
format="counter"/>. </t>
</section>
</section> </section>
<section anchor="operational" numbered="true" toc="default">
<name>Operational Considerations</name>
<t> Khronos is designed to defend NTP clients from time-shifting attacks w
hile using public NTP servers. As such, Khronos is not applicable for data cent
ers and enterprises that synchronize with local atomic clocks, GPS devices, or a
dedicated NTP server (e.g., due to regulations).</t>
<section anchor="values" title="Khronos's Recommended Parameters"> <t> Khronos can be used for devices that require and depend upon timekeeping wit
<t>According to empirical observations (presented in <xref target="Khronos_ hin a configurable constant distance from UTC.</t>
paper"/>), querying 15 servers at each poll interval (i.e., m=15) out of 500 ser <section anchor="Security_vs._load_considerations" numbered="true" toc="de
vers (i.e., n=500), and setting w to be around 25 ms provides both high time acc fault">
uracy and good security. Specifically, when selecting w=25ms, approximately 83% <name>Load Considerations</name>
of the servers' clocks are at most w-away from UTC, and within 2w from each othe <t>One requirement from Khronos is not to induce excessive load on NTP s
r, satisfying the first condition of Khronos's system process. For similar reaso ervers beyond that of NTPv4, even if it is widely integrated into NTP clients. W
n, the threshold for time offset triggering clock update by Khronos (H) should b e discuss below the possible causes for a Khronos-induced load on servers and ho
e between w to 2w and is selected on default to 30ms. Note that in order to supp w this can be mitigated.</t>
ort congested links scenarios, it is recommended to use a higher w value, such a <t>Servers in pool.ntp.org are weighted differently by the NTP server po
s 1 sec.</t> ol when assigned to NTP clients. Specifically, server owners define a "server we
ight" (the "netspeed" parameter) and servers are assigned to clients probabilist
<t>Furthermore, according to Khronos security analysis, setting K to be 3 ( ically according to their proportional weight. Khronos's queries are equally dis
i.e., if after 3 re-samplings the two conditions are not satisfied then Khronos tributed across a pool of servers. To avoid overloading servers, Khronos queries
enters "panic mode") is safe when facing time shifting attacks. In addition, the servers less frequently than NTPv4, with the Khronos query interval set to 10 t
probability of an attacker forcing a panic mode on a client when K equals 3, is imes the default NTPv4 maxpoll (interval) parameter. Hence, if Khronos queries a
negligible (less than 0.000002 for each polling interval).</t> re targeted at servers in pool.ntp.org, any target increase in server load (in t
<t>Khronos's effect on precision and accuracy are discussed in <xref target erms of multiplicative increase in queries or number of bytes per second) is con
="Precision_Security"/> and <xref target="Security"/>. </t> trolled by the poll interval configuration, which was analyzed in <xref target="
Ananke" format="default"/>.</t>
<t>Consider the scenario where an attacker attempts to generate signific
ant load on NTP servers by triggering multiple consecutive panic modes at multip
le NTP clients. We note that to accomplish this, the attacker must have MITM cap
abilities with respect to the communication between each and every client in a l
arge group of clients and a large fraction of all NTP servers in the queried poo
l. This implies that the attacker must either be physically located at a central
location (e.g., at the egress of a large ISP) or launch a wide-scale attack (e.
g., on BGP or DNS); thereby, it is capable of carrying similar and even higher i
mpact attacks regardless of Khronos clients.</t>
</section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="threatModel" numbered="true" toc="default">
<name>Threat Model</name>
</section> <t>The threat model encompasses a broad spectrum of attackers impacting
a subset (e.g., one-third) of the servers in NTP pools. These attackers can rang
<section anchor="operational" title="Operational Considerations"> e from a fairly weak (yet dangerous) MITM attacker that is only capable of delay
<t> Khronos is designed in order to defend NTP clients from time shifting ing and dropping packets (e.g., using the Bufferbloat attack <xref target="RFC80
attacks while using public NTP servers. As such, Khronos is not applicable for 33"/>) to an extremely powerful attacker who is in control of (even authenticate
datacenters and enterprises which synchronize with local atomic clocks, GPS dev d) NTP servers and is capable of fully determining the values of the time sample
ices or a dedicated NTP server (for example due to regulations).</t> s returned by these NTP servers (see detailed attacker discussion in <xref targe
t="RFC7384" format="default"/>).</t>
<t> Khronos can be used for devices that require and depend upon time kee
ping withing a configurable constant distance from UTC.</t>
<section anchor="Security vs. load considerations" title="Load considerat
ions">
<t>One requirement from Khronos is thus not to induce excessive load on N
TP servers beyond that of NTPv4, even if widely integrated into NTP clients. We
discuss below the possible causes for Khronos-induced load on servers and how th
is can be mitigated.</t>
<t>Servers in pool.ntp.org are weighted differently by the NTP server pool wh
en assigned to NTP clients. Specifically, server owners define a ``server weight
'' (the ``netspeed'' parameter) and servers are assigned to clients probabilisti
cally according to their proportional weight. Khronos (watchdog mode) queries ar
e equally distributed across a pool of servers. To avoid overloading servers, Kh
ronos queries servers less frequently than NTPv4, with Khronos query interval se
t to 10 times the default NTPv4 maxpoll (interval) parameter. Hence, if Khronos
queries are targeted at servers in pool.ntp.org, any target increase in server l
oad (in terms of multiplicative increase in queries or number of bytes per secon
d) is controlled by the poll interval configuration which was analyzed in <xref
target="Ananke_paper"/>.</t>
<t> Consider the scenario where an attacker attempts to generate significant
load on NTP servers by triggering multiple consecutive panic modes at multiple N
TP clients. We note that to accomplish this, the attacker must have man-in-the-m
iddle capabilities with respect to the communication between each and every clie
nt in a large group of clients and a large fraction of all NTP servers in the qu
eried pool. This implies that the attacker must either be physically located at
a central location (e.g., at the egress of a large ISP) or launch a wide scale a
ttack (e.g., on BGP or DNS) and thereby capable to carry similar and even higher
impact attacks regardless of Khronos clients.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<section anchor="threatModel" title="Threat Model">
<t> The following powerful attacker, including MitM, is considered: the atta
cker is assumed to control a subset (e.g., third) of the servers in NTP pools an
d is capable of fully determining the values of the time samples returned by the
se NTP servers. The threat model encompasses a broad spectrum of attackers, rang
ing from fairly weak (yet dangerous) MitM attackers only capable of delaying and
dropping packets (for example using the Bufferbloat attack) to extremely powerf
ul attackers who are in control of (even authenticated) NTP servers (see detaile
d security requirements discussion in <xref target="RFC7384"/>).</t>
<t> The attackers covered by this model might be, for example, (1) in dir
ect control of a fraction of the NTP servers (e.g., by exploiting a software vul
nerability), (2) an ISP (or other Autonomous-System-level attacker) on the defau
lt BGP paths from the NTP client to a fraction of the available servers, (3) a n
ation state with authority over the owners of NTP servers in its jurisdiction, o
r (4) an attacker capable of hijacking (e.g., through DNS cache poisoning or BGP
prefix hijacking) traffic to some of the available NTP servers. The details of
the specific attack scenario are abstracted by reasoning about attackers in term
s of the fraction of servers with respect to which the attacker has adversarial
capabilities.
Attackers that can impact communications with (or control) higher fractio
n of the servers, for example all servers, are out of scope. Considering pool si
ze to be thousands across the world, such attackers will most probably be capabl
e of performing far worst damage than time shifting. </t>
<t> Notably, Khronos provides protection from MitM and powerful attacks t <t>For example, the attackers covered by this model might be:</t>
hat cannot be achieved by cryptographic authentication protocols since even with <ol><li>in direct control of a fraction of the NTP servers (e.g., by exploiting
such measures in place an attacker can still influence time by dropping/delayin a software vulnerability),</li>
g packets. However, adding an authentication layer (e.g., NTS <xref target="RFC8 <li>an ISP (or other attacker at the Autonomous System level) on the default BGP
915"/>) to Khronos will enhance its security guarantees and enable the detection paths from the NTP client to a fraction of the available servers,</li>
of various spoofing and modification attacks.</t> <li>a nation state with authority over the owners of NTP servers in its jurisdic
tion, or</li>
<li>an attacker capable of hijacking (e.g., through DNS cache poisoning or BGP p
refix hijacking) traffic to some of the available NTP servers.</li>
</ol>
<t>The details of the specific attack scenario are abstracted by reasoning about
attackers in terms of the fraction of servers with respect to which the attacke
r has adversarial capabilities.
Attackers that can impact communications with (or control) a higher fract
ion of the servers (e.g., all servers) are out of scope.
Considering the pool size across the world to be in the thousands, such attacker
s will most likely be capable of creating far worse damage than time-shifting at
tacks. </t>
<t> Notably, Khronos provides protection from MITM and powerful attacks that can
not be achieved by cryptographic authentication protocols since, even with such
measures in place, an attacker can still influence time by dropping/delaying pac
kets. However, adding an authentication layer (e.g., NTS <xref target="RFC8915"
format="default"/>) to Khronos will enhance its security guarantees and enable t
he detection of various spoofing and modification attacks.</t>
<t> Moreover, Khronos uses randomness to independently select the querie
d servers in each poll interval, preventing attackers from exploiting observatio
ns of past server selections.
</t>
</section>
<section anchor="attackDetection" numbered="true" toc="default">
<name>Attack Detection</name>
<t> Khronos detects time-shifting attacks by constantly monitoring NTPv4
's (or potentially any other current or future time protocol) clock and the offs
et computed by Khronos and checking whether the offset exceeds a predetermined t
hreshold (H). NTPv4 controls the client's clock unless an attack was detected. U
nder attack, Khronos takes control over the client's clock in order to prevent i
ts shift.</t>
<t>Analytical results (in <xref target="Khronos" format="default"/>) ind
icate that if a local Khronos pool consists of 500 servers, one-seventh of whom
are controlled by a MITM attacker, and 15 of those servers are queried in each K
hronos poll interval, then success in shifting time of a Khronos client by even
a small degree (100 ms) takes many years of effort (over 20 years in expectation
). See a brief overview of Khronos's security analysis below.</t>
</section>
<section anchor="Security_analysis" numbered="true" toc="default">
<name>Security Analysis Overview</name>
<t>Time samples that are at most w away from UTC are considered "good",
whereas other samples are considered "malicious". Two scenarios are considered:
</t>
<ul spacing="normal">
<li>Scenario A: Less than two-thirds of the queried servers are under
the attacker's control.</li>
<li>Scenario B: The attacker controls more than two-thirds of the quer
ied servers.</li>
</ul>
<t>Scenario A consists of two sub-cases:</t>
<ol>
<li>There is at least one good sample in the set of samples not elimina
ted by Khronos (in the middle third of samples), and</li>
<li>there are no good samples in the remaining set of samples.</li>
</ol>
<t>In sub-case 1, the other remaining samples, including those
provided by the attacker, must be close to a good sample (otherwise, the firs
t condition of Khronos's system process in <xref target="Conditions" format="def
ault"/> is violated and a new set of servers is chosen). This implies that the a
verage of the remaining samples must be close to UTC.</t>
<t>In sub-case 2, since more than a third of the initial samples were
good, both the (discarded) third-lowest-value samples and the
(discarded) third-highest-value samples must each contain a good
sample. Hence, all the remaining samples are bounded from both
above and below by good samples, and so is their average value,
implying that this value is close to UTC <xref target="RFC5905"/>.</t>
<t> Moreover, Khronos uses randomness to independently select the queried <t>In Scenario B, the worst possibility for the client is that all remaining
servers in each poll interval, preventing attackers from exploiting observation samples are malicious (i.e., more than w away from UTC). However, as proved
s of past server selections. in <xref target="Khronos" format="default"/>, the probability of this scenario
</t> is extremely low, even if the attacker controls a large fraction (e.g.,
one-fourth) of the n servers in the local Khronos pool. Therefore, the
probability that the attacker repeatedly reaches this scenario decreases
exponentially, rendering the probability of a significant time shift
negligible. We can express the improvement ratio of Khronos over NTPv4 by the
ratios of their single-shift probabilities. Such ratios are provided in <xref
target="improvement_ratio" format="default"/>, where higher values indicate
higher improvement of Khronos over NTPv4 and are also proportional to the
expected time until a time-shift attack succeeds once.</t>
<t keepWithNext="true"/>
<table anchor="improvement_ratio" align="center">
<name>Khronos Improvement</name>
<thead>
<tr>
<th align="center">Attack Ratio</th>
<th align="center">6 Samples</th>
<th align="center">12 Samples</th>
<th align="center">18 Samples</th>
<th align="center">24 Samples</th>
<th align="center">30 Samples</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1/3</td>
<td align="center">1.93e+01</td>
<td align="center">3.85e+02</td>
<td align="center">7.66e+03</td>
<td align="center">1.52e+05</td>
<td align="center">3.03e+06</td>
</tr>
<tr>
<td align="center">1/5</td>
<td align="center">1.25e+01</td>
<td align="center">1.59e+02</td>
<td align="center">2.01e+03</td>
<td align="center">2.54e+04</td>
<td align="center">3.22e+05</td>
</tr>
<tr>
<td align="center">1/7</td>
<td align="center">1.13e+01</td>
<td align="center">1.29e+02</td>
<td align="center">1.47e+03</td>
<td align="center">1.67e+04</td>
<td align="center">1.90e+05</td>
</tr>
<tr>
<td align="center">1/9</td>
<td align="center">8.54e+00</td>
<td align="center">7.32e+01</td>
<td align="center">6.25e+02</td>
<td align="center">5.32e+03</td>
<td align="center">4.52e+04</td>
</tr>
<tr>
<td align="center">1/10</td>
<td align="center">5.83e+00</td>
<td align="center">3.34e+01</td>
<td align="center">1.89e+02</td>
<td align="center">1.07e+03</td>
<td align="center">6.04e+03</td>
</tr>
<tr>
<td align="center">1/15</td>
<td align="center">3.21e+00</td>
<td align="center">9.57e+00</td>
<td align="center">2.79e+01</td>
<td align="center">8.05e+01</td>
<td align="center">2.31e+02</td>
</tr>
</tbody>
</table>
<t keepWithPrevious="true"/>
<t>In addition to evaluating the probability of an attacker successfully
shifting time at the client's clock, we also evaluated the probability that the
attacker succeeds in launching a DoS attack on the servers by causing many clie
nts to enter panic mode (and querying all the servers in their local Khronos poo
ls). This probability (with the previous parameters of n=500, m=15, w=25, and K=
3) is negligible even for an attacker who controls a large number of servers in
clients' local Khronos pools, and it is expected to take decades to force a pani
c mode. </t>
<t>Further details about Khronos's security guarantees can be found in <
xref target="Khronos" format="default"/>.</t>
</section>
</section> </section>
<section anchor="Pseudocode" numbered="true" toc="default">
<name>Khronos Pseudocode</name>
<section anchor="attackDetection" title="Attack Detection"> <!--
<t> Khronos detects time-shifting attacks by constantly monitoring NTPv4's ( this is incorrect, please see below for further guidance:
or potentially any other current or future time protocol) clock and the offset c
omputed by Khronos and checking whether the offset exceeds a predetermined thres
hold (H). Unless an attack was detected, NTPv4 controls the client's clock. Unde
r attack, Khronos takes control over the clients clock in order to prevent its s
hift.</t>
<t>Analytical results (in <xref target="Khronos_paper"/>) indicate that if a
local Khronos pool consists of 500 servers, 1/7 of whom are controlled by a mac
hine-in-the-middle attacker, and 15 servers are queried in each Khronos poll int
erval, then success in shifting time of a Khronos client by even a small degree
(100 ms), takes many years of effort (over 20 years in expectation). See a brief
overview of Khronos's security analysis below.</t>
<t> Khronos's security analysis is briefly described next.</t>
</section>
<section anchor="Security_analysis" title="Security Analysis Overview">
<t>Time-samples that are at most w away from UTC are considered "good", whe
reas other samples are considered "malicious". Two scenarios are considered: </t
>
<t><list style="symbols">
<t>Less than 2/3 of the queried servers are under the attacker's control.</
t>
<t>The attacker controls more than 2/3 of the queried servers.</t>
</list></t>
<t>The first scenario, where there are more than 1/3 good samples, consists
of two sub-cases: (i) there is at least one good sample in the set of samples n
ot eliminated by Khronos (in the middle third of samples), and (ii) there are no
good samples in the remaining set of samples. In the first of these two cases (
at least one good sample in the set of samples that was not eliminated by Khrono
s), the other remaining samples, including those provided by the attacker, must
be close to a good sample (for otherwise, the first condition of Khronos's syste
m process in <xref target="Conditions"/> is violated and a new set of servers is
chosen). This implies that the average of the remaining samples must be close t
o UTC. In the second sub-case (where there are no good samples in the set of rem
aining samples), since more than a third of the initial samples were good, both
the (discarded) third lowest-value samples and the (discarded) third highest-val
ue samples must each contain a good sample. Hence, all the remaining samples are
bounded from both above and below by good samples, and so is their average valu
e, implying that this value is close to UTC <xref target="RFC5905"/>.</t>
<t>In the second scenario, where the attacker controls more than 2/3 of the
queried servers, the worst possibility for the client is that all remaining sam
ples are malicious (i.e., more than w away from UTC). However, as proved in <xre
f target="Khronos_paper"/>, the probability of this scenario is extremely low ev
en if the attacker controls a large fraction (e.g., 1/4) of the n servers in the
local Khronos pool. Therefore, the probability that the attacker repeatedly rea
ches this scenario decreases exponentially, rendering the probability of a signi
ficant time shift negligible. We can express the improvement ratio of Khronos ov
er NTPv4 by the ratios of their single shift probabilities. Such ratios are prov
ided in Table <xref target="improvement_ratio"/>, where higher values indicate h
igher improvement of Khronos over NTPv4 and are also proportional to the expecte
d time till a time shift attack succeeds once. </t>
<texttable anchor="improvement_ratio" title="Khronos Improvement">
<preamble></preamble>
<ttcol align="center">Attack Ratio</ttcol>
<ttcol align="center">6 samples</ttcol>
<ttcol align="center">12 samples</ttcol>
<ttcol align="center">18 samples</ttcol>
<ttcol align="center">24 samples</ttcol>
<ttcol align="center">30 samples</ttcol>
<c>1/3</c> <c>1.93e+01</c> <c>3.85e+02</c> <c>7.66e+03</c> <c>1.52e+05
</c> <c>3.03e+06</c>
<c>1/5</c> <c>1.25e+01</c> <c>1.59e+02</c> <c>2.01e+03</c> <c>2.54e+04
</c> <c>3.22e+05</c>
<c>1/7</c> <c>1.13e+01</c> <c>1.29e+02</c> <c>1.47e+03</c> <c>1
.67e+04</c> <c>1.90e+05</c>
<c>1/9</c> <c>8.54e+00</c> <c>7.32e+01</c> <c>6.25e+02</c> <c>5
.32e+03</c> <c>4.52e+04</c>
<c>1/10</c> <c>5.83e+00</c> <c>3.34e+01</c> <c>1.89e+02</c> <c>1
.07e+03</c> <c>6.04e+03</c>
<c>1/15</c> <c>3.21e+00</c> <c>9.57e+00</c> <c>2.79e+01</c> <c>8
.05e+01</c> <c>2.31e+02</c>
<postamble></postamble>
</texttable>
<t>In addition to evaluating the probability of an attacker successfully sh
ifting time at the client's clock, we also evaluated the probability that the at
tacker succeeds in launching a DoS attack on the servers by causing many clients
to enter a panic mode (and query all the servers in their local Khronos pools).
This probability (with the previous parameters of n=500, m=15, w=25 and K=3) is
negligible even for an attacker who controls a large number of servers in clien
t's local Khronos pools, and it is expected to take decades to force panic mode.
</t>
<t>Further details about Khronos's security guarantees can be found in < If the current list of preferred values for "type"
xref target="Khronos_paper"/>.</t> (https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
</section> contain an applicable type, then feel free to let us know. Also, it is
acceptable to leave the "type" attribute not set.
</section> c) Please review the following line as it exceeds our character limit.
Please let us know how we can update.
<!-- This PI places the pagebreak correctly (before the section title) in the Original:
text output. --> S = sample(m) //gather samples from (tens of) randomly chosen servers
<section anchor="Pseudocode" Perhaps:
title="Khronos Pseudocode"> S = sample(m) //get samples from (tens of) randomly chosen servers
<figure> -->
<preamble>The pseudocode for Khronos Time Sampling Scheme, which is invok
ed in each Khronos poll interval is as follows:</preamble>
<artwork><![CDATA[ <t keepWithNext="true">The pseudocode for Khronos Time Sampling Scheme, wh
counter = 0 ich is invoked in each Khronos poll interval, is as follows:</t>
S = [] <sourcecode type="pseduocode">
T = [] counter = 0
While counter < K do S = []
S = sample(m) //gather samples from (tens of) randomly chosen servers T = []
T = bi_side_trim(S,1/3) //trim lowest and highest thirds While counter &lt; K do
if (max(T) - min(T) <= 2w) and (|avg(T) - tk| < ERR + 2w) Then S = sample(m) //get samples from (tens of) randomly chosen servers
return avg(T) // Normal case T = bi_side_trim(S,1/3) //trim lowest and highest thirds
end if (max(T) - min(T) &lt;= 2w) and (|avg(T) - tk| &lt; ERR + 2w), then
counter ++ return avg(T) // Normal case
end end
// panic mode counter ++
S = sample(n) end
T = bi-sided-trim(S,1/3) //trim lowest and highest thirds // panic mode
return avg(T) S = sample(n)
T = bi-sided-trim(S,1/3) //trim lowest and highest thirds
]]></artwork> return avg(T)
</figure> </sourcecode>
<t>Note that if clock disciplines can be called during this pseudocode's executi
</section> on, then each time offset sample, as well as the final output (Khronos time offs
et), should be normalized with the sum of the clock disciplines offsets (tk) at
<section anchor="Precision_Security" title="Precision vs. Security"> the time of computing it.</t>
<t>Since NTPv4 updates the clock at times when no time-shifting attacks
are detected, the precision and accuracy of a Khronos client are the same as NTP
v4 at these times.
Khronos is proved to maintain an accurate estimation of the UTC with hig
h probability. Therefore when Khronos detects that client's clock error exceeds
a threshold (H), it considers it as an attack and takes control over the client'
s clock. As a result, the time shift is mitigated and high accuracy is guarantee
d (the error is bounded by H).</t>
<t> Khronos is based on crowdsourcing across servers and regions, change
s the set of queried servers more frequently than NTPv4 <xref target="Khronos_pa
per"/>, and avoids some of the filters in NTPv4's system process. These factors
can potentially harm its precision. Therefore, a smoothing mechanism can be used
, where instead of a simple average of the remaining samples, the smallest (in a
bsolute value) offset is used unless its distance from the average is higher tha
n a predefined value. Preliminary experiments demonstrated promising results wit
h precision similar to NTPv4.</t>
<t> Note that in applications such as multi source media streaming, whic
h are highly sensitive to time differences among hosts, it is advisable to use K
hronos at all hosts in order to obtain high precision even in the presence of at
tackers that try to shift each host in a different magnitude and/or direction. A
nother more efficient approach for this cases may be to allow direct time synchr
onization between one host who runs Khronos to others.</t>
</section>
<section anchor="implementation" title="Implementation Status">
<t> This section records the status of known implementations of the proto
col defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in <xref target="RFC7942
"/>.
The description of implementations in this section is intended to assist the
IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation here doe
s not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was supplied by
IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their features.
Readers are advised to note that other implementations may
exist.</t>
<t> According to <xref target="RFC7942"/>, "this will allow reviewers and wor
king groups to assign due consideration to documents that have the benefit of ru
nning code, which may serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is up to the individua
l working groups to use this information as they see fit".</t>
<section anchor="implementation1" title="Implementation 1">
<t> Organization: Hebrew University of Jerusalem </t>
<t> Implementers: Neta Rozen-Schiff, May Yaaron, Noam Caspi and Shahar Co
hen </t>
<t> Maturity: Proof-of-Concept Prototype</t>
<t> This implementation was used to check consistency and to ensure complete
ness of this specification.</t>
<section anchor="coverage" title="Coverage">
<t> This implementation covers the complete specification.</t>
</section>
<section anchor="licensing" title="Licensing">
<t> The code is released under the MIT license.</t>
<t> The source code is available at: https://github.com/netars/chronos</t
>
</section>
<section anchor="contact" title="Contact Information">
<t>Contact Martin Langer: neta.r.schiff@gmail.com</t>
</section>
<section anchor="update_date" title="Last Update">
<t>The implementation was updated in June 2022.</t>
</section>
</section>
<section anchor="implementation2" title="Implementation 2">
<t> Organization: Network Time Foundation (NTF) </t>
<t> Implementers: Neta Rozen-Schiff, Danny Mayer, juergen perlinger and H
arlan Stenn.</t>
<t> Contact Martin Langer: neta.r.schiff@gmail.com</t>
<t> Maturity: in progress (https://khronos.nwtime.org/).</t>
</section> </section>
<section anchor="Precision_Security" numbered="true" toc="default">
<name>Precision vs. Security</name>
<t>Since NTPv4 updates the clock at times when no time-shifting attacks ar
e detected, the precision and accuracy of a Khronos client are the same as NTPv4
at these times.
Khronos is proved to maintain an accurate estimation of the UTC with hig
h probability. Therefore, when Khronos detects that client's clock error exceeds
a threshold (H), it considers it to be an attack and takes control over the cli
ent's clock. As a result, the time shift is mitigated and high accuracy is guara
nteed (the error is bounded by H).</t>
<t> Khronos is based on crowdsourcing across servers and regions, changes
the set of queried servers more frequently than NTPv4 <xref target="Khronos" for
mat="default"/>, and avoids some of the filters in NTPv4's system process. These
factors can potentially harm its precision. Therefore, a smoothing mechanism ca
n be used where instead of a simple average of the remaining samples, the smalle
st (in absolute value) offset is used unless its distance from the average is hi
gher than a predefined value. Preliminary experiments demonstrated promising res
ults with precision similar to NTPv4.</t>
<t>In applications such as multi-source media streaming, which are highly
sensitive to time differences among hosts, note that it is advisable to use Khro
nos at all hosts in order to obtain high precision, even in the presence of atta
ckers that try to shift each host in a different magnitude and/or direction. Ano
ther approach that is more efficient for these cases may be to allow direct time
synchronization between one host who runs Khronos to others.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="IANA" numbered="true" toc="default">
<t>The authors would like to thank Erik Kline, Miroslav Lichvar, Danny Maye <name>IANA Considerations</name>
r, Karen O'Donoghue, Dieter Sibold, Yaakov. J. Stein, Harlan Stenn, Hal Murray, <t>This document has no IANA actions.</t>
Marcus Dansarie, Geoff Huston, Roni Even, Benjamin Schwartz, Tommy Pauly, Rob Sa </section>
yre, Dave Hart and Ask Bjorn Hansen for valuable contributions </middle>
to this document and helpful discussions and comments.</t> <back>
</section> <references>
<name>References</name>
<!-- Possibly a 'Contributors' section ... --> <references>
<name>Normative References</name>
<section anchor="IANA" title="IANA Considerations"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<t>This memo includes no request to IANA.</t> 905.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</middle> 384.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<back> 033.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title="Normative References"> 915.xml"/>
&RFC5905;
&RFC7384;
&RFC7942;
&RFC8915;
<!-- A reference written by by an organization not a person. -->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor="Khronos_paper"
target="https://www.ndss-symposium.org/wp-content/uploads/2018/0
2/ndss2018_02A-2_Deutsch_paper.pdf">
<front>
<title>Preventing (Network) Time Travel with Chronos</title>
<author initials="O." surname="Deutsch">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="N" surname="Rozen-Schiff">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="D." surname="Dolev">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="M." surname="Schapira">
<organization>Hebrew University of Jerusalem</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="Ananke_paper"
target="https://www.ndss-symposium.org/wp-content/uploads/ndss20
21_1A-2_24302_paper.pdf">
<front>
<title>Preventing (Network) Time Travel with Chronos</title>
<author initials="Y." surname="Perry">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="N" surname="Rozen-Schiff">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="M." surname="Schapira">
<organization>Hebrew University of Jerusalem</organization>
</author>
<date year="2021" />
</front>
</reference>
</references> </references>
<references>
<name>Informative References</name>
<reference anchor="Khronos" target="https://www.ndss-symposium.org/wp-con
tent/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf">
<front>
<title>Preventing (Network) Time Travel with Chronos</title>
<author initials="O." surname="Deutsch">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="N." surname="Rozen-Schiff">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="D." surname="Dolev">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="M." surname="Schapira">
<organization>Hebrew University of Jerusalem</organization>
</author>
<date month="February" year="2018"/>
</front>
<seriesInfo name="DOI" value="10.14722/ndss.2018.23231"/>
<refcontent>Network and Distributed Systems Security (NDSS) Symposium,
San Diego, CA, USA</refcontent>
</reference>
</back> <reference anchor="Ananke" target="https://www.ndss-symposium.org/wp-con
tent/uploads/ndss2021_1A-2_24302_paper.pdf">
<front>
<title>A Devil of a Time: How Vulnerable is NTP to Malicious Timeser
vers?</title>
<author initials="Y." surname="Perry">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="N" surname="Rozen-Schiff">
<organization>Hebrew University of Jerusalem</organization>
</author>
<author initials="M." surname="Schapira">
<organization>Hebrew University of Jerusalem</organization>
</author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="DOI" value="10.14722/ndss.2021.24302"/>
<refcontent>Network and Distributed Systems Security (NDSS) Symposium,
Virtual</refcontent>
</reference>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Erik Kline"/>,
<contact fullname="Miroslav Lichvar"/>, <contact fullname="Danny
Mayer"/>, <contact fullname="Karen O'Donoghue"/>, <contact
fullname="Dieter Sibold"/>, <contact fullname="Yaakov. J. Stein"/>,
<contact fullname="Harlan Stenn"/>, <contact fullname="Hal Murray"/>,
<contact fullname="Marcus Dansarie"/>, <contact fullname="Geoff
Huston"/>, <contact fullname="Roni Even"/>, <contact fullname="Benjamin
Schwartz"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Rob
Sayre"/>, <contact fullname="Dave Hart"/>, and <contact fullname="Ask
Bjorn Hansen"/> for valuable contributions to this document and helpful
discussions and comments.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 36 change blocks. 
749 lines changed or deleted 694 lines changed or added

This html diff was produced by rfcdiff 1.48.