Loading...
Loading...
When native Windows 802.1x supplicant is used with tunneled EAP protocol (e.g. PEAP, TEAP, or EAP-FAST) and "EAP-TLS L-bit" is enabled in "Allowed Protocols" set that is used in matching Authentication Rule for the endpoint on ISE, then the following flow occurs: //Whether "EAP-TLS L-bit" is enabled or disabled: - Supplicant sends EAPOL "Start" twice - NAD sends "Request, Identity" - Supplicant sends "Response, Identity" twice with user/machine identity - ISE sends "Request Preferred-EAP-Protocol" (if not configured explicitly in Allowed Protocols set, then it's EAP-TLS) with EAP-TLS Flags 0x21 (Start with Version 1) - Supplicant sends "Response, Legacy Nak (Response Only)" twice with "Desired Auth Type" = enabled EAP Protocol on endpoint - ISE sends "Request EAP-Protocol" for same Desired Auth Type of endpoint (if allowed in Allowed Protocols set) with EAP-TLS Flags 0x20 (Start) - Supplicant sends "Client Hello" & "Response EAP-Protocol" with EAP-TLS Flags 0x80 (Length Included) - ISE sends "Request EAP-Protocol" with EAP-TLS Flags 0xc0 (Length Included & More Fragments) which indicates EAP-TLS fragmentation and we can see "EAP-TLS Length" is higher than "Length" but with EAP-TLS fragmentation, ISE must receive ACK from supplicant for each sent fragment before sending next fragment - Supplicant sends "Response EAP-Protocol" twice with EAP-TLS Flags 0x00 - ISE sends "Request EAP-Protocol" with EAP-TLS Flags 0x40 (More Fragments) for subsequent fragment - Supplicant sends "Response EAP-Protocol" twice with EAP-TLS Flags 0x00 - Last above 2 steps are repeated for all fragments of this EAP-TLS message - ISE sends "Server Hello, Certificte, Server Key Exchange, Server Hello Done" with EAP-TLS Flags 0x00 - Supplicant replies with "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" & "Response EAP-Protocol" packets with EAP-TLS Flags 0x80 (Length Included) //If "EAP-TLS L-bit" is disabled: - ISE sends "Change Cipher Spec, Encrypted Handshake Message" with EAP-TLS Flags 0x00 - Supplicant sends "Response EAP-Protocol" with EAP-TLS Flags 0x00 - ISE sends "Application Data" with EAP-TLS Flags 0x00 - Supplicant sends "Application Data" & "Response EAP-Protocol" with EAP-TLS Flags 0x00 - Last above 2 steps are repeated a few more times - ISE sends Access-Accept (Success) packet //If "EAP-TLS L-bit" is enabled: - ISE sends "Change Cipher Spec, Encrypted Handshake Message" with EAP-TLS Flags 0x80 (Length Included) - Supplicant sends "Response EAP-Protocol" with EAP-TLS Flags 0x00 - ISE sends "Application Data" with EAP-TLS Flags 0x80 (Length Included) after above steps of establishing TLS tunnel of tunneled EAP protocol - Supplicant discards EAP session and doesn't complete EAP authentication for inner method of the tunnel - In (Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Wired-AutoConfig -> Operational), we get event with "Event ID" is "15514" for "Wired 802.1X Authentication failed" & "Level" is "Error" & Error Code is "0x0" & Reason is "0x70004" & "Reason Text" is "The network stopped answering authentication requests" - After EAP timeout on NAD (value of "dot1x timeout tx-period" multiplied by "dot1x max-reauth-req"), NAD sends EAPOL Start packet and we start new session with same issue, and we notice "Endpoint abandoned EAP session and started new" failed authentication on ISE for previous incomplete session
All of the below conditions should be matched: - EAP-TLS L-bit is enabled in Allowed Protocols set on ISE - Native Windows 802.1x supplicant - Tunneled EAP protocol (e.g. PEAP, TEAP, EAP-FAST)
Any of the below workarounds should fix the issue: - Disable EAP-TLS L-bit in Allowed Protocols set on ISE - Use (AnyConnect / Secure Client) NAM supplicant
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.