Switching de LAN : 802.1x

Implementaciones y comportamiento de la fragmentación EAP

18 Junio 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (19 Diciembre 2015) | Comentarios

Introducción

Este documento describe cómo entender y resolver problemas las sesiones del Protocolo de Autenticación Extensible (EAP). Se discuten estos problemas:

  • Comportamiento de los servidores del Authentication, Authorization, and Accounting (AAA) cuando devuelven el certificado de servidor para la sesión de la Seguridad de la capa del Protocolo-transporte de la autenticación ampliable (EAP-TLS)
  • Comportamiento de los suplicantes cuando devuelven el certificado del cliente para la sesión del EAP-TLS
  • Interoperabilidad cuando utilizan el supplicant nativo de Microsoft Windows y al administrador del acceso a la red de Cisco AnyConnect (NAM)
  • Fragmentación en el proceso IP, RADIUS, y del EAP-TLS y del nuevo ensamble realizado por los dispositivos de acceso a la red
  • El atributo de la unidad de transmisión del Framed-máximo RADIUS (MTU)
  • El comportamiento de los servidores de AAA cuando realizan la fragmentación de los paquetes del EAP-TLS

Contribuido por Michal Garcarz, David Bednarczyk, y Wojciech Cecot, ingenieros de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

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

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

Cadena de certificados vuelta por el servidor

El servidor de AAA (Access Control Server (ACS) y ISE) vuelve siempre el encadenamiento lleno para el paquete del EAP-TLS con los saludos del servidor y el certificado de servidor:

El certificado de identidad ISE (Common Name (CN) =lise.example.com) se devuelve junto con el Certificate Authority (CA) que firmó el CN=win2012,dc=example,dc=com. El comportamiento es lo mismo para el ACS y el ISE.

Cadena de certificados vuelta por el supplicant

Supplicant del natural de Microsoft Windows

El supplicant del natural de Microsoft Windows 7 configurado para utilizar el EAP-TLS, con o sin el “simple certificate selection (Usar selección de certificado simple)”, no envía el encadenamiento lleno del certificado del cliente. Este comportamiento ocurre incluso cuando el certificado del cliente es firmado por diverso CA (diverso encadenamiento) que el certificado de servidor.

Este ejemplo se relaciona con los saludos del servidor y el certificado presentados en el tiro de pantalla anterior. Para ese escenario, el certificado ISE es firmado por CA con el uso de un asunto, CN=win2012,dc=example,dc=com. Pero el Certificado de usuario instalado en el almacén de Microsoft es firmado por diverso CA, CN=CA, C=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA.

Como consecuencia, el supplicant de Microsoft Windows responde con el certificado del cliente solamente. CA que lo firma (CN=CA, S=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA) no se asocia.

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

Solución

Una Cadena de certificados llena se debe instalar en el almacén de certificados de ACS y de ISE (todo el CA y CA sub que firman los certificados del cliente).

Los problemas con la validación de certificado se pueden detectar fácilmente en el ACS o el ISE. La información sobre el certificado untrusted se presenta y los informes ISE:

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

Los problemas con la validación de certificado en el supplicant no son fácilmente perceptibles. El servidor de AAA responde generalmente que el “punto final abandonó la sesión EAP”:

AnyConnect NAM

El AnyConnect NAM no tiene esta limitación. En el mismo escenario, asocia el encadenamiento completo del certificado del cliente (se asocia CA correcto):

Supplicant nativo de Microsoft Windows junto con AnyConnect NAM

Cuando ambos servicios están para arriba, AnyConnect NAM toma la precedencia. Incluso cuando el servicio NAM no se ejecuta, todavía engancha en Microsoft Windows el API y adelante los paquetes EAP, que pueden causar los problemas para el supplicant del natural de Microsoft Windows. Aquí está un ejemplo de tal error.

Usted habilita el seguimiento en Microsoft Windows con este comando:

C:\netsh ras set tracing * enable

La demostración de las trazas (c:\windows\trace\svchost _RASTLS.LOG):

