Commit graph

23 commits

Author SHA1 Message Date
Jouni Malinen
98cd3d1c3b Preparations for variable length KCK and KEK
This modifies struct wpa_ptk to allow the length of KCK and KEK to be
stored. This is needed to allow longer keys to be used, e.g., with
Suite B 192-bit level.

Signed-off-by: Jouni Malinen <j@w1.fi>
2015-01-27 01:26:49 +02:00
Jouni Malinen
5c6787a6ca PeerKey: Clean up EAPOL-Key Key Data processing on AP
This extends the earlier PeerKey station side design to be used on the
AP side as well by passing pointer and already validated length from the
caller rather than parsing the length again from the frame buffer. This
avoids false warnings from static analyzer (CID 62870, CID 62871,
CID 62872).

Signed-off-by: Jouni Malinen <j@w1.fi>
2014-11-23 21:03:40 +02:00
Jouni Malinen
f23c5b17e1 AP: Extend EAPOL-Key msg 1/4 retry workaround for changing SNonce
If the 4-way handshake ends up having to retransmit the EAPOL-Key
message 1/4 due to a timeout on waiting for the response, it is possible
for the Supplicant to change SNonce between the first and second
EAPOL-Key message 2/4. This is not really desirable due to extra
complexities it causes on the Authenticator side, but some deployed
stations are doing this.

This message sequence looks like this:
AP->STA: EAPOL-Key 1/4 (replay counter 1, ANonce)
AP->STA: EAPOL-Key 1/4 (replay counter 2, ANonce)
STA->AP: EAPOL-Key 2/4 (replay counter 1, SNonce 1)
AP->STA: EAPOL-Key 3/4 (replay counter 3, ANonce)
STA->AP: EAPOL-Key 2/4 (replay counter 2, SNonce 2)
followed by either:
STA->AP: EAPOL-Key 4/4 (replay counter 3 using PTK from SNonce 1)
or:
AP->STA: EAPOL-Key 3/4 (replay counter 4, ANonce)
STA->AP: EAPOL-Key 4/4 (replay counter 4, using PTK from SNonce 2)

Previously, Authenticator implementation was able to handle the cases
where SNonce 1 and SNonce 2 were identifical (i.e., Supplicant did not
update SNonce which is the wpa_supplicant behavior) and where PTK
derived using SNonce 2 was used in EAPOL-Key 4/4. However, the case of
using PTK from SNonce 1 was rejected ("WPA: received EAPOL-Key 4/4
Pairwise with unexpected replay counter" since EAPOL-Key 3/4 TX and
following second EAPOL-Key 2/4 invalidated the Replay Counter that was
used previously with the first SNonce).

This commit extends the AP/Authenticator workaround to keep both SNonce
values in memory if two EAPOL-Key 2/4 messages are received with
different SNonce values. The following EAPOL-Key 4/4 message is then
accepted whether the MIC has been calculated with the latest SNonce (the
previously existing behavior) or with the earlier SNonce (the new
extension). This makes 4-way handshake more robust with stations that
update SNonce for each transmitted EAPOL-Key 2/4 message in cases where
EAPOL-Key message 1/4 needs to be retransmitted.

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
2014-11-21 17:02:00 +02:00
Jouni Malinen
692ec3058b FT: Add support for postponing FT response
If the PMK-R1 needs to be pulled for the R0KH, the previous
implementation ended up rejecting the over-the-air authentication and
over-the-DS action frame unnecessarily while waiting for the RRB
response. Improve this by postponing the Authentication/Action frame
response until the pull response is received.

Signed-off-by: Jouni Malinen <j@w1.fi>
2014-03-23 18:31:06 +02:00
Jouni Malinen
8dd9f9cdde Allow management group cipher to be configured
This allows hostapd to set a different management group cipher than the
previously hardcoded default BIP (AES-128-CMAC). The new configuration
file parameter group_mgmt_cipher can be set to BIP-GMAC-128,
BIP-GMAC-256, or BIP-CMAC-256 to select one of the ciphers defined in
IEEE Std 802.11ac-2013.

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
2014-03-14 21:58:45 +02:00
Jouni Malinen
25ef8529c1 P2P: Add support for IP address assignment in 4-way handshake
This new mechanism allows P2P Client to request an IPv4 address from the
GO as part of the 4-way handshake to avoid use of DHCP exchange after
4-way handshake. If the new mechanism is used, the assigned IP address
is shown in the P2P-GROUP-STARTED event on the client side with
following new parameters: ip_addr, ip_mask, go_ip_addr. The assigned IP
address is included in the AP-STA-CONNECTED event on the GO side as a
new ip_addr parameter. The IP address is valid for the duration of the
association.

