Re: Authenticated TLS "contraints" in ntpd(8)
On Thu, Feb 12, 2015 at 02:05:59AM +1300, Carlin Bingham wrote: > On Wed, 11 Feb 2015, at 12:32 AM, Reyk Floeter wrote: > > Let me share the answer to a question that I got in a private mail: > > > > > On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote: > > >> ---snip--- > > >> servers pool.ntp.org > > >> constraints from "https://www.google.com/search?q=openntpd"; > > >> constraints from www.twitter.com > > >> constraint from www.apple.com > > >> ---snap--- > > >> > > > > > > Is the last "constraint" in singular pointing to www.apple.com valid or is > > > it a typo? > > > > > > > Yes, it is valid. As mentioned in the man page, it works like the > > existing server vs. servers for NTP peers. > > > > When a hostname or URL is specified, ntpd(8) will resolve the host. > > The singular version will use only one of the returned IP addresses > > and the plural version will use it as a pool and use all of the > > returned IP addresses. > > > > Following the example, a "dig A" on www.google.com or www.apple.com > > will typically show you a number of addresses, while the Akamai-hosted > > www.apple.com only returns one address near you. You're free to use > > any host, and some people might prefer to use their own trusted > > servers, I just picked some examples with good availability and > > seemingly good time. > > > > Reyk > > > > Using `constraints` I see it trying to query both the IPv4 addresses and > the IPv6 addresses that the hostname resolves to, even though the > machine has no IPv6 access. Is this expected? > Yes, it is. If the request to the IPv6 address fails, it will simply ignore the host. There is the AI_ADDRCONFIG flag in the resolver that does what you want. But I discussed it with Henning and we concluded that ntpd MUST NOT use it - the availability of IPv6 at startup does not necessarily mean that it will not be available later. ntpd is a long-running process that is also used on laptops etc. that move between networks but ntpd keeps on running. If you want to disable IPv6 lookups comepletely, put the following in your /etc/resolv.conf: family inet4 And remove "family inet6" if you happen to find it in the file. Reyk
Re: Authenticated TLS "contraints" in ntpd(8)
On Wed, 11 Feb 2015, at 12:32 AM, Reyk Floeter wrote: > Let me share the answer to a question that I got in a private mail: > > > On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote: > >> ---snip--- > >> servers pool.ntp.org > >> constraints from "https://www.google.com/search?q=openntpd"; > >> constraints from www.twitter.com > >> constraint from www.apple.com > >> ---snap--- > >> > > > > Is the last "constraint" in singular pointing to www.apple.com valid or is > > it a typo? > > > > Yes, it is valid. As mentioned in the man page, it works like the > existing server vs. servers for NTP peers. > > When a hostname or URL is specified, ntpd(8) will resolve the host. > The singular version will use only one of the returned IP addresses > and the plural version will use it as a pool and use all of the > returned IP addresses. > > Following the example, a "dig A" on www.google.com or www.apple.com > will typically show you a number of addresses, while the Akamai-hosted > www.apple.com only returns one address near you. You're free to use > any host, and some people might prefer to use their own trusted > servers, I just picked some examples with good availability and > seemingly good time. > > Reyk > Using `constraints` I see it trying to query both the IPv4 addresses and the IPv6 addresses that the hostname resolves to, even though the machine has no IPv6 access. Is this expected? -- Carlin
Re: Authenticated TLS "contraints" in ntpd(8)
On 02/10/2015 12:43 PM, Stuart Henderson wrote: On 2015/02/10 12:32, Reyk Floeter wrote: Let me share the answer to a question that I got in a private mail: On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote: ---snip--- servers pool.ntp.org constraints from "https://www.google.com/search?q=openntpd"; Cue google turning on captchas for searches for openntpd ;-) Won't the captcha page also include the date header? :)
Re: Authenticated TLS "contraints" in ntpd(8)
On Tue, Feb 10, 2015 at 11:19 PM, Reyk Floeter wrote: > On Tue, Feb 10, 2015 at 10:51:12PM -0700, Theo de Raadt wrote: >> So I gave Reyk some beer, and he did the impossible :-) >> > > I sense a pattern here. > > Reyk Not enough samples to be a pattern yet.. You shouldn't worry.. It's too bad supporting IkeV1 in your software is impossible.
Re: Authenticated TLS "contraints" in ntpd(8)
On Tue, Feb 10, 2015 at 10:51:12PM -0700, Theo de Raadt wrote: > So I gave Reyk some beer, and he did the impossible :-) > I sense a pattern here. Reyk
Re: Authenticated TLS "contraints" in ntpd(8)
> * Henning Brauer [2015-02-10 13:21]: > > * Kevin Chadwick [2015-02-10 13:14]: > > > On Tue, 10 Feb 2015 10:55:53 +0100 > > > Reyk Floeter wrote: > > > > The standardized attempts to add authentication to NTP are a) fairly > > > > horrible (ASN.1 etc.) and b) rarely deployed. > > > When ntpd acts as a server, could the package signing code be of use > > > with ntpd keys? > > getting the signature into the ntp packets in a way that doesn't break > > compatibility is the challenge. > > let me elaborate slightly: even if we came up with a überauth > mechanism that doesn't suck and doesn't break compat, it wouldn't be > of much use unless the servers you sync from support it - one of the > pools for most. even if you could completely trust them and whatever > model of key distribution, for them to support this, you have to get it > standarized. and even if we managed to get it pushed through the > standards corpses^Wbodies, it would take ages until it gets deployed, > IF it ever gets widely deployed. > That's a lot of ifs, I leave the judgement on likeliness to you. > > constraints from https, however - that works today. So full disclosure, this was my idea, though Reyk wrote the code. I was struck by how 2 decades ago there was common practice to use "rdate -a", thus using the RFC 868 timed protocol. It is a one-shot, triggering a slide using the kernel adjtime system call. Then ntp showed up, kind of but it was heavy, and it became more common practice to have small machines do rdate -an. Once again, it is a one-shot, triggering a slide using the kernel adjtime system call. Such practice was good enough for most uses. Some people did this in cron. ntp was just too large to compile, too complicated for automatic setup, so it was rarely used back in those days. Some time went by, and more people started using official NTP, but we wavered, not liking the sourc code. Finally openntpd arrived, designed to be light and secure -- enough so we could run it in all circumstances. It contains protection against NTP packet spoofing, but cannot solve the NTP protocol MITM problems. Recently, tlsdate showed up, which is basically rdate -TLS, and perhaps it has an option like "-a", but still that would be the one-shot triggering a slide in the kernel. Solving nothing new really in terms of time quality... However it struck me that we could use such a method to authenticate information learned from NTP sources. As long as the information was handled correctly in one daemon. Asyncronously, and very carefully, using the privsep model for safety. So I gave Reyk some beer, and he did the impossible :-)
Re: Authenticated TLS "contraints" in ntpd(8)
* Henning Brauer [2015-02-10 13:21]: > * Kevin Chadwick [2015-02-10 13:14]: > > On Tue, 10 Feb 2015 10:55:53 +0100 > > Reyk Floeter wrote: > > > The standardized attempts to add authentication to NTP are a) fairly > > > horrible (ASN.1 etc.) and b) rarely deployed. > > When ntpd acts as a server, could the package signing code be of use > > with ntpd keys? > getting the signature into the ntp packets in a way that doesn't break > compatibility is the challenge. let me elaborate slightly: even if we came up with a überauth mechanism that doesn't suck and doesn't break compat, it wouldn't be of much use unless the servers you sync from support it - one of the pools for most. even if you could completely trust them and whatever model of key distribution, for them to support this, you have to get it standarized. and even if we managed to get it pushed through the standards corpses^Wbodies, it would take ages until it gets deployed, IF it ever gets widely deployed. That's a lot of ifs, I leave the judgement on likeliness to you. constraints from https, however - that works today. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Authenticated TLS "contraints" in ntpd(8)
On Tue, 10 Feb 2015 13:03:27 + David Dahlberg wrote: > > > The standardized attempts to add authentication to NTP are a) fairly > > > horrible (ASN.1 etc.) and b) rarely deployed. > > > > When ntpd acts as a server, could the package signing code be of use > > with ntpd keys? > > How exactly? You cannot use signing for PSK, Private Cert GK as they > require peer-to-peer shared secrets. The rest of the autokey protocols > do not provide any usable identity checks anyway. Nice read: > http://zero-entropy.de/autokey_analysis.pdf > > The HTTPS-based scheme is at least able to link a rough time constraint > to a PKI (which autokey is not even able to do) and it follows the > general design approach of OpenNTPd: Being simple and good enough for > most use cases. I was meaning just for internal OpenBSD use between ntpds really (you would still need a trusted or checked source with a decent crystal) without resorting to handing axes out, outside the standards meeting with the time_t pdf link enscribed in the handle ;-).
Re: Authenticated TLS "contraints" in ntpd(8)
Am Dienstag, den 10.02.2015, 12:35 + schrieb Kevin Chadwick: > On Tue, 10 Feb 2015 10:55:53 +0100 > Reyk Floeter wrote: > > > The standardized attempts to add authentication to NTP are a) fairly > > horrible (ASN.1 etc.) and b) rarely deployed. > > When ntpd acts as a server, could the package signing code be of use > with ntpd keys? How exactly? You cannot use signing for PSK, Private Cert GK as they require peer-to-peer shared secrets. The rest of the autokey protocols do not provide any usable identity checks anyway. Nice read: http://zero-entropy.de/autokey_analysis.pdf The HTTPS-based scheme is at least able to link a rough time constraint to a PKI (which autokey is not even able to do) and it follows the general design approach of OpenNTPd: Being simple and good enough for most use cases. -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Authenticated TLS "contraints" in ntpd(8)
* Kevin Chadwick [2015-02-10 13:14]: > On Tue, 10 Feb 2015 10:55:53 +0100 > Reyk Floeter wrote: > > The standardized attempts to add authentication to NTP are a) fairly > > horrible (ASN.1 etc.) and b) rarely deployed. > When ntpd acts as a server, could the package signing code be of use > with ntpd keys? getting the signature into the ntp packets in a way that doesn't break compatibility is the challenge. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Authenticated TLS "contraints" in ntpd(8)
On Tue, 10 Feb 2015 10:55:53 +0100 Reyk Floeter wrote: > The standardized attempts to add authentication to NTP are a) fairly > horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys?
Re: Authenticated TLS "contraints" in ntpd(8)
On 2015/02/10 12:32, Reyk Floeter wrote: > Let me share the answer to a question that I got in a private mail: > > > On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote: > >> ---snip--- > >> servers pool.ntp.org > >> constraints from "https://www.google.com/search?q=openntpd"; Cue google turning on captchas for searches for openntpd ;-)
Re: Authenticated TLS "contraints" in ntpd(8)
Let me share the answer to a question that I got in a private mail: > On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote: >> ---snip--- >> servers pool.ntp.org >> constraints from "https://www.google.com/search?q=openntpd"; >> constraints from www.twitter.com >> constraint from www.apple.com >> ---snap--- >> > > Is the last "constraint" in singular pointing to www.apple.com valid or is > it a typo? > Yes, it is valid. As mentioned in the man page, it works like the existing server vs. servers for NTP peers. When a hostname or URL is specified, ntpd(8) will resolve the host. The singular version will use only one of the returned IP addresses and the plural version will use it as a pool and use all of the returned IP addresses. Following the example, a "dig A" on www.google.com or www.apple.com will typically show you a number of addresses, while the Akamai-hosted www.apple.com only returns one address near you. You're free to use any host, and some people might prefer to use their own trusted servers, I just picked some examples with good availability and seemingly good time. Reyk
Authenticated TLS "contraints" in ntpd(8)
Hi! Theo, Henning, and me developed an idea to utilize TLS in some way for authenticated time in ntpd(8). We are not intending to use it as a direct time source, but as a "constraint" to verify the NTP responses. I came up with an implementation that has been designed to be an optional, non-intrusive feature that is now part of OpenBSD -current. >From the ntpd.conf(5) man page: "ntpd(8) can be configured to query the `Date' from trusted HTTPS servers via TLS. This time information is not used for precision but acts as an authenticated constraint, thereby reducing the impact of unauthenticated NTP `Man-In-The-Middle' attacks. Received NTP packets with time information falling outside of a range near the constraint will be discarded and such NTP servers will be marked as invalid." The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. HTTPS is most widely deployed and provides a reference time in the Date: header. The resolution is not good enough as a time source, only seconds and it does not consider network and I/O delays, but it is good enough to provide bounds that can be used to verify the NTP responses. We only use the time from the HTTPS header, and not the TLS timestamp, as the latter is most possibly randomized in modern SSL/TLS implementations. To test it, you can configure one or more HTTPS URLs or hosts in your ntpd.conf that will be queried upon startup of ntpd. Any HTTPS URL would work and the path is fully optional. The server certificate is currently verified against the CA certificates in /etc/ssl/cert.pem; a self-signed certificate would not work unless you add your own CA to the file. ---snip--- servers pool.ntp.org constraints from "https://www.google.com/search?q=openntpd"; constraints from www.twitter.com constraint from www.apple.com ---snap--- The feature is still experimental and we're continuing to improve the semantics. But it is already fully functional and ready to be tested. The HTTPS client requests are executed in independent processes that are fully isolated from each other and from the NTP processes - a strict separation protects the daemon from any potential failures in the TLS execution. Related commit: http://marc.info/?l=openbsd-cvs&m=142355043928397&w=2 Have fun with catching the "outliars"! Reyk
