Zusammenfassung

  • NTS kann die Identität des NTS-KE-Endpunkts feststellen und eine NTP-Antwort einer offenen Anfrage zuordnen. Es beglaubigt weder die Genauigkeit der Serveruhr noch symmetrische Laufzeiten, wählt keine Zeitquelle aus und erteilt keine Erlaubnis für einen Sprung der Systemuhr.
  • Eine nachvollziehbare Zeitentscheidung bewahrt vier getrennte Belege: Identität und Schlüsselaushandlung, Paketannahme, Eignung und Auswahl der Quelle sowie Uhrendisziplin und Ausführung. Ein einziges grünes Sicherheitszeichen verschleiert die eigentliche Entscheidungskette.

Zwei gültige Antworten ergeben noch keine Zeit

Der Einstieg ist ein konstruiertes Gedankenexperiment, kein gemeldeter Vorfall. Quelle A und B besitzen gültige Zertifikate. Beide NTS-KE-Sitzungen gelingen. Jeder Server liefert Cookies und Schlüsselmaterial. Die späteren NTP-Antworten werden mit dem Schlüssel in Server-zu-Client-Richtung geprüft, spiegeln eine noch offene eindeutige Kennung und sind keine Wiederholungen. Trotzdem verlangt A fast keine Korrektur, B hingegen 800 Millisekunden.

Dafür muss die Kryptografie nicht versagt haben. Eine Quelle kann eine falsche vorgelagerte Referenz besitzen. Ein Pfad kann asymmetrisch verzögert sein. Die Synchronisationsdistanz kann die lokale Grenze überschreiten. Oder die Kandidaten bilden mit anderen Quellen keine mehrheitlich gestützte Schnittmenge.

Der Client muss weiterhin urteilen. Er kann A wählen, B mit unabhängiger Bestätigung verwenden, eine konsistente Gruppe kombinieren oder unsynchronisiert bleiben. Die Uhr bei widersprüchlichen Belegen nicht zu bewegen, ist eine gültige Sicherheitsentscheidung.

Die genaue Aussage von NTS

RFC 8915 teilt NTS in zwei Protokolle. NTS Key Establishment läuft über TLS. Die Zeitübertragung verwendet NTS-Erweiterungsfelder in NTP-Paketen des Client-Server-Modus. Identität und Schlüssel werden zuerst ausgehandelt; die häufigen Messungen bleiben leichtgewichtig.

NTS-KE nutzt TCP-Port 4460, TLS 1.3 oder neuer und die ALPN-Kennung ntske/1. Der Server kann den NTP-Endpunkt benennen, ein AEAD-Verfahren aushandeln und einen Anfangsvorrat undurchsichtiger Cookies ausgeben. Der TLS-Exporter leitet getrennte Schlüssel für Client-zu-Server und Server-zu-Client ab. Danach kann die Verbindung geschlossen und der clientbezogene Zustand auf dem Server verworfen werden.

Der Client bringt den Zustand in einem Cookie zurück. Seine Anfrage enthält außerdem eine eindeutige Kennung und einen Authentisierer. Eine zulässige Antwort muss mit dem Server-zu-Client-Schlüssel prüfbar sein und eine Kennung einer offenen Anfrage wiedergeben. Frische Cookies können geschützt zurückkehren und den Vorrat ohne dauerhaften Clientzustand auf dem Server auffüllen.

Damit belegt NTS einen präzisen, begrenzten Satz: Die angenommene Antwort stammt von der Partei hinter den NTS-Schlüsseln, wurde unterwegs nicht verändert und beantwortet eine wirkliche Anfrage. Die Richtigkeit des Oszillators, der vorgelagerten Referenzen oder des gelieferten UTC-Werts ist darin nicht enthalten.

IANA registriert die gemeinsamen Typwerte für Unique Identifier, NTS Cookie, Cookie Placeholder sowie Authenticator and Encrypted Extension Fields. Das schafft eine gemeinsame Sprache, aber keine Bewertung von Uhren.

Identität ist keine Genauigkeit

Das Zertifikat beantwortet die Identitätsfrage zum NTS-KE-Dienst, nicht die Genauigkeitsfrage zur Uhr. Das Cookie stellt Authentisierungsparameter wieder her, ist aber kein UTC-Nachweis. Die eindeutige Kennung verbindet Anfrage und Antwort, misst jedoch keine Pfadsymmetrie.

Der in RFC 8915 beschriebene Verzögerungsangriff zeigt die Grenze. Ein Akteur auf dem Pfad kann beide Richtungen unterschiedlich verzögern, ohne Inhalt oder Reihenfolge zu verändern. Sämtliche kryptografischen Prüfungen bleiben gültig, während der berechnete Offset falsch wird. Manipuliert wird die Laufzeit, nicht der geschützte Inhalt. Eine maximale Distanz begrenzt das Risiko; mehrere Quellen oder Pfade helfen, sofern sie nicht denselben Kontrollpunkt teilen.

Auch Vertraulichkeit ist begrenzt. Der grundlegende NTP-Header bleibt sichtbar, NTS kann Erweiterungsfelder verschlüsseln. Verfügbarkeit ist eine weitere Ebene: Pakete lassen sich verwerfen, und manche Kiss-o’-Death-Antworten sind nicht authentisiert.

