Amazing-Mirror/fragattacks
1
0
Fork 0
mirror of https://github.com/vanhoefm/fragattacks.git synced 2024-11-26 09:18:24 -05:00
Code Issues Projects Releases Wiki Activity
f80fd58de6
fragattacks/src/ap/wpa_auth_i.h

258 lines
7.4 KiB
C
Raw Normal View History

Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05: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 09:49:18 -05: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-27 20:34:43 -05: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 09:46:35 -05: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-27 20:34:43 -05:00
*/
#ifndef WPA_AUTH_I_H
#define WPA_AUTH_I_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 07:17:33 -05: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 10:15:36 -05: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 07:17:33 -05:00
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
struct wpa_group;
struct wpa_stsl_negotiation {
struct wpa_stsl_negotiation *next;
u8 initiator[ETH_ALEN];
u8 peer[ETH_ALEN];
};
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 04:05:19 -04:00
u8 p2p_dev_addr[ETH_ALEN];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05: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;
int TimeoutCtr;
int GTimeoutCtr;
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 10:02:00 -05:00
u8 alt_SNonce[WPA_NONCE_LEN];
u8 alt_replay_counter[WPA_REPLAY_COUNTER_LEN];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
u8 PMK[PMK_LEN];
struct wpa_ptk PTK;
Boolean PTK_valid;
Boolean pairwise_set;
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 15:36:11 -05: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 07:17:33 -05: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 15:36:11 -05: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-27 20:34:43 -05: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 06:54:54 -04: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-27 20:34:43 -05: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 15:59:31 -05: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 15:36:11 -05: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 10:02:00 -05:00
unsigned int alt_snonce_valid:1;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
#ifdef CONFIG_IEEE80211R
unsigned int ft_completed:1;
unsigned int pmk_r1_name_valid:1;
#endif /* CONFIG_IEEE80211R */
WNM: Add WNM-Sleep Mode implementation for AP Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
2012-02-26 10:25:55 -05:00
unsigned int is_wnmsleep:1;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05: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;
#ifdef CONFIG_IEEE80211R
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 14:04:13 -04: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 15:40:35 -04: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 12:13:03 -04: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;
u8 ft_pending_pull_nonce[FT_R0KH_R1KH_PULL_NONCE_LEN];
u8 ft_pending_auth_transaction;
u8 ft_pending_current_ap[ETH_ALEN];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
#endif /* CONFIG_IEEE80211R */
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 10:39:12 -04: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 13:13:31 -04:00
#ifdef CONFIG_P2P
u8 ip_addr[4];
#endif /* CONFIG_P2P */
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05: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 15:38:16 -05: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-27 20:34:43 -05: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 17:52:46 -05: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 06:08:03 -05:00
Boolean reject_4way_hs_for_entropy;
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05: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 14:26:37 -04:00
u8 IGTK[2][WPA_IGTK_MAX_LEN];
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
int GN_igtk, GM_igtk;
#endif /* CONFIG_IEEE80211W */
};
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_stsl_negotiation *stsl_negotiations;
struct wpa_auth_config conf;
struct wpa_auth_callbacks cb;
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 13:13:31 -04: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-27 20:34:43 -05: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 13:17:58 -04: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-27 20:34:43 -05:00
#ifdef CONFIG_PEERKEY
int wpa_stsl_remove(struct wpa_authenticator *wpa_auth,
struct wpa_stsl_negotiation *neg);
void wpa_smk_error(struct wpa_authenticator *wpa_auth,
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 13:51:26 -05:00
struct wpa_state_machine *sm,
const u8 *key_data, size_t key_data_len);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
void wpa_smk_m1(struct wpa_authenticator *wpa_auth,
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 13:51:26 -05:00
struct wpa_state_machine *sm, struct wpa_eapol_key *key,
const u8 *key_data, size_t key_data_len);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
void wpa_smk_m3(struct wpa_authenticator *wpa_auth,
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 13:51:26 -05:00
struct wpa_state_machine *sm, struct wpa_eapol_key *key,
const u8 *key_data, size_t key_data_len);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
#endif /* CONFIG_PEERKEY */
#ifdef CONFIG_IEEE80211R
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 14:42:54 -04: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-27 20:34:43 -05: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 09:49:18 -05:00
struct wpa_ptk *ptk);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05: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 14:11:26 -05:00
void wpa_ft_install_ptk(struct wpa_state_machine *sm);
Re-initialize hostapd/wpa_supplicant git repository based on 0.6.3 release
2008-02-27 20:34:43 -05:00
#endif /* CONFIG_IEEE80211R */
#endif /* WPA_AUTH_I_H */
Reference in New Issue Copy Permalink