Zusammenfassung

  • Nach RFC 1446 konnte eine SNMPv2-Party ihr eigenes Geheimnis ändern, bevor sie die Antwort erzeugte; die Antwort verwendete dann einen Schlüssel, den der Manager noch nicht übernommen hatte.
  • Fehlte die Antwort, waren eine verlorene Anfrage und eine vollzogene Änderung mit verlorener Rückantwort nicht unterscheidbar; der private Wert ließ sich nicht auslesen.
  • Ein erkennbarer öffentlicher Marker diente als unabhängiger Zeuge, während alter und neuer Schlüssel bis zur Klärung sogar über Neustarts hinweg erhalten bleiben mussten.

Der entfernte Commit kam zuerst

RFC 1446 zerlegte die Änderung eines vorhandenen Geheimnisses in eine feste Folge. Die verantwortliche Managementstation erzeugte einen neuen Wert und sandte einen geschützten setRequest. Der Empfänger verarbeitete ihn und erzeugte eine Antwort. Erst nach deren Empfang aktualisierte der Manager seine lokale Datenbank.

Beim Wechsel des eigenen Geheimnisses schrieb das Ziel den neuen Wert vor der Antwort. Diese Antwort wurde bereits nach dem neuen Geheimnis konstruiert. Die Managementstation prüfte noch mit dem alten. Ohne einen besonderen Übergangspfad konnte sie eine korrekte Antwort als unauthentisch verwerfen.

Ausgangsbefehl, Zustellung, entfernter Commit, Antwortbildung, Rückweg und Annahme waren getrennte Tatsachen. Kryptographische Integrität hob ihre Reihenfolge nicht auf.

Keine Antwort ließ zwei Zustände offen

Vielleicht erreichte die Anfrage das Ziel nie; dann galt beiderseits der alte Schlüssel. Vielleicht wurde sie verarbeitet und nur die Antwort ging verloren; dann hatte der Agent den neuen Wert, der Manager aber nicht.

Ein blindes Wiederholen mit dem alten Schlüssel konnte gerade wegen des ersten Erfolgs scheitern. Dieser Folgefehler bewies weder Angriff noch Netzausfall noch einen abgestürzten Agenten.

Der private Wert war nicht lesbar. Ein direktes Auslesen zur Abstimmung hätte den Schutz des Geheimnisses beseitigt. Die geschlossene Beobachtungsfläche verlangte einen separaten, ungefährlichen Nachweis.

Der RFC-Editor-Eintrag führt das Dokument als historisch. MD5 und DES sind Teil des Designs von 1993, keine aktuelle Einsatzempfehlung. Das Commit-Problem ergibt sich aus verteilter Reihenfolge, nicht aus der Wahl eines bestimmten Algorithmus.

Ein öffentlicher Marker bezeugte die geheime Änderung

RFC 1446 empfahl, gleichzeitig einen neuen, wiedererkennbaren öffentlichen Wert zu setzen. Beim Authentisierungsschlüssel wurde der öffentliche Authentisierungswert geändert, beim Privacy-Schlüssel der entsprechende andere. Blieb die Antwort aus, konnte der Manager diesen Marker lesen.

Die Party MIB aus RFC 1447 trennte private und öffentliche Felder sowie Party-Uhr und Lebensdauer. Der Marker war weder Schlüsselmaterial noch dessen Ableitung. Er band eine unsichtbare Zustandsänderung an einen lesbaren Transaktionszeugen.

Auch dieser Zeuge hatte eine scharfe Grenze. Ein passender Marker belegte die Anwendung der Änderung am Ziel. Er belegte nicht die lokale Umschaltung des Managers, Haltbarkeit nach einem Absturz, Berechtigung der nächsten Operation oder eine Wirkung im Netz.

Beide Kandidaten mussten dauerhaft werden

Zwischen Versand und Bestätigung musste die Station den alten und den neuen geheimen Wert halten. Eine Netzstörung konnte die Unsicherheit verlängern. RFC 1446 verlangte daher Bereitschaft, beide Werte über Neustarts hinweg aufzubewahren.

Der Controller durfte nicht nur den erhofften Endzustand speichern. Wurde der alte Schlüssel gelöscht, obwohl die Anfrage nie ankam, war der Zugang weg. Ging der neue verloren, obwohl nur die Antwort fehlte, entstand dieselbe Gefahr. Der ungeklärte Vorgang bestand aus zwei möglichen entfernten Realitäten.

Party-Identität, Authentisierungsuhr und private Schlüssel brauchten im Modell nichtflüchtige, unverfälschbare Darstellungen. Die Uhr musste auch nach Stromausfall monoton bleiben. Ein wieder gestarteter Prozess ohne diesen Kontext konnte gültige Nachrichten aus dem Zeitfenster werfen und administrative Synchronisierung erfordern.

Neustart war kein Wiederherstellungsbeweis. Erst die Übereinstimmung von Identität, Zeit, beiden Kandidaten, Lebensdauer und Marker stellte die Beziehung wieder her.

Authentisierung ordnete keine Zustandsfolge

Der gemeinsame Digest stützte Herkunft und Integrität. Uhr und Lebensdauer begrenzten übermäßige Verzögerung und Replay. Sie verhinderten keine Löschung oder Unterdrückung von Nachrichten. Eine fehlende authentisierte Antwort war laut RFC kein schlüssiger Beleg für Agenten- oder Netzfehler; sogar ein Authentisierungsfehlerhinweis konnte durch Uhr- oder Schlüsselabweichung fehlen.

SNMP legte auch keine allgemeine Reihenfolge für Zustandsänderungen fest. Der Manager sollte vor dem nächsten Eingriff positive Bestätigung oder Ablauf des vorherigen abwarten. snmpSetSerialNo in der SNMPv2 MIB bot eine gesonderte Ordnungshilfe, aber keinen Persistenz- oder Wirkungsnachweis.

Das Administrative Model aus RFC 1445 ergänzte Parties, Kontexte und Zugriffsregeln. Eine authentisierte Herkunft bedeutete weder allgemeine Objektberechtigung noch vollzogene Betriebswirkung.

Der öffentliche Zeuge blieb im USM erhalten

Das Party-Modell wurde nicht zur endgültigen Architektur. RFC 1910 erprobte Benutzer, Agentenidentität, Boot-Zähler, Zeitfenster und Zugriffsregeln. RFC 2574 und RFC 3414 definierten später das User-based Security Model für SNMPv3.

Identitäten und Schlüsselableitung änderten sich, der Zeuge blieb. Einweg-KeyChange-Objekte änderten nicht lesbare Schlüssel, ein Spin Lock koordinierte konkurrierende Schreiber und usmUserPublic trug einen Zufallsmarker. Ohne Antwort las der Manager diesen Wert, um Anfrageverlust von Antwortverlust zu trennen.

Diese Kontinuität macht die Kryptographie von 1993 nicht aktuell. Sie zeigt, dass ein entfernter Wechsel eines nicht lesbaren Geheimnisses neben der Antwort eine unabhängige Zustandsbeobachtung braucht.

Quellen