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