DGNum/hostapd
6
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions
hostapd/src/ap/wpa_auth_i.h

295 lines
8.3 KiB
C
Raw Normal View History

Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
/*
* hostapd - IEEE 802.11i-2004 / WPA Authenticator: Internal definitions
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-25 15:49:18 +01:00
* Copyright (c) 2004-2015, Jouni Malinen <j@w1.fi>
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
*
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 15:46:35 +01:00
* This software may be distributed under the terms of the BSD license.
* See README for more details.
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
*/
#ifndef WPA_AUTH_I_H
#define WPA_AUTH_I_H
FT RRB: Add msg replay and msg delay protection 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>
2017-04-02 14:52:51 +02:00
#include "utils/list.h"
Improve EAPOL-Key handshake stability with retransmitted frames Accept response to any pending request, not just the last one. This gives the Supplicant more time to reply since hostapd will now allow up to three seconds for the reply to the first EAPOL-Key frame transmission (and two seconds for the first retry and one second for the last) while the previous version invalidated any old request immediately when sending a retransmitted frame. If the Supplicant replies to more than one request, only the first reply to arrive at the Authenticator will be processed. As far as the Supplicant is concerned, this behavior does not differ from the previous one except for being less likely to cause unneeded retransmissions of EAPOL-Key frames. This can help in cases where power saving is used when the group key is rekeyed or when there is excessive traffic on the channel that can delay (or drop) EAPOL-Key frames.
2008-12-16 13:17:33 +01:00
/* max(dot11RSNAConfigGroupUpdateCount,dot11RSNAConfigPairwiseUpdateCount) */
Cleaned up EAPOL-Key timeout processing dot11RSNAConfigGroupUpdateTimeOut and dot11RSNAConfigPairwiseUpdateTimeOut MIB variables were only used in draft versions of IEEE 802.11i, so rename these in order not to use confusing name here. Replaced EAPOL-Key timeout to use following timeouts (in milliseconds): 100,1000,1000,1000 (this was 1000,1000,1000,0). There is no point in sending out the final EAPOL-Key frame which would be immediately followed by disconnection. After the change to allow response to any pending EAPOL-Key frame, it is fine to send the first retransmission quickly to avoid long wait in cases where Supplicant did not receive the first frame for any reason. The new sequence will still provide 3.1 seconds of time to get any response frame, so this does not reduce the previous time.
2008-12-18 16:15:36 +01:00
#define RSNA_MAX_EAPOL_RETRIES 4
Improve EAPOL-Key handshake stability with retransmitted frames Accept response to any pending request, not just the last one. This gives the Supplicant more time to reply since hostapd will now allow up to three seconds for the reply to the first EAPOL-Key frame transmission (and two seconds for the first retry and one second for the last) while the previous version invalidated any old request immediately when sending a retransmitted frame. If the Supplicant replies to more than one request, only the first reply to arrive at the Authenticator will be processed. As far as the Supplicant is concerned, this behavior does not differ from the previous one except for being less likely to cause unneeded retransmissions of EAPOL-Key frames. This can help in cases where power saving is used when the group key is rekeyed or when there is excessive traffic on the channel that can delay (or drop) EAPOL-Key frames.
2008-12-16 13:17:33 +01:00
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
struct wpa_group;
struct wpa_state_machine {
struct wpa_authenticator *wpa_auth;
struct wpa_group *group;
u8 addr[ETH_ALEN];
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 10:05:19 +02:00
u8 p2p_dev_addr[ETH_ALEN];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
enum {
WPA_PTK_INITIALIZE, WPA_PTK_DISCONNECT, WPA_PTK_DISCONNECTED,
WPA_PTK_AUTHENTICATION, WPA_PTK_AUTHENTICATION2,
WPA_PTK_INITPMK, WPA_PTK_INITPSK, WPA_PTK_PTKSTART,
WPA_PTK_PTKCALCNEGOTIATING, WPA_PTK_PTKCALCNEGOTIATING2,
WPA_PTK_PTKINITNEGOTIATING, WPA_PTK_PTKINITDONE
} wpa_ptk_state;
enum {
WPA_PTK_GROUP_IDLE = 0,
WPA_PTK_GROUP_REKEYNEGOTIATING,
WPA_PTK_GROUP_REKEYESTABLISHED,
WPA_PTK_GROUP_KEYERROR
} wpa_ptk_group_state;
Boolean Init;
Boolean DeauthenticationRequest;
Boolean AuthenticationRequest;
Boolean ReAuthenticationRequest;
Boolean Disconnect;
DPP: Add new AKM 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>
2017-06-17 22:48:52 +02:00
u16 disconnect_reason; /* specific reason code to use with Disconnect */
Add hostapd options wpa_group_update_count and wpa_pairwise_update_count 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>
2017-01-05 17:00:33 +01:00
u32 TimeoutCtr;
u32 GTimeoutCtr;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
Boolean TimeoutEvt;
Boolean EAPOLKeyReceived;
Boolean EAPOLKeyPairwise;
Boolean EAPOLKeyRequest;
Boolean MICVerified;
Boolean GUpdateStationKeys;
u8 ANonce[WPA_NONCE_LEN];
u8 SNonce[WPA_NONCE_LEN];
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 16:02:00 +01:00
u8 alt_SNonce[WPA_NONCE_LEN];
u8 alt_replay_counter[WPA_REPLAY_COUNTER_LEN];
Fix Suite B 192-bit AKM to use proper PMK length 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>
2015-10-14 00:18:11 +02:00
u8 PMK[PMK_LEN_MAX];
unsigned int pmk_len;
SAE: Fix PMKID in EAPOL-Key msg 1/4 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>
2018-03-23 16:45:44 +01:00
u8 pmkid[PMKID_LEN]; /* valid if pmkid_set == 1 */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
struct wpa_ptk PTK;
Boolean PTK_valid;
Boolean pairwise_set;
hostapd: Avoid key reinstallation in FT handshake 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>
2017-07-14 15:15:35 +02:00
Boolean tk_already_set;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
int keycount;
Boolean Pair;
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 21:36:11 +01:00
struct wpa_key_replay_counter {
Improve EAPOL-Key handshake stability with retransmitted frames Accept response to any pending request, not just the last one. This gives the Supplicant more time to reply since hostapd will now allow up to three seconds for the reply to the first EAPOL-Key frame transmission (and two seconds for the first retry and one second for the last) while the previous version invalidated any old request immediately when sending a retransmitted frame. If the Supplicant replies to more than one request, only the first reply to arrive at the Authenticator will be processed. As far as the Supplicant is concerned, this behavior does not differ from the previous one except for being less likely to cause unneeded retransmissions of EAPOL-Key frames. This can help in cases where power saving is used when the group key is rekeyed or when there is excessive traffic on the channel that can delay (or drop) EAPOL-Key frames.
2008-12-16 13:17:33 +01:00
u8 counter[WPA_REPLAY_COUNTER_LEN];
Boolean valid;
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 21:36:11 +01:00
} key_replay[RSNA_MAX_EAPOL_RETRIES],
prev_key_replay[RSNA_MAX_EAPOL_RETRIES];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
Boolean PInitAKeys; /* WPA only, not in IEEE 802.11i */
Boolean PTKRequest; /* not in IEEE 802.11i state machine */
Boolean has_GTK;
Fix group key rekeying when reauth happens during pending group key update We need to cancel the group key update for a STA if a reauthentication request is received while the STA is in pending group key update. When canceling the update, we will also need to make sure that the PTK Group Key state machine ends up in the correct state (IDLE) to allow future updates in case of WPA2.
2008-10-21 12:54:54 +02:00
Boolean PtkGroupInit; /* init request for PTK Group state machine */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
u8 *last_rx_eapol_key; /* starting from IEEE 802.1X header */
size_t last_rx_eapol_key_len;
unsigned int changed:1;
unsigned int in_step_loop:1;
unsigned int pending_deinit:1;
unsigned int started:1;
unsigned int mgmt_frame_prot:1;
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 21:59:31 +01:00
unsigned int rx_eapol_key_secure:1;
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 21:36:11 +01:00
unsigned int update_snonce:1;
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 16:02:00 +01:00
unsigned int alt_snonce_valid:1;
FT: Differentiate between FT for station and for AP in build 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>
2016-10-27 14:18:32 +02:00
#ifdef CONFIG_IEEE80211R_AP
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
unsigned int ft_completed:1;
unsigned int pmk_r1_name_valid:1;
FT: Differentiate between FT for station and for AP in build 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>
2016-10-27 14:18:32 +02:00
#endif /* CONFIG_IEEE80211R_AP */
WNM: Add WNM-Sleep Mode implementation for AP Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
2012-02-26 16:25:55 +01:00
unsigned int is_wnmsleep:1;
SAE: Fix PMKID in EAPOL-Key msg 1/4 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>
2018-03-23 16:45:44 +01:00
unsigned int pmkid_set:1;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
u8 req_replay_counter[WPA_REPLAY_COUNTER_LEN];
int req_replay_counter_used;
u8 *wpa_ie;
size_t wpa_ie_len;
enum {
WPA_VERSION_NO_WPA = 0 /* WPA not used */,
WPA_VERSION_WPA = 1 /* WPA / IEEE 802.11i/D3.0 */,
WPA_VERSION_WPA2 = 2 /* WPA2 / IEEE 802.11i */
} wpa;
int pairwise; /* Pairwise cipher suite, WPA_CIPHER_* */
int wpa_key_mgmt; /* the selected WPA_KEY_MGMT_* */
struct rsn_pmksa_cache_entry *pmksa;
u32 dot11RSNAStatsTKIPLocalMICFailures;
u32 dot11RSNAStatsTKIPRemoteMICFailures;
FT: Differentiate between FT for station and for AP in build 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>
2016-10-27 14:18:32 +02:00
#ifdef CONFIG_IEEE80211R_AP
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
u8 xxkey[PMK_LEN]; /* PSK or the second 256 bits of MSK */
size_t xxkey_len;
u8 pmk_r1_name[WPA_PMK_NAME_LEN]; /* PMKR1Name derived from FT Auth
* Request */
u8 r0kh_id[FT_R0KH_ID_MAX_LEN]; /* R0KH-ID from FT Auth Request */
size_t r0kh_id_len;
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 20:04:13 +02:00
u8 sup_pmk_r1_name[WPA_PMK_NAME_LEN]; /* PMKR1Name from EAPOL-Key
* message 2/4 */
FT: Validate MDIE and FTIE in FT 4-way handshake message 2/4
2010-04-10 21:40:35 +02:00
u8 *assoc_resp_ftie;
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 17:13:03 +01:00
void (*ft_pending_cb)(void *ctx, const u8 *dst, const u8 *bssid,
u16 auth_transaction, u16 status,
const u8 *ies, size_t ies_len);
void *ft_pending_cb_ctx;
struct wpabuf *ft_pending_req_ies;
FT: New RRB message format 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>
2017-04-02 14:52:50 +02:00
u8 ft_pending_pull_nonce[FT_RRB_NONCE_LEN];
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 17:13:03 +01:00
u8 ft_pending_auth_transaction;
u8 ft_pending_current_ap[ETH_ALEN];
FT: Add support for wildcard R0KH/R1KH 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>
2017-04-02 14:52:52 +02:00
int ft_pending_pull_left_retries;
FT: Differentiate between FT for station and for AP in build 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>
2016-10-27 14:18:32 +02:00
#endif /* CONFIG_IEEE80211R_AP */
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 16:39:12 +02:00
int pending_1_of_4_timeout;
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>
2013-03-16 18:13:31 +01:00
#ifdef CONFIG_P2P
u8 ip_addr[4];
#endif /* CONFIG_P2P */
FILS: Process FILS Authentication frame (AP) 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>
2015-09-04 23:04:21 +02:00
#ifdef CONFIG_FILS
u8 fils_key_auth_sta[FILS_MAX_KEY_AUTH_LEN];
u8 fils_key_auth_ap[FILS_MAX_KEY_AUTH_LEN];
size_t fils_key_auth_len;
FILS: Mark connection fully authorized after FILS Association (AP) Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
2015-09-09 17:56:57 +02:00
unsigned int fils_completed:1;
FILS: Process FILS Authentication frame (AP) 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>
2015-09-04 23:04:21 +02:00
#endif /* CONFIG_FILS */
Extend RESEND_* test commands to allow forcing plaintext TX 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>
2017-10-19 11:16:18 +02:00
#ifdef CONFIG_TESTING_OPTIONS
void (*eapol_status_cb)(void *ctx1, void *ctx2);
void *eapol_status_cb_ctx1;
void *eapol_status_cb_ctx2;
#endif /* CONFIG_TESTING_OPTIONS */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
};
/* per group key state machine data */
struct wpa_group {
struct wpa_group *next;
int vlan_id;
Boolean GInit;
int GKeyDoneStations;
Boolean GTKReKey;
int GTK_len;
int GN, GM;
Boolean GTKAuthenticator;
u8 Counter[WPA_NONCE_LEN];
enum {
WPA_GROUP_GTK_INIT = 0,
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 21:38:16 +01:00
WPA_GROUP_SETKEYS, WPA_GROUP_SETKEYSDONE,
WPA_GROUP_FATAL_FAILURE
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
} wpa_group_state;
u8 GMK[WPA_GMK_LEN];
u8 GTK[2][WPA_GTK_MAX_LEN];
u8 GNonce[WPA_NONCE_LEN];
Boolean changed;
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-23 23:52:46 +01:00
Boolean first_sta_seen;
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 12:08:03 +01:00
Boolean reject_4way_hs_for_entropy;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
#ifdef CONFIG_IEEE80211W
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-12 19:26:37 +01:00
u8 IGTK[2][WPA_IGTK_MAX_LEN];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
int GN_igtk, GM_igtk;
#endif /* CONFIG_IEEE80211W */
Remove WPA per-VLAN groups when no more stations remain 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>
2015-04-26 14:22:55 +02:00
/* Number of references except those in struct wpa_group->next */
unsigned int references;
Fix init of group state machine for static VLANs 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>
2015-10-05 16:14:26 +02:00
unsigned int num_setup_iface;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
};
struct wpa_ft_pmk_cache;
/* per authenticator data */
struct wpa_authenticator {
struct wpa_group *group;
unsigned int dot11RSNAStatsTKIPRemoteMICFailures;
u32 dot11RSNAAuthenticationSuiteSelected;
u32 dot11RSNAPairwiseCipherSelected;
u32 dot11RSNAGroupCipherSelected;
u8 dot11RSNAPMKIDUsed[PMKID_LEN];
u32 dot11RSNAAuthenticationSuiteRequested; /* FIX: update */
u32 dot11RSNAPairwiseCipherRequested; /* FIX: update */
u32 dot11RSNAGroupCipherRequested; /* FIX: update */
unsigned int dot11RSNATKIPCounterMeasuresInvoked;
unsigned int dot11RSNA4WayHandshakeFailures;
struct wpa_auth_config conf;
wpa_auth: Make struct wpa_auth_callbacks const 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>
2017-01-26 16:24:06 +01:00
const struct wpa_auth_callbacks *cb;
void *cb_ctx;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
u8 *wpa_ie;
size_t wpa_ie_len;
u8 addr[ETH_ALEN];
struct rsn_pmksa_cache *pmksa;
struct wpa_ft_pmk_cache *ft_pmk_cache;
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>
2013-03-16 18:13:31 +01:00
#ifdef CONFIG_P2P
struct bitfield *ip_pool;
#endif /* CONFIG_P2P */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
};
FT RRB: Add msg replay and msg delay protection 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>
2017-04-02 14:52:51 +02:00
#ifdef CONFIG_IEEE80211R_AP
#define FT_REMOTE_SEQ_BACKLOG 16
struct ft_remote_seq_rx {
u32 dom;
struct os_reltime time_offset; /* local time - offset = remote time */
/* accepted sequence numbers: (offset ... offset + 0x40000000]
* (except those in last)
* dropped sequence numbers: (offset - 0x40000000 ... offset]
* all others trigger SEQ_REQ message (except first message)
*/
u32 last[FT_REMOTE_SEQ_BACKLOG];
unsigned int num_last;
u32 offsetidx;
struct dl_list queue; /* send nonces + rrb msgs awaiting seq resp */
};
struct ft_remote_seq_tx {
u32 dom; /* non zero if initialized */
u32 seq;
};
struct ft_remote_seq {
struct ft_remote_seq_rx rx;
struct ft_remote_seq_tx tx;
};
#endif /* CONFIG_IEEE80211R_AP */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
int wpa_write_rsn_ie(struct wpa_auth_config *conf, u8 *buf, size_t len,
const u8 *pmkid);
void wpa_auth_logger(struct wpa_authenticator *wpa_auth, const u8 *addr,
logger_level level, const char *txt);
void wpa_auth_vlogger(struct wpa_authenticator *wpa_auth, const u8 *addr,
logger_level level, const char *fmt, ...);
void __wpa_send_eapol(struct wpa_authenticator *wpa_auth,
struct wpa_state_machine *sm, int key_info,
const u8 *key_rsc, const u8 *nonce,
const u8 *kde, size_t kde_len,
int keyidx, int encr, int force_version);
int wpa_auth_for_each_sta(struct wpa_authenticator *wpa_auth,
int (*cb)(struct wpa_state_machine *sm, void *ctx),
void *cb_ctx);
Added support for opportunistic key caching (OKC) This allows hostapd to share the PMKSA caches internally when multiple BSSes or radios are being controlled by the same hostapd process.
2008-08-03 19:17:58 +02:00
int wpa_auth_for_each_auth(struct wpa_authenticator *wpa_auth,
int (*cb)(struct wpa_authenticator *a, void *ctx),
void *cb_ctx);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
FT: Differentiate between FT for station and for AP in build 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>
2016-10-27 14:18:32 +02:00
#ifdef CONFIG_IEEE80211R_AP
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
int wpa_write_mdie(struct wpa_auth_config *conf, u8 *buf, size_t len);
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 20:42:54 +02:00
int wpa_write_ftie(struct wpa_auth_config *conf, const u8 *r0kh_id,
size_t r0kh_id_len,
const u8 *anonce, const u8 *snonce,
u8 *buf, size_t len, const u8 *subelem,
size_t subelem_len);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
int wpa_auth_derive_ptk_ft(struct wpa_state_machine *sm, const u8 *pmk,
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-25 15:49:18 +01:00
struct wpa_ptk *ptk);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
struct wpa_ft_pmk_cache * wpa_ft_pmk_cache_init(void);
void wpa_ft_pmk_cache_deinit(struct wpa_ft_pmk_cache *cache);
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 20:11:26 +01:00
void wpa_ft_install_ptk(struct wpa_state_machine *sm);
FILS: Derive FT key hierarchy on authenticator side for FILS+FT 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>
2017-05-07 13:32:25 +02:00
int wpa_ft_store_pmk_r0(struct wpa_authenticator *wpa_auth,
const u8 *spa, const u8 *pmk_r0,
const u8 *pmk_r0_name, int pairwise);
FT: Differentiate between FT for station and for AP in build 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>
2016-10-27 14:18:32 +02:00
#endif /* CONFIG_IEEE80211R_AP */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-28 02:34:43 +01:00
#endif /* WPA_AUTH_I_H */
Reference in a new issue Copy permalink