Zusammenfassung

  • RFC 2411 teilte die ursprüngliche IPsec-Spezifikation in sieben Zuständigkeitsbereiche, damit neue Algorithmusdokumente ESP, AH, Schlüsselverwaltung und zugewiesene Werte nicht widersprüchlich kopierten.
  • Die Roadmap war informativ: Sie zeigte zur maßgeblichen Quelle, bewies aber weder die implementierte Revision noch die ausgehandelte Auswahl, den Einbau der SAs oder den Erfolg des Datenverkehrs.

Die zentrale Abbildung von RFC 2411 zeigt keine Bits auf der Leitung. Sie zeigt Kästchen.

Oben steht die Architektur, darunter ESP und AH. Verschlüsselungs- und Authentisierungsalgorithmen sind seitlich angeordnet. In der Mitte verbindet die Domain of Interpretation gemeinsame Werte. Von unten kommt die Schlüsselverwaltung. Für einen flüchtigen Blick ist es ein Inhaltsverzeichnis mit Pfeilen. Für die damalige Entwicklung von IPsec war es eine Regel darüber, wer welche Aussage besitzen durfte.

Neue Algorithmen sollten auch nach der Veröffentlichung der Basisdokumente hinzukommen. Würde für jeden Algorithmus die Architektur neu geöffnet, verlöre der Kern seine Stabilität. Würde hingegen jedes Algorithmusdokument die allgemeinen ESP- und AH-Regeln wiederholen, entstünden mehrere Fassungen derselben Aussage.

Die erste Kopie erleichtert das Lesen. Die zehnte erschwert die Interoperabilität.

Ein veralteter Standardwert bleibt in einem Text stehen. Eine Warnung fehlt in einem anderen. Eine Variante beschreibt Padding anders. Jedes Dokument kann für sich plausibel wirken, während zwei Produkte aus der Gesamtheit verschiedene Protokolle bauen. RFC 2411 nannte diese Entwicklung den Effekt der „draft explosion“.

Die Antwort war keine allmächtige Gesamtspezifikation. Sie war eine Aufteilung der Verantwortung.

Das Architekturdokument erhielt die gemeinsamen Begriffe, Sicherheitsanforderungen und Mechanismen. ESP und AH erhielten ihre Paketformate und allgemeinen Verarbeitungsregeln. Ein Verschlüsselungsdokument sollte erklären, wie genau ein Algorithmus in ESP eingesetzt wird. Wenn ein Authentisierungsverfahren in ESP und AH gleich arbeitet, sollte ein einziges Dokument beide abdecken. Das DOI stellte die bekannten Kennungen und operativen Parameter bereit. Schlüsselverwaltungsdokumente waren für Aufbau und Verwaltung des Schlüsselmaterials zuständig.

Die Zeichnung war keine Befehlskette. Eine DOI-Kennung bewertete nicht die Sicherheit eines Algorithmus. Eine Roadmap, die auf ESP verwies, durfte die ESP-Spezifikation nicht ersetzen. Jede Quelle hatte eine begrenzte Aussagefläche.

Beim Schlüsselmaterial wird diese Grenze technisch greifbar. Die Schlüsselverwaltung musste Material in ausreichender Länge und Stärke erzeugen. Die Eigenschaften einzelner Algorithmen gehörten jedoch zu deren Dokumenten: Schlüssellängen, Reihenfolge, Paritätsbehandlung, schwache Schlüssel und besondere Formate. Andernfalls müsste die Schlüsselverwaltung bei jeder neuen Transformation ihre fremden Detailkenntnisse erweitern.

Die Architektur beschrieb, wie bei mehreren benötigten Schlüsseln aus einem gemeinsamen Block extrahiert wird. Wo diese Aufteilung stattfand, blieb offen. Ein Schlüsselverwaltungsprozess konnte vor der Übergabe teilen; alternativ konnte der Kernel den gesamten Block erhalten und dort das im RFC so genannte „slicing and dicing“ ausführen.

Das gemeinsame Ergebnis war normiert. Die innere Prozessgrenze war es nicht.

Das ist keine Lücke, sondern eine bewusste lokale Entscheidung. Die gemeinsame Schicht endet dort, wo der entfernte Teilnehmer keine Gleichförmigkeit benötigt.

Bei optionalen Parametern verlangte die Roadmap dagegen Zurückhaltung. Wo ein fester Wert technisch vernünftig war, sollte er gewählt werden. Jede weitere Aushandlungsoption vergrößerte die Zahl der Vorschläge, Codepfade und möglichen Schnittmengen. Zwei konforme Implementierungen konnten lange Listen unterstützen und trotzdem keine gemeinsame Auswahl finden.

