Resumen

  • RFC 9678 define una extensión ECDHE opcional y autenticada para EAP-AKA', con X25519 y P-256, que incorpora un secreto efímero a la derivación de MSK, EMSK y K_re.
  • Un acceso puede autenticarse correctamente por EAP-AKA' sin usar la extensión si las políticas aceptan repliegue; por tanto, el indicador de éxito no mide la propiedad de secreto hacia adelante.
  • Incluso cuando la negociación se completa, la protección de sesiones pasadas exige cierre e eliminación efectiva de todos los materiales relevantes, algo que el intercambio no puede certificar a distancia.

El éxito que tomó la ruta antigua

Una actualización activa la extensión en el servidor. La mayoría de los terminales reconoce AT_KDF_FS y responde con una clave pública. Un grupo antiguo no lo hace. Para evitar una interrupción, la política permite continuar con EAP-AKA' convencional. El cuadro operativo queda verde: todos se autenticaron.

La disponibilidad es real. La conclusión de seguridad no.

Las sesiones del grupo antiguo nunca obtuvieron la contribución ECDHE que RFC 9678 añade para resistir una exposición futura de la clave de larga duración. No hubo error de protocolo. La política eligió compatibilidad. Si el informe ejecutivo toma el éxito de autenticación como prueba de secreto hacia adelante, borra precisamente la decisión que explica el riesgo.

Esta escena convierte el repliegue en una cuestión de autoridad. El estándar proporciona un modo nuevo y reglas para negociarlo. El operador decide cuándo negarse a la ruta vieja, quién asume la pérdida de acceso y cuánto tiempo puede existir una excepción.

Qué aporta el nuevo intercambio

RFC 9678 apareció en marzo de 2025 como Proposed Standard y actualiza RFC 9048 y RFC 5448. EAP-AKA' utiliza credenciales de largo plazo asociadas al abonado y al entorno de autenticación de origen. Esa dependencia crea una amenaza de “capturar ahora, abrir después”: conservar tráfico y material de protocolo hasta obtener años más tarde la clave simétrica de largo plazo.

La extensión agrega un acuerdo efímero Elliptic Curve Diffie-Hellman. El servidor envía opciones AT_KDF_FS y una clave pública en AT_PUB_ECDHE; el par selecciona una opción compatible y devuelve su valor. IANA registra los tipos de atributo 152 y 153. El RFC define alternativas basadas en X25519 y P-256.

Los nuevos atributos quedan cubiertos por AT_MAC. Esa protección une la selección y las claves públicas a la autenticación AKA' existente: un intermediario sin credenciales no puede sustituirlas sin provocar un fallo de verificación. El secreto compartido participa en MK_ECDHE, y de la jerarquía salen K_re, MSK y EMSK.

Si un atacante obtiene más tarde la clave de abonado, esa clave por sí sola ya no reconstruye el secreto efímero. Esa es la mejora. No implica que un atacante que ya posee la clave de largo plazo durante la sesión activa quede neutralizado; el documento advierte que tal adversario puede atacar el intercambio presente y escuchar el tráfico resultante.

La política vive en ambos extremos

Servidor y par deciden si la extensión es obligatoria, preferida u opcional. También deciden qué grupos y funciones admiten y si una falta de coincidencia autoriza el repliegue. Cuando el par exige la protección y no puede usarla, RFC 9678 define un comportamiento de fallo en vez de simular el resultado.

Esta autonomía local evita imponer de una sola vez una política global. También crea estados que deben observarse por separado: capacidad anunciada, oferta recibida, selección concreta, transcript autenticado, repliegue aceptado y fallo por requisito. Una sola métrica de acceso confunde esos estados.

El problema no es el repliegue en sí. Puede ser una decisión razonada durante una migración. El problema aparece cuando deja de tener nombre, población y fecha de caducidad. Una excepción invisible tiende a convertirse en arquitectura permanente.

Negociar no destruye

La protección histórica descrita por RFC 9678 contiene una condición explícita: las sesiones terminadas deben haber eliminado todo el material de clave relevante. Eso incluye los secretos efímeros y las claves de sesión cuya supervivencia permitiría recuperar o usar el contexto antiguo.

