Subject: [ntpwg] NTS: bootstrapping clients [was WGLC on NTS: Round trips for key exchange]

From: Sharon Goldberg <[email-masked]>
Date: Fri, 25 Mar 2016 12:51:47 -0400

On Thu, Mar 24, 2016 at 5:02 AM, Dieter Sibold <[email-masked]> wrote:

Am 23.03.2016 um 23:17 schrieb Sharon Goldberg <[email-masked]>:

Suppose an unauthenticated timing exchange happens and convince the client
> to update its clock before KE completes. Then,
> man-in-the-middle can trick the client into updating its clock to a
> bogus time in the past. Then, the attackers inject old compromised
> certificates into the KE exchange. (That is, a revoked/expired
> certificate for which the attacker has learned the secret key
> corresponding to the public key in the certificate.) The client is
> in the past, so it accepts the old bogus certificates, and the
> attacker has defeated any protection provided by NTS. (This is very
> related to the attack by Selvi in [5] and what we wrote about
> attacking SSL certificates in Section III of our paper [6]. See
> also [7].)
>
> We believe the NTS KE can be modified to authenticate timing
> messages sent in parallel with the KE. Note that this must be done
> *without* requiring these initial timing messages to be MAC'd,
> since before the KE completes, the client and server will not have
> a shared symmetric key.
>
> We believe that the NTS KE can be modified to include this feature.
> See *. Is this of interest?
>
>
> But is this not a fundamental problem? Even if an implementation supports
> an additional KE.  As long as the KE is based on certificates and the
> verification of the certificate’s validity is based upon time stamps a
> client which starts  NTS  and has no notion about the current time is a
> priori vulnerable to attacks described in [5].
>
> No, the attack described above will work *even if the victim client starts
up with an accurate time*.

Say my victim machine starts up knowing that it is the year 2016.  Now the
attacker modifies the timestamps on the unauthenticated timing messages
that are sent before the KE completes to the year 2014.  The client now
updates it clock to the year 2014.  Then during the key exchange the
attacker uses certificates from 2014 which were compromised by the attacker
by exploiting the heartblead bug.  Profit.

Notice that this attack works even on a client that is "bootstrapped", ie
has a clock that is approximately accurate upon startup.

Protecting a "non-bootstrapped" client from such an attack will be more
difficult.

But at the very least NTS should protect "bootstrapped" clients.

Along similar lines, I think it would be valuable for NTS to give some
advice on how to ensure most clients are bootstrapped most of the time.

Here is one idea. Each time the client updates its local clock, it also
writes the time to a file. This file persists even after the client shuts
down. Thus, when the client restarts and receives certificates as part of
the key exchange, the client will check this file and make sure that the
certificate is not expiring a time earlier than the last time written to
this file. This will stop attacks that try to roll the client to a time
BEFORE the last time it last synced, like the one described above.

Sharon
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Dieter Sibold <[email-masked]>
Date: Tue, 29 Mar 2016 18:59:26 +0200

> Am 25.03.2016 um 17:51 schrieb Sharon Goldberg <[email-masked]>:
> 
> On Thu, Mar 24, 2016 at 5:02 AM, Dieter Sibold <[email-masked] <mailto:[email-masked]>> wrote:
>> Am 23.03.2016 um 23:17 schrieb Sharon Goldberg <[email-masked] <mailto:[email-masked]>>:
> 
>> Suppose an unauthenticated timing exchange happens and convince the client to update its clock before KE completes. Then,
> But is this not a fundamental problem? Even if an implementation supports an additional KE.  As long as the KE is based on certificates and the verification of the certificate’s validity is based upon time stamps a client which starts  NTS  and has no notion about the current time is a priori vulnerable to attacks described in [5]. 
> 
> No, the attack described above will work *even if the victim client starts up with an accurate time*. 
> 
> Say my victim machine starts up knowing that it is the year 2016.  Now the attacker modifies the timestamps on the unauthenticated timing messages that are sent before the KE completes to the year 2014.  The client now updates it clock to the year 2014.  Then during the key exchange the attacker uses certificates from 2014 which were compromised by the attacker by exploiting the heartblead bug.  Profit. 

This is true. And this is what I meant. 

> 
> Notice that this attack works even on a client that is "bootstrapped", ie has a clock that is approximately accurate upon startup.  

This is also true, of course. But a a bootstrapped client can mitigate this attack by just not using the unauthenticated timing messages for time synchronization. 

> 
> Protecting a "non-bootstrapped" client from such an attack will be more difficult.
> 

This lead to the question how a client will verify that it is a „bootstrapped“ client.

> 
> Along similar lines, I think it would be valuable for NTS to give some advice on how to ensure most clients are bootstrapped most of the time.
> 
> Here is one idea. Each time the client updates its local clock, it also writes the time to a file. This file persists even after the client shuts down. Thus, when the client restarts and receives certificates as part of the key exchange, the client will check this file and make sure that the certificate is not expiring a time earlier than the last time written to this file. This will stop attacks that try to roll the client to a time BEFORE the last time it last synced, like the one described above.

This is true but leaves open the question how the client will check this file on its very first bootstrapping process. Also, this will not work for clients with memory based file system. Even some manufactures of NTP server appliances would probably lose such info during a reboot of the system. Sure, also for such systems appropriate means are feasible to make such a attack more difficult. 

However, from our point of view this is not a question of the specification but of the implementation. Form the specification point of view the situation is clear. The KE is piggybacked on NTP packets and the NTP header information including the four timestamps t1 - t4 are not protected by a MAC. The subsequent time_request and time_response messages are authenticated. The timestamps from the KE exchanges may or may not be applied for the calculation of the time offset. From our point of view this is not to be specified or decided by NTS.

We believe that a good implementation will leave the decision of how these timestamps will be used to the user (probably by default it should not consider them). But I can also imagine business cases in which an user will evaluate the risk of this attack and based on the evaluation's result will decide to accept the remaining risk and use these timestamps in order to have faster time synchronization.

Dieter