Zusammenfassung

  • RFC 2402 berechnete den AH-ICV über eine vorbereitete Ansicht: unveränderliche Felder blieben, vorhersehbare veränderliche Felder erhielten ihren erwarteten Ankunftswert, unvorhersehbare Inhalte wurden für die Berechnung durch Null ersetzt.
  • Ein passender ICV bewies nicht, dass jedes Netzbit gleich blieb. Fragmentierung folgte dem ausgehenden AH, Zusammensetzen ging der Eingangsprüfung voraus; Replay-Prüfung konnte deaktiviert sein, Richtlinie und Anwendung entschieden später.

TTL muss sich auf dem Weg ändern. Auch die IPv4-Prüfsumme ändert sich danach. Eine wörtliche Authentisierung würde normale Weiterleitung als Manipulation behandeln; vollständiges Auslassen würde Position und Länge verlieren. RFC 2402 ließ die Oktette im Aufbau stehen und setzte ihren Inhalt nur in der ICV-Eingabe auf Null.

Der IP Authentication Header von November 1998 bot verbindungslose Integrität und Ursprungsprüfung sowie einen vom Empfänger je SA wählbaren Replay-Schutz. Vertraulichkeit bot er nicht. Er erfasste höhere Protokolldaten und so viel IP-Header wie möglich, nannte den Schutz aber selbst stückweise, weil manche Felder unterwegs wechseln.

AH enthielt Next Header, Länge, Reserved, SPI, Sequence Number und Authentication Data. SPI, Ziel und AH-Protokoll wählten die einseitige Association samt Algorithmus und Schlüssel. Die Sequenznummer wurde immer gesendet und erhöht, auch wenn der Empfänger sie nicht gegen Wiederholung prüfte.

Die ICV-Eingabe hatte drei Klassen. Unveränderliche Felder und höhere Daten gingen mit ihrem Wert ein. Veränderliche, deren Ankunftswert vorhersehbar war, wurden auf diesen Zustand gebracht. Unvorhersehbare Inhalte erhielten Null. Authentication Data selbst wurde während der Berechnung ebenfalls genullt, bevor das Ergebnis dort eingetragen wurde.

Nullfüllung war keine Löschung. Die Oktette blieben an ihrem Platz, erhielten Ausrichtung und banden die Feldlänge in die Struktur ein, obwohl der Inhalt außerhalb lag. Die vorbereitete Ansicht teilte das Skelett des Pakets, nicht sämtliche Werte. „Normalisierung“ ist Erklärungssprache; RFC 2402 unterschied unveränderlich, veränderlich aber vorhersehbar und veränderlich.

Bei IPv4 wurden Version, IHL, Total Length, Identification, AH-Protokollwert, Source Address und gewöhnliche Destination Address einbezogen. Ein Ziel unter Source Routing war veränderlich, aber vorhersehbar. TOS, Flags, Fragment Offset, TTL und Header Checksum wurden genullt. Router änderten TOS, konnten DF setzen, verringerten TTL und berechneten die Prüfsumme neu.

Ein gültiger ICV konnte daher neben einer kleineren TTL stehen. Er bewies Gleichheit der vorbereiteten Ansicht unter SA, Schlüssel und Algorithmus, nicht Stillstand des übertragenen Bildes. Ausgeschlossene Felder blieben im Paket; lediglich ihre Werte lagen außerhalb der AH-Aussage.

IPv6 folgte demselben Prinzip. Class, Flow Label und Hop Limit wurden im 1998er Modell genullt. Ein Ziel unter Routing Header war vorhersehbar. Hop-by-Hop- und Destination-Optionen kennzeichneten veränderliche Option Data; deren Inhalt wurde zu Nulloktetten, während Typ und Länge geschützt blieben. Neue Optionen mussten ihr Verhalten definieren.

Padding trennte Rechnung und Übertragung weiter. Explizites Padding in Authentication Data wurde gesendet und authentisiert. Algorithmen konnten zusätzlich implizite Nulloktette bis zur Blockgrenze verlangen; sie nahmen an der Rechnung teil, erschienen aber nie im Netz. Die Ansicht konnte Ersatzwerte und ungesendete Bytes enthalten.

Fragmentierung bestimmte die Prüfeinheit. Im Transportmodus wurde AH auf das vollständige Datagramm angewandt, Fragmentierung kam danach. Router durften teilen, doch der Empfänger setzte vor AH zusammen. Ein dort noch als Fragment erscheinendes Objekt war zu verwerfen und zu protokollieren. Im Tunnelmodus konnte ein geschütztes äußeres Paket dagegen ein bereits fragmentiertes inneres Paket tragen.

Eingehend rekonstruierte die Implementierung die Ansicht: SA wählen, empfangenen ICV sichern, Authentication Data und unvorhersehbare Felder nullen, implizites Padding ergänzen, berechnen und vergleichen. Bei aktivem Replay-Schutz konnte die Sequenz vorgeprüft werden, das Fenster rückte erst nach ICV-Erfolg. Ohne Schutz bewies eine vorhandene Nummer keine Replay-Entscheidung.

RFC 2402 erklärte das Datagramm an diesem AH-Schritt für gültig. RFC 2401 verlangte danach noch Eingangsrichtlinie vor Übergabe oder Weiterleitung, die Anwendung entschied wiederum später. Association, Senderansicht, ICV, Fragmente, Zusammensetzung, Empfängeransicht, Vergleich, optionales Replay, Richtlinie und Anwendung waren getrennte Belege.

Die Spezifikation ist historisch. Sie ersetzte RFC 1826 und wurde durch RFC 4302 und RFC 4305 ersetzt. HMAC-MD5 und HMAC-SHA-1 sind keine heutigen Empfehlungen. RFC 4302 behielt das Teilabdeckungsprinzip, änderte aber Association-Suche, erweiterte Sequenzen und Algorithmusverwaltung.

Lu Hengs spätere Texte über laufenden Code und Realitätsebenen sind eine analytische Linse, nicht Sprache des RFC. „Authentisiert“ wirkt nur durch die tatsächlich gebaute und verglichene Ansicht; es kann ausgeschlossene Felder, optionale Kontrollen und spätere Ergebnisse nicht mitbehaupten.

Quellen