Proper cn in certificate for use with NTS

Server operators
1

I’m tinkering with NTS on 188.166.95.178 and 193.175.73.151 – NTS seems to be working, but which cn (in the x.509 Certificate) should pool servers use?

Turns out that both servers can properly communicate using char-ntp-pool.charite.de and mail.python.org:

server char-ntp-pool.charite.de nts iburst
server mail.python.org nts iburst
2

I would assume you would put the proper hostname of your machine, whatever a reverse lookup of your IP resolves to? NTPSec is the only program I know of at the moment that has implemented the draft NTS spec, and unfortunately I haven’t had time to mess around with it…

If you have to implement all the various continent/country pool aliases that could be extremely tedious…

The NTP Pool does not officially support NTS (or any authentication scheme) at this time…

3

The current NTS spec doesn’t support use cases like the pool, sadly.

https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

There’s been some discussion in the working group about it, but nothing made it into the draft. https://datatracker.ietf.org/wg/ntp/about/

(It’s sad to me because outside the OS vendor NTP services I believe we service a huge part of the NTP queries done in the world, so even if “security” has different trade-offs for a public volunteer run service like ours, it could still have value).

4

Yes, I thought it would be “nice to have”, but I see the issue with additional CN values (SubjectAlternativeName) and the like.

5

What exactly is missing in NTS to be usable in pool.ntp.org? Do we need the servers to be in multiple zones? Would a wildcard certificate not work?

For a start, I thought there could be a single experimental (e.g. nts-test.pool.ntp.org) zone, which would resolve to servers that support NTS. The pool system would generate a different certificate for each server, which would be valid for a short period of time (e.g. one week) and would have to be periodically updated. To make it a little bit more difficult for attackers, only servers that have at least one year of good history can be in the nts pool.

Is that not worth the trouble?

1 Like
6

I don’t think it’s worth the trouble, especially until NTS is finalized and implemented in more NTP packages / products.

7

The NTS specification has been published in RFC 8915. Some client/server implementations support it, and are already included in some Linux distributions, ready to be configured with/as NTS servers.

Any news about potential NTS support in pool.ntp.org?

I have few NTS-enabled servers using the nts-test.strangled.net name, if anyone is looking for more servers for testing. If I could get a certificate for an NTS-specific pool.ntp.org zone, I’d be happy to add it.