Problemen met EAP-fragmentatie, implementaties en gedrag oplossen

Inleiding

In dit document wordt beschreven hoe u EAP-sessies (Extensible Authentication Protocol) kunt begrijpen en oplossen.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• EAP- en EAP-TLS-protocollen
• De Cisco Identity Services Engine (ISE)
• CLI-configuratie van Cisco Catalyst-switches

Het is noodzakelijk om een goed begrip te hebben van EAP en EAP-TLS om dit artikel te begrijpen.

Gebruikte componenten

Dit document is niet beperkt tot specifieke hardware- en softwareversies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Secties van dit document zijn gewijd aan de dekking in deze gebieden:

• Gedrag van verificatie-, autorisatie- en boekhoudservers (AAA) wanneer ze het servercertificaat voor de EAP-TLS-sessie (Extensible Authentication Protocol-Transport Layer Security) retourneren.
• Gedrag van aanvragers bij het retourneren van het clientcertificaat voor de EAP-TLS-sessie.
• Interoperabiliteit wanneer zowel de Microsoft Windows Native Supplicant als de Cisco AnyConnect Network Access Manager (NAM) worden gebruikt.
• Fragmentatie in IP, RADIUS en EAP-TLS en herassemblageproces uitgevoerd door netwerktoegangsapparaten.
• Het RADIUS Framed-Maximum Transmission Unit (MTU) attribuut.
• Het gedrag van AAA-servers bij het uitvoeren van fragmentatie van EAP-TLS-pakketten.

Certificaatketen geretourneerd door server

De AAA-server (Access Control Server (ACS) en ISE) retourneert altijd de volledige keten voor het EAP-TLS-pakket met de Hello Server en het Server-certificaat:

Het ISE-identiteitscertificaat (Common Name (CN)=lise.example.com) wordt teruggestuurd samen met de Certificate Authority (CA) die het CN=win2012 heeft ondertekend, dc=voorbeeld, dc=com. Het gedrag is hetzelfde voor zowel ACS als ISE.

Certificaatketen geretourneerd door de aanvrager

Microsoft Windows Native Supplicant

Microsoft Windows 7 Native supplicant is geconfigureerd om EAP-TLS te gebruiken, met of zonder de eenvoudige certificaatselectie, en verzendt niet de volledige keten van het clientcertificaat. Dit gedrag treedt zelfs op wanneer het clientcertificaat is ondertekend door een andere CA (andere keten) dan het servercertificaat.

Dit voorbeeld is gerelateerd aan de Hello en Certificate van de server die in de vorige schermafbeelding zijn weergegeven. Voor dat scenario wordt het ISE-certificaat ondertekend door de CA met behulp van een onderwerpnaam, CN=win2012, dc=voorbeeld, dc=com, maar het gebruikerscertificaat dat in de Microsoft-winkel is geïnstalleerd, is ondertekend door een andere CA, CN=CA, C=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA.

Als gevolg hiervan reageert de Microsoft Windows-aanvrager alleen met het clientcertificaat. De CA die deze ondertekent (CN=CA, S=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA) is niet gekoppeld.

Vanwege dit gedrag kunnen de AAA-servers problemen ondervinden wanneer ze clientcertificaten valideren. Het voorbeeld heeft betrekking op Microsoft Windows 7 SP1 Professional.

Oplossing

Er moet een volledige certificaatketen worden geïnstalleerd in het certificaatarchief van ACS en ISE (alle CA- en sub-CA-ondertekenende clientcertificaten).

Problemen met certificaatvalidatie kunnen eenvoudig worden gedetecteerd op ACS of ISE. De informatie over niet-vertrouwde certificaten wordt gepresenteerd en ISE rapporteert:

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

Problemen met certificaatvalidatie bij de aanvrager zijn niet gemakkelijk op te sporen. Meestal reageert de AAA-server op de opgegeven EAP-sessie van Endpoint.

Naam AnyConnect

De AnyConnect NAM kent deze beperking niet. In hetzelfde scenario wordt de volledige keten van het clientcertificaat bevestigd (de juiste CA is aangesloten).

Microsoft Windows Native Supplicant samen met AnyConnect NAM

Wanneer beide services zijn ingeschakeld, heeft AnyConnect NAM voorrang. Zelfs wanneer de NAM-service niet wordt uitgevoerd, wordt nog steeds aangesloten op de Microsoft Windows API en worden de EAP-pakketten doorgestuurd, wat problemen kan veroorzaken voor de Microsoft Windows Native-aanvrager.

Hier is een voorbeeld van zo'n mislukking.

