Hostapd / Macbook Pro 4-way handshake issue

[Jouni Malinen]

On Wed, Jul 19, 2006 at 06:14:20PM -0500, Michael Stevens wrote:
> Ta-Chien Lin sent us a link to a previous post at  
> http://lists.shmoo.com/pipermail/hostap/2006-May/013235.html. The patch there 
> fixes the problem but it appears hostapd is correct in sending out both IEs 
> according to Page 83/98 of the 802.11i spec.  
> http://standards.ieee.org/getieee802/download/802.11i-2004.pdf

Thanks for reminding me about this.. IEEE 802.11i does not actually say
much (well, anything) about WPA, since WPA is not part of any IEEE
standards. This topic has come up when test cases for WPA2 were being
developed and interoperability with WPA-only devices was considered.

Ideally, both IEs would be included in message 3/4, but unfortunately,
that can break connection with some old WPA implementations. This is the
reason for only sending WPA IE in case the client is requesting WPA, not
WPA2. However, similar stripping of WPA IE for WPA2 stations is not
done, since WPA2 clients are expected to be able to handle more than one
IE in the EAPOL-Key message 3/4. In WPA2/IEEE 802.11i, message 3/4
already includes two parts (RSN IE and Group Key KDE), so the parser
will need to be able to handle both.

> On Tuesday 18 July 2006 13:58, james woodyatt wrote:
> > On Thursday 13 July 2006 15:35, Michael Stevens wrote:
> > > We have determined that MacBook Pros connecting to hostapd 0.4.9
> > > have a problem with the 4-way handshake when wpa=3 (WPA and WPA2
> > > operation).
> >
> > Apple engineers are currently analyzing this problem report.
> > Regretfully, I can offer no other information at this time.  Read
> > into that whatever you will.  <sigh/>

Unfortunately, there may be supplicant implementations that do not
process key data field in EAPOL-Key message 3/4 in a way that would
ignore unknown IEs or in this case, maybe get confused with both RSN and
WPA IE being present. If Beacon and Probe Response frames include both
IEs, so should msg 3/4 (with the unfortunate exception of some old WPA
stations which require a workaround). I would rather not change hostapd
to strip these IEs unless it is justified by a large number of client
devices that do not handle both IEs here.

It would be interesting to see debug log from the supplicant to verify
why the message is being rejected. It could also be useful to verify
that the WPA and RSN IEs in Beacon and Probe Response frames are the
exact same ones as the ones hostapd is adding to the EAPOL-Key frames
3/4. I have not tested mixed mode (WPA + WPA2) with BSD, so I don't know
what exactly to wait there. Anyway, I remember some issues with madwifi
driver related to this kind of configuration since the driver was
generating its own IEs and hostapd happened to generate a list of
allowed ciphers in different order and one of the IEs could include an
optional field and the other one did not.

The key data field in EAPOL-Key message 3/4 of WPA2/IEEE 802.11i is
encrypted, so packet capture log alone is not enough to verify whether
the IEs are indeed matching. hostapd debug log should show the plaintext
contents of the field ("Plaintext EAPOL-Key Key Data") and that can then
be compared to the IEs in the Beacon/ProbeRsp frames.

-- 
Jouni Malinen                                            PGP id EFC895FA