Resumen

  • EAP-TTLSv0 divide la negociación en un handshake TLS y una fase de datos protegidos. Si no hay certificado de cliente, la primera fase autentica al servidor, pero la identidad del usuario se presenta en la segunda.
  • El resultado defendible une identidad externa de enrutamiento, certificado y transcript, método e identidad internos, decisión y política AAA, entrega de claves, aplicación en el punto de acceso y tráfico observado.

TLS resolvió el destinatario, no todavía al usuario

RFC 5281 cierra la fase 1 cuando cliente y servidor intercambian ChangeCipherSpec y Finished. Ya existe una capa de registro protegida y ambos comparten secretos. El servidor TTLS se ha autenticado ante el cliente; el cliente solo se ha autenticado mediante TLS si presentó un certificado.

La fase 2 utiliza ese canal para transportar AVP. Allí pueden aparecer el nombre real, una contraseña, una secuencia EAP interna, evidencia de integridad, configuración o aprovisionamiento. El orden importa: el canal se vuelve confiable para recibir la afirmación antes de que la autoridad decida si la afirmación es válida.

Por eso «túnel establecido» no puede convertirse en «abonado autenticado». Tampoco demuestra autorización, instalación de política, protección del enlace ni acceso útil. Cada afirmación necesita su propio observador.

La fecha del documento exige contexto. RFC 5281 es informativo; RFC 8996 prohibió TLS 1.0 y 1.1, y RFC 9427 actualizó EAP-TTLS para TLS 1.3. Una implementación actual no puede tomar las versiones históricas como recomendación vigente.

El primer nombre puede ser solo una dirección postal

El intercambio EAP suele empezar con una identidad en claro, antes de negociar TTLS. Para proteger la privacidad, el cliente puede usar un marcador anónimo y conservar solamente el realm que permite llevar la solicitud al proveedor adecuado.

Ese valor responde «¿hacia qué dominio?» y no «¿quién es el abonado?». El nombre interno, protegido por TLS, responde a una pregunta distinta y será evaluado por AAA/H. Mezclar ambos campos convierte una pista de encaminamiento en prueba de identidad.

Los registros deberían conservar valor, posición y observador. Así es posible reconstruir qué vio el punto de acceso, qué usaron los proxies para enrutar y qué identidad recibió finalmente la autoridad. Un único campo mutable destruye esa trazabilidad.

El terminador ve lo que el túnel escondía

TLS protege los AVP hasta el servidor TTLS. Allí se descifran. El terminador reenvía la información relevante al servidor AAA de origen mediante el protocolo portador. TTLS y AAA/H pueden coincidir, pero también pueden ser sistemas separados con proxies intermedios.

No existe, por tanto, una sola envoltura cifrada de cliente a autoridad final. El tramo backend necesita su propia autenticación y protección. El servidor TTLS ocupa una posición de confianza: ve credenciales y traduce atributos.

La sintaxis compartida tampoco garantiza semántica compartida. RFC 5281 prohíbe copiar un AVP entre TTLS y RADIUS o Diameter si el servidor no entiende su significado en ambos contextos. La traducción correcta es otro recibo, no una propiedad automática del código numérico.

Aceptar puede requerir varias pruebas

AAA/H puede enviar desafíos sucesivos, aceptar o rechazar. El terminador transporta los desafíos por el canal y finalmente refleja el resultado al EAP exterior. En una política multifactor, varias autenticaciones internas pueden formar una sola secuencia.

El protocolo deja a la política decidir si deben aprobarse todas o basta una. Un contador de «métodos exitosos» no revela la regla de decisión. Hace falta la lista ordenada, el resultado de cada método y la versión de política que calculó la conclusión.

Hay ramas sin fase 2: el certificado del cliente puede haber sido suficiente o una sesión reanudada puede heredar una autenticación anterior. Pero la reanudación solo es legítima si la sesión original autenticó al usuario. Guardar en caché una sesión que terminó TLS y falló internamente abriría la puerta sin la prueba; RFC 5281 califica esa consecuencia de catastrófica.

La derivación de claves llega antes que su autoridad de uso

El handshake permite derivar MSK y EMSK. Tras una autenticación exitosa, el servidor TTLS distribuye material de clave y autorización al punto de acceso mediante AAA.

La capacidad matemática de producir bytes no autoriza el servicio. La política puede rechazar al usuario, la clave puede asociarse a otra sesión, el punto de acceso puede no instalarla o las restricciones pueden quedar desactualizadas. Incluso un enlace cifrado puede carecer de conectividad útil.

La evidencia debe ligar hash o identidad de clave, transcript, usuario, decisión AAA, sesión del punto de acceso y estado instalado. Si no existe esa unión, «clave generada» describe una posibilidad criptográfica, no un resultado de acceso.

EAP-Success no observa la ejecución

El cliente suele recibir EAP-Success. El punto de acceso recibe por otra ruta la aceptación, las claves y parámetros de autorización. Un mensaje está orientado al participante EAP; el otro alimenta al ejecutor de política.

Ninguno prueba por sí solo el trabajo del otro. La aceptación puede llegar y no aplicarse. El cliente puede ver éxito mientras el perfil correcto no se instala. El enlace puede activarse y aun así fallar dirección, ruta, DNS o aplicación.

Una afirmación de «acceso restaurado» debe incluir lectura del estado ejecutado y tráfico bidireccional, además del resultado de autenticación. El último observador requerido por la frase pública es quien puede cerrarla.

Dos éxitos sin unión criptográfica

La versión base también reconoce una carencia de binding entre autenticación externa e interna. Si la misma prueba de credencial funciona dentro y fuera del túnel, un atacante puede retransmitirla entre contextos. El documento recomienda evitar esa reutilización y adoptar mecanismos de unión.

No se debe importar retrospectivamente la protección de extensiones o métodos posteriores. EAP-TTLSv0 tiene su contrato histórico propio. El análisis actual debe registrar qué versión y qué binding estuvieron realmente presentes.

Diseñar un recibo por capas

Conserve:

  • cliente, punto de acceso, terminador TTLS y AAA/H;
  • identidad exterior, realm y ruta de proxies;
  • cadena del servidor, nombre esperado y resultado de validación;
  • versión TLS, cifrado, transcript y final de fase 1;
  • certificado del cliente o razón para entrar en fase 2;
  • identidad interna, método, desafíos y resultados;
  • transacción protegida del terminador hacia AAA/H;
  • decisión AAA, generación de política y autorización;
  • EAP-Success o EAP-Failure observado;
  • entrega de MSK y vínculo con la sesión correcta;
  • filtros y restricciones instalados realmente;
  • protección de enlace y primeros paquetes bidireccionales;
  • resultado de la aplicación citado en el informe.

Así una fase puede fallar sin falsificar las anteriores. El túnel puede ser correcto y el usuario rechazado. El usuario puede ser aceptado y la política no aplicada. La política puede aplicarse y el servicio no funcionar. Mantener esas diferencias es gobernar hechos, no colores.

Sources