> Am 24.03.2016 um 09:49 schrieb Miroslav Lichvar <[email protected]>: > > On Wed, Mar 23, 2016 at 06:17:33PM -0400, Sharon Goldberg wrote: >> 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. > > The NTP specification doesn't require servers to save any state per > client. The monitoring and rate limiting are optional features.
This is a valid argument. Together with the requirements formulated in RFC7384 this implies to formulate of a security mechanism which is stateless on the server side. But if we formulate NTS in such a way that the server keeps state of the client, NTS has to introduce the state. We cannot rely on NTP mechanisms. > >> Is this really such a >> problem to store a bunch of additional ~256 bit values for each client? > > That depends on the implementation. You can have an SNTP server with a > GPS refclock running on a microcontroller with couple kilobytes of RAM > and it can serve time to hunderds of thousands of clients. With NTS > the requirements on memory shouldn't change much, the CPU just has to > be faster or have the crypto algorithms implemented in HW. > >> And especially if this state only lives for the duration of the KE? > > There is no limit on the duration. The client may be polling the > server just couple times a day. Let's not forget the key exchange will > happen not only when the client is started, but also when the server > refreshes its seed. We certainly don't want clients to drop to their > minimum polling intervals or start a burst when that happens. > >> 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. > > Yes. To me it looks like a lot of complexity with little gain. > >> 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. > > I'm not sure if it's intentional, but recent versions of ntpd now > update the clock with the first (authenticated) sample. Older versions > and other implementations may require more. > >>> 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. > > Hm, I thought the incremental hash was meant for timestamps in the > first few NTS packets. > > If there were two associations per client, I think it would be even > more complex. There would have to be some mechanism for the server to > identify and link the two client associations, so it can hash the > right timestamps (and not timestamps for some other client behind NAT > for instance). The client would have to make sure requests from the > two associations are not too close to each other to not violate the > minimum request interval on the server. > > This would effectively double the polling rate. If the client is > allowed to increase its polling rate, I think it would be more useful > to do that with the NTS association rather than adding an extra > association, so the client would get the first authenticated sample > sooner. > > -- > Miroslav Lichvar > _______________________________________________ > ntpwg mailing list > [email protected] > http://lists.ntp.org/listinfo/ntpwg
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
