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 ([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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
