Zum Hauptinhalt springen

2.6. IKE SA SPIs and Cookies (IKE-SA-SPIs und Cookies)

2.6. IKE SA SPIs and Cookies (IKE-SA-SPIs und Cookies)​

Die ersten zwei acht Oktett großen Felder im Header heißen „IKE-SPIs“ und dienen am Anfang von IKE-Paketen als Verbindungskennung. Jede Endstelle wählt einen der beiden SPIs und MUSS sie so wählen, dass sie eine IKE-SA eindeutig identifizieren. Der Wert null ist besonders: Der Sender kennt den entfernten SPI noch nicht.

Eingehende IKE-Pakete werden nur über den SPI des Pakets einer IKE-SA zugeordnet, nicht z. B. über die Quell-IP.

Anders als bei ESP und AH, wo nur der SPI des Empfängers im Header steht, sendet IKE auch den SPI des Senders. Da der SPI des ursprünglichen IKE-Initiators immer zuerst gesendet wird, muss eine Endstelle mit mehreren IKE-SAs das Initiator-Flag prüfen, ob sie die ersten oder die zweiten acht Oktette vergeben hat.

In der ersten Nachricht eines initialen Austauschs kennt der Initiator den Responder-SPI nicht und setzt das Feld daher auf null. Wenn IKE_SA_INIT wegen INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN oder COOKIE keine IKE-SA erzeugt, kann der Responder-SPI in der Antwort ebenfalls null sein. Sendet der Responder jedoch einen nicht-null Responder-SPI, sollte der Initiator die Antwort nicht allein deswegen ablehnen.

Erwartete Angriffe sind Zustands- und CPU-Erschöpfung durch geflutete Sitzungsaufbauanfragen mit gefälschten IPs. Ein Responder mit minimalem CPU-Einsatz und ohne Zustand in einer SA, bis klar ist, dass der Initiator an der angegebenen Adresse empfangen kann, schwächt solche Angriffe.

Erkennt ein Responder viele halboffene IKE-SAs, SOLLTE er auf IKE_SA_INIT mit einer Antwort mit COOKIE-Benachrichtigung antworten. Die zugehörigen Daten MÜSSEN zwischen 1 und 64 Oktette (einschließlich) lang sein; die Erzeugung wird weiter unten beschrieben. Enthält die IKE_SA_INIT-Antwort COOKIE, MUSS der Initiator IKE_SA_INIT wiederholen, die COOKIE-Benachrichtigung mit den empfangenen Daten als erste Payload und alle anderen Payloads unverändert. Der initiale Austausch verläuft dann:

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 ändern außer der Cookie-Übermittlung keinen Zustand. Die Sequenznummern der ersten vier Nachrichten sind null, der letzten beiden eins. „A“ ist der SPI des Initiators, „B“ der des Responders.

Eine IKE-Implementierung kann die Cookie-Erzeugung so gestalten, dass beim zweiten IKE_SA_INIT kein gespeicherter Zustand nötig ist. Exakte Algorithmen sind nicht normativ. Beispiel für begrenzten DoS-Schutz:

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

wobei <secret> ein nur dem Responder bekannter, periodisch gewechselter Geheimwert ist und | Konkatenation bedeutet. <VersionIDofSecret> ändert sich bei Regenerierung von <secret>. Beim zweiten IKE_SA_INIT kann das Cookie neu berechnet und verglichen werden. Bei Übereinstimmung stammt das Cookie seit der letzten <secret>-Änderung und IPi muss der beim ersten Mal gesehenen Quelle entsprechen. SPIi sorgt bei parallelen Aufbauten für verschiedene Cookies. Ni verhindert Fälschung von Nachricht 3 bei Kenntnis nur von Nachricht 2. SPIi verhindert, dass ein Angreifer ein Cookie holt und viele IKE_SA_INIT mit verschiedenen Initiator-SPIs startet, um viele Hosts hinter einem NAT vorzutäuschen.

Wird <secret> während laufender Initialisierungen neu gewählt, kann IKE_SA_INIT einen anderen <VersionIDofSecret> tragen. Der Responder KANN mit neuem Cookie ablehnen oder KURZ den alten <secret> behalten und beide Cookies akzeptieren. Unbegrenzte Akzeptanz nach Wechsel wäre schädlich. <secret> sollte oft wechseln, besonders unter Angriff.

Stimmt ein empfangenes Cookie nicht, MUSS die Partei es ignorieren und wie ohne Cookie verarbeiten (üblicherweise Antwort mit neuem Cookie). Der Initiator sollte Cookie-Runden begrenzen (exponentielles Backoff). Ein Angreifer kann pro gefälschter Cookie-Antwort zwei Pakete auslösen.

Begriff „Cookies“ stammt aus Photuris [PHOTURIS]. ISAKMP [ISAKMP] nennt zwei acht-Oktett-Felder so; IKEv2 spricht von „IKE-SPI“ und hält das Cookie in einer separaten Notify-Payload.

Der Initiator wiederholt IKE_SA_INIT, weil der Responder ein Cookie will oder eine andere Diffie-Hellman-Gruppe als in KEi. Erhält er ein Cookie, muss er entscheiden, ob nur beim nächsten oder bei allen weiteren Versuchen es mitschickt.

Ein zusätzlicher Roundtrip kann nötig sein, oder wenn der Responder Cookies in allen Wiederholungen nicht unterstützt (z. B. KEi in Cookie-Berechnung → neues Cookie).

Unterstützen beide das Cookie in allen Wiederholungen, kann der Austausch kürzer sein:

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, DÜRFEN aber nicht scheitern, wenn andere es nicht tun.

Letztes Update am