Implementaciones y comportamiento de fragmentación de EAP

Introducción

Este documento describe cómo comprender y resolver problemas de sesiones de protocolo de autenticación extensible (EAP). Estos temas se discuten:

• Comportamiento de los servidores de autenticación, autorización y contabilidad (AAA) cuando devuelven el certificado de servidor para la sesión EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)
• Comportamiento de los suplicantes cuando devuelven el certificado de cliente para la sesión EAP-TLS
• Interoperabilidad cuando se utilizan Microsoft Windows Native Supplicant y Cisco AnyConnect Network Access Manager (NAM)
• Fragmentación en IP, RADIUS y EAP-TLS y proceso de reensamblado realizado por dispositivos de acceso a la red
• Atributo RADIUS Framed-Maximum Transmission Unit (MTU)
• Comportamiento de los servidores AAA cuando realizan la fragmentación de paquetes EAP-TLS

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Protocolos EAP y EAP-TLS
• Configuración de Cisco Identity Services Engine (ISE)
• Configuración CLI de switches Cisco Catalyst

Es necesario tener una buena comprensión de EAP y EAP-TLS para entender este artículo.

Cadena de certificados devuelta por el servidor

El servidor AAA (Access Control Server (ACS) e ISE) siempre devuelve la cadena completa para el paquete EAP-TLS con Server Hello y el certificado del servidor:

El certificado de identidad ISE (Nombre común (CN)=lise.example.com) se devuelve junto con la Autoridad de Certificación (CA) que firmó el CN=win2012,dc=example,dc=com. El comportamiento es el mismo tanto para ACS como para ISE.

Cadena de certificados devuelta por el solicitante

Microsoft Windows Native Supplicant

El suplicante nativo de Microsoft Windows 7 configurado para utilizar EAP-TLS, con o sin la "selección de certificado simple", no envía la cadena completa del certificado de cliente. Este comportamiento se produce incluso cuando el certificado de cliente está firmado por una CA (cadena diferente) distinta del certificado de servidor.

Este ejemplo está relacionado con Server Hello y Certificate que se presentaron en la captura de pantalla anterior.Para ese escenario, el certificado ISE está firmado por la CA con el uso de un nombre de asunto, CN=win2012,dc=example,dc=com. Pero el certificado de usuario instalado en el almacén de Microsoft está firmado por otra CA, CN=CA,C=PL,S=Cisco CA,L=Cisco CA, O=Cisco CA.

Como resultado, el suplicante de Microsoft Windows sólo responde con el certificado de cliente. La CA que lo firma (CN=CA,S=PL,S=Cisco CA, L=Cisco CA, O=Cisco CA) no está conectada.

Debido a este comportamiento, los servidores AAA pueden encontrar problemas cuando validan certificados de cliente. El ejemplo se relaciona con Microsoft Windows 7 SP1 Professional.

Solución

Se debe instalar una cadena de certificados completa en el almacén de certificados de ACS e ISE (todos los certificados de cliente de firma de CA y subCA).

Los problemas con la validación de certificados se pueden detectar fácilmente en ACS o ISE. Se presenta la información sobre el certificado no fiable e ISE informa:

12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain

No es fácil detectar los problemas con la validación de certificados en el solicitante. Por lo general, el servidor AAA responde que "sesión EAP abandonada de terminal":

NAM de AnyConnect

El NAM de AnyConnect no tiene esta limitación. En el mismo escenario, adjunta la cadena completa del certificado del cliente (se adjunta la CA correcta):

Microsoft Windows Native Supplicant junto con AnyConnect NAM

Cuando ambos servicios están activos, AnyConnect NAM tiene prioridad. Incluso cuando el servicio NAM no se ejecuta, aún se engancha en la API de Microsoft Windows y reenvía los paquetes EAP, lo que puede causar problemas al suplicante nativo de Microsoft Windows. Este es un ejemplo de tal fracaso.

Habilita el seguimiento en Microsoft Windows con este comando:

C:\netsh ras set tracing * enable

Los seguimientos (c:\windows\trace\svchost_RASTLS.LOG) muestran:

