WPA-Enterprise and wpa_supplicant/hostapd

[Cristian Ionescu-Idbohrn]

On Mon, 19 Sep 2005, Jouni Malinen wrote:

> On Mon, Sep 19, 2005 at 08:22:20PM +0200, Cristian Ionescu-Idbohrn wrote:
>
> > I noticed a simmilar problem with the wired driver.  The senario
> > is like this:
> >
> > * the wired supplicant connected to a cisco switch
> > * wpa_supplicant is started and authenticates
>
> Actually, I would guess that it did not complete authentication..

And you are, of course, correct.

> You can check this with, e.g., 'wpa_cli sta'.

,----
| # wpa_cli sta
| Selected interface 'eth0'
| bssid=01:80:c2:00:00:03
| ssid=
| pairwise_cipher=NONE
| group_cipher=NONE
| key_mgmt=IEEE 802.1X (no WPA)
| wpa_state=ASSOCIATED
| ip_address=1.2.3.4
| Supplicant PAE state=AUTHENTICATING
| suppPortStatus=Unauthorized
| EAP state=SUCCESS
| selectedMethod=13 (EAP-TLS)
| EAP TLS cipher=AES256-SHA
`----

The thing is 'EAP state=SUCCESS' seems to be enough. Got a green light
on the switch port and I can talk to the box plugged in there.

> > * the switch opens the port
> > * now I take the supplicant plug out from the switch port
> > * wait a second and plug it back in
> > * the switch sends a EAP-Request (as it is supposed to)
>
> This part can be replaced with anything that triggers
> re-authentication (for people like me who do not happen to have an
> 802.1X enabled wired switch at home ;-).
>
> > * the supplicant can't mannage to reauthenticate
>
> I saw this in my own test setup with driver_wired and was somewhat
> surprised since re-authentication has worked fine before. This ended
> up being a configuration error, though, and taken into account that
> I needed to look at the source code to figure this out, I would
> guess that this is not very well documented and you are likely to
> have same reason for the re-authentication failing..
>
> I would guess that you are leaving eapol_flags to its default value
> which is 3, i.e., require that EAPOL-Key are used to send keying
> material..

And you are, of course, correct again.

> This is not usually used with wired networks and as such,
> wpa_supplicant just gets stuck waiting for EAPOL-Key packets. This
> is otherwise valid behavior, but I would agree that it is a bug if
> there is no timeout on that state..

Fixable bug?

> And to fix this, just set eapol_flags=0 in the network block and
> re-authentication should work even with the wired driver.

Confirmed. 'eapol_flags=0' sorted that out. And the status looks a bit
different:

,----
| # wpa_cli sta
| Selected interface 'eth0'
| bssid=01:80:c2:00:00:03
| ssid=
| pairwise_cipher=NONE
| group_cipher=NONE
| key_mgmt=IEEE 802.1X (no WPA)
| wpa_state=COMPLETED
| ip_address=1.2.3.4
| Supplicant PAE state=AUTHENTICATED
| suppPortStatus=Authorized
| EAP state=SUCCESS
| selectedMethod=13 (EAP-TLS)
| EAP TLS cipher=AES256-SHA
`----

Thanks for the insites.

But, if I now run (cvs 20050920 snapshot):

  # wpa_cli reconfigure

(no configuration changes) the supplicant will send a 'EAPOL Start',
the switch will answer with 2 'EAP Request, Identity' (30 s interval),
followed by a 'EAP Failure' cycle, repeated forever. So it seams the
'reconfigure' puts the supplicant in 'EAP state=CONFUSION' ;-) It does
not reauthenticate. Last known status:

,----
| # wpa_cli sta
| Selected interface 'eth0'
| bssid=01:80:c2:00:00:03
| wpa_state=ASSOCIATED
| ip_address=1.2.3.4
| Supplicant PAE state=AUTHENTICATING
| suppPortStatus=Unauthorized
| EAP state=IDLE
`----


Cheers,
Cristian