<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!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"> nbsp    "&#160;">
  <!ENTITY RFC7384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7384.xml"> zwsp   "&#8203;">
  <!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8915.xml"> 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 xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-ntp-chronos-25" ipr="trust200902"> number="9523" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.18.0 -->
  <front>
    <title abbrev="NTP Extention with Khronos">A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos</title>
    <seriesInfo name="RFC" value="9523"/>
    <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> 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 Internet. This document describes a companion application to the NTPv4 client, named Khronos, which "Khronos", that is used as a "watchdog" alongside NTPv4, NTPv4 and that provides improved security against time shifting time-shifting attacks. Khronos involves changes to the NTP 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 title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>NTPv4, as defined in RFC 5905 <xref
target="RFC5905"/>, target="RFC5905" format="default"/>, is vulnerable to time shifting attacks, time-shifting attacks in which the attacker changes (shifts) the clock of a network device. Time shifting Time-shifting attacks on NTP clients can be based on interfering with the communication between the NTP clients and servers or compromising the servers themselves. Time shifting Time-shifting attacks on NTP are possible even if NTP communication is encrypted and authenticated. A weaker machine-in-the-middle (MitM) (MITM) attacker can shift time simply by dropping or delaying packets, whereas a powerful attacker, who attacker that has full control over an NTP server, server can do so by explicitly determining the NTP response content. This document introduces a time shifting time-shifting mitigation mechanism called Khronos. "Khronos".
	 Khronos can be integrated as a background monitoring background-monitoring application ("watchdog") (watchdog) that guard guards against time shifting time-shifting attacks in any NTP client. An NTP client that runs Khronos is interoperable with <xref target="RFC5905"/>-compatible NTPv4 servers. servers that are compatible with <xref target="RFC5905" format="default"/>. The Khronos mechanism does not affect the wire mechanism and mechanism; therefore, it is therefore applicable to any current or future time protocol.</t>
      <t>Khronos is a mechanism that runs in the background, continuously monitoring the client clock (which is updated by NTPv4) and calculating an estimated offset which we refer by (referred to as the "Khronos time offset". offset"). When the offset exceeds a predefined threshold (specified in <xref
     target="attackDetection"/>), target="attackDetection" format="default"/>), this is interpreted as the client experiencing a time shifting 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 passive.  This allows NTPv4 to control the client's clock and providing provides the ordinary high precision and accuracy of NTPv4.  When under attack, Khronos takes control over of the client's clock, mitigating the time shift, shift while guaranteeing relatively high accuracy with respect to UTC and precision, as discussed in <xref target="Precision_Security"/>.</t> target="Precision_Security" format="default"/>.</t>
      <t>By leveraging techniques from distributed computing theory for time-synchronization, time synchronization, Khronos achieves accurate time even in the presence of powerful attackers 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 few 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, NTPv4 employs an algorithm which that typically relies on a small subset of the NTP server pool (e.g., 4 four servers) for time synchronization, synchronization and is much more vulnerable to time shifting time-shifting attacks. Configuring NTPv4 to use several hundreds of servers will increase its security, but will incur very high network and computational overhead compared to Khronos and will be bounded by a compromised ratio of half of the time samples.</t>
      <t>A Khronos client iteratively "crowdsources" time queries across NTP servers and applies a provably secure algorithm for eliminating "suspicious" responses and for averaging over the remaining responses. In each Khronos poll interval, 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 3 three times more servers per polling interval than NTP, Khronos's polling interval can be longer (e.g., 10 times longer) than NTPv4, thereby, thereby minimizing the load on NTP servers and the communication overhead.
	 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 local Khronos pool consists of, for example, 500 servers, 1/7 one-seventh of whom are controlled by an attacker and Khronos queries 15 servers in each Khronos poll interval (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 over 100 ms from UTC. The full exposition of the formal analysis of this guarantee is available at <xref target="Khronos_paper"/>. target="Khronos" format="default"/>. </t>

<t>Khronos introduces a watchdog mechanism that maintains a time offset value that is used (the Khronos time offset) and uses it as a reference for detecting attacks.  The This time offset value computation differs from the current NTPv4 in two key aspects. aspects:</t>

<ul><li>
      First, Khronos periodically communicates, in each Khronos poll interval, Khronos periodically communicates  with only a few (tens) randomly selected servers out of a pool consisting of a large number (e.g., hundreds) of NTP servers.
	 Second, servers.</li>
      <li>Second, Khronos computes "Khronos the Khronos time offset" offset based on an approximate agreement technique to remove outliers, thus limiting the attacker's ability to contaminate the "time samples" time samples (offsets) derived from the queried NTP servers.  These  </li>
</ul>
<t>These two aspects allow Khronos to minimize the load on the NTP servers and to 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, NTS Network Time Security (NTS) <xref target="RFC8915"/> target="RFC8915" format="default"/> could make it more challenging for attackers to perform MITM attacks, but is of little impact if the servers themselves are compromised.</t>
    </section>
    <section title="Conventions numbered="true" toc="default">
      <name>Conventions Used in This Document"> Document</name>
      <section title="Terms and Abbreviations">
        <t><list hangIndent="23" style="hanging">

  		    <t hangText="NTPv4">Network numbered="true" toc="default">
        <name>Terms and Abbreviations</name>

        <dl newline="false" spacing="normal">
          <dt>NTPv4:</dt>
          <dd>Network Time Protocol version 4 4. See <xref target="RFC5905"/>.</t>

  		    <t hangText="System process">Selection Algorithm target="RFC5905" format="default"/>.</dd>
          <dt>System process:</dt>
          <dd>See the "Selection Algorithm" and the Cluster Algorithm <xref target="RFC5905"/>.</t>

			<t hangText="Security Requirements">Security Requirements "Cluster Algorithm" sections of Time Protocols in Packet Switched Networks <xref target="RFC7384"/>.</t>

			<t hangText="NTS">Network Time Security for the Network target="RFC5905" format="default"/>.</dd>
          <dt>Security Requirements:</dt>
          <dd>See "<xref target="RFC7384" format="title"/>" <xref target="RFC7384" format="default"/>.</dd>
          <dt>NTS:</dt>
          <dd>Network Time Protocol Security.  See "<xref target="RFC8915" format="title"/>" <xref target="RFC8915"/>.</t>

		</list></t> target="RFC8915" format="default"/>.</dd>
        </dl>
      </section>
      <section title="Notations">
       <texttable anchor="table_example" title="Khronos Notations">
         <preamble>Describing numbered="true" toc="default">
        <name>Notations</name>
        <t keepWithNext="true">When describing the Khronos algorithm, the following notation is used.</preamble>

         <ttcol align="center">Notation</ttcol>

         <ttcol align="left">Meaning</ttcol>

         <c>n </c>

         <c>The used:</t>

        <table anchor="table_example" align="center">
          <name>Khronos Notation</name>
          <thead>
            <tr>
              <th align="center">Notation</th>
              <th align="left">Meaning</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">n </td>
              <td align="left">The number of candidate servers in a Khronos pool (potentially hundreds). </c>

         <c>m </c>

         <c>The </td>
            </tr>
            <tr>
              <td align="center">m </td>
              <td align="left">The number of servers that Khronos queries in each poll interval (up to tens). </c>

         <c>w </c>

         <c>An </td>
            </tr>
            <tr>
              <td align="center">w </td>
              <td align="left">An upper bound on the distance between any "truechimer" NTP server (as in <xref target="RFC5905"/>) target="RFC5905" format="default"/>) and UTC.</c>

         <c>B </c>

         <c>An UTC.</td>
            </tr>
            <tr>
              <td align="center">B </td>
              <td align="left">An upper bound on the client's clock error rate (ms/sec). </c>

         <c>ERR  </c>

         <c>An </td>
            </tr>
            <tr>
              <td align="center">ERR  </td>
              <td align="left">An upper bound on the client's clock error between Khronos polls (ms).</c>

         <c>K  </c>

         <c>The (ms).</td>
            </tr>
            <tr>
              <td align="center">K  </td>
              <td align="left">The number of Khronos pool re-samplings resamplings until reaching "Panic mode".</c>

		 <c>H  </c>

         <c>Predefined "panic mode".</td>
            </tr>
            <tr>
              <td align="center">H  </td>
              <td align="left">Predefined threshold for a Khronos time offset triggering clock update by Khronos.</c>

         <postamble></postamble>
       </texttable> Khronos.</td>
            </tr>
          </tbody>
        </table>
        <t keepWithPrevious="true"/>
        <t>The recommended values are discussed in <xref target="values"/>.</t> target="values" format="default"/>.</t>
      </section>
    </section>
    <section title="Khronos Design"> numbered="true" toc="default">
      <name>Khronos Design</name>
      <t>Khronos watchdog periodically queries a set of m (tens) servers from a large (hundreds) server pool in each Khronos poll interval, where the m servers are selected 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 should be around 10 times the NTPv4 poll interval (i.e., a Khronos clock update occurs once every 10 NTPv4 clock updates). In each Khronos poll interval, if the Khronos time offset exceeds a predetermined threshold (denoted as H), an attack is indicated.</t>
      <t> Unless an attack is indicated, Khronos uses only one sample from each server (avoiding the "Clock Filter Algorithm" as defined in section 10 in <xref target="RFC5905"/>). target="RFC5905" sectionFormat="of" section="10"/>). When under attack, Khronos uses several samples from each server, server and executes the "Clock Filter Algorithm" for choosing the best sample from each server, server with low jitter. Then, given a sample from each server, Khronos discards outliers by executing the procedure described in <xref target="Conditions"/>.</t> target="Conditions" format="default"/>.</t>
      <t>Between consecutive Khronos polls, Khronos keeps track of clock offsets, for example e.g., by catching clock discipline (as in <xref target="RFC5905"/>) target="RFC5905" format="default"/>) calls. The sum of offsets is referred to as the "Khronos inter-poll offset" (denoted as tk) tk), which is set to zero after each Khronos poll.</t>
      <section title="Khronos numbered="true" toc="default">
        <name>Khronos Calibration - Gathering the Khronos Pool"> Pool</name>

