EAP-Success = failure?

[Jouni Malinen]

On Tue, Jan 15, 2008 at 09:52:45AM -0500, Ryan M. Adamson wrote:

> We're running an Interlink RAD-series RADIUS server, v 6.1.4.  I'm using 
> the latest (stable) compiled source for both wpa_supplicant and madwifi 
> drivers.  Our access point is a Cisco Aironet 1200.  I've included the 
> debug logs of both wpa_supplicant and the RADIUS server.  It looks like 
> authentication on the radius end is working.

Yes, but wpa_supplicant expects PEAPv1 to be terminated with a protected
result notification at that point. Based on my test results with an
earlier version of Interlink server, it looked like this particular
configuration was actually working, so I'm not sure what would have
changed here. Maybe the newer server version removed that part of PEAPv1
for some reason or there is a configuration option for setting different
PEAP behavior (PEAPv1 has so many different, and incompatible, draft
versions that it is not even funny anymore..).

As a workaround, you could try forcing PEAPv0 to be used since that is
more likely to interoperate. You can do this by using phase1="peapver=0"
in the configuration block (replace the peaplabel=1 with this).

> EAP-PEAP: using label 'client EAP encryption' in key derivation

>          phase1="peaplabel=1"

These things do not match.. Did you use this exact configuration option
in the run that produced that debug output? peaplabel=1 is unlikely to
be used with this RADIUS server and if the EAP authentication had been
completed successfully, the derived key would have likely been incorrect
with peaplabel=1. The debug log above seems to indicate that peaplabel=1
was not used to force the new label string ("client PEAP encryption")..

-- 
Jouni Malinen                                            PGP id EFC895FA