draft-ietf-ntp-chronos-01.txt   draft-ietf-ntp-chronos-02.txt 
Network Working Group N. Rozen-Schiff Network Working Group N. Rozen-Schiff
Internet-Draft D. Dolev Internet-Draft D. Dolev
Intended status: Informational Hebrew University of Jerusalem Intended status: Informational Hebrew University of Jerusalem
Expires: March 7, 2021 T. Mizrahi Expires: August 25, 2021 T. Mizrahi
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
M. Schapira M. Schapira
Hebrew University of Jerusalem Hebrew University of Jerusalem
September 3, 2020 February 21, 2021
A Secure Selection and Filtering Mechanism for the Network Time Protocol A Secure Selection and Filtering Mechanism for the Network Time Protocol
Version 4 draft-ietf-ntp-chronos-02
draft-ietf-ntp-chronos-01
Abstract Abstract
The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905,
is the mechanism used by NTP clients to synchronize with NTP servers is the mechanism used by NTP clients to synchronize with NTP servers
across the Internet. This document specifies an extension to the across the Internet. This document specifies an extension to the
NTPv4 client, named Chronos, which is used as a "watchdog" alongside NTPv4 client, named Chronos, which is used as a "watchdog" alongside
NTPv4, and provides improved security against time shifting attacks. NTPv4, and provides improved security against time shifting attacks.
Chronos involves changes to the NTP client's system process only and Chronos involves changes to the NTP client's system process only and
is backwards compatible with NTPv4 servers. is backwards compatible with NTPv4 servers. Chronos is also
compatible with NTPv5, since it does not affect the wire protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2021. This Internet-Draft will expire on August 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4
2.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extension to the NTP System Process . . . . . . . . . . . . . 4 3. Extension to the NTP System Process . . . . . . . . . . . . . 5
3.1. Chronos' System Process . . . . . . . . . . . . . . . . . 5 3.1. Chronos' System Process . . . . . . . . . . . . . . . . . 6
4. Chronos' Pseudocode . . . . . . . . . . . . . . . . . . . . . 6 3.2. Chronos' Recommended Parameters . . . . . . . . . . . . . 7
5. Precision vs. Security . . . . . . . . . . . . . . . . . . . 7 4. Chronos' Pseudocode . . . . . . . . . . . . . . . . . . . . . 7
6. Chronos' Threat Model and Security Guarantees . . . . . . . . 7 5. Precision vs. Security . . . . . . . . . . . . . . . . . . . 8
6.1. Security Analysis Overview . . . . . . . . . . . . . . . 8 6. Chronos' Threat Model and Security Guarantees . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Security Analysis Overview . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
NTPv4, as defined in RFC 5905 [RFC5905], is vulnerable to time NTPv4, as defined in RFC 5905 [RFC5905], is vulnerable to time
shifting attacks, in which the attacker's goal is to shift the local shifting attacks, in which the attacker's goal is to shift the local
time at an NTP client. See [Chronos_paper] for details. Time time at an NTP client. See [Chronos_paper] for details. Time
shifting attacks on NTP are possible even if all NTP communications shifting attacks on NTP are possible even if NTP communication is
are encrypted and authenticated. This document introduces an encrypted and authenticated. A weaker man-in-the-middle (MitM)
improved system process that incorporates an algorithm called attacker can shift time simply by dropping or delaying packets,
Chronos. Chronos is backwards compatible with NTPv4 and serves as an whereas a powerful attacker, who has full control over an NTP server,
NTPv4 client's "watchdog" for time shifting attacks. An NTP client can determine the response content. This document introduces a time
that runs Chronos is interoperable with [RFC5905]-compatible NTPv4 shifting mitigation mechanism called Chronos. Chronos is backwards
servers. compatible with NTPv4 and serves as an NTPv4 client's "watchdog" for
time shifting attacks. An NTP client that runs Chronos is
interoperable with [RFC5905]-compatible NTPv4 servers. Chronos is
also compatible with NTPv5, since it does not affect the wire
protocol.
Chronos is a background mechanism that continuously maintains a Chronos is a background mechanism that continuously maintains a
virtual "Chronos" clock update and compares it to NTPv4's clock virtual "Chronos" clock update and compares it to NTPv4's clock
update. When the gap between the two updates exceeds a certain update. When the gap between the two updates exceeds a certain
threshold (specified in Section 6), this is interpreted as the client threshold (specified in Section 6), this is interpreted as the client
experiencing a time shifting attack. In this case, Chronos is used experiencing a time shifting attack. In this case, Chronos is used
to update the client's clock, and NTPv4 is operated in the background to update the client's clock, and NTPv4 is operated in the background
until the gap between NTPv4 and Chronos' updates are again below this until the gap between NTPv4 and Chronos' updates are again below this
threshold, and hence NTPv4 is safe to use again. threshold, and hence NTPv4 is safe to use again.
Due to Choronos operating in the background, the client clock's Due to Chronos operating in the background, the client clock's
precision and accuracy are precisely as in NTPv4 while not precision and accuracy are precisely as in NTPv4 while not
experiencing a time-shifting attack. When under attack, Chronos experiencing a time-shifting attack. When under attack, Chronos
prevents the clock from being shifted by the attacker, thus still prevents the clock from being shifted by the attacker, thus still
preserving high accuracy and precision (as discussed in Section 6). preserving high accuracy and precision (as discussed in Section 6).
Chronos achieves accurate synchronization even in the presence of Chronos achieves accurate synchronization even in the presence of
powerful attackers who are in direct control of a large number of NTP powerful attackers who are in direct control of a large number of NTP
servers: up to 1/3 of the servers in the pool (where the pool may servers: up to 1/3 of the servers in the pool (where the pool may
consist of hundreds or even thousands of servers). NTPv4 chooses a consist of hundreds or even thousands of servers). NTPv4 chooses a
small subset of the NTP server pool (e.g. 4 servers), and small subset of the NTP server pool (e.g. 4 servers), and
skipping to change at page 3, line 34 skipping to change at page 3, line 38
given poll interval, Chronos is bound to detect the attack within a given poll interval, Chronos is bound to detect the attack within a
relatively small number of poll intervals. relatively small number of poll intervals.
A Chronos client iteratively "crowdsources" time queries across NTP A Chronos client iteratively "crowdsources" time queries across NTP
servers and applies a provably secure algorithm for eliminating servers and applies a provably secure algorithm for eliminating
"suspicious" responses and for averaging over the remaining "suspicious" responses and for averaging over the remaining
responses. Chronos is carefully engineered to minimize communication responses. Chronos is carefully engineered to minimize communication
overhead so as to avoid overloading NTP servers. Chronos' security overhead so as to avoid overloading NTP servers. Chronos' security
was evaluated both theoretically and experimentally with a prototype was evaluated both theoretically and experimentally with a prototype
implementation. These evaluation results indicate that in order to implementation. These evaluation results indicate that in order to
successfully shift time at a Chronos client by over 100ms from the successfully shift time at a Chronos client by over 100 milliseconds
UTC, even a powerful man-in-the-middle attacker requires over 20 from the UTC, even a powerful man-in-the-middle attacker requires
years of effort in expectation. The full paper is available at over 20 years of effort in expectation. The full paper is available
[Chronos_paper]. at [Chronos_paper].
Chronos introduces a watchdog mechanism that is added to the client's Chronos introduces a watchdog mechanism that is added to the client's
system process and maintains a virtual clock value that is used as a system process and maintains a virtual clock value that is used as a
reference for detecting attacks. The virtual clock value computation reference for detecting attacks. The virtual clock value computation
differs from the current NTPv4 in two key aspects. First, a Chronos differs from the current NTPv4 in two key aspects. First, a Chronos
client relies on a large number of NTP servers, from which only few client relies on a large number of NTP servers, from which only few
servers to synchronize with are periodically chosen at random, in servers to synchronize with are periodically chosen at random, in
order to avoid overloading the servers. Second, the selection order to avoid overloading the servers. Second, the selection
algorithm of the virtual clock uses an approximate agreement algorithm of the virtual clock uses an approximate agreement
technique to remove outliers, thus limiting the attacker's ability to technique to remove outliers, thus limiting the attacker's ability to
skipping to change at page 4, line 21 skipping to change at page 5, line 4
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terms and Abbreviations 2.2. Terms and Abbreviations
NTPv4 Network Time Protocol version 4 [RFC5905]. NTPv4 Network Time Protocol version 4 [RFC5905].
Selection process Clock filter algorithm and system process Selection process Clock filter algorithm and system process
[RFC5905]. [RFC5905].
2.3. Notations 2.3. Notations
Describing Chronos algorithm, the following notation are used. Describing Chronos algorithm, the following notation are used.
+---------+---------------------------------------------------------+ +----------+--------------------------------------------------------+
| Notaion | Meaning | | Notation | Meaning |
+---------+---------------------------------------------------------+ +----------+--------------------------------------------------------+
| n | The number of candidate servers in the pool that | | n | The number of candidate servers in the pool that |
| | Chronos can query (potentially hundreds) | | | Chronos can query (potentially hundreds) |
| m | The number of servers that NTPv4 queries in each poll | | m | The number of servers that NTPv4 queries in each poll |
| | interval (up to tens) | | | interval (up to tens) |
| w | An upper bound on the distance of the local time from | | w | An upper bound on the distance of the local time from |
| | the UTC at any NTP server with an accurate clock | | | the UTC at any NTP server with an accurate clock |
| | (termed "truechimer" in [RFC5905]) | | | (termed "truechimer" in [RFC5905]) |
| Cest | The client's estimation for the time that has passed | | Cest | The client's estimation for the time that has passed |
| | since its last synchronization to the server pool (sec) | | | since its last synchronization to the server pool |
| B | An upper bound on the client's time estimation error | | | (sec) |
| | (ms/sec) | | B | An upper bound on the client's time estimation error |
| ERR | An upper bound on the client's error regarding his | | | (ms/sec) |
| | estimation of the time passed from the last update, | | ERR | An upper bound on the client's error regarding his |
| | equals to B*Cest (ms) | | | estimation of the time passed from the last update, |
| K | Panic trigger | | | equals to B*Cest (ms) |
| tc | The current time [sec], as indicated by the virtual | | K | Panic trigger - the number of pool re-sampling until |
| | clock value that is computed by Chronos | | | reaches "Panic mode"; |
+---------+---------------------------------------------------------+ | tc | The current time [sec], as indicated by the virtual |
| | clock value that is computed by Chronos |
+----------+--------------------------------------------------------+
Table 1: Chronos Notations Table 1: Chronos Notations
The recommended values are discussed in Section 3.2.
3. Extension to the NTP System Process 3. Extension to the NTP System Process
A client that runs Chronos as a watchdog, uses NTPv4 as in [RFC5905], A client that runs Chronos as a watchdog, uses NTPv4 as in [RFC5905]
and in the background runs a modification to the elements of the and in the background runs a modification to the elements of the
system process described in Section 11.2.1 and 11.2.2 in [RFC5905] system process described in Section 11.2.1 and 11.2.2 in [RFC5905]
(namely, the Selection Algorithm and the Cluster Algorithm). The (namely, the Selection Algorithm and the Cluster Algorithm). The
NTPv4 conventional protocol periodically queries m servers in each NTPv4 conventional protocol periodically queries m servers in each
poll interval. In parallel the Chronos watchdog periodically queries poll interval. In parallel the Chronos watchdog periodically queries
a (variable) set of m servers in each Chronos poll interval. a (variable) set of m servers in each Chronos poll interval.
Specifically, in Chronos, after executing the clock filter algorithm Specifically, in Chronos, after executing the "Clock Filter
as defined in Section 10 in [RFC5905], the client discards outliers Algorithm" as defined in Section 10 in [RFC5905], the client discards
by executing the procedure described in this section and the next. outliers by executing the procedure described in this section and the
Then, the NTPv4 Combine Algorithm is used for computing the system next. Then, the NTPv4 "Combine Algorithm" is used for computing the
peer offset, as specified in Section 11.2.3 in [RFC5905]. In each system peer offset, as specified in Section 11.2.3 in [RFC5905]. In
poll interval the Chronos virtual clock value is compared with the each poll interval the Chronos virtual clock value is compared with
NTPv4 clock value, and if the difference exceeds a predetermined the NTPv4 clock value, and if the difference exceeds a predetermined
value, an attack is detected. value, an attack is detected. This process holds also for Chronos as
a watchdog of future NTPv5.
3.1. Chronos' System Process 3.1. Chronos' System Process
At the first time the Chronos system process is executed, calibration At the first time the Chronos system process is executed, calibration
is needed. The calibration process generates a local pool of servers is needed. The calibration process generates a local pool of servers
the client can synchronize with, consisting of n servers (up to the client can synchronize with, consisting of n servers (up to
hundreds). To this end, the NTP client executes the peer process and hundreds). To this end, the NTP client executes the "Peer Process"
clock filter algorithm as in Sections 9,10 in [RFC5905] and "Clock Filter Algorithm" as in Sections 9,10 in [RFC5905]
(respectively), on an hourly basis, for 24 consecutive hours, and (respectively), on an hourly basis, for 24 consecutive hours, and
generates the union of all received NTP servers' IP addresses. generates the union of all received NTP servers' IP addresses.
Importantly, this process can also be executed in the background Importantly, this process can also be executed in the background
periodically, once in a long time (e.g., every few weeks/months). periodically, once in a long time (e.g., every few weeks/months).
In each Chronos poll interval the Chronos system process randomly In each Chronos poll interval the Chronos system process randomly
chooses a set of m servers (where n with magnitude of hundreds and m chooses a set of m servers (where n with magnitude of hundreds and m
of tens) out of the local pool of n servers. Then, out of the time- of tens) out of the local pool of n servers. Then, out of the time-
samples received from this chosen subset of servers, a third of the samples received from this chosen subset of servers, a lowest third
samples with the lowest offset value and a third of the samples with of the samples' offset values and highest third of the samples'
the highest offset value are discarded. offset values are discarded.
Chronos checks that the following two conditions hold for the Chronos checks that the following two conditions hold for the
remaining samples: remaining samples:
o The maximal distance between every two time samples does not o The maximal distance between every two time samples does not
exceed 2w. exceed 2w.
o The average value of the remaining samples is at distance at most o The average value of the remaining samples is at distance at most
ERR+2w from the client's local clock (as computed by Chronos). ERR+2w from the client's local clock (as computed by Chronos).
(where w, ERR are as described in Table 1. Notice that ERR magnitude (where w, ERR are as described in Table 1. Notice that ERR magnitude
is approximately LAMBDA as defined in [RFC5905]). is approximately LAMBDA as defined in [RFC5905]).
In the event that both of these conditions are satisfied, the average In the event that both of these conditions are satisfied, the average
of the remaining samples is the "final offset". Otherwise, a random of the remaining samples is the "final offset". Otherwise, a random
partial of the interval is chosen, after which Chronos a new subset partial of the interval is chosen, after which a new subset of
of servers is sampled, in the exact same manner. This way, Chronos servers is sampled, in the exact same manner. This way, Chronos
client queries are spread across the time interval better in case of client queries are spread across the time interval better in case of
DoS atack on the NTP servers. This resampling process continues in DoS attack on the NTP servers. This resampling process continues in
subsequent Chronos poll intervals until the two conditions are both subsequent Chronos poll intervals until the two conditions are both
satisfied or the number of times the servers are re-sampled exceeds a satisfied or the number of times the servers are re-sampled exceeds a
"Panic Trigger" (K in Table 1), in which case, Chronos enters a "Panic Trigger" (K in Table 1), in which case, Chronos enters a
"Panic Mode". Note that it is configurable whether the client allows "Panic Mode". Note that it is configurable whether the client allows
panic mode or not. panic mode or not.
In panic mode, Chronos queries all the servers in the local server In panic mode, Chronos queries all the servers in the local server
pool, orders the collected time samples from lowest to highest and pool, orders the collected time samples from lowest to highest and
eliminates the bottom third and the top third of the samples. The eliminates the bottom third and the top third of the samples. The
client then averages over the remaining samples, and sets this client then averages over the remaining samples, and sets this
average to be the new "final offset". average to be the new "final offset".
As in [RFC5905], the final offset is passed on to the clock As in [RFC5905], the final offset is passed on to the clock
discipline algorithm for the purpose of steering the Chronos virtual discipline algorithm for the purpose of steering the Chronos virtual
clock to the correct time. The Chronos virtual clock is then clock to the correct time. The Chronos virtual clock is then
compared to the NTPv4 clock as part of the watchdog process. compared to the NTPv4 (or to the future NTPv5) clock as part of the
watchdog process.
3.2. Chronos' Recommended Parameters
According to empirical observations (presented in [Chronos_paper]), According to empirical observations (presented in [Chronos_paper]),
setting w to be around 25 milliseconds provides both high time querying 15 servers at each poll interval (i.e., m=15) out of 500
accuracy and good security. Moreover, empirical analyses showed servers (n=500), and setting w to be around 25 milliseconds provides
that, on average, approximately 83% of the servers' clocks are at both high time accuracy and good security. Moreover, empirical
most w-away from the UTC, and within 2w from each other, satisfying analyses showed that, on average, approximately 83% of the servers'
the first condition of Chronos' system process. clocks are at most w-away from the UTC, and within 2w from each
other, satisfying the first condition of Chronos' system process.
Furthermore, according to Chronos security analysis, setting K to be
3 (i.e., if after 3 re-sampling, the two conditions are not
satisfied, then Chronos reaches "panic mode") is both safe when
facing time shifting attacks and the probability of reaching the
"panic mode" is negligible (less than 0.000002).
Chronos effect on precision and accuracy are discussed in Section 5
and Section 6.
4. Chronos' Pseudocode 4. Chronos' Pseudocode
The pseudocode for Chronos' Time Sampling Scheme, which is invoked in The pseudocode for Chronos' Time Sampling Scheme, which is invoked in
each Chronos poll interval is as follows: each Chronos poll interval is as follows:
counter := 0 counter := 0
S = []
T = []
While counter < K do While counter < K do
S := sample(m) //gather samples from (tens of) randomly chosen servers S := sample(m) //gather samples from (tens of) randomly chosen servers
T := bi-side-trim(S,1/3) //trim the third lowest and highest values T := bi-side-trim(S,1/3) //trim the third lowest and highest values
if (max(T) -min(T) <= 2w) and (|avg(T)-tc| < ERR + 2w) Then if (max(T) -min(T) <= 2w) and (|avg(T)-tc| < ERR + 2w) Then
return avg(t) return avg(t)
end end
counter ++ counter ++
sleep(rand(0,1)*poll interval) sleep(rand(0,1)*poll interval)
end end
// panic mode // panic mode
S := sample(n) S := sample(n)
T := bi-sided-trim(S,1/3) //trim bottom and top thirds; T := bi-sided-trim(S,1/3) //trim bottom and top thirds;
return avg(T) return avg(T)
5. Precision vs. Security 5. Precision vs. Security
Since NTPv4 updates the clock so long as time-shifting attacks are Since NTPv4 (and future NTPv5) updates the clock as long as time-
not detected, the precision and accuracy of a Chronos client are the shifting attacks are not detected, the precision and accuracy of a
same as NTPv4 when not under attack. When under attack, Chronos, Chronos client are the same as NTPv4 when not under attack. Under
which changes the list of the sampled servers more frequently than attack, Chronos, which changes the list of the sampled servers more
NTPv4 [Chronos_paper], and without using some of the filters in frequently than NTPv4 [Chronos_paper], and does not use some of the
NTPv4's system process, can potentially be less precise (though filters in NTPv4's system process, can potentially be less precise
provably more accurate and secure than NTPv4, which is vulnerable to (though provably more secure than NTPv4, which is vulnerable to time-
time-shifting attacks [RFC5905]). shifting attacks [RFC5905]).
However, our experimental and empirical analyses of Chronos revealed However, our experimental and empirical analyses of Chronos revealed
that Chornos and NTPv4 exhibit the same level of precision and that Chornos and NTPv4 exhibit the same level of precision and
accuracy when not under attack, with Chronos maintaining this level accuracy when not under attack, with Chronos maintaining this level
even in the presence of time-shifting attacks. even in the presence of time-shifting attacks.
6. Chronos' Threat Model and Security Guarantees 6. Chronos' Threat Model and Security Guarantees
As explained above, Chronos repeatedly gathers time samples from As explained above, Chronos repeatedly gathers time samples from
small subsets of a large local pool of NTP servers. The following small subsets of a large local pool of NTP servers. The following
skipping to change at page 7, line 46 skipping to change at page 8, line 46
Autonomous-System-level attacker) on the default BGP paths from the Autonomous-System-level attacker) on the default BGP paths from the
NTP client to a fraction of the available servers, (3) a nation state NTP client to a fraction of the available servers, (3) a nation state
with authority over the owners of NTP servers in its jurisdiction, or with authority over the owners of NTP servers in its jurisdiction, or
(4) an attacker capable of hijacking (e.g., through DNS cache (4) an attacker capable of hijacking (e.g., through DNS cache
poisoning or BGP prefix hijacking) traffic to some of the available poisoning or BGP prefix hijacking) traffic to some of the available
NTP servers. The details of the specific attack scenario are NTP servers. The details of the specific attack scenario are
abstracted by reasoning about MitM attackers in terms of the fraction abstracted by reasoning about MitM attackers in terms of the fraction
of servers with respect to which the attacker has MitM capabilities. of servers with respect to which the attacker has MitM capabilities.
Chronos detects time-shifting attacks by constantly monitoring Chronos detects time-shifting attacks by constantly monitoring
NTPv4's offset and the offset computed by Chronos, as explained NTPv4's (or NTPv5's) offset and the offset computed by Chronos, as
above, and checking whether it exceeds a certain threshold (10ms by explained above, and checking whether it exceeds a certain threshold
default). (10 milliseconds by default).
Analytical results (in [Chronos_paper]) indicate that in order to Analytical results (in [Chronos_paper]) indicate that in order to
succeed in shifting time at a Chronos client by even a small amount succeed in shifting time at a Chronos client by even a small amount
(e.g., 100ms), even a powerful man-in-the-middle attacker requires (e.g., 100 milliseconds), even a powerful MitM attacker requires many
many years of effort (e.g., over 20 years in expectation). See a years of effort (e.g., over 20 years in expectation). See a brief
brief overview of Chronos' security analysis below. overview of Chronos' security analysis below.
Notably, Chronos provides protection from MitM attacks that cannot be Notably, Chronos provides protection from MitM attacks that cannot be
achieved by cryptographic authentication protocols since even with achieved by cryptographic authentication protocols since even with
such measures in place an attacker can still influence time by such measures in place an attacker can still influence time by
dropping/delaying packets. However, adding an authentication and dropping/delaying packets. However, adding an authentication and
crypto-based security layer to Chronos will enhance its security crypto-based security layer to Chronos will enhance its security
guarantees and enable the detection of various spoofing and guarantees and enable the detection of various spoofing and
modification attacks. modification attacks.
Chronos' security analysis is briefly described next. Chronos' security analysis is briefly described next.
skipping to change at page 10, line 11 skipping to change at page 11, line 11
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
9.2. Informative References 9.2. Informative References
[Chronos_paper] [Chronos_paper]
Deutsch, O., Schiff, N., Dolev, D., and M. Schapira, Deutsch, O., Schiff, N., Dolev, D., and M. Schapira,
"Preventing (Network) Time Travel with Chronos", 2018, "Preventing (Network) Time Travel with Chronos", 2018,
<https://www.ndss-symposium.org/wp- <https://www.ndss-symposium.org/wp-
content/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf>. content/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[roughtime]
Patton, C., "Roughtime: Securing Time with Digital
Signatures", 2018,
<https://blog.cloudflare.com/roughtime/>.
Authors' Addresses Authors' Addresses
Neta Rozen-Schiff Neta Rozen-Schiff
Hebrew University of Jerusalem Hebrew University of Jerusalem
Jerusalem Jerusalem
Israel Israel
Phone: +972 2 549 4599 Phone: +972 2 549 4599
Email: neta.r.schiff@gmail.com Email: neta.r.schiff@gmail.com
 End of changes. 26 change blocks. 
109 lines changed or deleted 114 lines changed or added

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