Passa al contenuto principale

2.6. IKE SA SPIs and Cookies (SPI IKE SA e cookie)

I primi due campi di otto ottetti nell'intestazione, chiamati « IKE SPI », identificano la connessione all'inizio dei pacchetti IKE. Ogni endpoint ne sceglie uno e DEVE sceglierli come identificatori unici di una IKE SA. Il valore zero è speciale: il mittente non conosce ancora il SPI remoto.

I pacchetti IKE in ingresso sono mappati a una IKE SA solo tramite lo SPI del pacchetto, non ad esempio tramite l'indirizzo IP sorgente.

A differenza di ESP e AH, dove nell'intestazione compare solo lo SPI del destinatario, in IKE viene inviato anche lo SPI del mittente. Poiché lo SPI scelto dall'iniziatore originale della IKE SA viene sempre inviato per primo, un endpoint con più IKE SA aperte deve guardare il flag Initiator per sapere se ha assegnato i primi o i secondi otto ottetti.

Nel primo messaggio di uno scambio iniziale l'iniziatore non conosce lo SPI del risponditore e mette il campo a zero. Se lo scambio IKE_SA_INIT non crea una IKE SA a causa di INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN o COOKIE, lo SPI del risponditore può essere zero anche nella risposta. Se il risponditore invia uno SPI risponditore non nullo, l'iniziatore non dovrebbe rifiutare la risposta solo per questo.

Due attacchi attesi sono esaurimento di stato e CPU mediante richieste di apertura sessione da IP falsi. Un risponditore che usa poca CPU e non impegna stato nella SA finché non sa che l'iniziatore riceve all'indirizzo dichiarato riduce l'efficacia dell'attacco.

Quando un risponditore rileva molte IKE SA semi-aperte, DOVREBBE rispondere alle IKE_SA_INIT con una risposta contenente la notifica COOKIE. I dati associati DEVONO essere tra 1 e 64 ottetti inclusi; la generazione è descritta più sotto. Se la risposta IKE_SA_INIT include COOKIE, l'iniziatore DEVE ritentare IKE_SA_INIT includendo la notifica COOKIE con i dati ricevuti come primo payload, gli altri invariati. Lo scambio iniziale è allora:

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}

I primi due messaggi non alterano lo stato salvo per il cookie. I numeri di sequenza dei primi quattro messaggi sono zero, degli ultimi due sono uno. « A » è lo SPI dell'iniziatore, « B » del risponditore.

Un'implementazione IKE può generare il cookie del risponditore senza stato salvato per riconoscere un cookie valido al secondo IKE_SA_INIT. Gli algoritmi esatti non sono normativi. Esempio di protezione DoS limitata:

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

dove <secret> è un segreto casuale noto solo al risponditore, cambiato periodicamente, e | è concatenazione. <VersionIDofSecret> cambia quando si rigenera <secret>. Al secondo IKE_SA_INIT il cookie può essere ricalcolato e confrontato. Se coincide, il cookie è stato generato dall'ultimo cambio di <secret> e IPi deve essere la sorgente vista la prima volta. SPIi distingue aperture parallele. Ni impedisce di falsificare il messaggio 3 vedendo solo il 2. SPIi impedisce di prendere un cookie e avviare molte IKE_SA_INIT con SPI iniziatori diversi simulando molte macchine dietro un NAT.

Se <secret> cambia durante inizializzazioni in corso, un IKE_SA_INIT può portare un <VersionIDofSecret> non corrente. Il risponditore PUÒ rifiutare con nuovo cookie o PUÒ tenere brevemente il vecchio <secret> e accettare entrambi. Non dovrebbe accettare indefinitamente dopo il cambio. <secret> dovrebbe cambiare spesso, soprattutto sotto attacco.

Se il cookie non corrisponde, la parte DEVE ignorarlo e trattare come senza cookie (di solito risposta con nuovo cookie). L'iniziatore dovrebbe limitare i tentativi di scambio cookie (backoff esponenziale). Un attaccante può causare due pacchetti per ogni cookie falso.

Terminologia: « cookies » da Photuris [PHOTURIS]. ISAKMP [ISAKMP] ha due campi di otto ottetti così chiamati; IKEv2 li chiama « IKE SPI » e tiene il cookie in un campo separato nella Notify.

L'iniziatore ritenta IKE_SA_INIT perché il risponditore chiede un cookie o vuole un gruppo Diffie-Hellman diverso da KEi. Ricevuto un cookie, deve decidere se includerlo solo nel prossimo tentativo o in tutti i successivi.

Un round trip in più può servire nel primo caso, o se tutti i tentativi portano il cookie ma il risponditore non lo supporta (es. KEi nel calcolo del cookie → nuovo cookie).

Se entrambi i peer supportano il cookie in tutti i tentativi, lo scambio può essere più breve:

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

Le implementazioni DOVREBBERO supportare questo scambio più breve, ma NON DEVONO fallire se altre non lo supportano.

Ultimo aggiornamento il