From Fedora Project Wiki
(Created page with "= Network Time Security = == Summary == Support the Network Time Security (NTS) authentication mechanism for the Network Time Protocol (NTP). == Owner == <!-- For change p...")
 
mNo edit summary
 
(10 intermediate revisions by 2 users not shown)
Line 3: Line 3:
== Summary ==
== Summary ==


Support the Network Time Security (NTS) authentication mechanism for the Network Time Protocol (NTP).
Support for the Network Time Security (NTS) authentication mechanism in the NTP client/server (chrony) and installer (anaconda).


== Owner ==
== Owner ==
<!--
* Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]]
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
* Email: mlichvar@redhat.com, mkolman@redhat.com
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:mlichvar| Miroslav Lichvar]]
* Email: mlichvar@redhat.com


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF33]]


[[Category:SelfContainedChange]]
[[Category:SelfContainedChange]]
Line 20: Line 16:
* Targeted release: [[Releases/33 | Fedora 33 ]]  
* Targeted release: [[Releases/33 | Fedora 33 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2372 #2372]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1834855 #1834855]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/508 #508]


== Detailed Description ==
== 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 control over an NTP client (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.
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 allows 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.
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.
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
NTS is not enabled by default. It can be enabled on clients by adding the `nts` option to the `server` or `pool` directive in ''/etc/chrony.conf''. For example


`
`
server foo.example.com iburst nts ntsport 12123
server time.example.com iburst nts
`
`


A special care must be taken when mixing authenticated and non-authenticated NTP sources, e.g. servers from the pool.ntp.org project, or local NTP servers provided by DHCP if they are not disabled by adding `PEERNTP=no` to ''/etc/sysconfig/network''. To prevent the attacker from making a large adjustment of the clock by modifying responses from (a majority of) the non-authenticated sources, the `require` and `trust` options must be specified for the authenticated sources. This way, the non-authenticated sources will be used only when they agree with authenticated sources and can contribute to the stability and accuracy of the synchronization.
There are several issues that may prevent NTS from working correctly:
 
* Firewalls may block the NTS-KE port.
The default ''/etc/chrony.conf'' can be modified to use 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 (with some testing and coordination). Another possibility for Fedora is to consider running its own NTP servers.  
* 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 servers can provide an alternative port 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. It is possible to disable the time checks before the first update of the clock by adding `nocerttimecheck 1` to ''/etc/chrony.conf'', but it has an impact on security.


== Benefit to Fedora ==
== Benefit to Fedora ==


This change enables Fedora users to securely synchronize the system clock to local or public NTP servers.
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 ==
== Scope ==
Line 52: Line 47:


# Update `chrony` to 4.0 and enable the NTS support (adding dependency on GnuTLS)
# Update `chrony` to 4.0 and enable the NTS support (adding dependency on GnuTLS)
# TBD: Modify the ''/etc/chrony.conf'' to use a public server with NTS support
# Add NTS support to the NTP settings in anaconda
# TBD: Add support for configuring NTS to the installer


* Other developers: N/A (not a System Wide Change)
* Other developers: N/A (not a System Wide Change)
Line 65: Line 59:
== Upgrade/compatibility impact ==
== 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.
There is no impact as NTS is not enabled by default.


== How To Test ==
== 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 configuration worked. The NTS-KE port may be blocked in firewalls. Large NTP packets on the port 123 may be blocked or rate-limited by ISPs. (NTS-KE supports port negotiation and an alternative port could be used to avoid this issue.)
Client NTS is enabled in ''/etc/chrony.conf'' by adding the `nts` option to the `server` or `pool` directive. For example:


If the installer was modified to support NTS, it needs to be tested that the generated configuration file is correct.
    server nts.sth1.ntp.se iburst nts
    server time.cloudflare.com iburst nts


The `chronyc -N sources` command can be used to verify that NTP sources are responding and the `chronyc ntpdata` command shows which sources are authenticated. For example
The installer needs to be tested that it enables NTS in ''/etc/chrony.conf'' as expected.
 
The `chronyc -N sources` command can be used to verify that the NTP servers are responding. The `chronyc -N authdata` command can be used to verify that the servers are authenticated with NTS. For example:


     # chronyc -N sources
     # chronyc -N sources
     MS Name/IP address        Stratum Poll Reach LastRx Last sample               
     MS Name/IP address        Stratum Poll Reach LastRx Last sample               
     ===============================================================================
     ===============================================================================
     ^* time.cloudflare.com          3   6   377   28  -115us[ -111us] +/-   13ms
     ^- nts.sth1.ntp.se              1   2   377     4  +1241us[+1241us] +/- 1500ms
     ^+ nts.ntp.se                    2   6  377    27  +212us[ +212us] +/-  22ms
     ^* time.cloudflare.com          3   6  377    47    -28us[ -44us] +/-  11ms
     # chronyc ntpdata | grep Auth
 
     Authenticated   : Yes
     # chronyc -N authdata
     Authenticated   : Yes
    Name/IP address            Mode KeyID Type KLen Last Atmp  NAK Cook CLen
   
    =========================================================================
     nts.sth1.ntp.se              NTS    1   15  256  139    0    0    8  100
     time.cloudflare.com          NTS    1   15  256  141    0    0    8  100
 
== User Experience ==
== User Experience ==


NTS can be enabled on NTP clients and servers. The directives and options are documented in the `chrony.conf` man page.
Client NTS can be enabled in the NTP settings in the installer.


If the installer was modified to support NTS, a new checkbox or dialog will be visible to the user during installation.
Client and server NTS can be enabled by editing ''/etc/chrony.conf'' as documented in the  `chrony.conf` man page.


== Dependencies ==
== Dependencies ==

Latest revision as of 12:31, 8 September 2020

Network Time Security

Summary

Support for the Network Time Security (NTS) authentication mechanism in the NTP client/server (chrony) and installer (anaconda).

Owner

Current status

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 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 is not enabled by default. It can be enabled on clients by adding the nts option to the server or pool directive in /etc/chrony.conf. For example

server time.example.com iburst nts

There are several issues that may prevent NTS from working correctly:

  • 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 servers can provide an alternative port 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. It is possible to disable the time checks before the first update of the clock by adding nocerttimecheck 1 to /etc/chrony.conf, but it has an impact on security.

Benefit to Fedora

This change enables Fedora users to securely synchronize the system clock to local or public NTP servers.

Scope

  • Proposal owners:
  1. Update chrony to 4.0 and enable the NTS support (adding dependency on GnuTLS)
  2. Add NTS support 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

There is no impact as NTS is not enabled by default.

How To Test

Client NTS is enabled in /etc/chrony.conf by adding the nts option to the server or pool directive. For example:

   server nts.sth1.ntp.se iburst nts
   server time.cloudflare.com iburst nts

The installer needs to be tested that it enables NTS in /etc/chrony.conf as expected.

The chronyc -N sources command can be used to verify that the NTP servers are responding. The chronyc -N authdata command can be used to verify that the servers are authenticated with NTS. For example:

   # chronyc -N sources
   MS Name/IP address         Stratum Poll Reach LastRx Last sample               
   ===============================================================================
   ^- nts.sth1.ntp.se               1   2   377     4  +1241us[+1241us] +/- 1500ms
   ^* time.cloudflare.com           3   6   377    47    -28us[  -44us] +/-   11ms
   # chronyc -N authdata
   Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
   =========================================================================
   nts.sth1.ntp.se              NTS     1   15  256  139    0    0    8  100
   time.cloudflare.com          NTS     1   15  256  141    0    0    8  100

User Experience

Client NTS can be enabled in the NTP settings in the installer.

Client and server NTS can be enabled by editing /etc/chrony.conf as documented in the chrony.conf man page.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)
  • Blocks product?

Documentation

N/A (not a System Wide Change)

Release Notes

TBD