dot1x specification EAPOL-Logoff clarification

[Arran Cudbard-Bell]

Artur Hecker wrote:
> 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.
It's all part of the same problem.
>
> 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.
What scope does this fall within ?!
>
>
>>>>> 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.
Surely the there's a different Authenticator instance for each physical 
port, so a logoff received by one Authenticator instance would not be 
honoured if it could not find a session matching the source Mac existing 
on that instance.
>
>
>> 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.
>
> 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
>
> -
> 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