Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment comprendre et dépanner les sessions EAP (Extensible Authentication Protocol).
Les sections de ce document sont consacrées aux domaines suivants :
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Il est nécessaire d'avoir une bonne compréhension d'EAP et d'EAP-TLS afin de comprendre cet article.
Le serveur AAA (Access Control Server (ACS) et ISE) renvoie toujours la chaîne complète pour le paquet EAP-TLS avec le paquet Hello du serveur et le certificat du serveur :
Le certificat d'identité ISE (Common Name (CN)=lise.example.com) est renvoyé avec l'autorité de certification (CA) qui a signé le CN=win2012, dc=example, dc=com. Le comportement est le même pour ACS et ISE.
Microsoft Windows 7 Native supplicant configuré afin d'utiliser EAP-TLS, avec ou sans la « Sélection de certificat simple », n'envoie pas la chaîne complète du certificat client.
Ce comportement se produit même lorsque le certificat client est signé par une autre autorité de certification (chaîne différente) que le certificat serveur.
Cet exemple est lié au Hello et au certificat du serveur présentés dans la capture d'écran précédente.
Pour ce scénario, le certificat ISE est signé par l'autorité de certification avec l'utilisation d'un nom de sujet, CN=win2012, dc=example, dc=com.
Mais le certificat utilisateur installé dans le magasin Microsoft est signé par une autre autorité de certification, CN=CA, C=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA.
Par conséquent, le demandeur Microsoft Windows répond uniquement avec le certificat client. L'autorité de certification qui la signe (CN=CA, S=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA) n'est pas jointe.
En raison de ce comportement, les serveurs AAA peuvent rencontrer des problèmes lors de la validation des certificats clients. L'exemple concerne Microsoft Windows 7 SP1 Professionnel.
Une chaîne de certificats complète doit être installée sur le magasin de certificats d'ACS et d'ISE (tous les certificats clients de signature de CA et de sous-CA).
Les problèmes de validation de certificat peuvent être facilement détectés sur ACS ou ISE. Les informations relatives aux certificats non approuvés sont présentées et ISE signale :
12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain
Les problèmes de validation de certificat sur le demandeur ne sont pas facilement détectables. Généralement, le serveur AAA répond que « Endpoint a abandonné la session EAP » :
Le module NAM AnyConnect ne présente pas cette limitation. Dans le même scénario, il joint la chaîne complète du certificat client (l'autorité de certification appropriée est jointe) :
Lorsque les deux services sont activés, AnyConnect NAM est prioritaire.
Même lorsque le service NAM ne s'exécute pas, il s'accroche toujours à l'API Microsoft Windows et transfère les paquets EAP, ce qui peut entraîner des problèmes pour le demandeur natif Microsoft Windows.
Voici un exemple d'un tel échec.
Vous activez le suivi sur Microsoft Windows avec cette commande :
C:\netsh ras set tracing * enable
Les traces (c:\windows\trace\svchost_RASTLS.LOG) montrent :
[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
Le dernier paquet est un certificat client (EAP-TLS fragment 1 avec EAP taille 1492) envoyé par le demandeur natif Microsoft Windows. Malheureusement, Wireshark n’affiche pas ce paquet :
Et ce paquet n'est pas réellement envoyé ; le dernier était le troisième fragment du certificat de serveur porteur EAP-TLS.
Il a été utilisé par le module NAM AnyConnect qui s'accroche à l'API Microsoft Windows.
C'est pourquoi il est déconseillé d'utiliser AnyConnect avec le demandeur natif Microsoft Windows.
Lorsque vous utilisez des services AnyConnect, il est conseillé d'utiliser également NAM (lorsque des services 802.1x sont nécessaires), et non le demandeur natif Microsoft Windows.
La fragmentation peut se produire sur plusieurs couches :
Les commutateurs Cisco IOS® sont très intelligents. Ils peuvent comprendre les formats EAP et EAP-TLS.
Bien que le commutateur ne puisse pas décrypter le tunnel TLS, il est responsable de la fragmentation, de l'assemblage et du réassemblage des paquets EAP lors de l'encapsulation dans le protocole EAPoL (Extensible Authentication Protocol over LAN) ou RADIUS.
Le protocole EAP ne gère pas la fragmentation. Voici un extrait de RFC 3748 (EAP) :
"La fragmentation n'est pas prise en charge dans EAP lui-même ; cependant, des méthodes EAP individuelles peuvent prendre en charge cela."
EAP-TLS en est un exemple. Voici un extrait de RFC 5216 (EAP-TLS), section 2.1.5 (fragmentation) :
"Lorsqu'un homologue EAP-TLS reçoit un paquet de requête EAP avec le bit M défini, il DOIT répondre avec une réponse EAP avec EAP-Type=EAP-TLS et aucune donnée.
Il s'agit d'un fragment ACK. Le serveur EAP DOIT attendre de recevoir la réponse EAP avant d'envoyer un autre fragment."
La dernière phrase décrit une fonctionnalité très importante des serveurs AAA. Ils doivent attendre l'accusé de réception avant de pouvoir envoyer un autre fragment EAP. Une règle similaire est utilisée pour le demandeur :
"L'homologue EAP DOIT attendre de recevoir la requête EAP avant d'envoyer un autre fragment."
La fragmentation ne peut se produire qu'entre le périphérique d'accès réseau (NAD) et le serveur AAA (IP/UDP/RADIUS utilisé comme transport).
Cette situation se produit lorsque NAD (commutateur Cisco IOS) tente d'envoyer la requête RADIUS qui contient la charge utile EAP, qui est plus grande que la MTU de l'interface :
La plupart des versions de Cisco IOS ne sont pas assez intelligentes et n'essaient pas d'assembler les paquets EAP reçus via EAPoL et de les combiner dans un paquet RADIUS qui peut tenir dans le MTU de l'interface physique vers le serveur AAA.
Les serveurs AAA sont plus intelligents (comme présenté dans les sections suivantes).
Il ne s'agit pas vraiment d'une fragmentation. Conformément à la RFC 2865, un seul attribut RADIUS peut avoir jusqu'à 253 octets de données.De ce fait, la charge utile EAP est toujours transmise dans plusieurs attributs RADIUS EAP-Message :
Ces attributs EAP-Message sont réassemblés et interprétés par Wireshark (l'attribut « Last Segment » révèle la charge utile de l'ensemble du paquet EAP).
L'en-tête de longueur du paquet EAP est égal à 1 012, et quatre AVP RADIUS sont nécessaires pour le transporter.
Dans la même capture d'écran, vous pouvez voir que :
Cela suggère qu'il s'agit du premier fragment EAP-TLS et que le demandeur en attend plus, ce qui peut être confirmé si vous examinez les indicateurs EAP-TLS :
Ce type de fragmentation se produit le plus souvent dans :
Comme expliqué précédemment, chaque fragment EAP-TLS doit faire l'objet d'un accusé de réception avant que les fragments suivants ne soient envoyés.
Voici un exemple (captures de paquets pour EAPoL entre le demandeur et le NAD) :
Les trames EAPoL et le serveur AAA renvoient le certificat du serveur :
Voici les détails du paquet 12 :
Vous pouvez voir que Wireshark a réassemblé les paquets 8, 10 et 12.
La taille des fragments EAP est de 1 002, 1 002 et 338, ce qui porte la taille totale du message EAP-TLS à 2 342 ;
La longueur totale du message EAP-TLS est annoncée dans chaque fragment. Ceci peut être confirmé si vous examinez les paquets RADIUS (entre NAD et le serveur AAA) :
Les paquets RADIUS 4, 6 et 8 transportent ces trois fragments EAP-TLS. Les deux premiers fragments sont reconnus.
Wireshark peut présenter les informations relatives aux fragments EAP-TLS (taille : 1 002 + 1 002 + 338 = 2 342).
Ce scénario et cet exemple étaient faciles. Le commutateur Cisco IOS n'a pas besoin de modifier la taille du fragment EAP-TLS.
Imaginez ce qui se passe lorsque la MTU NAD vers le serveur AAA est de 9 000 octets (trame jumbo) et que le serveur AAA est également connecté à l'aide de l'interface qui prend en charge les trames jumbo.
La plupart des demandeurs typiques sont connectés à l'aide d'une liaison de 1 Gbit avec une MTU de 1 500.
Dans un tel scénario, le commutateur Cisco IOS effectue un assemblage et un réassemblage « asymétrique » EAP-TLS et modifie la taille des fragments EAP-TLS.
Voici un exemple de message EAP volumineux envoyé par le serveur AAA (SSL Server Certificate) :
Ce scénario révèle que :
La même situation peut se produire pour un demandeur connecté via une liaison qui prend en charge les trames jumbo alors que le serveur AAA a une MTU plus petite (alors le commutateur Cisco IOS crée des fragments EAP-TLS quand il envoie le paquet EAP vers le serveur AAA).
Pour RADIUS, il existe un attribut Framed-MTU défini dans RFC 2865 :
Cet attribut indique l'unité de transmission maximale à configurer pour l'utilisateur, lorsqu'elle n'est pas négociée par un autre moyen (tel que PPP). Il PEUT être utilisé dans les paquets d'acceptation d'accès.
Il PEUT être utilisé dans un paquet de requête d'accès comme indication par le NAS au serveur qu'il préférerait cette valeur, mais le serveur n'est pas tenu d'honorer l'indication."
ISE ne tient pas compte de cet indice. La valeur de Framed-MTU envoyée par NAD dans la requête d'accès n'a aucun impact sur la fragmentation effectuée par ISE.
Plusieurs commutateurs Cisco IOS modernes ne permettent pas de modifier la MTU de l'interface Ethernet, à l'exception des paramètres de trames jumbo activés globalement sur le commutateur. La configuration des trames jumbo a un impact sur la valeur de l'attribut Framed-MTU envoyé dans la requête d'accès RADIUS. Par exemple, vous définissez :
Switch(config)#system mtu jumbo 9000
Ceci force le commutateur à envoyer Framed-MTU = 9000 dans toutes les demandes d'accès RADIUS. Idem pour le MTU système sans trames jumbo :
Switch(config)#system mtu 1600
Ceci force le commutateur à envoyer Framed-MTU = 1600 dans toutes les demandes d'accès RADIUS.
Notez que les commutateurs Cisco IOS modernes ne vous permettent pas de diminuer la valeur MTU du système en dessous de 1 500.
ISE essaie toujours d'envoyer des fragments EAP-TLS (généralement Server Hello avec certificat) de 1 002 octets (bien que le dernier fragment soit généralement plus petit).
Il n'honore pas le MTU tramé RADIUS. Il n'est pas possible de le reconfigurer pour envoyer de plus gros fragments EAP-TLS.
Il est possible de configurer la taille des fragments EAP-TLS si vous configurez l'attribut Framed-MTU localement sur NPS.
Même si l'article Configure the EAP Payload Size on Microsoft NPS mentionne que la valeur par défaut d'un MTU tramé pour le serveur NPS RADIUS est 1 500, les travaux pratiques du Centre d'assistance technique Cisco (TAC) ont montré qu'il envoie 2 000 avec les paramètres par défaut (confirmés dans un data center Microsoft Windows 2012).
Il est testé que la configuration Framed-MTU localement selon le guide mentionné précédemment est respectée par NPS, et il fragmente les messages EAP en fragments d'une taille définie dans Framed-MTU. Mais l'attribut Framed-MTU reçu dans la requête d'accès n'est pas utilisé (identique à celui sur ISE/ACS).
Définir cette valeur est une solution de contournement valide afin de résoudre les problèmes dans la topologie comme ceci :
Demandeur [MTU 1500] ---- ---- [MTU 9000]Commutateur[MTU 9000] ----- ----- [MTU 9000]NPS
Actuellement, les commutateurs ne vous permettent pas de définir la MTU par port ; pour les commutateurs 6880, cette fonctionnalité est ajoutée avec l'ID de bogue Cisco CSCuo26327 - 802.1x EAP-TLS ne fonctionne pas sur les ports hôtes FEX.
AnyConnect envoie des fragments EAP-TLS (généralement un certificat client) de 1 486 octets. Pour cette valeur, la trame Ethernet est de 1 500 octets. Le dernier fragment est généralement plus petit.
Microsoft Windows envoie des fragments EAP-TLS (généralement un certificat client) de 1 486 ou 1 482 octets. Pour cette valeur, la trame Ethernet est de 1 500 octets. Le dernier fragment est généralement plus petit.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
13-Jul-2023 |
Première publication |