Zusammenfassung

  • Im aggressiven Drei-Nachrichten-Beispiel von RFC 2412 konnten die Signaturen geprüft und der KEYID authentifiziert werden, während das Diffie-Hellman-Material noch als uncomputed galt.
  • Ein Kommunikationsnachweis war kein Berechnungsnachweis; Berechnung war weder beidseitige SA-Installation noch geschützter Paketfluss oder Anwendungserfolg.

Ein Zustandswort wird gefährlich, sobald es für mehr stehen soll, als der zugrunde liegende Übergang beweist.

RFC 2412 erschien im November 1998 als Informational und beschrieb OAKLEY. Zwei authentifizierte Parteien sollten mit Diffie-Hellman geheimes Schlüsselmaterial bestimmen, Algorithmen wählen, Perfect Forward Secrecy nutzen und sich in ISAKMP einfügen können. Das Dokument war kein Internetstandard und beanspruchte nicht, mit seinem Austausch bereits die späteren AH- oder ESP-Zustände installiert zu haben.

Das aggressive Beispiel bestand aus drei Nachrichten. Der Initiator sandte Cookie, Gruppe, öffentliches g^x, Algorithmusangebote, Identitäten, Nonce und Signatur. Der Responder ergänzte sein Cookie, g^y, die Auswahl, beide Nonces und seine Signatur. Die letzte signierte Nachricht des Initiators schloss den Transcript.

Die Signaturen konnten laut RFC als aufzeichnungsfähiger Kommunikationsnachweis dienen. Unmittelbar danach folgt die Begrenzung: Das von den Gruppenexponenten implizierte Schlüsselmaterial war zum Abschluss des Austauschs nicht erforderlich.

Eine Implementierung durfte x und g^y speichern, das Material als uncomputed markieren und es später berechnen.

Der Verarbeitungsablauf machte daraus eine konkrete Reihenfolge. Nach Prüfung der Responder-Signatur nahm der Initiator g^y in seinen Zustand auf. Er konnte (g^y)^x = g^xy berechnen, durfte dies aber bis nach dem Versand der letzten Antwort verschieben. Gleichwohl markierte er den KEYID als authentifiziert. Der Responder tat dasselbe nach gültiger Abschluss-Signatur und sollte anschließend g^xy berechnen und dem KEYID zuordnen.

Die Authentifizierung war abgeschlossen. Die Berechnung konnte noch ausstehen.

Schon die Benennung trennte beides. Die Cookies bildeten den KEYID, einen wiederverwendbaren Namen für Schlüsselmaterial und zugleich einen schwachen Anti-Clogging-Mechanismus. sKEYID bezeichnete das geheime Material hinter diesem Namen; es wurde nie übertragen und entstand im Beispiel aus g^xy, Nonces und Cookies. Ein Name konnte vor seinem Inhalt existieren. Seine Authentifizierung erzeugte den Inhalt nicht.

In Betriebssystemen und Managementoberflächen verschwindet diese Grenze leicht. Ein Log meldet „authenticated“, eine Ampel wird grün, die Anwendung liest „bereit“, und der Betreiber nimmt beidseitig installierte SAs sowie geschützten Verkehr an. Jeder Schritt legt dem vorigen Beleg eine fremde Aussage in den Mund.

Aufgeschobene Berechnung konnte vernünftig sein. Modulare Exponentiation war teuer. Außerhalb des kritischen Pfads der letzten Nachricht ließ sich sichtbare Latenz senken oder CPU-Last verteilen. Der Peer erhielt denselben signierten Transcript. Interoperabilität verlangte nicht zwingend denselben lokalen Ausführungszeitpunkt.

Der Aufschub verwandelte Rechenarbeit jedoch in Verwahrungspflicht. Privater Exponent, öffentlicher Peer-Wert, Gruppe, Cookies, Nonces, Identitäten und Algorithmen mussten korrekt zusammenbleiben. Danach folgten Prüfung, Berechnung, Ableitung und Bindung. Absturz, Ablauf, Neustart oder wiederverwendete Referenz konnten einen gültigen Transcript zurücklassen, obwohl der verwendbare Schlüssel nie entstand.

