Description of problem:
ntpd has lots of old, outdated code for unused protocols and ideas that make it less secure and harder to maintain.
ntpsec is a modern project that forked ntpd and removed the unused and unmaintained code. This removed over 70% of the code while maintaining full client and server compatibility with ntpd. It has also improved security by removing keywords and commands that did not contribute features but caused security problems.
As I understand it, ntpsec removed support for some (less useful) modes of the NTP protocol and is not intended to be a fully compatible drop-in replacement for ntp. We already have an alternative NTP implementation in RHEL7 which doesn't support all NTP modes. It performs better and so far has been more secure than ntp.
As a maintainer of the two NTP packages, I'm not sure if adding and maintaining ntpsec as a third NTP package would make sense. That could change if it had some unique features and could replace one or both of the packages. In any case, this should probably not be discussed as a bug of the ntp component.
It's now 2019....considering the number of attacks against NTP has endured from when this RFE was posted until now that NTPSEC either was immune to by default (90% of the time) or responded to more quickly, I would consider ntpsec a viable option to be brought into the official repos. You will need ntp.conf and ntpd already on the system (installed via the ntp package) but you could bundle those into the ntpsec package if you wanted or just make ntp a pre-req and a quick how-to to remove the ntp package without removing the service daemon or configuration file before installing ntpsec. Or just automate the install by automatically installing ntp, then the dependencies brought in by ./buildprep, then removing everything from ntp other than the needed components already specified, then install ntpsec. It's not a very painful procedure when done manually but when wanting to implement on a number of systems across the network (all RHEL/CENT/FED), the use of a package performing the steps outlined would be a faster and preferred route. Debian already has a package if you want to see what they did in Testing and SID (same package, just different repo).
Your comment about immunity to ntp attacks applies also to chrony (https://www.coreinfrastructure.org/blogs/securing-network-time/), which is the default NTP client in RHEL-7. We are also concerned about the security issues in ntp and as a result, ntp has been removed from the distribution since RHEL-8.0 Beta and NTP client / server functionality is covered by chrony package.
I would like NTPSEC offered as an alternative. I understand it not being the default but the link you refer to contains severely outdated information. I question whether chrony still remains the best. Plus there are use cases in which chrony doesn't cover but ntpsec could (in lieu of ntp). In the environment I'm in, we use ntp not chrony. I could make the argument to switch to chrony but while better than ntp, would require more work as ntpsec can use currently existing configurations and services. Chrony will require more time and effort to implement. Due to the fast-pace we need to maintain for implementing new features for the network and addressing bugs for internal projects, having a quick means of deployment is a requirement. NTPSEC can address this better than Chrony at this point in time. More importantly, the decrease in time differentials between ntp and ntpsec (which chrony has also) would be appreciated for our security monitoring tool as we prefer to be as precise as possible with our real-time alerts.
I'm not sure how you come to the conclusion that chrony takes more time to implement. The config files are essentially compatible, so you can simply install the chrony package, copy the /etc/ntp.conf to /etc/chrony.conf and it basically works. If you have something more complicated that requires conversion of config files, then I think that'll probably apply to the cut down features of NTPSEC as well. If you could detail the specific problems you have with converting to using chrony, then we may be able to help you there.
I agree that it would be good to provide NTPSEC as an alternative to Chrony, but I don't think that's because NTPSEC is somehow easier to implement, whether coming from an existing NTP environment or if starting afresh.
There is also a script that can automatically convert existing ntp configuration to chrony, including files like /etc/ntp/step-tickers and /etc/ntp/keys.
Thanks for the clarification. None of the info I researched on chrony really mentioned simply taking the configuration from ntp.conf to chrony.conf. It's something I will need to consider. Though I've read each has their own particular platforms they work best on. It would be very helpful if somebody had benchmarks for time efficiency and pen test results comparing the two.
" We are also concerned about the security issues in ntp and as a result, ntp has been removed from the distribution since RHEL-8.0 Beta and NTP client / server functionality is covered by chrony package."
Is there an official notice or will there be an official notice sent out regarding the dropping of ntp classic from RHEL and Fedora? My organization would like to see this before considering making a switch to either chrony or ntpsec.
The removal of ntp is mentioned in the RHEL 8.0 Beta release notes: