> 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$.
Pretty straightforward.
> 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.
Absolutely.
See also the end of this mail.
> 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.
I also do not think the client should use any such samples.
> 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.
Yes, this seems like it would make the most sense for employing the
proposed technique actually.
However, it does not get around the chicken-and-egg problem that was
outlined earlier: a client who is initially without any sense of
time/clock could be convinced to take old crypto data/certificates and
then that would impede the security of everything that follows.
My position on the whole issue would be that if we introduced a mechanic
as outlined in 1) - 7) *just* for an a posteriori verification of a small
number of initial exchanges, then the cost of the added complexity would
be too high.
If, on the other hand, we figured out how to get more use out of such
techniques, then it might be worth it.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
