Zusammenfassung

  • AES-XCBC-MAC-96 überträgt die ersten 96 Bit eines 128-Bit-Ergebnisses als IPsec-Prüfwert. RFC 3664 verwendet dagegen alle 128 Bit als PRF-Ausgabe für IKE.
  • RFC 4434 behält diese Ausgabe und das Ergebnis für 128-Bit-Schlüssel bei, hebt aber die feste Schlüssellänge auf. In IKEv2 gilt die feste Längenregel für die Schlüsselerzeugung, die variable für die Authentisierung mit einem gemeinsamen Geheimnis.

Drei Längen, drei Bedeutungen

Die Angabe „128 Bit“ bezeichnet in dieser Geschichte nicht nur eine Größe. RFC 3566 berechnet einen 128-Bit-AES-XCBC-Wert und sendet davon die linken 96 Bit im ESP- oder AH-Prüffeld. Die Gegenseite berechnet den vollständigen Wert und vergleicht dieselben 96 Bit. Das gekürzte Feld dient der Paket-Authentisierung; es ist nicht das gesamte Ergebnis, das die Konstruktion erzeugen kann. RFC 3566

IKE brauchte etwas anderes. Die Ausgabe seiner Pseudozufallsfunktion (PRF) fließt in die Schlüsselerzeugung ein. RFC 3664 hielt daher 96 Bit für zu kurz, um in IKEv1 oder IKEv2 dauerhaft als PRF-Ausgabe zu dienen. Die Änderung war eng begrenzt: AES-XCBC wird ohne den abschließenden Kürzungsschritt verwendet. Damit beträgt die PRF-Ausgabe 128 Bit. Das bedeutet nicht, dass jeder von IKE abgeleitete Schlüssel 128 Bit lang ist; die Ausgabe geht in die protokolleigene Ableitung ein. RFC 3664

RFC 3664 übernahm außerdem eine Vorgabe von AES-XCBC-MAC-96: Der Schlüssel musste genau 128 Bit lang sein. Die Ausgabe war vollständig, der Eingabeschlüssel aber fest dimensioniert. Für IKE-Geheimnisse anderer Länge war diese Grenze unhandlich. Der spätere Text verändert das Ergebnis bei einem 128-Bit-Schlüssel nicht, sondern legt fest, wie der Eingang vor dem AES-Schritt normalisiert wird. RFC-3664-Info und Errata RFC-3664-Errata

Die Korrektur von 2006 betraf den Eingang

RFC 4434 streicht die Vorgabe einer exakt 128 Bit langen Eingabe. Ein 128-Bit-Schlüssel wird unverändert verwendet. Ein kürzerer Schlüssel wird rechts mit Nullbits auf 128 Bit aufgefüllt. Bei 129 Bit oder mehr wird die PRF erneut ausgeführt: mit einem 128-Bit-Schlüssel aus Nullen und dem zu langen Schlüssel als Nachricht. Das Ergebnis dient als normalisierter Schlüssel. Dieser Weg ist weder gewöhnliches Abschneiden noch eine allgemeine Hashfunktion. RFC 4434

Die Formulierung „derselbe Algorithmus“ kann zwei Fragen verdecken: welche Ergebnisse auf der Leitung erscheinen und welche Eingaben Implementierungen akzeptieren. RFC 4434 hält für 128-Bit-Schlüssel dieselben Leitungsergebnisse wie RFC 3664 fest. Andere Längen werden nicht mehr abgewiesen, sondern in einen 128-Bit-AES-Schlüssel überführt. Die Ausgabe bleibt der vollständige 128-Bit-XCBC-Wert, nicht das 96-Bit-Prüffeld für ESP/AH. RFC-4434-Info und Errata RFC-4434-Errata

IKEv2 gab der PRF zwei Aufgaben

Der Nachfolger unterscheidet außerdem zwei Verwendungen in IKEv2. Bei der Erzeugung von Schlüsselmaterial gilt AES-XCBC-PRF-128 als PRF mit fester Länge; das IKEv2-Verfahren verteilt die Beiträge auf beide Nonces. Bei der Authentisierung eines gemeinsamen Geheimnisses behandelt RFC 4434 sie als variabel lang, sodass das Geheimnis selbst nicht 128 Bit lang sein muss. Der Text nennt die Logik etwas umständlich und begründet sie mit Interoperabilität zwischen Implementierungen, die der festen Regel von RFC 3664 folgen, und solchen, die die flexiblere Regel nutzen. RFC 4306 RFC 4434

Das ist die Überarbeitung eines Schnittstellenvertrags, kein Beleg für einen konkreten Implementierungsfehler oder eine breite Einführung. RFC 4434 behält die volle Ausgabe und den 128-Bit-Fall bei und beschreibt die Umwandlung kürzerer und längerer Eingaben. Die späteren Empfehlungen in RFC 8221 betreffen ESP/AH-Authentisierungsalgorithmen; sie belegen weder eine IKE-PRF-Aushandlung noch das Verhalten einzelner Implementierungen. RFC 8221

Die Entwicklung lässt sich in getrennten Schritten lesen: einen MAC für ein Paketfeld kürzen, den vollständigen Wert für die IKE-PRF behalten und den Eingabeschlüssel je nach Zweck normalisieren.

Quellen