A) TARGET ARCHITECTURE
We have a project where the target NTP time synchronisation architecture is the following:
- Stratum 1 servers provided by the customer.
- Stratum 2 servers: Spectracom SecureSync appliances provided by us.
- Stratum 3: end-user machines.
All NTP synchronization must be authenticated using Autokey IFF.
B) TEST LAB CONFIGURATION
In our lab, we simulate the target architecture with the following 3 machines:
- Stratum 1 server "vm-centos7-srv": CentOS 7 VM with ntpd 2.4.6, using local clock as reference.
- Stratum 2 server "ntpsrv": Spectracom SecureSync 1200 appliance.
- Stratum 3 client "vm-centos7-cli": CentOS 7 VM with ntpd 2.4.6.
In Autokey terminology, the machines have the following roles:
- vm-centos7-srv: server and Trusted Host (TH) -> generates the IFF group key.
- ntpsrv: server (not TH) -> has a copy of the "vm-centos7-srv" IFF group key.
- vm-centos7-cli: client -> has a copy of the "vm-centos7-srv" IFF public parameters.
The machines synchronize properly and report no error. However, "vm-centos7-cli" does not have the IFF flag set, i.e. it has "flags=0x87f03" instead of the expected "flags=0x87f23".
Also, if we delete all the keys (host and group) on "vm-centos7-srv", generate everything anew and restart ntpd, the other machines continue to synchronize, authenticate and trust this host. This means that Autokey authentication is useless, as any rogue server could impersonate a stratum 1 machine.
C) SIMPLIFIED ARCHITECTURE
When simplifying the configuration by synchronizing "vm-centos7-cli" directly with "vm-centos7-srv", the IFF flag is set on "vm-centos7-cli". The flags become 0x417f21 (dunno why the prefix is different, 41 instead of 8). However, in this case, even when the group parameters file is deleted from the client and ntpd restarted, the flags remain the same although IFF should not work.
Configuration of both CentOS 7 VMs was done as per the official ntpd page: http://support.ntp.org/bin/view/Support/ConfiguringAutokey
The "-c RSA-SHA1" option was added to the ntp-keygen commands.
D) QUESTIONS
- Is the target architecture (i.e. 1 IFF group with TH/server/client) viable ?
- In the complete architecture, why does the client fail to complete IFF authentication ?
- Why does the non-TH server still authenticate and synchronize when the keys have changed on the TH ?
- In the simplified architecture, why does the client have the IFF bit enabled even when it does not have the IFF group parameters configured ?
- What is the meaning of the first digits in the flags ? Only the 4 last digits are documented, not the first 1 or 2.
Sorry for this wall of text and thanks in advance for any information and help.
