On Wed, Oct 14, 2015 at 12:26:33PM +0300, Ilan Peer wrote:
> Some APs may send RSC octets in EAP message 3 of 4-Way Handshake or in
> EAP message 1 of Group Key Handshake in the opposite order. Thus, after a
> successful EAP authentication the TSC values of received multicast packets,
> such as DHCP, don't match the RSC one and as a result these packets are
> dropped on replay attack TSC verification. An example of such AP is
> Sapido RB-1732.
>
> Workaournd this by setting RSC octets to 0 on GTK installation if the AP
> RSC value is identified as a potentially having the byte order issue.
> The wpa_rsc_relaxation global configuration property allows to disable
> the GTK RSC workaround if it's not needed.
Thanks, applied with some fixes and cleanup.
> +static int wpa_supplicant_get_wpa_rsc_relaxation(const struct wpa_sm *sm)
> +{
> + if (sm->ctx->get_wpa_rsc_relaxation)
> + return sm->ctx->get_wpa_rsc_relaxation(sm->ctx->ctx);
> + return 0;
> +}
There is no need to add a separate function pointer and callback for
this; there is already a mechanism for updating WPA/RSN configuration
parameters for each connection. I replaced this callback mechanism with
a new such configuration parameter.
> +static int wpa_supplicant_rsc_relaxation(const struct wpa_sm *sm,
> + const u8 *rsc)
> +{
> + int rsclen;
> +
> + if (wpa_supplicant_get_wpa_rsc_relaxation(sm))
> + return 0;
This logic looks reversed, i.e., that needs to be "if
(!wpa_supplicant_get_wpa_rsc_relaxation(sm))"..
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
