Previously, only the delivery option 1 from RFC 4284
(EAP-Request/Identity from the AP) was supported. Now option 3
(subsequent EAP-Request/Identity from RADIUS server) can also be used
when hostapd is used as a RADIUS server. The eap_user file will need to
have a Phase 1 user entry pointing to Identity method in order for this
to happen (e.g., "* Identity" in the end of the file). The identity hint
is configured in the same was as for AP/Authenticator case (eap_message
in hostapd.conf).
This commit changes just the name and Action category per D7.0. The
retransmit/timeout processing in the AP is not yet updated with the
changes in D7.0.
Some deployed WPS implementations fail to parse zero-length attributes.
As a workaround, send a null character if the device attribute string is
empty. This allows default values (empty strings) to be used without
interop issues.
Before this change, it looked like an AP that was using wsccmd did not
get activated since wsccmd left the Selected Registrar Config Methods
attribute to be zero. Since Device Password ID can be used to
distinguish PBC from any other method, use only it to figure out whether
PBC or PIN method is active.
The new INTERFACE_LIST global control interface command can be used to
request a list of all available network interfaces that could be used
with the enabled driver wrappers. This could be used to enable
interfaces automatically by external programs (e.g., wpa_gui).
Driver wrappers can now register global_init() and global_deinit()
driver_ops handlers to get a global data structure that can be shared
for all interfaces. This allows driver wrappers to initialize some
functionality (e.g., interface monitoring) before any interfaces have
been initialized.
This callback is now used to stop wpa_supplicant from trying to continue
using parameters (most likely, device password) that do not work in a
loop. In addition, wpa_gui can now notify user of failed registration.
The event callback will be used for various event messages and the M2D
notification is the first such message. It is used to notify wpa_gui
about Registrar not yet knowing the device password (PIN).
We need to be a bit more careful when removing the WPS configuration
block since wpa_s->current_ssid may still be pointing at it. In
addition, registrar pointer in wps_context will need to be cleared
since the context data is now maintained over multiple EAP-WSC runs.
Without this, certain WPS operations could have used freed memory.
Instead of sending out EAP-Failure on errors (on AP) or stopping (on
Supplicant), send a NACK message based on the allowed EAP state machine
transitions for EAP-WSC.
Whenever new scan results include WPS AP(s) and the client is not
associated, send a notification message to control interface monitors.
This makes it easier for GUIs to notify the user about possible WPS
availability without having to go through the scan results.
Windows Server 2008 NPS gets very confused if the TLS Message Length is
not included in the Phase 1 messages even if fragmentation is not used.
If the TLS Message Length field is not included in ClientHello message,
NPS seems to decide to use the ClientHello data (excluding first six
octets, i.e., EAP header, type, Flags) as the OuterTLVs data in
Cryptobinding Compound_MAC calculation (per PEAPv2; not MS-PEAP)..
Lets add the TLS Message Length to PEAPv0 Phase 1 messages to get rid of
this issue. This seems to fix Cryptobinding issues with NPS and PEAPv0
is now using optional Cryptobinding by default (again) since there are
no known interop issues with it anymore.
Changed peer to derive the full key (both MS-MPPE-Recv-Key and
MS-MPPE-Send-Key for total of 32 octets) to match with server
implementation.
Swapped the order of MPPE keys in MSK derivation since server
MS-MPPE-Recv-Key | MS-MPPE-Send-Key matches with the order specified for
EAP-TLS MSK derivation. This means that PEAPv0 cryptobinding is now
using EAP-MSCHAPv2 MSK as-is for ISK while EAP-FAST will need to swap
the order of the MPPE keys to get ISK in a way that interoperates with
Cisco EAP-FAST implementation.
driver_test can now be used either over UNIX domain socket or UDP
socket. This makes it possible to run the test over network and makes it
easier to port driver_test to Windows.
hostapd configuration: test_socket=UDP:<listen port>
wpa_supplicant configuration: driver_param=test_udp=<dst IP addr>:<port>
This adds support for setting of a regulatory domain to wpa_supplicant
drivers. It also adds regulatory domain setting for the nl80211 driver.
We expect an ISO / IEC 3166 alpha2 in the wpa configuration file as a
global.
Since only one KDF is currently supported, the negotiation is not
allowed and peer must be rejected if it tries to send KDF selection in a
Challenge message. The negotiation code is left in the file and just
commented out since it was tested to work and can be used in the future
if another KDF is added.
The attribute uses 'Actual Identity Length' field to indicate the exact
(pre-padding) length of the Identity. This actual length should be used
as the length, not the remaining attribute length.
This was previously worked around by stripping null termination away
from the end of the identity string at EAP-SIM and EAP-AKA server code.
However, it is likely that that workaround is not really needed and the
real problem was in AT_IDENTITY parsing. Anyway, the workaround is left
in just in case it was really needed with some implementations.
This IE is not (at least yet) actually used for anything, but parsing it
cleans up verbose debug log a bit since thie previously unknown, but
commonly used, vendor IE was being reported as unknown.
This allows the same source code file to be shared for both methods. For
now, this is only in eap_aka_prime.c, but eventually, changes in
eap_aka_prime.c are likely to be merged into eap_aka.c at which point
the separate eap_aka_prime.c can be removed.
This is just making an as-is copy of EAP-AKA server and peer
implementation into a new file and by using the different EAP method
type that is allocated for EAP-AKA' (50). None of the other differences
between EAP-AKA and EAP-AKA' are not yet included.
It is likely that once EAP-AKA' implementation is done and is found to
work correctly, large part of the EAP-AKA and EAP-AKA' code will be
shared. However, it is not reasonable to destabilize EAP-AKA
implementation at this point before it is clearer what the final
differences will be.
Since the Registrar may not yet know the UUID-E when a new PIN is
entered, use of a wildcard PIN that works with any UUID-E can be useful.
Such a PIN will be bound to the first Enrollee trying to use it and it
will be invalidated after the first use.
