Resumen

  • RFC 5296 reduce la reautenticación EAP a una ida y vuelta, pero no convierte la aceptación del servidor, la respuesta al par, el transporte AAA y la asociación de capa inferior en un solo resultado.
  • La trazabilidad debe probar qué rMSK quedó ligada a qué autenticador, cuándo fue instalada, qué clave eligió la capa inferior y cuál fue el desenlace del acceso.

El final visible estaba en mitad del camino

ERP permite que un par con material vigente evite repetir todo el método EAP al cambiar de autenticador. EAP-Initiate/Re-auth viaja al servidor ER y EAP-Finish/Re-auth vuelve en una sola ronda. El servidor puede encontrarse en el dominio de origen o en el dominio visitado.

La rapidez oculta una cadena. El autenticador retransmite mensajes ERP. El servidor comprueba la posesión de rIK y la frescura. AAA lleva un rMSK por autenticador. El par deriva el mismo valor. Después, otra negociación establece las claves transitorias que la capa inferior usa para controlar paquetes.

Un indicador que termina en el Finish solo observa la mitad superior.

La admisión consume estado de secuencia

Initiate incluye un SEQ de 16 bits, un solo keyName-NAI, una suite criptográfica y una etiqueta de autenticación. Una nueva rRK reinicia SEQ a cero. El servidor decide si el número es el esperado o está dentro de una ventana permitida y aún no usada. Luego comprueba la suite y la integridad.

Al aceptar, deriva rMSK con rRK y SEQ. Finish devuelve el mismo SEQ, mientras el servidor incrementa el siguiente esperado o actualiza su ventana. Esa mutación puede ocurrir aunque la respuesta posterior se pierda.

Por eso, la prueba necesita el estado anterior, los límites de ventana, la decisión de no reutilización, el instante de aceptación y el estado nuevo. El paquete correcto no demuestra por sí solo qué quedó persistido.

Reenviar no significa volver a autorizar

El par mantiene los temporizadores. Una retransmisión conserva el Identifier EAP; un Initiate nuevo debe elegir otro. Finish solo corresponde al Initiate pendiente cuyo Identifier coincide.

SEQ e Identifier no son duplicados. Identifier correlaciona un intercambio pendiente. SEQ protege frente a repetición y entra en la derivación del rMSK. Si la telemetría los reduce a una petición genérica, puede contar dos veces un reenvío o confundir una nueva operación con el paquete anterior.

El estado ERP del autenticador debería limpiarse después de 300 segundos. Ese temporizador local no sincroniza automáticamente las ventanas del servidor ni el estado del par.

La autenticidad de Finish no es un acuse de instalación

El par comprueba que esperaba el SEQ recibido bajo ese keyName-NAI y valida la integridad de Finish. Después calcula rMSK. Solo entonces la asociación de seguridad inferior queda lista para ser activada.

La palabra “lista” mantiene abierta la causalidad. El servidor puede haber producido una respuesta auténtica mientras AAA no entrega la clave, el autenticador rechaza la generación o la negociación TSK falla. Incluso con ambos extremos poseyendo el mismo rMSK, el acceso efectivo aún depende de una decisión posterior.

El recibo debe distinguir creación y validación de Finish, envío y recepción AAA, instalación, selección de generación, inicio y fin de TSK, y resultado de control de acceso.

Una clave, un autenticador

rMSK se deriva de rRK con un rótulo fijo, SEQ y la longitud. No puede compartirse entre múltiples autenticadores y no vive más que rRK. Si aparece una nueva rRK, los rMSK siguientes proceden de ella, pero los anteriores ya entregados pueden seguir válidos hasta su vencimiento.

Una rotación no prueba un corte simultáneo. Cada autenticador mantiene su propio hecho de recepción, instalación, uso y retirada.

El bootstrap ofrece una prueba especialmente clara. Cuando existen TSK derivadas de un MSK previo, la capa inferior puede ignorar el rMSK recién recibido o puede iniciar una nueva asociación. La recepción es igual; el efecto no.

La concurrencia sustituye el siguiente número por una ventana

Un par puede ejecutar ERP simultáneamente por varios autenticadores hacia el mismo servidor. Los mensajes pueden desordenarse. Para aceptar operaciones legítimas, el servidor puede admitir SEQ no usados dentro de una ventana cuya gestión es local.

Auditar solo el número elimina el contexto de la decisión. Hay que guardar límites, generación de ventana, conjunto consumido, autenticador de tránsito y versión de política. Así se distingue una llegada tardía legítima de una repetición.

También conviene alertar cuando cambia el ancho de ventana: modifica el conjunto de mensajes admitidos sin cambiar ninguna clave.

Un fallo dudoso conserva dos explicaciones

El servidor responde con Finish de fallo. Si posee rIK, lo protege; si rechaza la suite, puede listar alternativas. El par verifica secuencia e integridad y puede reintentar con otra suite, reconstruyendo las claves cuando cambia la PRF.

Cuando falla la comprobación de repetición o integridad, el mensaje podría ser falso, pero también podría revelar que ambas partes no comparten suite. El par no puede saber cuál. Debe continuar los reenvíos antes de declarar fracaso.

La alarma profesional debe conservar esa ambigüedad. Clasificarla como ataque sin otra evidencia confunde un límite de observación con una atribución.

La revisión exigió posesión actual

RFC 6696 reemplazó RFC 5296 de forma compatible y aclaró que el autenticador o servidor ER local tiene que comprobar la posesión actual de material raíz válido durante el bootstrap implícito. Un contexto antiguo identificado por nombre no basta.

Esa comprobación habilita al actor para responder. Aun así no demuestra entrega, instalación ni acceso. La generación raíz debe acompañar toda la cadena.

Un recibo de extremo a extremo

Registrar identidad y vencimiento de rRK; keyName-NAI y dominio; Identifier; SEQ; ventana y estado de uso; suite; veredicto de integridad; aceptación y transición del contador; generación rMSK y vínculo a un autenticador; Finish; operación AAA y destino; acuse de recepción e instalación; verificación y derivación del par; MSK o rMSK elegida; negociación TSK; resultado de acceso; retorno a EAP completo; retransmisiones; y datos y veredicto de channel binding.

Nunca registrar las claves. La evidencia debe describir cuándo una posibilidad se convirtió en uso.

Sources