Subject: [Ntp] draft-schiff-ntp-chronos-01.txt

From: Neta R S <[email-masked]>
Date: Tue, 23 Oct 2018 10:56:23 +0300

Hi,

We submitted a new draft for Chronos (see below).
The main change is a hybrid approach: by default NTPv4 updates the local
clock but when a threat or evidence of attack is detected Chronos time is
considered.

Please take a look,
Thanks,
Neta

Name:           draft-schiff-ntp-chronos
Revision:       01
Title:          A Secure Selection and Filtering Mechanism for the Network
Time Protocol Version 4
Document date:  2018-10-21
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-schiff-ntp-chronos-01.txt
Status:         https://datatracker.ietf.org/doc/draft-schiff-ntp-chronos/
Htmlized:       https://tools.ietf.org/html/draft-schiff-ntp-chronos-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schiff-ntp-chronos
Diff:
https://www.ietf.org/rfcdiff?url2=draft-schiff-ntp-chronos-01

Abstract:
   The Network Time Protocol version 4 (NTPv4) defines the peer process,
   the clock filter algorithm, the system process and the clock
   description algorithm.  The clock filter algorithm and the system
   process, as defined in RFC 5905, are the mechanism according to which
   an NTP client chooses the NTP servers it synchronized with.  This
   document specifies an alternative set of client mechanisms, named
   Chronos, that is backward compatible with NTPv4, and offers an
   improved level of security against time shifting attacks.

---

From: <[email-masked]>
Date: Tue, 23 Oct 2018 17:37:53 +0000

Interesting evolution of the clustering concept.  A couple of thoughts.

  1.  It should be possible to perform this operation external to ntpd and then use the resulting information to add/remove servers?  More complex but same functionality?  Certainly cleaner in ntpd.
  2.  It should be possible to modify only the clock selection algorithm and not the clock filtering algorithm although this may be moot if there ends up being a lot of clock hopping.  It would likely result in better precision.
  3.  Instead of taking the average of the sampled servers, have you considered the opposite approach?  That would comprise statistical sampling of the network clocks to validate the current selected clock as a “truechimer”.  This should result in better performance with equivalent security, right?

Greg Dowd
Principal Engineer, FTD
Microsemi
3870 N. First St. | San Jose | CA 95134 | USA
Office: 408.964.7643
Email: [email-masked]<mailto:[email-masked]>
Company Website:  www.microsemi.com<http://www.microsemi.com/>

From: ntp [mailto:[email-masked]] On Behalf Of Neta R S
Sent: Tuesday, October 23, 2018 12:56 AM
To: [email-masked]
Subject: [Ntp] draft-schiff-ntp-chronos-01.txt

EXTERNAL EMAIL
Hi,

We submitted a new draft for Chronos (see below).
The main change is a hybrid approach: by default NTPv4 updates the local clock but when a threat or evidence of attack is detected Chronos time is considered.

Please take a look,
Thanks,
Neta

Name:           draft-schiff-ntp-chronos
Revision:       01
Title:          A Secure Selection and Filtering Mechanism for the Network Time Protocol Version 4
Document date:  2018-10-21
Group:          Individual Submission
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-schiff-ntp-chronos-01.txt
Status:         https://datatracker.ietf.org/doc/draft-schiff-ntp-chronos/
Htmlized:       https://tools.ietf.org/html/draft-schiff-ntp-chronos-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-schiff-ntp-chronos
Diff:           https://www.ietf.org/rfcdiff?url2=draft-schiff-ntp-chronos-01

Abstract:
   an NTP client chooses the NTP servers it synchronized with..  This

---

From: Neta R S <[email-masked]>
Date: Wed, 24 Oct 2018 13:41:59 +0300

Hi Greg,

Thanks a lot for the feedback.
Regarding 1, I think it's a good alternative with respect to implementation
simplicity and certainly worth checking.
Regarding 2, I can see the benefit for precision however I am worried it
will affect security as it prevents the chronos random peer sampling.
Reagrding 3, I agree. I also think that considering the statistical
information of the peers will get better results.