<t>Calibration is performed at the first time the Khronos is executed, executed and also periodically, once in a long time (every periodically thereafter (once every two weeks). The calibration process generates a local Khronos pool of n (up to hundreds) NTP servers that the client can synchronize with.
To this end, Khronos makes multiple DNS queries to addresses of NTP pools collect the union NTP pools. Each query returns a few NTP server IPs that Khronos combines into one set of all received IP addresses. IPs considered as the Khronos pool.
The servers in the Khronos pool should be scattered across different regions to make it harder for an attacker to compromise, compromise or gain machine-in-the-middle capabilities, MITM capabilities with respect to a large fraction of the Khronos pool. Therefore, Khronos calibration queries general NTP server pools (for example pool.ntp.org), (e.g., pool.ntp.org) and not only just the pool in the client's state or region.

In addition, servers can be selected to be part of the Khronos pool manually or by using other NTP pools (such as NIST internet Internet time servers).</t>
        <t>The first Khronos update requires m servers, which can be found in several minutes. Moreover, it is possible to query several DNS pool names to vastly accelerate the calibration and the first update.</t>
        <t>The calibration is the only Khronos part where DNS traffic is generated. Around 125 DNS queries are required by Khronos to obtain addresses of 500 NTP servers 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" title="Khronos's numbered="true" toc="default">
        <name>Khronos's Poll and System Processes"> Processes</name>
        <t>In each Khronos poll interval interval, the Khronos system process randomly chooses 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 for the security of the scheme and therefore scheme; therefore, any Khronos implementation must use a secure randomness implementation such as what is used for encryption key generation. </t>
        <t> Khronos's polling times of different servers may spread uniformly within its poll interval, which is similar to NTPv4. Servers which that do not respond during the Khronos poll interval are filtered out. If less than 1/3 one-third of the m servers are left, a new subset of servers is immediately sampled, sampled in the exact same manner (called (which is called the "resampling" process).</t>
        <t>Next, out of the time-samples time samples received from this chosen subset of servers, the lowest third of the samples' offset values and the highest third of the samples' offset values are discarded.</t>
        <t>Khronos checks that the following two conditions hold for the remaining sampled offsets: offsets (considering w and ERR defined in <xref target="table_example" format="default"/>): </t>
        <t><list style="symbols">
            <t>The
        <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).</t>
            <t>The offsets).</li>
          <li>The distance between the offsets offset's average and the Khronos inter-poll offset is ERR+2w at most ERR+2w.</t>
        </list> </t> most.</li>
        </ul>
