Subject: [ntpwg] NTS and quicksync

From: Danny Mayer <[email-masked]>
Date: Wed, 16 Mar 2016 23:38:34 -0400

I'd like to clear some of the air with regard to the discussion going on
between using NTS and using a MAC to authenticate packets before the NTS
protocol has completed.

Fundamentally NTP packets cannot protect the timestamps in the packet
while NTS is exchanging setup/authentication information between the two
servers. However some systems need a fast startup and timesync in
seconds (normally about 11 seconds) when using iburst mode. If the
starting server has to wait while the NTS protocol completes its
interaction then the iburst part will have exhausted the number of
initial packets and then the synchronization after NTS completes will
take minutes instead which everyone agrees is unacceptable.

One of the results of this is that if you rely on the initial packets
without NTS protection you can set the clock and it could be totally
wrong (because an attacker managed to spoof the packets). You could use
a symmetric key MAC as a temporary measure but then what's the point of NTS?

The question is this: How do we get a fast synchronized startup if we
only use NTS-authenticated packets?

Danny

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

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 17 Mar 2016 04:31:35 +0000

Danny Mayer writes:
> ...

How has this question *not* been adequately answered yet?

The easy answer is NTS+MAC while the NTS exchange is using 0x0004 Field
Types, until it has completed the first 3 complete exchanges and starts
sending 0x1004 Field Types, when the NTS EF includes MAC protection.

Symmetric key protection provides a level of authentication, and if one
chooses to use it to authenticate these early packets that's fine.

Authorization is available too, via 'restrict' entries.

NTS provides both authentication and authorization.  'restrict' entries
are stil available to provide authorization beyond whatever is built in
to NTS.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 17 Mar 2016 09:49:55 +0100

> take minutes instead which everyone agrees is unacceptable.

iburst will still work with NTS, it's similar to Autokey. It was
mentioned several times in the recent thread (although it may be
hidden in the noise).

When an association was configured with the iburst option, ntpd sends
6 packets in 10 seconds (2 second interval between them). NTS needs 3
requests to initialize the association, so the 4th, 5th and 6th reply
are authenticated and can be used for synchronization. If no packet is
lost (or significantly delayed due to bufferbloat, etc), ntpd will
make the first update of the clock about 7 seconds after the start.
Two packets can be lost and it should still make the first clock
update before the burst ends.

> only use NTS-authenticated packets?

By enabling iburst. No other changes should be necessary.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 17 Mar 2016 10:05:51 +0000

Miroslav,

Are you saying you believe iburst works fine with NTS and gives
authenticated time during the initial time sync phase?

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 17 Mar 2016 11:25:45 +0100

> authenticated time during the initial time sync phase?

Yes.

I'm confused. Have I or anyone else here said anything to the
contrary?

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Mar 2016 11:43:20 -0400

> chooses to use it to authenticate these early packets that's fine.

This is your recommendation but not surprisingly it has some drawbacks
like having to distribute a common keyset. What I'm looking for is if
there are other ideas for solving this without this drawback and still
providing fast clock synchronization.

I have one idea about this but I want to see if people have other ideas.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Mar 2016 11:47:28 -0400

> I'm confused. Have I or anyone else here said anything to the

Harlan has indicated that by the time that the NTS protocol exchange has
completed the number of iburst packets has been depleted and it won't be
able to synchronize for something like 10 minutes if the timestamps in
the NTS packets exchange are ignored because they are not protected.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 17 Mar 2016 19:02:08 +0000

> I'm confused. Have I or anyone else here said anything to the

NTS does not provide authenticated time until the cookie exchange has
been completed.  That means that NTS does not provide authenticated time
until after the initial time sync phase has been performed.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 18 Mar 2016 11:05:27 +0100

> until after the initial time sync phase has been performed.

Why would it mean that?

iburst consists of 6 requests (see the definition of NTP_IBURST in
ntpd/ntp_proto.c). NTS needs 3 requests to obtain the cookie.
Therefore, 3 requests in the iburst are left for synchronization with
authenticated packets. What am I missing here?

Danny said he needs the initial sync to happen in 11 seconds. That
worked with Autokey and will still work with NTS. You seemed to be
saying that the 6 second delay may still be a problem and you need
authenticated timestamps in the first reply. Autokey couldn't do that
and NTS will not be able to do that either. With symmetric keys it's
possible because there is already a secret shared between the server
and client. NTS needs 3 requests to exchange the secret.