La red no puede inspeccionar todos los lugares donde viven esas copias. El proceso EAP puede borrar su búfer mientras un gestor de claves conserva un identificador válido. Un acelerador puede mantener estado. Una puerta de enlace puede almacenar la MSK. Un volcado de memoria, una imagen de hibernación, una copia de seguridad o un canal de diagnóstico puede haber capturado el secreto.

Por eso, la palabra “efímero” describe la intención criptográfica, no una medición de la duración real. La duración se demuestra con un inventario de custodios, eventos de retiro y mecanismos de destrucción. El inventario debe incluir sistemas aguas abajo, no solo las dos entidades que intercambiaron mensajes EAP.

También hay que definir “sesión terminada”. La terminación del método, la desconexión de acceso, el fin de un túnel y la expiración del contexto de abonado pueden ocurrir en momentos distintos. Mientras un consumidor siga autorizado a usar una clave, esa copia no está retirada aunque otro componente haya cerrado su estado.

La apariencia de novedad en la reautenticación

Si la autenticación completa original incorporó ECDHE, K_re queda derivada de esa jerarquía y la reautenticación conserva protección frente a la obtención posterior de la clave larga. Es una propiedad útil para sesiones que evitan repetir el procedimiento completo.

No obstante, RFC 9678 no realiza un Diffie-Hellman nuevo en cada reautenticación. El evento reciente hereda material de un acuerdo anterior. La edad del contexto, su número de usos y su fecha de renovación completa son hechos de seguridad.

Una interfaz que presenta cada reautenticación como una nueva negociación ECDHE convierte una optimización en una afirmación falsa de frescura. El registro correcto enlaza la reautenticación con la autenticación completa que originó K_re.

El consumidor de MSK define la consecuencia

EAP produce material para otras capas. La extensión no protege tráfico en abstracto: contribuye a las claves que reciben consumidores concretos. Si después interviene IKEv2 con su propio acuerdo efímero, parte del beneficio puede estar ya presente en esa capa. Si la protección de enlace depende directamente de la MSK sin otro intercambio con secreto hacia adelante, RFC 9678 puede cambiar de forma decisiva la exposición histórica.

La prueba debe identificar qué MSK o EMSK salió, qué asociación la consumió, si hubo otro mecanismo efímero, cuándo terminó esa asociación y dónde quedaron copias. Sin ese enlace, la organización sabe cómo acabó EAP pero no sabe qué propiedad tuvo el tráfico que pretende describir.

Una escalera, no una casilla

La evidencia empieza antes de los paquetes: políticas del par y del servidor, reglas de repliegue y versiones de implementación. Continúa con la oferta ordenada, la elección de KDF, las claves públicas y la validación de AT_MAC. Después debe registrar, sin revelar secretos, que la contribución ECDHE entró en la derivación prevista.

El siguiente peldaño une cada salida con su consumidor. Luego aparecen los eventos de fin de sesión y el inventario de custodios. Cada custodio entrega un recibo de eliminación, caducidad o invalidación. Las excepciones —instantáneas, retención forense, depuración— quedan declaradas.

Un ensayo autorizado cierra la cadena: con la captura antigua y una clave de largo plazo expuesta después, intenta recuperar las claves retiradas. Un resultado negativo con alcance definido ofrece evidencia del resultado operativo. No convierte en conocidas todas las copias posibles, pero obliga a probar algo más fuerte que un indicador de configuración.

Especificación mínima, adopción observable

La publicación de RFC 9678 crea lenguaje común y reglas interoperables. No demuestra que un producto lo incorpore. La incorporación no demuestra que esté habilitado. La oferta no demuestra selección. La selección no demuestra uso por la capa relevante. El uso no demuestra eliminación.

La idea de especificación inicial mínima de Heng Lu encaja aquí: el estándar fija lo necesario para coordinar; las decisiones futuras quedan en los entornos que soportan sus costes. Su primacía del código ejecutado añade la disciplina decisiva. Los números de atributo pertenecen al texto; la vida de los secretos pertenece al software que corre y a los sistemas que los copian.

El objetivo no es rebajar el valor del protocolo. Es impedir que una buena mejora sea convertida en una promesa más amplia que su evidencia. RFC 9678 puede separar las sesiones pasadas de una clave larga expuesta. La organización debe demostrar que no conservó otra puerta hacia el mismo pasado.

Fuentes