[ntpwg] Questions on draft-ietf-ntp-using-nts-for-ntp-01

kristof.teichel at ptb.de kristof.teichel at ptb.de
Thu Sep 3 11:04:43 UTC 2015


Miroslav Lichvar <mlichvar at redhat.com> schrieb am 02.09.2015 17:24:31:

> Von: Miroslav Lichvar <mlichvar at redhat.com>
> An: kristof.teichel at ptb.de
> Kopie: ntpwg at lists.ntp.org
> Datum: 02.09.2015 17:24
> Betreff: Re: [ntpwg] Questions on draft-ietf-ntp-using-nts-for-ntp-01
> 
> Thanks for the response, Kristof.
> 
> On Tue, Sep 01, 2015 at 11:14:34PM +0200, kristof.teichel at ptb.de wrote:
> >    > Would it be acceptable for the client to be configured
> >    > with a public key that the server certificate has to be signed 
by?
> >    While I'm not sure I understand all the implications here (of
> >    persistent vs. ephemeral associations), I think it *might* be
> >    acceptable for the client to be configured to base his trust solely 
on
> >    such a public key. What would be the benefit of this?
> 
> The benefit would be that the client doesn't have to accept time only
> from a specified server. A broadcast/multicast server or an active
> peer can push the association to the clients or passive peers (if they
> are willing to accept it), which don't have to be configured with the
> hostname of the server or active peer.

We have designed the association and cookie exchanges with nonces for 
freshness checks, so that a client can be sure that an association 
response is not a replay of an old one which was valid at the time but is 
now outdated and possibly unsecure.
I believe that for this to work, the association always has to be 
initiated by the client.

For NTS-secured NTP, broadcast/multicast is treated largely seperately 
from unicast, the association/cookie exchanges do not really play a role 
there.

> 
> >    > However, a special care must be taken when creating the 
association.
> >    > To succeed even when an attacker is sending spoofed packets to 
the
> >    > peers, I think there has to be a server_assoc/cook reply for each
> >    > client_assoc/cook request, i.e. the initialization has to be
> >    > independent from the normal peer polling process. Should be the
> >    > assoc/cook messages sent in the NTP client/server mode packets or
> >    keep
> >    > them in the symmetric mode? My preference would be the former.
> >    Please explain the two options. Our idea has been to use the 
assoc/cook
> >    messages as specified for client-server also in the case of 
symmetric
> >    association, but we have not put much thought into the details yet.
> 
> The question is what packet mode should be used to start a symmetric
> association using NTS. I think one option is to use the client (mode
> 3) packets and switch to the symmetric mode (1 or 2) later when the
> NTS association has been created, i.e. don't allow server_assoc/cook
> messages in symmetric mode packets. The other option is to start
> immediately with symmetric mode packets, but modify the peer polling
> process to reply to all assoc/cook requests to prevent the DoS attack.
> The former seems like a cleaner approach to me.

I also like the former approach better.

> 
> >    > What exactly is preventing NTS to be usable with NTP pools? Is 
that
> >    > meant for the pool.ntp.org pool where the servers are not 
controlled
> >    > by a single entity or is there a requirement that one certificate
> >    > cannot be used on multiple servers?
> >    We figured there would not be a use case where a client would 
require
> >    authenticated time but would turn to a pool, because authenticated 
time
> >    seemed to imply that a client would need to choose a specific 
server
> >    (or several) which would be sufficiently trusted for its purposes. 
I
> >    have never explicitly thought about the mentioned requirement (a
> >    certificate may only validate one time server), but I believe it to
> >    make sense and have always implicitly assumed that it is there.
> >    Also, isn't it currently incredibly easy to become a member of an 
NTP
> >    pool? For usage with NTS, I think this would have to be severely
> >    restricted.
> 
> Yes, anyone can join the pool.ntp.org pool, so using authentication
> would probably not make much sense there. But what about pools where
> all servers are owned by one company for instance? As a pool I
> understand a name that resolves to addresses of multiple NTP servers.

For this topic, I do not yet have a good enough understanding of how 
clients work with pools. Does a client query the pool once, then get a 
fixed name/adress under which it can always reach the same server? Or is 
any time request sent to the pool name and then just routed to a random 
one of the servers reachable under that name?

In the former case, a client could just use NTS after it has acquired a 
name for a fixed server. In the latter case, the NTS/autokey approach of 
having a shared secret that is re-generatable on the server side (cookie) 
seems very difficult to apply, for all servers in the pool would have to 
possess synchronized secret server seeds.

> 
> -- 
> Miroslav Lichvar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntp.org/pipermail/ntpwg/attachments/20150903/e8801179/attachment.html>


More information about the ntpwg mailing list