Darum sollte ein fehlgeschlagenes NTS-KE nicht automatisch zu ungeschütztem NTP führen. Ein Angreifer könnte die Schlüsselaushandlung stören und so den Schutz entfernen. Eine Herabstufung erfordert eine ausdrückliche lokale Entscheidung.

Schon die Startzeit ist Vertrauenspolitik

X.509-Zertifikate besitzen Gültigkeitszeiträume. Ein Rechner, der wegen seiner unzuverlässigen Uhr Netzwerkzeit braucht, benötigt zugleich eine ungefähre Zeit, um das Zertifikat des Zeitdienstes zu prüfen. Eine vollkommene Lösung für jede Umgebung gibt es nicht.

RFC 8915 nennt eine batteriegestützte Uhr, eine manuelle Schätzung, den zuletzt persistent gespeicherten Wert und mehrere Zeitquellen. Eine Antwort unmittelbar nach NTS-KE sollte zudem mit der Zertifikatslaufzeit vereinbar sein. Das sind Plausibilitätsfenster, keine exakte UTC-Quelle.

Noch vor der ersten authentisierten Messung entscheidet der Betreiber: Welche Vertrauensanker gelten? Wie alt darf die gespeicherte Zeit sein? Wann darf die Zeitprüfung eines Zertifikats gelockert werden? Wie viele unabhängige Quellen müssen vor einer Korrektur übereinstimmen? Ohne dokumentierte Antwort entscheiden Produktvorgaben.

Nach der Paketprüfung beginnt die Quellwahl

RFC 5905 beschreibt eine lokale Kette. Paketverarbeitung erzeugt Messwerte. Ein Filter vermindert das Rauschen je Assoziation. Die Auswahl sucht eine mehrheitlich gestützte Schnittmenge. Clustering entfernt Ausreißer. Kombination liefert einen endgültigen Offset. Erst die Uhrendisziplin steuert Phase und Frequenz.

NTS stärkt den Eingang dieser Kette: Fälschung und Replay können verworfen werden, bevor sie Messwerte werden. Die späteren Schritte bleiben bestehen. Eine authentisierte Quelle kann ein falseticker sein. Ein kryptografisch gültiger Messwert kann wegen Laufzeit oder Root Distance ausscheiden. Fehlen genügend Überlebende, bleibt das System unsynchronisiert.

Die aktuelle chrony-Dokumentation trennt diese Sichtweisen. authdata zeigt Authentisierungsmodus, Schlüsselaushandlungen, Versuche, negative Bestätigungen und Cookies. Andere Berichte zeigen Erreichbarkeit, Übereinstimmung und Auswahl. maxdelay und verwandte Prüfungen verwerfen ungeeignete Laufzeiten. minsources kann Aktualisierungen blockieren, bis genügend Quellen auswählbar sind. Vertrauens- und Anforderungsoptionen steuern das Verhältnis authentisierter und offener Quellen.

NTPsec besitzt eigene Bedienelemente für Zertifikate, Client, Server und Cookie-Schlüssel. Die Unterschiede markieren die Stelle, an der gemeinsame Interoperabilität endet und Betreiberpolitik beginnt.

Vier Belege statt eines Abzeichens

Der Identitätsbeleg enthält den konfigurierten NTS-KE-Namen, Zertifikatskette, Dienstidentität, Vertrauenssatz und Zeitpunkt der Schlüsselaushandlung.

Der Paketbeleg enthält Schlüsselgeneration, Kennung, Cookiezustand, Authentisierer, zugehörige Anfrage und Zustandsänderungen durch Replay oder NTS-NAK.

Der Messbeleg enthält Offset, Laufzeit, Dispersion, Root Distance, Erreichbarkeit, Verlauf, Schnittmenge und Ausreißerstatus. Hier kann eine echte Antwort unbrauchbar werden.

Der Ausführungsbeleg enthält die gewählte Quelle oder Kombination, den Grenzwert für Slew oder Step, den ausführenden Prozess und den Zustand zuvor. Er dokumentiert die Autorität über den Rechner.

„NTS aktiv“ allein belegt die Nutzung des Mechanismus, nicht den Grund einer Uhränderung.

Minimale gemeinsame Regel, lokale Entscheidung

Heng Lus Minimum Initial Specification beschränkt die gemeinsame Ebene auf deterministische Regeln für Interoperabilität, Sicherheit und lokale Prüfung. Spätere Entscheidungen verbleiben bei den Teilnehmern, die Code ausführen. Veröffentlichung ist keine Übernahme, und gemeinsame Syntax schafft keine dauerhafte Befehlsgewalt.

So gelesen bleibt NTS eng. Die IETF definiert Verhandlung, Schlüssel, Cookies und Validierung. IANA registriert Nummern. Eine Zertifizierungsstelle wirkt an der Endpunktidentität mit. Keine dieser Stellen wählt die Quellen des Clients, setzt seine maximale Distanz, beurteilt die Startzeit oder genehmigt den Systemaufruf zur Uhränderung.

Running-Code Primacy ergänzt den Praxistest: Unabhängige Systeme können die Eigenschaften implementieren und lokal prüfen. Der Client darf das Paket annehmen und den Messwert ablehnen, die Identität vertrauen und den Step verbieten. Diese Trennung ist ein Sicherheitsmerkmal.

Quellen und Geltungsbereich

Die 800 Millisekunden sind illustrativ und benennen keinen Anbieter, Fehler, Vorfall oder Angriff. Eingefrorene Quellen: