Zusammenfassung

  • RFC 1446 prüfte eine authentifizierte SNMPv2-Nachricht an zwei getrennten Grenzen: Der mit einem gemeinsamen Geheimnis berechnete MD5-Digest musste stimmen, und der Zeitstempel musste innerhalb der administrativ festgelegten Lebensdauer liegen.
  • partyAuthClock durfte unter demselben privaten Authentifizierungsschlüssel nicht sinken. Ein Rücksprung allein öffnete einen bereits verlassenen Zeitbereich erneut und konnte alten, aufgezeichneten Nachrichten wieder Gültigkeit verschaffen.
  • Aus Teilnehmeridentität, Schlüsselgeneration und monotonem Zeitstand entstand eine Sicherheitsepoche. RFC 3414 bildete sie später durch Engine-ID, nichtflüchtigen Boot-Zähler und Zeit innerhalb des aktuellen Starts ab, ohne kryptografische Gültigkeit mit Rechtzeitigkeit gleichzusetzen.

Der Neustart, der einer alten Nachricht die Tür öffnete

Nehmen wir an, ein Agent erreicht auf seiner Authentifizierungsuhr den Stand 91.000. Eine Nachricht mit dem Zeitstempel 90.500 wurde zuvor mitgeschnitten. Bei einer zugelassenen Lebensdauer von 300 Sekunden gilt sie als zu alt, sobald die lokale Vorstellung des Empfängers von der Quelluhr über 90.800 hinausgelaufen ist.

Nach einem Stromausfall lädt der Agent einen gespeicherten Stand von 90.400. Der private Authentifizierungsschlüssel ist dagegen unverändert erhalten. Nun liegt die alte Nachricht rechnerisch wieder im Fenster. Niemand hat sie neu ausgestellt. Ihr Inhalt und ihr Digest sind unverändert. Nicht die Nachricht ist jünger geworden, sondern das Gedächtnis des Empfängers kürzer.

Damit berührte RFC 1446 einen Punkt, der in einer bloßen Liste von Algorithmen kaum sichtbar wird: Replay-Schutz benötigt dauerhaften Zustand. Ein Digest bindet Bytes an ein Geheimnis und lässt Veränderungen erkennen. Er trägt aber kein selbstständiges Wissen darüber, ob dieselben Bytes bereits in einer früheren Phase zulässig waren. Dieses Wissen liegt beim Empfänger.

Die Vorschrift lautete deshalb nicht lediglich „halte die Uhren möglichst genau“. Solange ein bestimmter privater Authentifizierungsschlüssel verwendet wurde, musste die Uhr eines Teilnehmers nicht fallend verlaufen. Sollte ihr Wert sinken, musste sich gleichzeitig der Schlüssel ändern. Erst die Kombination aus Identität, Schlüsselgeneration und monotoner Zeit bestimmte, zu welcher Sicherheitsepoche eine Nachricht gehörte.

Ein richtiges Prüfergebnis konnte zeitlich falsch sein

RFC 1446 erschien im April 1993 als Standards-Track-Dokument und ist heute als Historic eingestuft. Es definierte für SNMPv2 je ein Authentifizierungs- und ein Datenschutzprotokoll. Im Profil v2md5AuthProtocol verwendete ein Teilnehmer 16 Oktette privates Authentifizierungsmaterial; MD5 lieferte einen 128-Bit-Digest.

Der Sender setzte sein Geheimnis vorübergehend in das Digest-Feld, kodierte die authentifizierte Nachrichtenform und berechnete darüber den Hash. Für die Übertragung ersetzte das Ergebnis das Geheimnis. Der Empfänger entnahm den gelieferten Digest, rekonstruierte dieselbe Form mit seiner lokalen Kopie des privaten Schlüssels, rechnete erneut und verglich. Bei einer Abweichung wurde snmpStatsWrongDigestValues erhöht und die Nachricht verworfen.

Zur vollständigen Entscheidung benötigte der Empfänger außerdem die lokal gespeicherte Authentifizierungsuhr der Quellpartei und deren Lebensdauer. Die zeitliche Ablehnung trat ein, wenn folgende Beziehung galt:

authSrcTimestamp + Lebensdauer < lokale Authentifizierungsuhr

Dann stieg snmpStatsNotInLifetimes, und die Nachricht galt für die weitere Verarbeitung als nicht authentisch. Diese Terminologie darf nicht verdecken, dass der Digest durchaus stimmen konnte. Die Nachricht scheiterte nicht an ihrer kryptografischen Bindung, sondern daran, dass sie einer vom Empfänger ausgeschlossenen Vergangenheit angehörte.

Die beiden Prüfungen erzeugten unterschiedliche Belege. Ein Digest-Vergleich kann zeigen, dass bestimmte empfangene Bytes unter einer bekannten Schlüsselkonfiguration den vorgesehenen Integritäts- und Herkunftstest bestanden. Der Zeitvergleich kann zeigen, ob sie im akzeptierten Fenster lagen. Keiner der beiden Belege beweist allein, dass Zugriff erlaubt war, eine Operation ausgeführt wurde, sich ein Gerät tatsächlich änderte oder eine Änderung einen weiteren Neustart überstand.

Eine belastbare Aufzeichnung muss deshalb Teilnehmer oder autoritative Engine, Schlüsselgeneration, Zeit- beziehungsweise Boot-Epoche, angewandtes Fenster, Nachrichtenbytes, Digest-Ergebnis und Zeitentscheidung miteinander verbinden. Zugriffskontrolle, Protokollantwort und unabhängige Beobachtung der Außenwirkung bleiben eigene Datensätze. Das Etikett „authentifiziert“ ist zu grob, um diese Kette zu ersetzen.

Lebensdauer war eine bewusste Risikogrenze

Authentifizierte Nachrichten trugen Zeitstempel für Quelle und Ziel mit einer Auflösung von einer Sekunde. Die Lebensdauer war keine vom Netz entdeckte Naturkonstante. Sie war eine administrative Obergrenze für noch akzeptable Verzögerung. RFC 1446 empfahl, sie so klein zu wählen, wie Uhrengenauigkeit, Umlaufzeit und Häufigkeit der Überprüfung zuließen.

Ein kurzes Fenster begrenzt die Nutzbarkeit einer Aufzeichnung, reagiert aber empfindlich auf Drift und Verzögerung. Ein großes Fenster erhöht die betriebliche Toleranz und verlängert zugleich die Phase, in der eine Kopie brauchbar bleibt. Wer die Lebensdauer vergrößert, um Fehlermeldungen verschwinden zu lassen, ändert daher eine Sicherheitsentscheidung und nicht nur einen Komfortwert.

„Innerhalb des Fensters“ bedeutete außerdem nicht „einmalig“. Zwei identische Kopien konnten beide rechtzeitig sein. Bei Nachrichten, die Zustand verändern sollten, riet der RFC, eine positive Bestätigung oder das Ende des betreffenden Zeitraums abzuwarten, bevor eine Folgemeldung versandt wurde. Digest und Zeitfenster machten aus dem Nachrichtenaustausch kein Transaktionsjournal mit strenger Reihenfolge.

Nach Zeit- und Digest-Prüfung folgte die Zugriffspolitik. Nur wenn irgendein Zugriff erlaubt war, konnten höhere authentifizierte Zeitstempel die lokalen Vorstellungen von Teilnehmeruhren gezielt vorwärts bewegen. Diese Reihenfolge begrenzte, wer dem Empfänger Zeit beibringen durfte. Sie machte den Zeitfortschritt jedoch weder zu einer Autorisierung noch zum Beweis einer ausgeführten Geräteänderung.

Der neue Schlüssel kappte die alte Verbindung

