Extensible Authentication Protocol

^[1]​Extensible Authentication Protocol (EAP) es un framework de autenticación usado habitualmente en redes WLAN Point-to-Point Protocol. Aunque el protocolo EAP no está limitado a LAN inalámbricas y puede ser usado para autenticación en redes cableadas, es más frecuente su uso en las primeras. Recientemente los estándares WPA y WPA2 han adoptado cinco tipos de EAP como sus mecanismos oficiales de autenticación.

Es una estructura de soporte, no un mecanismo específico de autenticación. Provee algunas funciones comunes y negociaciones para el o los mecanismos de autenticación escogidos. Estos mecanismos son llamados métodos EAP, de los cuales se conocen actualmente unos 40. Además de algunos específicos de proveedores comerciales, los definidos por RFC de la IETF incluyen EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, y EAP-AKA.

Los métodos modernos capaces de operar en ambientes inalámbricos incluyen EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP y EAP-TTLS. Los requerimientos para métodos EAP usados en LAN inalámbricas son descritos en la RFC 4017. Cuando EAP es invocada por un dispositivo NAS (Network Access Server) capacitado para 802.1X, como por ejemplo un punto de acceso 802.11 a/b/g, los métodos modernos de EAP proveen un mecanismo seguro de autenticación y negocian un PMK (Pair-wise Master Key) entre el dispositivo cliente y el NAS. En esas circunstancias, la PMK puede ser usada para abrir una sesión inalámbrica cifrada que usa cifrado TKIP o AES.

EAP fue diseñado para utilizarse en la autenticación para acceso a la red, donde la conectividad de la capa IP puede no encontrase disponible. Dado que EAP no requiere conectividad IP, solamente provee el suficiente soporte para el transporte confiable de protocolos de autenticación y nada más.

EAP es un protocolo lock-step, el cual solamente soporta un solo paquete en transmisión. Como resultado, EAP no puede transportar eficientemente datos robustos, a diferencia de protocolos de capas superiores como TCP.

Aunque EAP provee soporte para retransmisión, este asume que el ordenamiento de paquetes es brindado por las capas inferiores, por lo cual el control de orden de recepción de tramas no está soportado. Ya que no soporta fragmentación y re-ensamblaje, los métodos de autenticación basados en EAP que generan tramas más grandes que el soportado por defecto por EAP, deben aplicar mecanismos especiales para poder soportar la fragmentación (Por ejemplo EAP-TLS). Como resultado, puede ser necesario para un algoritmo de autenticación agregar mensajes adicionales para poder correr sobre EAP. Cuando se utiliza autentificación a base de certificados, el certificado es más grande que el MTU de EAP, por lo que el número de round-trips (viaje de ida y vuelta de paquetes) entre cliente y servidor puede aumentar debido a la necesidad de fragmentar dicho certificado.

Se debe considerar que cuando EAP corre sobre una conexión entre cliente y servidor donde se experimenta una significante pérdida de paquetes, los métodos EAP requerirán muchos viajes de ida y vuelta y se reflejará en dificultades de conexión.

1.- El servidor de autenticación envía un Request (Solicitud) de Autenticación al cliente, el mensaje de Request tiene un campo de Tipo, en el cual el cliente debe responder que es lo que está solicitando, los tipos existentes son: Identidad, Notificación, Nak, MD5-Challenge, One-Time Password (OTP), Generic Token-Card (GTC), Tipos Expandidos y Experimental

2.- El cliente envía un paquete Response (Respuesta) al servidor. Al igual que en el paquete Request, el paquete Response contiene un campo de Tipo, el cual corresponde al campo de Tipo en el paquete de Request.

3.- El servidor de autenticación envía un paquete Request adicional, al cual el cliente envía un Response. La secuencia de Request y Response continúa según sea necesario. Como se mencionó, EAP es un protocolo lock-step, por lo que no se puede enviar el siguiente paquete sin haber recibido uno válido antes. El servidor es responsable de transmitir las solicitudes de retrasmisión, dichos métodos se describen en el RFC de EAP, el RFC 3748. Después de un número de retransmisiones, el Servidor PUEDE terminar la conversación EAP. El servidor NO PUEDE enviar un paquete de Success o Failure cuando se retransmite o cuando falla en recibir una respuesta a dichos paquetes por parte del cliente.

4.-La conversación continúa hasta que el servidor no puede autenticar al cliente, y en dicho caso el servidor DEBE trasmitir un mensaje de Failure. Como alternativa, la conversación de autenticación puede continuar hasta que el servidor determina que se ha cumplido con una autenticación satisfactoriamente, para dicho caso, el servidor DEBE enviar un paquete de Success.

m

---