Thanks a lot,
Neta

On Tue, Oct 23, 2018 at 8:37 PM <[email-masked]> wrote:

>    1. It should be possible to perform this operation external to ntpd
>    and then use the resulting information to add/remove servers?  More complex
>    but same functionality?  Certainly cleaner in ntpd.
>    2. It should be possible to modify only the clock selection algorithm
>    and not the clock filtering algorithm although this may be moot if there
>    ends up being a lot of clock hopping.  It would likely result in better
>    precision.
>    3. Instead of taking the average of the sampled servers, have you
>    considered the opposite approach?  That would comprise statistical sampling
>    of the network clocks to validate the current selected clock as a
>    “truechimer”.  This should result in better performance with equivalent
>    security, right?
>
>
>
>
>
> *Greg Dowd*
>
> Principal Engineer, FTD
>
> Microsemi
>
> Email: [email-masked] <[email-masked]>*
>
> Company Website:  www.microsemi.com
>
>
>
>
>
>
> *From:* ntp [mailto:[email-masked]] *On Behalf Of *Neta R S
> *Sent:* Tuesday, October 23, 2018 12:56 AM
> *To:* [email-masked]
> *Subject:* [Ntp] draft-schiff-ntp-chronos-01.txt
>
>
>
> EXTERNAL EMAIL
>
> Hi,
>
>
>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 30 Oct 2018 11:58:08 -0400

I met with Michael Schapira back in May and discussed their paper on
Chronos. A number of comments on the draft first before I discuss that
paper.

The introduction (Section 1) states without proof or reference that:

"Time shifting attacks on NTP are possible even if all NTP
communications are encrypted and authenticated".

That needs to be justified. It may be true but if any of the servers
involved in providing a clock is compromised then the whole server is
compromised and there are worse things happening on that server. The NTP
protocol was never meant to deal with those issues.

Further in the Introduction it talks about Chronos applying a "provably
secure algorithm" but the draft provides no actual proof that it's
secure. Further on it talks about "provable security guarantees" but I
am not clear what the guarantee is nor what happens if the guarantee is
violated.

Section 5 talks again about Chronos "provably more secure than NTPv4"
but there is no reference where to find that in the Chronos paper to
justify the statement. I don't have the paper at hand at the moment to
look. Section 5 mentions [roughtime]. Is that a reference or something else.

Section 8 - Security Considerations - should come before acknowledgements.

Section 8 talks about MitM attackers being in direct control of a
fraction of the NTP servers but in that case they are not MitM though I
understand the point. Note that if you are concerned about security and
there are vulnerabilities with BGP hijacking or nation-state attacks you
shouldn't be using the pool servers at all and should use your own
infrastructure whether you use GPS sources or your own atomic clock
depending on your own requirements. I'm not sure that the claim of 20
years of effort should be made in this draft as technological changes
are always changing such claims and estimates.

At the more fundamental level the clock selection process ignores a
number of the criteria used in the reference implementation of clock
selection, including important ones like jitter since it throws away the
information obtained each cycle since it selects a different set of NTP
servers each time. Reliability of the source is important here. Note
that there are multiple sources of jitter not just in the network but
also in the NTP Servers providing the packet as well as the client's own
clock. Throwing away the lowest third and the highest third is not
necessarily the best way of selecting the data. If you have an attacker
trying to push the clock away from the proper value it's likely to be
the highest ones but they can also be biasing the middle third as well
and it's the lowest third that should be chosen.

The Chronos paper discusses the experimental side. My discussion with
Michael indicated that the experiments were carried out on virtual
machines. Unfortunately that represents a different problem. What is the
Chronos client disciplining? If it is the clock of the virtual machine
then is that affecting the underlying clock on the physical machine, is
the clock just ignoring the disciplining of the clock, does it move the
virtual clock out of sync with the underlying hardware clock? This
doesn't even get into the question of multicore CPU's. If it affects the
underlying hardware clocks what is the effect on the clock of multiple
virtual machines disciplining the underlying clock? Rerunning this on
non-virtual machines would be helpful.