<t> (where w and ERR are as described in <xref target="table_example"/>).</t>

     <t>In
   In the event that both of these conditions are satisfied, the average of
   the offsets is set to be the "Khronos Khronos time offset". offset. Otherwise, resampling is
   performed. This process spreads the Khronos client's queries across servers
   servers, thereby improving security against powerful attackers (as
   discussed in <xref target="Security_analysis"/>) 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 re-sampled resampled exceeds a "Panic Trigger" "panic trigger" (K in <xref target="table_example"/>), in which case
   target="table_example" format="default"/>). In this case, Khronos enters a "Panic Mode".</t>
   panic mode.</t>

        <t>In panic mode, Khronos queries all the servers in its local Khronos pool, orders the collected time samples from lowest to highest highest, and eliminates the lowest third and the highest third of the samples. The client then averages over calculates the average of the remaining samples, samples and sets this average to be the new "Khronos Khronos time offset".</t> offset.</t>
        <t>If the Khronos time offset exceeds a predetermined threshold (H) (H), it is passed on to the clock discipline algorithm in order to steer the system time (as in <xref target="RFC5905"/>). target="RFC5905" format="default"/>). In this case case, the user and/or admin of the client machine should be notified about the detected time shifting time-shifting attack, for example e.g., by a message written to a relevant event log or displayed on screen.</t>

        <t> Note that resampling follows immediately follows the previous sampling
        since waiting until the next polling interval may increase the time
        shift in face of an attack. This shouldn't generate high overhead
        since the number of resamples is bounded by K (after K resamplings, "Panic mode"
        panic mode is in place) and the chances to arrive to of ending up with repeated
        resampling are low (see <xref target="Security"/> target="Security" format="default"/> for
        more details). Moreover, in an interval following a panic mode,
        Khronos executes the same system process which that starts by querying only
        m servers (regardless of previous panic).</t>
      </section>
      <section anchor="values" title="Khronos's numbered="true" toc="default">
        <name>Khronos's Recommended Parameters"> Parameters</name>
        <t>According to empirical observations (presented in <xref target="Khronos_paper"/>), target="Khronos" format="default"/>), querying 15 servers at each poll interval (i.e., m=15) out of 500 servers (i.e., n=500), n=500) and setting w to be around 25 ms provides both high time accuracy and good security. Specifically, when selecting w=25ms, w=25 ms, approximately 83% of the servers' clocks are are, at most w-away most, w away from UTC, UTC and within 2w from each other, satisfying the first condition of Khronos's system process. For a similar reason, the threshold for a Khronos time offset triggering a clock update by Khronos (H) should be between w to 2w and is selected on 2w; the default to 30ms. is 30 ms.	Note that in order to support scenarios with congested links scenarios, it is recommended to use links, using a higher w value, such as 1 sec.</t> second, is recommended.</t>

