Resumen

  • FRID es un NAI seudónimo creado por el servidor para localizar un contexto EAP-IKEv2 previo. Que una tabla devuelva ese contexto no demuestra posesión de sus claves.
  • La reconexión exige mensajes 3 y 4 protegidos por el contexto anterior, SPI nuevos, nonces frescos y derivación de MSK/EMSK nuevos. EAP-Success tampoco demuestra autorización AAA, instalación o tráfico.

Una red doméstica tiene tres servidores EAP. El primero emitió el seudónimo; el balanceador entrega el regreso al tercero. El realm es correcto, pero la base local no conoce el nombre de usuario ofuscado. ¿Ha fallado la identidad, la autenticación o solamente la distribución de estado?

RFC 5106 no permite responder con una sola etiqueta. El método EAP-IKEv2 define un modo de reconexión rápida para pares que ya completaron una autenticación mutua. Es obligatorio implementarlo, opcional utilizarlo y siempre queda sujeto a política local.

El contexto nace en un intercambio completo. El servidor actúa como iniciador IKEv2 y el par como respondedor. Ambos negocian algoritmos, nonces y material Diffie-Hellman; después verifican identidades y valores AUTH dentro de payloads protegidos. Solo al final aparecen EAP-Success, MSK y EMSK.

Durante un intercambio completo exitoso, el servidor puede incluir Next Fast-ID. Ese payload contiene un Fast-Reconnect-ID en formato NAI. El nombre de usuario es un seudónimo y el realm queda expuesto para que AAA pueda enrutar la petición. El servidor conserva la relación con la identidad permanente y el contexto criptográfico.

El FRID no es un certificado ni una contraseña portátil. Es un selector. Su componente aleatorio debería ser fresco y único dentro de los servidores que pueden atender a los abonados del operador. Presentarlo permite pedir una ruta rápida; no obliga al servidor a aceptarla.

El documento reconoce que la próxima solicitud puede llegar a otro servidor. Recomienda un mecanismo central que permita resolver seudónimos entre servidores domésticos. Si no existe, el receptor puede pedir la identidad permanente. Esta salida no significa que el par sea falso: significa que el plano de selección no tiene el estado requerido.

Por eso conviene registrar realm_routed, frid_presented, context_mapped y policy_selected por separado. Un realm correcto solo elige un dominio administrativo. Una búsqueda positiva solo elige una fila candidata. La política puede ordenar un intercambio completo incluso cuando ambos datos son correctos.

El par puede usar FRID únicamente si lo recibió en el NFID del último intercambio exitoso. Debe enviarlo mediante EAP-Response/Identity. Si el servidor responde con el mensaje 3 del flujo completo, el par tiene que aceptarlo. La optimización no crea un derecho a evitar la autenticación completa.

Cuando se elige fast reconnect, la prueba continúa con los mensajes 3 y 4. Sus payloads cifrados e íntegros usan las claves del contexto exitoso anterior. El servidor genera un nuevo SPI no nulo para la propuesta y Ni fresco; opcionalmente genera un valor Diffie-Hellman fresco. El par verifica el mensaje, crea su SPI y Nr, y protege la respuesta.

El servidor verifica el mensaje 4. Solo una respuesta correcta completa la ejecución y permite EAP-Success. Un atacante que conoce o adivina el FRID todavía carece de las claves antiguas. Una base puede devolver una fila obsoleta y, aun así, la verificación detectará que las partes no comparten el mismo estado.

La reconexión produce material nuevo. SKEYSEED incorpora SK_d anterior, Ni, Nr y, cuando existe, un nuevo secreto Diffie-Hellman. Se regeneran claves de cifrado e integridad. KEYMAT aporta 64 octetos para MSK y 64 para EMSK. Está prohibido generarlos si el flujo no termina con éxito.

El Session-ID también es nuevo porque incluye Ni y Nr actuales. Peer-ID y Server-ID proceden del intercambio completo original. FRID, identidades de principal y Session-ID no son alias. Uno selecciona contexto, otros describen a las partes autenticadas y el tercero identifica la ejecución fresca.

