The key-manahement argument

[Richard Laager]

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