<t>Furthermore, according to Khronos security analysis, setting K to be 3 (i.e., if after 3 re-samplings  the two conditions are not satisfied after three resamplings, then Khronos enters "panic mode") panic mode) is safe when facing time shifting time-shifting attacks.  In addition, the probability of an attacker forcing a panic mode on a client when K equals 3, K=3 is negligible (less than 0.000002 for each polling interval).</t>
        <t>Khronos's effect on precision and accuracy are discussed in Sections <xref target="Precision_Security"/> target="Security" format="counter"/> and <xref target="Security"/>. target="Precision_Security" format="counter"/>. </t>
      </section>
    </section>
    <section anchor="operational" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t> Khronos is designed in order to defend NTP clients from time shifting time-shifting attacks while using public NTP servers.  As such, Khronos is not applicable for datacenters data centers and enterprises which that synchronize with local atomic clocks, GPS devices devices, or a dedicated NTP server (for example (e.g., due to regulations).</t>

<t> Khronos can be used for devices that require and depend upon time keeping withing timekeeping within a configurable constant distance from UTC.</t>
      <section anchor="Security vs. load considerations" title="Load considerations"> anchor="Security_vs._load_considerations" numbered="true" toc="default">
        <name>Load Considerations</name>
        <t>One requirement from Khronos is thus not to induce excessive load on NTP servers beyond that of NTPv4, even if it is widely integrated into NTP clients. We discuss below the possible causes for a Khronos-induced load on servers and how this can be mitigated.</t>
        <t>Servers in pool.ntp.org are weighted differently by the NTP server pool when assigned to NTP clients. Specifically, server owners define a ``server weight'' "server weight" (the ``netspeed'' "netspeed" parameter) and servers are assigned to clients probabilistically according to their proportional weight. Khronos (watchdog mode) Khronos's queries are equally distributed across a pool of servers. To avoid overloading servers, Khronos queries servers less frequently than NTPv4, with the Khronos query interval set 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 load (in terms of multiplicative increase in queries or number of bytes per second) is controlled by the poll interval configuration configuration, which was analyzed in <xref target="Ananke_paper"/>.</t>

   <t> Consider target="Ananke" format="default"/>.</t>
        <t>Consider the scenario where an attacker attempts to generate significant load on NTP servers by triggering multiple consecutive panic modes at multiple NTP clients. We note that to accomplish this, the attacker must have man-in-the-middle MITM capabilities with respect to the communication between each and every client in a large group of clients and a large fraction of all NTP servers in the queried 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 wide-scale attack (e.g., on BGP or DNS) and thereby DNS); thereby, it is capable to carry of carrying similar and even higher impact attacks regardless of Khronos clients.</t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="threatModel" title="Threat Model">
    <t> The following powerful attacker, including MitM, is considered: the attacker is assumed to control numbered="true" toc="default">
        <name>Threat Model</name>

        <t>The threat model encompasses a broad spectrum of attackers impacting a subset (e.g., third) one-third) of the servers in NTP pools and is capable of fully determining the values of the time samples returned by these NTP servers. The threat model encompasses a broad spectrum of attackers, ranging pools. These attackers can range from a fairly weak (yet dangerous) MitM attackers MITM attacker that is only capable of delaying and dropping packets (for example (e.g., using the Bufferbloat attack) attack <xref target="RFC8033"/>) to an extremely powerful attackers attacker who are is in control of (even authenticated) NTP servers and is capable of fully determining the values of the time samples returned by these NTP servers (see detailed security requirements attacker discussion in <xref target="RFC7384"/>).</t>

	<t> The target="RFC7384" format="default"/>).</t>

