Current status

[Gary E. Miller]

Yo Hal!

On Tue, 12 Feb 2019 23:14:47 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> Gary said:
> >> 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.   
> 
> The code to configure file names is in there now.

Cool.

> Unless somebody objects or has a better idea, I'll implement Richard
> Laager suggestion to disable the NTS-KE server if it can't read the
> certificate and key.

I can't think of any other option.  Is there?

> I don't see how to implement your file for key to key file.  There is
> no API for that.  Besides, that doesn't seem like the right
> approach.  If you want to startup without typing in something, make
> the key file without a password.  Am I missing something?

I agree it is a very uncommon option.  Something to do last, if ever.

Programs like Apache httpd do a apassphrase dialog at startup if the
private key file needs a password.  Then they allow you to select
how that dialog happens with SSLPassPhraseDialog directive.  The admin
sets that directive to run a program that outputs the required
passphrase.

> >> 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.   
> 
> Does that work and/or is there a simpler way?  Why not filter on IP
> Address? Is the existing restrict stuff good enough?

Many ways to skin the cat.  Client certificates are a common way in
corporate environments.  IP filtering does not work well in a modern
world of dynamic addresses and roving laptops.

Once again, a low priority, but it will happen.

> > 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.   
> 
> The API is that you give it a chain rather than just a simple cert.

One way to do it.  Not the most common.  OK to start with, not OK
in production.  Look at the Apache httpd doc to see many other ways
to do it (with OpenSSL).

A lot of users are simply incapable of making their own cert chain.
Fancy deployments need to many chains to make them practical.

> The chain TLS client gives the chain to the server.  The chain has
> the cert and any intermediate certs needed to get to the root.  There
> may be no intermediate certs.  That would be a chain of one rather
> than what may be typical two.

What is a "chain TLS client"?

Also, look at Apache httpd.  They have an option to specify how many
hops up the chain to check.

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/20190213/57d2d784/attachment.bin>