Added a new configuration option, wpa_ptk_rekey, that can be used to
enforce frequent PTK rekeying, e.g., to mitigate some attacks against TKIP
deficiencies. This can be set either by the Authenticator (to initiate
periodic 4-way handshake to rekey PTK) or by the Supplicant (to request
Authenticator to rekey PTK).
With both wpa_ptk_rekey and wpa_group_rekey (in hostapd) set to 600, TKIP
keys will not be used for more than 10 minutes which may make some attacks
against TKIP more difficult to implement.
A driver was found to remove SSID IE from NDIS_WLAN_BSSID_EX IEs, but the
correct SSID is included in NDIS_802_11_SSID structure inside the BSSID
data. If this is seen in scan results, create a matching SSID IE and add it
to the end of IEs to fix scan result parsing.
Need to make sure that portValid is TRUE in order to avoid PAE state
machine going into DISCONNECTED state on eapol_sm_step(). This could be
triggered at least with OKC.
Changed EAP-FAST configuration to use separate fields for A-ID and
A-ID-Info (eap_fast_a_id_info) to allow A-ID to be set to a fixed
16-octet len binary value for better interoperability with some peer
implementations; eap_fast_a_id is now configured as a hex string.
eap_fast_prov config parameter can now be used to enable/disable different
EAP-FAST provisioning modes:
0 = provisioning disabled
1 = only anonymous provisioning allowed
2 = only authenticated provisioning allowed
3 = both provisioning modes allowed
draft-cam-winget-eap-fast-provisioning-06.txt or RFC 4851 do not seem to
mandate any particular order for TLVs, but some interop issues were noticed
with an EAP-FAST peer implementation when Result TLV followed PAC TLV. The
example in draft-cam-winget-eap-fast-provisioning-06.txt shows the TLVs in
the other order, so change the order here, too, to make it less likely to
hit this type of interop issues.
This adds all the attributes that are marked as mandatory for SoH in
IF-TNCCS-SOH v1.0. MS-Machine-Inventory does not contain correct data
(i.e., all version fields are just marked as inapplicable) and
MS-MachineName is hardcoded to wpa_supplicant@w1.fi for now.
It is possible that the initialization of the Phase 2 EAP method fails and
if that happens, we need to stop EAP-TTLS server from trying to continue
using the uninitialized EAP method. Otherwise, the server could trigger
a segmentation fault when dereferencing a NULL pointer.
A bug just got reported as a result of this for mac80211 drivers.
https://bugzilla.redhat.com/show_bug.cgi?id=459399
The basic problem is that since taking the device down clears the keys
from the driver on many mac80211-based cards, and since the mode gets
set _after_ the keys have been set in the driver, the keys get cleared
on a mode switch and the resulting association is wrong. The report is
about ad-hoc mode specifically, but this could happen when switching
from adhoc back to managed mode.
IEEE 802.11w/D6.0 defines new AKMPs to indicate SHA256-based algorithms for
key derivation (and AES-CMAC for EAPOL-Key MIC). Add support for using new
AKMPs and clean up AKMP processing with helper functions in defs.h.
This updates management frame protection to use the assocition ping process
from the latest draft (D6.0) to protect against unauthenticated
authenticate or (re)associate frames dropping association.
This adds most of the new frame format and identifier definitions from IEEE
802.11w/D6.0. In addition, the RSN IE capability field values for MFP is
replaced with the new two-bit version with MFPC (capable) and MFPR
(required) processing.
If IWEVGENIE or custom event wpa_ie/rsn_ie is received in scan with empty
buffer, the previous version ended up calling realloc(NULL, 0) which seems
to return a non-NULL value in some cases. When this return value is passed
again into realloc with realloc(ptr, 0), the returned value could be NULL.
If the ptr is then freed (os_free(data.ie) in SIOCGIWAP handling), glibc
may crash due to invalid pointer being freed (or double-freed?). The
non-NULL realloc(NULL, 0) return value from glibc looks a bit odd behavior,
but anyway, better avoid this case completely and just skip the IE events
that have an empty buffer.
This issue should not show up with drivers that produce proper scan results
since the IEs will always include the two-octet header. However, it seems
to be possible to see this when using 64-bit kernel and 32-bit userspace
with incorrect compat-ioctl processing.
When the TLS handshake had been completed earlier by the server in case of
abbreviated handshake, the output buffer length was left uninitialized. It
must be initialized to zero in this case. This code is used by EAP-FAST
server and the uninitialized length could have caused it to try to send a
very large frame (though, this would be terminated by the 50 roundtrip EAP
limit). This broke EAP-FAST server code in some cases when PAC was used to
establish the tunnel.
This commit brings in cleaned up version of IEEE 802.11n implementation
from Intel (1). The Intel tarball includes number of other changes, too,
and only the changes specific to IEEE 802.11n are brought in here. In
addition, this does not include all the changes (e.g., some of the
configuration parameters are still missing and driver wrapper changes for
mac80211 were not included).
(1)
http://www.kernel.org/pub/linux/kernel/people/chuyee/wireless/iwl4965_ap/hostap_0_6_0_intel_0.0.13.1.tgz
These functions are based on the hostapd implementation and complete
the userspace MLME code in wpa_supplicant (though, mac80211 will still need
couple of pending patches to be integrated in order to get userspace client
MLME working again).
This adds some parts needed to use usermode MLME with the current mac80211
(plus a patch to add a new cfg80211 command; not yet submitted to
wireless-testing). This version creates a monitor interface for management
frames and is able to send Probe Request frames during scan. However, it
looks like management frame reception is not yet working properly. In
addition, mlme_{add,remove}_sta() handlers are still missing.
Network device ifindex will change when the interface is re-inserted.
driver_nl80211.c will need to accept netlink events from "unknown" (based
on ifindex) interfaces when a previously used card was removed earlier. If
the previously removed interface is added back, the driver_wext data need
to be updated to match with the new ifindex value. In addition, the initial
setup tasks for the card (set interface up, update ifindex, set mode, etc.)
from wpa_driver_nl80211_init() need to be run again.
This is the changes from commit 3fbda8f943
(driver_wext.c) ported for driver_nl80211.c.
