EAP-Fragmentierungsimplementierungen und -Verhalten

Einführung

In diesem Dokument wird beschrieben, wie Sie EAP-Sitzungen (Extensible Authentication Protocol) verstehen und Probleme damit beheben können. Diese Themen werden erörtert:

• Verhalten von AAA-Servern (Authentication, Authorization, and Accounting) bei der Rückgabe des Serverzertifikats für die EAP-TLS-Sitzung (Extensible Authentication Protocol-Transport Layer Security)
• Verhalten von Supplicants bei Rückgabe des Client-Zertifikats für die EAP-TLS-Sitzung
• Interoperabilität, wenn sowohl die native Microsoft Windows-Komponente als auch der Cisco AnyConnect Network Access Manager (NAM) verwendet werden
• Fragmentierung in IP-, RADIUS- und EAP-TLS sowie von Netzwerkzugriffsgeräten ausgeführte Reassemblierung
• Das Attribut RADIUS Framed-Maximum Transmission Unit (MTU)
• Verhalten von AAA-Servern bei der Fragmentierung von EAP-TLS-Paketen

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• EAP- und EAP-TLS-Protokolle
• Konfiguration der Cisco Identity Services Engine (ISE)
• CLI-Konfiguration von Cisco Catalyst Switches

Um diesen Artikel zu verstehen, ist ein gutes Verständnis von EAP und EAP-TLS erforderlich.

Vom Server zurückgegebene Zertifikatkette

