Interesting EAP-TLS condition, any insights?

[Michael Griego]

I'm very curious about the outcome of this as well.  The AP is 
*supposed* to block all traffic except for EAP traffic pending the 
required EAP-Success from the Authentication Server.  If the AP is 
allowing non-EAP traffic through, and, given that the client->AP traffic 
occurs unencrypted until the EAPoL Keys are sent, that could allow a 
total bypass of security on those APs.

Ick.  I hope this doesn't turn out to be true for any other vendors...  
I'm pretty sure that it doesn't work that way for Proxim APs since I've 
seen the EAPoL exchange hang on those guys before and the client gives 
up and tries to communicate anyway to no avail...

--Mike


Alan DeKok wrote:
> "Timothy J. Miller" <tmiller at mitre.org> wrote:
>   
>> 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.
>>     
>
>   That would appear to be a bug in the AP.  I'd be curious to know how
> many AP's have that bug.  If so, it would be a very, very, serious
> problem.
>
>   I'm not sure how to fix that, to be honest.  There's little you can
> do on the RADIUS server to make the AP work.
>
>   My only suggestion is to try another AP.  If that works, mail Cisco,
> and tell them about the bug.
>
>   Alan DeKok.
>
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>