Musste eine Option bestehen bleiben, brauchte sie eine Begründung, Vorgaben oder Bereiche und eine Erklärung ihrer Auswirkungen auf Format und Verarbeitung. „Konfigurierbar“ war noch keine interoperable Definition.

Die empfohlenen Inhalte künftiger Algorithmusdokumente lesen sich wie eine Prüfliste: minimale, maximale und empfohlene Schlüssellängen; Zufallsquellen; schwache Schlüssel; Erneuerung; Leistung; Feldformate; Padding; Wechselwirkungen; bekannte Angriffe; Implementierungsfallen; Validierungsverfahren und Testvektoren.

RFC 2411 führte diese Prüfungen nicht durch. Es wies die Quelle, die den Mechanismus verstand, an, die Prüfung möglich zu machen.

Genau deshalb darf die Roadmap nicht als Betriebsnachweis verwendet werden. Ein Eintrag in der Karte beweist eine dokumentierte Zuständigkeit. Eine IANA-Nummer beweist einen eindeutigen Namen. Eine Produktangabe beweist eine Behauptung. Ein IKE-Protokoll kann eine Auswahl beweisen. Keine dieser Ebenen beweist allein, dass beide Kernel korrekte SAs installiert haben oder dass Nutzverkehr sein Ziel erreichte.

Karte, Quellregel, Implementierung, Aushandlung, Installation, Paket und Ergebnis brauchen eigene Belege.

RFC 2411 begrenzte seinen Anspruch ausdrücklich. Es war Informational und spezifizierte keinen Internetstandard. Für tatsächliche Sicherheitsverfahren verwies es auf Architektur, ESP, AH und die Algorithmusdokumente. Auch der Hinweis, dass viele Verschlüsselungsverfahren ohne Authentisierung nicht sicher sind, war eine Leseanweisung und kein Zertifikat für ein System.

RFC 6071 löste die Roadmap 2011 ab. Die Zahl der IPsec- und IKE-RFCs war über die ursprüngliche Arbeitsgruppe, Folgegruppen und andere Protokolle hinweg gewachsen. Das neue Dokument bezeichnete sich als Momentaufnahme. Seine Anforderungsstufen galten zum Stand Februar 2011; spätere RFCs konnten sie ändern. Bei einem Widerspruch sollte das andere RFC Vorrang haben.

Eine belastbare Zusammenfassung erklärt, wann sie nachrangig ist.

RFC 6071 hielt zugleich fest, dass formale Ablösung und eingesetzte Software verschiedene Tatsachen waren. Das neue IPsec hatte das alte abgelöst, doch die alte Fassung blieb in Implementierungen verbreitet. IKEv2 hatte IKEv1 abgelöst, während IKEv1 weiter betrieben wurde. „Obsolet“ verändert den Dokumentgraphen. Es entfernt keinen Code. „Im Einsatz“ beschreibt einen Bestand, nicht dessen heutige Empfehlung.

Auch die Karte änderte sich. Kombinierte Algorithmen erhielten eine eigene Gruppe. Pflichtalgorithmen wanderten in getrennte Dokumente, damit kryptographische Vorgaben schneller als Paketformate aktualisiert werden konnten. IKEv2 vereinte Inhalte, die IKEv1 auf ISAKMP, Oakley und DOI verteilt und teilweise widersprüchlich beschrieben hatte.

Zu wenig Trennung schafft einen unbeweglichen Monolithen. Zu viel Trennung macht den Leser zum Integrator. Die richtige Grenze folgt Änderungstakt, Fachverantwortung und Interoperabilität.

RFC 8221 setzt dieses Modell fort. Kryptographische Implementierungsanforderungen und Nutzungshinweise müssen sich ändern können, wenn neue Angriffe, Algorithmen und Geräteklassen auftreten. Das IANA-Register hält Bezeichner stabil, aber ein registrierter Wert ist weder empfohlen noch aktiviert noch ausgehandelt. RFC 9395 konnte später IKEv1 und alte Algorithmen zurückziehen, ohne die historische Spur zu löschen.

Die historische Leistung von RFC 2411 bestand darin, Dokumentenarchitektur als Protokolltechnik zu behandeln. Gemeinsame Regeln gehörten in die gemeinsame Schicht, spezielle Regeln an den Mechanismus, interne Entscheidungen zur Implementierung, sofern sie den Vertrag zwischen Peers nicht änderten.

Doch kein Kästchen installierte eine SA. Erst Code konnte eine Regel übernehmen. Erst zwei Peers konnten eine kompatible Auswahl treffen. Erst beide Systeme konnten Zustand einbauen. Erst Pakete konnten zeigen, was im Datenpfad tatsächlich geschah.

RFC 2411 ordnete die Zuständigkeiten. Die laufende Wahrheit blieb bei den Maschinen.

Quellen