dot1x specification EAPOL-Logoff clarification

Wed Apr 30 15:40:00 CEST 2008

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 speciﬁed in this clause if 
and only if the following
conditions are all true:
a) The Destination MAC address ﬁeld contains the PAE group address, as 
speciﬁed in 7.8 (in non-
shared media LANs), or the speciﬁc MAC address of the PAE (in shared 
media LANs).
b) The PAE Ethernet Type ﬁeld contains the value of the PAE Ethernet 
Type, as speciﬁed in 7.8.
c) The Packet Type ﬁeld contains one of the values EAP-Packet, 
EAPOL-Start, EAPOL-Logoff, or
EAPOL-Key, as speciﬁed 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 at sussex.ac.uk)
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08 
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900