Eine aufgezeichnete Nachricht besaß zwei Merkmale, die beim ersten Durchlauf zusammenpassten: Ihr Digest gehörte zum damaligen Geheimnis, und ihr Zeitstempel lag im damaligen Fenster. Dreht der Betreiber nur die Uhr zurück, wird die zweite Bedingung wiederhergestellt. Bleibt der Schlüssel gleich, besteht auch die erste fort.

Ein gleichzeitiger Schlüsselwechsel zerstört die Verbindung. Der alte Zeitstempel mag numerisch wieder nahe an der Gegenwart liegen; der unter dem früheren Geheimnis erzeugte Digest passt nicht zum neuen. Der Schlüsselwechsel korrigiert die Uhr nicht. Er kennzeichnet, dass derselbe Zahlenbereich nun zu einer anderen kryptografischen Epoche gehört.

RFC 1447 schrieb die Regel in das Party-MIB. Die Definition von partyAuthClock untersagte eine Verringerung, sofern nicht gleichzeitig der private Authentifizierungsschlüssel des Teilnehmers geändert wurde. partyAuthLifetime gab das erlaubte Intervall in Sekunden an. Was wie zwei verwaltete Variablen aussah, bildete gemeinsam mit Identität und Schlüsselstand eine operative Sicherheitsgrenze.

Auch ein Schlüsselwechsel war kein einzelnes Ereignis. Eine verantwortliche Managementstation musste den neuen Wert bestimmen, den Änderungswunsch senden, die Zustellung klären, die Übernahme durch den Agenten bestätigen, weitere verantwortliche Stationen koordinieren und schließlich das alte Geheimnis ausmustern. Während dieser Übergangszeit konnte sie beide Werte benötigen, sogar nach einem eigenen Neustart.

Der protokollierte Versand einer Änderung beweist daher keine Übernahme. Eine lokale Annahme beweist nicht, dass ein zweiter Manager den neuen Wert kennt. Zu frühes Löschen des alten Schlüssels gefährdet Verfügbarkeit; unbegrenzte Aufbewahrung verlängert mehrere gleichzeitig gültige Vertrauensgeschichten.

Erst orientieren, dann authentifiziert bestätigen

Das Modell setzte lose synchronisierte Uhren und mindestens eine verantwortliche Managementstation voraus, die Zeitsynchronisation und Geheimnisverteilung koordinierte. Solange sich die Geheimnisse nicht änderten, sollte die langsamere Zeitvorstellung zur schnelleren vorgeschoben werden. Die schnellere unter demselben Schlüssel zurückzunehmen, wäre gerade die gefährliche Wiederöffnung gewesen.

Für den Anfang gab es ein aufschlussreiches Verfahren. Wenn der Manager noch nicht wusste, ob seine Uhren mit dem Agenten übereinstimmten, durfte er die Zeitwerte zunächst unauthentifiziert abrufen. Die Antwort diente als Kandidat für die Synchronisation. Nachdem der Wert übernommen war, musste ein authentifizierter Abruf ihn bestätigen.

Die erste Beobachtung war nützlich, ohne vertrauenswürdig zu sein. Sie sagte, welchen Wert der unerwiesene Gegenüber präsentierte. Die zweite Beobachtung brachte die Bindung an das gemeinsame Geheimnis hinzu. Wer beide Schritte getrennt dokumentiert, kann zeigen, an welcher Stelle Vertrauen entstand. Wer nur den Endwert speichert, verwandelt Entdeckung nachträglich in Beweis.

Mehrere verantwortliche Managementstationen verschärften die Koordinationsfrage. Sie konnten unterschiedliche Vorstellungen von Uhr und Schlüsselgeneration besitzen. Ein für eine Station vollständiger Übergang ließ eine andere womöglich in der alten Epoche zurück. Die technische Spezifikation verlangte lokale Abstimmung; die Organisation musste festlegen, wer den Wechsel auslösen durfte und welche Bestätigung ihn abschloss.

Ausfallsicherheit bedeutete monotones Gedächtnis