[2916] 09-14 21:29:11:254: >> Received Request (Code: 1) packet: Id: 55, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[2916] 09-14 21:29:11:254: << Sending Response (Code: 2) packet: Id: 55, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[1804] 09-14 21:29:11:301: >> Received Request (Code: 1) packet: Id: 56, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[1804] 09-14 21:29:11:301: << Sending Response (Code: 2) packet: Id: 56, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:348: >> Received Request (Code: 1) packet: Id: 57, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[1804] 09-14 21:29:11:348: << Sending Response (Code: 2) packet: Id: 57, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: >> Received Request (Code: 1) packet: Id: 58, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: << Sending Response (Code: 2) packet: Id: 58, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM
[3084] 09-14 21:31:11:203: >> Received Request (Code: 1) packet: Id: 122, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[3084] 09-14 21:31:11:218: << Sending Response (Code: 2) packet: Id: 122, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[3420] 09-14 21:31:11:249: >> Received Request (Code: 1) packet: Id: 123, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[3420] 09-14 21:31:11:249: << Sending Response (Code: 2) packet: Id: 123, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 124, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[3420] 09-14 21:31:11:281: << Sending Response (Code: 2) packet: Id: 124, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 125, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:296: << Sending Response (Code: 2) packet: Id: 125, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM

El último paquete es un certificado de cliente (EAP-TLS fragment 1 con EAP size 1492) enviado por el suplicante nativo de Microsoft Windows. Desafortunadamente, Wireshark no muestra ese paquete:

Y ese paquete no se envía realmente (el último fue el tercer fragmento del certificado de servidor de carga EAP-TLS). Se ha consumido en el módulo NAM de AnyConnect que se conecta a la API de Microsoft Windows.

Por este motivo, no se recomienda utilizar AnyConnect junto con el suplicante nativo de Microsoft Windows. Cuando utiliza cualquier servicio de AnyConnect, se recomienda utilizar también NAM (cuando se necesitan servicios 802.1x), no el suplicante nativo de Microsoft Windows.

Fragmentación

La fragmentación podría ocurrir en varias capas:

• IP
• Pares de valor de atributo RADIUS (AVP)
• EAP-TLS

Los switches Cisco IOS^® son muy inteligentes. Pueden entender los formatos EAP y EAP-TLS. Aunque el switch no puede descifrar el túnel TLS, es responsable de la fragmentación y el ensamblaje y reensamblado de los paquetes EAP cuando se encapsula en el protocolo de autenticación extensible sobre LAN (EAPoL) o RADIUS.

El protocolo EAP no admite la fragmentación. A continuación se muestra un extracto de RFC 3748 (EAP):

"La fragmentación no se soporta dentro del propio EAP; sin embargo, los métodos EAP individuales pueden admitir esto".

EAP-TLS es un ejemplo. A continuación se muestra un extracto de RFC 5216 (EAP-TLS), sección 2.1.5 (fragmentación):

"Cuando un peer EAP-TLS recibe un paquete EAP-Request con el bit M configurado, DEBE responder con un EAP-Response con EAP-Type=EAP-TLS y sin datos. Esto funciona como un fragmento ACK. El servidor EAP DEBE esperar hasta que reciba EAP-Response antes de enviar otro fragmento".

La última frase describe una característica muy importante de los servidores AAA. Deben esperar a ACK antes de poder enviar otro fragmento EAP. Se utiliza una regla similar para el solicitante:

"El peer EAP DEBE esperar hasta que reciba EAP-Request antes de enviar otro fragmento".

Fragmentación en la Capa IP

La fragmentación sólo puede producirse entre el dispositivo de acceso a la red (NAD) y el servidor AAA (IP/UDP/RADIUS utilizado como transporte). Esta situación ocurre cuando NAD (switch de Cisco IOS) intenta enviar la solicitud RADIUS que contiene la carga útil EAP, que es mayor que la MTU de la interfaz:

La mayoría de las versiones de Cisco IOS no son lo suficientemente inteligentes y no tratan de ensamblar paquetes EAP recibidos a través de EAPoL y combinarlos en un paquete RADIUS que puede caber en la MTU de la interfaz física hacia el servidor AAA.

Los servidores AAA son más inteligentes (como se muestra en las siguientes secciones).

Fragmentación en RADIUS

Esto no es realmente ningún tipo de fragmentación. Según RFC 2865, un único atributo RADIUS puede tener hasta 253 bytes de datos.Debido a esto, la carga útil EAP siempre se transmite en varios atributos RADIUS de mensaje de EAP:

