Resumen

  • Cuando el servidor acepta la reanudación de TEAP, RFC 9930 permite saltar por completo la fase 2; el ticket debe conservar la relación con la autenticación interna y con las credenciales que sustentan la autorización actual.
  • Si una credencial nueva no puede asociarse al ticket, el servidor debe invalidarlo y obligar a realizar una autenticación completa en la conexión posterior.

Reanudar tiene una razón operativa convincente. Si una persona o una máquina se autentica muchas veces al día, repetir todos los métodos internos carga innecesariamente los servicios de identidad. Por eso RFC 9930 obliga a las implementaciones de TEAP a soportar la reanudación y señala beneficios de escala y estabilidad. Soportar la función, sin embargo, no obliga a aceptar cualquier estado antiguo.

TEAP completo reparte el trabajo en dos fases. La primera usa TLS para levantar un túnel protegido y autenticado. En la segunda viajan los métodos internos y los TLV que pueden autenticar a la máquina, al usuario o a ambos, emitir o cambiar credenciales, realizar Crypto-Binding e intercambiar resultados protegidos. RFC 6678 describe los requisitos de un método EAP tunelizado estándar; RFC 3748 define los actores y los resultados de EAP. Haber creado el túnel no demuestra que el trabajo interior haya terminado.

La reanudación existe para omitirlo. RFC 9930 dice que, si el servidor acepta reanudar, la fase 2 se evita íntegramente. Si rechaza la petición, completa un handshake TLS ordinario y ambas partes deben continuar con la fase 2. El estado puede quedar en el servidor o trasladarse al cliente mediante un ticket como el de RFC 5077. En TLS 1.3, RFC 8446 usa NewSessionTicket para preparar estado relacionado con una PSK futura. Esa continuidad criptográfica no declara que la política de acceso siga siendo la misma.

El ticket puede incluso nacer demasiado pronto. RFC 9427 explica que TLS 1.3 permite enviarlo después del Finished del cliente, antes de que se haya ejecutado la autenticación interna del método tunelizado. Un cliente podría obtener el ticket, abandonar la sesión y tratar de reanudarla sin superar el control interno. Por eso el servidor no debe permitir reanudación salvo que la autenticación interior concluyera con éxito. Conviene retrasar la emisión; si la biblioteca TLS no lo permite, hay que descartar o invalidar los tickets de sesiones fallidas. Si el ticket no revela el resultado, se presume que la autenticación interna no terminó y se la ejecuta antes de conceder acceso.

Tampoco Crypto-Binding sustituye a la autorización. Tras un método interno satisfactorio, RFC 9930 exige Intermediate-Result y Crypto-Binding. El Compound MAC vincula participantes, túnel y secuencia de autenticación, y detecta ciertas sustituciones o rupturas. No decide una VLAN, un ACL, un rol, el estado de una cuenta ni un servicio permitido. Incluso ante un Result TLV de éxito, el par puede pedir otra acción si su política no está satisfecha; el servidor decide conforme a su propia política.

La dificultad temporal aparece aun cuando la primera sesión fue impecable. La fase 2 puede proporcionar o modificar credenciales. La autorización posterior debe basarse en esas credenciales autenticadas, no en una identidad anónima o distinta de la fase 1. En la reanudación también debe aplicarse la autorización correcta: las credenciales nuevas tienen que quedar asociadas al ticket. Si la relación no puede mantenerse, el servidor debe invalidar los tickets de esa sesión. La siguiente conexión pasa por autenticación completa y permite asociar una base actual a un ticket nuevo.

RFC 9190 amplía el análisis a cualquier dato que cambie entre el handshake original y la reanudación: información del par, del autenticador o de las capas circundantes. Si la diferencia puede cambiar una decisión de autorización, contabilidad o política, la decisión debe reevaluarse. Cuando no hay una decisión segura, conviene rechazar la reanudación y continuar con un handshake completo. El límite de siete días de un ticket TLS 1.3 no equivale a siete días de permiso.

La evidencia operativa debe permitir reconstruir la cadena. Hace falta el hash del ticket o Session ID, emisor, tiempos, sesión completa de origen, éxito interno, versiones de credencial y política, contexto del autenticador, cambios intermedios, reevaluación y motivo de aceptación, rechazo o invalidación. Después se registran por separado la autorización actual, el recibo de aplicación del NAS y la observación del tráfico o servicio. RFC 5247 aporta el contexto de claves e identidades EAP, pero no prueba esos efectos posteriores.

La especificación inicial mínima de Heng Lu ayuda a mantener el límite. El ticket común conserva sólo el estado acotado necesario para interoperar; la decisión futura permanece local y atribuible. El código en ejecución debe mostrar qué estado consultó realmente. Ticket, credencial autenticada, política actual, autorización, aplicación y resultado pertenecen a capas distintas. Una reanudación confiable no es la que olvida el pasado, sino la que sabe exactamente qué reutiliza y cuándo dejar de hacerlo.

Sources