Autenticazione IKEv2 - perché / come funziona?

Question

Autenticazione IKEv2 - perché / come funziona?

#1 da (3 voti)

4

Attualmente sto cercando di capire il protocollo IKEv2 che viene utilizzato per IPsec e mi chiedo perché / come funziona il processo di autenticazione.

Da quanto ho capito, nello scambio IKE_SA_INIT precedente, l'iniziatore e il rispondente concordano su una suite crittografica, si scambiano i loro valori DH e un nonce.

Il seguente scambio IKE_AUTH dovrebbe verificare l'identità dei pari tra loro. Il protocollo ha derivato un sacco di chiavi dal segreto condiviso SKEYSEED che è stato calcolato usando i valori DH e non.
Nello scambio IKE_AUTH viene utilizzato uno dei keypair per basarsi semplicemente su un blocco di dati - una copia del precedente scambio IKE_SA_INIT, il nonce e il prf del peer (SK, ID).

Quello che non capisco è il fatto che dal momento che i valori di DH e nonces vengono inviati non autenticati e non crittografati nello scambio IKE_SA_INIT, un hacker non può semplicemente falsificare l'identità del partner di comunicazione avversario ed eseguire un attacco MitM?

A che punto nel protocollo un tale attacco MitM, ad es. sostituisce i valori di DH, essere riconosciuto dall'altro lato?

Grazie mille in anticipo!

authentication man-in-the-middle ike

posta Peter 02.02.2015 - 17:10

fonte

1 risposta

Leggi altre domande sui tag authentication man-in-the-middle ike

Difesa software contro gli attacchi a freddo Spoof IP in un pacchetto TCP e codice PHP vulnerabile

score 3 · Answer 1

Il punto di DH è che solo le due parti possono generare un segreto condiviso (g ^xy) per lo scambio di DH. SKEYSEED non è il segreto condiviso per lo scambio DH. Infatti deriva dal DH shared secret e dai nonces; non dai parametri DH trasmessi. SKEYSEED non viene mai trasmesso sul filo.

Una volta completato lo scambio di DH e vengono generate le chiavi di crittografia / integrità, i messaggi AUTH vengono utilizzati per dimostrare l'identità di ciascun lato.

RFC 5996: sezione 1.2

The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi and integrity protects the contents of the first message using the AUTH payload (see Section 2.15). It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s). If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field.

Affinché un attacco MitM funzioni, è necessario conoscere il segreto condiviso DH. Non puoi semplicemente sostituire i parametri DH. I valori scambiati sono g ^x mod p e g ^y mod p. Devi conoscere x o y . Questi sono non facilmente calcolati perché è necessario eseguire un registro discreto su un numero (che dovrebbe essere) molto grande.

Puoi provare a impersonare un lato della negoziazione, ma non è proprio un MitM. E IKEv2 non è ciò che proteggerebbe da questo tipo di attacco. Quello sarebbe il lavoro delle regole del firewall e cosa no.