dot1x specification EAPOL-Logoff clarification

[Artur Hecker]

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.

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.

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.



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