pre-authentication to RSN AP through non-RSN AP

Jouni Malinen j
Wed Mar 10 14:08:29 PST 2010


On Mon, Mar 08, 2010 at 05:07:09PM -0800, Jason Young wrote:
> I'm testing pre-authentication with the 0.6.x supplicant and I've found that it
> does not work when the current AP is non-RSN (i.e. [WPA-EAP-TKIP]) and the
> preauth AP is RSN (i.e. [WPA2-EAP-CCMP-preauth]). The pre-authentication
> exchange does succeed according to the supplicant logs but the pmksa is never
> added to the pmksa cache because pmksa_cache_add (src/rsn_supp/pmksa_cache.c)
> is silently failing when the current protocol is not RSN. This problem does not
> happen with in 0.7.x because commit f5a51b58d4a78821cf28b99b54dc7addd0da34
> moves the protocol check into the caller but never added a check for the
> preauth case in rsn_preauth_eapol_cb (src/rsn_supp/preauth.c).

Interesting.. I do not remember whether the old behavior was by design
or not, but that particular commit was at least supposed to be a cleanup
change that would not change actual behavior..

> So my question is: which behavior is correct for pre-authentication? I don't
> see anything in the 802.11 spec that prevents preauthenticating to an RSN AP
> through a non-RSN AP.

I think this is undefined so both options could be considered "correct".
Anyway, it does not make much sense to go through the EAP authentication
and then drop the end result.

The standard does have a requirement for the current association:
pairwise keys must be "employed". Since IEEE 802.11 does not say
anything about WPA, this could be considered to refer to use of RSN..
Still, WPA can use pairwise keys and I don't think that there is any
critical need for strong data link encryption for the RSN
pre-authentication frames anyway.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list