The IP address pool for this new mechanism is configured as global
wpa_supplicant configuration file parameters ip_addr_go, ip_addr_mask,
ip_addr_star, ip_addr_end. For example:

ip_addr_go=192.168.42.1
ip_addr_mask=255.255.255.0
ip_addr_start=192.168.42.2
ip_addr_end=192.168.42.100

DHCP mechanism is expected to be enabled at the same time to support P2P
Devices that do not use the new mechanism. The easiest way of managing
the IP addresses is by splitting the IP address range into two parts and
assign a separate range for wpa_supplicant and DHCP server.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
2014-01-27 21:44:26 +02:00
Jouni Malinen
7d7f7be2e5 Verify group key configuration for WPA group
If configuration of the group key to the driver fails, move the WPA
group into failed state and indication group setup error to avoid cases
where AP could look like it is working even through the keys are not set
correctly.

Signed-hostap: Jouni Malinen <j@w1.fi>
2013-12-24 22:38:16 +02:00
Jouni Malinen
94ddef3e72 P2P: Make peer's P2P Device Address available to authenticator
This can be used to implement per-device PSK selection based on the
peer's P2P Device Address instead of P2P Interface Address.

Signed-hostap: Jouni Malinen <j@w1.fi>
2013-09-01 11:05:19 +03:00
Jouni Malinen
ad3872a372 WNM: Use CONFIG_WNM more consistently
Replace CONFIG_IEEE80211V with CONFIG_WNM to get more consistent build
options for WNM-Sleep Mode operations. Previously it was possible to
define CONFIG_IEEE80211V without CONFIG_WNM which would break the build.
In addition, IEEE 802.11v has been merged into IEEE Std 802.11-2012 and
WNM is a better term to use for this new functionality anyway.

Signed-hostap: Jouni Malinen <j@w1.fi>
2012-12-16 18:22:54 +02:00
Xi Chen
d32d94dbf4 WNM: Add WNM-Sleep Mode implementation for AP
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
2012-08-01 13:21:23 +03:00
Jouni Malinen
0f3d578efc Remove the GPL notification from files contributed by Jouni Malinen
Remove the GPL notification text from the files that were
initially contributed by myself.

Signed-hostap: Jouni Malinen <j@w1.fi>
2012-02-11 19:39:36 +02:00
Jouni Malinen
68921e24b2 Allow SNonce update after sending EAPOL-Key 3/4 if 1/4 was retransmitted
Some supplicant implementations (e.g., Windows XP WZC) update SNonce for
each EAPOL-Key 2/4. This breaks the workaround on accepting any of the
pending requests, so allow the SNonce to be updated even if we have
already sent out EAPOL-Key 3/4.

While the issue was made less likely to occur when the retransmit
timeout for the initial EAPOL-Key msg 1/4 was increased to 1000 ms,
this fixes the problem even if that timeout is not long enough.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
2012-01-02 22:36:11 +02:00
Jouni Malinen
0d442affb6 Set Secure=1 for EAPOL-Key msg 3/4 in WPA conditional on 2/4
This is a workaround for Windows 7 supplicant rejecting WPA msg 3/4
in case it used Secure=1 in msg 2/4. This can happen, e.g., when
rekeying PTK after EAPOL-Key Error Request (Michael MIC failure)
from the supplicant.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
2011-11-17 22:59:31 +02:00
Jouni Malinen
e4bf4db907 Work around SNonce updates on EAPOL-Key 1/4 retransmission
Some deployed supplicants update their SNonce for every receive
EAPOL-Key message 1/4 even when these messages happen during the
same 4-way handshake. Furthermore, some of these supplicants fail
to use the first SNonce that they sent and derive an incorrect PTK
using another SNonce that does not match with what the authenticator
is using from the first received message 2/4. This results in
failed 4-way handshake whenever the EAPOL-Key 1/4 retransmission
timeout is reached. The timeout for the first retry is fixed to
100 ms in the IEEE 802.11 standard and that seems to be short
enough to make it difficult for some stations to get the response
out before retransmission.

