Zusammenfassung

  • NTS besteht aus einer TLS-gestützten Schlüsseleinrichtung und späteren NTP-Paketen. Das vom Client zurückgebrachte Cookie rekonstruiert den Zustand, ohne dass der Server eine Client-Akte behält.
  • Cookie-Schlüssel, C2S- und S2C-Schlüssel, zufällige Anforderungskennung, Cookie-Nachschub und lokale Uhrendisziplin sind getrennte Kontrollen.
  • Dieter Sibold ist einer von fünf Autoren von RFC 8915 und wird aktuell als Vorsitzender der IETF-NTP-Arbeitsgruppe geführt. Das dokumentiert Mitwirkung, nicht Alleinerfindung oder Kontrolle über Betriebsentscheidungen.

Ein Neustart trennt häufig Theorie von Betrieb. Die NTP-Prozesse laufen wieder, TLS antwortet, die Netzwege sind gesund. Trotzdem erhalten Clients NTS NAK, weil der Server die Schlüsselgeneration verloren hat, mit der ihre Cookies verschlüsselt wurden.

Dieses Szenario zeigt, was „zustandslos“ in Network Time Security wirklich bedeutet. Der Server muss keine Sitzung pro Client speichern. Er ist aber nicht frei von gemeinsamem Zustand. Er muss die Schlüssel kennen, mit denen er seine eigenen ausgelagerten Belege wieder lesen kann.

RFC 8915 löst damit ein Skalierungsproblem und schafft zugleich einen präzisen Kontinuitätsvertrag. Der Client trägt einen versiegelten Zustand. Der Server behält die Deutungshoheit. Die Zeitmessung selbst wird erst in einer weiteren, getrennten Entscheidung bewertet.

TLS richtet ein, NTP arbeitet weiter

Die NTS Key Establishment Protocol-Verbindung läuft über TCP-Port 4460. Im TLS-Handshake wird per ALPN ntske/1 ausgewählt. Client und Server handeln das Folgeprotokoll und einen AEAD-Algorithmus aus; der Server kann außerdem einen anderen NTP-Host und Port nennen.

Aus der TLS-Sitzung werden zwei richtungsgebundene Schlüssel exportiert: C2S für Client zu Server und S2C für Server zu Client. Danach erhält der Client erste Cookies. Anforderung und Antwort werden abgeschlossen, TLS wird geschlossen, und auf der Serverseite bleibt keine clientspezifische Sitzung zurück.

Die wiederkehrende Zeitübertragung nutzt NTP-Datagramme mit zusätzlichen NTS-Feldern. Der übliche 48-Oktett-Header wird authentifiziert, jedoch nicht verschlüsselt. Die teure asymmetrische Kryptografie bleibt in der selteneren Einrichtungsphase; die häufigen Zeitpakete nutzen symmetrische Verfahren.

Diese Trennung erlaubt unterschiedliche Komponenten für NTS-KE und NTP. Sie verlangt aber einen nachweisbaren Übergang. Ein Betriebsbeleg muss Zertifikatsprüfung, ALPN, Folgeprotokoll, AEAD, exportierte Generation, Zielserver, ausgegebene Cookies und das erste erfolgreiche geschützte NTP-Paket verbinden. Ein erfolgreicher Handshake allein ist kein vollständiger Dienst.

Der Client verwahrt eine Aussage des Servers

Das von RFC 8915 vorgeschlagene Cookie-Format enthält im verschlüsselten Inneren die AEAD-Kennung sowie S2C- und C2S-Schlüssel. Der Server versiegelt diese Werte mit einem gesonderten Cookie-Verschlüsselungsschlüssel. Das Ergebnis besteht aus Schlüsselkennung, Nonce und Geheimtext.

Der Client erfährt den Inhalt nicht. Er kann das Cookie speichern und zurückgeben, aber weder Algorithmus noch Schlüssel austauschen. Beim nächsten Paket wählt der Server anhand der Kennung eine Schlüsselgeneration, prüft den Geheimtext und stellt die Verbindungseigenschaften wieder her.

Stateless bezeichnet somit den Verzicht auf eine Client-Tabelle. Gemeinsam genutzte Cookie-Schlüssel, frühere Generationen, Konfiguration und Zeitquellen bleiben erhalten. Ein Cluster muss diese Generationen an alle antwortenden Knoten verteilen. Sonst wird ein gültiges Cookie je nach Lastverteilung angenommen oder abgelehnt.

Der ausgelagerte Beleg schafft Verwahrung ohne Vollmacht. Dass der Client die Bytes besitzt, macht ihn nicht zum Autor. Kontinuität wird tragbar, ohne die kryptografische Autorität zu verschieben.

