Network Time Security (NTS) RFC 8915

Das Network Time Protocol Version 4 (RFC 5905) ist das am meisten verwendete Netzwerk-Zeitübertragungsprotokoll. Es ist in fast jedem IP-Netz zu finden. Häufig werden NTP-Nachrichten über Standleitungen oder das "öffentliche Internet" übertragen. Daher ist es besonders wichtig, dass ein NTP-Client feststellen kann, dass der NTP-Server derjenige ist, für den er sich ausgibt, und dass niemand die Nachrichten auf ihrem Weg verändert hat. Glücklicherweise verfügt NTPv4 über eingebaute Sicherheitsmechanismen: Das Symmetric-Key-Verfahren und Autokey. Leider skaliert das Symmetric-Key-Verfahren aufgrund der manuellen Schlüsselverteilung schlecht. Autokey hat hingegen bekannte Schwachstellen und kann durch einen Brute-Force-Angriff geknackt werden.

Die Internet Engineering Task Force (IETF) hat einen aktualisierten Sicherheitsmechanismus namens NTS - Network Time Security (RFC 8915) veröffentlicht, der diese Schwachstellen nicht aufweist.

Seit der Firmware Version 7.08 unterstützen alle Meinberg LANTIME NTP-Zeitserver vollumfänglich NTS (Network Time Security) im Unicast-Client-Server-Modus.

Abbildung 1. Die drei Einheiten von Network Time Security (NTS)

Wie funktioniert NTS?

NTS funktioniert ausschließlich im "Unicast-Client-Server-Modus" von NTP. Bei den weniger verbreiteten NTP-Kommunikationsmodi muss (noch) mit dem Symmetric-Key-Verfahren, Autokey oder ohne zusätzliche Sicherheit gearbeitet werden.

Beteiligte Akteure im Netzwerk

Neben dem NTP-Server und dem Client gibt es den NTS-KE-Server. KE steht für Key Establishment. In der Praxis kann es sich bei dem NTS-KE-Server und dem NTP-Server um zwei Programme handeln, die auf demselben Server laufen, oder sie können sich auf separater Hardware befinden. Der Zweck des NTS-KE-Servers besteht darin, kryptografische Algorithmen zwischen NTP-Client und -Server auszuhandeln und Schlüsselmaterial zu verteilen.

Bevor ein Client mit dem KE-Server über NTS "sprechen" kann, eröffnet er eine sichere Sitzung mit Transport Layer Security (TLS). Dabei authentifiziert der Client den NTS-KE-Server anhand dessen Public-Key-Zertifikat. Sobald die TLS-Sitzung aufgebaut ist, sendet der Client eine Liste der von ihm unterstützten AEAD-Sicherheitsalgorithmen (Authenticated Encryption with Associated Data) sowie (optional) einen bevorzugten NTP-Server und eine Portnummer im Netzwerk-Stack. Der KE-Server antwortet mit einem ausgewählten Algorithmus, der IP-Adresse des NTP-Servers, der Portnummer und einem oder mehreren initialen Cookies. Da der NTP- und der NTS-KE-Server oft vom gleichen Zeitserverhersteller implementiert und zusammen gebündelt werden, ist die Interaktion zwischen ihnen im NTS-Standard nicht spezifiziert. Auf eine implementierungsspezifische Art und Weise teilt der NTS-Server dem KE-Server mit, welche Sicherheitsalgorithmen er verwenden will und mit welchem Schlüssel die Cookies verschlüsselt werden sollen.

Abbildung 2. NTP-Client meldet sich beim NTS-Key Establishment Server an

Sobald der NTP-Client initiale Cookies vom KE-Server erhalten hat, kann er eine sichere NTP-Anfrage an den NTP-Server senden. Der NTP-Server verwendet die Informationen in den NTP-Erweiterungsfeldern, um das Cookie zu sammeln und die NTP-Anfrage zu authentifizieren. Der NTP-Server erzeugt dann das nächste Cookie und sendet es zusammen mit der NTP-Antwort. Dies ist in Abbildung 3 dargestellt. Was hat es nun mit den ganzen Cookies auf sich, die hin und her geschickt werden? Der Grund dafür ist, dass NTP-Server "zustandslos" sind. Sie wollen sich nicht an einzelne Clients erinnern, da es eine sehr große Anzahl von ihnen geben könnte. Dabei ist zu beachten, dass der Client möglicherweise mehrere Cookies vom KE-Server erhält, damit er sich nicht jedes Mal erneut beim KE-Server anmelden muss, wenn er NTP neu startet.

NTS verwendet NTP-Erweiterungsfelder. Der "Unique Identifier" ist wie eine Sequenznummer, wird jedoch von einem kryptografisch sicheren Zufallszahlengenerator erzeugt ( CSPRNG - Cryptographically Secure Pseudorandom Number Generator). Dadurch erhalten die NTP-Nachrichten mehr Entropie als bei gewöhnlichen Sequenznummern, was es schwieriger macht, die Sicherheit mit Brute-Force-Hackalgorithmen zu knacken. In einem NTP-Anfrage- und Antwortpaar wird derselbe "Unique Identifier" verwendet. Zusammen mit dem Cookie wird ein Zeiger auf den vom NTS-Server verwendeten Schlüssel verwendet, um das Cookie zu entschlüsseln. Das Erweiterungsfeld für die Authentifizierung enthält eine kryptografische Prüfsumme (Message Authentication Code), der mit dem Wert verglichen wird, den der Client und der Server beim Empfang der Nachricht erzeugen. Wenn sie übereinstimmen, wurde die Nachricht im Netz nicht verändert.

Abbildung 4. Struktur der NTP-Nachrichten mit NTS-Erweiterungsfeldern

Wie wird ein Cookie für NTS erzeugt?

Ein Cookie enhält die in Abbildung 5 dargestellten Komponenten und wird vom Server verschlüsselt, bevor er an den Client verteilt wird. Zu beachten ist, dass der Client verschlüsselte Cookies an den Server senden, diese aber nicht lesen kann. Der Client speichert lediglich Informationen für den Server, damit der Server zustandslos bleiben kann. Eine Nonce ist ein Feld aus Zufallsbits, das der Nachricht hinzugefügt wird, um die Entropie des verschlüsselten Cookies zu erhöhen. NTS verwendet unterschiedliche Schlüssel für die NTP-Anfrage vom Client an den Server (C2S) und für die Antwort vom Server an den Client (S2C).