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 ([EMAIL PROTECTED])
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
