Resumen

  • Una prueba EAP válida puede terminar antes de que la política autorice el servicio, el NAS acepte sus atributos, las claves lleguen al destino correcto o la capa de enlace abra el paso.
  • El expediente fiable conserva por separado la conversación del método, el resultado EAP, el paquete RADIUS, la decisión de acceso, las claves, la asociación segura y la primera conectividad útil.

Hay fallos que el usuario describe como «la contraseña no funciona» aunque la contraseña no sea el problema. El servidor ha validado la credencial; después, un límite de sesiones impide el acceso. O llega Access-Accept, pero el punto de acceso no admite el VLAN pedido. O se exporta una clave que nunca se instala en la asociación de enlace. El resultado de identidad permanece correcto y la red sigue inutilizable.

La RFC 3748 formalizó en 2004 el Extensible Authentication Protocol en el Standards Track. Bernard Aboba comparte la autoría con Larry Blunk, John Vollbrecht, James Carlson y Henrik Levkowetz. No es una invención individual. Su diseño distribuye responsabilidades porque EAP es un marco para métodos de autenticación, no un sistema completo de autorización y conectividad.

El peer responde en el enlace. El autenticador inicia EAP y controla el punto local. El servidor EAP termina el método. Si el autenticador actúa como pass-through, el servidor puede residir en un backend AAA distante y el equipo de acceso solo retransmite mensajes. El componente que comprueba la credencial no tiene por qué ser el que abre el camino de datos.

La propia RFC admite que un peer autenticado puede quedar sin acceso por política, como un límite de sesiones. Los proxies AAA también pueden influir en la autorización. El resultado protegido de un método informa de lo que verificaron sus extremos; no contiene por sí solo el servicio asignado, la capacidad del NAS ni la voluntad final de ofrecer acceso.

El alcance reducido de EAP Success

Cuando el método concluye correctamente, el autenticador envía un paquete con código 3. EAP Success no lleva datos adicionales, no recibe acuse y no se retransmite. Si se pierde, determinadas indicaciones de éxito de la capa inferior pueden permitir al peer llegar a la conclusión correcta. Por eso, ni la presencia ni la ausencia aislada del paquete reconstruyen toda la sesión.

El protocolo ordena descartar un Success prefabricado enviado nada más conectar cuando el método no permite terminar. Así evita que un autenticador falso salte la conversación. Para interpretar el código hay que conservar el estado anterior del método, no solo una captura del último paquete.

El paquete tampoco revela si se aplicaron atributos de autorización, si el puerto controlado cambió de estado, si se instaló la clave correcta o si se obtuvo una dirección IP. Mucho menos demuestra que un flujo de aplicación haya atravesado la red.

RADIUS decide con otro campo

La RFC 3579, de Aboba y P. Calhoun, explica el transporte de EAP dentro de RADIUS. El NAS espera Access-Accept o Access-Reject. Debe decidir el acceso exclusivamente a partir del tipo de paquete RADIUS y no del paquete EAP encapsulado.

Una combinación Access-Reject/EAP Success es contradictoria y no debería enviarse. Si aparece, el NAS rechaza el acceso aunque el peer pueda interpretar que la autenticación salió bien. Access-Accept/EAP Failure produce la divergencia opuesta. El NAS no debe fabricar un mensaje para arreglar la discrepancia. La anomalía debe quedar registrada con ambos resultados.

Access-Accept termina la fase de autenticación, pero puede incluir instrucciones de servicio, VLAN, filtros o límites. Si el NAS reconoce una prestación solicitada y no puede ofrecerla, debe fallar. Un backend también puede devolver políticas diferentes a autenticadores con capacidades distintas. La misma identidad válida no garantiza el mismo acceso en todo lugar.

Generar una clave no instala el canal

La RFC 5247, firmada por Aboba, Dan Simon y P. Eronen, separa la ejecución del método, el transporte de material criptográfico y el protocolo de asociación segura. Una Master Session Key exportada es un producto intermedio. Aún debe llegar al autenticador autorizado, respetar su alcance y producir claves transitorias en la capa inferior.

Un registro que solo diga «MSK generado» omite el destinatario, el identificador de sesión, la derivación y la instalación. Tampoco demuestra que la asociación terminara. Los identificadores del servidor pueden variar entre intercambios internos y externos, y el peer no siempre sabe qué backend atendió la conversación antes de empezarla.

RFC 3748 añade que el tráfico posterior debe quedar vinculado a quienes completaron EAP. La integridad, autenticación y protección antirrepetición por paquete tienen que apoyarse en las claves derivadas. Sin esa unión, una conversación EAP correcta puede preceder a datos falsificados o repetidos.

Credencial correcta, servicio anunciado incorrecto

Una credencial válida para varios servicios abre otra brecha. Un NAS malicioso puede anunciar una red valiosa y conectar al usuario a otra. La RFC 6677 aborda este problema del NAS o proveedor mentiroso. El peer envía de forma protegida datos sobre el servicio observado y el servidor los compara con lo que sabe del autenticador.

El channel binding conserva una relación: anuncio visto, declaración del NAS, referencia del backend y método que protege la comparación. No convierte un nombre de red en identidad certificada ni demuestra despliegue universal. Sí permite detectar que una autenticación fuerte terminó en un contexto distinto del esperado.

La RFC 5216 traza una frontera parecida para EAP-TLS. Además de validar la cadena, una implementación decide si las identidades del certificado son adecuadas y están autorizadas en su contexto. La criptografía entrega material para la política; no decide todas sus reglas.

Una cadena de recibos, no una luz verde

El expediente empieza con el servicio descubierto, la intención del peer, el NAS y el puerto. Después vienen método, conversación, resultado protegido, identidades, EAP Success o Failure, tipo RADIUS, atributos y decisión local. A continuación se anotan exportación y destino de claves, asociación segura, puerto controlado, configuración IP, primera conexión útil y contabilidad.

Así se distingue una credencial rechazada de una identidad válida sin derecho, una autorización de un servicio incompatible y un método finalizado de una ruta de datos inexistente. Esa precisión reduce el tiempo de diagnóstico y evita atribuir a la identidad un fallo de capacidad o política.

Fuentes