> Am 23.03.2016 um 23:17 schrieb Sharon Goldberg <[email protected]>:
>
> > > 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?
Yes, this is true. But the capabilities of NTP to keep track of the states are
very limited. Our NTP servers with the most current NTPD are only able to store
about 12000 records, in which the oldest records are about 10 to 60 seconds
old. They even cannot guarantee to memorize the state of a client when it is in
iburst mode. Perhaps the implementation can be adjusted to allow for even more
state information. However when we started this project we had and still have
the requirement to have a solution that can allow a NTPD to serve at least 10^5
clients. That is the practical reason we wanted to have an approach that is
stateless on the server side. Another reason is RFC 7384, Sec. 5.7, which state
that a security mechanism should minimize the storage requirements of client
state in the server.
Dieter
>
> 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
> <https://en.wikipedia.org/wiki/Galois/Counter_Mode>
>
> Sharon Goldberg
> Computer Science, Boston University
> http://www.cs.bu.edu/~goldbe
> <http://www.cs.bu.edu/~goldbe>_______________________________________________
> TICTOC mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