Estos atributos EAP-Message son reensamblados e interpretados por Wireshark (el atributo "Último segmento" revela la carga útil de todo el paquete EAP). El encabezado Length del paquete EAP es igual a 1012 y se requieren cuatro AVP RADIUS para transportarlo.

Fragmentación en EAP-TLS

De la misma captura de pantalla, puede ver que:

• La longitud del paquete EAP es de 1012
• La longitud de EAP-TLS es de 2342

Esto sugiere que es el primer fragmento EAP-TLS y que el solicitante debe esperar más, lo que se puede confirmar si examina los indicadores EAP-TLS:

Este tipo de fragmentación se produce con más frecuencia en:

• RADIUS Access-Challenge enviado por el servidor AAA, que transporta el EAP-Request con el certificado de servidor de Secure Sockets Layer (SSL) con toda la cadena.
• RADIUS Access-Request send by NAD, que transporta EAP-Response con el certificado de cliente SSL con toda la cadena.

Confirmación de fragmento EAP-TLS

Como se explicó anteriormente, cada fragmento EAP-TLS se debe reconocer antes de enviar los fragmentos subsiguientes.

Este es un ejemplo (capturas de paquetes para EAPoL entre el solicitante y el NAD):

Las tramas EAPoL y el servidor AAA devuelven el certificado del servidor:

• Ese certificado se envía en un fragmento EAP-TLS (paquete 8).
• El solicitante reconoce ese fragmento (paquete 9).
• El segundo fragmento EAP-TLS es reenviado por NAD (paquete 10).
• El solicitante reconoce ese fragmento (paquete 11).
• NAD reenvía el tercer fragmento EAP-TLS (paquete 12).
• El solicitante no necesita reconocer esto; más bien, procede con el certificado de cliente que comienza en el paquete 13.

Estos son los detalles del paquete 12:

Puede ver que Wireshark reensambló los paquetes 8, 10 y 12. El tamaño de los fragmentos EAP es 1,002, 1,002 y 338, lo que lleva el tamaño total del mensaje EAP-TLS a 2342 (la longitud total del mensaje EAP-TLS se anuncia en cada fragmento). Esto se puede confirmar si examina los paquetes RADIUS (entre el servidor NAD y AAA):

Los paquetes RADIUS 4, 6 y 8 transportan esos tres fragmentos EAP-TLS. Se reconocen los dos primeros fragmentos. Wireshark puede presentar la información sobre los fragmentos EAP-TLS (tamaño: 1,002 + 1,002 + 338 = 2,342).

Este escenario y ejemplo fue fácil. El switch Cisco IOS no necesitaba cambiar el tamaño del fragmento EAP-TLS.

Fragmentos EAP-TLS reensamblados con diferentes tamaños

Tenga en cuenta lo que sucede cuando la MTU NAD hacia el servidor AAA es de 9000 bytes (trama Jumbo) y el servidor AAA también está conectado con el uso de la interfaz que soporta tramas jumbo. La mayoría de los suplicantes típicos están conectados con el uso de un link de 1 Gbit con una MTU de 1,500.

En tal escenario, el switch Cisco IOS realiza el ensamblado y el reensamblado "asimétricos" de EAP-TLS y cambia los tamaños de los fragmentos de EAP-TLS. Este es un ejemplo para un mensaje EAP grande enviado por el servidor AAA (certificado de servidor SSL):

1. El servidor AAA debe enviar un mensaje EAP-TLS con un certificado de servidor SSL. El tamaño total de ese paquete EAP es 3000. Después de que se encapsula en RADIUS Access-Challenge/UDP/IP, sigue siendo menor que la MTU de la interfaz del servidor AAA. Se envía un solo paquete IP con 12 atributos RADIUS EAP-Message. No hay fragmentación de IP ni EAP-TLS.
   
   
2. El switch del IOS de Cisco recibe tal paquete, lo desencapsula y decide que EAP debe enviarse a través de EAPoL al suplicante. Dado que EAPoL no admite la fragmentación, el switch debe realizar la fragmentación EAP-TLS.
   
   
3. El switch Cisco IOS prepara el primer fragmento EAP-TLS que puede caber en la MTU de la interfaz hacia el suplicante (1500).
   
   
4. Este fragmento es confirmado por el solicitante.
   
   
5. Se envía otro fragmento EAP-TLS después de recibir la confirmación.
   
   
6. Este fragmento es confirmado por el solicitante.
   
   
7. El switch envía el último fragmento EAP-TLS.

