EAP-TLS - Authentication succeeds with in-correct "private_key_passwd"
Christ Schlacta
aarcane
Thu Oct 7 16:41:06 PDT 2010
If a cert is changed it almost always means a cert has been installed
to the wrong place and must now be revoked. The revocation of the old
cert will trigger a failure and a proper reauthentication. For the
other 1 percent or less of the time restarting the supplicant is
sufficient. Also, can we mov the pmksa cache onto disk to speed up
restarting and rebooting ?
Sent from my iPhone
On Oct 7, 2010, at 12:22, saurav barik <saurav.barik at gmail.com> wrote:
> I agree - PMKSA caching is a good feature. But it should not force to
> skip the need for a reauth. A user might try to change his TLS
> certificates/password at the run-time and edit the wpa_supplicant.conf
> for the new configs. In this case, wpa_supplicant should have a
> provision to start a reauth session because the certificates are
> changed. In this case user is not breaking a working config - he just
> wants to use new configuration. As of now, the only way the new config
> can take effect is by restarting the running wpa_supplicant. Would not
> it be better, if we can have a similar mechanism with a running
> wpa_supplicant?
>
> If we need to re-run wpa_supplicant every time TLS certs are changed,
> then logon/logoff options from wpa_cli is redundant. Please correct me
> if I am wrong.
>
> Thanks,
> Saurav
>
> On Fri, Oct 8, 2010 at 12:33 AM, Christ Schlacta <aarcane at gmail.com>
> wrote:
>> An inability to break a working config is hardly a bug. PMKSA
>> should
>> never flush unless it's failed, and flushing any sooner, or forcing
>> re-authentication sooner is wasteful of bandwidth and other
>> resources.
>> This should be classified as a feature, not as a bug.
>>
>> On 10/7/2010 11:59 AM, saurav barik wrote:
>>> Yes, logoff followed by logon also skips reauth. I tried forcing a
>>> reauth using eapol_sm_request_reauth() in "logon" path. Still it
>>> does
>>> not reauth. I am wandering whether it should be considered as a
>>> known-issue in wpa_supplicant or is this behavior acceptable. I
>>> believe wpa_supplicant should reauthenticate if there is a change in
>>> EAP-TLS related config. Should I flush PMKSA caching in logon path
>>> as
>>> well? Is there any command-line config option(from wpa_cli) for it?
>>>
>>> Please advise.
>>>
>>> Thanks,
>>> Saurav
>>>
>>> On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen<j at w1.fi> wrote:
>>>> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>>>>> Is there any way to trigger a forced reauthentication from a
>>>>> running
>>>>> wpa_supplicant? wpa_cli config options does not have it.
>>>> When using IEEE 802.1X/EAP, logoff follow by logon would do this
>>>> without
>>>> reassociation and reassociate will do this in all security modes
>>>> (though, PMKSA caching may be used to skip EAP authentication in
>>>> that
>>>> case).
>>>>
>>>> --
>>>> Jouni Malinen PGP id
>>>> EFC895FA
>>>> _______________________________________________
>>>> HostAP mailing list
>>>> HostAP at lists.shmoo.com
>>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>>>
>>> _______________________________________________
>>> HostAP mailing list
>>> HostAP at lists.shmoo.com
>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>>
More information about the Hostap
mailing list