aboutsummaryrefslogtreecommitdiffstats
path: root/src/ap/wpa_auth_i.h
Commit message (Collapse)AuthorAgeFilesLines
* SAE: Advertise Extended RSN Capabilities when H2E is enabledJouni Malinen3 days1-0/+1
| | | | Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* Remove CONFIG_IEEE80211W build parameterJouni Malinen2019-09-081-2/+0
| | | | | | | | | Hardcode this to be defined and remove the separate build options for PMF since this functionality is needed with large number of newer protocol extensions and is also something that should be enabled in all WPA2/WPA3 networks. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Maintain PMK-R1 for a connected STAJouni Malinen2019-04-181-0/+2
| | | | | | | This is needed to allow PTK rekeying to be performed through 4-way handshake in an association started through FT protocol. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* FT: Remove unused pmk argument from wpa_auth_derive_ptk_ft()Jouni Malinen2019-04-181-2/+1
| | | | | | | FT rules for PTK derivation do not use PMK. Remove the unused argument to the PTK derivation function. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* DPP2: PFS for PTK derivationJouni Malinen2019-03-181-0/+4
| | | | | | | | | | Use Diffie-Hellman key exchange to derivate additional material for PMK-to-PTK derivation to get PFS. The Diffie-Hellman Parameter element (defined in OWE RFC 8110) is used in association frames to exchange the DH public keys. For backwards compatibility, ignore missing request/response DH parameter and fall back to no PFS in such cases. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* FILS+FT: AP mode processing of PMKR1Name in initial MD associationJouni Malinen2019-03-131-0/+1
| | | | | | | | | | | | | Derive PMKR1Name during the FILS authentication step, verify that the station uses matching PMKR1Name in (Re)Association Request frame, and add RSNE[PMKR1Name] into (Re)Association Response frame when going through FT initial mobility domain association using FILS. These steps were missed from the initial implementation, but are needed to match the IEEE 802.11ai requirements for explicit confirmation of the FT key hierarchy (similarly to what is done in FT 4-way handshake when FILS is not used). Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* OCV: Track STA OCV capability in AP modeMathy Vanhoef2018-12-161-0/+3
| | | | | | Check and store OCV capability indication for each STA. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
* FT: FTE generation for SHA384-based AKM on APJouni Malinen2018-06-051-2/+2
| | | | | | | The MIC field is now a variable length field, so make FTE generation in hostapd aware of the two different field lengths. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Support variable length keysJouni Malinen2018-06-051-1/+2
| | | | | | This is a step in adding support for SHA384-based FT AKM. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Add helper function for FILS key storingMichael Braun2018-04-051-3/+2
| | | | | | | | FILS calls wpa_ft_store_pmk_r0() from wpa_auth.c. This is moved into a new function wpa_ft_store_pmk_fils() in preparation of additional information being needed. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* SAE: Fix PMKID in EAPOL-Key msg 1/4Jouni Malinen2018-03-231-0/+2
| | | | | | | | | | | | | | Previously, the association that used SAE authentication ended up recalculating the PMKID for EAPOL-Key msg 1/4 using incorrect PMK-to-PMKID derivation instead of using the previously derived PMKID from SAE. The correct PMKID was used only when going through PMKSA caching exchange with a previously derived PMKSA from SAE. Fix this by storing the SAE PMKID into the state machine entry for the initial SAE authentication case when there is no explicit PMKSA entry attached to the station. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* Extend RESEND_* test commands to allow forcing plaintext TXJouni Malinen2017-10-191-0/+6
| | | | | | | | | | | | | | | | | | This allows hostapd testing functionality to be forced to send out a plaintext EAPOL-Key frame with the RESEND_* command. That can be useful in seeing how the station behaves if an unencrypted EAPOL frame is received when TK is already configured. This is not really perfect since there is no convenient way of sending out a single unencrypted frame in the current nl80211 design. The monitor interface could likely still do this, but that's not really supposed to be used anymore. For now, clear and restore TK during this operation. The restore part is not really working correctly, though, since it ends up clearing the TSC value on the AP side and that shows up as replay protection issues on the station. Anyway, this is sufficient to generate sniffer captures to analyze station behavior. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* Remove all PeerKey functionalityJouni Malinen2017-10-151-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | This was originally added to allow the IEEE 802.11 protocol to be tested, but there are no known fully functional implementations based on this nor any known deployments of PeerKey functionality. Furthermore, PeerKey design in the IEEE Std 802.11-2016 standard has already been marked as obsolete for DLS and it is being considered for complete removal in REVmd. This implementation did not really work, so it could not have been used in practice. For example, key configuration was using incorrect algorithm values (WPA_CIPHER_* instead of WPA_ALG_*) which resulted in mapping to an invalid WPA_ALG_* value for the actual driver operation. As such, the derived key could not have been successfully set for the link. Since there are bugs in this implementation and there does not seem to be any future for the PeerKey design with DLS (TDLS being the future for DLS), the best approach is to simply delete all this code to simplify the EAPOL-Key handling design and to get rid of any potential issues if these code paths were accidentially reachable. Signed-off-by: Jouni Malinen <j@w1.fi>
* hostapd: Avoid key reinstallation in FT handshakeMathy Vanhoef2017-10-151-0/+1
| | | | | | | | | | | | | | | | | | Do not reinstall TK to the driver during Reassociation Response frame processing if the first attempt of setting the TK succeeded. This avoids issues related to clearing the TX/RX PN that could result in reusing same PN values for transmitted frames (e.g., due to CCM nonce reuse and also hitting replay protection on the receiver) and accepting replayed frames on RX side. This issue was introduced by the commit 0e84c25434e6a1f283c7b4e62e483729085b78d2 ('FT: Fix PTK configuration in authenticator') which allowed wpa_ft_install_ptk() to be called multiple times with the same PTK. While the second configuration attempt is needed with some drivers, it must be done only if the first attempt failed. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
* DPP: Add new AKMJouni Malinen2017-06-191-0/+1
| | | | | | | | | | This new AKM is used with DPP when using the signed Connector to derive a PMK. Since the KCK, KEK, and MIC lengths are variable within a single AKM, this needs number of additional changes to get the PMK length delivered to places that need to figure out the lengths of the PTK components. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* FILS: Derive FT key hierarchy on authenticator side for FILS+FTJouni Malinen2017-05-071-0/+3
| | | | | | | Derive PMK-R0 and the relevant key names when using FILS authentication for initial FT mobility domain association. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Add support for wildcard R0KH/R1KHMichael Braun2017-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Enable use of FT RRB without configuring each other AP locally. Instead, broadcast messages are exchanged to discover APs within the local network. When an R0KH or R1KH is discovered, it is cached for one day. When a station uses an invalid or offline r0kh_id, requests are always broadcast. In order to avoid this, if r0kh does not reply, a temporary blacklist entry is added to r0kh_list. To avoid blocking a valid r0kh when a non-existing pmk_r0_name is requested, r0kh is required to always reply using a NAK. Resend requests a few times to ensure blacklisting does not happen due to small packet loss. To free newly created stations later, the r*kh_list start pointer in conf needs to be updateable from wpa_auth_ft.c, where only wconf is accessed. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* FT RRB: Add msg replay and msg delay protectionMichael Braun2017-05-031-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a counter and adds sequence numbering to FT RRB packets. The sequence number is checked against r0kh/r1kh sequence number cache. Special attention is needed in case the remote AP reboots and thus loses its state. I prefer it to recover automatically even without synchronized clocks. Therefore an identifier called dom is generated randomly along the initial sequence number. If the dom transmitted does not match or the sequence number is not in the range currently expected, the sender is asked for a fresh confirmation of its currently used sequence numbers. The packet that triggered this is cached and processed again later. Additionally, in order to ensure freshness, the remote AP includes an timestamp with its messages. It is then verified that the received messages are indeed fresh by comparing it to the older timestamps received and the time elapsed since then. Therefore FT_RRB_TIMESTAMP is no longer needed. This assigns new OUI 00:13:74 vendor-specific subtype 0x0001 subtypes: 4 (SEQ_REQ) and 5 (SEQ_RESP). This breaks backward compatibility, i.e., hostapd needs to be updated on all APs at the same time to allow FT to remain functional. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* FT: New RRB message formatMichael Braun2017-05-031-1/+1
| | | | | | | | | | | | | | Convert FT RRB into a new TLV based format. Use AES-SIV as AEAD cipher to protect the messages. This needs at least 32 byte long keys. These can be provided either by a config file change or letting a KDF derive the 32 byte key used from the 16 byte key given. This breaks backward compatibility, i.e., hostapd needs to be updated on all APs at the same time to allow FT to remain functional. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* PeerKey: Remove dead code related to STSL negotiation stateJouni Malinen2017-02-121-11/+0
| | | | | | | | | | | | The struct wpa_stsl_negotiation seemed to have been for some kind of tracking of state of PeerKey negotiations within hostapd. However, nothing is actually adding any entries to wpa_auth->stsl_negotiations or using this state. Since PeerKey does not look like something that would be deployed in practice, there is no justification to spend time on making this any more complete. Remove the dead code now instead of trying to figure out what it might be used for. Signed-off-by: Jouni Malinen <j@w1.fi>
* Add hostapd options wpa_group_update_count and wpa_pairwise_update_countGünther Kelleter2017-02-061-2/+2
| | | | | | | | | | | | | | | wpa_group_update_count and wpa_pairwise_update_count can now be used to set the GTK and PTK rekey retry limits (dot11RSNAConfigGroupUpdateCount and dot11RSNAConfigPairwiseUpdateCount). Defaults set to current hardcoded value (4). Some stations may suffer from frequent deauthentications due to GTK rekey failures: EAPOL 1/2 frame is not answered during the total timeout period of currently ~3.5 seconds. For example, a Galaxy S6 with Android 6.0.1 appears to go into power save mode for up to 5 seconds. Increasing wpa_group_update_count to 6 fixed this issue. Signed-off-by: Günther Kelleter <guenther.kelleter@devolo.de>
* wpa_auth: Make struct wpa_auth_callbacks constJohannes Berg2017-01-291-1/+2
| | | | | | | | | Instead of copying the struct wpa_auth_callbacks, just keep a pointer to it, keep the context pointer separate, and let the user just provide a static const structure. This reduces the attack surface of heap overwrites, since the function pointers move elsewhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* FT: Differentiate between FT for station and for AP in buildIlan Peer2016-10-291-6/+6
| | | | | | | | | | | | | | Previously, CONFIG_IEEE80211R enabled build that supports FT for both station mode and AP mode. However, in most wpa_supplicant cases only station mode FT is required and there is no need for AP mode FT. Add support to differentiate between station mode FT and AP mode FT in wpa_supplicant builds by adding CONFIG_IEEE80211R_AP that should be used when AP mode FT support is required in addition to station mode FT. This allows binary size to be reduced for builds that require only the station side FT functionality. Signed-off-by: Ilan Peer <ilan.peer@intel.com>
* FILS: Mark connection fully authorized after FILS Association (AP)Jouni Malinen2016-10-251-0/+1
| | | | Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* FILS: Process FILS Authentication frame (AP)Jouni Malinen2016-10-221-0/+6
| | | | | | | This implements processing of FILS Authentication frame for FILS shared key authentication with ERP and PMKSA caching. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* Fix Suite B 192-bit AKM to use proper PMK lengthJouni Malinen2015-10-141-1/+2
| | | | | | | | | | | | | In addition to the PTK length increasing, the length of the PMK was increased (from 256 to 384 bits) for the 00-0f-ac:12 AKM. This part was missing from the initial implementation and a fixed length (256-bit) PMK was used for all AKMs. Fix this by adding more complete support for variable length PMK and use 384 bits from MSK instead of 256 bits when using this AKM. This is not backwards compatible with the earlier implementations. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* Fix init of group state machine for static VLANsMichael Braun2015-10-051-0/+1
| | | | | | | | | | | This ensures that group key is set as long as the interface exists. Additionally, ifconfig_up is needed as wpa_group will enter FATAL_FAILURE if the interface is still down. Also vlan_remove_dynamic() is moved after wpa_auth_sta_deinit() so vlan_remove_dynamic() can check it was the last user of the wpa_group. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* Remove WPA per-VLAN groups when no more stations remainMichael Braun2015-04-261-0/+2
| | | | | | | | | | | | | Previously, struct wpa_group was created when the first station enters the group and the struct wpa_group was not freed when all station left the group. This causes a problem because wpa_group will enter FATAL_FAILURE when a wpa_group is running while the AP_VLAN interface has already been removed. Fix this by adding a reference counter to struct wpa_group and free a group if it is unused. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* Preparations for variable length KCK and KEKJouni Malinen2015-01-261-2/+2
| | | | | | | | 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>
* PeerKey: Clean up EAPOL-Key Key Data processing on APJouni Malinen2014-11-231-3/+6
| | | | | | | | | | 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>
* AP: Extend EAPOL-Key msg 1/4 retry workaround for changing SNonceJouni Malinen2014-11-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* FT: Add support for postponing FT responseJouni Malinen2014-03-231-0/+9
| | | | | | | | | | 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>
* Allow management group cipher to be configuredJouni Malinen2014-03-141-1/+1
| | | | | | | | | | 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>
* P2P: Add support for IP address assignment in 4-way handshakeJouni Malinen2014-01-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Verify group key configuration for WPA groupJouni Malinen2013-12-241-1/+2
| | | | | | | | | 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>
* P2P: Make peer's P2P Device Address available to authenticatorJouni Malinen2013-09-011-0/+1
| | | | | | | 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>
* WNM: Use CONFIG_WNM more consistentlyJouni Malinen2012-12-161-2/+0
| | | | | | | | | | 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>
* WNM: Add WNM-Sleep Mode implementation for APXi Chen2012-08-011-0/+3
| | | | Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* Remove the GPL notification from files contributed by Jouni MalinenJouni Malinen2012-02-111-8/+2
| | | | | | | Remove the GPL notification text from the files that were initially contributed by myself. Signed-hostap: Jouni Malinen <j@w1.fi>
* Allow SNonce update after sending EAPOL-Key 3/4 if 1/4 was retransmittedJouni Malinen2012-01-021-2/+4
| | | | | | | | | | | | | 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>
* Set Secure=1 for EAPOL-Key msg 3/4 in WPA conditional on 2/4Jouni Malinen2011-11-171-0/+1
| | | | | | | | | 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>
* Work around SNonce updates on EAPOL-Key 1/4 retransmissionJouni Malinen2011-03-291-0/+2
| | | | | | | | | | | | | | | | | | | | 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.
* hostapd: Verify availability of random data when using WPA/WPA2Jouni Malinen2010-11-241-0/+1
| | | | | | | | | | 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.
* Re-initialize GMK and Key Counter on first station connectionJouni Malinen2010-11-231-0/+1
| | | | | | | | | | | | | | | | 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.
* FT: Validate MDIE and FTIE in FT 4-way handshake message 2/4Jouni Malinen2010-04-101-0/+1
|
* FT: Add FTIE, TIE[ReassocDeadline], TIE[KeyLifetime] to EAPOL-Key 3/4Jouni Malinen2010-04-101-0/+5
| | | | | These are mandatory IEs to be included in the FT 4-Way Handshake Message 3.
* FT: Fix FT 4-Way Handshake to include PMKR1Name in messages 2 and 3Jouni Malinen2010-04-071-0/+2
| | | | | | | | | | | | | | | | | | | 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.
* FT: Re-set PTK on reassociationJouni Malinen2010-04-041-1/+0
| | | | | | 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.
* FT: Force key configuration after association in FT-over-DSJouni Malinen2010-04-041-0/+1
| | | | | | 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.
* FT: Fix PTK configuration in authenticatorJouni Malinen2010-03-131-0/+1
| | | | | | 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.