Hello!
I switched on 802.11w on my AP (rt2860) in hostapd with ieee80211w=1 and
in wpa_supplicant with ieee80211w=2 (ath9k). key_mgmt is WPA-EAP (TLS) /
CCMP for both pairwise and group.
On both machines, compat-wireless-2012-04-26 (or
compat-wireless-3.4-rc3) is running.
Directly after authorization, dhcp is started and therefore the opening
of the BA session is started by the AP but times out because of no
answer of the supplicant:
AP:
[63010.267285] Open BA session requested for 48:5d:60:33:aa:11 tid 0
[63010.279073] activated addBA response timer on tid 0
[63011.280107] addBA response timer expired on tid 0
[63011.280134] Tx BA session stop requested for 48:5d:60:33:aa:11 tid 0
[63011.289149] Stopping Tx BA session for 48:5d:60:33:aa:11 tid 0
[63013.270550] Open BA session requested for 48:5d:60:33:aa:11 tid 0
[63013.285059] activated addBA response timer on tid 0
[63014.288104] addBA response timer expired on tid 0
[63014.288130] Tx BA session stop requested for 48:5d:60:33:aa:11 tid 0
[63014.301131] Stopping Tx BA session for 48:5d:60:33:aa:11 tid 0
The ath9k supplicant gets the BA session request, but times out, too:
[75492.707613] Open BA session requested for ec:2c:69:57:01:dd tid 0
[75492.718195] activated addBA response timer on tid 0
[75493.719577] addBA response timer expired on tid 0
[75493.719633] Tx BA session stop requested for ec:2c:69:57:01:dd tid 0
[75493.728655] Stopping Tx BA session for ec:2c:69:57:01:dd tid 0
[75495.709051] Open BA session requested for ec:2c:69:57:01:dd tid 0
[75495.720317] activated addBA response timer on tid 0
[75496.721801] addBA response timer expired on tid 0
[75496.721825] Tx BA session stop requested for ec:2c:69:57:01:dd tid 0
[75496.730775] Stopping Tx BA session for ec:2c:69:57:01:dd tid 0
[75496.731299] Open BA session requested for ec:2c:69:57:01:dd tid 0
[75496.743795] activated addBA response timer on tid 0
[75497.745162] addBA response timer expired on tid 0
[75497.745198] Tx BA session stop requested for ec:2c:69:57:01:dd tid 0
[75497.754246] Stopping Tx BA session for ec:2c:69:57:01:dd tid 0
[75497.754775] Open BA session requested for ec:2c:69:57:01:dd tid 0
[75497.755097] Open BA session requested for ec:2c:69:57:01:dd tid 0
[75497.755102] BA request denied - session is not idle on tid 0
I can see in the air trace, that the supplicant seems to answer fine to
the BA request of the AP, but the AP seems not to understand the package.
It looks like this (AP), if it's working fine (w/o 802.11n):
[62405.350620] Open BA session requested for 48:5d:60:33:aa:11 tid 0
[62405.364062] activated addBA response timer on tid 0
[62405.365389] Rx A-MPDU request on tid 0 result 0
[62405.365644] switched off addBA timer for tid 0
[62405.365648] Aggregation is on for tid 0
The deauth request from wpa_supplicant -> AP isn't recognized on the AP,
too.
Any idea?
Thanks,
kind regards,
Andreas
Andreas Hartmann wrote:
> On Mon, May 07 2012 at 07:11:31 +0200
> Andreas Hartmann <[email protected]> wrote:
>
>> Hello!
>>
>> I switched on 802.11w on my AP (rt2860) in hostapd with ieee80211w=1 and
>> in wpa_supplicant with ieee80211w=2 (ath9k). key_mgmt is WPA-EAP (TLS) /
>> CCMP for both pairwise and group.
>>
>> On both machines, compat-wireless-2012-04-26 (or
>> compat-wireless-3.4-rc3) is running.
>>
>> Directly after authorization, dhcp is started and therefore the opening
>> of the BA session is started by the AP but times out because of no
>> answer of the supplicant:
>
> [...]
>
>>
>> The deauth request from wpa_supplicant -> AP isn't recognized on the AP,
>> too.
>
> Meanwhile, I found the reason (I forgot to take care of hostapd's
> logfile - I would have expected an error message from the driver in
> messages, too :-)):
>
> AP (hostapd.log):
> ...
> 1336372202.462946: WPA: 48:5d:60:3e:a3:18 WPA_PTK entering state INITIALIZE
> 1336372202.462965: wpa_driver_nl80211_set_key: ifindex=17 alg=0 addr=0x673d40 key_idx=0 set_tx=1 seq_len=0 key_len=0
> 1336372202.462977: addr=48:5d:60:3e:a3:18
> 1336372202.462999: WPA: 48:5d:60:3e:a3:18 WPA_PTK_GROUP entering state IDLE
> 1336372202.463007: WPA: 48:5d:60:3e:a3:18 WPA_PTK entering state AUTHENTICATION
> 1336372202.463018: WPA: 48:5d:60:3e:a3:18 WPA_PTK entering state AUTHENTICATION2
> 1336372202.463025: WPA: Re-initialize GMK/Counter on first station
> 1336372202.463896: GMK - hexdump(len=32): [REMOVED]
> 1336372202.464771: Key Counter - hexdump(len=32): [REMOVED]
> 1336372202.465639: GTK - hexdump(len=16): [REMOVED]
> 1336372202.466502: IGTK - hexdump(len=16): [REMOVED]
> 1336372202.466524: wpa_driver_nl80211_set_key: ifindex=17 alg=3 addr=0x44fbbe key_idx=1 set_tx=1 seq_len=0 key_len=16
> 1336372202.466539: broadcast key
> 1336372202.478318: wpa_driver_nl80211_set_key: ifindex=17 alg=4 addr=0x44fbbe key_idx=4 set_tx=1 seq_len=0 key_len=16
> 1336372202.478349: broadcast key
> 1336372202.478389: nl80211: set_key failed; err=-22 Invalid argument)
> ....
> 1336372202.529973: wlan0: STA 48:5d:60:3e:a3:18 IEEE 802.1X: authenticated - EAP type: 13 (TLS)
>
>
> But there are some questions open anyway:
>
> - Why is the authentication started here at all, regardless of an error?
> - Why does TLS succeed? (802.11g is "working").
> - Why does set_key fail?
>
>
> I'm getting the same error, regardless if nohwcrypt is enabled for
> rt2800pci or not.
The attached patch seems to enable 802.11w for rt2800pci (AP). It does
not work for rt2800usb (rt3572 SUPP), even if the set_key error
disappears (originally the flag IEEE80211_HW_MFP_CAPABLE was set
unconditionally).
I can't say, if it works with all rt2800pci devices and I can't say, if
it works with rt2800pci device used as supplicant.
Tested (incl. PTK rekeying) with ath9k supplicant. Deauthentication does
work fine, too. I couldn't test, if using more then one supplicant at
the same time, does work, too.
Legacy driver (rt5572sta) seems to not support 802.11w at all (with
ralink driver). Even if ieee80211w=2 in supplicant.conf is enabled, it
uses plain text management frames.
Regards,
Andreas Hartmann
Hello Jouni,
thanks for your response!
Jouni Malinen wrote:
> On Mon, May 07, 2012 at 09:02:58AM +0200, Andreas Hartmann wrote:
>> - Why is the authentication started here at all, regardless of an error?
>
> I don't think that hostapd would verify driver capabilities for 802.11w
> at the moment, so it does not know that it should have rejected the
> configuration here.. Same for wpa_supplicant and station mode, I'd
> guess.
Wouldn't it be better, if it would stop processing completely? I was
surprised to have a half working connection :-).
[...]
Kind regards,
Andreas Hartmann
On Mon, May 07, 2012 at 04:16:18PM +0200, Andreas Hartmann wrote:
> Jouni Malinen wrote:
> > I don't think that hostapd would verify driver capabilities for 802.11w
> > at the moment, so it does not know that it should have rejected the
> > configuration here.. Same for wpa_supplicant and station mode, I'd
> > guess.
>
> Wouldn't it be better, if it would stop processing completely? I was
> surprised to have a half working connection :-).
Sure, it would be good to verify driver capabilities before even
starting the BSS as AP or trying to associate with 802.11w as station.
--
Jouni Malinen PGP id EFC895FA
On Mon, May 07, 2012 at 01:04:29PM +0200, Helmut Schaa wrote:
> I'm fine with enabling MFP in rt2800pci but I don't know enough about the
> necessary requirements.
>
> Jouni, are there any special requirements for MFP?
The main requirements:
- support CCMP encryption/decryption of unicast robust management frames
(subset of Action frames, Deauthentication, Disassociation)
- support BIP and IGTK configuration for group addressed robust
management frames (TX-only for AP, RX-only for STA); I would expect
most drivers to use software implementation on the host CPU for this
taken into account that there is only very limited use of group
addressed robust management frames
- SA Query mechanism (mac80211-based drivers get this pretty much
automatically from hostapd for AP mode and mac80211 for STA)
- ability to configure RSN capabilities into RSN element and to
provide the received element to user space (again, most mac80211-based
drivers should work as-is)
--
Jouni Malinen PGP id EFC895FA
On Mon, May 07 2012 at 07:11:31 +0200
Andreas Hartmann <[email protected]> wrote:
> Hello!
>
> I switched on 802.11w on my AP (rt2860) in hostapd with ieee80211w=1 and
> in wpa_supplicant with ieee80211w=2 (ath9k). key_mgmt is WPA-EAP (TLS) /
> CCMP for both pairwise and group.
>
> On both machines, compat-wireless-2012-04-26 (or
> compat-wireless-3.4-rc3) is running.
>
> Directly after authorization, dhcp is started and therefore the opening
> of the BA session is started by the AP but times out because of no
> answer of the supplicant:
[...]
>
> The deauth request from wpa_supplicant -> AP isn't recognized on the AP,
> too.
Meanwhile, I found the reason (I forgot to take care of hostapd's
logfile - I would have expected an error message from the driver in
messages, too :-)):
AP (hostapd.log):
...
1336372202.462946: WPA: 48:5d:60:3e:a3:18 WPA_PTK entering state INITIALIZE
1336372202.462965: wpa_driver_nl80211_set_key: ifindex=17 alg=0 addr=0x673d40 key_idx=0 set_tx=1 seq_len=0 key_len=0
1336372202.462977: addr=48:5d:60:3e:a3:18
1336372202.462999: WPA: 48:5d:60:3e:a3:18 WPA_PTK_GROUP entering state IDLE
1336372202.463007: WPA: 48:5d:60:3e:a3:18 WPA_PTK entering state AUTHENTICATION
1336372202.463018: WPA: 48:5d:60:3e:a3:18 WPA_PTK entering state AUTHENTICATION2
1336372202.463025: WPA: Re-initialize GMK/Counter on first station
1336372202.463896: GMK - hexdump(len=32): [REMOVED]
1336372202.464771: Key Counter - hexdump(len=32): [REMOVED]
1336372202.465639: GTK - hexdump(len=16): [REMOVED]
1336372202.466502: IGTK - hexdump(len=16): [REMOVED]
1336372202.466524: wpa_driver_nl80211_set_key: ifindex=17 alg=3 addr=0x44fbbe key_idx=1 set_tx=1 seq_len=0 key_len=16
1336372202.466539: broadcast key
1336372202.478318: wpa_driver_nl80211_set_key: ifindex=17 alg=4 addr=0x44fbbe key_idx=4 set_tx=1 seq_len=0 key_len=16
1336372202.478349: broadcast key
1336372202.478389: nl80211: set_key failed; err=-22 Invalid argument)
....
1336372202.529973: wlan0: STA 48:5d:60:3e:a3:18 IEEE 802.1X: authenticated - EAP type: 13 (TLS)
But there are some questions open anyway:
- Why is the authentication started here at all, regardless of an error?
- Why does TLS succeed? (802.11g is "working").
- Why does set_key fail?
I'm getting the same error, regardless if nohwcrypt is enabled for
rt2800pci or not.
Thanks for your advice,
kind regards,
Andreas Hartmann
On Tue, 2012-05-08 at 08:28 +0200, Andreas Hartmann wrote:
> This means for rt2x00: to get 11w working with hw encryption enabled,
> there needs to be some differentiation for the encryption of management
> frames: if management frame, let mac80211 do the job - all other frames
> should be encrypted by hw.
> Correct?
That might not be sufficient -- you might have control over TX, but if
the hardware attempts to decrypt encrypted mgmt frames you're out of
luck entirely.
johannes
On Mon, May 07, 2012 at 09:02:58AM +0200, Andreas Hartmann wrote:
> - Why is the authentication started here at all, regardless of an error?
I don't think that hostapd would verify driver capabilities for 802.11w
at the moment, so it does not know that it should have rejected the
configuration here.. Same for wpa_supplicant and station mode, I'd
guess.
> - Why does TLS succeed? (802.11g is "working").
If you are using SHA-1 -based AKM, the initial association, 4-way
handshake, and data TX/RX are almost identical..
> - Why does set_key fail?
The driver did not support configuration of IGTK for BIP (i.e., key to
protect group-addressed robust management frames).
--
Jouni Malinen PGP id EFC895FA
On Tue, 2012-05-08 at 09:22 +0200, Andreas Hartmann wrote:
> Johannes Berg wrote:
> > On Tue, 2012-05-08 at 08:28 +0200, Andreas Hartmann wrote:
> >
> >> This means for rt2x00: to get 11w working with hw encryption enabled,
> >> there needs to be some differentiation for the encryption of management
> >> frames: if management frame, let mac80211 do the job - all other frames
> >> should be encrypted by hw.
> >> Correct?
> >
> > That might not be sufficient -- you might have control over TX, but if
> > the hardware attempts to decrypt encrypted mgmt frames you're out of
> > luck entirely.
>
> This means, that if hw encryption is enabled, the encryption must be
> done entirely by hw (because of rx) and therefore, MFP must be supported
> by hardware (does Ralink support MFP?)? Or is there a possibility to
> tell the hardware not to decrypt some types of frames even if they are
> encrypted?
How would I know? This is all hardware questions :)
johannes
Hi,
On Mon, May 7, 2012 at 12:17 PM, Andreas Hartmann
<[email protected]> wrote:
> The attached patch seems to enable 802.11w for rt2800pci (AP). It does
> not work for rt2800usb (rt3572 SUPP), even if the set_key error
> disappears (originally the flag IEEE80211_HW_MFP_CAPABLE was set
> unconditionally).
I'm fine with enabling MFP in rt2800pci but I don't know enough about the
necessary requirements.
Jouni, are there any special requirements for MFP?
Thanks,
Helmut
Hi Jouni, hi Helmut,
Jouni Malinen wrote:
> On Mon, May 07, 2012 at 01:04:29PM +0200, Helmut Schaa wrote:
>> I'm fine with enabling MFP in rt2800pci but I don't know enough about the
>> necessary requirements.
>>
>> Jouni, are there any special requirements for MFP?
>
> The main requirements:
> - support CCMP encryption/decryption of unicast robust management frames
> (subset of Action frames, Deauthentication, Disassociation)
I tested WPA-EAP-SHA256 with group key ccmp.
> - support BIP and IGTK configuration for group addressed robust
> management frames (TX-only for AP, RX-only for STA); I would expect
> most drivers to use software implementation on the host CPU for this
> taken into account that there is only very limited use of group
> addressed robust management frames
The IGTK is a single key (shared key). There are a maximum of 4 shared
keys designated in rt2x00mac.c for each BSS for use with hw encryption.
Since rt2800usb is working fine with nohwcrypt=1 (but not with
encryption done in hw), I assume, that there is no differentiation
between the encryption / decryption of different frame types. If hw
encryption is turned on, all types of frames are encrypted / decrypted
by hardware and vice versa.
I'm not sure how BIP is secured if hw encryption is enabled. BIP is
implemented in mac80211 as part of decryption. Is BIP done during hw
encryption, too? Or is it done by mac80211 w/ enabled hw encryption, too?
Grrr. Now I know, why I had to disable hw encryption for rt2800usb.
Because it was disabled for rt2800pci (AP), too. If mac80211 is doing
the job, 11w works fine. If encryption is done by hardware (AP), 11w is
broken: the ath9k station doesn't work any more, regardless if hw
encryption is switched on or off for ath9k.
11w rt2800pci (AP) ath9k sta rt2800usb sta
---------------------------------------------------------------------
1,3 nohwcrypt=1 nohwcrypt=[0|1] nohwcrypt=1
2,4 nohwcrypt=0 nohwcrypt=[0|1] nohwcrypt=1
2,5 nohwcrypt=0 nohwcrypt=[0|1] nohwcrypt=0
1 = ath9k fine
2 = ath9k broken
3 = rt2800usb fine
4 = rt2800usb broken
5 = rt2800usb seems to work
This means for rt2x00: to get 11w working with hw encryption enabled,
there needs to be some differentiation for the encryption of management
frames: if management frame, let mac80211 do the job - all other frames
should be encrypted by hw.
Correct?
> - SA Query mechanism (mac80211-based drivers get this pretty much
> automatically from hostapd for AP mode and mac80211 for STA)
> - ability to configure RSN capabilities into RSN element and to
> provide the received element to user space (again, most mac80211-based
> drivers should work as-is)
Thank you very much for your explanations, Jouni!
Regards,
Andreas
Jouni Malinen wrote:
> On Tue, May 08, 2012 at 08:28:33AM +0200, Andreas Hartmann wrote:
>>> The main requirements:
>>> - support CCMP encryption/decryption of unicast robust management frames
>>> (subset of Action frames, Deauthentication, Disassociation)
>>
>> I tested WPA-EAP-SHA256 with group key ccmp.
>
> The key point here is to test whether at least one of those management
> frames gets encrypted and decrypted correctly. Deauthentication frames
> may be easiest for that purpose and you can request the station to
> disconnect to test AP's capability of receiving the frame and then use
> hostapd_cli deauthenticate <addr> command on the AP to request the
> station to be disconnected.
Deauth works fine as long as both ralink devices (AP and STA) use
nowhwcrypt (or both are using hwcrypt - but this does not work with
ath9k STA e.g.).
If one of both runs hwencryption, it doesn't work any more - exactly the
same as with BA session requests.
>> The IGTK is a single key (shared key). There are a maximum of 4 shared
>> keys designated in rt2x00mac.c for each BSS for use with hw encryption.
>
> BIP uses key indexes 4 and 5 (i.e., the 5th and 6th index).. Anyway,
> this would most likely be handled in software so the main point here is
> to prevent hardware from doing anything additional to the frames.
>
>> Since rt2800usb is working fine with nohwcrypt=1 (but not with
>> encryption done in hw), I assume, that there is no differentiation
>> between the encryption / decryption of different frame types. If hw
>> encryption is turned on, all types of frames are encrypted / decrypted
>> by hardware and vice versa.
>
> BIP is kind of special since it doesn't actually even set the Protected
> field in the frame header which may make this easier.. The frames are
> not actually encrypted, i.e., BIP protects only authenticity of the
> frames.
Thanks for this explanation!
>> I'm not sure how BIP is secured if hw encryption is enabled. BIP is
>> implemented in mac80211 as part of decryption. Is BIP done during hw
>> encryption, too? Or is it done by mac80211 w/ enabled hw encryption, too?
>
> With most drivers, yes, I would expect mac80211 to handle both TX and RX
> side. The driver should just return -EOPNOTSUPP in the set_key() handler
> for WLAN_CIPHER_SUITE_AES_CMAC to leave BIP for mac80211 and CCMP for
> hwardware.
So, this is lower priority for me at the moment :-).
>> This means for rt2x00: to get 11w working with hw encryption enabled,
>> there needs to be some differentiation for the encryption of management
>> frames: if management frame, let mac80211 do the job - all other frames
>> should be encrypted by hw.
>> Correct?
>
> Well, if you are saying that the issues shows up with unicast robust
> management frames, too, and not just BIP (group addressed robust
> management frames),
Yes. My primary problem at the moment is the handling of the unicast
robust management frames.
> then you are in problems..
yes - that's why I am here :-)
> With good luck, you could
> be able to make the hardware not mess up with unicast robust management
> frames and handle them in mac80211. This may be easier for TX,
How do I exactly recognize this situation? The unicast robust management
frames aren't decrypted with WLAN_CIPHER_SUITE_AES_CMAC. Could they be
given back to mac80211 because of the fact they are management frames?
> but RX
> can be a bit complex.
This seems to be my problem here, too. Sending the deauth from AP
(nohwcrypt=1) can't be handled by STA with hwcrypt enabled.
> It may go to the point of having to use the
> driver to workaround the mess that hardware did (i.e., re-encrypted the
> frame in incorrect way to get back to the correctly encrypted form and
> then sent that to mac80211).. All this depends on the exact behavior of
> the hardware with a frame that was designed after the hardware was, so
> good luck figuring that out ;-).
Thank you!
Regards,
Andreas
Johannes Berg wrote:
> On Tue, 2012-05-08 at 08:28 +0200, Andreas Hartmann wrote:
>
>> This means for rt2x00: to get 11w working with hw encryption enabled,
>> there needs to be some differentiation for the encryption of management
>> frames: if management frame, let mac80211 do the job - all other frames
>> should be encrypted by hw.
>> Correct?
>
> That might not be sufficient -- you might have control over TX, but if
> the hardware attempts to decrypt encrypted mgmt frames you're out of
> luck entirely.
This means, that if hw encryption is enabled, the encryption must be
done entirely by hw (because of rx) and therefore, MFP must be supported
by hardware (does Ralink support MFP?)? Or is there a possibility to
tell the hardware not to decrypt some types of frames even if they are
encrypted?
Regards,
Andreas
On Tue, May 08, 2012 at 08:28:33AM +0200, Andreas Hartmann wrote:
> > The main requirements:
> > - support CCMP encryption/decryption of unicast robust management frames
> > (subset of Action frames, Deauthentication, Disassociation)
>
> I tested WPA-EAP-SHA256 with group key ccmp.
The key point here is to test whether at least one of those management
frames gets encrypted and decrypted correctly. Deauthentication frames
may be easiest for that purpose and you can request the station to
disconnect to test AP's capability of receiving the frame and then use
hostapd_cli deauthenticate <addr> command on the AP to request the
station to be disconnected.
> The IGTK is a single key (shared key). There are a maximum of 4 shared
> keys designated in rt2x00mac.c for each BSS for use with hw encryption.
BIP uses key indexes 4 and 5 (i.e., the 5th and 6th index).. Anyway,
this would most likely be handled in software so the main point here is
to prevent hardware from doing anything additional to the frames.
> Since rt2800usb is working fine with nohwcrypt=1 (but not with
> encryption done in hw), I assume, that there is no differentiation
> between the encryption / decryption of different frame types. If hw
> encryption is turned on, all types of frames are encrypted / decrypted
> by hardware and vice versa.
BIP is kind of special since it doesn't actually even set the Protected
field in the frame header which may make this easier.. The frames are
not actually encrypted, i.e., BIP protects only authenticity of the
frames.
> I'm not sure how BIP is secured if hw encryption is enabled. BIP is
> implemented in mac80211 as part of decryption. Is BIP done during hw
> encryption, too? Or is it done by mac80211 w/ enabled hw encryption, too?
With most drivers, yes, I would expect mac80211 to handle both TX and RX
side. The driver should just return -EOPNOTSUPP in the set_key() handler
for WLAN_CIPHER_SUITE_AES_CMAC to leave BIP for mac80211 and CCMP for
hwardware.
> This means for rt2x00: to get 11w working with hw encryption enabled,
> there needs to be some differentiation for the encryption of management
> frames: if management frame, let mac80211 do the job - all other frames
> should be encrypted by hw.
> Correct?
Well, if you are saying that the issues shows up with unicast robust
management frames, too, and not just BIP (group addressed robust
management frames), then you are in problems.. With good luck, you could
be able to make the hardware not mess up with unicast robust management
frames and handle them in mac80211. This may be easier for TX, but RX
can be a bit complex. It may go to the point of having to use the
driver to workaround the mess that hardware did (i.e., re-encrypted the
frame in incorrect way to get back to the correctly encrypted form and
then sent that to mac80211).. All this depends on the exact behavior of
the hardware with a frame that was designed after the hardware was, so
good luck figuring that out ;-).
--
Jouni Malinen PGP id EFC895FA