2.6. IKE-SA-SPIs und Cookies

Die ersten beiden Acht-Oktett-Felder im Header, genannt "IKE SPIs", werden zu Beginn von IKE-Paketen als Verbindungskennung verwendet. Jeder Endpunkt wählt eines der beiden SPIs und MUSS sie so wählen, dass sie eindeutige Kennungen einer IKE-SA sind. Ein SPI-Wert von Null ist speziell: Er zeigt an, dass der entfernte SPI-Wert dem Sender noch nicht bekannt ist.

Eingehende IKE-Pakete werden einem IKE-SA nur anhand des SPI des Pakets zugeordnet, nicht (beispielsweise) anhand der Quell-IP-Adresse des Pakets.

Anders als bei ESP und AH, wo im Header einer Nachricht nur der SPI des Empfängers erscheint, wird in IKE der SPI des Senders in jeder Nachricht mitgesendet. Da der vom ursprünglichen Initiator der IKE-SA gewählte SPI immer zuerst gesendet wird, muss ein Endpunkt mit mehreren offenen IKE-SAs, der die passende IKE-SA über den von ihm zugewiesenen SPI finden will, das Initiator-Flag im Header betrachten, um zu bestimmen, ob er die ersten oder die zweiten acht Oktette zugewiesen hat.

In der ersten Nachricht eines initialen IKE-Austauschs kennt der Initiator den SPI-Wert des Responders nicht und setzt daher dieses Feld auf Null. Wenn der IKE_SA_INIT-Austausch aufgrund von INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN oder COOKIE (siehe Abschnitt 2.6) nicht zur Erstellung einer IKE-SA führt, ist der SPI des Responders auch in der Antwortnachricht Null. Wenn der Responder jedoch einen von Null verschiedenen Responder-SPI sendet, sollte der Initiator die Antwort nicht nur aus diesem Grund ablehnen.

Zwei erwartete Angriffe gegen IKE sind Zustands- und CPU-Erschöpfung, bei denen das Ziel mit Sitzungsinitiierungsanfragen von gefälschten IP-Adressen geflutet wird. Diese Angriffe können weniger wirksam gemacht werden, wenn ein Responder minimale CPU verwendet und keinen Zustand für eine SA festlegt, bis er weiß, dass der Initiator Pakete an der Adresse empfangen kann, von der aus er vorgibt, sie zu senden.

Wenn ein Responder eine große Zahl halb-offener IKE-SAs erkennt, SOLLTE er auf IKE_SA_INIT-Anfragen mit einer Antwort antworten, die die COOKIE-Benachrichtigung enthält. Die mit dieser Benachrichtigung verbundenen Daten MÜSSEN eine Länge von 1 bis 64 Oktett (einschließlich) haben, und ihre Erzeugung wird weiter unten in diesem Abschnitt beschrieben. Wenn die IKE_SA_INIT-Antwort die COOKIE-Benachrichtigung enthält, MUSS der Initiator die IKE_SA_INIT-Anfrage erneut versuchen und die COOKIE-Benachrichtigung mit den empfangenen Daten als ersten Payload einschließen, während alle anderen Payloads unverändert bleiben. Der initiale Austausch verläuft dann wie folgt:

Initiator Responder

HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Die ersten beiden Nachrichten beeinflussen keinen Initiator- oder Responder-Zustand, außer das Cookie zu übermitteln. Insbesondere sind die Nachrichtensequenznummern in den ersten vier Nachrichten alle Null und die Nachrichtensequenznummern in den letzten beiden Nachrichten sind Eins. 'A' ist der vom Initiator zugewiesene SPI, während 'B' der vom Responder zugewiesene SPI ist.

Eine IKE-Implementierung kann die Erzeugung ihres Responder-Cookies so implementieren, dass beim Eintreffen der zweiten IKE_SA_INIT-Nachricht kein gespeicherter Zustand benötigt wird, um ihr gültiges Cookie zu erkennen. Die zur Cookie-Erzeugung verwendeten genauen Algorithmen und Syntax beeinflussen die Interoperabilität nicht und sind daher hier nicht festgelegt. Folgendes ist ein Beispiel, wie ein Endpunkt Cookies zur Implementierung eines begrenzten DoS-Schutzes verwenden könnte.

Ein guter Weg, dies zu tun, ist, das Responder-Cookie wie folgt zu setzen:

Cookie = | Hash(Ni | IPi | SPIi | )