Der AAA-Server (Access Control Server (ACS) und die ISE geben immer die vollständige Kette für das EAP-TLS-Paket mit dem Server Hello und dem Server-Zertifikat zurück:

Das ISE-Identitätszertifikat (Common Name (CN)=lise.example.com) wird zusammen mit der Zertifizierungsstelle (Certificate Authority, CA) zurückgegeben, die CN=win2012,dc=example,dc=com signiert hat. Das Verhalten ist für ACS und ISE identisch.

Vom Supplicant zurückgegebene Zertifikatskette

Native Komponente von Microsoft Windows

Microsoft Windows 7 Native Supplicant, der für die Verwendung von EAP-TLS konfiguriert wurde, mit oder ohne "Einfache Zertifikatauswahl", sendet nicht die gesamte Kette des Client-Zertifikats. Dieses Verhalten tritt auch dann auf, wenn das Clientzertifikat von einer anderen Zertifizierungsstelle (einer anderen Kette) als das Serverzertifikat signiert wird.

Dieses Beispiel bezieht sich auf den im vorherigen Screenshot dargestellten Server Hello und das Zertifikat. Für dieses Szenario wird das ISE-Zertifikat von der Zertifizierungsstelle unter Verwendung eines Betreffnamens CN=win2012,dc=example,dc=com signiert. Das im Microsoft Store installierte Benutzerzertifikat wird jedoch von einer anderen Zertifizierungsstelle signiert: CN=CA,C=PL,S=Cisco CA,L=Cisco CA, O=Cisco CA.

Daher antwortet die Microsoft Windows-Komponente nur mit dem Clientzertifikat. Die Zertifizierungsstelle, die sie signiert (CN=CA,S=PL,S=Cisco CA, L=Cisco CA, O=Cisco CA) ist nicht angehängt.

Aufgrund dieses Verhaltens können die AAA-Server bei der Validierung von Clientzertifikaten auf Probleme stoßen. Das Beispiel bezieht sich auf Microsoft Windows 7 SP1 Professional.

Lösung

Im Zertifikatsspeicher von ACS und ISE (alle signierenden Clientzertifikate für CA- und UnterCA-Zertifikate) sollte eine vollständige Zertifikatkette installiert werden.

Probleme bei der Zertifikatsvalidierung können auf ACS oder ISE problemlos erkannt werden. Es werden Informationen zu nicht vertrauenswürdigen Zertifikaten und ISE-Berichten angezeigt:

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

Probleme bei der Zertifikatsvalidierung auf dem Supplicant sind nicht leicht erkennbar. In der Regel antwortet der AAA-Server darauf, dass "Endpunkt keine EAP-Sitzung" ist:

AnyConnect NAM

Das AnyConnect NAM weist diese Einschränkung nicht auf. Im selben Szenario fügt er die gesamte Kette des Client-Zertifikats an (die richtige CA ist angehängt):

Native Microsoft Windows-Komponente zusammen mit AnyConnect NAM

Wenn beide Services verfügbar sind, hat AnyConnect NAM Vorrang. Selbst wenn der NAM-Dienst nicht ausgeführt wird, wird er weiterhin auf der Microsoft Windows-API angeheftet und die EAP-Pakete weitergeleitet, was Probleme für die systemeigene Komponente von Microsoft Windows verursachen kann. Hier ein Beispiel für einen solchen Fehler.

Sie aktivieren die Ablaufverfolgung unter Microsoft Windows mit dem folgenden Befehl:

C:\netsh ras set tracing * enable

Die Traces (c:\windows\trace\svchost_RASTLS.LOG) zeigen Folgendes:

[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

Das letzte Paket ist ein Client-Zertifikat (EAP-TLS Fragment 1 mit EAP-Größe 1492), das von der nativen Komponente von Microsoft Windows gesendet wird. Leider zeigt Wireshark dieses Paket nicht:

Und dieses Paket wird nicht wirklich gesendet (das letzte war das dritte Fragment des EAP-TLS-Trading-Server-Zertifikats). Sie wurde vom AnyConnect NAM-Modul verwendet, das auf der Microsoft Windows-API hostet.

Daher wird nicht empfohlen, AnyConnect zusammen mit der nativen Microsoft Windows-Komponente zu verwenden. Wenn Sie AnyConnect-Services verwenden, wird empfohlen, auch NAM (wenn 802.1x-Dienste erforderlich sind) zu verwenden, nicht den systemeigenen Microsoft Windows-Supplicant.

Fragmentierung

Die Fragmentierung kann auf mehreren Ebenen auftreten:

• IP
• RADIUS Attribute Value Pairs (AVP)
• EAP-TLS

Cisco IOS^® Switches sind sehr intelligent. Sie können die Formate EAP und EAP-TLS verstehen. Obwohl der Switch den TLS-Tunnel nicht entschlüsseln kann, ist er für die Fragmentierung sowie die Zusammenstellung und Neuassemblierung der EAP-Pakete bei der Kapselung in Extensible Authentication Protocol over LAN (EAPoL) oder RADIUS verantwortlich.

Das EAP-Protokoll unterstützt keine Fragmentierung. Hier ein Auszug aus RFC 3748 (EAP):

"Fragmentierung wird innerhalb des EAP selbst nicht unterstützt. Dies können jedoch auch einzelne EAP-Methoden unterstützen."

Ein Beispiel hierfür ist EAP-TLS. Es folgt ein Auszug aus RFC 5216 (EAP-TLS), Abschnitt 2.1.5 (Fragmentierung):

"Wenn ein EAP-TLS-Peer ein EAP-Request-Paket mit dem M-Bitsatz empfängt, MUSS er mit einer EAP-Antwort mit EAP-Type=EAP-TLS antworten, ohne dass Daten vorliegen. Dies dient als Fragment-ACK. Der EAP-Server MUSS warten, bis er die EAP-Antwort erhält, bevor er ein weiteres Fragment sendet."

Der letzte Satz beschreibt eine sehr wichtige Funktion von AAA-Servern. Sie müssen auf das ACK warten, bevor sie ein anderes EAP-Fragment senden können. Eine ähnliche Regel wird für die Komponente verwendet:

"Der EAP-Peer MUSS warten, bis er die EAP-Anforderung erhält, bevor er ein anderes Fragment sendet."

Fragmentierung im IP-Layer

Eine Fragmentierung kann nur zwischen dem Network Access Device (NAD) und dem AAA-Server (IP/UDP/RADIUS, der als Transport verwendet wird) auftreten. Diese Situation tritt ein, wenn NAD (Cisco IOS-Switch) versucht, die RADIUS-Anforderung zu senden, die die EAP-Nutzlast enthält, die größer ist als die MTU der Schnittstelle:

Die meisten Cisco IOS-Versionen sind nicht intelligent genug und versuchen nicht, über EAPoL empfangene EAP-Pakete zu einem RADIUS-Paket zusammenzufassen, das in die MTU der physischen Schnittstelle zum AAA-Server passen kann.

AAA-Server sind intelligenter (wie in den nächsten Abschnitten beschrieben).

Fragmentierung in RADIUS

Das ist eigentlich keine Fragmentierung. Gemäß RFC 2865 kann ein einzelnes RADIUS-Attribut bis zu 253 Byte an Daten enthalten. Aus diesem Grund wird die EAP-Nutzlast immer in mehreren RADIUS-EAP-Nachrichten-Attributen übertragen:

Diese EAP-Message-Attribute werden von Wireshark neu zusammengestellt und interpretiert (das Attribut "Last Segment" zeigt die Nutzlast des gesamten EAP-Pakets an). Der Length-Header im EAP-Paket entspricht 1.012, und für die Übertragung sind vier RADIUS-AVPs erforderlich.

Fragmentierung in EAP-TLS

Im gleichen Screenshot können Sie Folgendes sehen:

• Die EAP-Paketlänge beträgt 1.012.
• EAP-TLS-Länge: 2.342

Dies deutet darauf hin, dass es sich um das erste EAP-TLS-Fragment handelt und dass der Supplicant mehr erwarten sollte. Dies kann durch die Überprüfung der EAP-TLS-Flags bestätigt werden:

Diese Art der Fragmentierung tritt am häufigsten in folgenden Fällen auf:

• RADIUS Access-Challenge wird vom AAA-Server gesendet, der die EAP-Anforderung mit dem SSL-Serverzertifikat (Secure Sockets Layer) der gesamten Kette überträgt.
• RADIUS Access-Request wird von NAD gesendet, das die EAP-Antwort mit dem SSL-Client-Zertifikat in der gesamten Kette überträgt.

EAP-TLS-Fragmentbestätigung

Wie bereits erläutert, muss jedes EAP-TLS-Fragment bestätigt werden, bevor nachfolgende Fragmente gesendet werden.

Hier ein Beispiel (Paketerfassung für EAPoL zwischen Komponente und NAD):

EAPoL-Frames und der AAA-Server geben das Serverzertifikat zurück:

• Dieses Zertifikat wird in einem EAP-TLS-Fragment (Paket 8) gesendet.
• Der Supplicant bestätigt dieses Fragment (Paket 9).
• Das zweite EAP-TLS-Fragment wird durch NAD (Paket 10) weitergeleitet.
• Der Supplicant bestätigt dieses Fragment (Paket 11).
• Das dritte EAP-TLS-Fragment wird durch NAD weitergeleitet (Paket 12).
• Der Antragsteller muss dies nicht anerkennen. Stattdessen wird das Client-Zertifikat verwendet, das mit Paket 13 beginnt.

Nachfolgend sind die Details von Paket 12 aufgeführt:

Sie sehen, dass Wireshark die Pakete 8, 10 und 12 erneut assembliert. Die Größe der EAP-Fragmente beträgt 1.002, 1.002 und 338, wodurch die Gesamtgröße der EAP-TLS-Nachricht auf 2.342 ansteigt (die gesamte Länge der EAP-TLS-Nachricht wird in jedem Fragment angegeben). Dies kann bei der Überprüfung von RADIUS-Paketen (zwischen NAD- und AAA-Server) bestätigt werden:

Die RADIUS-Pakete 4, 6 und 8 enthalten diese drei EAP-TLS-Fragmente. Die ersten beiden Fragmente werden bestätigt. Wireshark kann die Informationen zu den EAP-TLS-Fragmenten (Größe: 1.002 + 1.002 + 338 = 2.342).

Dieses Szenario und dieses Beispiel waren einfach. Der Cisco IOS-Switch musste die EAP-TLS-Fragmentgröße nicht ändern.

EAP-TLS-Fragmente werden mit unterschiedlicher Größe neu assembliert

Stellen Sie sich vor, was passiert, wenn die NAD-MTU zum AAA-Server 9.000 Byte (Jumbo-Frame) beträgt und der AAA-Server ebenfalls mit der Schnittstelle verbunden ist, die Jumbo-Frames unterstützt. Die meisten typischen Supplicants sind über eine 1-Gbit-Verbindung mit einer MTU von 1.500 verbunden.

In einem solchen Szenario führt der Cisco IOS-Switch eine "assymetrische" EAP-TLS-Assembly aus und reassembliert sie und ändert die Größe der EAP-TLS-Fragmente. Hier ein Beispiel für eine große EAP-Nachricht, die vom AAA-Server (SSL-Serverzertifikat) gesendet wird:

1. Der AAA-Server muss eine EAP-TLS-Nachricht mit einem SSL-Serverzertifikat senden. Die Gesamtgröße dieses EAP-Pakets beträgt 3.000. Wenn sie in RADIUS Access-Challenge/UDP/IP eingekapselt ist, ist sie immer noch kleiner als die MTU der AAA-Serverschnittstelle. Ein einzelnes IP-Paket wird mit 12 RADIUS EAP-Message-Attributen gesendet. Es gibt keine IP- oder EAP-TLS-Fragmentierung.
   
   
2. Der Cisco IOS-Switch empfängt ein solches Paket, kapselt es und beschließt, dass EAPs über EAPoL an die Komponente gesendet werden müssen. Da EAPoL keine Fragmentierung unterstützt, muss der Switch eine EAP-TLS-Fragmentierung durchführen.
   
   
3. Der Cisco IOS-Switch erstellt das erste EAP-TLS-Fragment, das in die MTU der Schnittstelle zur Komponente (1.500) passen kann.
   
   
4. Dieses Fragment wird vom Supplicant bestätigt.
   
   
5. Nach Erhalt der Bestätigung wird ein weiteres EAP-TLS-Fragment gesendet.
   
   
6. Dieses Fragment wird vom Supplicant bestätigt.
   
   
7. Das letzte EAP-TLS-Fragment wird vom Switch gesendet.

Dieses Szenario zeigt Folgendes auf:

• Unter bestimmten Umständen muss die NAD EAP-TLS-Fragmente erstellen.
• Die NAD ist dafür verantwortlich, diese Fragmente zu senden/zu bestätigen.

Die gleiche Situation kann auch für eine Komponente auftreten, die über eine Verbindung verbunden ist, die Jumbo Frames unterstützt, während der AAA-Server eine kleinere MTU aufweist (dann erstellt der Cisco IOS-Switch EAP-TLS-Fragmente, wenn er das EAP-Paket an den AAA-Server sendet).

RADIUS-Attribut Framed-MTU

Für RADIUS gibt es ein Framed-MTU-Attribut, das in RFC 2865 definiert ist:

"Dieses Attribut gibt die maximale Übertragungseinheit an, die für den Benutzer konfiguriert werden muss, wenn sie nicht auf andere Weise (z. B. PPP) ausgehandelt wird. Sie kann in Access-Accept-Paketen verwendet werden. Es kann in einem Access-Request-Paket als Hinweis vom NAS auf den Server verwendet werden, dass dieser Wert bevorzugt wird, aber der Server muss den Hinweis nicht einhalten."

Die ISE beachtet den Hinweis nicht. Der Wert der von NAD in der Access-Request gesendeten Framed-MTU hat keine Auswirkungen auf die von der ISE durchgeführte Fragmentierung.

Mehrere moderne Cisco IOS-Switches lassen keine Änderungen an der MTU der Ethernet-Schnittstelle zu, außer bei global auf dem Switch aktivierten Jumbo Frames-Einstellungen. Die Konfiguration von Jumbo Frames beeinflusst den Wert des Framed-MTU-Attributs, das in der RADIUS Access-Request gesendet wird. Sie legen z. B. Folgendes fest:

Switch(config)#system mtu jumbo 9000

Dadurch wird der Switch gezwungen, in allen RADIUS-Zugriffsanfragen Framed-MTU = 9000 zu senden. Gleiches für System-MTU ohne Jumbo Frames:

Switch(config)#system mtu 1600

Dadurch wird der Switch gezwungen, in allen RADIUS-Zugriffsanfragen Framed-MTU = 1600 zu senden.

Beachten Sie, dass moderne Cisco IOS-Switches die Senkung der System-MTU-Werte unter 1.500 nicht zulassen.

AAA-Server und zusätzliches Verhalten beim Senden von EAP-Fragmenten

ISE

Die ISE versucht immer, EAP-TLS-Fragmente (in der Regel Server Hello mit Zertifikat) zu senden, die 1.002 Byte lang sind (obwohl das letzte Fragment in der Regel kleiner ist). Die RADIUS Framed-MTU wird dabei nicht berücksichtigt. Es ist nicht möglich, diese neu zu konfigurieren, um größere EAP-TLS-Fragmente zu senden.

Microsoft Network Policy Server (NPS)

Die Größe der EAP-TLS-Fragmente kann konfiguriert werden, wenn das Framed-MTU-Attribut lokal auf NPS konfiguriert wird.

Während im Artikel Konfigurieren der EAP-Payload-Größe für Microsoft NPS angegeben wird, dass der Standardwert einer eingerahmten MTU für den NPS RADIUS-Server 1.500 ist, hat das Cisco Technical Assistance Center (TAC)-Labor gezeigt, dass 2.000 mit den Standardeinstellungen gesendet werden (bestätigt in einem Microsoft Windows 2012-Rechenzentrum).

Es wird getestet, dass das Festlegen der Framed-MTU lokal gemäß dem oben genannten Leitfaden vom NPS beachtet wird, und die EAP-Nachrichten werden in Fragmente aufgeteilt, deren Größe in der Framed-MTU festgelegt ist. Das in der Access-Request empfangene Frame-MTU-Attribut wird jedoch nicht verwendet (identisch mit dem Attribut in ISE/ACS).

Das Festlegen dieses Werts ist eine gültige Problemumgehung, um Probleme in der Topologie wie dieser zu beheben:

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

Derzeit können Sie die MTU-Größe für jeden Port nicht festlegen. Für Switches der Serie 6880 wird diese Funktion zusammen mit der Cisco Bug ID CSCuo26327 - 802.1x EAP-TLS hinzugefügt, die auf FEX-Host-Ports nicht funktioniert.

AnyConnect

AnyConnect sendet EAP-TLS-Fragmente (in der Regel Client-Zertifikat) mit einer Länge von 1.486 Byte. Für diese Wertgröße beträgt der Ethernet-Frame 1.500 Byte. Das letzte Fragment ist normalerweise kleiner.

Native Komponente von Microsoft Windows

Microsoft Windows sendet EAP-TLS-Fragmente (in der Regel Client-Zertifikat) mit einer Länge von 1.486 oder 1.482 Byte. Für diese Wertgröße beträgt der Ethernet-Frame 1.500 Byte. Das letzte Fragment ist normalerweise kleiner.

Zugehörige Informationen

• Konfigurieren der Port-basierten IEEE 802.1x-Authentifizierung
• Technischer Support und Dokumentation - Cisco Systems