5. Considerazioni sulla sicurezza

Sebbene questo protocollo sia progettato per minimizzare la divulgazione di informazioni di configurazione a una controparte non autenticata, una parte di tale divulgazione è inevitabile. Una o l'altra parte deve prima identificarsi e per prima dimostrare la propria identità. Per evitare il probing, all'iniziatore dello scambio è richiesto di identificarsi per primo e in genere di autenticarsi per primo. Tuttavia, l'iniziatore può apprendere che il risponditore supporta IKE e quali protocolli crittografici supporta. Il risponditore (o chi finge di essere il risponditore) può, tramite il payload CERTREQ, non solo sondare l'identità dell'iniziatore, ma anche determinare quali certificati l'iniziatore è disposto a utilizzare.

L'uso dell'autenticazione EAP modifica leggermente le possibilità di probing. Quando viene utilizzata l'autenticazione EAP, il risponditore dimostra la propria identità prima dell'iniziatore, quindi un iniziatore che conosca un nome di iniziatore valido può sondare sia il nome sia il certificato del risponditore.

Il rekeying ripetuto usando CREATE_CHILD_SA senza ulteriore scambio Diffie-Hellman rende tutte le SA vulnerabili ad attacchi di crittoanalisi contro una singola chiave. Gli implementatori dovrebbero essere consapevoli di questo fatto e porre un limite al numero di scambi CREATE_CHILD_SA tra le esponenziazioni. Questo documento non prescrive tale limite.

La forza delle chiavi derivate da uno scambio Diffie-Hellman da uno qualsiasi dei gruppi qui definiti dipende dalla forza intrinseca del gruppo stesso, dalla dimensione degli esponenti utilizzati e dall'entropia fornita dal generatore di numeri casuali impiegato. A causa di questi input, è difficile determinare la forza delle chiavi per qualsiasi gruppo definito. Quando usato con un generatore di numeri casuali forte e con un esponente non inferiore a 200 bit, il gruppo Diffie-Hellman 2 è comunemente usato con 3DES. Il gruppo 5 offre maggiore sicurezza del gruppo 2. Il gruppo 1 serve solo a scopi storici e non fornisce forza sufficiente, se non in combinazione con DES, che è anch'esso destinato solo a scopi storici. Gli implementatori dovrebbero prestare attenzione a queste stime quando stabiliscono politiche e negoziano parametri di sicurezza.

Si noti che queste limitazioni riguardano il gruppo Diffie-Hellman stesso. Nulla in IKE vieta l'uso di un gruppo più forte né indebolisce la forza ottenuta da un gruppo più forte (fatti salvi i limiti della forza degli altri algoritmi negoziati, inclusa la PRF). Infatti, il framework estensibile di IKE incoraggia la definizione di gruppi aggiuntivi; l'uso di gruppi a curva ellittica può migliorare notevolmente la forza con numeri molto più piccoli.

Si presume che tutti gli esponenti Diffie-Hellman vengano cancellati dalla memoria dopo l'uso.

Gli scambi IKE_SA_INIT e IKE_AUTH avvengono prima che l'iniziatore sia autenticato. Di conseguenza, le implementazioni di questo protocollo distribuite su qualsiasi rete non sicura devono essere del tutto robuste. Le vulnerabilità implementative, in particolare gli attacchi DoS, potrebbero essere sfruttate da una controparte non autenticata. Poiché il numero di messaggi nell'autenticazione basata su EAP non è limitato, questo problema è particolarmente preoccupante.

La forza di tutte le chiavi è limitata dalla dimensione di output della PRF negoziata. Pertanto, una PRF con output inferiore a 128 bit (ad esempio 3DES-CBC) NON DEVE essere usata con questo protocollo.

La sicurezza di questo protocollo dipende in modo critico dalla casualità dei parametri scelti casualmente. Questi parametri dovrebbero essere generati da una sorgente casuale forte o pseudo-casuale correttamente inizializzata (vedere [RANDOMNESS]). Gli implementatori dovrebbero assicurarsi che i numeri casuali usati sia per le chiavi sia per i nonce non compromettano la sicurezza delle chiavi.

Per la giustificazione di molte scelte di progettazione crittografica di questo protocollo, vedere [SIGMA] e [SKEME]. Sebbene la sicurezza di una Child SA negoziata non dipenda dalla forza della crittografia e della protezione di integrità negoziate nella IKE SA, le implementazioni NON DEVONO negoziare NONE come algoritmo di protezione di integrità IKE, né ENCR_NULL come algoritmo di crittografia IKE.