Work around this issue by increasing the initial EAPOL-Key 1/4
timeout by 1000 ms (i.e., total timeout of 1100 ms) if the station
acknowledges reception of the EAPOL-Key frame. If the driver does
not indicate TX status for EAPOL frames, use longer initial
timeout (1000 ms) unconditionally.
2011-03-29 17:39:12 +03:00
Jouni Malinen
08704cd885 hostapd: Verify availability of random data when using WPA/WPA2
On Linux, verify that the kernel entropy pool is capable of providing
strong random data before allowing WPA/WPA2 connection to be
established. If 20 bytes of data cannot be read from /dev/random,
force first two 4-way handshakes to fail while collecting entropy
into the internal pool in hostapd. After that, give up on /dev/random
and allow the AP to function based on the combination of /dev/urandom
and whatever data has been collected into the internal entropy pool.
2010-11-24 13:08:03 +02:00
Jouni Malinen
1bdb7ab3af Re-initialize GMK and Key Counter on first station connection
This adds more time for the system entropy pool to be filled before
requesting random data for generating the WPA/WPA2 encryption keys.
This can be helpful especially on embedded devices that do not have
hardware random number generator and may lack good sources of
randomness especially early in the bootup sequence when hostapd is
likely to be started.

GMK and Key Counter are still initialized once in the beginning to
match the RSN Authenticator state machine behavior and to make sure
that the driver does not transmit broadcast frames unencrypted.
However, both GMK (and GTK derived from it) and Key Counter will be
re-initialized when the first station connects and is about to
enter 4-way handshake.
2010-11-24 00:52:46 +02:00
Jouni Malinen
0f857f43df FT: Validate MDIE and FTIE in FT 4-way handshake message 2/4 2010-04-10 22:40:35 +03:00
Jouni Malinen
86dfabb809 FT: Add FTIE, TIE[ReassocDeadline], TIE[KeyLifetime] to EAPOL-Key 3/4
These are mandatory IEs to be included in the FT 4-Way Handshake
Message 3.
2010-04-10 21:42:54 +03:00
Jouni Malinen
26e23750b9 FT: Fix FT 4-Way Handshake to include PMKR1Name in messages 2 and 3
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.
2010-04-07 21:04:13 +03:00
Jouni Malinen
81a658d754 FT: Re-set PTK on reassociation
It turns out that this is needed for both FT-over-DS and FT-over-air
when using mac80211, so it looks easiest to just unconditionally
re-configure the keys after reassociation when FT is used.
2010-04-04 09:34:14 +03:00
Jouni Malinen
d8ad6cb966 FT: Force key configuration after association in FT-over-DS
This seems to be needed at least with mac80211 when a STA is using
FT-over-DS to reassociate back to the AP when the AP still has the
previous association state.
2010-04-04 09:16:11 +03:00
Jouni Malinen
0e84c25434 FT: Fix PTK configuration in authenticator
Must update sm->pairwise when fetching PMK-R1 SA.
Add a workaround for drivers that cannot set keys before association
(e.g., cfg80211/mac80211): retry PTK configuration after association.
2010-03-13 21:11:26 +02:00
Jouni Malinen
1057d78eb8 Move generic AP functionality implementation into src/ap
This code can be shared by both hostapd and wpa_supplicant and this
is an initial step in getting the generic code moved to be under the
src directories. Couple of generic files still remain under the
hostapd directory due to direct dependencies to files there. Once the
dependencies have been removed, they will also be moved to the src/ap
directory to allow wpa_supplicant to be built without requiring anything
from the hostapd directory.
2009-12-25 01:12:50 +02:00
Renamed from hostapd/wpa_auth_i.h (Browse further)