dot1x specification EAPOL-Logoff clarification

[Artur Hecker]

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