On 1/19/19 5:10 AM, Hal Murray wrote: >> * Is NTPsec going to force C2S/S2C key rollover (e.g. by adding an >> expiration time to its cookie format) or leave expiration to clients? > Maybe, but not initially. We need a crypto geek to tell us how much we can > safely encrypt and/or authenticate so we can translate that back to packets. > >> * How is NTPsec going to handle key expiration when it is the client?
> I assume you are talking about K, the server master key. Not exactly. I'm talking about C2S and S2C. If the server uses the suggested cookie approach, or anything similiar, this means K by implication, but that isn't the point. Imagine a server that uses the suggested cookie approach and simply never rolls over K. As long as the client daemon is running, its cookies will be valid and keep getting renewed. C2S and S2C will never get rolled over. Should the client track an expiration limit in memory, and when that limit is hit, re-run NTS-KE? This probably has the same answer as for the server: you need guidance from a crypto expert. >> * What configuration options will be provided for each piece? > The client needs a new option on the server line. Possibly more than one. See below. >> * Is NTPsec going to initiate NTS by default? > Probably not. That would break backward compatibility. It does if NTS is _required_ by default. So obviously you can't do that But there is a middle ground: opportunistic NTS. This would be analogous to STARTTLS for SMTP (from a server to an MX). Straw proposal: server/pool get two new configuration options: nts and nonts. This means there are three possible configuration states for a server/pool: nts - Require NTS. If any part of NTS negotiation fails, do not speak NTP to this association. Certificates are fully validated on the TLS for NTS-KE (i.e. they must match the hostname, be valid time-wise, etc.). nonts - Do not attempt NTS. Behave as a pre-NTS NTP client always has. neither is set: For a pool, behave as "nonts" (because the common pool case is a public pool with volunteer servers that will not be able to present a valid certificate for the pool). For a server, attempt NTS-KE. If NTS-KE succeeds, use NTS. If NTS-KE fails, fall back to non-NTS. Since you're willing to fall back to non-NTS anyway, ignore certificate failures in the TLS negotiation for NTS-KE. However, if the certificate validation succeeds, behave as if "nts" is set for the rest of the lifetime of this daemon run; in other words, do not allow a downgrade later. The guidance to system administrators is simple: If your server supports NTS, set "nts" on the association. If it does not, set nothing. If there is some strong reason (e.g. attempting NTS-KE takes a long time to timeout because a firewall is blackholing the TCP packets?), you have "nonts" to forcibly disable NTS. For anyone who upgrades without touching their config, and one or more servers happen to support NTS, they will transparently start using it, albeit in a slightly-reduced security mode: they can be MITMed or downgraded, but only at ntpd start. As we have discussed before, certificate validation requires the client time to be relatively close to accurate. Opportunistic NTS could provide a useful result for systems with no RTC. When ntpd starts, the certificate validation fails (because the time is wrong), but NTS can otherwise succeed. The time gets set. Eventually, the client will need to re-run NTS-KE due to key rollover. At that point, the certificate check will succeed, resulting in the server association being "upgraded" to "nts" mode. Now the client is fully protected for the remainder of that ntpd run. Tthis might be an argument for re-running NTS-KE on any opportunistic NTS associations right away if the clock is stepped more than a minimal amount; this would achieve the same result faster, by not having to wait for key rollover. If the client is tracking key expiration as a time_t, this might happen as a side effect. That is, the system boots up with a time several years in the past, so the key expiration timeout is also several years in the past (plus a couple of days). Once the time is stepped, that expiration timestamp will be immediately in the past, triggering a re-run of NTS-KE. -- Richard _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
