dot1x specification EAPOL-Logoff clarification

[Artur Hecker]

Hi Arran


>> well, there is a big difference: the EAP-Success (unsigned, *sigh*)  
>> is the confirmation necessary for supplicant to know if it proceeds  
>> or not (DHCP, data comm, etc). (By the way, it's difficult to  
>> compare: the EAP-Success is EAP, while EAPOL is dot1X). The EAPOL- 
>> Logoff is not necessary for anything. You send it before you stop  
>> communicating. You might just as well just stop communicating.
> Not true. From an accounting point of view the EAPOL-Logoff is  
> pretty vital to maintain accurate information about which users are  
> on which stations on which layer 2 network where. Sure a change in  
> state at the MAC level will terminate any active sessions on that  
> port, but a change in state at the MAC level doesn't always occur.
>
> I know RADIUS Accounting isn't related to EAP authentication in any  
> way, but nor is DHCP. At a protocol level there is no requirement  
> for the supplicant to signal the authenticator telling it, that it  
> wishes to end the session. But for all the other protocols that hang  
> off it, it is vital to have reliable state information.

Ok, accounting is a very different issue. You were talking about DHCP  
before, so I did not get it.

Actually, you speak about Accounting control: you want to be sure that  
the EAP-Logoff has been taken into account by the access controller  
and that presumably your access is not billed anymore. From my  
experience, this depends a lot on your billing plans, tariffs, models,  
etc. And precise per minute or byte accounting works rather badly with  
Radius... As you said, it is a completely different problem anyway.

By the way, in that situation, EAP-Logoff would need to be signed.  
Just as any reply...


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


>>>> Oops? If you ask me, the 802.1X/EAP were actually pushed and  
>>>> promoted to improve WiFi security, even if they have nothing to  
>>>> do with WiFi. WPA, WPA2/802.11i (i.e. both Enterprise and PSK)  
>>>> use EAPOL and are based on 802.1X (at least in part). All newer  
>>>> recommendations concerning WiFi security mention 802.1X access  
>>>> control and EAP for session opening. HOKEY, 802.11r etc. work on  
>>>> that too, etc.
>>
>> By the way, Ethernet *is* a shared medium. So, unless you have a  
>> completely switched wired LAN, you can always send EAP-Logoff  
>> (presumably with the wrong source MAC address) to anybody on your  
>> trunk. Even in switched LANs, depending on the architecture, there  
>> are possibilities to trick out the switches with poisoning,  
>> broadcasts, etc. EAP-Logoff should have been signed, at least  
>> optionally, especially if key material exists...
> We do have a completely switched wired LAN. One to One links from  
> the edge switches to the clients, switched all the way to the  
> core... Unless I misunderstood what you meant be switched.

ok.


> You can't broadcast EAPOL Logoff packets, if you do, they will be  
> ignored....

I didn't mean that you'd broadcast the EAPOL packet. You broadcast  
something under a wrong source MAC until some switch starts forwarding  
packets for this address to you. Then you can safely send out EAP- 
Logoff packets to the switch on the user's behalf, resulting in the  
closure of this session (this is DDoS). It does depend on the precise  
architecture though, e.g. where is the controller, is the first switch  
the access controller etc. It does not always work.


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



artur



>
>>
>> My personal perception is completely inverse to yours: I think that  
>> 802.1X is more used in wireless (WiFi) than in wired LANs. But  
>> maybe you have some statistics on that? That would be interesting  
>> to know :-)
> We have 3500 dot1x authenticated wired ports, and all of 11 wireless  
> access points running dot1x authentication... I've also found dot1x  
> to work far more reliably on a wired medium than wireless, and after  
> talking to others at Networkshop (Big networking conference) that is  
> the general consensus.
>>
>>
>>> Thanks for your input Artur.
>>
>> Discussing standars is fun :-)
>>
>>
> That is is
>>
>> Thanks
>> artur
> Thanks,
> Arran
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>
> -- 
> Arran Cudbard-Bell (A.Cudbard-Bell at sussex.ac.uk)
> Authentication, Authorisation and Accounting Officer
> Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton
> EXT:01273 873900 | INT: 3900
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html