[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 paquete más reciente es un certificado del cliente (fragmento 1 del EAP-TLS con la talla 1492 EAP) enviado por el supplicant del natural de Microsoft Windows. Desafortunadamente, Wireshark no muestra ese paquete:

Y ese paquete no se envía realmente (el más reciente era el tercer fragmento del certificado de servidor que llevaba del EAP-TLS). Ha sido consumido por el módulo NAM de AnyConnect ese los ganchos en Microsoft Windows API.

Por eso no se aconseja para utilizar AnyConnect junto con el supplicant del natural de Microsoft Windows. Cuando usted utiliza cualquier servicio de AnyConnect, se aconseja para utilizar el NAM también (cuando los servicios del 802.1x son necesarios), no el supplicant del natural de Microsoft Windows.

Fragmentación

La fragmentación pudo ocurrir en las capas múltiples:

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

El Switches del ® del Cisco IOS es muy inteligente. Pueden entender los formatos EAP y del EAP-TLS. Aunque el Switch no pueda desencriptar el túnel de TLS, es responsable de la fragmentación, y ensamblaje y nuevo ensamble de los paquetes EAP cuando encapsulación en el protocolo extensible authentication sobre LAN (EAPoL) o el RADIUS.

El protocolo EAP no soporta la fragmentación. Aquí está un extracto del RFC 3748 (EAP):

La “fragmentación no se soporta dentro de EAP sí mismo; sin embargo, los métodos EAP individuales pueden soportar esto.”

El EAP-TLS es tal ejemplo. Aquí está un extracto del RFC 5216 (EAP-TLS), la sección 2.1.5 (fragmentación):

“Cuando un par del EAP-TLS recibe un paquete de la EAP-petición con el conjunto de bits M, DEBE responder con una EAP-respuesta con EAP-Type=EAP-TLS y ningunos datos. Esto sirve como fragmento ACK. El servidor EAP DEBE esperar hasta que reciba la EAP-respuesta antes de enviar otro fragmento.”

La frase más reciente describe una característica muy importante de los servidores de AAA. Deben esperar el ACK antes de que puedan enviar otro fragmento EAP. Una regla similar se utiliza para el supplicant:

“El par EAP DEBE esperar hasta que reciba la EAP-petición antes de enviar otro fragmento.

Fragmentación en la capa IP

La fragmentación puede ocurrir solamente entre el dispositivo de acceso a la red (NAD) y el servidor de AAA (IP/UDP/RADIUS usado como transporte). Esta situación ocurre cuando el NAD (Switch del Cisco IOS) intenta enviar el pedido de RADIUS que contiene el payload EAP, que es entonces un MTU más grande de la interfaz:

La mayoría de las versiones deL Cisco IOS no son bastante inteligentes y no intentan ensamblar los paquetes EAP recibidos vía EAPoL y combinarlos en un paquete RADIUS que pueda caber en el MTU de la interfaz física hacia el servidor de AAA.

Los servidores de AAA son más inteligentes (según lo presentado en las siguientes secciones).

Fragmentación en el RADIUS

Ésta no es realmente ninguna clase de fragmentación. Según el RFC 2865, un solo atributo de RADIUS puede tener hasta 253 bytes de dato. Debido a ese, el payload EAP se transmite siempre en los atributos de RADIUS múltiples del mensaje EAP:

Esos atributos del mensaje EAP son vueltos a montar e interpretados por Wireshark (el atributo del “segmento más reciente” revela el payload de los paquetes EAP enteros). La encabezado de la longitud en los paquetes EAP es to1,012 igual, y cuatro RADIUS AVP se requieren para transportarlo.

Fragmentación en el EAP-TLS

Del mismo tiro de pantalla, usted puede ver eso:

  • La longitud de los paquetes EAP es 1,012
  • La longitud del EAP-TLS es 2,342

Esto sugiere que sea el primer fragmento del EAP-TLS y el supplicant debe contar con más, que pueden ser confirmadas si usted examina los indicadores del EAP-TLS:

Esta clase de fragmentación lo más frecuentemente ocurre en:

  • Acceso-desafío RADIUS enviado por el servidor de AAA, que lleva la EAP-petición con el certificado de servidor de Secure Sockets Layer (SSL) con el encadenamiento entero.
  • El pedido de acceso RADIUS envía por el NAD, que lleva la EAP-respuesta con el certificado de cliente SSL con el encadenamiento entero.

Confirmación del fragmento del EAP-TLS

Según lo explicado anterior, cada fragmento del EAP-TLS debe ser reconocido antes de que se envíen los fragmentos subsiguientes.

Aquí está un ejemplo (capturas de paquetes para EAPoL entre el supplicant y el NAD):

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

  • Ese certificado se envía en un fragmento del EAP-TLS (paquete 8).
  • El supplicant reconoce ese fragmento (paquete 9).
  • El segundo fragmento del EAP-TLS es remitido por NAD (paquete 10).
  • El supplicant reconoce ese fragmento (paquete 11).
  • El tercer fragmento del EAP-TLS es remitido por NAD (paquete 12).
  • El supplicant no necesita reconocer esto; bastante, procede con el certificado del cliente que comienza en el paquete 13.

Aquí están los detalles del paquete 12:

Usted puede ver que Wireshark volvió a montar los paquetes 8, 10, y 12. El tamaño del EAP hace fragmentos de is1,002, de 1,002, y de 338, que trae el tamaño total del mensaje del EAP-TLS a 2342 (la longitud del mensaje total del EAP-TLS se anuncia en cada fragmento). Esto puede ser confirmada si usted examina los paquetes RADIUS (entre el NAD y el servidor de AAA):

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

Este escenario y ejemplo eran fáciles. El Switch del Cisco IOS no necesitó cambiar el tamaño del fragmento del EAP-TLS.

Fragmentos del EAP-TLS vueltos a montar con diverso tamaño

Considere qué sucede cuando el NAD MTU hacia el servidor de AAA es 9,000 bytes (trama Jumbo) y el servidor de AAA también está conectado con el uso de la interfaz que soporta las Tramas gigantes. La mayor parte de los suplicantes típicos están conectados con el uso de un link 1Gbit con un MTU de 1,500.

En tal escenario, el Switch del Cisco IOS realiza el ensamblaje y el nuevo ensamble “asimétricos” del EAP-TLS y cambia los tamaños de los fragmentos del EAP-TLS. Aquí está un ejemplo para un mensaje EAP grande enviado por el servidor de AAA (certificado de servidor SSL):

  1. El servidor de AAA debe enviar un mensaje del EAP-TLS con un certificado de servidor SSL. El tamaño total de esos paquetes EAP es 3,000. Después de que se encapsule en RADIUS Access-Challenge/UDP/IP, sigue siendo menos que el MTU de interfaz del servidor de AAA. Un solo paquete del IP se envía con 12 atributos del mensaje EAP RADIUS. No hay fragmentación IP ni del EAP-TLS.

  2. El Switch del Cisco IOS recibe tal paquete, los decapsulates él, y decide a que el EAP necesita ser enviado vía EAPoL al supplicant. Puesto que EAPoL no soporta la fragmentación, el Switch debe realizar la fragmentación del EAP-TLS.

  3. El Switch del Cisco IOS prepara el primer fragmento del EAP-TLS que puede caber en el MTU de la interfaz hacia el supplicant (1,500).

  4. Este fragmento es confirmado por el supplicant.

  5. Se envía otro fragmento del EAP-TLS después de que se reciba el acuse de recibo.

  6. Este fragmento es confirmado por el supplicant.

  7. El fragmento más reciente del EAP-TLS es enviado por el Switch.

Este escenario revela eso:

  • En algunas circunstancias, el NAD debe crear los fragmentos del EAP-TLS.
  • El NAD es responsable del enviar/que reconoce esos fragmentos.

La misma situación puede ocurrir para un supplicant conectado vía un link que soporte las Tramas gigantes mientras que el servidor de AAA tiene un MTU más pequeño (entonces el Switch del Cisco IOS crea los fragmentos del EAP-TLS cuando envía los paquetes EAP hacia el servidor de AAA).

Atributo de RADIUS Framed-MTU

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

“Este atributo indica la Unidad máxima de transmisión (MTU) que se configurará para el usuario, cuando no se negocia por algún otro medio (por ejemplo el PPP). PUEDE ser utilizado en los paquetes access-accept. PUEDE ser utilizado en un paquete access-request como indirecta por el NAS al servidor que preferiría ese valor, pero el servidor no se requiere para honrar la indirecta.

El ISE no honra la indirecta. El valor del Framed-MTU enviado por el NAD en el pedido de acceso no tiene ningún impacto en la fragmentación realizada por el ISE.

El Switches moderno múltiple del Cisco IOS no permite los cambios al MTU de la interfaz de Ethernet a excepción de las configuraciones de las Tramas gigantes habilitadas global en el Switch. La configuración de las Tramas gigantes afecta el valor del atributo Framed-MTU enviado en el pedido de acceso RADIUS. Por ejemplo, usted fijó:

Switch(config)#system mtu jumbo 9000

Esto fuerza el Switch para enviar Framed-MTU = 9000 en todos los pedidos de acceso RADIUS. Lo mismo para el mtu del sistema sin las Tramas gigantes:

Switch(config)#system mtu 1600

Esto fuerza el Switch para enviar Framed-MTU = 1600 en todos los pedidos de acceso RADIUS.

Note que el Switches moderno del Cisco IOS no permite que usted disminuya el valor del mtu del sistema debajo de 1,500.

Servidores de AAA y comportamiento del supplicant cuando usted envía los fragmentos EAP

ISE

El ISE intenta siempre enviar los fragmentos del EAP-TLS (generalmente saludos del servidor con el certificado) que son 1,002 bytes de largo (aunque el fragmento más reciente es generalmente más pequeño). No honra el RADIUS FRAMED-MTU. No es posible configurarlo de nuevo para enviar fragmentos más grandes del EAP-TLS.

Servidor de políticas de la red de Microsoft (NP)

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

El evento aunque la configuración el Tamaño de carga útil EAP en el artículo de Microsoft NP menciona que el valor predeterminado de un MTU enmarcado para el servidor de RADIUS NP es 1,500, el laboratorio del Centro de Asistencia Técnica de Cisco (TAC) ha mostrado que envía 2,000 con las configuraciones predeterminadas (confirmadas en Microsoft Windows 2012 Datacenter).

Se prueba que fijando el Framed-MTU localmente según la guía previamente mencionada es respetado por los NP, y hace fragmentos de los mensajes EAP en los fragmentos de un tamaño fijado en el Framed-MTU. Pero el atributo Framed-MTU recibido en el pedido de acceso no se utiliza (lo mismo que en ISE/ACS).

La determinación de este valor es una solución alternativa válida para reparar los problemas en la topología como esto:

Supplicant [MTU 1500] ---- ---- [MTU 9000]Switch [MTU 9000] ----- ----- [MTU 9000]NPS

El Switches no permite actualmente que usted fije el MTU por el puerto; para los 6880 Switch, esta característica se agrega con el Id. de bug Cisco CSCuo26327 - EAP-TLS del 802.1x que no trabaja en los puertos de host FEX.

AnyConnect

AnyConnect envía los fragmentos del EAP-TLS (generalmente certificado del cliente) que son 1,486 bytes de largo. Para este tamaño del valor, la trama Ethernet es 1,500 bytes. El fragmento más reciente es generalmente más pequeño.

Supplicant del natural de Microsoft Windows

Microsoft Windows envía los fragmentos del EAP-TLS (generalmente certificado del cliente) que son 1,486 o 1,482 bytes de largo. Para este tamaño del valor, la trama Ethernet es 1,500 bytes. El fragmento más reciente es generalmente más pequeño.

Información Relacionada


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118634