5. Security Considerations (Considerazioni sulla sicurezza)

5. Security Considerations (Considerazioni sulla sicurezza)

Sebbene questo protocollo sia progettato per ridurre al minimo la divulgazione di informazioni di configurazione ai pari non autenticati, una certa divulgazione è inevitabile. Uno dei due pari deve identificarsi per primo e provare per primo la propria identità. Per evitare il probing, l'iniziatore di uno scambio è tenuto a identificarsi per primo ed è di solito tenuto ad autenticarsi per primo. L'iniziatore può tuttavia apprendere che il risponditore supporta IKE e quali protocolli crittografici supporta. Il risponditore (o qualcuno che si spaccia per il risponditore) può non solo sondare l'iniziatore per la sua identità ma anche, usando payload CERTREQ, determinare quali certificati l'iniziatore è disposto a usare.

L'uso dell'autenticazione EAP modifica leggermente le possibilità di probing. Con l'autenticazione EAP, il risponditore prova la propria identità prima dell'iniziatore, quindi un iniziatore che conoscesse il nome di un iniziatore valido potrebbe sondare il risponditore sia per il nome sia per i certificati.

Ripetuti rinnovi di chiave con CREATE_CHILD_SA senza ulteriori scambi Diffie-Hellman espongono tutte le SA alla crittanalisi di una singola chiave. Gli implementatori devono tenere conto di questo fatto e impostare un limite agli scambi CREATE_CHILD_SA tra un'esponenziazione e l'altra. Questo documento non prescrive tale limite.

La robustezza di una chiave derivata da uno scambio Diffie-Hellman con uno dei gruppi qui definiti dipende dalla robustezza intrinseca del gruppo, dalla dimensione dell'esponente usato e dall'entropia fornita dal generatore di numeri casuali. A causa di questi fattori è difficile determinare la robustezza di una chiave per ciascun gruppo definito. Il gruppo Diffie-Hellman numero due, usato con un generatore casuale forte e un esponente di almeno 200 bit, è comune con 3DES. Il gruppo cinque offre maggiore sicurezza del gruppo due. Il gruppo uno è solo storico e non fornisce robustezza sufficiente salvo con DES, anch'esso solo storico. Le implementazioni devono tenere conto di queste stime quando definiscono le politiche e negoziano i parametri di sicurezza.

Queste limitazioni riguardano i gruppi Diffie-Hellman in sé. Non c'è nulla in IKE che vieti gruppi più forti né nulla che diluisca la robustezza ottenuta da gruppi più forti (limitata dalla robustezza degli altri algoritmi negoziati inclusa la PRF (Pseudorandom Function)). Anzi, il framework estensibile di IKE incoraggia la definizione di ulteriori gruppi; l'uso di gruppi a curve ellittiche può aumentare notevolmente la robustezza con numeri molto più piccoli.

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

Gli scambi IKE_SA_INIT e IKE_AUTH avvengono prima che l'iniziatore sia autenticato. Di conseguenza un'implementazione di questo protocollo deve essere completamente robusta quando è distribuita su qualsiasi rete non sicura. Le vulnerabilità di implementazione, in particolare gli attacchi DoS (Denial of Service), possono essere sfruttati da pari non autenticati. La questione è particolarmente preoccupante a causa del numero illimitato di messaggi nell'autenticazione basata su EAP.

La robustezza di tutte le chiavi è limitata dalla dimensione dell'uscita della PRF negoziata. Per questo motivo una PRF la cui uscita è 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 devono essere generati da una sorgente casuale forte o pseudo-casuale correttamente seminata (vedere [RANDOMNESS]). Gli implementatori devono fare attenzione affinché l'uso di numeri casuali per chiavi e nonce sia progettato in modo da non compromettere la sicurezza delle chiavi.

Per la motivazione di molte scelte di progetto crittografico in questo protocollo, vedere [SIGMA] e [SKEME]. Sebbene la sicurezza delle Child SA negoziate non dipenda dalla robustezza della crittografia e della protezione di integrità negoziate nella SA IKE, 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 critica è come garantire la casualità di questi segreti. La pratica più robusta è assicurarsi che ogni chiave pre-condivisa contenga tanta casualità quanto la chiave più forte negoziata. Derivare un segreto condiviso da password, nome o altra fonte a bassa entropia non è sicuro. Tali fonti sono soggette ad attacchi a dizionario e ingegneria sociale, tra gli altri.

