[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