EAP-TLS - Authentication succeeds with in-correct "private_key_passwd"
saurav.barik at gmail.com
Wed Oct 13 10:57:33 EDT 2010
I ran wpa_supplicant with -dd option and attached is the log.
logoff/logon is trying to reauth, but couple of places I see it uses
old-successful-config-data if fast_reauth is enabled. I disabled
fast_reauth in my config but it did not help(new credentials such as
"private_key_passwd" are not validated again, as part of reauth).
On Sun, Oct 10, 2010 at 12:17 PM, Jouni Malinen <j at w1.fi> wrote:
> On Sun, Oct 10, 2010 at 12:19:15AM +0530, saurav barik wrote:
>> I disabled fast_reauth in my conf file(fast_reauth=0). Then I changed
>> wpa_supplicant conf file with wrong certificates and triggerred logoff
>> followed by logon from wpa_cli. Immediately I could ping the AP
>> successfully(with wrong certificates). So I am not too sure whether
>> the reauthentication really happened. I also tried doing a reassociate
>> after logon. But in all the cases the ping to the AP was successful
>> with wrong certs. If logoff/logon causes a reauth then why should the
>> port get enabled with wrong certs? If PMKSA does not have anything to
>> do with this behavior, I really don't have any issues with it. I am
>> just concerned about the station still able to successfully connect to
>> the AP (via wpa-eap) with wrong credentials.
> Please take a look at wpa_supplicant debug log (run it with -dd on
> command line) and see what happens between logoff and logon. Please also
> keep in mind that the station may not actually have any IEEE 802.1X port
> control, so this behavior may depend on the AP side only (i.e., if it
> does not implement 802.1X correctly, the connection could still
> Jouni Malinen PGP id EFC895FA
> HostAP mailing list
> HostAP at lists.shmoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 13308 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20101013/f6901e60/attachment-0001.rtf
More information about the HostAP