RFC 1446 verlangte für Teilnehmeridentität, Authentifizierungsuhr, privaten Authentifizierungsschlüssel und privaten Datenschutzschlüssel nichtflüchtige, unverfälschbare Darstellungen. Wenn möglich, sollte die Lebensdauer ähnlich geschützt werden. Ein vorhandenes Datenbankfeld genügte nicht; der jüngste gültige Zusammenhang musste den Ausfall überstehen.

Eine Implementierung konnte eine batteriegestützte Uhr verwenden. Alternativ konnte sie regelmäßig einen Stand nichtflüchtig sichern und beim Neustart konservativ nach vorn springen, sodass kein seit der letzten Sicherung plausibel erreichter Wert unterschritten wurde. Es ging weniger um exakte Wandzeit als darum, unter demselben Schlüssel keinen bereits verbrauchten Bereich erneut zu betreten.

Blieb ein Agent so lange abgeschaltet, bis eine Teilnehmeruhr ihren Höchstwert erreichte, blieb sie dort stehen. Die einzige authentifizierte Managementanforderung, die dann gesendet werden sollte, musste mindestens Uhr und privaten Authentifizierungsschlüssel ändern. Der Höchstwert war das Ende der Epoche, keine Einladung zum Zurücksetzen.

Waren geschützte Parameter verloren oder zerstört, verlangte der RFC zufällige Ersatzwerte. Kommunikation konnte erst nach manueller Neuverteilung wieder beginnen. Diese sichtbare Unterbrechung war sicherer als eine erfundene Kontinuität. Eine verantwortliche Station, die den Neustart eines Agenten feststellte, musste möglicherweise weitere Party-Attribute wiederherstellen, darunter eine nicht erhaltene Lebensdauer, und für die zulässige Wiederherstellungsnachricht einen Zeitstempel kontrolliert vorziehen.

Ein Boot-Zähler erlaubte der Sekundenanzeige den Neustart

Das User-based Security Model aus RFC 3414 ordnete die Zeitgültigkeit später einer autoritativen SNMP-Engine zu. snmpEngineID identifizierte diese Engine, snmpEngineBoots zählte Neustarts oder Neuinitialisierungen, und snmpEngineTime maß die Sekunden innerhalb des aktuellen Starts. Engine-ID und Boot-Zähler mussten nichtflüchtig erhalten bleiben.

Der Zeitmesser innerhalb eines Starts durfte auf null zurückkehren, weil vorher der Boot-Zähler stieg. Eine Nachricht aus dem vorigen Start gehörte damit zu einer anderen Epoche, selbst wenn ihre Sekundenangabe der aktuellen ähnelte. Der autoritative Empfänger wies einen abweichenden Boot-Zähler oder eine Zeit außerhalb des festen 150-Sekunden-Fensters zurück.

Die Darstellung änderte sich, die Trennung nicht. Ein korrekter Authentifizierungswert war weiterhin kein Beweis für Zeitgültigkeit. Konnte die Engine ihren letzten Boot-Zähler nicht zuverlässig bestimmen, setzte sie ihn auf den Höchstwert fest. Authentifizierte Nachrichten scheiterten dann an der Zeitprüfung, bis eine manuelle Intervention eine neue Engine-Identität oder neue Benutzergeheimnisse herstellte.

RFC 3414 ersetzte RFC 1446 nicht unmittelbar; zur Entwicklung gehören Zwischenschritte. Der architektonische Vergleich bleibt dennoch aufschlussreich. RFC 1446 schützte die rückwärts bewegte kontinuierliche Uhr durch einen Schlüsselwechsel. RFC 3414 machte den zurücksetzbaren Zeitzähler durch eine dauerhafte Boot-Epoche eindeutig. Beide verlangten neben dem passenden Geheimnis einen Nachweis, dass die Nachricht zur gegenwärtigen Geschichte des Empfängers gehörte.

Quellen