Bug#687166: [pkg-ntp-maintainers] Bug#687166: Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Tue, Sep 11, 2012 at 09:23:45PM +0200, Kurt Roeckx wrote: 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. So the problem is that autokey does not work over NAT. So I don't think it's going to be a good idea to try to turn this on by default. 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: Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Tue, Sep 18, 2012, at 01:03 PM, Kurt Roeckx wrote: On Tue, Sep 11, 2012 at 09:23:45PM +0200, Kurt Roeckx wrote: 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. So the problem is that autokey does not work over NAT. So I don't think it's going to be a good idea to try to turn this on by default. Agreed. What else could we do? NTP upstream bug report? Or a more general debian bug need secure replacement for NTP? Against which component? -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html -- 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, * 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: ntp: NTP security vulnerability because not using authentication by default
Package: ntp Version: 1:4.2.6.p3+dfsg-1ubuntu3.1 Severity: normal Tags: security Debian implements so much security one way or another. So much defenses against network level man in the middle or malicious proxies or wifi hotspots. Cryptographic verification generally works well but there is one big drawback: it requires correct date/time. NTP in Debian does not use any authentication by default, although it is supported by NTP. I conclude, that almost no one is using authenticated NTP, because there are no instructions in a forum or blog how to enable NTP authentication. Therefore almost everyone uses standard configuration and is at risk. An adversary can tamper with the unauthenticated NTP replies and put the users time several years back, especially, but not limited, if the bios battery or hardware clock is defect. That issue becomes more relevant with new devices like RP, which do not even have a hardware clock. Putting the clock several years back allows an adversary to use already revoked, broken, expired certificates; replay old, broken, outdated, known vulnerable updates etc. Suggested solutions: - NTP supports public and private keys: http://doc.ntp.org/4.1.0/genkeys.htm Use it. - Write easy documentation how to host an authenticated NTP server. - Write easy documentation how to use an authenticated NTP server. - Add gui optoins for using authenticated NTP. - Debian could run their own authenticated NTP server. - Debian has importance. You could officially ask the NTP pool if they could add authentication. - Debian could publicly the problem and ask the community for help. - I am sure some NTP server volunteers would like to add authentication, if you can provide clear instructions for them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687166: ntp: NTP security vulnerability because not using authentication by default
Hi, * none anots...@fastmail.fm [2012-09-10 15:42]: [...] An adversary can tamper with the unauthenticated NTP replies and put the users time several years back, especially, but not limited, if the bios battery or hardware clock is defect. That issue becomes more relevant with new devices like RP, which do not even have a hardware clock. Putting the clock several years back allows an adversary to use already revoked, broken, expired certificates; replay old, broken, outdated, known vulnerable updates etc. NTP is certainly subject to spoofing attacks by its nature. I also agree that this may be a problem in some settings. Just considering that e.g. kerberos is making heavy use of accurate timing. In theory NTP should be robust against wrong timing information from single servers. Obviously this doesn't help you, if your DNS is also spoofed and you control all NTP servers. Since NTP does support symmetric/autokey by now, what I really wonder about is why this is no strict requirement for servers in pool.ntp.org to which certainly also our debian ntp vendor zone belongs. I think it would be desirable to ship default configurations with those keys setup. I CC'ed Ask who is maintaining pool.ntp.org for this discussion. Ask, is there such a requirement and I missed it or is it not existent? If not, how realistic is it to change this? While I don't think this is a critical problem, I'd also love to see this changed in future default configurations of the ntp package in Debian. Kind regards Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 pgp0T1Xk5sldC.pgp Description: PGP signature
Bug#687166: ntp: NTP security vulnerability because not using authentication by default
On Sep 10, 2012, at 8:13, Nico Golde n...@debian.org wrote: Hi, [Adding NTP authentication] I CC'ed Ask who is maintaining pool.ntp.org for this discussion. Ask, is there such a requirement and I missed it or is it not existent? If not, how realistic is it to change this? Completely unrealistic with volunteer/public servers, sadly. If you give it a bit of thought you'll realize it can't work. :-) If we were to add authentication to the pool.ntp.org system, everyone would have to know the key so it'd not serve any purpose at all. 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. 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: ntp: NTP security vulnerability because not using authentication by default
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? Kind regards Nico P.S: I'm all but an NTP expert :) -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 pgpK8YFLPvxan.pgp Description: PGP signature
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
