dot1x specification EAPOL-Logoff clarification

[Arran Cudbard-Bell]

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

Unless a wireless AP would accept unencrypted packets from a station 
*after* the WPA four way handshake had been completed; i'm not really 
familiar enough with 802.11 to know...

Thanks for your input Artur.

Arran

> Artur
>
>
>
>
> On 29 Apr 2008, at 18:50, Arran Cudbard-Bell wrote:
>
>> Arran Cudbard-Bell wrote:
>>> Hi,
>>>
>>> Having some interesting issues with a HP ProCurve 2510 an Apple Mac 
>>> Power Book running OSX 10.5.2, and MAC-Auth + EAP-Auth on the same 
>>> wired port.
>>>
>>> I know this isn't strictly the list for this as this isn't really 
>>> RADIUS, but i'm not sure where to post...
>>>
>>> Two questions:
>>>
>>>   IEE802.1x-2004
>>>       8.1.3 EAPOL-Logoff
>>>       When a Supplicant wishes the Authenticator PAE to perform a 
>>> logoff (i.e., to set the controlled Port state to
>>>       unauthorized), the Supplicant PAE originates an EAPOL-Logoff 
>>> message (see 7.5.4) to the Authenticator
>>>       PAE. As a result, the Authenticator PAE immediately places the 
>>> controlled Port in the unauthorized state
>>>
>>> 1) It appears in the spec that there is no requirement or indeed 
>>> method of the Supplicant PAE of confirming that the EAPOL-Logoff has 
>>> been honoured. So the supplicant PAE could be in the unauthorised 
>>> state while the Authenticator could be in the authorised state. Is 
>>> this an over site of the dot1x spec, or is this meant to be handled 
>>> at a higher level with EAP ?
>> Sorry. Looking at the diagrams in 8-5 it appears my suspicion is 
>> correct. Unless a re-auth timer is implemented by the Authenticator 
>> PAE, this mismatched authentication state could persist indefinitely.
>>
>> The EAPOL-LOGOFF frame is *not* retransmitted to the Authentication 
>> server... and the Authenticator PAE does not respond to EAPOL-LOGOFF 
>> frames, it just alters it's state. So if the EAPOL-LOGOFF frame was 
>> lost in transit... damn, why no EAPOL-LOGOFF-CONFIRMATION packet ... 
>> In every other part of the EAP/dot1x spec a request *should* always 
>> be answered by a response... but not here... are these guys idiots, 
>> or am I being dense ?!
>>
>> See this would solve the issue in question 2 perfectly.
>>
>>
>> -- 
>> 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