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@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@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900