Eine Zufallszahl bezeugt genau eine Anfrage

Eine geschützte Anfrage führt genau einen zufälligen Unique Identifier, ein Cookie und einen mit C2S erzeugten Authenticator. Der Server kopiert die Kennung in die Antwort und schützt sie mit S2C. So erkennt der Client, dass die Antwort zu seiner aktuellen Anfrage gehört.

Die Kennung ist kein dauerhaftes Geräteattribut und öffnet das Cookie nicht. Sie verhindert, dass eine alte gültige Antwort unbemerkt in einen neuen Austausch gelangt. C2S und S2C verhindern zusätzlich, dass ein Beweis für eine Richtung als Beweis für die andere verwendet wird.

Der zustandslose Server führt in diesem Profil keine vollständige Liste verarbeiteter Anforderungen. Eine wiederholte gültige Anfrage darf erneut Arbeit auslösen, sofern die Antwort keinen Verstärkungshebel bildet. RFC 8915 schützt deshalb in diesem Entwurf NTP-Modus 3 und 4; andere Betriebsarten haben andere Anforderungen an gegenseitige Authentisierung und Replay-Schutz.

Fehlerberichte müssen Cookie-Generation unbekannt, Entschlüsselung fehlgeschlagen, Paket-Tag ungültig, Antwortkennung falsch und authentisierte Zeitprobe verworfen auseinanderhalten. Diese Zustände haben verschiedene Ursachen.

Platzhalter begrenzen die Antwortgröße

Cookies sollen möglichst nicht wiederverwendet werden, weil ein stabiler undurchsichtiger Wert Verkehr über einen Netzwechsel hinweg verknüpfen kann. Der Server liefert daher Ersatz. Eine kleine UDP-Anfrage darf jedoch keine beliebig große Antwort an eine gefälschte Quelladresse auslösen.

NTS Cookie Placeholders reservieren den Raum bereits in der Anfrage. Der Server ersetzt ihn durch neue Cookies. Die Empfehlung zielt auf acht unbenutzte Cookies und höchstens sieben Platzhalter in einer Anfrage. Droht Fragmentierung, soll der Client weniger anfordern.

Der freie Raum ist eine Größenquittung. Der Client hat die Antwortkapazität mit seiner eigenen Paketlänge vorfinanziert. Monitoring sollte Bestand, Platzhalter, Nachschub, Cookie-Länge, Verluste und Datagrammgröße gemeinsam führen. Acht ist ein Betriebsrichtwert, kein universelles Gütesiegel.

Gelöschte Schlüssel machen alte Belege unlesbar

Das vorgeschlagene Cookie trägt keine allgemeine Ablaufzeit, die für alle Umsetzungen gilt. Entscheidend ist, ob der Server den referenzierten Entschlüsselungsschlüssel noch besitzt. RFC 8915 empfiehlt Rotation, Löschung alter Generationen für Vorwärtssicherheit und eine begrenzte Übergangsmenge.

Fehlt der Schlüssel, antwortet der Server mit NTS NAK. Der Client muss NTS-KE wiederholen. Ein Neustart ohne Persistenz, eine fehlerhafte Cluster-Verteilung, eine zu schnelle Rotation oder die bewusste Reaktion auf einen kompromittierten Schlüssel kann viele Clients gleichzeitig zur TLS-Einrichtung zwingen.

Die getrennten Dienste begrenzen zugleich Ausfälle. Ist nur NTS-KE unerreichbar, können Clients mit noch lesbaren Cookies den NTP-Dienst weiterverwenden. Neue Clients und solche mit unbrauchbaren Generationen können es nicht. Einrichtung und Zeitpaketdienst besitzen getrennte Verfügbarkeiten und eine gemeinsame Schlüsselbrücke.

Die aktuelle chrony-Dokumentation macht diese Zustände sichtbar. authdata trennt Einrichtungszähler, AEAD, Schlüssellänge, letztes erfolgreiches Establishment, Versuche, NAK, Cookie-Anzahl und Cookie-Länge. Die Serverkonfiguration beschreibt Persistenz und Rotation. Das sind versionsabhängige chrony-Entscheidungen, keine allgemeinen RFC-Standardwerte.

Datenschutz und Robustheit verlangen Gegensätzliches

Ein frisches Cookie pro Anfrage erschwert die passive Verknüpfung eines Geräts, wenn es das Netz wechselt. Daher wird fortlaufend Ersatz erzeugt. Fällt NTS-KE länger aus, kann dieser Vorrat jedoch enden.

RFC 8915 gestattet Wiederverwendung, wenn Robustheit wichtiger ist als Unverknüpfbarkeit. Der Dienst bleibt authentisiert, sendet dafür aber einen erkennbaren Wert erneut. Diese Ausnahme benötigt Schwelle, Dauer und Rückkehrbedingung.