wobei ein nur dem Responder bekannter, periodisch geänderter Zufalls-Schlüssel ist und | die Verkettung angibt. sollte immer dann geändert werden, wenn neu generiert wird. Das Cookie kann neu berechnet werden, wenn das IKE_SA_INIT das zweite Mal eintrifft, und mit dem Cookie in der empfangenen Nachricht verglichen werden. Stimmt es überein, weiß der Responder, dass das Cookie seit der letzten Änderung von erzeugt wurde und dass IPi mit der beim ersten Mal gesehenen Quelladresse identisch sein muss. Die Einbeziehung von SPIi in die Berechnung stellt sicher, dass, wenn mehrere IKE-SAs parallel aufgebaut werden, sie alle unterschiedliche Cookies erhalten (vorausgesetzt, der Initiator wählt eindeutige SPIi). Die Einbeziehung von Ni in den Hash stellt sicher, dass ein Angreifer, der nur Nachricht 2 sieht, keine Nachricht 3 erfolgreich fälschen kann. Ebenso verhindert die Einbeziehung von SPIi in den Hash, dass ein Angreifer ein Cookie vom anderen Ende abholt und dann viele IKE_SA_INIT-Austausche mit unterschiedlichen Initiator-SPIs (und vielleicht Portnummern) startet, sodass der Responder glaubt, viele Maschinen hinter einer NAT-Box würden sich alle verbinden wollen.

Wenn während laufender Initialisierung von Verbindungen ein neuer Wert für gewählt wird, kann ein IKE_SA_INIT mit einer anderen als der aktuellen zurückgegeben werden. Der Responder KANN in diesem Fall die Nachricht ablehnen, indem er eine weitere Antwort mit einem neuen Cookie sendet, oder er KANN den alten Wert von für kurze Zeit behalten und Cookies annehmen, die aus beiden berechnet wurden. Der Responder sollte Cookies nicht unbegrenzt annehmen, nachdem geändert wurde, da dies einen Teil des DoS-Schutzes aufheben würde. Der Responder sollte den Wert von häufig ändern, insbesondere bei einem Angriff.

Wenn eine Partei eine IKE_SA_INIT-Anfrage mit einem Cookie empfängt, dessen Inhalt nicht dem erwarteten Wert entspricht, MUSS diese Partei das Cookie ignorieren und die Nachricht so verarbeiten, als wäre kein Cookie enthalten; dies bedeutet normalerweise, eine Antwort mit einem neuen Cookie zu senden. Der Initiator sollte die Anzahl der Cookie-Austauschversuche begrenzen, bevor er aufgibt, möglicherweise mit exponentiellem Back-off. Ein Angreifer kann mehrere Cookie-Antworten auf die IKE_SA_INIT-Nachricht des Initiators fälschen, und jede dieser gefälschten Cookie-Antworten verursacht das Senden von zwei Paketen: ein Paket vom Initiator zum Responder (der diese Cookies ablehnt) und eine Antwort vom Responder zum Initiator, die das korrekte Cookie enthält.

Eine Anmerkung zur Terminologie: Der Begriff "cookies" stammt von Karn und Simpson [PHOTURIS] in Photuris, einem frühen Vorschlag für Schlüsselverwaltung mit IPsec, und hat sich erhalten. Der feste Nachrichtenheader des Internet Security Association and Key Management Protocol (ISAKMP) [ISAKMP] enthält zwei Acht-Oktett-Felder namens "cookies", und diese Syntax wird von sowohl IKEv1 als auch IKEv2 verwendet, obwohl sie in IKEv2 als "IKE SPI" bezeichnet werden und es ein neues separates Feld in einem Notify-Payload gibt, das das Cookie hält.

Es gibt zwei häufige Gründe, warum der Initiator den IKE_SA_INIT-Austausch möglicherweise wiederholen muss: Der Responder fordert ein Cookie oder möchte eine andere Diffie-Hellman-Gruppe als im KEi-Payload enthalten. Wenn der Initiator ein Cookie vom Responder erhält, muss der Initiator entscheiden, ob er das Cookie nur im nächsten Wiederholungsversuch der IKE_SA_INIT-Anfrage einschließt oder auch in allen nachfolgenden Wiederholungen.

Wenn der Initiator das Cookie nur im nächsten Wiederholungsversuch einschließt, kann in einigen Fällen ein zusätzlicher Round-Trip nötig sein. Ein zusätzlicher Round-Trip ist auch nötig, wenn der Initiator das Cookie in allen Wiederholungen einschließt, der Responder dies jedoch nicht unterstützt. Wenn beispielsweise der Responder die KEi-Payloads in die Cookie-Berechnung einbezieht, wird er die Anfrage durch Senden eines neuen Cookies ablehnen.

Wenn beide Peers das Einschließen des Cookies in allen Wiederholungen unterstützen, kann ein etwas kürzerer Austausch stattfinden.

Initiator Responder

HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> <-- HDR(A,B), SAr1, KEr, Nr

Implementierungen SOLLTEN diesen kürzeren Austausch unterstützen, MÜSSEN aber nicht fehlschlagen, wenn andere Implementierungen diesen kürzeren Austausch nicht unterstützen.