Hi
This is where it gets interesting. Just because the dot1x controlled port is in the closed state, it does not mean that another .1D bridge filter can't be open and allow traffic. HP et al have introduced (or are attempting) to introduce two tiered authentication, where the client is authenticated by MAC Address using RADIUS authentication, and then may 'Elevate' by sending an EAPOL-Start or Responding to an Ident Request. If the EAP session is terminated, with an EAP-Logoff then the client is Re- Authenticated with MAC-Based authentication.
Ok, this is something else once again. However, imo this is a very different problem. This is the integration of two tiers of a multi- tier access control. This cannot be within the scope of the standardization of any single access control type used here.
It is therefore up to the manufacturer to make sure that his solution is feasible, reliable and that it works. Just one other word: especially in multi-tier environment, there should be a precise distinction of different EAPOL packets. Thus, especially in this environment the signing of EAP-Logoff seems vital. Otherwise the outer tier could always send you a spoofed confirmation even though it never gave your Logoff to the inner tier, etc.
Anyway, it's a very different problem, out of scope of dot1X. What scope does this fall within ?!
The problem is not within the standard, but how to build a system out of several ones. From the standard point of view, I still think that not confirming EAPOL-Logoff is a valuable design choice. As opposed to not have signed it :-) I guess there is no standard which could reign over the application of other standards. These things are usually called "best practices". But I doubt there is one for multi-tier network access authentication with per-minute accounting :-)
I don't see how you could spoof EAPOL-Logoff packets in an encrypted wireless medium, unless you'd already cracked the WPA keys... You'd need to crack the unicast key for the target client....
Stop - the EAPOL packets are neither signed NOR encrypted, in any medium.
That's the whole problem I'm talking about. They are *not* data traffic, these are management frames, as defined by 802.1X (1 = management). They never go through TKIP, CCMP, WEP etc. Since MAC addresses cannot be encrypted neither by definition, you can safely take the source address of the user and send EAPOL Logoff on his behalf.
Woha, I didn't realise that ! Ok yes this could be a big issue.
Given the ease of this DDoS attack, I usually propose to ignore any EAP-Logoff altogether within the Authenticator PAE - if possible. As I said, this decision is up to the AuthServer. If the Session-Timeout is very short in respect to your Accounting intervals necessary for billing, I think you do not need to rely on it. artur