Alan DeKok wrote:
Only if you do it *before* the supplicant stops responding.
FYI, I think I've figured out what's happening. On my Mac, the 802.1x supplicant will abandon the EAP-TLS authentication after the Server Hello Done message if it doesn't have a proper certificate and private key to continue the TLS exchange, as would happen when the user's smartcard is removed. When it does this, it sends an eapLogoff message which sends the AP 802.1x state machine back to DISCONNECTED and unauthorizes the station's port. (IMHO, the Mac supplicant should send a TLS Fatal Handshake message, followed by an eapLogoff, because this would be friendlier to resources on the RADIUS server. But since the station is kicked off the network, it doesn't really matter that much. I may log a bug on this.) On XP, however, the supplicant simply leaves the authentication pending. It never sends a TLS Fatal Handshake or an eapLogoff message. I think this is because of how CAPI handles smartcards; basically, CAPI *always* believes that the smartcard keys are present, even when the card is absent. It's up to the CSP to notify CAPI when keys are unavailable. Since this doesn't appear to be happening, the supplicant blocks waiting for keys so it can send the TLS Client Certificate message. Back on the AP, this seems to tickle an 802.1x state machine bug. The state machine enters a loop, either in the CONNECTING state itself or in a loop from CONNECTING, AUTHENTICATING, ABORTING and back to CONNECTING. This loop should end when a counter (reAuthCounter, which is incremented each time the machine enters the CONNECTING state), exceeds the reAuthMax value, sending the machine back to the DISCONNECTED state. Either reAuthMax is set absurdly high by default on the AP (but it's supposed to be 2 according to IEEE 802.1x-2001), or the counter is not getting incremented in this pathway. Note that a port can only become unauthorized by entering the DISCONNECTED, HELD or FORCE_UNAUTH states. Since the AP state machine never gets to any of these once looping begins with an XP supplicant, the station remains connected to the network. Thus the symptoms I'm seeing. I'll be writing this up to send to both MS and Cisco. I'll likely submit it to BUGTRAQ and Full-Disclosure as well. -- Tim