<t>For example, the attackers covered by this model might be, for example, (1) in be:</t>
<ol><li>in direct control of a fraction of the NTP servers (e.g., by exploiting a software vulnerability), (2) an vulnerability),</li>
<li>an ISP (or other Autonomous-System-level attacker) attacker at the Autonomous System level) on the default BGP paths from the NTP client to a fraction of the available servers, (3) a servers,</li>
<li>a nation state with authority over the owners of NTP servers in its jurisdiction, or (4) an or</li>
<li>an attacker capable of hijacking (e.g., through DNS cache poisoning or BGP prefix hijacking) traffic to some of the available NTP servers. The 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 attacker has adversarial capabilities.
	Attackers that can impact communications with (or control) a higher fraction of the servers, for example servers (e.g., all servers, servers) are out of scope.
Considering the pool size across the world to be thousands across in the world, thousands, such attackers will most probably likely be capable of performing creating far worst worse damage than time shifting. time-shifting attacks. </t>
<t> Notably, Khronos provides protection from MitM MITM and powerful attacks that cannot be achieved by cryptographic authentication protocols since since, even with such measures in place place, an attacker can still influence time by dropping/delaying packets. However, adding an authentication layer (e.g., NTS <xref target="RFC8915"/>) target="RFC8915" format="default"/>) to Khronos will enhance its security guarantees and enable the detection of various spoofing and modification attacks.</t>
        <t> Moreover, Khronos uses randomness to independently select the queried servers in each poll interval, preventing attackers from exploiting observations of past server selections.
        </t>
      </section>
      <section anchor="attackDetection" title="Attack Detection"> 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 offset computed by Khronos and checking whether the offset exceeds a predetermined threshold (H). Unless an attack was detected, NTPv4 controls the client's clock. clock unless an attack was detected. Under attack, Khronos takes control over the clients client's clock in order to prevent its shift.</t>
        <t>Analytical results (in <xref target="Khronos_paper"/>) target="Khronos" format="default"/>) indicate that if a local Khronos pool consists of 500 servers, 1/7 one-seventh of whom are controlled by a machine-in-the-middle MITM attacker, and 15 of those servers are queried in each Khronos poll interval, then success in shifting time of a Khronos client by even a small degree (100 ms), 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 numbered="true" toc="default">
        <name>Security Analysis Overview">
     <t>Time-samples 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>
     <t><list style="symbols">
     <t>Less
        <ul spacing="normal">
          <li>Scenario A: Less than 2/3 two-thirds of the queried servers are under the attacker's control.</t>
     <t>The control.</li>
          <li>Scenario B: The attacker controls more than 2/3 two-thirds of the queried servers.</t>
     </list></t>

     <t>The first scenario, where there are more than 1/3 good samples, servers.</li>
        </ul>
        <t>Scenario A consists of two sub-cases: (i) there sub-cases:</t>
	<ol>
	  <li>There is at least one good sample in the set of samples not eliminated by Khronos (in the middle third of samples), and (ii) there and</li>
	  <li>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 Khronos), 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 (for otherwise, (otherwise, the first condition of Khronos's system process in <xref target="Conditions"/> target="Conditions" format="default"/> is violated and a new set of servers is chosen). This implies that the average of the remaining samples must be close to UTC. In the second UTC.</t>
<t>In sub-case (where there are no good samples in the set of remaining samples), 2, since more than a third of the initial samples were
   good, both the (discarded) third lowest-value third-lowest-value samples and the
   (discarded) third highest-value 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>In the second scenario, where the attacker controls more than 2/3 of the queried servers, Scenario B, the worst possibility for the client is that all remaining
samples are malicious (i.e., more than w away from UTC).  However, as proved
in <xref target="Khronos_paper"/>, target="Khronos" format="default"/>, the probability of this scenario
is extremely low low, even if the attacker controls a large fraction (e.g., 1/4)
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 single-shift probabilities.  Such ratios are provided in Table <xref target="improvement_ratio"/>,
target="improvement_ratio" format="default"/>, where higher values indicate
higher improvement of Khronos over NTPv4 and are also proportional to the
expected time till until a time shift time-shift attack succeeds once. </t>

	<texttable once.</t>

        <t keepWithNext="true"/>
        <table anchor="improvement_ratio" title="Khronos Improvement">
         <preamble></preamble>

         <ttcol align="center">
          <name>Khronos Improvement</name>
          <thead>
            <tr>
              <th align="center">Attack Ratio</ttcol>
		 <ttcol Ratio</th>
              <th align="center">6 samples</ttcol>
         <ttcol Samples</th>
              <th align="center">12 samples</ttcol>
		 <ttcol Samples</th>
              <th align="center">18 samples</ttcol>
		 <ttcol Samples</th>
              <th align="center">24 samples</ttcol>
		 <ttcol Samples</th>
              <th 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> 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 clients to enter a panic mode (and query querying all the servers in their local Khronos pools). This probability (with the previous parameters of n=500, m=15, w=25 w=25, and K=3) is negligible even for an attacker who controls a large number of servers in client's clients' local Khronos pools, and it is expected to take decades to force a panic mode. </t>
        <t>Further details about Khronos's security guarantees can be found in <xref target="Khronos_paper"/>.</t> target="Khronos" format="default"/>.</t>
      </section>
    </section>
   <section anchor="Pseudocode" numbered="true" toc="default">
      <name>Khronos Pseudocode</name>

<!-- This PI places
this is incorrect, please see below for further guidance:

If the pagebreak correctly (before current list of preferred values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
contain an applicable type, then feel free to let us know. Also, it is
acceptable to leave the section title) in "type" attribute not set.

c) Please review the text output. following line as it exceeds our character limit.
Please let us know how we can update.

Original:
S = sample(m) //gather samples from (tens of) randomly chosen servers

Perhaps:
S = sample(m) //get samples from (tens of) randomly chosen servers
-->

   <section anchor="Pseudocode"
            title="Khronos Pseudocode">
     <figure>
       <preamble>The

      <t keepWithNext="true">The pseudocode for Khronos Time Sampling Scheme, which is invoked in each Khronos poll interval interval, is as follows:</preamble>

       <artwork><![CDATA[ follows:</t>
      <sourcecode type="pseduocode">
counter = 0
S = []
T = []
While counter < &lt; K do
   S = sample(m) //gather //get samples from (tens of) randomly chosen servers
   T = bi_side_trim(S,1/3) //trim lowest and highest thirds
   if (max(T) - min(T) <= &lt;= 2w) and (|avg(T) - tk| < &lt; ERR + 2w) Then 2w), then
       return avg(T) // Normal case
   end
   counter ++
end
// panic mode
S = sample(n)
T = bi-sided-trim(S,1/3) //trim lowest and highest thirds
return avg(T)

           ]]></artwork>
     </figure>
