Zusammenfassung

  • RFC 2410 definierte NULL als Identitätsfunktion mit null Bit Schlüsselmaterial und null Bit Initialisierungsvektor. Keine Vertraulichkeit war damit eine präzise, verhandelbare ESP-Option statt einer mehrdeutigen Auslassung.
  • NULL allein bot keinen Sicherheitsdienst. ESP konnte es mit starker Integrität kombinieren; ein gewöhnliches ESP-Paket verriet einem Zwischenbeobachter trotzdem nicht deterministisch, ob die Nutzlast verschlüsselt oder nur authentisiert war.

Die Pointe von RFC 2410 ist nicht, dass der Algorithmus schwach war. Er tat definitionsgemäß nichts. NULL(b) = I(b) = b: Der ausgegebene Block entsprach dem eingegebenen Block.

Hinter der humorvollen Erzählung über römische Kryptografie stand eine enge technische Spezifikation. Für die IKE-Schlüsselextraktion musste die Schlüssellänge null Bit betragen, ebenso die IV-Länge. NULL war zustandslos und hatte eine Blockgröße von einem Oktett.

Gerade diese Detailtreue beseitigte Mehrdeutigkeit. Ohne benannte Transformation hätte ein fehlender Verschlüsselungswert Konfigurationsfehler, Voreinstellung oder absichtliche Entscheidung bedeuten können. Mit NULL nutzten beide Seiten dieselbe Vorschlags- und Auswahlmechanik und konnten Integrität ohne Vertraulichkeit vereinbaren.

Die Einordnung als Verschlüsselungstransformation beschrieb den Protokollplatz, nicht die Wirkung. RFC 2410 erklärte ausdrücklich, dass NULL weder Vertraulichkeit noch einen anderen Sicherheitsdienst liefere. Schutz entstand nur durch die separat gewählte Authentisierungs- und Integritätstransformation.

Damit war ESP_NULL nicht gleichbedeutend mit ungeschütztem IP. Zusammen mit einem starken Authentisierungsalgorithmus konnte ESP Datenursprung und Integrität schützen, ohne die Nutzlast zu verbergen. Der Vergleich mit AH blieb begrenzt: ESP_NULL bezog den IP-Header nicht so in die Berechnung ein wie AH dessen geeignete Teile.

Gleicher Authentisierungsalgorithmus konnte vergleichbare kryptografische Stärke bedeuten. Daraus folgten weder identisches Paketformat noch identisches NAT-Verhalten oder dieselbe lokale Zulässigkeit. Die Dienstbeschreibung ersetzte nicht die Implementierungs- und Policy-Belege.

RFC 2406 verlangte mindestens einen starken Verschlüsselungs- oder Authentisierungsalgorithmus pro ESP-SA. RFC 4303 erhielt die Invariante: Vertraulichkeit und Integrität durften in bestimmten Fällen jeweils NULL sein, aber niemals gleichzeitig. Ein ESP-Header allein durfte keinen Schutz vortäuschen.

Ein Logeintrag ENCR_NULL beschreibt deshalb nur die Vertraulichkeitsseite. Für eine belastbare Aussage fehlen mindestens Integritätsalgorithmus, Schlüsselherkunft, Replay-Policy, Richtlinienversion, eingehende und ausgehende SA sowie Installations- und Prüfergebnis.

NULL ist auch nicht automatisch ein Downgrade. Erlaubte die Policy Integrität ohne Vertraulichkeit, war die Auswahl korrekt. Verlangte sie Verschlüsselung und akzeptierte die Aushandlung trotzdem NULL, kann derselbe Wert Fehlkonfiguration oder Angriff belegen. Erst Policy und Transcript unterscheiden die Geschichten.

Im IKEv1/IPsec-DOI-Register trug ESP_NULL die Kennung 11. Das heutige IKEv2-Register listet ENCR_NULL ebenfalls als 11 für ESP und kennzeichnet es als unzulässig für den Schutz von IKEv2 selbst. Ohne Tabelle, Transformationstyp und Protokollkontext ist die Zahl bedeutungslos.

Ein Register schafft gemeinsame Semantik. Es belegt keine Nutzung. Es zeigt nicht, ob ein Peer den Wert anbot, der andere ihn auswählte, beide Kernel ihn installierten oder ein Paket darunter verarbeitet wurde. Symbol und laufender Zustand bleiben getrennt.

