IKEv1 gegen IKEv2: Authentifizierung mit vorab geteiltem Schlüssel und was sich unterscheidet

Zwei Gateways, die mit demselben vorab geteilten Schlüssel konfiguriert sind, schließen einen Handshake ab, und ein Paketmitschnitt zeigt kein Geheimnis, das über die Leitung geht. Das ist der Teil, den sich Leute merken. Der interessante Teil ist, was jede Version tatsächlich berechnet, um zu beweisen, dass das Geheimnis bekannt ist, denn IKEv1 und IKEv2 bauen diesen Beweis aus unterschiedlichen Eingaben und legen dabei unterschiedliche Informationen offen. Lesen Sie die beiden Spuren nebeneinander, und der Unterschied hört auf, kosmetisch zu sein.

Was der Beweis leisten muss

Diffie-Hellman gibt beiden Partnern einen gemeinsamen Wert, dessen öffentliche Hälften jeder Berechnende ebenfalls berechnen kann. Für sich genommen beweist das nichts über Identität: Ein Angreifer, der einen Schlüsselaustausch abschließt, hat denselben gemeinsamen Wert wie Ihr Gateway. Der Authentifizierungsschritt existiert, um diesen Austausch an ein Geheimnis zu binden, das nur die vorgesehenen Partner besitzen, sowie an die Identitäten und Parameter, auf die sie sich geeinigt haben.

Diese Bindung ist der Grund, warum der Hash mehr als den Schlüssel abdeckt. Würde er nur das Geheimnis abdecken, könnte ein Angreifer ihn in einen anderen Austausch mit anderen Identitäten oder Vorschlägen einspielen.

IKEv1 Main Mode: SKEYID ableiten und dann beweisen

Main Mode läuft in sechs Nachrichten ab. Das erste Paar verhandelt die Sicherheitsassoziation, das zweite tauscht öffentliche Diffie-Hellman-Werte und Nonces aus, und das dritte trägt Identitäten plus Authentifizierungs-Hashes unter der gerade aufgebauten Verschlüsselung. RFC 2409 definiert die Konstruktion: Bei Authentifizierung mit vorab geteiltem Schlüssel wird SKEYID aus dem Geheimnis und beiden Nonces abgeleitet, und das spätere Schlüsselmaterial wird aus SKEYID, dem gemeinsamen Diffie-Hellman-Wert, den Cookies und Konstanten abgeleitet.

Der Hash in Nachricht fünf und sechs wird über den Diffie-Hellman-Wert, die beiden Cookies, den Vorschlag und die Identität des Absenders berechnet, mit SKEYID als Schlüssel. Der Empfänger berechnet ihn mit seinem eigenen konfigurierten Geheimnis neu. Eine Abweichung beendet den Austausch, und zu keinem Zeitpunkt ist das Geheimnis selbst eine Nutzlast.

Aggressive Mode komprimiert dieselbe Arbeit in drei Nachrichten, was bedeutet, dass Identitäten und der Authentifizierungs-Hash unterwegs sind, bevor ein verschlüsselter Kanal existiert. Das ist eine echte Exposition für ein erratbares Geheimnis und unabhängig von der Frage, ob das Geheimnis übertragen wurde. IKEv1 ist durch RFC 9395 veraltet, sodass eine Altspur eine Diagnoseübung und kein Bereitstellungsziel ist.

IKEv2: eine andere Ableitung und eine andere AUTH-Nutzlast

IKEv2 verwendet den IKEv1-Schlüsselplan nicht wieder. Die anfänglichen IKE-Schlüssel stammen aus einem Startwert, der aus den Nonces und dem gemeinsamen Diffie-Hellman-Wert gebildet wird, und die untergeordneten Sicherheitsassoziationen leiten sich daraus ab. Der vorab geteilte Schlüssel speist den Startwert überhaupt nicht.

Die Authentifizierung erscheint dann als AUTH-Nutzlast. Für die Authentifizierung mit geteiltem Schlüssel legt RFC 7296 eine aufgefüllte Form des Geheimnisses fest, die durch Hashen des Geheimnisses mit der festen Zeichenkette Key Pad for IKEv2 entsteht, und danach durch Hashen der signierten Austauschdaten und der Identität mit diesem aufgefüllten Schlüssel. Der Prüfer kann denselben Wert rekonstruieren; ein Beobachter kann es ohne das Geheimnis nicht.

Beachten Sie, was sich geändert hat. In IKEv1 ist das Geheimnis in den Schlüsselplan eingebacken, bevor der Authentifizierungs-Hash existiert; in IKEv2 ist der Schlüsselplan unabhängig vom Geheimnis, und der Beweis ist eine eigene Nutzlast, die an die signierten Oktette gebunden ist. Dieselbe konzeptionelle Garantie, andere Maschinerie, und deshalb lassen sich Parameternamen und Mitschnitte nicht eins zu eins abbilden.

Was ein Beobachter tatsächlich lernt

Öffentliche Diffie-Hellman-Werte, Vorschläge, Nonces und Cookies sind in beiden Versionen sichtbar. Identitäten sind im IKEv1 Aggressive Mode sichtbar und in den anderen Fällen geschützt. Das Geheimnis ist nie sichtbar.

Dieser letzte Satz hat eine Grenze, die es wert ist, genannt zu werden. Ein schwaches, von Menschen gewähltes Geheimnis lässt sich durch Raten angreifen: Der Angreifer berechnet, wie der Authentifizierungswert für ein Kandidatengeheimnis aussehen würde, und vergleicht. Der IKEv1 Aggressive Mode macht das am billigsten, weil der Beweis offenliegt, und die Standards warnen allgemein vor Geheimnissen mit niedriger Entropie. Das Geheimnis nie zu übertragen ist nicht dasselbe, wie ein schlechtes Geheimnis sicher zu machen.

Was mit dem Vergleich zu tun ist

Verwenden Sie ein einzigartiges Geheimnis pro Partnerpaar, erzeugen Sie es aus einer Zufallsquelle und rotieren Sie es über denselben Bereitstellungspfad, der es verteilt hat. Wenn das Geheimnis in einer Konfigurationsvorlage gespeichert ist, die an jede Filiale geht, ist eine Kompromittierung an einer Stelle eine Kompromittierung überall.

Bevorzugen Sie zertifikatsbasierte Authentifizierung, wo die Betriebskosten akzeptabel sind, da sie das Raten des gemeinsamen Geheimnisses beseitigt und jedem Partner eine eigene Identität gibt. Wo ein vorab geteilter Schlüssel bleibt, halten Sie ihn lang, begrenzen Sie seinen Geltungsbereich und behandeln Sie die IKE-Version als Sicherheitsentscheidung statt als Interoperabilitätsdetail.