Next: 5 Elaborazione dei pacchetti Up: 1 Descrizione Previous: 3 ESP (Encapsulating Security Indice Indice analitico
Come si è visto, nell'architettura di IPsec è centrale il concetto di security association, ma né AH né ESP si preoccupano della gestione delle SA. Le security association possono essere costruite manualmente o automaticamente; è chiaro però che una loro gestione manuale non è in genere praticabile se non in contesti molto limitati, per cui è necessario un meccanismo automatico: il protocollo IKE (Internet Key Exchange) risolve questo problema.
Il protocollo ISAKMP (Internet Security Association and Key Management Protocol, specificato in [5]) definisce le procedure e il formato dei pacchetti per la gestione (creazione, modifica, cancellazione) delle security association e per lo scambio e l'autenticazione delle chiavi, indipendentemente dalla tecnica di generazione delle chiavi stesse, dagli algoritmi di cifratura e dai meccanismi di autenticazione. Il significato preciso dei pacchetti ISAKMP dipende dal contesto (dominio interpretativo) utilizzato: nel nostro caso si tratta del dominio IPsec, definito in [6]. IKE è un protocollo ibrido, che integra ISAKMP con parte dei protocolli Oakley12e SKEME, ed è specificato in [8].
IKE ha due fasi: nella prima i due nodi creano una security association per IKE stesso (detta ISAKMP SA13), ovvero un canale sicuro da utilizzare per i messaggi di IKE, nella seconda fase utilizzano la ISAKMP SA per negoziare security association per altri protocolli. Nella prima fase si può usare il main mode oppure l'aggressive mode, mentre nella seconda fase si utilizza il quick mode.
La sequenza di messaggi del main mode è illustrata in figura 2.5. I primi due messaggi servono a negoziare i parametri della ISAKMP SA, nei due successivi avviene lo scambio dei valori per il protocollo Diffie-Hellman14 (insieme con alcuni dati ausiliari), infine gli ultimi due servono ad autenticare lo scambio Diffie-Hellman. Il metodo di autenticazione negoziato nella prima parte influenza la composizione dei messaggi successivi, ma non il loro scopo; sono infatti possibili quattro forme di autenticazione: mediante firma digitale (lo scambio in figura 2.5 si riferisce a tale modalità), mediante cifratura a chiave pubblica15 (con due diverse modalità) e mediante chiave segreta condivisa. Si faccia attenzione a non confondere l'autenticazione dell'identità dell'interlocutore, che è quella di cui si preoccupa IKE e alla quale ci si riferisce ora, con l'autenticazione della provenienza dei dati, che è quella garantita dal servizio di autenticazione di AH ed ESP: la prima, tramite l'uso di un certificato, di un segreto condiviso o della crittografia a chiave pubblica, è volta a garantire che l'interlocutore è chi effettivamente sostiene di essere, mentre la seconda è volta a garantire che i dati ricevuti provengono effettivamente dall'interlocutore identificato dalla prima.
Ecco i messaggi nel dettaglio: nel primo l'iniziatore16 oltre all'header (HDR) manda un insieme di proposte per la security association da negoziare (SA), il ricevitore replica indicando nel proprio messaggio la proposta che ha scelto. Nel terzo e quarto messaggio avviene lo scambio Diffie-Hellman, tramite il payload KE (che contiene i dati pubblici scambiati per effettuare il DH), e il payload Nx (che contiene il ``nonce'', ovvero un numero casuale ausiliario utilizzato per la generazione della chiave e per l'autenticazione). Infine nel terzo e quarto messaggio (che sono cifrati con la chiave appena negoziata) i due interlocutori procedono all'autenticazione: si identificano con il payload IDxx (che contiene un identificativo come l'indirizzo IP, o il nome dell'host o altro -- si veda [6] per i dettagli) fornendo eventualmente anche un certificato (payload CERT, opzionale) e inserendo una firma (payload SIG_x) calcolata su un hash.
L'aggressive mode, la cui sequenza di messaggi è illustrata in figura 2.6 (sempre nel caso dell'autenticazione con firma digitale), ottiene lo stesso risultato del main mode ma con un numero inferiore di messaggi (tre anziché sei), al prezzo però di non proteggere le identità degli interlocutori: dato che i payload IDxx sono scambiati prima che sia terminato lo scambio Diffie-Hellman, questi viaggiano in chiaro e non cifrati come nel caso del main mode17.
Dopo aver terminato la fase 1, con il main mode o con l'aggressive mode, i due interlocutori hanno creato una ISAKMP SA, e quindi possono procedere alla fase 2 e creare security association per altri protocolli (non ISAKMP). Questa negoziazione avviene mediante il quick mode, ed è illustrata in figura 2.7. Al contrario di quanto avviene nella fase 1, qui tutti i messaggi sono cifrati perché sono protetti dalla ISAKMP SA. Nel primo messaggio l'iniziatore fa un insieme di proposte per i parametri della SA da negoziare (payload SA), inserisce un valore casuale (payload Ni) che sarà utilizzato per calcolare la chiave, e un hash (payload HASH) per autenticare il messaggio; opzionalmente è possibile includere due payload di tipo ID che contengono gli identificativi delle due parti che stanno negoziando la SA18. In questo modo il Diffie-Hellman viene effettuato con gli stessi valori scambiati nella fase 1, per cui non si ha la proprietà della perfect forward secrecy19: se si vuole la PFS è necessario effettuare un nuovo scambio DH includendo il payload KE. Nel secondo messaggio il ricevitore sceglie tra le proposte presentate (payload SA), comunica il proprio ``nonce'' (payload Nr), eventualmente inserisce i payload degli identificativi e il payload KE (quest'ultimo nel caso si voglia la PFS), e autentica il messaggio tramite il payload HASH. Lo scambio si conclude con un terzo messaggio di conferma, contenente un HASH calcolato, tra le altre cose, su entrambi i ``nonce''.
Una singola negoziazione ha come risultato in realtà due security association: una dall'iniziatore al ricevitore e una in senso inverso20; è inoltre possibile fare più di una negoziazione con un solo scambio quick mode.
