Interesting EAP-TLS condition, any insights?

[Timothy J. Miller]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2859 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20060103/03cf2ff3/attachment.bin>