dot1x specification EAPOL-Logoff clarification

[Arran Cudbard-Bell]

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 ?

---

2) On the termination of an EAP session, VLAN membership is usually 
altered, either to a MAC-Authorised VID a default unauthorised VID, or 
the port is blocked. Windows clients are pretty crap in terms of DHCP 
when this happens, and fail to renew their leases when moving between 
authorised and unauthorised states. Apple Mac clients however are very 
good in terms of DHCP dot1x integration. Unfortunately with EAP-Based 
and MAC-Based authentication transistions, DHCP renewal doesn't appear 
to work. This is what i've seen from the traces:

FRAME 6436 - TS 212.482482 - Assumed VLAN 603 - Actual VLAN 603 - EAPOL 
Logoff
FRAME 6440 - TS 212.484947 - Assumed VLAN Blocked (transistion) - Actual 
VLAN 603 - DHCP REQUEST
FRAME 6443 - TS 212.487252 - Assumed VLAN Blocked (transistion) - Actual 
VLAN 603 - DHCP ACK (Answered by server on 603)
FRAME 6454 - TS 212.529774 - Assumed VLAN 134 - Actual VLAN 134 - EAP 
Failure (Seems to denotate MAC Authentication succeeding)

So it appears after the supplicant sends the EAPOL-Logoff, the DHCP client attempts to get a lease very quickly; so quickly in fact that the switch hasn't altered the state of the port. The result being that the DHCP request is acked by the DHCP server on the dot1x authorised VLAN, the VLAN transistion *then* occurs, but as the DHCP client has satisfied itself that it has a valid lease for the PAE unauthorised state it doesn't renew the lease until it expires...

Should I be shouting at HP to get their switches to register the state change faster, or shouting at Apple to make their DHCP timings less agressive ?

Many Thanks,
Arran

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