Apart from the above it's an interesting proposal.

Danny

On 10/24/18 6:41 AM, Neta R S wrote:
> Regarding 1, I think it's a good alternative with respect to
> implementation simplicity and certainly worth checking.
> Regarding 2, I can see the benefit for precision however I am worried
> it will affect security as it prevents the chronos random peer sampling.
> On Tue, Oct 23, 2018 at 8:37 PM <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      1. It should be possible to perform this operation external to
>         ntpd and then use the resulting information to add/remove
>         servers?  More complex but same functionality?  Certainly
>         cleaner in ntpd.
>      2. It should be possible to modify only the clock selection
>         algorithm and not the clock filtering algorithm although this
>         may be moot if there ends up being a lot of clock hopping.  It
>         would likely result in better precision.
>         considered the opposite approach?  That would comprise
>         statistical sampling of the network clocks to validate the
>         current selected clock as a “truechimer”.  This should result
>         in better performance with equivalent security, right? 
>
>      
>
>      
>
>     */Greg Dowd/**//*
>
>     Principal Engineer, FTD
>
>     Microsemi
>
>     Email: [email-masked] <mailto:[email-masked]>_
>
>     Company Website:  www.microsemi.com <http://www.microsemi.com/>
>
>
>      
>
>      
>
>     *From:* ntp [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Neta R S
>     *To:* [email-masked] <mailto:[email-masked]>
>     The main change is a hybrid approach: by default NTPv4 updates the
>     local clock but when a threat or evidence of attack is detected
>     Chronos time is considered.
>
>      
>
>     Please take a look,
>
>     Thanks,
>
>     Neta
>
>      
>
>     Status:       
>      https://datatracker.ietf.org/doc/draft-schiff-ntp-chronos/
>
>     Htmlized:     
>      https://tools.ietf.org/html/draft-schiff-ntp-chronos-01
>
>     Htmlized:     
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Dieter Sibold <[email-masked]>
Date: Tue, 30 Oct 2018 16:01:49 +0000

Hi Greg,

maybe it is only me. But to be honest I don’t understand the third point. Especially, what do you mean with the opposite approach? I would like to understand your implications.

Dieter

Von: ntp <[email-masked]> im Auftrag von "[email-masked]" <[email-masked]>
Datum: Dienstag, 23. Oktober 2018 um 19:42
An: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Betreff: Re: [Ntp] draft-schiff-ntp-chronos-01.txt

Greg Dowd
Principal Engineer, FTD
Microsemi

EXTERNAL EMAIL
Hi,

Please take a look,
Thanks,
Neta

Abstract:

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 16:39:46 +0000

Hi Dieter,
This mirrors a statement by Danny recently that information is being lost in the suggested approach.  The current clock combining algorithm uses the weighted average of the clocks left after the selection algorithm.  This provides mitigation against network bias, jitter and clockhopping.  My intent in comment 3 was to suggest that instead of using the secure selection algorithm to determine a single "jam synchronization", the secure algorithm could perhaps be used as a new "clustering" step that would complement or bracket the current produced clock correction.  If the filtered, smoothed clock correction is within the bracket, it would be used.  If it fell outside, some other step would take place, marking outlier as falseticker and re-running or some other step.  This technique was discussed I think years ago in the SNTP work and was part of the DSNTP (Datum Secure Network Time Protocol) we produced back then.  The idea was that the authentication code validated the steering section but did not replace it.

Does that make sense?

Greg Dowd
Principal Engineer, FTD
Microsemi

From: Dieter Sibold [mailto:[email-masked]]
Sent: Tuesday, October 30, 2018 9:02 AM
To: Greg Dowd - C32313 <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ntp] draft-schiff-ntp-chronos-01.txt

Hi Greg,

maybe it is only me. But to be honest I don't understand the third point. Especially, what do you mean with the opposite approach? I would like to understand your implications.

Dieter

Von: ntp <[email-masked]<mailto:[email-masked]>> im Auftrag von "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Datum: Dienstag, 23. Oktober 2018 um 19:42
An: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [Ntp] draft-schiff-ntp-chronos-01.txt

  1.  It should be possible to perform this operation external to ntpd and then use the resulting information to add/remove servers?  More complex but same functionality?  Certainly cleaner in ntpd.
  2.  It should be possible to modify only the clock selection algorithm and not the clock filtering algorithm although this may be moot if there ends up being a lot of clock hopping.  It would likely result in better precision.
  3.  Instead of taking the average of the sampled servers, have you considered the opposite approach?  That would comprise statistical sampling of the network clocks to validate the current selected clock as a "truechimer".  This should result in better performance with equivalent security, right?

Greg Dowd
Principal Engineer, FTD
Microsemi

From: ntp [mailto:[email-masked]] On Behalf Of Neta R S
Sent: Tuesday, October 23, 2018 12:56 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ntp] draft-schiff-ntp-chronos-01.txt

EXTERNAL EMAIL
Hi,

Please take a look,
Thanks,
Neta

Abstract:

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 30 Oct 2018 22:38:09 +0200

Thanks for the answer Greg.
Does this imply that chronos will „only“ replaces NTP’s selection 
process? After that NTP’s cluster and combination algorithms are 
applied in order to calculate the clock offset. Additionally, chronos 
will provide an upper bound for a valid clock offset?

Dieter

On 30 Oct 2018, at 17:39, [email-masked] wrote:

> Hi Dieter,
> This mirrors a statement by Danny recently that information is being 
> lost in the suggested approach.  The current clock combining algorithm 
> uses the weighted average of the clocks left after the selection 
> algorithm.  This provides mitigation against network bias, jitter and 
> clockhopping.  My intent in comment 3 was to suggest that instead of 
> using the secure selection algorithm to determine a single "jam 
> synchronization", the secure algorithm could perhaps be used as a new 
> "clustering" step that would complement or bracket the current 
> produced clock correction.  If the filtered, smoothed clock correction 
> is within the bracket, it would be used.  If it fell outside, some 
> other step would take place, marking outlier as falseticker and 
> re-running or some other step.  This technique was discussed I think 
> years ago in the SNTP work and was part of the DSNTP (Datum Secure 
> Network Time Protocol) we produced back then.  The idea was that the 
> authentication code validated the steering section but did not replace 
> it.
>
> Does that make sense?
>
>
>
> Greg Dowd
> Principal Engineer, FTD
> Microsemi
> maybe it is only me. But to be honest I don't understand the third 
> point. Especially, what do you mean with the opposite approach? I 
> would like to understand your implications.
>
> Dieter
>
> Von: ntp <[email-masked]<mailto:[email-masked]>> im 
> Auftrag von "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> An: "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> and then use the resulting information to add/remove servers?  More 
> complex but same functionality?  Certainly cleaner in ntpd.
> algorithm and not the clock filtering algorithm although this may be 
> moot if there ends up being a lot of clock hopping.  It would likely 
> result in better precision.
> considered the opposite approach?  That would comprise statistical 
> sampling of the network clocks to validate the current selected clock 
> as a "truechimer".  This should result in better performance with 
> equivalent security, right?
>
>
> Greg Dowd
> Principal Engineer, FTD
> Microsemi

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 30 Oct 2018 22:52:03 +0200

Hi Neta,

regarding table 1: I suppose the small w and the capital W represent the 
same quantity?

Dieter

On 23 Oct 2018, at 9:56, Neta R S wrote:

> local

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 21:59:41 +0000

Somewhat.  My intent was to suggest that the new algorithm should NOT replace the current steering part of the loop but instead operate in front or alongside or even post (although that would only report, not prevent attacks).  I was not focused on the part it would replace (see my other comments) but to suggest there is a part it perhaps should not replace.  As an example, there is no mention of hysteresis in the secure selection.  This doesn’t mean it could not include it but it is not necessary to solve the security problem.  However, it is vital to the clock steering algorithm and supplied in the form of anti-clockhopping and maybe the prefer logic.  This mix of requirements led to my comments trying to compartmentalize the security as an envelope under which the steering could hopefully continue to operate without significant noise being introduced.

Thanks..Greg

Greg Dowd
Principal Engineer, FTD
Microsemi

From: Dieter Sibold [mailto:[email-masked]]
Sent: Tuesday, October 30, 2018 1:38 PM
To: Greg Dowd - C32313 <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ntp] draft-schiff-ntp-chronos-01.txt

Thanks for the answer Greg.
Does this imply that chronos will „only“ replaces NTP’s selection process? After that NTP’s cluster and combination algorithms are applied in order to calculate the clock offset. Additionally, chronos will provide an upper bound for a valid clock offset?

Dieter

On 30 Oct 2018, at 17:39, [email-masked]<mailto:[email-masked]> wrote:
Hi Dieter,
This mirrors a statement by Danny recently that information is being lost in the suggested approach.  The current clock combining algorithm uses the weighted average of the clocks left after the selection algorithm.  This provides mitigation against network bias, jitter and clockhopping.  My intent in comment 3 was to suggest that instead of using the secure selection algorithm to determine a single “jam synchronization”, the secure algorithm could perhaps be used as a new “clustering” step that would complement or bracket the current produced clock correction.  If the filtered, smoothed clock correction is within the bracket, it would be used.  If it fell outside, some other step would take place, marking outlier as falseticker and re-running or some other step.  This technique was discussed I think years ago in the SNTP work and was part of the DSNTP (Datum Secure Network Time Protocol) we produced back then.  The idea was that the authentication code validated the steering section but did not replace it.

Does that make sense?

Greg Dowd
Principal Engineer, FTD
Microsemi

From: Dieter Sibold [mailto:[email-masked]]
Sent: Tuesday, October 30, 2018 9:02 AM
To: Greg Dowd - C32313 <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ntp] draft-schiff-ntp-chronos-01.txt

Hi Greg,

Dieter

Greg Dowd
Principal Engineer, FTD
Microsemi

EXTERNAL EMAIL
Hi,

Please take a look,
Thanks,
Neta

Abstract:

---

From: "Dieter Sibold" <[email-masked]>
Date: Wed, 31 Oct 2018 17:19:15 +0100

Thanks Greg
I suppose I’ve got it.
Dieter

On 30 Oct 2018, at 22:59, [email-masked] wrote:

> Somewhat.  My intent was to suggest that the new algorithm should NOT 
> replace the current steering part of the loop but instead operate in 
> front or alongside or even post (although that would only report, not 
> prevent attacks).  I was not focused on the part it would replace (see 
> my other comments) but to suggest there is a part it perhaps should 
> not replace.  As an example, there is no mention of hysteresis in the 
> secure selection.  This doesn’t mean it could not include it but it 
> is not necessary to solve the security problem.  However, it is vital 
> to the clock steering algorithm and supplied in the form of 
> anti-clockhopping and maybe the prefer logic.  This mix of 
> requirements led to my comments trying to compartmentalize the 
> security as an envelope under which the steering could hopefully 
> continue to operate without significant noise being introduced.
>
> Thanks..Greg
>
>
> Greg Dowd
> Principal Engineer, FTD
> Microsemi
> Does this imply that chronos will „only“ replaces NTP’s 
> selection process? After that NTP’s cluster and combination 
> algorithms are applied in order to calculate the clock offset. 
> Additionally, chronos will provide an upper bound for a valid clock 
> offset?
>
> Dieter
>
>
> On 30 Oct 2018, at 17:39, 
> [email-masked]<mailto:[email-masked]> wrote:
> Hi Dieter,
> using the secure selection algorithm to determine a single “jam 
> synchronization”, the secure algorithm could perhaps be used as a 
> new “clustering” step that would complement or bracket the current 
> To: Greg Dowd - C32313 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[email-masked]>; 
> [email-masked]<mailto:[email-masked]>
> maybe it is only me. But to be honest I don’t understand the third 
> as a “truechimer”.  This should result in better performance with