U kunt tracering inschakelen in Microsoft Windows met deze opdracht:

C:\netsh ras set tracing * enable

De sporen (c:\windows\trace\svchost_RASTLS.LOG) tonen:

[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

Het laatste pakket is een clientcertificaat (EAP-TLS-fragment 1 met EAP-grootte 1492) dat is verzonden door de Microsoft Windows Native-aanvrager. Helaas laat Wireshark dat pakket niet zien:

En dat pakket wordt niet echt verzonden; het laatste was het derde fragment van het EAP-TLS-certificaat met server.

Het is verbruikt door de AnyConnect NAM-module die is aangesloten op de Microsoft Windows API.

Daarom wordt het niet aangeraden AnyConnect samen met de Microsoft Windows Native-aanvrager te gebruiken.

Wanneer u AnyConnect-services gebruikt, wordt u aangeraden ook NAM te gebruiken (wanneer 802.1x-services nodig zijn), niet de Microsoft Windows Native Supplicant.

fragmentatie

De fragmentatie vindt mogelijk plaats op meerdere lagen:

• IP
• RADIUS Attribuutwaardeparen (AVP)
• EAP-TLS

Cisco IOS^® switches zijn zeer intelligent. Ze kunnen EAP- en EAP-TLS-formaten begrijpen. Hoewel de switch de TLS-tunnel niet kan ontcijferen, is deze verantwoordelijk voor de fragmentatie en assemblage en hermontage van de EAP-pakketten wanneer deze worden ingekapseld in Extensible Authentication Protocol over LAN (EAPoL) of RADIUS.

Het EAP-protocol ondersteunt geen fragmentatie. Hier is een fragment uit RFC 3748 (EAP):

"Fragmentatie wordt niet ondersteund binnen het EAP zelf; individuele EAP-methoden kunnen dit echter wel ondersteunen."

EAP-TLS is daar een voorbeeld van. Hier is een uittreksel uit RFC 5216 (EAP-TLS), paragraaf 2.1.5 (fragmentatie):

"Wanneer een EAP-TLS-peer een EAP-Request-pakket met de M-bitset ontvangt, MOET deze reageren met een EAP-Response met EAP-Type=EAP-TLS en geen gegevens.

Dit dient als een fragment. De EAP-server MOET wachten tot hij de EAP-respons ontvangt voordat hij een ander fragment verzendt."

De laatste zin beschrijft een zeer belangrijk kenmerk van AAA-servers. Ze moeten wachten op de ACK voordat ze een ander EAP-fragment kunnen verzenden. Een soortgelijke regel wordt gebruikt voor de aanvrager:

"De EAP-peer MOET wachten tot hij het EAP-Request ontvangt voordat hij een ander fragment verzendt."

Fragmentatie in de IP-laag

Fragmentatie kan alleen optreden tussen het Network Access Device (NAD) en de AAA-server (IP/UDP/RADIUS gebruikt als transport).

Deze situatie doet zich voor wanneer NAD (Cisco IOS switch) probeert de RADIUS Request te verzenden die de EAP-payload bevat, die groter is dan MTU van de interface:

De meeste Cisco IOS-versies zijn niet intelligent genoeg en proberen geen EAP-pakketten die via EAPoL zijn ontvangen, samen te stellen en te combineren in een RADIUS-pakket dat in de MTU van de fysieke interface naar de AAA-server kan passen.

AAA-servers zijn intelligenter (zoals wordt weergegeven in de volgende secties).

Fragmentatie in RADIUS

Dit is niet echt een vorm van fragmentatie. Volgens RFC 2865 kan een enkel RADIUS-attribuut tot 253 bytes aan gegevens bevatten. Daarom wordt de EAP-payload altijd verzonden in meerdere EAP-Message RADIUS-attributen:

Die EAP-Message-attributen worden opnieuw samengesteld en geïnterpreteerd door Wireshark (het attribuut Laatste segment onthult de payload van het hele EAP-pakket).

De koptekst Lengte in het EAP-pakket is gelijk aan 1.012 en er zijn vier RADIUS AVP's nodig om het te vervoeren.

Fragmentatie in EAP-TLS

Op dezelfde screenshot kun je zien dat:

• EAP-pakketlengte is 1.012
• EAP-TLS lengte is 2.342

Dit suggereert dat het het eerste EAP-TLS-fragment is en de aanvrager verwacht meer, wat kan worden bevestigd als u de EAP-TLS-vlaggen onderzoekt:

Dit soort fragmentatie komt het meest voor bij:

• RADIUS Access-Challenge wordt verzonden door de AAA-server, die het EAP-Request met het SSL-servercertificaat (Secure Sockets Layer) met de hele keten draagt.
• RADIUS Access-Request wordt verzonden door NAD, dat de EAP-Response met het SSL-clientcertificaat met de hele keten meedraagt.

EAP-TLS-fragmentbevestiging

Zoals eerder uitgelegd, moet elk EAP-TLS-fragment worden erkend voordat de volgende fragmenten worden verzonden.

Hier is een voorbeeld (pakketopnames voor EAPoL tussen de aanvrager en de NAD):

EAPoL-frames en de AAA-server retourneren het servercertificaat:

• Dat certificaat wordt verzonden in een EAP-TLS-fragment (pakket 8).
• De aanvrager erkent dat fragment (pakket 9).
• Het tweede EAP-TLS-fragment wordt doorgestuurd door NAD (pakket 10).
• De aanvrager erkent dat fragment (pakje 11).
• Het derde EAP-TLS-fragment wordt doorgestuurd door NAD (pakket 12).
• De aanvrager hoeft dit niet te erkennen; in plaats daarvan gaat hij verder met het clientcertificaat dat begint bij pakket 13.

Hier zijn de details van pakket 12:

Je ziet dat Wireshark de pakketten 8, 10 en 12 opnieuw in elkaar heeft gezet.

De omvang van de EAP-fragmenten is 1.002, 1.002 en 338, wat de totale omvang van het EAP-TLS-bericht op 2.342 brengt.

De totale EAP-TLS-berichtlengte wordt in elk fragment aangekondigd. Dit kan worden bevestigd als u RADIUS-pakketten (tussen NAD- en AAA-server) onderzoekt:

RADIUS-pakketten 4, 6 en 8 bevatten deze drie EAP-TLS-fragmenten. De eerste twee fragmenten zijn bekend.

Wireshark kan de informatie over de EAP-TLS fragmenten presenteren (grootte: 1.002 + 1.002 + 338 = 2.342).

Dit scenario en voorbeeld was eenvoudig. De Cisco IOS-switch hoefde de grootte van het EAP-TLS-fragment niet te wijzigen.

EAP-TLS-fragmenten opnieuw gemonteerd met verschillende afmetingen

Overweeg wat er gebeurt als NAD MTU richting AAA-server 9.000 bytes (jumbo frame) is en de AAA-server ook is verbonden met het gebruik van de interface die jumbo frames ondersteunt. De meeste van de typische aanvragers zijn verbonden met het gebruik van een 1Gbit-link met een MTU van 1.500.

In een dergelijk scenario voert de Cisco IOS-switch EAP-TLS assymetrische assemblage en herassemblage uit en wijzigt hij de grootte van EAP-TLS-fragmenten.

Hier is een voorbeeld van een groot EAP-bericht dat wordt verzonden door de AAA-server (SSL-servercertificaat):

1. De AAA-server moet een EAP-TLS-bericht verzenden met een SSL-servercertificaat. De totale grootte van dat EAP-pakket is 3.000. Nadat het is ingekapseld in RADIUS Access-Challenge / UDP / IP, is het nog steeds minder dan de AAA-serverinterface MTU. Een enkel IP-pakket wordt verzonden met 12 RADIUS EAP-Message-attributen. Er is geen IP- of EAP-TLS-fragmentatie.
   
   
2. De Cisco IOS-switch ontvangt een dergelijk pakket, decapsuleert het en besluit dat EAP via EAPoL naar de aanvrager moet worden verzonden. Aangezien EAPoL geen fragmentatie ondersteunt, moet de switch EAP-TLS-fragmentatie uitvoeren.
   
   
3. De Cisco IOS-switch bereidt het eerste EAP-TLS-fragment voor dat in de MTU van de interface naar de aanvrager kan passen (1.500).
   
   
4. Dit fragment wordt bevestigd door de aanvrager.
   
   
5. Een ander EAP-TLS-fragment wordt verzonden nadat de bevestiging is ontvangen.
   
   
6. Dit fragment wordt bevestigd door de aanvrager.
   
   
7. Het laatste EAP-TLS-fragment wordt verzonden door de switch.

Dit scenario laat zien dat:

• Onder bepaalde omstandigheden moet de NAD EAP-TLS-fragmenten maken.
• De NAD is verantwoordelijk voor het verzenden/erkennen van deze fragmenten.

Dezelfde situatie kan zich voordoen voor een aanvrager die is verbonden via een koppeling die jumboframes ondersteunt, terwijl de AAA-server een kleinere MTU heeft (vervolgens maakt de Cisco IOS-switch EAP-TLS-fragmenten wanneer het EAP-pakket naar de AAA-server wordt verzonden).

RADIUS Attribuut Framed-MTU

Voor RADIUS is er een Framed-MTU attribuut gedefinieerd in RFC 2865:

"Dit kenmerk geeft de maximale transmissie-eenheid aan die voor de gebruiker moet worden geconfigureerd, wanneer er niet op een andere manier over wordt onderhandeld (zoals PPP). Het kan worden gebruikt in Access-Accept-pakketten. Het kan worden gebruikt in een Access-Request-pakket als een hint door de NAS naar de server dat het die waarde zou verkiezen, maar de server is niet verplicht om de hint te honoreren."

ISE houdt zich niet aan de hint. De waarde van de door NAD verzonden Framed-MTU in het Access-Request heeft geen invloed op de door ISE uitgevoerde fragmentatie.

Meerdere hedendaagse Cisco IOS-switches staan geen wijzigingen toe aan de MTU van de Ethernet-interface, behalve voor instellingen voor jumboframes die wereldwijd op de switch zijn ingeschakeld. De configuratie van jumboframes is van invloed op de waarde van het kenmerk Framed-MTU dat wordt verzonden in het RADIUS Access-Request. U stelt bijvoorbeeld in:

Switch(config)#system mtu jumbo 9000

Dit dwingt de switch om Framed-MTU = 9000 te verzenden in alle RADIUS Access-Requests. Hetzelfde geldt voor het MTU-systeem zonder jumboframes:

Switch(config)#system mtu 1600

Dit dwingt de switch om Framed-MTU = 1600 te verzenden in alle RADIUS Access-Requests.

Merk op dat de huidige Cisco IOS-switches u niet toestaan om de MTU-waarde van het systeem onder de 1.500 te verlagen.

AAA-servers en ondersteunend gedrag bij het verzenden van EAP-fragmenten

ISE

ISE probeert altijd EAP-TLS-fragmenten te verzenden (meestal Server Hello met Certificate) die 1.002 bytes lang zijn (hoewel het laatste fragment meestal kleiner is).

Het is niet in overeenstemming met de RADIUS Framed-MTU. Het is niet mogelijk om het opnieuw te configureren om grotere EAP-TLS-fragmenten te verzenden.

Microsoft Network Policy Server (NPS)

Het is mogelijk om de grootte van de EAP-TLS-fragmenten te configureren als u het kenmerk Framed-MTU lokaal op NPS configureert.

Hoewel in het artikel Configure the EAP Payload Size on Microsoft NPS wordt vermeld dat de standaardwaarde van een ingelijste MTU voor de NPS RADIUS-server 1.500 is, heeft het laboratorium van het Cisco Technical Assistance Center (TAC) aangetoond dat het 2.000 verzendt met de standaardinstellingen (bevestigd op een Microsoft Windows 2012 Datacenter).

Het is getest dat de instelling Framed-MTU lokaal volgens de eerder genoemde gids wordt gerespecteerd door NPS, en het fragmenteert de EAP-berichten in fragmenten van een grootte ingesteld in Framed-MTU, maar het Framed-MTU attribuut ontvangen in de Access-Request wordt niet gebruikt (hetzelfde als op ISE / ACS).

Het instellen van deze waarde is een geldige oplossing om problemen in de topologie als deze op te lossen:

VERZOEKENDE PARTIJ [MTU 1500] --- ---- [MTU 9000]Switch [MTU 9000] ---- ---- [MTU 9000]NPS

Op dit moment is het met switches niet mogelijk om de MTU per poort in te stellen; voor 6880 switches is deze functie toegevoegd met Cisco bug ID CSCuo26327 - 802.1x EAP-TLS die niet werkt op FEX-hostpoorten.

AnyConnect

AnyConnect verzendt EAP-TLS-fragmenten (meestal clientcertificaat) met een lengte van 1.486 bytes. Voor deze waarde is het Ethernet-frame 1.500 bytes. Het laatste fragment is meestal kleiner.

Microsoft Windows Native Supplicant

Microsoft Windows verzendt EAP-TLS-fragmenten (meestal clientcertificaat) die 1.486 of 1.482 bytes lang zijn. Voor deze waarde is het Ethernet-frame 1.500 bytes. Het laatste fragment is meestal kleiner.

Gerelateerde informatie

• IEEE 802.1x-poortgebaseerde verificatie configureren
• Technische ondersteuning en documentatie – Cisco Systems