Le notifiche NAT_DETECTION_*_IP contengono un hash di indirizzi e porte nel tentativo di nascondere gli indirizzi IP interni dietro un NAT. Poiché lo spazio di indirizzamento IPv4 ha solo 32 bit ed è di solito molto sparso, un attaccante potrebbe scoprire l'indirizzo interno dietro il NAT provando tutti gli indirizzi IP e cercando l'hash corrispondente. I numeri di porta sono di solito fissati a 500 e gli SPI possono essere estratti dal pacchetto. Ciò riduce il numero di calcoli di hash a 2^32. Con una stima informata dell'uso dello spazio di indirizzi privato, il numero di calcoli è molto minore. I progettisti non devono quindi presumere che l'uso di IKE non riveli informazioni sugli indirizzi interni.

Quando si usa un metodo di autenticazione EAP che non genera una chiave condivisa per proteggere un successivo payload AUTH, sono possibili certi attacchi man-in-the-middle e di impersonazione del server [EAPMITM]. Queste vulnerabilità si verificano quando EAP è usato anche in protocolli non protetti con un tunnel sicuro. Poiché EAP è un protocollo di autenticazione generico, spesso usato per il single sign-on, una soluzione IPsec distribuita che si affida a un metodo EAP che non genera una chiave condivisa (noto anche come metodo EAP non generatore di chiavi) può essere compromessa a causa della distribuzione di un'applicazione del tutto non correlata che usa lo stesso metodo EAP non generatore di chiavi ma in modo non protetto. Nota che questa vulnerabilità non si limita a EAP ma può verificarsi in altri scenari in cui un'infrastruttura di autenticazione è riutilizzata. Ad esempio, se il meccanismo EAP usato da IKEv2 utilizza un autenticatore a token, un attaccante man-in-the-middle potrebbe impersonare il server web, intercettare lo scambio di autenticazione a token e usarlo per avviare una connessione IKEv2. Per questo motivo l'uso di metodi EAP non generatori di chiavi DOVREBBE essere evitato ove possibile. Dove sono usati, è estremamente importante che tutti gli usi di questi metodi EAP DOVREBBERO utilizzare un tunnel protetto in cui l'iniziatore convalida il certificato del risponditore prima di avviare l'autenticazione EAP. Gli implementatori DOVREBBERO descrivere nella documentazione delle loro implementazioni le vulnerabilità dell'uso di metodi EAP non generatori di chiavi in modo che gli amministratori che distribuiscono soluzioni IPsec siano consapevoli di questi pericoli.

Un'implementazione che usa EAP DEVE inoltre usare un'autenticazione basata su chiave pubblica del server verso il client prima che inizi l'autenticazione EAP, anche se il metodo EAP offre autenticazione reciproca. Ciò evita ulteriori varianti del protocollo IKEv2 e protegge i dati EAP da attaccanti attivi.

Se i messaggi IKEv2 sono abbastanza lunghi da richiedere la frammentazione a livello IP, gli attaccanti potrebbero impedire il completamento dello scambio esaurendo i buffer di riassemblaggio. Le possibilità possono essere ridotte al minimo usando le codifiche Hash and URL invece di inviare certificati (vedere la Sezione 3.6). Ulteriori mitigazioni sono discusse in [DOSUDPPROT].

Il controllo di ammissione è critico per la sicurezza del protocollo. Ad esempio, le ancore di fiducia usate per identificare i pari IKE dovrebbero probabilmente essere diverse da quelle usate per altre forme di fiducia, come quelle usate per identificare server web pubblici. Inoltre, sebbene IKE lasci molta libertà nella definizione della politica di sicurezza per identità, credenziali e correlazione tra di esse per un pari attendibile, avere tale politica di sicurezza definita esplicitamente è essenziale per un'implementazione sicura.