</sourcecode>
<t>Note that if clock disciplines can be called during this pseudocode's execution, then each time offset sample, as well as the final output (Khronos time offset), should be normalized with the sum of the clock disciplines offsets (tk) at the time of computing it.</t>
    </section>
    <section anchor="Precision_Security" title="Precision numbered="true" toc="default">
      <name>Precision vs. Security"> Security</name>
      <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 NTPv4 at these times.
	 Khronos is proved to maintain an accurate estimation of the UTC with high probability. Therefore Therefore, when Khronos detects that client's clock error exceeds a threshold (H), it considers it as to be an attack and takes control over the client's clock. As a result, the time shift is mitigated and high accuracy is guaranteed (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_paper"/>, target="Khronos" format="default"/>, 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, used where instead of a simple average of the remaining samples, the smallest (in absolute value) offset is used unless its distance from the average is higher than a predefined value. Preliminary experiments demonstrated promising results with precision similar to NTPv4.</t>

	 <t> Note that in
      <t>In applications such as multi source multi-source media streaming, which are highly sensitive to time differences among hosts, note that it is advisable to use Khronos at all hosts in order to obtain high precision precision, even in the presence of attackers that try to shift each host in a different magnitude and/or direction. Another approach that is more efficient approach for this these cases may be to allow direct time synchronization 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 protocol 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 does 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 working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual 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 Cohen </t>
	<t> Maturity: Proof-of-Concept Prototype</t>
    <t> This implementation was used to check consistency and to ensure completeness 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 Harlan 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="Acknowledgements" title="Acknowledgements">
     <t>The authors would like to thank Erik Kline, Miroslav Lichvar, Danny Mayer, Karen O'Donoghue, Dieter Sibold, Yaakov. J. Stein, Harlan Stenn, Hal Murray, Marcus Dansarie, Geoff Huston, Roni Even, Benjamin Schwartz, Tommy Pauly, Rob Sayre, Dave Hart and Ask Bjorn Hansen for valuable contributions
   to this document and helpful discussions and comments.</t>
   </section>

   <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes document has no request to IANA.</t> IANA actions.</t>
    </section>
  </middle>
  <back>

   <references title="Normative References">

     &RFC5905;

	 &RFC7384;

	 &RFC7942;

	 &RFC8915;

     <!-- A reference written by by an organization not a person. -->
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8033.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"/>

   </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->
      <references>
        <name>Informative References</name>
	<reference anchor="Khronos_paper" anchor="Khronos" target="https://www.ndss-symposium.org/wp-content/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" 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" /> 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>

        <reference anchor="Ananke_paper" anchor="Ananke" target="https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf">
          <front>
         <title>Preventing (Network) Time Travel with Chronos</title>
            <title>A Devil of a Time: How Vulnerable is NTP to Malicious Timeservers?</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" /> 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>