Intercambio de claves durante la fase IKE_AUTH de IKEv2

Question

Intercambio de claves durante la fase IKE_AUTH de IKEv2

#1 de ecdsa (1 votos)

1

Esto es lo que parece un apretón de manos casual IKEv2 :

  Initiator                                                       Responder
  |                                                                      |
 1|-----------------------> HDR, SAi1, KEi, Ni ------------------------->|
 2|<----------------- HDR, SAr1, KEr, Nr, [CERTREQ] <--------------------|
 3|----> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}-->| 
 4|<------------ HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} <-----------|
  |                                                                      |

Donde los mensajes (1) y (2) pertenecen a IKE_SA_INIT exchange y los mensajes (3) y (4) pertenecen a IKE_AUTH exchange. He analizado un rastro de wirehark de este intercambio y me parece que durante IKE_AUTH (SAi2, SAr2) , el iniciador / el respondedor anuncia el conjunto de algoritmos de seguridad que él / él elige respectivamente (cifrado, autenticación, protección de integridad, grupo diffie-hellman) . Sin embargo, ninguno de los dos anuncia su valor DH. Así que no hay intercambio de claves real aquí. Mi pregunta es ¿para qué sirve la negociación de asociación de seguridad (SAi2, SAr2) ? y ¿por qué incluso necesitamos un segundo intercambio de claves ya que el protocolo ya logró una durante IKE_SA_INIT (en otras palabras, por qué necesitamos negociar nuevas claves)?

diffie-hellman ipsec ike

pregunta sasuke_X220 15.07.2017 - 17:35

fuente

1 respuesta

Lea otras preguntas en las etiquetas diffie-hellman ipsec ike

Cómo defenderse contra un atacante sin afectar a otros usuarios de la misma puerta de enlace NAT ¿Las tarjetas de crédito almacenan primero cuatro y últimos cuatro que PCI SAQ?

score 1 · Accepted Answer

Las cargas útiles SAi2/SAr2 , junto con las cargas útiles TSi/TSr , se utilizan para negociar la SA infantil inicial. Según RFC 7296, sección 1.2 :

El iniciador comienza la negociación de un SA de niño usando el SAi2 carga útil. Los campos finales (comenzando con SAi2) se describen en la Descripción del intercambio CREATE_CHILD_SA.

Sin embargo, el material clave para este Child SA se deriva del material clave IKE (establecido con las cargas útiles KE durante IKE_SA_INIT ), por lo que no hay un intercambio de claves separado. Los grupos DH no se incluyen explícitamente en las cargas útiles de SA durante IKE_AUTH . De la misma sección que arriba:

Tenga en cuenta que los mensajes IKE_AUTH no contienen KEi / KEr o Ni / Nr payloads. Por lo tanto, las cargas útiles de SA en el intercambio IKE_AUTH no pueden contener Transforme el Tipo 4 (grupo Diffie-Hellman) con cualquier valor que no sea NINGUNA. Las implementaciones DEBEN omitir toda la subestructura de transformación en lugar de enviar valor NINGUNO.

Una implementación IKEv2 que admita RFC 6023 (Iniciación IKEv2 sin hijos) puede omitir estas cargas útiles SA/TS y crear un IKE SA sin niño inicial SA.

Al crear o cambiar la clave de las SA de niño más tarde con CREATE_CHILD_SA intercambios, los pares pueden opcionalmente negociar un grupo de DH e intercambiar sus factores de DH públicos utilizando KE de cargas útiles (si eso no se hace, las claves para la nueva SA de niño se derivan de nuevo el material clave de IKE SA). Esto tiene el propósito de separar el IKE de las claves de SA de niño y las claves de SA de sí de uno a otro (a esto generalmente se lo denomina secreto de reenvío perfecto o PFS).