When a driver does not implement the TDLS_TEARDOWN operation internally,
send an explicit TDLS link teardown frame to the driver.
Change all teardown calls to use these calling semantics.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Cc: Kalyan C Gaddam <chakkal@iit.edu>
When a discovery request is received, add the peer to the TDLS peer
cache and send a response containing minimal data. Mandatory IEs in
the discovery response frame will be filled out by the driver.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Cc: Kalyan C Gaddam <chakkal@iit.edu>
Put glue code in place to propagate TDLS related driver capabilities to
the TDLS state machine.
If the driver doesn't support capabilities, assume TDLS is supported
internally.
When TDLS is explicitly not supported, disable all user facing TDLS
operations.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Cc: Kalyan C Gaddam <chakkal@iit.edu>
A zero dialog-token is considered invalid by IEEE Std 802.11z-2010.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Cc: Kalyan C Gaddam <chakkal@iit.edu>
Whenever PMK gets changed (e.g., due to re-authentication), all PMKSA
caching entries that were created using the previous PMK needs to be
replaced. Previously, only the entry for the current AP was cleared.
Flush the other entries based on network_ctx matches to get rid of the
OKC entries. These entries can then be re-creating using OKC with the
new PMK.
If a network configuration block is removed or modified, flush
all PMKSA cache entries that were created using that network
configuration. Similarly, invalidate EAP state (fast re-auth).
The special case for OKC on wpa_supplicant reconfiguration
(network_ctx pointer change) is now addressed as part of the
PMKSA cache flushing, so it does not need a separate mechanism
for clearing the network_ctx values in the PMKSA cache.
If the driver maintains its own copy of the PMKSA cache, we need to
clear an entry from the driver whenever wpa_supplicant is dropping
an old PMKSA cache entry.
Reassociation Request/Response frame validation need to count all IEs in
the RIC. In addition, TIE is not protected, so it should not be included
in the count.
Signed-off-by: Hong Wu <hong.wu@dspg.com>
Add support to wpa_supplicant for device-based GTK rekeying. In order to
support that, pass the KEK, KCK, and replay counter to the driver, and
handle rekey events that update the latter.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The change to use wpa_dbg() in wpa_sm_parse_own_wpa_ie() could result
in a NULL pointer dereference if the function were called when WPA
state machine has not been initialized. While this cannot really
happen in practice, it is better to be prepared for that since that
was the case before the wpa_dbg() change.
This avoids reading past the end of the IE buffer should the FTIE
be too short. In addition, one debug hexdump was using uninitialized
pointer to the FTIE buffer, so fixed it to use the pointer from the
parse data.
If there is already a link the requested peer, request start of
renegotiation instead of completely new link. This seems to be needed
to allow some driver to accept the trigger for a new negotiation.
tdls_testing 0x80 can now be used to request wpa_supplicant to send
a TDLS Setup Request frame (i.e., try to initiate TDLS setup)
whenever a TDLS Setup Request frame has been received from a peer.
Blindly clearing all struct wpa_tdls_peer members is a risky
operation since it could easily clear pointers to allocated
memory, etc. information that really should not be removed.
Instead of hoping that new code gets added here to restore
the important variables, reverse the approach and only clear
structure members one by one when needed.
This allows the same code path to be used for both protected and
unprotected configurations to limit need for duplicated code in
both the driver and wpa_supplicant.
This adds code for validating that the same Key Lifetime is used
throughout TPK handshake and enables TPK lifetime expiration and
renewal/teardown. These part seem to be working, but the actual
handling of TDLS Setup Confirm and renewal are not fully
functional yet.
tdls_testing bits:
bit 3 = use short TPK lifetime (301 seconds)
bit 4 = use wrong TPK lifetime in TDLS Setup Response
bit 5 = use wrong TPK lifetime in TDLS Setup Confirm
These special test cases can be configured at run time with "wpa_cli
tdls_testing <value>" where <value> is an integer (either as a decimal
or as a hex value with 0x prefix) bitmap of special features with
following bits available at this point:
bit 0 = long frame (add dummy subelement to make FTIE very long)
bit 1 = use alternative RSN IE (different RSN capab value and no extra
replay counters)
bit 2 = send incorrect BSSID in Link Identifier of TDLS Setup Request
(e.g., 1 = long FTIE, 2 = different RSN IE, 3 = both of those)
This is disabled by default and can be enabled for the build by
adding the following line to .config:
CFLAGS += -DCONFIG_TDLS_TESTING
This converts number of debugging messages to use wpa_msg() in order
to allow the interface name to be shown with the messages.
A new function, wpa_dbg(), is introduced to allow
CONFIG_NO_STDOUT_DEBUG=y builds to remove the debug strings. This is
otherwise identical with wpa_msg(), but it gets compiled out if stdout
debugging is disabled.
Previously, both NULL and ff:ff:ff:ff:ff:ff addr were used in various
places to indicate default/broadcast keys. Make this more consistent
and useful by defining NULL to mean default key (i.e., used both for
unicast and broadcast) and ff:ff:ff:ff:ff:ff to indicate broadcast
key (i.e., used only with broadcast).
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
There is no point in maintaining two almost identical versions
of this parser. Move WPA IE parser into wpa_common.c similarly
to what was already the case with RSN IE parse.
Commit 83935317a7 added forced
disconnection in case of 4-way handshake failures. However, it should
not have changed the case where the supplicant is requesting fallback
to full EAP authentication if the PMKID in EAPOL-Key message 1/4 is
not know. This case needs to send an EAPOL-Start frame instead of
EAPOL-Key message 2/4.
This works around a problem with APs that try to force PMKSA caching
even when the client does not include PMKID in (re)association request
frame to request it. [Bug 355]
There are no subdirectories in any of these directories or plans
for adding ones. As such, there is no point in running the loop
that does not do anything and can cause problems with some shells.
Instead of parsing the IEs in the callers, use the already existing
parser in wpa_ft.c to handle MDIE and FTIE from initial MD association
response. In addition, this provides more complete access to association
response IEs to FT code which will be needed to fix FT 4-way handshake
message 2/4.
This sets the FT Capability and Policy field in the MDIE to the values
received from the target AP (if available). This fixes the MDIE contents
during FT Protocol, but the correct value may not yet be used in initial
mobility domain association.
IEEE Std 802.11r-2008, 11A.4.2 describes FT initial mobility domain
association in an RSN to include PMKR1Name in the PMKID-List field
in RSN IE in messages 2/4 and 3/4. This makes the RSN IE not be
bitwise identical with the values used in Beacon, Probe Response,
(Re)association Request frames.
The previous versions of wpa_supplicant and hostapd did not add the
PMKR1Name value in EAPOL-Key frame and did not accept it if added
(due to bitwise comparison of RSN IEs). This commit fixes the
implementation to be compliant with the standard by adding the
PMKR1Name value into EAPOL-Key messages during FT 4-Way Handshake and
by verifying that the received value matches with the value derived
locally.
This breaks interoperability with previous wpa_supplicant/hostapd
versions.
If the PTK configuration prior to association fails, allow reassociation
attempt to continue and configure PTK after association. This is a
workaround for drivers that do not allow PTK to be configured before
association (e.g., current cfg80211/mac80211).
This avoids potential use of uninitialized stack memory when printing
out peer address based on SMK error message that does not include the
MAC address.
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
This makes it clearer which files are including header from src/common.
Some of these cases should probably be cleaned up in the future not to
do that.
In addition, src/common/nl80211_copy.h and wireless_copy.h were moved
into src/drivers since they are only used by driver wrappers and do not
need to live in src/common.
This avoids passing the raw scan results into the RSN code and by
doing so, removes the only dependency on src/drivers from the
src/rsn_supp code (or from any src subdirectory for that matter).
This removes need for local configuration to ignore *.o and *~
and allows the src/*/.gitignore files to be removed (subdirectories
will inherit the rules from the root .gitignore).
There is no point in trying to continue if a 4-way handshake frame is
discarded or if PTK/GTK/IGTK configuration fails. Force the client to
disconnect in such a case to avoid confusing user by claiming the
connection was successfully completed.
IEEE 802.11r KDF uses key length in the derivation and as such, the PTK
length must be specified correctly. The previous version was deriving
using 512-bit PTK regardless of the negotiated cipher suite; this works
for TKIP, but not for CCMP. Update the code to use proper PTK length
based on the pairwise cipher.
This fixed PTK derivation for both IEEE 802.11r and IEEE 802.11w (when
using AKMP that specifies SHA-256-based key derivation). The fixed
version does not interoperate with the previous versions. [Bug 307]
hostapd will now go through the RIC Request and process each RDIE. Only
WMM TSPEC requests are currently supported; all other request
descriptors will be declined.
RIC Response is written by hostapd and verified by wpa_supplicant (MIC
validation). wpa_supplicant does not yet have code to notify the driver
about the resource request results.
This adds first part of FT resource request as part of Reassocition
Request frame (i.e., FT Protocol, not FT Resource Request Protocol).
wpa_supplicant can generate a test resource request when driver_test.c
is used with internal MLME code and hostapd can verify the FTIE MIC
properly with the included RIC Request.
The actual RIC Request IEs are not processed yet and hostapd does not
yet reply with RIC Response (nor would wpa_supplicant be able to
validate the FTIE MIC for a frame with RIC Response).
Previously, both CONFIG_IEEE80211W=y and CONFIG_IEEE80211R=y were needed
to enable SHA256-based key handshake (WPA-PSK-SHA256 and
WPA-EAP-SHA256). This can now be done with just CONFIG_IEEE80211W=y.
This adds WPS support for both hostapd and wpa_supplicant. Both programs
can be configured to act as WPS Enrollee and Registrar. Both PBC and PIN
methods are supported.
Currently, hostapd has more complete configuration option for WPS
parameters and wpa_supplicant configuration style will likely change in
the future. External Registrars are not yet supported in hostapd or
wpa_supplicant. While wpa_supplicant has initial support for acting as
an Registrar to configure an AP, this is still using number of hardcoded
parameters which will need to be made configurable for proper operation.
It looks like some Windows NDIS drivers (e.g., Intel) do not clear the
PMKID list even when wpa_supplicant explicitly sets the list to be
empty. In such a case, the driver ends up trying to use PMKSA caching
with the AP and wpa_supplicant may not have the PMK that would be needed
to complete 4-way handshake.
RSN processing already had some code for aborting PMKSA caching by
sending EAPOL-Start. However, this was not triggered in this particular
case where the driver generates the RSN IE. With this change, this case
is included, too, and the failed PMKSA caching attempt is cleanly
canceled and wpa_supplicant can fall back to full EAP authentication.
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.
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 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.
