dot1x specification EAPOL-Logoff clarification

[Artur Hecker]

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.

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.

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.


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

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 :-)


> Thanks for your input Artur.

Discussing standars is fun :-)



Thanks
artur