Method and apparatus for operating with enhanced data privacy features for stations implementing changing MAC address

Abstract

In a network operating with enhanced data privacy features, a method comprises: receiving 320, from a station capable of changing its medium access control (MAC) address (i.e. Randomized and Changing

Description

TECHNICAL FIELD Hie present disclosure pertains to the field of wireless local area network (WLAN) services. More particularly, the present disclosure pertains to speeding up associations while stations implement a Randomized and Changing MAC mechanism. BACKGROUND The evolution of wireless systems has brought privacy concerns at the forefront, driven by user demand and requirements of the General Data Protection Regulation (GDPR). The global wireless industry is faced with the growing need to protect users’ Personally Identifiable Information (PII) from increasingly sophisticated user tracking and user profiling activities, while continuing to improve WLAN services and user experience. PII corresponds to any data that identifies an individual or from which identity or contact information of an individual can be derived. For instance, in the context of IEEE 802.11 family of standards, PII may be the use of unique identifiers (such as MAC addresses or SSIDs) that can be directly connected to a single device or small group of devices and therefore owners of such devices. To mitigate tracking and traffic analysis, a user device may randomly change its MAC address. For example, the standard IEEE Std 802.11™-2020 specified a mechanism, called Randomized and Changing MAC (RCM), for periodically changing the MAC address of a non-access Point (AP) station (STA) to a random value. However, for some services to work, it may be needed that the non-AP STA is still identified by an AP and network services. PMK (Pairwise Master Key) caching is one service that is affected by the RCM mechanism. PMK is a shared secret between two entities (typically between an authenticator and a supplicant) used to derive Painvise Temporal Keys (PTK) for data encryption and that is usually established as a result of a successfill full authentication. A full authentication can be very timeconsuming depending on the authentication method and network load conditions. PMK caching avoids running a full authentication for re-establishing the PMK if the PMK was already established as a result of a previous authentication. The authenticator, e.g., the AP, indexes the cached PMK with the MAC address of the supplicant, e.g., the STA. Once the MAC address of the STA is changed, the STA is no longer recognized by the AP and thus it’s not possible to retrieve the cached PMK associated with that STA. Consequently, a full authentication is run again for re-establishing the PMK. The above-described situation has not been addressed by tire prior art. SUMMARY It is a broad objective of the present disclosure to overcome some of the foregoing concerns, in particular to accelerate authentications while maintaining privacy. In this context, the present disclosure provides, according to a first aspect, a communication method performed by an access point (AP) of a set of basic service sets (BSSs), comprising: receiving, from a station capable of changing its medium access control (MAC) address, an identifier assigned to the station by an AP of the set of BSSs for identifying the station within the set of BSSs; obtaining a cached Pairwise Master Key (PMK) associated with the station using the received identifier; and generating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP. In some embodiments, obtaining the PMK comprising retrieving, from a cache table, the PMK using the identifier. In some embodiments, the identifier is a device identifier (Device ID) assigned by the AP during a 4-way handshake procedure performed between the station and the AP. In some embodiments, the identifier is assigned by the AP performing the method. Hie present disclosure furthermore provides, according to a second aspect, a communication method performed by an access point (AP), comprising: receiving, from a station capable of changing its medium access control (MAC) address, an identifier (PMKID) identifying a cached Pairwise Master Key (PMK), the PMK identifier being generated based on a first MAC address of the station different from a second MAC address used by the station at the receiving; obtaining a cached PMK associated with the station using the received PMK identifier; and generating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP. In some embodiments, obtaining the PMK comprising retrieving, from a cache table, the PMK using the received PMK identifier. In some embodiments, the method further comprising, after obtaining the PMK, generating an PMK identifier based on the second MAC address of the station; and updating indexing of the cached PMK with the generated PMK identifier. In some embodiments, wherein the first MAC address corresponds to the MAC address of the station at indexing of the cached PMK by the PMK identifier was last updated. The present disclosure furthermore provides, according to a third aspect, a communication method performed by a non-access point (AP) station, comprising: generating a Pairwise Master Key (PMK) identifier for identifying a PMK based on a first media access control (MAC) address of the station; changing the MAC address of the station from the first MAC address to a second MAC address; and sending, using the second MAC address of the station, the PMK identifier generated based on the first MAC address. In some embodiments, the method further comprising, after sending the association request to the AP, re-generating the identifier based on the second MAC address of the station and updating indexing of a cached PMK using the re-generated identifier. In some embodiments, the PMK identifier is sent to the AP in an association request. Hie present disclosure furthermore provides, according to a fourth aspect, a communication method performed by an access point (AP), comprising: receiving, from a station capable of changing its medium access control (MAC) address, an encoded (obfuscated) identifier (PMKID) identifying a Pairwise Master Key (PMK), the identifier being based on a MAC address of the station at the time indexing of the PMK by the identifier was last established decoding the received encoded identifier; obtaining a PMK associated with the station using the decoded identifier; and generating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP. In some embodiments, the method further comprising receiving from the station, via a secured channel, a code and wherein the encoded identifier is decoded using the code for retrieving the decoded identifier. In some embodiments, the received code is a random number and wherein the decoding comprising applying an XOR operation between the random number and the encoded identifier. In some embodiments, obtaining the PMK comprising retrieving, from a cache table, the PMK using the identifier. Correlatively, the invention also provides a wireless communication station, a network controller and access points comprising at least one microprocessor configured for carry ing respective methods as described above. Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as described above. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard-disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g., a microwave or RF signal. BRIEF DESCRIPTION OF DRAWINGS Embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates an exemplary network system in which embodiments of the disclosure may be implemented; Figure 2 schematically illustrates exemplary sequences of messages exchanged, at initial association, between an AP STA (authenticator) and a non-AP STA (supplicant) operating a PMKSA caching mechanism; Figure 3 illustrates, using a flowchart, main steps of a method at an AP communicating with a STA operating an RCM, according to first exemplar} embodiments of the disclosure; Figure 4 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism based on Device ID indication mechanism according to embodiments of the disclosure; Figure 5 illustrates, using a flowchart, main steps of a communication method at AP, according to embodiments of the disclosure; Figure 6 illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to embodiments of the disclosure; Figures 7a and 7b illustrate, using a flowchart, main steps of a communication method at a non-AP STA and AP, respectively, according to second exemplary embodiments of the disclosure; Figure 8 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism according to second exemplary embodiments of the disclosure; Figure 9 illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to second exemplary embodiments of the disclosure; Figure 10 illustrates, using a flowchart, main steps of a communication method at AP, according to second exemplary embodiments of the disclosure; Figure 11 illustrates, using a flowchart, main steps of a communication method at an AP according to third exemplary embodiments of the disclosure; Figure 12 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism), according to third exemplary embodiments of the disclosure; Figure 13 illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to third exemplary embodiments of the disclosure; Figure 14 illustrates, using a flowchart, main steps of a communication method at AP, according to third exemplary embodiments of tine disclosure; Figure 15 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM according to fourth exemplary embodiments of the disclosure; Figure 15a illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to fourth exemplary embodiments of the disclosure; Figure 16 illustrates, using a flowchart, main steps of a communication method at an AP, according to fourth exemplary embodiments of the disclosure; and Figure 17 schematically illustrates a communication device of a wireless network configured to implement at least one embodiment of the present invention. DESCRIPTION OF EMBODIMENTS Figure 1 illustrates an exemplary network system in which embodiments of the disclosure may be implemented. Hie illustrated wireless communication network 100 includes a distribution system 110 interconnecting a set of basic service sets (BSSs) 120. Each BSS is fomied by a single access point station (AP STA) together with wireless client devices (non-AP STAs), creating a wireless local area network (WLAN). Each non-AP STA may receive a signal from several APs within their range. Depending on its configuration, each non-AP STA can, manually or automatically, select the network with which to associate. The set of BSSs may form an extended service set (ESS) by sharing a common service set identifier (SSID). Each BSS may be identified to users by the SSID, as well as to other devices by a basic service set identifier (BSSID). The BSSID of a BSS may be a medium access control (MAC) address of the AP of the BSS. Each AP periodically broadcasts beacon frames (“beacons”) including the corresponding BSSID to enable any STA within wireless range of the AP to associate or re-associate with the AP to establish or maintain a communication link with the AP. The WLANs may be networks implementing at least one of the IEEE 802.11 family of wireless communication protocol standards (such as that defined by the IEEE 802.11-2020 specification or amendments thereof). The distribution system 110 offers a secured channel between BSSs that can be used to exchange information, e.g., cryptographic keys, without exposure to any intermediate parties. The security strength against eavesdropping of the secure channel in the distribution system is assumed to be greater than or equal to the security strength (typically based on encryption means) of the channels used in the set of BSSs. The secured channel may be a wireless or a wired backhaul network. In Figure 1, three WLANs of multiple (n) WLANs and a Network Controller 140 are illustrated. A first WLAN comprises AP 131-1 and STAs 135-1 and 136-1 and covering a basic service area (BSA) 130-1. A second WLAN comprises AP 131-2 and STA 135-2 and covering a BSA 130-2. And a third WLAN comprises AP 131-n and STA 135-n and covering a BSA 130-n. The shown BSAs 130-1, 130-2 and 130-n are for illustration only; they may have different coverages and shapes in a real environment. If a STA moves out of its BSA, it can no longer directly communicate with other STAs present in the BSA. In operation mode, STAs (135-1, 136-1, 135-2, 135-n) are associated with their corresponding APs 131-1, 131-2, 131-n but may roam to associate with another AP (referred to as next or target AP) of another WLAN of the wireless communication network 100. In other words, when a STA, initially associated with a first AP, moves in an area covered by another AP, the STA may switch from the first AP to the other (target) AP. The switching between APs without losing connection is called roaming or BSS transition. A STA associated with a first AP may also disassociate from that AP, e.g., because the STA is switched off or moved outside its BSA, and re-associate again either with the same first AP or with another AP of the set of BSSs, e.g., when the STA is switched on or moved back within the BSA of the other AP. The set of BSSs 120 may contain a Network Controller 140 including an authentication server (AS) used by some authentication protocols. In certain implementations, the AS might be integrated into the same physical device as an AP, or into a STA in an independent BSS (IBSS) or personal BSS (PBSS). A STA may cache a Pairwise Master key (PMK) it establishes as a result of previous successful authentication. The PMK is not used to encrypt data, but rather to produce encryption keys (called ”Paiiw ise Temporal Keys”, PTKs) that are used to encrypt unicast data between two STAs. Typically, the PMK is cached along with context information including a PMK identifier (PMKID) and the MAC address of the authenticator’s or peer’s STA. In 802.11, a Pairwise Master Key Security Association (PMKSA) context is created as part of a Robust Security Network Associations (RSNA). The PMKSA is created as a result of a successful IEEE 802. IX exchange, Opportunistic Wireless Encryption (OWE) exchange, Simultaneous Authentication of Equals (SAE) authentication, Fast Initial Link Setup (FILS) authentication, or preshared PMK information (referred to herein as full authentication methods). The PMKSA contains, among other elements, the PMK, the PMKID, the Authenticator’s or peer’s MAC address, and a lifetime of the PMKSA. The PMKID is calculated based on the PMK, the STA MAC address and the Authenticator’s or peer’s MAC address. The PMKSA may then be cached and used in a subsequent (re)association without the need to ran a full authentication again. Figure 2 schematically illustrates exemplary sequences of messages exchanged, at initial association (e.g., without a pre-existing cache), between an AP STA (authenticator) and a non-AP STA (supplicant) operating a PMKSA caching mechanism as it is specified in the standard IEEE Std 802.11-2020. Ilie illustration relies on an 802. IX / EAP-based authentication involving an authentication server. A STA (Client) 210 and an AP 220 first exchange an open authentication request and response messages 231. The STA 210 then launches an association procedure 230 by sending an Association Request 232. The AP 220 responds by sending an Association Response 233 to the STA 210. The STA 210 indicates in a Robust Security Network Information Element (RSNE) of the Association Request frame 232 its supported Group and Painvise Cipher suites, its supported Authentication and Key Management (AKM) suites. Moreover, it checks by using as index the MAC address of AP 220 if it has a cached PMKSA corresponding to the AP 220. If not, it sets the field “PMKID count” of the Association Request frame 232 to 0 (the field “PMKID List” is not included). When STA 210 and AP 220 negotiate an Authentication and Key Management (AKM) suites requiring a full EAP authentication involving EAP and RADIUS, many EAP messages are exchanged between STA 210 and AP 220 (messages 241) and between AP 220 and Network Controller 225 in which the authentication server is embedded (messages 242) in order to check the authenticity of the STA 210. As a result, a Pairwise Master Key (PMK) is generated from the Master Session Key (MSK) 201 and distributed to both STA 210 and AP 220 through a secure communication channel. When EAP authentication completes successfully, Client 210 and AP 220 each generates respectively a PMKSA 209a and a PMKSA 209b comprising the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, a lifetime and the negotiated Authentication and Key Management (AKM). Furthermore, PMKSA 209a comprises the MAC address of the AP 220 and PMKSA 209b comprises optionally the MAC address of the STA 210. The PMKID is computed / derived from the PMK as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” I1AA II SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS 180-4. Tnmcate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of AP 220 (Authenticator Address) and SPA the MAC address of Client 210 (Supplicant Address). STA 210 inserts the generated PMKSA 209a in its PMKSA cache. The PMKSA 209a is indexed by the MAC address of AP 220 in its PMKSA cache. AP 220 inserts the generated PMKSA 209b in its PMKSA cache. The PMKSA 209b is indexed by the PMKID in the PMKSA cache of the AP 220. Next, a 4-way handshake 250 is initiated between STA 210 and AP 220 by exchanging messages 251, 252, 253 and 254. If the 4-way handshake procedure completes successfully, a same Painvise Transient Key (PTK) is generated at both Client 210 and AP 220 based on the PMK. The PTK is used to encrypt exchanged data. Note that even if the STA 210 later dissociates from the AP 220, cached PMKSAs 209a and 209b are kept (for a lifetime duration). If STA 210 intends to associate again with AP 220, STA 210 initiates an association procedure in which it indicates in the RSNE of a (Re)Association Request frame its supported Group and Painvise Cipher suites and its supported AKM suites. Moreover, it checks by using as index the MAC address of AP 220 if it has a cached PMKSA corresponding to the AP 220. If PMKSA 209a was not deleted from the cache, STA 210 retrieves the cached PMKSA 209a corresponding to AP 220, sets the field “PMKID count” of the (Re)Association Request frame to 1 and includes the corresponding PMKID in the field “PMKID List” in the (Re)Association Request frame. Because establishing the PMKs at the peer STAs could be time-consuming (depending on the authentication protocol used), it is desirable to reuse existing cached PMKs although a STA has changed its MAC address, while maintaining privacy. The following embodiments of the disclosure describe technical solutions to address this problem. First exemplary embodiments In order to deal with a STA (Client) operating RCM and to allow an authorized AP to recognize the STA if it disconnects and reconnects later, e.g., if the STA reconnects to a same ESS, IEEE 802.1 Ibh task group has specified a mechanism referred to as device ID indication in which an AP provides a device identifier to a STA to allow any AP in the AP’s ESS to recognize the STA when it returns to that ESS even if the STA operated an RCM procedure (i.e., changed its MAC address). The STA provides that device ID to any AP in the same ESS upon a new association. Figure 3 illustrates, using a flowchart, main steps of a method at an AP communicating with a STA operating an RCM, according to first exemplary embodiments of the disclosure. These first exemplary embodiments rely advantageously on the use of an identifier assigned by an AP, such as the device ID, to identify the STA and to avoid running a full authentication if not needed. Step 310 relates to assigning or receiving assignment from another AP of an identifier to the STA. For example, the identifier is a device identifier (Device ID) assigned by the AP during a previous 4-way handshake procedure performed between the STA and the AP. Alternatively, the identifier is a device identifier (Device ID) assigned by another AP of a set of BSSs during a 4-way handshake procedure performed between the STA and the other AP and communicated to the AP. Alternatively, the identifier is any random number assigned by the AP. In either case, the AP indexes the PMK (or PMKSA) associated with the station with the identifier. Step 320 relates to receiving, from the STA, an identifier, previously assigned by an AP of the set of BSSs, typically an ESS, for identifying the STA within the set of BSSs. Step 330 relates to obtaining a Painvise Master Key (PMK) associated with the STA using the received identifier as index. In one implementation, the PMK is retrieved from a cache table using the identifier. Step 340 relates to generating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP. Step 350 relates to encrypting exchanged messages. As it will be become apparent from the detailed description below, the identifier assigned by the AP is communicated to the STA in an encrypted message, thereby is not possible to tell that the STA receiving the identifier is the same STA that retransmits the identifier when notifying itself to an AP at reassociation, even if the latter transmission is not encrypted. Also, a same identifier is not assigned twice by the AP, thereby it is not possible to track the STA since the STA does not notify itself (in clear) two times with the same assigned identifier. Figure 4 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism based on Device ID indication mechanism according to embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication involving an authentication server. However, the PMKSA caching may be established as a result of any other authentication method discussed above (involving or not an AS). When a non-AP STA (Client) 410 intends to associate with AP 420 for which STA 410 has not cached Pairwise Master Key (PMK) relative to AP 420, STA 410 operates the association procedure 430. In particular, it launches an association procedure 430 in which it indicates in the Robust Security Network Information Element (RSNE) of the Association Request frame 432 its supported Group and Pairwise Cipher suites, its supported Authentication and Key Management (AKM) suites. Moreover, it checks by using the MAC address of AP 420 if it has a cached PMKSA corresponding to the AP 420. If not, it sets the field "PMKID count” of the Association Request frame 432 to 0 (the field “PMKID List” is not included). In complement, STA 410 indicates during its association procedure 430 its activation of device ID for a particular ESS by setting the Device ID Active field to 1 in the Extended RSN Capabilities field (section 9.4.2.241 (RSNXE) of the standard IEEE Std 802.11-2020) of the (Re)Association Request frame 432. Similarly, AP 420 indicates its activation of device ID by setting the Device ID Active field to 1 in the Extended RSN Capabilities field of the association Response frame 433. AP 420 generates an identifier Device ID for STA 410 to be used by STA 410, at a next association with the AP or with any other AP of the ESS that AP 420 belongs to, in order for the STA 410 to be identified. When STA 410 and AP 420 negotiate an Authentication and Key Management (AKM) suites requiring a full EAP authentication involving EAP and RADIUS, many EAP messages are exchanged between STA 410 and AP 420 (messages 441) and between AP 420 and Network Controller 425 in which the authentication server is embedded (messages 442) in order to check the authenticity of STA 410. As a result, a Pairwise Master Key (PMK) is generated from the Master Session Key (MSK) 401 and distributed to both STA 410 and AP 420 through a secure communication channel. If the full EAP authentication completes successfully, STA 410 and AP 420 each generates respectively a PMKSA 409a and a PMKSA 409b comprising one or more of the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, MAC address of the AP, the MAC address of the STA, a lifetime and the negotiated Authentication and Key Management (AKM). Tire PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128 (HMAC-SHA-1 (PMK, “PMK Name ” 11 A A {{ SPA)) wherein HMAC-SHA-1 is a cry ptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP 420 and SPA the current MAC address of STA 410. The PMKSA 409b contains also the Device ID generated by the AP 420 for STA 410. STA 410 and AP 420 store the generated PMKSAs 409a and 409b into their respective PMKSA caches. The PMKSA 409a is indexed by the MAC address of AP 220. The PMKSA 409b is indexed by anyone of the PMKID and the Device ID. Next, STA 410 and AP 420 initiate the 4-way handshake 450 to generate the Pairwise Transient Key PTK1 403 used to encrypt the further data to be exchanged. The previously generated Device ID is included in a Device ID Key Data Encapsulation (KDE) which is included in the Key Data field of the 4-way handshake message 3 (453). The Device ID KDE is encrypted (the field "Enciy pted Key Data” of 453 is set to 1) by using the PTK-KEK of the PTK 403 that it has generated from the information included in the 4-way handshake message 2 (452) and PMK. STA 410 cannot thus be tracked when it reassociates (even if the Device ID is communicated in clear after reassociation). In another embodiment, any identifier, such as a random number, may be sent by the AP, instead of the Device ID. Optionally, AP 420 propagates Device ID to all APs of a set of BSSs, e.g., the ESS, that AP 420 belongs to. This allows the STA 410 to associate to any other AP of the set of BSSs and it still be identified. At the reception of the 4-way handshake message 3 (453), STA 410 extracts and decrypts the Device ID KDE contained in the Key Data field by using the PTK-KEK component of the PTK PTK1 403 that it has generated from the information included in the 4-way handshake message 1 (451) and PMK. STA 410 stores the Device ID retrieved from the Device ID KDE along with the identifier of the ESS, typically the Service SET Identifier (SSID). As illustrated at 455, it is assumed that STA 410 or AP 420 operates a disassociation of STA 410 with AP 420 for some reasons; as for instance STA 410 moves away from AP 420. If STA 410 intends to associate again with AP 420, STA 410 uses a new MAC address according to the RCM mechanism, referred to as RCM-MAC-Address. STA 410 checks by using as index the MAC address of AP 420 if it has a cached PMKSA in its PMKSA cache corresponding to the AP 420. If yes, it retrieves the cached PMKSA 409a corresponding to AP 220. STA 410 then computes a new PMKID relative to the cached PMKSA 409a, referred to as PMKID-RCM 407, based on its address RCM-MAC-Address. STA 410 computes PMKID-RCM 407 using PMK: PMKID-RCM = Truncate-128(HMAC-SHA-1(PMK. “PMK Name ” {{ AA {{ SPA)) wherein PMK is the PMK of the cached PMKSA 409a, AA the MAC address of the AP 420 and SPA the address RCM-MAC-Address of the STA 410. According to an implementation, STA 410 updates the cached PMKSA 409a by replacing PMKID by PMKID-RCM 407. According to another implementation, STA 410 generates a new PMKSA 409a corresponding to AP 420 with the same values than the previously cached PMKSA 409a corresponding to AP 420 except for the PMKID which is set to PMKID-RCM 407. In such a case, the previously cached PMKSA 409a corresponding to AP 420 may be deleted. AP 420 generates also a new identifier Device ID for STA 410 to be used by STA 410, at a next association with the AP or with any other AP of the ESS that AP 420 belongs to, m order for the STA 410 to be identified. Next, STA 410 initiates an association procedure 460 during which STA 410 indicates in the RSNE of the Association Request frame 462 its supported Group and Pairwise Cipher suites and its supported AKM suites. Moreover, STA 410 sets the “PMKID Count” field to 1 and includes the PMKID-RCM 407 in the field “PMKID List”. STA 410 also indicates its activation of Device ID for the ESS in which the AP 420 belongs to by setting the Device ID Active field to 1 in the Extended RSN Capabilities field of the association Request frame 462. At the reception of Association Request frame 462, AP 420 checks if the “PMKID Count” field of its RSNE is not set to 0 and the Device ID Active field of its Extended RSN Capabilities field is set to 1. If yes, AP 420 extracts and stores the PMKID (PMKID-RCM 407) advertised in the field “PMK List” referred to as RCV-PMKID. Note that as the received PMKID is based on a newly generated MAC address (RCM-MAC-Address) of STA 410 whereas the PMKSA 409b related to STA 410 is indexed with a PMKID based on the MAC address that the STA 410 used in its previous association and consequently different from RCM-MAC-Address. According to embodiments of the invention, although the cached and the received PMKIDs do not match, a full EAP authentication procedure to retrieve the PMK corresponding to STA 410 is not launched at this stage, if ever. Rather, AP 420 completes the association procedure 460 by sending an association response frame 463 indicating a successful association. AP 420 indicates also in association response frame 463 its activation of Device ID by setting the Device ID Active field to 1 in the Extended RSN Capabilities field. If the “PMKID Count” field in the RSNE is set to 0 or the Device ID Active field in the Extended RSN Capabilities field is set to 0, AP 420 initiates a full EAP authentication involving EAP and RADIUS. Next, AP 420 initiates the 4-way handshake 470 to generate the PTK used to encrypt the further data to be exchanged. For this, AP 420 transmits the 4-way Handshake message 1 471 in which the “Key Data” field is not set. At the reception of the 4-way Handshake message 1 471, STA 410 derives a new PTK referred to as PTK2 405 from the PMK although the “Key Data” is not set. For the generation of the 4-way handshake message 2 (472), STA 410 retrieves the stored Device ID corresponding to the ESS for which AP 420 belongs to and includes it in a Device ID KDE. The Device ID KDE is included in the Key Data field of the 4-way handshake message 2 (472). STA 410 transmits the 4-way Handshake message 2 472. At the reception of the 4-way Handshake message 2 472, AP 420 extracts the Device ID from the Device ID KDE from the Key Data field and uses it to identify STA 410. In another embodiment where an identifier (e.g., a random number) is assigned by an AP instead of Device ID, the identifier is extracted by the AP from the 4-way Handshake message 2 472. AP 420 uses also the Device ID (or identifier) as index to retrieve the latest cached or updated PMKSA 409b, depending on implementations discussed above, associated with STA 410 based on the extracted Device ID. If AP 420 fails to identify a cached PMKSA indexed by the received Device ID (or identifier), AP 420 stops the 4-way handshake by silently discarding the 4-way Handshake message 2 472. In such a case, STA 410 and AP 220 may delete their corresponding cached PMKSAs, and a full authentication may be initiated. If AP 420 succeeds to identify a cached PMKSA indexed by the received ID (or identifier), AP 420 extracts the PMK from retrieved cached PMKSA, referred to as CACHED-PMK, and AP 420 computes LOCAL-PMKID 408, based on CACHED-PMK and the current MAC address of tire STA 410 (retrieved from the TA field of the frames that STA 410 transmits as for instance frames 462 or 472) which corresponds to the RCM-MAC-Address: LOCAL-PMKID = Tnmcate-128(HMAC-SHA-1 (CACHED-PMK, "PMK Name "|| AA | SPA)); wherein AA the MAC address of tire AP 420 and SPA the is the new MAC address used by STA 410 RCM-MAC-Address. If the LOCAL-PMKID corresponds to the RCV-PMKID, according to embodiments, AP 420 updates its cached PMKSA 409b by replacing PMKID by LOCAL-PMKID 408. According to other embodiments, AP 420 generates a new PMKSA 409b with the same values than the previously cached PMKSA excepted for the PMKID which is set to PMKID-RCM 407. In such a case, the previously cached PMKSA is deleted. Next, AP 420 derives the new PTK, referred to as PTK2 405, from PMK and continues the 4-way handshake 470 by transmitting the 4-way Handshake message 3 473. It is worth to note that in this case, the authentication has succeeded without a frill EAP authentication involving EAP and RADIUS and so, the authentication has been greatly accelerated. Otherwise, If the PMKID LOCAL-PMKID does not correspond to the RCV-PMKID, it stops the 4-way handshake by silently discarding the 4-way Handshake message 2 472. In such a case, STA 410 and AP 220 may delete their corresponding cached PMKSAs, and a frill authentication may be initiated. It is worth to note that the update of the cached PMKSA by replacing PMKID by LOCAL-PMKID 408 still allows STA 410 to use the PMKSA caching mechanism when it will reassociate with AP 420 as the RCM mechanism is not operated for reassociation. The generated new Device ID (or identifier) is included in a Device ID Key Data Encapsulation (KDE) which is included in the Key Data field of the 4-way handshake message 3 (473). Hie Device ID KDE is encrypted (the field “Encrypted Key Data” of 473 is set to 1) by using the PTK-KEK of the PTK PTK2 405 that it has generated from the information included in the 4-way handshake message 2 (472) and the PMK. AP 420 includes the Device ID assigned to STA 410 in the cached PMKSA 409b related to the STA 410. The PMKSA 409b related to STA 410 is indexed by the PMKID and the new Device ID assigned to STA 410. AP 420 propagates new Device ID (for example by coupling it with the previous Device ID to identity the Device ID to be updated) to all APs of the ESS that AP 420 belongs to, and at the reception of the Device ID, each AP which has a cached PMKSA related to the STA 410 updates it by replacing the existing Device ID by the new received one. At the reception of the 4-way handshake message 3 (473), STA 410 extracts and deciypts the new Device ID KDE contained in the Key Data field by using the PTK-KEK of the PTK 405 that it has generated from the information included in the 4-way handshake message 1 (471) and the PMK. STA 410 replaces the stored Device ID corresponding to the SSID of the ESS for which AP 420 belongs to by the received new Device ID included in the Device ID KDE. Figure 5 illustrates, using a flowchart, main steps of a communication method at AP, according to embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). When an AP which has activated its Device ID indication mechanism operates association procedure with a said non-AP STA (Client) which has advertised its Device ID indication mechanism (step 510), it generates at step 515 a new identifier Device ID for said STA. Next, the AP checks at step 520 if a full EAP-based authentication is necessary or not. For this, it checks in the received association request if the STA sets the field “PMKID count” to 0. If yes, next step is step 530. If not, next step is 540. Step 530 corresponds to the example of a full EAP authentication involving EAP and RADIUS performed between the AP and the STA. Next, at step 531, the AP generates and caches a PMKSA comprising one or more of the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, MAC address of the AP, a lifetime and the negotiated Authentication and Key Management (AKM). The PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” 11 AA 11 SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP and SPA the current MAC address of the said STA. The PMKSA contains also the Device ID generated by the AP 420 at step 515. Next, at step 532, AP initiates the 4-way handshake by transmitting the 4-way Handshake message 1. Next, at step 560, when the AP transmits the Message 3 of the 4-way handshake, it includes into it a KDE container referred to as Device ID KDE, for holding the new Device ID generated at step 515. The Device ID KDE is included in the Key Data field which is encrypted. AP propagates the new Device ID (for example by coupling it with the previous Device ID to identity the Device ID to be updated) to all APs of the ESS that AP belongs and at the reception of the Device ID, each AP which has a cached PMKSA related to the said STA updates the cached PMKSA by updating its Device ID (corresponding to the previous Device ID) by tire new received one. At step 540, AP checks if the field “PMKID List” of the association request received from the said STA contains a PMKID, referred to as RCV-PMKID, corresponding to a PMKID of a PMKSA stored in its PMKSA cache. If yes, next step is 545. If not, next step is 551. Steps 540 and 545 are optional. They address the case where the STA reassociates without changing its MAC address. The PMK can thus be retrieved based on the cached PMKID. This is particularly useful if the STA has been assigned a new Device ID, while the STA has not changed its MAC address. At step 545 the cached PMKSA is retrieved from the RCV-PMKID and then step 560 is performed. At step 551, the AP extracts and stores the PMKID advertised in the field “PMK List” referred to as RCV-PMKID. Next, at step 552, the AP initiates the 4-way handshake with the said STA by transmitting the 4-way Handshake message 1. At step 553 corresponding to the reception of the reception of the 4-way Handshake message 2, the AP extracts at step 554 the Device ID from the Device ID KDE of the Key Data field and uses the Device ID as index to retrieve at step 555 the latest cached or updated PMKSA 409b corresponding to the STA. Optionally, at step 556, the AP extracts the PMK from retrieved cached PMKSA, referred to as CACHED-PMK, and computes a LOCAL-PMKID, based on CACHED-PMK and the current MAC address of the said STA as follows: LOCAL-PMKID = Truncate-128(HMAC-SHA-1(CACHED-PMK, “PMKName” \\AA | SPA)); wherein A A the MAC address of the AP 420 and SPA the is MAC address used by said STA. If the LOCAL-PMKID doesn’t correspond to the RCV-PMKID, the algorithm is stopped. Next, at step 557, according to embodiments, the AP updates its cached PMKSA by replacing the stored PMKID by LOCAL-PMKID and the stored Device ID by the new Device ID generated at step 515. According to other embodiments, the AP generates a new PMKSA with the same values than the previously cached PMKSA excepted for the PMKID which is set to PMKID-RCM 407. In such a case, the previously cached PMKSA is deleted. The AP propagates new Device ID generated at step 515 (for example by coupling it with the previous Device ID to identity the Device ID to be updated) to all APs of the ESS that AP belongs and at the reception of the Device ID, each AP which has a cached PMKSA related to the said STA updates the cached PMKSA by updating its Device ID by the new received one. Figure 6 illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to embodiments of the disclosure. The illustration relies on an 802.1 X / EAP-bascd authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). First, at step 610, the STA operates an RCM procedure and changes its MAC address referred to as RCM-MAC-Address. Next, at step 620, when the STA intends to associate with an AP, it checks by using the MAC address of AP 420 if it has a cached PMKSA corresponding to the said AP. If yes, it retrieves a cached PMKSA corresponding to said AP and next step is step 640. If not, next step is 630. Next, at step 630, the STA initiates the association procedure with the AP in which it indicates in RSNE of the (Re)Association Request frame its supported Group and Painvise Cipher suites, its supported Authentication and Key Management (AKM) suites and sets the field “PMKID count” to 0. In complement, the STA indicates its activation of device ID for the AP by setting the Device ID Active field to 1 in the Extended RSN Capabilities field of the (Re)Association Request frame. Next, step 631 corresponds to the full EAP authentication involving EAP and RADIUS performed between the AP and the STA. When a full EAP authentication completes successfully, at step 632, the STA generates a Pairwise Master Key Security Association (PMKSA) comprising one or more of the following parameters: a Painvise Master Key Identifier (PMKID), PMK, MAC address of the said AP, a lifetime and the negotiated Authentication and Key Management (AKM). The PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128 (HMAC-SHA-1 (PMK, “PMK Name ” 11 A A {{ SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP 420 and SPA the current MAC address of STA 410. The STA store the generated PMKSA into its PMKSA cache. Next, at step 633, the STA initiates the 4-way handshake at the reception of the 4-way Handshake message 1 from the AP. Next, at step 650, when it receives the Message 3 of the 4-way handshake, the STA extracts and decrypts the Device ID KDE contained in the Key Data field. It replaces the stored Device ID corresponding to the SSID of the ESS for which AP belongs by the received new Device ID included in the Device ID KDE. At step 640, the STA has retrieved a cached PMKSA corresponding to said AP generated previously at step 632. It computes a new identifier PMKID-RCM using the PMK of the retrieved cached PMKSA corresponding to the said AP: PMKID-RCM = Truncate-128(HMAC-SHA-1 (PMK, “PMK Name ” {{ AA {{ SPA)) wherein AA the MAC address of the said AP and SPA the address RCM-MAC-Address of the STA. According to an implementation, the STA updates the cached PMKSA corresponding to the AP by replacing PMKID by PMKID-RCM. According to another implementation, the STA generates a new PMKSA with the same values than the previously cached PMKSA except for the PMKID which is set to PMKID-RCM. In such a case, the previously cached PMKSA is deleted. Next, at step 641, the STA initiates an association procedure during which STA indicates in the RSNE of the Association Request frame its supported Group and Pairwise Cipher suites and its supported AKM suites. Moreover, STA sets the ’ PMKID Count” field to 1 and includes the PMKID-RCM generated at step 640 in the field “PMKID List”. The STA also indicates its activation of Device ID for the ESS in which the AP belongs by setting the Device ID Active field to 1 in the Extended RSN Capabilities field of the association Request frame. Next, at the reception of the 4-way Handshake message I, the STA derives at step 642, a PTK referred to as PTK2 from the PMK of the retrieved cached PMKSA although the “Key Data” is not set. For the generation of the 4-way handshake message 2, the STA retrieves the stored Device ID corresponding to the ESS for which the said AP belongs to and includes it in a Device ID KDE. The Device ID KDE is included in the Key Data field of the 4-way handshake message 2. At step 643, it sends the 4-way handshake message 2. Next step is 650. Second exemplary embodiments According to second exemplary embodiments of tire disclosure, a delay is applied in the update of the PMKID when the STA changes its MAC address. In other words, by delaying the update of the PMKID, the AP is capable of determining, by means of the PMKID, that the previous and the current MAC address relate to a same STA. Once the current MAC is associated with the proper cached PMKSA, the PMKID can then be updated based on the current MAC address (to be used again when current MAC address changes). PMKID is an identifier used as an intermediate means for associating the two MAC addresses, similarly to the identifier, e.g., Device ID, of the first exemplary embodiments is used as an intermediate means before it is replaced with a new assigned identifier. Figure 7a illustrates, using a flowchart, main steps of a communication method at a non-AP STA according to second exemplary embodiments of the disclosure. Step 710 relates to changing the MAC address of the STA from a first MAC address to a second MAC address, in accordance with the RCM mechanism. Step 720 relates to retrieving a cached PMKID using the MAC address of the AP. Here, the cached PMKID has been generated based on the first MAC address. Step 730 relates to sending, using the second MAC address of the STA, the retrieved PMKID. Since the PMKID has been generated based on the first MAC address, the AP is capable of associating it with the PMKID cached at tire AP, and hence retrieving the corresponding PMK. Step 740 relates to re-generating a PMKID based on the second MAC address of the station, and step 750 relates to updating the PMKSA using the re-generated PMKID. Figure 7b illustrates, using a flowchart, main steps of a communication method at an AP according to second exemplary embodiments of the disclosure Step 760 relates to receiving a PMKID from a STA identified with a second MAC address. Step 770 relates to obtaining a cached Pairwise Master Key (PMK) associated with the station using the received PMKID. As the PMKID has been generated based on previous MAC address of the STA (first MAC address), and the PMKID was not updated before being communicated to the AP, the AP is capable of retrieving the cached using the received PMKID as index. Step 780 relates to re-generating the PMKID based on the second MAC address of the station, and step 790 relates to updating indexing of the PMKSA using the re-generated PMKID. Consequently, when the STA changes again its MAC address, the same process can be repeated. Thus, according to an implementation of the second exemplary embodiments of the disclosure, when the STA operates the RCM and changes it MAC address for initiating an association procedure with the AP, it applies a delay to update its PMKID. In particular, the STA updates the PMKID with the new MAC address only after transmitting the PMKID to the AP in the Association Request. According to another implementation of the second exemplary embodiments of the disclosure, the STA does not apply a delay for updating its PMKID. When the STA operates the RCM and changes it MAC address for initiating an association procedure with the AP, the STA updates its PMKID based on the second MAC address. However, the STA either maintains in memory or re-generates the PMKID based on the previous (first) MAC address in order to be communicated to the AP and allow the AP to identify the STA as a known station. In either implementation, the association procedure is initiated by including not updated PMKID (e.g., based on previous MAC address of the STA) in the association request. When the AP receives the Association Request, the AP uses the received PMKID as index to retrieve the PMKSA relative to the STA, and thus the PMK. Moreover, the AP checks whether the MAC address of the STA used for the Association Request is the same as the MAC address stored in the PMKSA. If not, the AP updates the PMKSA by computing a new PMKID based on the current MAC address of the STA, used for the association request. The MAC address of the STA is preferably included in the PMKSA. Figure 8 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism according to embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication involving an authentication server. However, the PMKSA caching may be established as a result of any other authentication method discussed above (involving or not an AS). In the figure, the PMKID generated based on the first MAC address (MAC@ 1) of the STA is referred to as PMKID# 1. Hie PMKID generated based on the second MAC address (MAC@2) of the STA is referred to as PMKID#2. The figure illustrates an implementation where the update of the PMKSA is done after the transmission of PMKID (a delay applied). According to another implementation, the update of the PMKSA with the PMKID#2 may be performed any time, provided that the association request is transmitted to the AP including PMKID# 1. Figure 9 illustrates, using a flowchart, main steps of a communication method at a non-AP STA, according to second exemplary embodiments of the disclosure. The illustration relies on an 802. IX / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). First, at step 910, the non-AP STA operates an RCM procedure and changes its MAC address referred to as RCM-MAC-Address. Next, at step 920, when the non-AP STA intends to associate with an AP, it checks by using the MAC address of AP 420 if it has a cached PMKSA corresponding to the AP. If yes, it retrieves a cached PMKSA corresponding to the AP and next step is step 940. If not, next step is 930. At step 930, the non-AP STA initiates the association procedure with the AP by indicating in RSNE of the (Re)Association Request frame its supported Group and Pairwise Cipher suites, its supported Authentication and Key Management (AKM) suites and sets the field "‘PMKID count” to 0. In complement, the non-AP STA indicates its PMKSA Caching Privacy Support by setting the PMKSA Caching Privacy Support subfield to 1 in RSN Extension Element (RSNXE) of the (Re) Association Request frame. Step 931 corresponds to the full EAP authentication involving EAP and RADIUS performed between the AP and the non-AP STA. When a full EAP authentication completes successfully, at step 932, the STA generates a Pairwise Master Key Security Association (PMKSA) comprising one or more of the following parameters: a Painvise Master Key Identifier (PMKID), PMK, MAC address of the said AP, a lifetime and the negotiated Authentication and Key Management (AKM). The PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128 (HMAC-SHA-1 (PMK, “PMKName ” 11 AA {{ SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP 420 and SPA the current MAC address of STA 410. Hie non-AP STA stores the generated PMKSA into its PMKSA cache. Next, at step 950, the non-AP STA initiates the 4-way handshake at the reception of the 4-way Handshake message 1 from the AP. At step 940, tine non-AP STA initiates the association procedure by transmitting an association request. The association request includes the PMKSA Caching Privacy Support of the non-AP STA by setting the PMKSA Caching Privacy Support subfield in the RSNXE to 1 in RSNXE. Moreover, the non-AP STA sets the “PMKID Count” field to 1 and includes the PMKID of the cached PMKSA corresponding to the AP in the RSNE of the association request. Next, at step 941, the non-AP STA computes a new identifier PMKID-RCM using the PMK of the retrieved cached PMKSA corresponding to the AP: PMKID-RCM = Truncate-128(HMAC-SHA-1 (PMK. ‘‘PMKName ” II AA II SPA)) wherein AA the MAC address of the said AP and SPA the address RCM-MAC-Address of the non-AP STA. At step 942, the non-AP STA updates the cached PMKSA corresponding to the AP by replacing PMKID by PMKID-RCM. Next, at step 950, the non-AP STA initiates the 4-way handshake at the reception of the 4-way Handshake message 1 from the AP. Figure 10 illustrates, using a flowchart, main steps of a communication method at an AP according to second exemplary embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). When an AP operates an association procedure with a non-AP STA (Client) and receives at step 1010 an association request indicating the PMKSA Caching Privacy Support of the Client, it checks at step 1020 if a full EAP-based authentication is necessary or not. For this, it checks in the received association request if the STA sets the field “PMKID count" to 0. If yes, next step is step 1030. If not, next step is 1040. Step 1030 corresponds to the example of a full EAP authentication involving EAP and RADIUS performed between the AP and the STA. Next, at step 1031, the AP generates and caches a PMKSA comprising one or more of the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, MAC address of the AP, a lifetime and tire negotiated Authentication and Key Management (AKM). The PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” 11 AA {{ SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP and SPA the current MAC address of the said STA. Next, at step 1050, AP initiates the 4-way handshake by transmitting the 4-way Handshake message 1. At step 1040, AP retrieves the cached PMKSA corresponding to the PMKID included in the field “PMKID List” of the association request received from the said Client. Next, at step 1041, the non-AP STA computes a new identifier PMKID-RCM using the PMK of the retrieved cached PMKSA corresponding to the AP: PMKID-RCM = Truncate-128(HMAC-SHA-1 (PMK, "PMKName” | AA | SPA)) wherein AA the MAC address of the said AP and SPA the address RCM-MAC-Address of the non-AP STA. At step 1042, the non-AP STA updates the cached PMKSA corresponding to the AP by replacing the cached PMKID by PMKID-RCM. Next, at step 1050, AP initiates the 4-way handshake by transmitting the 4-way Handshake message 1. Third exemplary embodiments According to third exemplary embodiments of the disclosure, an obfuscation is applied to the PMKID transmitted when the STA changes its MAC address. In an implementation, the obfuscation is performed by encoding the PMKID using an identifier (e.g., a mask) provided by tire AP. The identifier changes at each association, similarly to the Device ID, and encrypted at least during one transmission to avoid identification and tracking by untrusted third parties. Thus, by de-obfuscating (e.g., decrypting) the received obfuscated PMKID by the AP using the identifier (e.g., tire mask), the PMKID can be used by the AP to retrieve the PMK. As the identifier changes, the obfuscated (e.g., encoded) PMKID transmitted over the air at each association changes, even if the PMKID is not updated when the MAC address of the STA changes. Tracking of the STA is hence prevented. According to an implementation, the PMKID is not updated when the MAC address of the STA changes, only the initial PMKID generated when establishing the PMKSA is kept. This advantageously reduces the computation time. Figure 11 illustrates, using a flowchart, main steps of a communication method at an AP according to third exemplary embodiments of the disclosure. These third exemplary embodiments rely advantageously on the use of an identifier assigned by an AP, such as the device ID, to obfuscate the PMKID and avoid tracking. Step 1110 relates to receiving, from the STA, an obfuscated PMKID. The obfuscation being performed for example by encoding the PMKID using an identifier, known to die AP (previously transmitted to the STA). The identifier may be a mask and the encoding comprising XORing the PMKID with the mask. Step 1120 relates to de-obfiiscating the received PMKID. For example, decoding the received encoded PMKID using the known identifier (e.g., mask). Step 1130 relates to obtaining a cached Pairwise Master Key (PMK) associated with the station using the de-obfiiscated PMKID. Step 1140 relates to generating a Pairwise Transient Key (PTK) based on the obtained PMK, and step 1150 relates to encry pting exchanged messages using the PTK. In an implementation, the mask or identifier is transmitted encrypted during the 4-way handshake by the AP (in message 3). The mask is typically a sequence of random bits, referred to as PMKID MASK which is XORed with the PMKID included in the cached PMKSA corresponding to the AP. In one implementation, the PMKID is never updated when the MAC address of the STA changes. Hie PMKID generated based on the MAC address of the STA at the time a full authentication was performed and the PMKSA created is retained. In another implementation, the PMKID may be updated at defined times, periods or for certain MAC addresses or number of MAC address changes. In this other implementation, the AP needs to be notified to regenerate the PMKID based on the new parameters, e.g., the current MAC address of the STA. Indexing of the PMK in the PMKSA is consequently updated with the newly generated PMKID. The indexing of the cached PMK by the PMKID at the AP side remains thus valid even when the STA changes its MAC address. Hie PMK can thus be retrieved. While the PMKID is not systematically changed depending on implementations, privacy is still ensured because the mask, preferably random, applied to obfuscate the PMKID changes each time the PMKID is transmitted. When the STA initiates the procedure association, it set the PMKID referred to as OTAPMKID in the association request as follows: OTA PMKID = PMKID MASK + PMKID When the AP receives the OTA PMKID in the association request, it retrieves the PMKID as follows: PMKID = PMKID MASK + OTA PMKID Figure 12 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism according to embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication involving an authentication server. However, the PMKSA caching may be established as a result of any other authentication method discussed above (involving or not an AS). In the illustration of figure 12, PMKID=0 corresponds to the PMKID generated based on the MAC address of the STA at the time a full authentication was performed and the PMKSA created. The mask generated by the AP at the first association is referred to as PMKID MASK# 1. The mask generated by the AP at the second association is referred to as PMKID_MASK#2. The obfuscated PMKID transmitted over the air at the reassociation is OTA PMKID and calculated in this illustration as: OTA PMKID = PMKID MASK- 1 + PMKID# 0 Figure 13 illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to third exemplary embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). First, at step 1310, the non-AP STA operates an RCM procedure and changes its MAC address referred to as RCM-MAC-Address. Next, at step 1320, when the non-AP STA intends to associate with an AP, it checks by using the MAC address of AP 420 if it has a cached PMKSA corresponding to the said AP. If yes, it retrieves a cached PMKSA corresponding to said AP and next step is step 1340. If not, next step is 1330. At step 1330, the non-AP STA initiates the association procedure with the AP 420 in which it indicates in RSNE of the (Re)Association Request frame its supported Group and Pairwise Cipher suites, its supported Authentication and Key Management (AKM) suites and sets the field “PMKID count” to 0. In complement, the non-AP STA indicates its PMKSA Caching Privacy Support by setting the PMKSA Caching Privacy Support subfield to 1 in RSN RSNXE of the (Re)Association Request frame. Next, step 1331 corresponds to the full EAP authentication involving EAP and RADIUS performed between the AP 420 and the non-AP STA. When a full EAP authentication completes successfully, at step 1332, the STA generates a Pairwise Master Key Security Association (PMKSA) comprising one or more of the following parameters: a Painvise Master Key Identifier (PMKID), PMK, MAC address of the said AP, a lifetime and the negotiated Authentication and Key Management (AKM). Tire PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” 11 AA {{ SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP 420 and SPA the current MAC address of STA 410. The non-AP STA stores the generated PMKSA into its PMKSA cache. Next, at step 1350, the non-AP STA initiates the 4-way handshake at the reception of the 4-way Handshake message 1 from the AP. Next, at step 1360, when it receives the Message 3 of the 4-way handshake, the non-AP STA extracts and decrypts the PMKID mask PMKIDMASK contained in the PMKIDMask KDE of the Key Data field. The PMKID mask PMKID MASK is stored and indexed with the MAC address of the AP 420. If a PMKID mask corresponding to AP 420 is already stored, it is replaced by the received PMKID mask PMKID MASK. At step 1340, the non-AP STA retrieves the PMKID mask PMKID MASK corresponding to AP 420. Next, at step 1341, the non-AP STA encodes the PMKID of the cached PMKSA of AP 420. Hie encoding (resp. decoding) includes masking (resp. unmasking) such as XORing. For instance, the encoded PMKID corresponds to the PMKID of the cached PMKSA of AP 420 XORED with the PMKID mask PMKIDMASK of AP 420. Next, at step 1342, tire non-AP STA initiates the association procedure by transmitting an association request. The association request includes the PMKSA Caching Privacy Support of the non-AP STA by setting the PMKSA Caching Privacy Support subfield in the RSNXE to 1 in RSNXE. Moreover, the non-AP STA sets the “PMKID Count” field to 1 and includes the encoded PMKID corresponding to the AP generated at step 1341 in the RSNE of the association request. Next step is 1350. Figure 14 illustrates, using a flowchart, main steps of a communication method at an AP, according to third exemplary embodiments of the disclosure. The illustration relies on an 802.IX / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). When an AP supporting the PMKSA Caching Privacy Support operates association procedure with a said non-AP STA (Client) which has advertised its support to the PMKSA Caching Privacy Support in the association request (step 1410), it generates at step 1415 a new PMKID mask PMKID MASK. Typically, a PMKID mask corresponds to a sequence of random bits of the same length of the PMKID. Next, the AP checks at step 1420 if a full EAP-based authentication is necessary or not. For this, it checks in the received association request if the non-AP STA sets the field “PMKID count” to 0. If yes, next step is step 1430. If not, next step is 1440. Step 1430 corresponds to the example of a full EAP authentication involving EAP and RADIUS performed between the AP and tire STA. Next, at step 1431, the AP generates and caches a PMKSA comprising one or more of the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, MAC address of the AP, a lifetime and the negotiated Authentication and Key Management (AKM). The PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” 11 AA 11 SPA)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP 420 and SPA the current MAC address of STA 410. Next, at step 1432, AP stores the new PMKID mask PMKID MASK generated at step 1415 with the PMKID of the processed PMKSA (either generated at step 1431 or retrieved at step 1440). Next, at step 1450, AP initiates the 4-way handshake by transmitting the 4-way Handshake message 1. Next, at step 1460, when it transmits the Message 3 of the 4-way handshake, it includes into it a KDE container referred to as PMKIDMask KDE, for holding the new PMKID mask PMKID MASK generated at step 1415. The PMKIDMask ID KDE is included in the Key Data field which is encrypted. At step 1440, AP de-obfuscates the received PMKID. For this, for each stored PMKID mask PMKID MASK TEST, it retrieves its corresponding PMKID referred to as PMKID TEST and operates a demasking operation by XORing the PMKID^MASK TEST and PMKID TEST. The output of the demasking operation is referred to as PMK1DTESTOUT and the AP checks whether it corresponds to a PMKID of a cached PMKSA into its PMKSA cache. If yes, the dc-obfiiscated PMKID corresponds to PMKID OUT TEST and its corresponding PMKSA corresponds to the PMKSA of the non-AP STA. Next step is 1432. Fourth exemplary embodiments According to fourth exemplary embodiments of the disclosure, the generation of the PMKID is made dependent from an identifier (referred to PMKIDNonce) provided by the AP. The PMKIDNonce may be the Device ID or any random number. As the identifiers described in the other exemplary embodiments, the PMKIDNonce should not be transmitted more than once in clear over the air and changed at every association to keep privacy and prevent tracking. By changing the way the PMKID is calculated and making it based on tire PMKIDNonce, security is increased as it becomes difficult for a third party to determine the PMK using a dictionary attack. Figure 15 schematically illustrates exemplary sequences of messages between a non-AP STA operating an RCM and an AP STA for operating a PMKSA caching mechanism according to fourth exemplary' embodiments of the disclosure. The illustration relies on an 802.1X / EAP-based authentication involving an authentication server. However, the PMKSA caching may be established as a result of any other authentication method discussed above (involving or not an AS). In the illustration of figure 15, the PMKIDNonce generated by the AP at the first association is referred to as PMKIDNonce# 1, and the second generated PMKIDNonce is referred to as PMKIDNonce#2. PMKID# 1 corresponds to the PMKID generated based on the PMK and PMKIDNonce#!. PMKID#2 corresponds to the PMKID generated based on the PMK and PMKIDNonce#2. Figure 15a illustrates, using a flowchart, main steps of a communication method at non-AP STA (Client), according to fourth exemplary embodiments of the disclosure. The illustration relies on an 802. IX / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). First, at step 1510, the non-AP STA operates an RCM procedure and changes its MAC address referred to as RCM-MAC-Address. Next, at step 1520, when the non-AP STA intends to associate with an AP, it checks by using the MAC address of AP 420 if it has a cached PMKSA corresponding to the said AP. If yes, it retrieves a cached PMKSA corresponding to said AP and next step is step 1540. If not, next step is 1530. At step 1530, the non-AP STA initiates the association procedure with the AP 420 in which it indicates in RSNE of the (Re)Association Request frame its supported Group and Pairwise Cipher suites, its supported Authentication and Key Management (AKM) suites and sets the field ‘PMKID count” to 0. hr complement, the non-AP STA indicates its PMKSA Caching Privacy Support by setting the PMKSA Caching Privacy Support subfield to 1 in RSN RSNXE of the (Re)Association Request frame Next, step 1531 corresponds to the full EAP authentication involving EAP and RADIUS performed between the AP 420 and the non-AP STA. When a full EAP authentication completes successfully, at step 1532, the STA generates a Pairwise Master Key Security Association (PMKSA) comprising one or more of the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, MAC address of the said AP, a lifetime and the negotiated Authentication and Key Management (AKM). As no PMKIDNonce is previously received yet, the PMKID is computed / derived from the PMK, for example as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” 11 AA {{ SPA)) wherein HMAC-SHA-1 is a cry ptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of the bit string S starting from the left, AA the MAC address of the AP 420 and SPA the current MAC address of STA 410. Alternatively, the PMKID is not generated and the initial PMKSA (when first established) does not contain a PMKID. The non-AP STA store the generated PMKSA into its PMKSA cache. Next, at step 1550, the non-AP STA initiates the 4-way handshake at the reception of the 4-way Handshake message 1 from the AP. Next, at step 1560, when it receives the Message 3 of the 4-way handshake, the non-AP STA extracts and decrypts the PMKIDNonce contained in the PMKIDNonce KDE of the Key Data field. The PMKIDNonce is stored and indexed with the MAC address of the AP 420. If a PMKIDNonce corresponding to AP 420 is already stored, it is replaced by the received PMKIDNonce. At step 1540, the non-AP STA retrieves the PMKIDNonce corresponding to AP 420. Next, at step 1541, the non-AP STA computes a new identifier PMKID-RCM using the PMK of the retrieved cached PMKSA corresponding to the said AP and the PMKIDNonce retrieved at step 1540, for example, as follows: PMKID-RCM = Truncate-128(HMAC-SHA-1 (PMK, “PMKName" \ \ PMKIDNonce)) Next, at step 1542, the non-AP STA initiates the association procedure by transmitting an association request. The association request includes the PMKSA Caching Privacy Support of the non-AP STA by setting the PMKSA Caching Privacy Support subfield in the RSNXE to 1 in RSNXE. Moreover, the non-AP STA sets the “PMKID Count" field to 1 and includes the new PMKID corresponding to the said AP generated at step 1541 in the RSNE of the association request. Next step is 1550. Figure 16 illustrates, using a flowchart, main steps of a communication method at an AP, according to fourth exemplary embodiments of the disclosure. The illustration relies on an 802.IX / EAP-based authentication and a 4-way handshake procedure. However, any other authentication method discussed above can be used (involving or not an AS). When an AP supporting the PMKSA Caching Privacy Support operates association procedure with a said non-AP STA (Client) which has advertised its support to the PMKSA Caching Privacy Support in the association request (step 1610), it generates at step 1615 a new PMKIDNonce. PMKIDNonce corresponds to a sequence of random bits or to Device ID for example. Next, the AP checks at step 1620 if a full EAP-based authentication is necessary or not. For this, it checks in the received association request if the non-AP STA sets the field “PMKID count” to 0. If yes, next step is step 1630. If not, next step is 1640. Step 1630 corresponds to the example of a full EAP authentication involving EAP and RADIUS performed between the AP and die STA. Next, at step 1631, the AP generates and caches a PMKSA comprising one or more of the following parameters: a Pairwise Master Key Identifier (PMKID), PMK, MAC address of the AP, a lifetime and the negotiated Authentication and Key Management (AKM). The PMKID is computed / derived from the PMK and the PMKIDNonce generated at step 1615, for example as follows: PMKID = Truncate-128(HMAC-SHA-1(PMK, “PMKName” \ \ PMKIDNonce)) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of Next, at step 1650, AP initiates the 4-way handshake by transmitting the 4-way Handshake message 1. Next, at step 1660, when it transmits the Message 3 of the 4-way handshake, it includes into it a KDE container referred to as PMKIDNonce KDE, for holding the new PMKIDNonce generated at step 1615. The PMKIDNonce ID KDE is included in the Key Data field which is encrypted. At step 1640, AP retrieves the cached PMKSA corresponding to the PMKID included in the field “PMKID List” of the association request received from the said Client. At step 1642, AP updates the PMKSA by updating the PMKID with the new PMKIDNonce generated at step 1615. The updated PMKID, referred to as RCM PMKID, is computed for example as follows: PMKID = Truncate-128(HMAC-SHA-1 (PMK, “PMKName ” 11 PMKIDNonce) wherein HMAC-SHA-1 is a cryptographic hash function specified in IETF RFC 2104 and FIPS (Federal Information Processing Standard) 180-4 publications. Truncate-N(S) is bits 0 to N-l of. Next step is 1650. Figure 17 schematically illustrates a communication device 1700, typically any of the stations of Figure 1, of a wireless network, configured to implement at least one of the exemplary embodiments of the present disclosure. The communication device 1700 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 1700 may comprise a communication bus 1713 to which may be connected: - a central processing unit 1701, such as a processor, denoted CPU; - a memory 1703, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and - at least two communication interfaces 1702 and 1702’ connected to the wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 1704 and 1704’, respectively. Preferably the communication bus 1713 may provide communication and interoperability between the various elements included in the communication device 1700 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1700 directly or by means of another element of the communication device 1700. The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1702 or 1702’, in order to be stored in the memory 1703 of the communication device 1700 before being executed. In an embodiment, the device 1700 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Embodiment(s) of the present invention can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be referred to more fully as a “non-transitory computer-readable storage medium") to perform the functions of one or more of the above-described embodiment(s) and / or that includes one or more circuits (e.g., application specific integrated circuit (ASIC)) for performing the functions of one or more of the abovedescribed embodiment(s), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiment(s) and / or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). Ure computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium. Tire storage medium may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), etc.), a flash memory device, a memory card, and the like. Expressions such as “comprise”, “include”, “incorporate”, “contain”, “is” and “have” are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural 5 and vice versa. A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed may be combined without departing from the scope of the invention. As an example, the embodiments described above consider one or more privacy 10 parameters to be changed.

Claims

1. A communication method performed by an access point (AP) of a set of basic service sets (BSSs), comprising:receiving, from a station capable of changing its medium access control (MAC) address, an identifier assigned to the station by an AP of the set of BSSs for identifying the station within the set of BSSs;obtaining a cached Pairwise Master Key (PMK) associated with the station using the received identifier; andgenerating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP.

2. The communication method according to claim 1, wherein obtaining the PMK comprising retrieving, from a cache table, the PMK using the identifier.

3. The communication method according to claim 1 or 2, wherein the identifier is a device identifier (Device ID) assigned by the AP during a 4-way handshake procedure performed between the station and the AP.

4. The communication method according to claim 1, 2 or 3, wherein the identifier is assigned by the AP performing the method.

5. A communication method performed by an access point (AP), comprising:receiving, from a station capable of changing its medium access control (MAC) address, an identifier (PMKID) identifying a cached Pairwise Master Key (PMK), the PMK identifier being generated based on a first MAC address of the station different from a second MAC address used by the station at the receiving;obtaining a cached PMK associated with the station using the received PMK identifier; andgenerating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP.

6. The communication method according to claim 5, wherein obtaining the PMK comprising retrieving, from a cache table, the PMK using the received PMK identifier.

7. The communication method according to claim 5 or 6, further comprising, afterobtaining the PMK,generating an PMK identifier based on the second MAC address of the station; and updating indexing of the cached PMK with the generated PMK identifier.

8. The communication method according to claim 1, wherein the first MAC address corresponds to the MAC address of the station at indexing of the cached PMK by the PMK identifier was last updated.

9. A communication method performed by a non-access point (AP) station, comprising:generating a Pairwise Master Key (PMK) identifier for identifying a PMK based on a first media access control (MAC) address of the station;changing the MAC address of the station from the first MAC address to a second MAC address; andsending, using the second MAC address of the station, the PMK identifier generated based on the first MAC address.

10. The communication method according to claim 9, further comprising, after sending the association request to the AP, re-generating the identifier based on the second MAC address of the station and updating indexing of a cached PMK using the re-generated identifier.

11. The communication method according to claim 9 or 10, wherein the PMK identifier is sent to the AP in an association request.

12. A communication method performed by an access point (AP), comprising:receiving, from a station capable of changing its medium access control (MAC) address, an encoded identifier (PMKID) identifying a Pairwise Master Key (PMK), the identifier being based on a MAC address of the station at the time indexing of the PMK by the identifier was last establisheddecoding the received encoded identifier;obtaining a PMK associated with the station using the decoded identifier; andgenerating a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP.

13. The communication method according to claim 12, further comprising receiving from the station, via a secured channel, a code and wherein the encoded identifier is decoded using the code for retrieving the decoded identifier.

14. The communication method according to claim 13, wherein the received code is a random number and wherein the decoding comprising apply ing an XOR operation between the random number and the encoded identifier.

15. Ure communication method according to claim 12, 13 or 14, wherein obtaining the PMK comprising retrieving, from a cache table, the PMK using the identifier.

16. A communication device comprising:a reception unit configured to receive, from a station capable of changing its medium access control (MAC) address, an identifier assigned to the station by an AP of the set of BSSs for identifying the station within the set of BSSs;an obtention unit configured to obtain a cached Pairwise Master Key (PMK) associated with the station using the received identifier; anda generation unit configured to generate a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP.

17. The communication device according to claim 16, further comprising a cache table and wherein the obtention unit is configured to retrieve the PMK from the cache table using the device identifier.

18. A communication device compri sing:a reception unit configured to receive, from a station capable of changing its medium access control (MAC) address, an identifier (PMKID) identifying a cached Pairwise Master Key (PMK), the PMK identifier being generated based on a first MAC address of the station different from a second MAC address used by the station at the receiving;an obtention unit configured to obtain a cached PMK associated with the station using the received PMK identifier; anda generation unit configured to generate a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP.

19. A communication device comprising:generating a Pairwise Master Key (PMK) identifier for identifying a PMK based on a first media access control (MAC) address of the station;a changing unit configured to change the MAC address of the station from the first MAC address to a second MAC address; anda sending unit configured to send, using the second MAC address of the station, the PMK identifier generated based on the first MAC address.

20. A communication device comprising:a reception unit configured to receive, from a station capable of changing its medium access control (MAC) address, an encoded (obfuscated) identifier (PMKID) identifying a Pairwise Master Key (PMK), the identifier being based on a MAC address of the station at the time indexing of the PMK by the identifier was last establisheda decoder configured to decode the received encoded identifier;an obtention unit configured to obtain a PMK associated with the station using the decoded identifier; anda generation unit configured to generate a Pairwise Transient Key (PTK) based on the obtained PMK for encrypting messages exchanged between the station and the AP.

21. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a communication device, causes a 5 communication device to execute a communication method according to anyone of claim 1, 5, 9 and 12.

Images