Resumen

  • El reinicio o la recuperación de recursos puede borrar el caché de un autenticador mientras el par conserva una clave EAP que todavía no llegó a su vencimiento local.
  • La recuperación segura necesita comprobar estado conjunto en el presente. Si ya no existe una clave común para proteger la resincronización, debe volver a una autenticación completa.

El minuto doce no existía en la otra máquina

El cliente veía una sesión reutilizable hasta las 07:30. Eran las 07:18. El indicador mostraba doce minutos de margen y el software eligió la ruta abreviada. El autenticador, que había reiniciado a las 07:11, no encontraba ese nombre de clave. La operación falló antes de crear claves de tráfico nuevas.

El informe inicial decía «clave rechazada antes de caducar». La frase mezclaba dos hechos. En el cliente, el límite temporal no había llegado. En el autenticador, el objeto había dejado de existir. Una política de duración no reserva memoria remota ni impide que otro proceso descarte estado.

La RFC 5247 trata ese desacuerdo como parte normal del diseño. Un par o un autenticador puede reiniciar o recuperar recursos y limpiar una parte o todo su caché. Por eso la negociación de vida útil no garantiza que ambos cachés sigan sincronizados. Incluso puede ser imposible que el par conozca la ausencia hasta intentar usar la clave.

La lección operativa es incómoda y útil: un contador puede ser exacto sin describir el sistema distribuido.

Tres fases, tres recibos

El marco EAP no produce una única autorización verde. En la fase de método, el par y el servidor EAP pueden autenticarse y derivar material como MSK y EMSK. En la fase AAA, el servidor transporta material y atributos hacia un autenticador. Después, un protocolo de asociación segura entre par y autenticador identifica el contexto, demuestra posesión, negocia capacidades y crea claves transitorias.

La caché permite conservar parte de lo obtenido para otra sesión. No elimina la última fase. Allí hay que demostrar que los dos extremos vivos conservan material compatible y que seleccionaron el mismo contexto. También hay que introducir frescura para no volver a usar las mismas claves de tráfico.

Una entrada local responde «yo guardé esto». Un intercambio protegido responde «los dos podemos usarlo ahora». La diferencia es el centro del problema.

Nombrar no es demostrar

Puede haber varias claves del mismo tipo entre las mismas partes. La RFC exige que el protocolo de asociación nombre explícitamente la elegida para la prueba de posesión. De lo contrario, dos entradas correctas podrían producir una conversación sobre contextos distintos.

El nombre sirve como selector, no como credencial autónoma. Tras seleccionarlo, las partes deben probar posesión sin revelar el secreto. Cuando se admite almacenamiento en caché, el protocolo debe derivar TSK nuevas, normalmente con nonces o contadores. Luego debe activar esas claves y asociarlas con el tráfico correcto.

Por tanto, el recibo completo no cabe en «cache hit». Hace falta registrar el nombre solicitado, la coincidencia en cada lado, la prueba mutua, las contribuciones de frescura, la derivación, la activación y el primer paquete protegido aceptado. El servicio de aplicación viene después.

Reparar el caché también es una operación privilegiada

Cuando un lado conserva la clave y el otro no, la orden «vuelve a instalarla» parece una solución. Pero esa orden cambia el estado de seguridad. Necesita una autoridad que no dependa de la propia entrada ausente.

La RFC 5247 recomienda un mecanismo de resincronización por el protocolo de asociación o por una señal de la capa inferior. Si ambas partes todavía comparten una clave adecuada, ese intercambio puede ir protegido. Si ya no la comparten, no existe una base segura para confiar en la petición de reparación.

Una afirmación sin protección no puede resucitar el secreto que supuestamente la autoriza. En ese caso, la alternativa es iniciar de nuevo EAP, por ejemplo después de un temporizador. La vía más larga vuelve a comprobar las credenciales y puede producir material nuevo, autorización actual y una asociación nueva.

Es una arquitectura de recuperación, no un castigo. Mantiene la dirección correcta de la evidencia: primero se reconstruye autoridad, luego se instala estado.

También importa el alcance

Dos copias byte a byte iguales pueden estar autorizadas para superficies distintas. El marco recomienda sincronizar el alcance del caché y las restricciones de uso. El par debe saber qué considera reutilizable cada autenticador; el autenticador necesita entender el alcance que conserva el par.

Un movimiento entre puntos de acceso, puertos o perfiles no amplía una clave. La existencia local tampoco prueba que el backend elegido en la nueva ruta comparta el estado persistente del anterior. La RFC observa que un autenticador puede cambiar de servidor EAP por configuración o disponibilidad, y que servidores capaces de validar las mismas credenciales no necesariamente comparten toda su memoria.

Por eso una reanudación fallida no debe transformarse de inmediato en «usuario inválido». Puede ser una diferencia de ámbito, de selección de clave, de ruta AAA o de generación de caché.

Diseñar estados que no acusen sin pruebas

Los sistemas de soporte suelen reducir la secuencia a aceptado o credencial incorrecta. Esa simplificación destruye el diagnóstico. Si el autenticador perdió una entrada por reinicio, cambiar la contraseña del usuario no corrige nada. Si la clave está fuera de alcance, aumentar el tamaño del caché tampoco.

Conviene registrar el primer límite no satisfecho: nombre desconocido, contexto ausente, prueba de posesión fallida, TSK no derivada, activación no confirmada, política de acceso denegada o tráfico sin respuesta. Hasta disponer de ese dato, «causa desconocida» es más honesto que revocación, ataque o error humano.

La disciplina protege también al usuario. Un fallo de optimización no debería bloquear una identidad válida. El sistema puede cerrar la ruta abreviada y abrir una reautenticación segura, conservando los dos resultados como hechos diferentes.

La prueba decisiva borra un solo lado

Un laboratorio que reinicia cliente y autenticador juntos demuestra muy poco. La matriz útil combina cuatro condiciones: ambos guardan la entrada; solo la guarda el par; solo la guarda el autenticador; ninguno la guarda. Cada una debe terminar en un resultado determinado, con reintentos limitados y una ruta visible de recuperación.

También hay que ensayar presión de memoria, rotación de backend y reinicios masivos. Una tasa alta de reutilización puede ocultar que el sistema de autenticación completa está infradimensionado. Cuando miles de entradas desaparecen a la vez, el ahorro anterior se convierte en una avalancha hacia el camino caro.

La métrica ejecutiva no es únicamente porcentaje de aciertos. Es capacidad de recuperar fallos seguros sin reutilizar TSK antiguas, sin degradar la comprobación y sin dejar a los usuarios atrapados entre dos memorias coherentes consigo mismas.

Sources