Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On Mon, May 04, 2020 at 04:44:00PM +, Zbigniew Jędrzejewski-Szmek wrote: > Aside: the PEERNTP option seems to be very weakly documented. After > some searching I found [1, 2] and [3]. Some up-to-date documentation would > be necessary if users are expected to configure this. Ok. I filed bug #1831542 to improve the documentation. > It sounds like PEERNTP should be a per-interface setting. If I'm > connecting to a trusted network or VPN, I might want to use and trust > the provided NTP servers. If connecting to a public network, don't trust > and use NTS to verify servers. You could do that. PEERNTP can be set for each interface in the corresponding /etc/sysconfig/network-scripts/ifcfg-* file. However, as was suggested earlier in the thread, there will likely be a new upstream option in chrony to globally control mixing of unauthenticated and authenticated NTP sources, so PEERNTP doesn't have to be disabled when all NTP servers from DHCP are not to be trusted, e.g. because they are not expected to authenticate their upstream servers. > Also, what software supports /etc/sysconfig/network? I think we currently > have initscripts-network, NetworkManager, systemd-networkd in Fedora. It works with the initscripts and NetworkManager. For systemd-networkd there is no dispatcher mechanism in Fedora, so NTP servers provided by DHCP are ignored when using systemd-networkd with chrony or ntp. In Debian and Ubuntu there is a networkd-dispatcher service for that. > > An option could be added to disable the time checks before the > > first update of the clock. This would have an impact on security. > > ... how would that look? It'd need support in chrony itself, right? > Would upstream accept such code? Yes. It's already supported upstream and in our latest rawhide package. The time checks can be disabled with the NoCertTimeCheck directive in chrony.conf. The idea is that anaconda will set it when no RTC is found or it has no battery backup (if can we detect that). -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
Hi, sorry for thread necromancy... On Wed, Apr 08, 2020 at 10:42:09AM +0200, Miroslav Lichvar wrote: > What I meant, if someone for example had at home a stratum 1 server > (e.g. synchronized to GPS) and they trusted everything and everyone in > their local network, it would make sense to still use the server > (without NTS) in addition to any external time servers authenticated > by NTS. > > The question is if we need to change the default value of the PEERNTP > option. There could be a new default which adds the servers provided > by DHCP only if chronyd is not using any servers with enabled > authentication. Aside: the PEERNTP option seems to be very weakly documented. After some searching I found [1, 2] and [3]. Some up-to-date documentation would be necessary if users are expected to configure this. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-understanding_the_ntpd_configuration_file [2] https://docs.fedoraproject.org/en-US/Fedora/26/html/System_Administrators_Guide/s1-Understanding_the_ntpd_Configuration_File.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=809367 It sounds like PEERNTP should be a per-interface setting. If I'm connecting to a trusted network or VPN, I might want to use and trust the provided NTP servers. If connecting to a public network, don't trust and use NTS to verify servers. Also, what software supports /etc/sysconfig/network? I think we currently have initscripts-network, NetworkManager, systemd-networkd in Fedora. From the original proposal: > Computers with no RTC (e.g. some ARM boards), or RTC that is too far > from the real time, will fail to verify TLS certificates. Making NTP not work on boards without RTC could impact a large number of such users, and also those who have flaky RTCs. Right now they can simply use NTP to update the clock after boot, and with this proposal that'd be broken... In my experience, bug reports that stem from broken RTC are somewhat frequent (e.g. journalctl doesn't handle the case of a jumping clock very well, and we get reports about this fairly regularly). So I think handling the no-RTC case gracefully would be a requirement to make NTS enabled by default. > An option could be added to disable the time checks before the > first update of the clock. This would have an impact on security. ... how would that look? It'd need support in chrony itself, right? Would upstream accept such code? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On Thu, Apr 09, 2020 at 02:08:46PM -0500, Brandon Nielsen wrote: > Additionally, the 'nts' option for 'server' and 'pool' directives, to me, > does not make it immediately clear that NTS will be required for _all_ NTP > servers. To me, that option implies that NTS will be enforced for that > particular pool or server. Especially since I can have additional directives > without that option set (which admittedly makes little sense). Yes, the nts option is specific to the source. Sometimes it makes sense to mix non-NTS and NTS sources (e.g. in the case with trusted network), but probably more commonly it does not. > Finally, the suggestion of bootstrapping NTP without using NTS when TLS > checks fail concerns me. It needs to be clear when such a thing is allowed > or not. The suggestion was to disable the TLS time check, not TLS+NTS completely. > I would be much happier with some kind of `requireents` option in > `/etc/chrony.conf`. When set, NTS is an absolute hard requirement, no plain > NTP servers will be used (from DHCP or otherwise), NTP bootstrapping > mentioned above would also be forbidden. When not set, NTS is still verified > for cases where the option is set, but other NTP servers still work > (bootstrapping allowed?). Good idea. An upstream option to control mixing of authenticated and non-authenticated sources would make sense to me. This would nicely minimize downstream-specific changes. I think it might have more than just two settings (enabled, disabled) and we'll need to figure out where exactly it should be controlled (e.g. configuration, measurements, or source selection). Thanks, -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/9/20 11:06 AM, Miroslav Lichvar wrote: On Wed, Apr 08, 2020 at 02:09:01PM -0500, Brandon Nielsen wrote: On 4/8/20 3:42 AM, Miroslav Lichvar wrote: What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) I'm not saying there is necessarily an issue, just a logical inconsistency. If the DNS servers provided by DHCP are trusted, why would any plain NTP servers also provided by DHCP not be trusted? I can do nefarious things with either. I think it depends on the network. Is it yours or is it a random hotspot? In general neither should be trusted, but most applications don't rely on DNS being secure, so using random untrusted DNS servers from DHCP is usually not a major issue. I'm ignoring privacy issues. I disagree with saying applications don't rely on DNS being secure, but I also concede it has very little to do with this discussion. See my off-topic rant in my reply to Björn Persson. I apologize for conflating the issue in the first place. [snip] The PEERNTP option will still work. It may just have a different default and/or have a new setting. Circling back to my concerns about this proposal from an admin standpoint. I have never needed to touch PEERNTP before for DHCP provided NTP to work. I'm also not sure from a security standpoint I want `PEERNTP=yes` to work if NTS is otherwise enabled? Seems potentially confusing. I don't like chrony behavior being dictated by non-chrony config. Additionally, the 'nts' option for 'server' and 'pool' directives, to me, does not make it immediately clear that NTS will be required for _all_ NTP servers. To me, that option implies that NTS will be enforced for that particular pool or server. Especially since I can have additional directives without that option set (which admittedly makes little sense). Finally, the suggestion of bootstrapping NTP without using NTS when TLS checks fail concerns me. It needs to be clear when such a thing is allowed or not. I would be much happier with some kind of `requireents` option in `/etc/chrony.conf`. When set, NTS is an absolute hard requirement, no plain NTP servers will be used (from DHCP or otherwise), NTP bootstrapping mentioned above would also be forbidden. When not set, NTS is still verified for cases where the option is set, but other NTP servers still work (bootstrapping allowed?). Logging would help make clear what's going on, if the `nts` option is set on a pool or server with `REQUIREENTS` off, we could log warnings when non-NTS servers are used. And with `REQUIREENTS` on, we could log warnings about servers that were ignored due to not supporting NTS (including the DHCP provided one). The PEERNTP option would function as usual, not passing DHCP provided NTP servers to chrony if disabled. It would have no additional influence over chrony behavior, chrony behavior would remain entirely controlled by it's own configuration file. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/9/20 10:42 AM, Björn Persson wrote: [snip] Fedora's defaults should be chosen to keep users reasonably secure every way we can. If you as a sysadmin trust the DHCP server and every other device on the local network – including any device that may be connected in the future – then you should have the option to configure the system to trust DHCP-provided NTP and DNS servers. Björn Persson That's one part of my complaint (which, admittedly, doesn't have much to do with this proposal). We seem to be trending toward some awkward one-size-fits-some semi-trust system where parts of the network are trusted as provided, and other parts aren't. What I would love to see take shape instead (and again, I acknowledge this has almost nothing at all to to with this proposal) is the ability for users to easily mark networks as trusted or untrusted, with trusted networks using network provided resources, and the system firewall wide open (the current workstation default). On untrusted networks, DNSSEC / DoH / DoT (rough order of preference) used for DNS from a trusted resolver, NTS, firewall locked down, and maybe even a connection to a VPN automatically established if configured by the user. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On Wed, Apr 08, 2020 at 02:09:01PM -0500, Brandon Nielsen wrote: > On 4/8/20 3:42 AM, Miroslav Lichvar wrote: > > What is the issue with using untrusted DNS servers here? An NTS client > > is supposed to verify the certificates. Local MITM attackers shouldn't > > be able to force the client to synchronize to a different NTP server. > > (Of course, they can always disable the synchronization.) > > > > I'm not saying there is necessarily an issue, just a logical inconsistency. > If the DNS servers provided by DHCP are trusted, why would any plain NTP > servers also provided by DHCP not be trusted? I can do nefarious things with > either. I think it depends on the network. Is it yours or is it a random hotspot? In general neither should be trusted, but most applications don't rely on DNS being secure, so using random untrusted DNS servers from DHCP is usually not a major issue. I'm ignoring privacy issues. > Generally speaking, on a network I admin, if I've configured DHCP to provide > things like NTP and DNS servers, it's because I intend client devices to use > those things. While some devices choose to ignore DHCP provided DNS (and > NTP), I can still reroute those requests at the edge router. Is that also > possible with NTS? Even if it gets rerouted to a plain NTP server? No, an NTS-enabled client cannot be redirected to a different server (using a different certificate or NTS keys). That would be a security issue. It's similar to DNS over HTTPS. > I feel like if this is on by default we're basically saying nobody trusts > any provided NTP server unless it supports NTS. If that's the case, do away > with the 'trusted network' verbiage and just say that only NTS servers > provided over DHCP will be used. The NTP option in DHCP doesn't provide the client with a name of the server (at least in IPv4), so it couldn't try NTS even if it wanted. > Additionally, what about the no-internet case? Will a local, non-NTS NTP > server be acceptable in that case? I feel like that would be handled by the > change to PEERNTP you mention above. But then can't attackers "disable the > synchronization" as you mention above, essentially forcing us back to no > additional security? I think the installer could verify that NTS works (which implies working Internet connection) and if not, it would leave PEERNTP enabled. > > It would still work, even if we didn't use it by default. The name is > > just an alias for pool.ntp.org. The servers used in the current > > default configuration are not run by Fedora. > > > > Does the alias provide no additional functionality? Does it help with an > estimate of running Fedora machines in the wild? The alias is a "vendor" zone to give the pool admins some control in case our NTP clients create too much traffic and need to be stopped. I think the admins have some statistics on DNS traffic in specific zones, but I'm not privy to the data. > Will there be some kind of 'canary domain' like there is for DoH > (use-application-dns.net)? I don't think I saw any suggestions for implementing that. > Again from a network admin standpoint, if I > provide a local NTP server without NTS, I want an easy way to tell the > devices I manage to use it. The PEERNTP option will still work. It may just have a different default and/or have a new setting. -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
Brandon Nielsen wrote: > If the DNS servers provided by DHCP are trusted, why > would any plain NTP servers also provided by DHCP not be trusted? I can > do nefarious things with either. For DNS the solution is to not trust the DHCP-provided resolvers but validate DNSsec locally. A valid chain of DNSsec signatures tells you that the DNS record is authentic regardless of what servers it passed through on its way to you. Then you can use a DHCP-provided resolver without trusting it because the only nefarious thing it can do is to refuse to resolve a name for you, which just makes it a broken resolver. A similar approach for NTP would be if the stratum-1 servers would sign timestamps that secondary servers would cache and forward to clients, but caching timestamps doesn't work because the nature of a clock is that the time changes all the time. Thus I don't see how you can get out of trusting the NTP servers you use. Fedora's defaults should be chosen to keep users reasonably secure every way we can. If you as a sysadmin trust the DHCP server and every other device on the local network – including any device that may be connected in the future – then you should have the option to configure the system to trust DHCP-provided NTP and DNS servers. Björn Persson pgpBIghKNvC8u.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/8/20 3:42 AM, Miroslav Lichvar wrote: On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: It doesn't make much sense to me for this to default to on if we still "trust" the DNS servers provided over DHCP. What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) I'm not saying there is necessarily an issue, just a logical inconsistency. If the DNS servers provided by DHCP are trusted, why would any plain NTP servers also provided by DHCP not be trusted? I can do nefarious things with either. Generally speaking, on a network I admin, if I've configured DHCP to provide things like NTP and DNS servers, it's because I intend client devices to use those things. While some devices choose to ignore DHCP provided DNS (and NTP), I can still reroute those requests at the edge router. Is that also possible with NTS? Even if it gets rerouted to a plain NTP server? Additionally, it's not clear to me from the proposal what it would take for an NTP server provided over DHCP to be "trusted", or what a "trusted network" is. Are only NTS-enabled sources to be trusted? Generally, yes. What I meant, if someone for example had at home a stratum 1 server (e.g. synchronized to GPS) and they trusted everything and everyone in their local network, it would make sense to still use the server (without NTS) in addition to any external time servers authenticated by NTS. The question is if we need to change the default value of the PEERNTP option. There could be a new default which adds the servers provided by DHCP only if chronyd is not using any servers with enabled authentication. That makes sense. But again, if I don't trust everything and everyone in my network, why do I trust the provided DNS servers? I feel like if this is on by default we're basically saying nobody trusts any provided NTP server unless it supports NTS. If that's the case, do away with the 'trusted network' verbiage and just say that only NTS servers provided over DHCP will be used. Additionally, what about the no-internet case? Will a local, non-NTS NTP server be acceptable in that case? I feel like that would be handled by the change to PEERNTP you mention above. But then can't attackers "disable the synchronization" as you mention above, essentially forcing us back to no additional security? Maybe what we should really have is a REQUIRENTS option for chronyd? What becomes of the old default fedora.pool.ntp.org? It would still work, even if we didn't use it by default. The name is just an alias for pool.ntp.org. The servers used in the current default configuration are not run by Fedora. Does the alias provide no additional functionality? Does it help with an estimate of running Fedora machines in the wild? Finally, from a purely personal standpoint, I don't like seeing yet more infrastructure being handed over to a hyperscaler like Cloudflare (see also DoH in Firefox). I would be less opposed to this being default if pool.ntp.org found a way to support it. Yes, that's a valid point, which we need to consider. I don't have a strong opinion either way. I'd like to see pool.ntp.org to support NTS. But I'm not sure if the trust of not being attacked will be comparable to a single entity running the servers, even if the pool has a sufficient number of NTS-enabled servers and implements some mitigations like mixing servers from different countries. Will there be some kind of 'canary domain' like there is for DoH (use-application-dns.net)? Again from a network admin standpoint, if I provide a local NTP server without NTS, I want an easy way to tell the devices I manage to use it. From a user standpoint, I like this change and the security it offers. But with a network admin hat on, it feels like yet more local infrastructure being pushed outside of my control. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: > It doesn't make much sense to me for this to default to on if we still > "trust" the DNS servers provided over DHCP. What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) > Additionally, it's not clear to > me from the proposal what it would take for an NTP server provided over DHCP > to be "trusted", or what a "trusted network" is. Are only NTS-enabled > sources to be trusted? Generally, yes. What I meant, if someone for example had at home a stratum 1 server (e.g. synchronized to GPS) and they trusted everything and everyone in their local network, it would make sense to still use the server (without NTS) in addition to any external time servers authenticated by NTS. The question is if we need to change the default value of the PEERNTP option. There could be a new default which adds the servers provided by DHCP only if chronyd is not using any servers with enabled authentication. > What becomes of the old default fedora.pool.ntp.org? It would still work, even if we didn't use it by default. The name is just an alias for pool.ntp.org. The servers used in the current default configuration are not run by Fedora. > Finally, from a purely personal standpoint, I don't like seeing yet more > infrastructure being handed over to a hyperscaler like Cloudflare (see also > DoH in Firefox). I would be less opposed to this being default if > pool.ntp.org found a way to support it. Yes, that's a valid point, which we need to consider. I don't have a strong opinion either way. I'd like to see pool.ntp.org to support NTS. But I'm not sure if the trust of not being attacked will be comparable to a single entity running the servers, even if the pool has a sufficient number of NTS-enabled servers and implements some mitigations like mixing servers from different countries. -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: > On 4/6/20 4:08 PM, Ben Cotton wrote: > > [snip] > > > > > > It doesn't make much sense to me for this to default to on if we still > "trust" the DNS servers provided over DHCP. Additionally, it's not clear to > me from the proposal what it would take for an NTP server provided over DHCP > to be "trusted", or what a "trusted network" is. Are only NTS-enabled > sources to be trusted? > > What becomes of the old default fedora.pool.ntp.org? > > Finally, from a purely personal standpoint, I don't like seeing yet more > infrastructure being handed over to a hyperscaler like Cloudflare (see also > DoH in Firefox). I would be less opposed to this being default if > pool.ntp.org found a way to support it. I don't know the answers to your questions on the change, but just FYI, firefox in Fedora is not using DoH. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Network Time Security
On 4/6/20 4:08 PM, Ben Cotton wrote: [snip] It doesn't make much sense to me for this to default to on if we still "trust" the DNS servers provided over DHCP. Additionally, it's not clear to me from the proposal what it would take for an NTP server provided over DHCP to be "trusted", or what a "trusted network" is. Are only NTS-enabled sources to be trusted? What becomes of the old default fedora.pool.ntp.org? Finally, from a purely personal standpoint, I don't like seeing yet more infrastructure being handed over to a hyperscaler like Cloudflare (see also DoH in Firefox). I would be less opposed to this being default if pool.ntp.org found a way to support it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 Self-Contained Change proposal: Network Time Security
https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity == Summary == Support for the Network Time Security (NTS) authentication mechanism in the NTP client/server (chrony) and installer (anaconda). == Owner == * Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]] * Email: mlich...@redhat.com, mkol...@redhat.com == Detailed Description == NTP is a widely used protocol for synchronization of clocks over network. Authentication of NTP packets is important to prevent a Man-in-the-middle (MITM) attacker from taking full control over the client's clock (e.g. force it to jump to a distant future or past). Several different authentication mechanisms have been specified for NTP. The oldest and simplest one uses secret keys, where each client has its own key which needs to be securely distributed to the server and client. This means it is mostly limited to local networks. Autokey is a newer mechanism based on public-key cryptography, but it was shown to be insecure and it is rarely supported on public servers. NTS is a new authentication mechanism [https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp specified by the IETF] for NTP. NTS has an NTS-KE protocol using Transport Layer Security (TLS) to establish the keys and provide the client with cookies which allow the NTP server to not keep any client-specific state. NTP packets are authenticated using Authenticated Encryption with Associated Data (AEAD). NTS is expected to scale well to a large numbers of clients. There are already some public NTP servers with NTS support. The default NTP client and server on Fedora is `chrony`. Support for NTS is added in version 4.0. It uses the GnuTLS library for TLS and the Nettle library for AEAD. NTS authentication can be enabled on the client by adding the `nts` option to the `server` or `pool` directive in ''/etc/chrony.conf''. Until a standard port is assigned for NTS by IANA, the port may need to be specified with the `ntsport` option. For example ` server time.example.com iburst nts ntsport 12123 ` When using NTS-enabled NTP sources, any NTP source that is not trusted and reachable over a trusted network should be disabled. This includes servers provided by DHCP. They should be disabled by adding `PEERNTP=no` to ''/etc/sysconfig/network''. We can consider changing the default ''/etc/chrony.conf'' to use some trusted public NTP servers with NTS support. There are public servers provided by [https://www.cloudflare.com/time/ Cloudflare] and [https://www.netnod.se/time-and-frequency/how-to-use-nts Netnod]. Both would be ok with Fedora using their servers by default (after some testing and coordination). There is also a possibility that pool.ntp.org will support NTS, although it is not very clear how useful would NTS be in this case as the servers are owned by individual contributors instead of a single trusted entity and attackers can easily join the pool (some mitigations have been proposed on the pool mailing list). Potential issues with enabling NTS by default: * Firewalls may block the NTS-KE port. * ISPs may block or rate limit longer NTP packets as a mitigation for amplification attacks using NTP mode 6 and 7. NTS-KE supports port negotiation and an alternative port could be used to avoid this issue. * Computers with no RTC (e.g. some ARM boards), or RTC that is too far from the real time, will fail to verify TLS certificates. An option could be added to disable the time checks before the first update of the clock. This would have an impact on security. == Benefit to Fedora == This change enables Fedora users to securely synchronize the system clock to local or public NTP servers. TBD: This change also makes the default configuration of the NTP client secure. == Scope == * Proposal owners: # Update `chrony` to 4.0 and enable the NTS support (adding dependency on GnuTLS) # TBD: Modify the default ''/etc/chrony.conf'' to use public servers with NTS support # Add an NTS option to the NTP settings in anaconda * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Fedora systems updated from a previous version will use the new ''/etc/chrony.conf'' automatically if the installed file was not modified. If it was modified, the users will need to update the file manually or rename ''/etc/chrony.conf.rpmnew'' to ''/etc/chrony.conf'' in order to enable NTS. == How To Test == If the default configuration is modified for this Change, it needs to be tested that it works correctly on most systems where the previous default configuration using pool.ntp.org servers worked. The installer needs to be tested that it enables NTS in ''/etc/chrony.conf'' as expected and that it adds `PEERNTP=no` to ''/etc/sysconfig/network''. The `chronyc -N sources` command can be used to
Fedora 33 Self-Contained Change proposal: Network Time Security
https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity == Summary == Support for the Network Time Security (NTS) authentication mechanism in the NTP client/server (chrony) and installer (anaconda). == Owner == * Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]] * Email: mlich...@redhat.com, mkol...@redhat.com == Detailed Description == NTP is a widely used protocol for synchronization of clocks over network. Authentication of NTP packets is important to prevent a Man-in-the-middle (MITM) attacker from taking full control over the client's clock (e.g. force it to jump to a distant future or past). Several different authentication mechanisms have been specified for NTP. The oldest and simplest one uses secret keys, where each client has its own key which needs to be securely distributed to the server and client. This means it is mostly limited to local networks. Autokey is a newer mechanism based on public-key cryptography, but it was shown to be insecure and it is rarely supported on public servers. NTS is a new authentication mechanism [https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp specified by the IETF] for NTP. NTS has an NTS-KE protocol using Transport Layer Security (TLS) to establish the keys and provide the client with cookies which allow the NTP server to not keep any client-specific state. NTP packets are authenticated using Authenticated Encryption with Associated Data (AEAD). NTS is expected to scale well to a large numbers of clients. There are already some public NTP servers with NTS support. The default NTP client and server on Fedora is `chrony`. Support for NTS is added in version 4.0. It uses the GnuTLS library for TLS and the Nettle library for AEAD. NTS authentication can be enabled on the client by adding the `nts` option to the `server` or `pool` directive in ''/etc/chrony.conf''. Until a standard port is assigned for NTS by IANA, the port may need to be specified with the `ntsport` option. For example ` server time.example.com iburst nts ntsport 12123 ` When using NTS-enabled NTP sources, any NTP source that is not trusted and reachable over a trusted network should be disabled. This includes servers provided by DHCP. They should be disabled by adding `PEERNTP=no` to ''/etc/sysconfig/network''. We can consider changing the default ''/etc/chrony.conf'' to use some trusted public NTP servers with NTS support. There are public servers provided by [https://www.cloudflare.com/time/ Cloudflare] and [https://www.netnod.se/time-and-frequency/how-to-use-nts Netnod]. Both would be ok with Fedora using their servers by default (after some testing and coordination). There is also a possibility that pool.ntp.org will support NTS, although it is not very clear how useful would NTS be in this case as the servers are owned by individual contributors instead of a single trusted entity and attackers can easily join the pool (some mitigations have been proposed on the pool mailing list). Potential issues with enabling NTS by default: * Firewalls may block the NTS-KE port. * ISPs may block or rate limit longer NTP packets as a mitigation for amplification attacks using NTP mode 6 and 7. NTS-KE supports port negotiation and an alternative port could be used to avoid this issue. * Computers with no RTC (e.g. some ARM boards), or RTC that is too far from the real time, will fail to verify TLS certificates. An option could be added to disable the time checks before the first update of the clock. This would have an impact on security. == Benefit to Fedora == This change enables Fedora users to securely synchronize the system clock to local or public NTP servers. TBD: This change also makes the default configuration of the NTP client secure. == Scope == * Proposal owners: # Update `chrony` to 4.0 and enable the NTS support (adding dependency on GnuTLS) # TBD: Modify the default ''/etc/chrony.conf'' to use public servers with NTS support # Add an NTS option to the NTP settings in anaconda * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Fedora systems updated from a previous version will use the new ''/etc/chrony.conf'' automatically if the installed file was not modified. If it was modified, the users will need to update the file manually or rename ''/etc/chrony.conf.rpmnew'' to ''/etc/chrony.conf'' in order to enable NTS. == How To Test == If the default configuration is modified for this Change, it needs to be tested that it works correctly on most systems where the previous default configuration using pool.ntp.org servers worked. The installer needs to be tested that it enables NTS in ''/etc/chrony.conf'' as expected and that it adds `PEERNTP=no` to ''/etc/sysconfig/network''. The `chronyc -N sources` command can be used to