NTS verspricht keine vollständige Anonymität. Der Zeitserver kann seine Clients beobachten, die TLS-Einrichtung gehört nicht zum gleichen Unverknüpfbarkeitsziel, und der NTP-Header bleibt sichtbar. Ein sauberer Beleg vermerkt Erstnutzung oder Wiederverwendung und deren Anlass.

Ein echtes Paket kann falsche Zeit tragen

Die Authentisierung belegt, dass der erwartete Schlüsselinhaber die geschützten Felder erzeugt hat und dass sie unverändert ankamen. Sie belegt nicht, dass die Serveruhr richtig geht oder dass ihre Referenzen unabhängig und ehrlich sind.

RFC 8633 empfiehlt mindestens vier unabhängige, vielfältige Quellen, wenn gute Genauigkeit benötigt wird. Filterung, Überschneidung, Clusterbildung und lokale Uhrendisziplin aus NTPv4 bleiben bestehen. NTS ersetzt sie nicht.

Bei einem Verzögerungsangriff verändert ein Angreifer keinen geschützten Inhalt. Er hält Pakete in einer Richtung länger zurück. Die ungefähre Symmetrieannahme der Offset-Berechnung wird verletzt; die Authentisierung ist erfolgreich, die Messung kann trotzdem verschoben sein.

Auch die Zertifikatsprüfung hat ein Startproblem. Gültigkeitszeiträume brauchen eine Uhr, während der Client gerade wegen einer unsicheren Uhr synchronisiert. RFC 8915 nennt eine persistierte letzte Zeit, batteriegestützte Uhren, strikte Regeln, mehrere Quellen und eine nachträgliche Plausibilitätsprüfung, aber keine perfekte Lösung.

Der Betriebsnachweis endet deshalb erst bei Offset, Laufzeit, Root Distance, akzeptierten und verworfenen Quellen, Systemzustand und angewandter Korrektur. Kryptografischer Ursprung ist nicht metrologische Richtigkeit.

Dieter Sibold steht für einen kollektiven Beitrag

RFC 8915 erschien im September 2020 mit Daniel Fox Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie und Ragnar Sundblad als Autoren. Das Standards-Track-Dokument wurde öffentlich geprüft und repräsentiert IETF-Konsens.

Der aktuelle IETF Datatracker nennt Sibold als Vorsitzenden der Arbeitsgruppe Network Time Protocols und als Gutachter im Internet Area Directorate. Unter seinem Profil stehen RFC 8633 und RFC 8915. Die Arbeitsgruppenseite führt ihn neben Karen O'Donoghue und beschreibt fortlaufende Arbeit an NTP, NTS, Verzögerungsresistenz und künftigen Spezifikationen.

Die PTB, Deutschlands nationales Metrologieinstitut, bezeichnet Dr. Dieter Sibold in ihrem aktuellen Impressum als Informationssicherheitsbeauftragten. Eine offizielle PTB-Mitteilung zur sicheren Computersynchronisation nennt ihn als Ansprechpartner für NTS.

Diese Unterlagen belegen Mitwirkung zwischen Metrologie, Betrieb und Standardisierung. Sie belegen keine Alleinerfindung, keine Kontrolle über den IETF-Konsens, chrony oder jeden PTB-Zeitdienst. Autorenschaft macht Beiträge zurechenbar, nicht exklusiv.

Vier Nachweise müssen zusammenfinden

Der erste betrifft NTS-KE: Gegenstelle, Zertifikatskette, Zeitprüfung, TLS, ALPN, Protokoll, AEAD, Generation und NTP-Ziel. Geheimnisse werden nicht protokolliert; sichere Generationsbezüge schon.

Der zweite betrifft Cookie-Kontinuität: Versiegelungsgeneration, Bestand, Erst- oder Wiederverwendung, Platzhalter, Nachschub, NAK, Rotation und Neueinrichtung. Im Cluster gehört der antwortende Knoten dazu.

Der dritte betrifft das NTP-Paket: sicherer Hash der Anforderungskennung, Richtung, Authentisierung, Antwortzuordnung, Offset, Laufzeit und Verwerfungsgrund. Der vierte betrifft die lokale Uhr: Kandidaten, Auswahl, Korrektur und Zustand danach.

Erst diese Kette verhindert, dass eine grüne Stufe für das Ganze spricht. TLS kann erfolgreich sein und NTP scheitern; ein Paket kann authentisch und seine Messung ungeeignet sein; die Uhr kann stimmen und die Cookie-Schlüssel beim nächsten Neustart verschwinden. Running-Code-Primat heißt, diese Übergänge zu beweisen.

Quellen