La rotación de FRID requiere memoria de confirmación. El par podría no guardar el nuevo valor enviado en NFID. El servidor debería mantener el último usado y el último emitido. Si la autenticación fracasa, no puede sobrescribir el FRID asociado con la última autenticación exitosa. De lo contrario, una respuesta perdida rompe la próxima reconexión.

El rechazo de replay depende de la época de claves. Tras una reconexión exitosa, repetir un mensaje 3 capturado debería fallar porque las claves han cambiado. Para demostrarlo hay que guardar generación de contexto y transición, no solo el seudónimo. El mismo FRID puede aparecer en una retransmisión legítima y en un intento posterior inválido.

La privacidad también tiene límite. Se oculta el nombre de usuario, no el realm. Los registros operativos no deberían publicar el FRID en claro; un digest estable por período permite correlacionar intentos sin convertir el seudónimo en un nuevo identificador de seguimiento indefinido.

EAP-Success cierra la método, no toda la red. RFC 5247 ubica MSK y EMSK dentro de una arquitectura con más actores. La política AAA debe autorizar el servicio, el autenticador debe recibir e instalar material, el plano inferior debe abrirse y el tráfico debe demostrar funcionamiento.

RFC 5106 indica además que no soporta channel binding. El éxito del método no certifica por sí mismo la identidad o características del acceso subyacente. Esa ausencia impide utilizar una luz EAP como prueba total de que el abonado llegó al servicio esperado mediante el punto esperado.

El perfil criptográfico de 2008 tampoco decide la política actual. MODP de 1024 bits, 3DES y transformaciones basadas en SHA-1 pertenecen al mínimo de interoperabilidad histórico. Aceptarlos hoy requiere una evaluación aparte. Conformidad al RFC y seguridad de despliegue no son el mismo recibo.

La observabilidad debería conservar: digest y realm de FRID, servidor emisor y receptor, generación de contexto, resultado de resolución, elección fast/full, SPI propuestos, digests de Ni/Nr, grupo DH, verificación de cada mensaje, Session-ID, resultado EAP y handles de claves. AAA, instalación, primer tráfico y prueba de servicio llegan después.

Con esos eventos, las alertas pueden ser precisas: seudónimo desconocido, réplica retrasada, contexto divergente, integridad fallida, nonce repetido, fallback por política, éxito sin exportación o autorización sin instalación. La precisión evita culpar al par cuando falló el clúster y evita culpar al clúster cuando falló la prueba.

La rapidez de RFC 5106 proviene de reutilizar un contexto autenticado para verificar un intercambio nuevo. No proviene de declarar que el nombre que encontró una fila ya autenticó a quien lo pronunció.

Hay otra consecuencia para la respuesta a incidentes. Si el clúster elimina contextos por presión de memoria, el FRID puede seguir apareciendo en el dispositivo aunque el servidor ya no tenga estado útil. La respuesta correcta es volver al flujo completo o pedir la identidad permanente, no recrear silenciosamente una fila vacía bajo el mismo identificador. Reconstituir estado sin las claves y la genealogía anteriores produciría una coincidencia administrativa que ninguna de las partes puede demostrar criptográficamente.

La métrica de latencia también debe tener etapas. identity_to_lookup, lookup_to_message3, message3_to_message4 y message4_to_success muestran costes distintos. Optimizar solo el primer intervalo puede hacer que el tablero parezca más rápido mientras aumentan fallos de integridad o fallbacks completos. La rapidez útil termina en una sesión nueva verificable, no en la primera respuesta de una caché.

Para retries, el sistema necesita un identificador de intento además de FRID. Dos paquetes con el mismo seudónimo, SPI de cabecera previo y contenido idéntico pueden ser retransmisión del mismo run; otros Ni, proposal SPI o generation anuncian otro intento. Sin esa separación, un contador de «replays» puede castigar pérdidas normales de red o, al contrario, esconder una repetición contra estado ya rotado.

Fuentes