NTS

[Richard Laager]

On 09/17/2018 06:50 PM, Hal Murray via devel wrote:
> I'd be a lot happier if I had a good feel for the big picture.  How will NTP 
> be used?  What does a client have to do to use it?  What does a server have to 
> do to support it?

I'm also interested in these answers.


I use NTP in a few different scenarios:

1) A client under my control accesses a fixed server under my control.
For example, my typical server would be an NTP client talking to my NTP
servers.

2) A client under my control accesses a fixed server not under my
control. For example, my NTP servers are NTP clients talking to
hand-picked upstream NTP servers.

3) A client not under my control accesses a server under my control. For
example, my customers can access my NTP servers. Also, I participate in
the NTP pool.

4) A client under my control accesses the pool. My systems, both NTP
clients and servers, use the pool in addition to the other sources. (If
this is terrible, you might separately explain to me why.)


As a sysadmin, here's what I am expecting for NTS (correct me if I'm
wrong, please)...

On my servers, I will provide ntpd (or some other related program) one
or more (e.g. both RSA and ECDSA) Cert/Chain/Key combinations. The
certificate(s) will have a hostname corresponding to the name that
clients use (e.g. ntp1.wiktel.com).

On my clients, ntpd will (through the SSL library or distro packaging of
ntpd or a related program) default to using the system's root
certificate store.

For #1, I want to configure the client to _require_ that the server use
NTS. I know my server supports NTS (in this hypothetical). (I would need
to turn off use of the pool on my clients, to avoid downgrade attacks.)

For #2, I would force NTS required if I know it is supported, just like
in #1. Otherwise, it would be nice if it was used opportunistically.
That way, if the server supports NTS, I get all of its benefits after
the initial leap-of-faith. I'm still subject to MITM and downgrade
attacks initially during that leap-of-faith, but that's less bad than
being subject to them all the time.

#3 is just the opposite side of #2. As the server operator, I would
enable NTS. Clients who know I support NTS can require it. Clients who
don't know I support NTS get it opportunistically, if such a mode is
supported.

For #4, it is not possible to authenticate the configured hostname
(which is 0.pool.ntp.org or similar), as the pool servers presumably
would not have certs for ntp.org hostnames*. In this case, it would be
nice to use NTS opportunistically.

* I suppose it would be possible for the pool to give out certificates
to servers which are configured as part of the pool, if they cooperated
with Let's Encrypt or something.

Does the NTS protocol support the idea of a TLS certificate that would
be valid for NTS without being valid for all protocols, for example by
Extended Key Usage or similar?

-- 
Richard