Interesting EAP-TLS condition, any insights?

[Timothy J. Miller]

This is a neat one.

EAP-TLS is working just fine between an XP supplicant, a Cisco AP1200 
WAP running 12.3(4)JA, and FreeRADIUS 1.0.1 (plus a patch to allow 
multiple root CAs for EAP-TLS trust).  Client certificates are on 
smartcards, and the AP has a reauthentication timer set, with the intent 
that clients will be kicked off the WLAN (eventually) when the card is 
removed (since without the card reauthentication can't complete).

Only it doesn't seem to work that way.

What appears to happen is this:  The authentication starts but never 
completes, since the client can't complete the TLS handshake without the 
smartcard inserted (and PIN entered).  FreeRADIUS blocks at the 
"Requiring client certificate" step, as I would expect.  However, the AP 
holds the authentication pending but *leaves the client fully 
connected*.  This means that as long as an incomplete reauthentication 
is pending, a previously-authenticated client remains online.  Not the 
effect I was looking for.

The Cisco AP has an optional setting for RADIUS timeout, but this only 
seems to apply for the initial packet; since the RADIUS server responded 
to the initial access-request, that timeout doesn't apply.

I tried ramping down max_request_time and setting 
delete_blocked_requests to yes, but it didn't have any effect; 
FreeRADIUS never sends an access-reject.

There appear to be no controls on XP to force a complete 
deauthentication after a timeout that I can find.

Will porting forward to current rev address this, or does anyone else 
have an insight?

-- 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/20051223/3381853d/attachment.bin>