Durante IKE_SA_INIT usted negocia algoritmos criptográficos que asumo (corríjame si me equivoco) son muy similares a un conjunto de cifrado TLS (algoritmo criptográfico simétrico y una función hash). También hace un intercambio Diffie-Hellman que supongo que no está especificado en el SAi1 / SAr1 porque siempre hace DH en IKEv2.
Sí, son similares. Pero no hay conjuntos de cifrado fijos en IKE (es decir, se pueden combinar libremente algoritmos de diferentes tipos de transformación en una propuesta, con algunas excepciones, como no negociar algoritmos de integridad cuando se proponen cifrados de modo AEAD).
El grupo DH también se negocia con cargas útiles SA (tipo de transformación 4), aunque el iniciador ya envíe una carga útil KE con su valor DH público para un grupo específico. Entonces, si el iniciador propone más de un grupo DH, tiene que asumir qué grupo seleccionará el respondedor (el respondedor podría, por supuesto, usar la carga útil de KE como una sugerencia fuerte hacia el grupo que debería seleccionarse, pero podría preferir su propia configuración) o ni siquiera apoyar el grupo propuesto). Si la suposición del iniciador fue incorrecta y el respondedor selecciona un grupo DH diferente, responderá con una notificación INVALID_KE_PAYLOAD que contiene el grupo seleccionado. Luego, el iniciador debe enviar otra solicitud IKE_SA_INIT con una carga útil KE debidamente actualizada (y posiblemente una carga útil SA actualizada).
Lo que no entiendo por qué querría negociar conjuntos de cifrado nuevamente. RFC 7293 me dice que
Todos los mensajes después del intercambio inicial están protegidos criptográficamente mediante los algoritmos criptográficos y las claves negociadas en el intercambio IKE_SA_INIT.
¿cuál es el punto de las ofertas de SA en la solicitud CREATE_CHILD_SA?
Esa cita se refiere al tráfico IKE, que se cifra después de que se haya establecido el material clave con el intercambio DH durante IKE_SA_INIT . Pero para transportar el tráfico a través de IPsec es necesario negociar las SA reales de IPsec / Child dentro de la IKE SA. Los algoritmos utilizados para IKE y las SA de niño pueden ser diferentes; en realidad, cada SA de niño negociada podría en teoría utilizar diferentes algoritmos (que generalmente no es el caso, pero usar algoritmos diferentes para IKE y las SA de niño es definitivamente común, por ejemplo, AES-GCM para IPsec y AES / SHA-2 para IKE). Es por eso que los algoritmos se negocian en CREATE_CHILD_SA intercambios.
El intercambio CREATE_CHILD_SA también se usa para cambiar las claves de las IKE y las SA infantiles, y si bien se podrían negociar diferentes algoritmos, entonces (básicamente se crea una nueva SA para reemplazar la existente) RFC 7296, sección 2.8 desalienta esto:
Tenga en cuenta que, al cambiar de clave, el nuevo
Child SA NO DEBE tener diferentes selectores de tráfico y algoritmos
que el anterior.
También tenga en cuenta que, a menos que se implemente RFC 6023 , ya se creó una primera SA de Child con el IKE_AUTH intercambiar. Los algoritmos utilizados para esta SA se negocian con las cargas útiles de SA durante IKE_AUTH (SAi2 / SAr2 en RFC 7296 ). Sin embargo, debido a que no hay un intercambio de DH por separado (las claves para esta SA siempre se derivan del material de la clave IKE), no se negociarán grupos DH, RFC 7296, sección 1.2 :
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.
Si luego se cambia la clave de Child SA, se puede negociar opcionalmente un grupo DH para establecer un nuevo material clave que sea independiente del material de la clave IKE. Debido a que no se incluyeron transformaciones de DH en las cargas útiles de SA iniciales utilizadas para este SA de niño, los errores de configuración con respecto a los grupos de DH para este SA de niño solo pueden detectarse cuando se vuelve a introducir la clave y falla.