Bug#687166: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default
Hi, * Ask Bjørn Hansen a...@ntppool.org [2012-09-11 01:01]: On Sep 10, 2012, at 15:07, Kurt Roeckx k...@roeckx.be wrote: [...] So my understanding of things is that even if we also had a way to distribute all the public keys, you still can't get it to work as you need to provide each client with a secret key. I think what first needs to be done is have an autokey implementation that either doesn't need a private key for each client but is secure or doesn't need state on the server side for each client. Indeed; I thought ntpd had a public key encryption scheme where we just need the secret key on the server[1] and the public key can be general for all Debian users. (I think that's the 'autokey' scheme -- the trustedkey/requestkey stuff is where you share a secret between client and server). That was my understanding as well. At least the documentation states: key pairs are used where establishing shared secrets is difficult. The autokey mechanism uses key pairs.. Cheers Nico pgpbjwzet5yC2.pgp Description: PGP signature
Bug#687166: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Tue, Sep 11, 2012 at 12:49:09PM +0200, Nico Golde wrote: Hi, * Ask Bjørn Hansen a...@ntppool.org [2012-09-11 01:01]: On Sep 10, 2012, at 15:07, Kurt Roeckx k...@roeckx.be wrote: [...] So my understanding of things is that even if we also had a way to distribute all the public keys, you still can't get it to work as you need to provide each client with a secret key. I think what first needs to be done is have an autokey implementation that either doesn't need a private key for each client but is secure or doesn't need state on the server side for each client. Indeed; I thought ntpd had a public key encryption scheme where we just need the secret key on the server[1] and the public key can be general for all Debian users. (I think that's the 'autokey' scheme -- the trustedkey/requestkey stuff is where you share a secret between client and server). That was my understanding as well. At least the documentation states: key pairs are used where establishing shared secrets is difficult. The autokey mechanism uses key pairs.. So after reading some more, I think the only option we have is using the IFF identity scheme. But I seem to be failing in getting it working. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687166: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Mon, Sep 10, 2012 at 06:18:42PM +0200, Nico Golde wrote: Hi, * Ask Bjørn Hansen a...@ntppool.org [2012-09-10 18:03]: On Sep 10, 2012, at 8:13, Nico Golde n...@debian.org wrote: [Adding NTP authentication] We could setup a set of servers with authentication, but that'd be a much smaller list of servers (for better and worse). It wouldn't be like the current NTP Pool at all. Next would be to add DNSSEC to the DNS (which is non-trivial with the current zone and the current resources; at peaks the DNS servers get 20-30k qps and each response is different so you have to sign in real-time.). If there's a need and resources, I could run a zone with DNSSEC and with autokey configured, but it'd not be possible in the open source/everyone volunteers a resource or two scheme. Wouldn't it still make sense to have a zone configured with autokey even without DNSSEC? Or is an active attacker bombarding the victim with faked NTP responses without spoofed DNS not an issue at all, so all this matters *only* if DNS is spoofed? Autokey does several things, the most important of those is to authenticate the peer your're talking too. I don't see DNSSEC adding anything useful if autokey is used, unless we also want to distribute the public keys via DNS. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687166: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default
Hi Kurt, Of course you are right. DNSSEC will help a different use case. That leaves us the first problem of the keys having to be secret which is impossible if random servers are hosting them. If the Debian project had a set of servers with autokey configured that should be used for ntp.debian.org or auth.debian.pool.ntp.org or some such then we could setup the NTP Pool system to do the monitoring and DNS for those. Ask -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687166: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Mon, Sep 10, 2012 at 02:06:52PM -0700, Ask Bjørn Hansen wrote: Hi Kurt, Of course you are right. DNSSEC will help a different use case. That leaves us the first problem of the keys having to be secret which is impossible if random servers are hosting them. If the Debian project had a set of servers with autokey configured that should be used for ntp.debian.org or auth.debian.pool.ntp.org or some such then we could setup the NTP Pool system to do the monitoring and DNS for those. I'm not sure Debian wants to run ntp.debian.org. We would need to ask people to donate resources for that, and the pool project already exists for that. We do internally run autokey between *.debian.org hosts, but that's not for other people to query. I don't really understand autokey. But from reading things I understand there are 4 authentication scheme's and 5 identity schemes and it works in groups, and clients would need to have secret keys that belong to the same group. So my understanding of things is that even if we also had a way to distribute all the public keys, you still can't get it to work as you need to provide each client with a secret key. I think what first needs to be done is have an autokey implementation that either doesn't need a private key for each client but is secure or doesn't need state on the server side for each client. If you want to drop state for each client in the server, I think that's going to require the client to send it's public key for each query. In any case, I think this is going to significatly increase bandwidth and cpu usage on the servers. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687166: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Sep 10, 2012, at 15:07, Kurt Roeckx k...@roeckx.be wrote: I'm not sure Debian wants to run ntp.debian.org. We would need to ask people to donate resources for that, and the pool project already exists for that. Indeed! Sorry I wasn't clear. The NTP Pool system can work on other domains than pool.ntp.org, so with a few NS pointers *.ntp.debian.org could be the NTP Pool but only including hosts configured and monitored to the debian specifications (including autokey etc as appropriate). Then the pool system can still do the monitoring, automatically update DNS, point clients to nearby servers, etc. [...] So my understanding of things is that even if we also had a way to distribute all the public keys, you still can't get it to work as you need to provide each client with a secret key. I think what first needs to be done is have an autokey implementation that either doesn't need a private key for each client but is secure or doesn't need state on the server side for each client. Indeed; I thought ntpd had a public key encryption scheme where we just need the secret key on the server[1] and the public key can be general for all Debian users. (I think that's the 'autokey' scheme -- the trustedkey/requestkey stuff is where you share a secret between client and server). Ask [1] But those servers obviously have to be run by especially trusted people as they need to know the secret and be okay with the increased resource requirements etc. I figure in the Debian community you could find/pick a few dozen servers suitable for that which likely would be enough. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
