Autenticación IKEv2: ¿por qué / cómo funciona?

Question

Autenticación IKEv2: ¿por qué / cómo funciona?

#1 de RoraΖ (3 votos)

4

Actualmente estoy intentando entender el protocolo IKEv2 que se usa para IPsec y me pregunto por qué / cómo funciona el proceso de autenticación.

Según mi entendimiento, en el intercambio IKE_SA_INIT anterior, el Iniciador y el Respondedor acuerdan un conjunto criptográfico, se envían mutuamente sus valores de DH y un nonce.

Se supone que el siguiente intercambio IKE_AUTH verifica la identidad de los compañeros entre sí. El protocolo derivó muchas claves del secreto compartido SKEYSEED que se calcularon utilizando los valores y valores de DH.
En el intercambio IKE_AUTH, uno de los par de llaves se utiliza básicamente para firmar simplemente un bloque de datos: una copia del intercambio IKE_SA_INIT anterior, nonce y prf (SK, ID) del par.

Lo que no entiendo es el hecho de que, dado que los valores y puntos de acceso de DH se envían sin autenticar y sin encriptar en el intercambio IKE_SA_INIT, ¿no podría un atacante simplemente falsificar la identidad del compañero de comunicación contrario y realizar un ataque MitM?

En qué punto del protocolo se produciría un ataque MitM de este tipo, por ejemplo, reemplaza los valores de DH, ser reconocido por el otro lado?

¡Muchas gracias de antemano!

authentication man-in-the-middle ike

pregunta Peter 02.02.2015 - 17:10

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication man-in-the-middle ike

¿Qué detiene un servidor SSH de los inicios de sesión de MITMing? Spoof IP en un paquete TCP y un código PHP vulnerable

score 3 · Answer 1

El punto de DH es que solo las dos partes pueden generar un secreto compartido (g ^xy) para el intercambio de DH. SKEYSEED no es el secreto compartido para el intercambio DH. De hecho, se deriva del DH secreto compartido y los nonces; no de los parámetros DH transmitidos. SKEYSEED nunca se transmite a través del cable.

Una vez que se completa el intercambio de DH, y se generan las claves de cifrado / integridad, los mensajes AUTH se utilizan para probar la identidad de cada lado.

RFC 5996: Sección 1.2

El iniciador afirma su identidad con la carga útil IDi, demuestra el conocimiento del secreto correspondiente a IDi y la integridad protege el contenido del primer mensaje mediante la carga útil AUTH (consulte Sección 2.15 ). También puede enviar su (s) certificado (s) en carga (s) CERT y una lista de sus anclajes de confianza en carga (s) CERTREQ. Si se incluye alguna carga útil CERT, el primer certificado proporcionado DEBE contener la clave pública utilizada para verificar el campo AUTH.

Para que un ataque MitM funcione, deberías conocer el secreto compartido de DH. No puedes simplemente reemplazar los parámetros DH. Los valores intercambiados son g ^x mod p y g ^y mod p. Necesitas saber x o y . Estos no se calculan fácilmente porque necesita realizar un registro discreto en un número muy grande (lo que debería ser).

Puedes intentar personificar un lado de la negociación, pero eso no es realmente un MitM. Y IKEv2 no es lo que protegería contra este tipo de ataque. Ese sería el trabajo de las reglas de firewall y qué no.