Interesting EAP-TLS condition, any insights?

[Timothy J. Miller]

Michael Griego wrote:
> 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.

It only occurs during a session reauthentication forced by the AP; 
initial authentication works as expected.  The traffic remains encrypted 
during the pending authentication, so I'm assuming that the previous 
session keys are still being used.  And it only happens with XP as a client.

It's at the least a partial bypass of security because part of the point 
of the forced reauthentication is to get new keys.

> 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...

Unfortunately I don't have another AP to test at the moment.

-- 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/20051227/bc3c7afa/attachment.bin>