RFC 9395 verschob IKEv1 und seine Begleitdokumente in den historischen Status und schloss alte Register. Zugleich wurden mehrere überalterte Algorithmen abgewertet; ENCR_NULL gehörte nicht zu ihnen. Integritäts-ESP ohne Vertraulichkeit blieb Teil späterer ESP-Regeln.

RFC 8221 verlangte weiterhin die Implementierung von ENCR_NULL, damit authentisiertes ESP ohne Verschlüsselung interoperabel blieb. Ein Grund war die bessere Eignung von ESP gegenüber AH bei NAT. Implementierungspflicht sichert eine gemeinsame Fähigkeit, nicht ihre Verwendung in jeder SA.

Für die Endpunkte war die Auswahl eindeutig, weil sie die SA kannten. Ein Zwischenknoten sah SPI und ESP-Format, verfügte aber nicht zwingend über den vertrauenswürdigen Zustand, der den SPI einer Transformation zuordnete. Im Paket fehlte ein allgemein sichtbares, deterministisches Kennzeichen.

Das wurde relevant, als Unternehmensnetze integritätsgeschützten Klartext auf Schadsoftware oder Zugriffsregeln prüfen wollten. Ein verschlüsseltes Paket als Klartext zu behandeln zerstört die Analyse. Ein ESP_NULL-Paket für verschlüsselt zu halten kann eine Inspektionslücke öffnen.

RFC 5840 führte WESP ein, weil gewöhnliches ESP die beiden Fälle nicht deterministisch trennte. Eine zusätzliche Hülle konnte Vertraulichkeitsnutzung explizit anzeigen und Inspektion technisch ermöglichen. Das bewies weder weltweite Einführung noch eine allgemeine Berechtigung zur Inspektion.

RFC 5879 dokumentierte Heuristiken für bestehende Endpunkte. Ein Beobachter prüfte plausible innere Protokollstrukturen, Längen und Konsistenz. Das konnte betrieblich helfen, blieb aber eine Schlussfolgerung und keine authentisierte Aussage des SA-Eigentümers.

Auch der Verwaltungsrahmen war wesentlich. Die beschriebenen Inspektionsfälle lagen typischerweise in einer kontrollierten Organisation, deren Policy verschlüsseltes Umgehen der Kontrolle verhindern sollte. Außerhalb einer solchen Beziehung kann ein Beobachter weder Offenheit erzwingen noch aus lesbaren Bytes ein Mandat ableiten.

Deterministische Sichtbarkeit und Befugnis sind ebenfalls verschieden. WESP kann anzeigen, dass keine Vertraulichkeit eingesetzt wird. Es entscheidet nicht, wer lesen darf, für welchen Zweck, wie lange Daten gespeichert werden und wer die Folgen trägt.

Hinter der Klassifikation folgen weitere unabhängige Schritte. Eingehende und ausgehende SA sind getrennt. Aushandlung beweist keine beidseitige Installation. Bestehende SA beweist keine erfolgreiche Integritätsprüfung. Eine gültige Prüfung beweist keine Annahme durch Replay-Fenster, innere Firewall oder Anwendung.

Ein brauchbarer Nachweis verbindet deshalb Peer-Identität, Policy-Version, Vorschlag, Auswahl, richtungsbezogene SPI, beide Algorithmen, Schlüsselprovenienz, Installationsantwort, Sequenzzustand, Zähler, Klassifikationsmethode, Inspektionsbefugnis und Anwendungsergebnis.

Lu Hengs Realitätsschichten ordnen die Rollen. RFC und Register definieren ein Symbol. IKE erzeugt eine Vereinbarung. Der Kernel hält laufenden Zustand. Das Paket liefert Beobachtung. Der Zwischenknoten klassifiziert. Die Policy erteilt Befugnis. Die Anwendung besitzt das Ergebnis.

Die minimale Ausgangsspezifikation beschränkte die gemeinsame Schicht auf die Identitätsfunktion und ihre notwendigen Parameter. Spätere Entscheidungen – Integrität allein, WESP, Heuristik, Inspektion – blieben bei den Teilnehmern, die Code betrieben und Konsequenzen trugen. Erst Implementierung und Annahme machten sie real.

RFC 2410 machte das Nichtverschlüsseln eindeutig. Die spätere Geschichte zeigte, dass eine eindeutige Entscheidung zwischen Endpunkten noch lange keine öffentliche Eigenschaft des Pakets ist.

Quellen