Este escenario revela que:

• En algunas circunstancias, el NAD debe crear fragmentos EAP-TLS.
• La NAD es responsable de enviar/reconocer esos fragmentos.

La misma situación puede ocurrir para un suplicante conectado a través de un link que soporta tramas jumbo mientras que el servidor AAA tiene una MTU más pequeña (entonces el switch Cisco IOS crea fragmentos EAP-TLS cuando envía el paquete EAP hacia el servidor AAA).

Atributo RADIUS Framed-MTU

Para RADIUS, hay un atributo Framed-MTU definido en RFC 2865:

"Este atributo indica la unidad de transmisión máxima que se va a configurar para el usuario, cuando no se negocia por otros medios (como PPP). SE PUEDE utilizar en paquetes Access-Accept. PUEDE ser utilizado en un paquete Access-Request como una pista por el NAS al servidor que preferiría ese valor, pero el servidor no es necesario para honrar la pista".

ISE no cumple con la sugerencia. El valor de la MTU con trama enviada por NAD en la solicitud de acceso no tiene ningún impacto en la fragmentación realizada por ISE.

Varios switches modernos de Cisco IOS no permiten cambios en la MTU de la interfaz Ethernet, excepto para la configuración de tramas gigantes habilitada globalmente en el switch. La configuración de tramas jumbo afecta el valor del atributo Framed-MTU enviado en RADIUS Access-Request. Por ejemplo, se establece lo siguiente:

Switch(config)#system mtu jumbo 9000

Esto obliga al switch a enviar Framed-MTU = 9000 en todas las solicitudes de acceso RADIUS. Lo mismo para la MTU del sistema sin tramas jumbo:

Switch(config)#system mtu 1600

Esto obliga al switch a enviar Framed-MTU = 1600 en todas las solicitudes de acceso RADIUS.

Observe que los switches Cisco IOS modernos no le permiten disminuir el valor de MTU del sistema por debajo de 1,500.

Servidores AAA y comportamiento de suplicante al enviar fragmentos EAP

ISE

ISE siempre intenta enviar fragmentos EAP-TLS (normalmente Server Hello con certificado) de 1002 bytes (aunque el último fragmento suele ser más pequeño). No cumple con el RADIUS Framed-MTU. No es posible reconfigurarlo para enviar fragmentos EAP-TLS más grandes.

Microsoft Network Policy Server (NPS)

Es posible configurar el tamaño de los fragmentos EAP-TLS si configura el atributo Framed-MTU localmente en NPS.

Si bien el artículo Configurar el tamaño de carga útil de EAP en Microsoft NPS menciona que el valor predeterminado de una MTU con trama para el servidor RADIUS NPS es 1500, el laboratorio de Cisco Technical Assistance Center (TAC) ha demostrado que envía 2000 con la configuración predeterminada (confirmada en un Data Center de Microsoft Windows 2012).

Se prueba que la configuración MTU de MTU Tramitada localmente según la guía mencionada anteriormente es respetada por NPS, y fragmenta los mensajes EAP en fragmentos de un tamaño configurado en MTU Entramada. Sin embargo, no se utiliza el atributo Framed-MTU recibido en Access-Request (igual que en ISE/ACS).

Establecer este valor es una solución alternativa válida para solucionar problemas en la topología como esta:

Suplicante [MTU 1500] — [MTU 9000]Switch [MTU 9000] — [MTU 9000]NPS

Los switches actuales no le permiten establecer la MTU por puerto; para los switches 6880, esta función se agrega con el ID de bug de Cisco CSCuo26327 - 802.1x EAP-TLS que no funciona en los puertos host FEX.

AnyConnect

AnyConnect envía fragmentos EAP-TLS (normalmente certificado de cliente) de 1486 bytes de longitud. Para este tamaño de valor, la trama Ethernet es de 1500 bytes. El último fragmento suele ser más pequeño.

Microsoft Windows Native Supplicant

Microsoft Windows envía fragmentos EAP-TLS (normalmente certificado de cliente) de 1486 o 1482 bytes de longitud. Para este tamaño de valor, la trama Ethernet es de 1500 bytes. El último fragmento suele ser más pequeño.

Información Relacionada

• Configuración de la Autenticación Basada en Puertos IEEE 802.1x
• Soporte Técnico y Documentación - Cisco Systems