Sorry correction to my email: the key $k$ held by server is just one key for ALL clients.
On Wed, Mar 23, 2016 at 6:17 PM, Sharon Goldberg <[email protected]> wrote: > > > 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 > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
