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.
wpa_sm_set_config() can be called even if the network block does not
change. However, the previous version ended up calling
pmksa_cache_notify_reconfig() every time and this cleared the network
context from PMKSA cache entries. This prevented OKC from ever being used.
Do not call pmksa_cache_notify_reconfig() if the network context remains
unchanged to allow OKC to be used.
Network device ifindex will change when the interface is re-inserted.
driver_wext.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_wext_init() need to be run again.
The change to support fragmentation added extra function to generate the
EAP header, but forgot to remove the original code and ended up getting two
EAP headers and TNC flags field in the generated message. These header
fields need to be added only in the function that builds the final message
(and if necessary, fragments the data).
When scan results got moved from wpa_scan_result -> wpa_scan_res, the
'maxrate' member was dropped from wpa_scan_res. The D-Bus interface
used 'maxrate', which was replaced with wpa_scan_get_max_rate().
Unfortunately, wpa_scan_get_max_rate() returns 802.11 rate values
directly from the IE, where 'maxrate' was the rate in bits/second. The
supplicant internally fakes an IE for wpa_scan_res from the value of
wpa_scan_result->maxrate, but interprets ->maxrate as an 802.11 rate
index.
As a side-effect, this fixes a soft-break of the D-Bus control API since
the wpa_scan_res change was introduced.
Function 'wpa_sm_set_config' used the argument 'config' as the network
context which is a pointer to a local variable of the function
'wpa_supplicant_rsn_supp_set_config'.
This is one reason why no proactive key was generated. This network
context never matched with the network context saved in the pmksa cache
entries.
The structure 'rsn_supp_config' has already a member 'network_ctx' which
is now filled in by this patch with 'ssid'.
Signed-off-by: Michael Bernhard <michael.bernhard@bfh.ch>
Just in case, do not use the not-yet-approved WEXT changes even if someone
where to build wpa_supplicant with IEEE 802.11w support unless this new
macro has been defined explicitly.
Added configuration of MFP related parameters with WEXT. The changes to
linux/wireless.h have not yet been applied to the Linux kernel tree, so the
code using them is still open to changes and is ifdef'ed out if
CONFIG_IEEE80211W is not set.
Add the support for the Linux wireless drivers which want to do
4-way handshake and need to know the PSK before the handshake.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Add the new flags which are supposed to be included in Linux 2.6.27
for the drivers which want to do 4-way handshake and to know PMK.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
This avoids getting stuck in state where wpa_supplicant has canceled scans,
but the driver is actually in disassociated state. The previously used code
that controlled scan timeout from WPA module is not really needed anymore
(and has not been needed for past four years since authentication timeout
was separated from scan request timeout), so this can simply be removed to
resolved the race condition. As an extra bonus, this simplifies the
interface to WPA module.
[Bug 261]
driver_nl80211.c is based on driver_wext.c and it is still using Linux
wireless extensions for many functions. Over time, the new driver interface
code should be modified to use nl80211/cfg80211 for everything.
Don't cast pointers to int in definitions of PRISM2_HOSTAPD_RID_HDR_LEN
and PRISM2_HOSTAPD_GENERIC_ELEMENT_HDR_LEN. Use size_t instead. That's
actually what the code needs.
CONFIG_INTERNAL_LIBTOMMATH_FAST=y in .config can now be used to enable all
optimized routines at a cost of about 4 kB. This is small enough increase
in size to justify simplified configuration.
At the cost of about 1 kB of additional binary size, the internal
LibTomMath can be configured to include faster div routine to speed up DH
and RSA. This can be enabled with CONFIG_INTERNAL_LIBTOMMATH_FAST_DIV=y in
.config.
This gets rid of potential warnings about buffer bounds errors. The earlier
code works fine, but it is not the cleanest way of using the struct wpa_ptk
definition for TK1/TK2.
At the cost of about 0.5 kB of additional binary size, the internal
LibTomMath can be configured to include faster sqr routine to speed up DH
and RSA. This can be enabled with CONFIG_INTERNAL_LIBTOMMATH_FAST_SQR=y in
.config.
struct wpa_ie_hdr had separate fields for 24-bit OUI and 8-bit oui_type
for WPA/RSN selectors. {WPA,RSN}_SELECTOR_{GET,PUT} access these four
octets through oui and the "out-of-bounds" access for the fourth octet is
actually reading/writing oui_type. This works fine, but some tools complain
about the array bounds "failure". Since oui_type is never accessed
separately, the simplest fix is to just combine these into a single 4-octet
field.
Since mac80211 requires that the device be !IFF_UP to change the mode
(and I think the old prism54 fullmac driver does too), do that. This
shouldn't harm fullmac devices since they can handle mode switches on
the fly and usually don't care about up/down that much.
Add a cost of about 2.5 kB of additional cost, the internal LibTomMath can
be configured to include fast exptmod routine to speed up DH and RSA.
This can be enabled with CONFIG_INTERNAL_LIBTOMMATH_FAST_EXPTMOD=y in
.config.
In situations where the driver does background scanning and sends a
steady stream of scan results, wpa_supplicant would continually
reschedule the scan. This resulted in specific SSID scans never
happening for a hidden AP, and the supplicant never connecting to the AP
because it never got found. Instead, if there's an already scheduled
scan, and a request comes in to reschedule it, and there are enabled
scan_ssid=1 network blocks, let the scan happen anyway so the hidden
SSID has a chance to be found.
mac80211 sends _both_ channel and frequency in it's scan results, with
frequency first and channel second (it's since been fixed to send
channel first and frequency second to work around this issue). This
results in wpa_supplicant getting the right value when the frequency
comes, but overwriting the value with '0' when the channel comes because
wpa_supplicant can't handle 5GHz channel numbers. So if a valid
previous SIOCGIWFREQ event came in, don't try to overwrite it.
The internal TLS implementation can now use both PKCS #1 RSA private key
and PKCS #8 encapsulated RSA private key. PKCS #8 encrypted private key is
not yet supported.
The server handshake processing was still using SSL_read() to get OpenSSL
to perform the handshake. While this works for most cases, it caused some
issues for re-authentication. This is now changed to use SSL_accept() which
is more approriate here since we know that the handshake is still going on
and there will not be any tunneled data available. This resolves some of
the re-authentication issues and makes it possible for the server to notice
if TLS processing fails (SSL_read() did not return an error in many of
these cases while SSL_accept() does).
Set session id context to a unique value in order to avoid fatal errors
when client tries session resumption (SSL_set_session_id_context() must be
called for that to work), but disable session resumption with the unique
value for the time being since not all server side code is ready for it yet
(e.g., EAP-TTLS needs special Phase 2 processing when using abbreviated
handshake).
Changed EAP-TLS server not to call TLS library when processing the final
ACK (empty data) from the client in order to avoid starting a new TLS
handshake with SSL_accept().
Move the basic processing of received frames into eap_tls_common.c and use
callback functions to handle EAP type specific processing of the version
field and payload.
Fragmentation is now done as a separate step to clean up the design and to
allow the same code to be used in both Phase 1 and Phase 2. This adds
support for fragmenting EAP-PEAP/TTLS/FAST Phase 2 (tunneled) data.
Need to clear the state back to MSG after having processed all incoming
fragments. Without this, the server got stuck in sending the fragment ACK
even after having received the full message.
Even though we try to disable TLS compression, it is possible that this
cannot be done with all TLS libraries. For example, OpenSSL 0.9.8 does not
seem to have a configuration item for disabling all compression (0.9.9 has
such an option). If compression is used, Phase 2 decryption may end up
producing more data than the input buffer due to compressed data. This
shows up especially with EAP-TNC that uses very compressible data format.
As a workaround, increase the decryption buffer length to (orig_len+500)*3.
This is a hack, but at least it handles most cases. TLS compression should
really be disabled for EAP use of TLS, but since this can show up with
common setups, it is better to handle this case.
It looks like this SSL_set_options() value was added in 0.9.9 and it does
not exist in stable releases of OpenSSL. Fix build by using #ifdef on this
variable before use.
The middle byte of the secret (key for PRF) is shared with key halfs in
case the key length is odd. This does not happen in any of the current
tls_prf() uses, but it's better to fix this function to avoid future issues
should someone end up defining a use that uses an odd length for the key.
Process SoH Request in SoH EAP Extension method and reply with SoH TLV. The
contents of SSoH is not yet complete (i.e., some of the required attributes
are still missing). Use of SoH is disabled by default; it can be enabled
with tnc=soh in phase1 parameter for PEAP.
crypto_binding=# in phase1 network parameter can now be used to change the
PEAPv0 cryptobinding behavior (0 = do not use, 1 = optional (default),
2 = required).
Allow the user to set the IP address of the eapol_test client. This if
very useful when you have a machine with many interfaces and want to use a
particular one for testing RADIUS connectivity. For instance when I run the
national eduroam proxy I can only connect to other server from a particular
address, an our machine happens to have several IPs. So if I want to run
connectivity tests, I must make sure that my test uses a particular
interface. The -A option allows one to set this).
(jm: cleaned up to use radius configuration structure instead of global
variable for the address and added IPv6 support)
Implements the Chargable-User-Identity (CUI), as defined in RFC 4372.
Option "-i" causes the eapol_test to send a NUL CUI - which is a request to
send a CUI back. Capital "-I" allows to specify the value of the CUI.
This has been defined for cases where the client wants to reauthenticate.
If TNC is enabled, PEAPv0 server is now sending out SoH request to initiate
IF-TNCCS-SOH (Microsoft NAP / Statement of Health) handshake. The results
are currently only shown in debug log and they do not affect authentication
or authorization result.
The previous version was deriving unnecessarily large amount of output data
for the implicit challenge. With the TLS PRF, this was not causing any
problems because the output length is not explicitly bound into the
derivation. Anyway, it is better to use the correct output length should
the PRF be ever changed to a one that uses the output length to change the
beginning of the output data.
It looks like Microsoft implementation does not match with their
specification as far as PRF+ label usage is concerned.. IPMK|CMK is derived
without null termination on the label, but the label for CSK derivation
must be null terminated.
This allows cryptobinding to be used with PEAPv0 in a way that
interoperates with Windows XP SP3 (RC2) and as such, this functionality is
now enabled as an optional addition to PEAPv0.
Microsoft uses reverse order for MS-MPPE keys in EAP-PEAP when compared to
EAP-FAST derivation of ISK. Swap the keys here to get the correct ISK for
EAP-PEAPv0 cryptobinding. This resolves the cryptobinding interop issue
with WinXP SP3 RC2. However, it looks like MSK derivation does not
interoperate when using cryptobinding, so this code remains disabled for
the time being.
This implementation is complete for PEAPv0 (Microsoft extension), but the
use of cryptobinding is disabled in this version, i.e., this does not
change protocol behavior at all.
Interop tests between hostapd and wpa_supplicant work fine, but there are
some problems in getting hostapd to interoperate with Windows XP SP3 RC2
(peer replies with Result Failure to the attempted cryptobinding). The
implementation will remain disabled until this issue has been resolved.
EAP-PEAP was the only method that used the external eap_tlv.c peer
implementation. This worked fine just for the simple protected result
notification, but extending the TLV support for cryptobinding etc. is not
trivial with such separation. With the TLV processing integrated into
eap_peap.c, all the needed information is now available for using
additional TLVs.
EAP-PEAP was the only method that used the external eap_tlv.c server
implementation. This worked fine just for the simple protected result
notification, but extending the TLV support for cryptobinding etc. is not
trivial with such separation. With the TLV processing integrated into
eap_peap.c, all the needed information is now available for using
additional TLVs.
This adds support for PS3 wireless to wpa_supplicant.
Although PS3 wireless driver is designed to conform the WEXT standard
as much as possible, unfortunately the wext driver wrapper of
wpa_supplicant can not support PS3 wireless fully because:
- PS3 wireless driver uses private WEXT ioctls for accepting PSK of
WPA-Personal from the userland.
WEXT does not specify the way to do it.
- The association and 4-way handshake are done by PS3 virtual
wireless device. The guest OSes can not interfere it.
- No EAPOL frames are allowed to go outside of the
hypervisor/firmware nor come from. They are eaten by the firmware.
Thus I needed to make a new driver wrapper for PS3 wireless.
This patch can be applied against the latest 0.6.x tree.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
The old version was using struct wpa_sm::bssid which is not necessarily
updated to point to the correct target address when doing over-the-air FT
since the address is used before the association has actually been
completed.
Transition. This fixes a potential issue where an incorrectly behaving AP
could send a group key update using the old (now invalid after reassociate)
PTK. This could also happen if there is a race condition between reporting
received EAPOL frames and association events.