Deshalb braucht jede Stufe ihren Beleg. Der Transcript-Beleg bestätigt eine Signatur über bestimmte Felder. Der Validierungsbeleg bestätigt die zulässige öffentliche Gruppengröße. Der Berechnungsbeleg bestätigt g^xy und abgeleitetes Material. Der Bindungsbeleg ordnet es dem richtigen KEYID, den Identitäten und Algorithmen zu. Der Installationsbeleg weist den Laufzeitzustand nach. Erst Paket- und Anwendungsbelege zeigen Verkehr und Zweck.

Eine wahre Stufe ist keine Vollmacht für die nächste.

RFC 2412 warnte bereits vor bestimmten degenerierten Exponenten und verlangte gute Zufallsquellen. Das veröffentlichte Erratum korrigiert die Begriffe „safe prime“ und „Sophie Germain prime“, ohne den Berechnungsaufschub zu verändern.

RFC 6989 präzisierte später die Diffie-Hellman-Prüfungen für IKEv2, auch für Gruppen mit kleinen Untergruppen. Ein ungültiger KE-Payload durfte nicht zur Erzeugung einer IKE SA verwendet werden. Daraus lässt sich nicht ableiten, was ältere OAKLEY- oder IKEv1-Produkte tatsächlich prüften. Es bestätigt aber die Reihenfolge: Empfang ist nicht Validierung, Validierung nicht Berechnung, Berechnung nicht Installation.

RFC 2409 verband ISAKMP- und OAKLEY-Elemente zu IKEv1. Auch der Aggressive Mode konnte die letzte Nutzlast ungeschützt senden und dadurch die Exponentiation bis zum Abschluss der Verhandlung verschieben. Die Schlüsselableitung benötigte dennoch den realen gemeinsamen Wert. Ein Abschlusslabel lieferte keine fehlenden Bits.

IKEv2 ordnete den Ablauf in RFC 4306, 5996 und 7296 neu. RFC 7296 berechnet SKEYSEED aus Nonces und dem ephemeren Diffie-Hellman-Geheimnis und leitet daraus getrennte Schlüssel ab. Zudem kann eine IKE SA authentifiziert sein, während die Child SA oder eine Konfigurationsanforderung scheitert.

Das ist nicht OAKLEYs Zustandsautomat. Es ist ein späteres Beispiel für dieselbe methodische Vorsicht: Erfolg im Kontrollpfad beweist nicht den vollständigen Datenpfad.

Dokumentstatus und installierter Bestand bleiben ebenfalls getrennt. RFC 2412 war Informational. IKEv1 wurde standardisiert, später durch IKEv2 ersetzt; Algorithmenempfehlungen änderten sich; RFC 9395 erklärte IKEv1 und alte Algorithmen für überholt. Kein Dokument entfernt Code aus einem laufenden Gerät.

Lu Hengs Running-Code Primacy liefert dafür eine strenge Lesart. Ein Dokument darf einen Übergang definieren. Nur die laufende Implementierung erzeugt den Nachweis, dass er stattfand. Die Realitätsschichten lauten: Nachricht, Signatur, Validierung, Berechnung, Bindung, Installation, Paket, Anwendung.

Minimum Initial Specification zeigt zugleich, wo lokale Freiheit sinnvoll ist. Unabhängige Implementierungen brauchten gemeinsame signierte Felder, Ableitungsregeln und Parameterbedeutungen. Sie mussten nicht im identischen CPU-Zyklus exponentieren, solange die lokale Wahl Sicherheit und Interoperabilität nicht veränderte.

Wer verschiebt, kontrolliert aber das unsichtbare Intervall. Er muss die Eingaben erhalten, den Zustand präzise anzeigen und stärkere Aussagen zurücknehmen, wenn die Berechnung scheitert. Die Anwendung, die den Ausfall trägt, darf nicht aus einem grünen Feld raten müssen.

Uncomputed ist deshalb ein bemerkenswert ehrliches Wort. Es würdigt den gültigen Kommunikationsnachweis und weigert sich zugleich, einen noch nicht ausgeführten Rechenschritt vorzutäuschen.

Der Austausch war authentifiziert. Das Geheimnis musste noch berechnet werden. Die SA musste gebunden und installiert werden. Paket und Dienst mussten sich erst bewähren.

Vertrauen entsteht, wenn jedes Verb seinen eigenen Beleg behält.

Quellen