Artur Hecker wrote:
hi
just one comment.
On 30 Apr 2008, at 10:59, Arran Cudbard-Bell wrote:
Artur Hecker wrote:
Hi Arran
In my eyes, the fact that it is not confirmed is a minor issue. It's probably a reasonable design choice: as you said, the controlled port at the Auth may be in the authorized state, while the client might think that is unauthorized, so what? This can happen at any time anyway, e.g. in wireless when the connection suddenly drops. Besides, in practice most Supplicants won't bother sending anything at all: what if the NIC was suddenly unplugged by the user? What if the PC has crashed? What if it was unpowered, etc etc etc. Agreed. I guess I was looking at it more in terms of integration. It's more about the supplicant knowing when it's state has been reflected by the authenticator. This is done when the supplicant authenticates, the EAP-Success is confirmation that the Authenticator PAE is in the authorised state. But not when the supplicant forcefully disconnects with an EAPOL-Logoff.
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.
If you want to restart, you simply resend the EAPOL Start in either case. It changes nothing.
In any case, confirmed or not, every Authenticator *must* be prepared for such a situation. By the way, it is in no way against its policy, since it is not up to the supplicant (=client) to decide when the network access port is to be opened and when it is to be closed. This decision is up to the AuthServer, which has supposedly issued a positive decision as to the controlled port in question being open at this very moment. These differences in PAE state can cause issues when attempting to use the supplicant PAE state to control the state of other 'Zero-Configuration' networking clients like DHCP. If the EAPOL Logoff message were confirmed by the Authenticator, this could be a used trigger DHCP lease acquisition. The IEEE 802.1x 2004 document does mention DHCP integration briefly, which is why I'm surprised they didn't think to provision for it here.
Why? DHCP only depends on EAP-Success, but certainly not on EAP-Logoff. I think that I do not understand your issue: you cannot send ANY DHCP messages after EAP-Logoff has succeeded, it's too late. The controlled port at the L2 will be closed. DHCP is L3 data going over the controlled port. If you want to do any integration, you could drop your DHCP lease but *before* closing the controlled port. 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.
I'm guessing this is implemented with two .1D bridge port entities operating on the same physical port, but i'm not sure.... 1. Physical connection to the port 2. Authenticated on MAC Using RADIUS - Mac Auth Session Starts 2a. MAC State change signals DHCP client 2b. DHCP Request 2c. Got DHCP Lease on MAC-Auth VLAN 3. Authenticated using dot1x - Mac Auth Session Ends - dot1x Session begins 3a. Supplicant signals DHCP client 3b. DHCP Request 3c. Got DHCP Lease on dot1x-Auth VLAN 4. EAP-Session Ends (EAPOL-Logoff) 4a. Supplicant signals DHCP client (too quickly) 4b. DHCP Request 4c. Got DHCP Lease on dot1x-Auth VLAN 5. Authenticated on MAC Using RADIUS - Mac Auth Session Starts 5a. DHCP client satisfied at 4c, station now bogon on MAC-Auth VLAN 6 Physical Disconnection - Mac Auth Session ends See the problem is at 4a, the DHCP client has no way of knowing when the Authenticator has honoured the EAP Session termination, and so has no way of knowing when the EAPOL-Logoff was actually honoured.
Imo, there are no dependencies between DHCP and dot1X. And if they exist, they follow the other sense: DHCP is transported by the L2 channel opened by dot1X. So, you need to open the session before starting DHCP and you might want to terminate DHCP leases etc. before sending Logoff (even it this seems completely unnecessary, it will expire anyway). In any case, I do not see why Logoff needs to be confirmed, sorry.
See above.
Actually I would rather complain about other issues with EAP-Logoff. For instance, it is not authenticated/signed, so it is a perfect DDoS possibility.
Not really. The only situation in which I could see EAP-Logoff being used as a DDoS attack is in a shared media wired LAN, and not many people implement shared media wired LANs with dot1x authentication... it's also fairly hard to tap a wired LAN between the supplicant and the NAS without someone noticing.
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.
You can't broadcast EAPOL Logoff packets, if you do, they will be ignored.... 7.5.7 Validation of received EAPOL MPDUs and EAPOL protocol version handling A PAE shall process a received EAPOL MPDU as specified in this clause if and only if the following conditions are all true: a) The Destination MAC address field contains the PAE group address, as specified in 7.8 (in non- shared media LANs), or the specific MAC address of the PAE (in shared media LANs). b) The PAE Ethernet Type field contains the value of the PAE Ethernet Type, as specified in 7.8. c) The Packet Type field contains one of the values EAP-Packet, EAPOL-Start, EAPOL-Logoff, or EAPOL-Key, as specified in 7.5.4. I think A is the important one there .... In a shared media wired LAN, you can spoof the source MAC, and send an EAPOL-Logoff to terminate another clients session on your physical LAN segment. So yes, validation with keying material would be useful here... however not all EAP types generate keying material... Poisoning is an interesting one but I don't think that's possible either. 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....
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