Current status

[Gary E. Miller]

Yo Hal!

On Mon, 11 Feb 2019 21:49:46 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

>  There is the start of the NTS-KE client and server.  The client does
> the TLS handshake, saves the cookies, sets up C2S and S2C, then
> ignores them.  The server returns fake cookies.

Cool.  Nice start.

> They are using TCP port 123.

Which always seemd what the IANA should use.

> It's the minimal I could get away with and get this far.  It doesn't
> pay attention to any of the configuration parameters.  (other than
> nts enable and server foo nts)

So much to do, gotta start somewhere...

> The server reads the certificate chain from /etc/ntp/cert-chain.pem
> The server reads the private key from /etc/ntp/key.pem

Which will, eventually, need to be configurable.  Plus, when needed, the
key to the kep.pem file, somewhere.

> There is lots of logging.  As much as possible, it blunders on after
> errors.

Best not to let that persist too lnng.

> The server runs in a separate thread.  It doesn't spawn a thread for
> each new connection so a DoS would be trivial.  I don't have timeouts
> working yet.  ...

Progress.
 
> The client doesn't run in a separate thread.  (We can copy what DNS
> does.)

Progress.

> The client checks the certificate using the system root certs.

Which also needs to be configuable, eventually.

> Are we interested in client certificates?  If so, why?

Absolutely.  But maybe last thing to do.  A big user, like AWS, will
want the options of allowing only some clients, with client certs, to
access the Stratum 1.

> struct ntsconfig_t has:
> /* Configuration data for an NTS server or client instance */
>     char *ca;                   /* site default */
>     char *cert;                 /* site default */
> 
> I assume that cert is the filename for the server's certificate
> chain.

Maybe, maybe not.  A lot of people do not like to make their own
chain files.  Then you need a filename for the ca, the chain, and
the cert.  Plus the key file and the, optional, key to the key file.

>  If so, the second "site default" is bogus.

Sometimes.  Depends on client, or server.  Both roles could be
present in one daemon.

> We need a slot in there for the private key.

And the key to the key.  Not common, but the paranoid want it.

> doc for ca says:
>   Use the file (or directory) specified by _location_ to
>   validate NTS-KE server certificates. This is a default
>   for all client and server connections.
> 
> OpenSSL has separate slots for root-cert dir and file.  How should I
> tell which?  Should we have separate config options?

Or just use stat():

https://stackoverflow.com/questions/4553012/checking-if-a-file-is-a-directory-or-just-a-file

> I think Fedora and Debian cat all the certs in a directory into a
> file and then use that for the default.  Sounds like a speedup.

Or not.  Gentoo creates a hash link to each so the daemon only needs to
open the right one.  So on Gentoo you need the directory name, not a
filename.

Also, remember certbot.  When they issue me a cert, they only use one
root.  To spare the daemon reading all the certs to find the root cert that
matches my client cert, I configure that one as a single, small, file.

> There is a similar ca slot per server.
>     char *ca;           /* if NULL, use the site default (normal
> case) */ Why?  Are we really interested in per server root certs for
> certificate checking?  If so, example please?

Very common in high security applications, or inside the firewall
apps where a normal root cert will not work.

If I am paranoid, there are a lot of paranoid people, or behind a
firewall where normal certs dont' work because you have no public name,
then you create your own root.


> I think it's ready for people to see if their certificates work.

I'd need the config file stuff first.  My Lets Encrypt (LE) certs
are in:

/etc/letsencrypt/live/rellim.com-0001/

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190212/ead7df31/attachment.bin>