Quando si usano chiavi pre-condivise, una considerazione chiave è garantire la casualità di questi segreti. L'approccio più forte consiste nell'assicurarsi che qualsiasi chiave pre-condivisa contenga tanta casualità quanta la chiave più forte negoziata. Derivare un segreto condiviso da password, nomi o altre fonti a bassa entropia non è sicuro. Queste fonti sono vulnerabili ad attacchi a dizionario e ingegneria sociale, tra gli altri.

Le notifiche NAT_DETECTION_*_IP contengono un hash dell'indirizzo e della porta, cercando di nascondere l'indirizzo IP interno dietro il NAT. Dato che lo spazio di indirizzi IPv4 ha solo 32 bit ed è generalmente molto sparso, un attaccante potrebbe scoprire l'indirizzo interno usato dietro la box NAT provando tutti i possibili indirizzi IP e cercando un hash corrispondente. Il numero di porta è solitamente fissato a 500, e lo SPI può essere estratto dal pacchetto. Ciò riduce il numero di calcoli di hash a 2^32. Indovinando accuratamente l'uso dello spazio di indirizzi privati, il numero di calcoli di hash è molto più piccolo. Pertanto, i progettisti non dovrebbero presumere che l'uso di IKE non divulghi informazioni sugli indirizzi interni.

Quando si usano metodi di autenticazione EAP che non generano una chiave condivisa per proteggere i successivi payload AUTH, possono verificarsi alcuni attacchi man-in-the-middle e di spoofing del server [EAPMITM]. Queste vulnerabilità emergono quando EAP è usato anche per protocolli non protetti da un tunnel sicuro. Poiché EAP è un protocollo di autenticazione generico, spesso usato per fornire funzionalità di single sign-on, le soluzioni IPsec distribuite che fanno affidamento su metodi di autenticazione EAP non generanti chiave (anche detti metodi EAP non key-generating) potrebbero essere compromesse dalla distribuzione di un'applicazione del tutto non correlata che usa per caso lo stesso metodo EAP non key-generating ma operante in modo insufficientemente protetto. Si noti che questa vulnerabilità non è limitata a EAP e può verificarsi anche in altri scenari in cui l'infrastruttura di autenticazione è riutilizzata. Ad esempio, se il meccanismo EAP usato da IKEv2 sfrutta un autenticatore a token, un attaccante man-in-the-middle potrebbe impersonare un server Web, intercettare lo scambio di autenticazione a token e usarlo per avviare una connessione IKEv2. Pertanto, l'uso di metodi EAP non key-generating dovrebbe essere evitato nella misura del possibile. Quando questi sono usati, è estremamente importante che tutti questi usi di metodi EAP sfruttino un tunnel protetto in cui l'iniziatore verifica il certificato del risponditore prima di avviare l'autenticazione EAP. Gli implementatori dovrebbero descrivere nella documentazione della loro implementazione le vulnerabilità dell'uso di metodi EAP non key-generating, affinché gli amministratori che distribuiscono soluzioni IPsec ne siano consapevoli.

Le implementazioni che usano EAP DEVONO usare anche un'autenticazione basata su chiave pubblica server-client prima dell'inizio dell'autenticazione EAP, anche se il metodo EAP fornisce autenticazione mutua. Ciò evita varianti aggiuntive del protocollo IKEv2 e protegge i dati EAP da attaccanti attivi.

Se un messaggio IKEv2 è così lungo da richiedere la frammentazione a livello IP, un attaccante potrebbe impedire il completamento dello scambio esaurendo il buffer di riassemblaggio. Usando la codifica Hash and URL invece di inviare certificati (vedere sezione 3.6) è possibile minimizzare questa possibilità. Altri mitiganti sono discussi in [DOSUDPPROT].

Il controllo di ammissione è cruciale per la sicurezza del protocollo. Ad esempio, l'ancora di fiducia usata per identificare la controparte IKE dovrebbe probabilmente essere diversa da quella usata per altre forme di fiducia (come l'identificazione di server Web pubblici). Inoltre, sebbene IKE offra grande libertà nel definire politiche di sicurezza per l'identità, le credenziali e la loro associazione tra controparti fidate, la definizione esplicita di tali politiche di sicurezza è essenziale per un'implementazione sicura.