> > This is an interesting idea, but wouldn't the server have to save the
> > > incremental hash between client's requests? An NTP server normally
> > > doesn't keep any state for clients and when it does (e.g. for
> > > monitoring and rate limiting), it's all in a constant amount of memory
> > > to prevent DoS attacks on the server.
> >
> >
> > If an incremental hash is used, then it would require a constant amount
> of memory on the server.
>
> Per client, right?
>
> Right. But only for the duration of the KE; afterwards this could be
purged.
However, if this per client state really bothers us, there is a way around
it.
Before I say how to get around it, I was wondering why this bothers us so
much? The current ntpd already has the server saves per-client state, for
poll interval, rate limiting, and symmetric keys. Is this really such a
problem to store a bunch of additional ~256 bit values for each client?
And especially if this state only lives for the duration of the KE?
Anyway, here is a generic trick for getting rid of state on the server,
that could be useful for NTS. The trick is to use a cookie.
1) Let the server have a local symmetric key $k$ that only it knows. It
only needs on key for each client.
2) Let $s$ be the per client state that the server doesn't want to store.
For example, the session key with the client, or the incremental hash, or
whatever we want.
3) The server computes cookie $c$ = AuthEnc_{$k$} ($s$), where AuthEnc is
an authenticated encryption scheme like GCM [1].
4) The server sends $c$ to the client.
5) The client stores $c$. Note that since the client doesn't know $k$, it
can't read what is in $c$.
6) The client sends $c$ to the server with its request.
7) The server knows $k$, and can AuthDec_{$k$}($c$) to learn $s$.
We would need to be careful with session identifiers so attackers can't
replay old cookies here but this is the basic idea. I can do some research
on exactly how this should be done, I think there have been papers on it.
But I think it is worthwhile to carefully evaluate if this type of approach
is really needed for NTS, or is it just adding additional complexity.
> > Clients that would benefit most
> > > from having timestamps authenticated retroactively probably would be
> the
> > > ones that poll the server least frequently and are most likely to
> > > have their state on the server lost.
> >
> >
> > I'm not sure I understand this point. If a client is querying
> > infrequently, why not just wait until the KE completes, and the key is
> > established, before sending timing messages that can then be
> authenticated
> > with the established key? Why would you want to start a timing exchange
> > in parallel with the KE?
>
> My thought was that clients using longer interval would save more time
> by having old timestamps authenticated.
>
> If I understand the scheme you propose correctly, the client would
> have samples from previous packets in the NTS initialization validated
> when the last packet in the initialization is received.
Yes. So I imagine the client starting. Then it initiates NTS and in
parallel does some timing exchanges that are not MAC'd. These timing
exchanges won't update the clock yet. Then once the NTS KE completes, it
also authenticates these timing exchanges. At this point, the client can
choose to update its clock (or not) per the usual NTP processes.
> The question
> is what the client could do with these extra samples. I guess they
> could be useful to estimate the frequency error of the clock as ntpd
> does in the freq state for instance. A client polling at 64s interval
> would save more time with this than a client using 2s poll (iburst).
>
> Not sure, not an expert on NTP's timing algos. But we have seen that upon
initalization, ntpd requires about 4 timing samples before it updates its
clock. So it could collect these timing samples while the NTS KE is running.
> There is also a question whether the client would really want to use
> any samples from the non-timing NTS exchanges as the packets are
> longer and asymmetric, creating an extra error in the measurements.
>
>
So, in my mind, the timing messages would be sent in separate packets from
the NTS KE messages. They would be sent in parallel. That way, the crypto
done in NTS does not mess up the accuracy of the timing exchanges.
[1] https://en.wikipedia.org/wiki/Galois/Counter_Mode
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
