Method and apparatus for performing an enhanced fast BSS transition for CPE stations implementing changing MAC address

Abstract

A wireless communication method comprising, a station, associating with a first access point (AP) using a first media access control (MAC) address of the station 601, and generating a first Pairwise Master Key (PMK), associated with the first AP, based on a station identifier 605. The station reassociates with a second AP using a second MAC address of the station 602, and generates a second PMK, associated with the second AP, based on the station identifier 607. The station then generates a Pairwise Transient Key (PTK) based on the generated second PMK for encrypting messages exchanged between the station and the second AP 609. The station may further generate a primary, or level 1, PMK (PMK-R0) based on the station identifier and a primary PMK identifier (PMKR0ID) for identifying the PMK-R0. The PMKs associated with the APs may be generated based on the PMK-R0. The method is an extension of fast BSS transition (FT) methods. A wireless communication method wherein a station identifier is transmitted from a network controller to an AP, where it is stored in a cache table alongside an associated PMK-R0 identifier is also disclosed.

Description

TECHNICAL FIELD The present disclosure relates to wireless communications and more specifically to user privacy during roaming between basic service sets (BSSs). BACKGROUND The approaches described in this background section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section. Today, 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 wireless services and the user experience. PH 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, Pll 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. Below, the Pll are referred to as privacy parameters or PE, Privacy Enhancements, parameters. The IEEE 802.11 working group has then proposed a first procedure to limit the risk for a user to be traced, which consists in dynamically modifying the MAC address of the user device. This mechanism, called Randomized and Changing MAC (RCM) procedure, has been originally introduced as a privacy enhancing feature in the 802.11 aq Pre-Association Service Discovery Task Group and finally included in the standard IEEE Std 802.11-2020. It comprises periodical change of the MAC address of a non-Access Point (AP) station, also named Client, to a random value while it is not associated with a network or, equivalently, with an Access Point (AP). In order to go further in terms of privacy, a dedicated task group IEEE 802.11 bi has been initiated to specify a set of Client Privacy Enhancements (CPE) features that stations, referred to as CPE-capable STAs, could implement in the next version of standard 802.11. One of the specified CPE features is the ability for a CPE-capable non-AP STA (CPE non-AP STA or CPE Client) to change randomly its privacy parameters such as its MAC address while it is also associated with a CPE-capable AP (referred to as CPE AP) without any loss of connection. A second specified CPE feature is that this change shall be also effective when the CPE client operates a BSS Transition mechanism consisting in a roaming between two CPE APs. Amongst the standardized BSS Transition mechanisms, the Fast BSS Transition (FT) mechanism specified in the 802.11r amendment is currently the most used. In this context, a mobility domain, identified by a Mobility Domain IDentifier (MDID), is a set of basic service sets (BSSs), within the same extended service set (ESS), that support Fast BSS Transitions (FTs) between themselves and that are identified by the set’s MDID. FT allows to reduce strongly the handoff times during the roaming between two APs belonging to a same mobility domain while maintaining the QoS security for delaysensitive applications. For this, a full authentication is operated only with a first AP in the mobility domain and a shorter authentication is operated when the client associates with the next APs in the same mobility domain. The FT mechanism relies on a specific multi-layer hierarchy of cryptographic keys in which the keys of the next APs are generated before their effective use, and more precisely when the client operates the full authentication with the first AP. These keys form a set of keys associated with the client and dedicated for the FT of the client. For this, the MAC address of the Client is used for keys generation and these keys are used when operating the full authentication with the first AP. Also, the MAC address is used again for identifying the set of keys operated by the next AP during the shorter authentications. However, in the context of CPE, the MAC address of a CPE Client changes regularly and notably between the initial full authentication and the next shorter authentications with the next CPE APs; these next CPE APs are no longer capable of identifying the CPE Client and retrieving its set of keys. There is a need to provide improved support for mobility, such as CPE Clients roaming between APs of the mobility domain. SUMMARY The present invention has been devised to address one or more of the foregoing concerns. It concerns the definition and the use of an identifier for a station. This identifier, which is also named MD_STA_identifier in the following, is unique in the mobility domain and is permanent at least for the time the station is in communication with APs of the mobility domain. This identifier is used for the generation of the set of keys used for fast BSS transition and for the identification of this set of keys during the next authentications with an AP of the mobility domain. Embodiments of the invention deal with the amendments to the known methods related to the introduction of this new identifier. According to a first aspect of the invention there is provided a wireless communication method comprising, ata station: associating with a first access point (AP) using a first media access control (MAC) address of the station; generating a first Pairwise Master Key (PMK), associated with the first AP, based on a station identifier; reassociating with a second AP using a second MAC address of the station; generating a second PMK, associated with the second AP, based on the station identifier; and generating a Pairwise Transient Key (PTK) based on the generated second PMK for encrypting messages exchanged between the station and the second AP. Use of a persistent identifier for the station during roaming advantageously allows to have the PMK generated once and used without having to regenerate it although the station has changed its MAC address. The session key (PTK) can thus be generated securely and without delay ensuring a fast BSS transition. According to embodiments, the method comprises generating a primary PMK (PMK-RO) based on the station identifier and its associated primary PMK identifier (PMKROID). The generating of the first PMK, associated with the first AP, and the generating of the second PMK, associated with the second AP, are then based on the PMK-RO. Using a primary key (PMK-RO) allows to increase security as it is sufficient, according to embodiments of the invention, to transmit the primary PMK identifier (PMKROID) to the second AP, to allow the second AP to retrieve the PMK it received and use it for generating the PTK. It is to be noted that the station does not have to communicate the identifier to the second AP through the wireless channel that may be subject to eavesdropping, increasing thus security. From a controller perspective, embodiments of the invention relate to a wireless communication method comprising: generating a primary Pairwise Master Key (PMK)-R0 based on a station identifier; generating a primary PMK identifier (PMKROID) for identifying the generated PMK-RO; generating a PMK, associated with an access point (AP), based on the station identifier; generating a PMK identifier (PMKID) for identifying the generated PMK; and transmitting, to the AP, the PMK-RO, PMKROID, PMK and PMKID for the AP to generate a Pairwise Transient Key (PTK) for encrypting messages exchanged between the station and the AP. The parameters transmitted by the controller to the AP may be cached by the AP in a cache table and used to retrieve the PMK associated with a given station reassociating with the AP and that has initially associated at least once to another AP of the mobility domain. In a preferred implementation, the controller is located within a same apparatus than the other AP (initial AP). The controller may be located in any device in the network with a secured channel with the APs of the mobility domain. According to embodiments, the station is associated with a first AP using a first media access control (MAC) address prior reassociating with the AP using a second MAC address. From a target AP perspective (a target AP being the AP towards which the station performs the roaming), embodiments of the invention relate to a wireless communication method comprising: establishing a cache table comprising, for an entry associated with a station, a plurality of parameters received from a controller, the parameters comprising: a station identifier, a primary Pairwise Master Key (PMK)-R0 identifier (PMKROID) generated based on the station identifier, a PMK, associated with the AP, generated based on the station identifier and a PMK identifier (PMKID) identifying the PMK; associating with a station using a medium access control (MAC) address of the station; receiving from the station a primary PMK identifier (PMKROID); retrieving the station identifier from an entry of the cache table having a cached PMKROID matching the received PMKROID; generating a PMKID, associated with the AP, using the retrieved station identifier, retrieving the PMK received from the controller from an entry of the cache table having a cached PM KID matching the generated PM KID; and generating a Pairwise Transient Key (PTK) based on the retrieved PMK for encrypting messages exchanged between the station and the AP. The target AP is thus able to retrieve the PMK stored in its cache table without regenerating it and relying only on the PMKROID received from the station side through the wireless channel, and even if the station has changed its MAC address. Security is thus increased and roaming latency reduced. In a preferred implementation, the station identifier is set to a first MAC address. This allows to have simple initial association as it’s done the conventional way. It is being understood that when the station changes its MAC address, the identifier is kept unchanged (and thus equal to the first MAC address) for, at least, as long as it is desired to take benefit from previously generated PMK in the mobility domain. Alternatively, the station identifier (Device ID) is set to a device identifier associated with the station. This identifier may be already set by an AP and thus it may be advantageously reused as a persistent or permanent identifier in the embodiments of the invention. Correlatively, the invention also provides a wireless communication station, a network controller and access points comprising at least one microprocessor configured for carrying 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 THE DRAWINGS Embodiments of the invention 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 invention may be used; Figure 2 schematically illustrates an exemplary sequence of messages for operating a FT initiated by a client as specified in standard IEEE Std 802.11-2020; Figure 3 schematically illustrates an exemplary sequence of messages for operating a FT initiated by a CPE Client, according to one or several embodiments of the invention; Figure 4 illustrates a Fast BSS Transition (FT) Information Element (IE) in accordance with embodiments of the present invention; Figure 5 illustrates embodiments of the invention and the different exchanges between the different key holders; Figure 6 illustrates the main steps of a method for FT by a station according to embodiments of the invention; Figure 7 illustrates the main steps of a method for FT by a first AP, AP1, according to embodiments of the invention; Figure 8 illustrates the main steps of a method for FT by a next AP, AP2, according to embodiments of the invention; and Figure 9 schematically illustrates a communication device of a wireless network, configured to implement at least one embodiment of the present invention. Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and SingleCarrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e., wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to a different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. The 802.11 family of standards adopted by the Institute of Electrical and Electronics Engineers (IEEE) is an example specification providing a great number of mechanisms for wireless communications between stations. The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (AP) or non-AP station (STA). Figure 1 illustrates an example wireless communication network 100 in which embodiments of the invention may be implemented. The illustrated wireless communication network 100 includes a distribution system 110 interconnecting a set of basic service sets (BSSs) of an extended service set (ESS) 120. Each BSS is formed by a single access point (AP) together with wireless client devices (STAs), creating a wireless local area network (WLAN). Each STA may receive a signal from several APs within their range. Depending on its configuration, each STA can, manually or automatically, select the network with which to associate. The multiple APs may share a common service set identifier (SSID) as part of the ESS. 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 can 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 cryptographic keys without exposure to any intermediate parties. The cryptographic strength of the secure channel in the distribution system is assumed to be greater than or equal to the cryptographic strength of the channels used in the ESS. The secured channel may be a wireless or a wired backhaul network. In Figure 1, three WLANs of multiple (n) WLANs in ESS 120 are illustrated. A first WLAN comprises AP 131-1 and STAs 135-1 and 136-1 and covering an area 130-1. A second WLAN comprises AP 131-2 and STA 135-2 and covering an area 130-2. And a third WLAN comprises AP 131-n and STA 135-n and covering an area 130-n. The shown coverage areas 130-1, 130-2 and 130-n are for illustration only; they may have different coverages and shapes in a real environment. 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, a 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 (next) AP. The switching between APs is called roaming. Mobility domain A mobility domain is a set of basic service sets (BSSs), within a same extended service set (ESS), that support Fast BSS Transitions (FTs) between themselves. For example, the mobility domain may correspond to the ESS 120. As noted earlier, the mobility domain may be identified by a Mobility Domain IDentifier (MDID). In some embodiments, the Mobility domain contains also a network controller in which an authentication server, as a Remote Authentication Dial-In User Service (RADIUS) server, is used to process Authentication, Authorization, and Accounting (AAA) transactions. FT protocol In a basic BSS transition, a client connected to a first AP of the mobility domain, and that switches to another AP in the same mobility domain, initiates with the other AP firstly a full re-authentication and re-association procedure and secondly performs a legacy 4-way handshake to generate the session cryptographic key used to encrypt the further data to be transmitted. However, this basic transition mechanism takes time and provokes typically service interruption for delay-sensitive multimedia, voice or video application, especially in a strongly secured WLAN (e.g., employing IEEE802.1x and Extensible Authentication Protocol (EAP) methods for authentication). In order to significantly reduce this handoff time between the client and the network while maintaining security and QoS, a mechanism referred to as Fast BSS Transition (FT) has been specified by the 802.11 r amendment consisting in enabling fast secure roaming. For this, the client, referred to as FT Originator or FTO, operates a complete authentication / association with only one AP, referred to as first (or initial) AP, during a FT initial mobility domain association, and use shorter authentications with the next (or target) APs belonging to the same mobility domain as the first AP. FT introduces a new Authentication and Key Management (AKM) based on an hierarchical security key management scheme composed of three levels in which some components, referred to as security key holders (KHs), have specific security functions such as keys generation and distribution. KHs are part of either the AP key management, called authenticator KH, or the Client key management, called supplicant KH. The terms “authenticator”, “supplicant”, “authenticator KH” and “supplicant KH” are also used respectively for AP, Client, AP key management, Client key management. A first KH is a supplicant KH physically located in the client (STA) and referred to as SOKH. The performed functions are to derive and hold a first level (or primary) Pairwise Master Key (PMK-RO) from the Master Pairwise Master Key (MPMK) shared secretly between the AP and the client, derive from the key PMK-RO a second level (or secondary) Pairwise Master Key (PMK-R1) specific to the AP the client is currently associated with and provide the key PMK-R1 to a second supplicant KH physically located in the client. SOKH is identified by the identifier SOKH-ID set to the MAC address of the client. The second supplicant KH is referred to as S1 KH. It receives a key PMK-R1 from the SOKH, holds the key PMK-R1, and derives from it the Pairwise Transient Keys (PTKs) used to encrypt the further transmitted data. S1KH is identified by the identifier S1KH-ID set to the MAC address of the client. A third KH is an authenticator KH referred to as ROKH. Its functions are to derive and hold a first level key PMK-RO from the MPMK, derive from PMK-RO second level keys PMK-R1s, each one being specific to an AP, and distribute the keys PMK-R1s to KHs referred to as R1KHs. According to some embodiments, ROKH is physically part of the first AP of the mobility domain with which the station authenticates. In these embodiments, ROKH is identified by the identifier ROKH-ID set to the MAC address of the first AP. According to other embodiments, it is physically part of the network controller of the mobility domain. In these other embodiments, ROKH is identified by an identifier of the network controller (e.g., not longer than 48 bits). For the sake of clarity, it is considered hereinafter that ROKH is physically part of the first AP, unless otherwise stated. The fourth KH, referred to as R1KH, is an authenticator KH physically located in each AP of the mobility domain (including the first AP) that receives a PMK-R1 from ROKH, holds the key PMK-R1, and derives from it the PTKs. R1KH is identified by the identifier R1KH-ID set to the MAC address of the AP. The keys managed by these key holders may be seen as sets of keys dedicated to the FT in a mobility domain. These sets of keys are associated with a station (client) or an AP. They are identified by the MAC address of the station or the AP they are associated with. The MAC address of a station or an AP is assumed to feature a unique and permanent identifier of the station or of the AP. Based on the security key management scheme, a three level key hierarchy has been specified for FT in a mobility domain. The key PMK-RO is the first level of the FT key hierarchy. This key is unique to each client and remains the same for the client as long as the client is associated within the same mobility domain. PMK-RO is derived from the Master Pairwise Master Key (MPMK) shared secretly by the client and the AP master session key (MSK), the identifiers SOKH-ID and ROKH-ID are set respectively to the client’s MAC address and to the AP’s MAC address. Some other parameters can be also used as the Service Set IDentifier (SSID), the length of the SSID (SSIDIength), the Mobility Domain IDentifier (MDID) and the length of the identifier ROKH-ID (ROKHIength). The key derivation function used for generating PMK-RO is the Key Derivation Function KDF-Hash-Length as specified in sections 12.7.1.6.2 and 12.7.1.6.3 of the standard IEEE Std 802.11-2020: RO-Key-Data = KDF-Hash-Length(MPMK, “FT-RO”, SSIDIength || SS / D || MDID || ROKHIength || ROKH-ID || SOKH-ID); PMK-RO = L(R0-Key-Data, 0, Q); with L(S, F, N) is bits F to F+N-1 of the bit string S starting from the left and Q the length of the key PMK-RO based on the negotiated AKM during the association. The operator “||” represents the binary concatenation. “FT-RO” is a string name and is treated as an ASCII string. In Addition, an identifier / name is assigned to PMK-RO, referred to as PMKROName (or PMKROID), and is computed as: PMK-ROName-Salt = L(RO-Key-Data, Q, 128); PMKROName = Truncate-128(Hash(“FT-R0N"\\ PMK-ROName-Salt)); where Hash is a hash function selected according to the negotiated AKM during the association and Truncate-128 is the function which selects the first 128 bits of the output. “FT-RON” is a string name and is treated as an ASCII string. . The key PMK-R1 is the second level of the FT key hierarchy. It is derived from the first level PMK (PMK-RO) and the identifiers S1KH-ID and R1KH-ID set respectively to the client’s MAC address and AP’s MAC address. The key derivation function is also the Key Derivation Function KDF-Hash-Length as specified in sections 12.7.1.6.2 and 12.7.1.6.4 of the standard IEEE Std 802.11-2020: PMK-R1 = KDF-Hash-Length(PMK-R0, “FT-R1”, R1KH-ID || S1KH-ID); An identifier / name is also assigned to PMK-R1, referred to as PMKRIName (or PMKR1ID), and is computed as: PMKRIName = Truncate-128(Hash(“FT-R1N” || PMKROName || R1KH-ID || S1KH-ID)); where “FT-R1” and “FT-R1N” are string names and are treated as an ASCII string. The third and last level key in the FT key hierarchy is the PTK, the session key used to encrypt the further transmitted data. It is derived from the key PMK-R1 and a list of parameters comprising a 256-bit random bit string contributed by the S1KH (SNonce), a 256-bit random bit string contributed by the R1KH (ANonce), the client’s MAC address (STA-ADDR) and the AP’s MAC address (also named BSSID). The key derivation function is also the Key Derivation Function KDF-Hash-Length specified in sections 12.7.1.6.2 and 12.7.1.6.5 of the standard IEEE Std 802.11-2020: PTK = KDF-Hash-Length(PMK-R1, “FT-PTK”, SNonce || ANonce || BSSID || STA-ADDR); where “FT-PTK’ is a string name and is treated as an ASCII string. Back to the Figure 1, clients (e.g., 135-1, 136-1, 135-2, ..., 135-n) and the corresponding APs (e.g., 131-1, 131-2, ..., 131-n) are CPE-Capable meaning that they implement Client Privacy Enhancements (CPE) features. One of this Client Privacy Enhancements (CPE) features is the ability for the non-AP STAs to change randomly their privacy parameters such as their MAC address while they are associated with an AP, referred to as CPE AP, without any loss of connection. In such a context, a non-AP station implementing CPE features is referred to as CPE-capable non-AP STA or CPE non-AP STA or CPE Client. Similarly, a FTO implementing CPE features is referred to as CPE FTO. Similarly, an AP station implementing CPE features is referred to as CPE-capable AP or CPE AP. Figure 2 schematically illustrates an exemplary sequence of messages 200 for operating a FT initiated by a client as specified in standard IEEE Std 802.11-2020. The sequence 200 involves a first sequence of messages (241, 242, 243, 244 and 245) referred to as FT initial mobility domain association (IMDA) 240 involving the FTO 210, a first AP 220 (AP1) and a Network Controller 245, and a second sequence of messages (251, 252, 253 and 254) referred to as FT protocol involving the FTO 210 and a next AP 230 (AP2). The APs 220 and 230 belong to a same Mobility Domain, referred to as md1. As indicated on the figure and detailed below, these two sequences of messages are based on the FTO MAC address. The MAC address of FTO 210 is referred to mac_fto_0 during the FT IMDA and mac_fto_1 during the FT protocol. In the standard IEEE Std 802.11-2020, the stations (Client and AP) are not CPE-capable meaning that FTO 210 doesn’t change its MAC address overtime, and consequently the MAC addresses mac_fto_0 and mac_fto_1 are the same in this context. The MAC address of the first AP 220 is referred to mac_ap_1 and the MAC address of next AP 230 is referred to mac_ap_2. When the FTO 210 detects the presence of the first AP 220, FTO 210 initiates the FT IMDA 240 by initiating a Client Authentication / Association exchange 241. For this, FTO 210 transmits an authentication request to first AP 220. After receiving the authentication request, first AP 220 sends an authentication response to FTO 210. In some embodiments, the exchange of the authentication request and authentication response corresponds to the Open System authentication mechanism in accordance with the IEEE Std 802.11-2020. Next, upon successful authentication, FTO 210 sends an association request with a Robust Security Network Information Element (RSNIE) indicating the Authentication and Key Management (AKM) and a Mobility Domain Information Element (MDIE) indicating the existence of the mobility domain md1 and the support of FT procedures. First AP 220 may also advertise the content of MDIE in its beacon or probe response frames. Once receiving the association request, first AP 220 sends an association response to FTO 210 indicating whether the association is accepted or not. If yes, the association response includes a Fast BSS Transition (FT) Information Element (IE) specifying the identifiers R0KH-ID and R1KH-ID. Upon successful association between FTO 210 and first AP 220, the supplicant key holder (S0KH) of FTO 210 derives PMK-R0 (also referred to as PMK-R0[FTO]) from the MPMK as described previously by using the current MAC address of FTO 210 mac_fto_0 as S0KH-ID and an identifier of the network controller 225 as R0KH-ID. S0KH generates also a key identifier (digest) PMKROName[FTO, AP1] corresponding to PMK-R0 (also called PMKR0ID). In the following, PMKROName[FTO, AP1] may also be referred to as PMKR0Name[AP1] or simply PMKROName. Without explicit indication, PMKROName corresponds to the pair FTO and the AP involved in the FT initial mobility domain association (IMDA). Next, S0KH derives the key PMK-R1 relative to first AP 220 (referred to as PMK-R1[FTO, AP1]) from PMK-R0 as described previously by using the current MAC address of FTO 210 mac_fto_0 as S1KH-ID and the MAC address of first AP 220 mac_ap_1 as R1KH-ID. Finally, S0KH provides PMK-R1[FTO, AP1] and PMKROName to S1KH. The first AP 220 sends to the Network Controller 225 in a message 242 the MPMK and the current MAC address of FTO 210 mac_fto_0. The authenticator's key holder (R0KH) of Network Controller 225 derives PMK-R0 from the MPMK (provided by message 242) as described previously by using the current MAC address of FTO 210 mac_fto_0 (provided by message 242) as S0KH-ID and an identifier of the network controller 225 as R0KH-ID. R0KH generates also the identifier PMKROName corresponding to PMK-R0. Next, R0KH generates a set of PMK-R1s {PMK-R1[FTO, AP1], PMK-R1[FTO, AP2]}, each one corresponding to an APi of the mobility domain md1 (here AP1 and AP2) and derived from PMK-R0 as previously described by using the current MAC address of FTO 210 mac_fto_0 as S1 KH-ID and the MAC address of APi as R1 KH-ID. For instance, a first PMK-R1[FTO, AP1] is generated relative to first AP 220 by using its MAC address mac_ap_1 and a second one PMK-R1[FTO, AP2] is generated relative to next AP 230 by using its MAC address mac_ap_2. For each PMK-R1[FTO, APi], a corresponding identifier / name PMKR1Name[FTO, APi] (also referred to as PMKR1Name[APi] or PMKR1ID[APi])) is derived from the PMKROName, the current MAC address of FTO 210 mac_fto_0 as S1KH-ID and the MAC address of APi (mac_ap_1 for first AP 220 or mac_ap_2 for next AP 230) as R1KH-ID. Once generated, R0KH propagates the PMK-R1s to the corresponding APi of the mobility domain md1 (here AP1 and AP2). For this, it sends through the secure channel of the distribution system a message 243 to the first AP 220 including the PMK-R1[FTO, AP1] and its corresponding PMKR1Name[AP1], and a message 244 to AP230 including the PMK-R1[FTO, AP2] and its corresponding PMKR1Name[AP2]. Once the PMK-R1 [FTO, APi] and the associated PMKR1 Name[APi] received, the R1KH of each APi updates a hash table, referred to as FTO hash table, for which the PMKR1Name[APi] is used as a hash key for retrieving the key PMK-R1[FTO, APi], De facto, the R1KH of first AP 220 updates its FTO hash table with the hash key PMKR1Name[AP1] and the value PMK-R1[FTO, AP1], and the R1KH of next AP 230 updates its FTO hash table with the hash key PMKR1Name[AP2] and the value PMK-R1[FTO, AP2], The R1KH of first AP 220 initiates a 4-way handshake 245 in which the S1KH and R1KH generate and exchange the parameters SNonce and ANonce required to derive a session key PTK, referred to as PTK[FTO, AP1] from the PMK-R1[FTO, AP1] as described previously. Next, the data exchanged between the FTO 210 and first AP 220 are encrypted with the key PTK[FTO, AP1], The 4-way handshake is a method for a non-AP station and an AP station to agree on a shared secret. According to this method, the shared secret is not exchanged between the non-AP station and the AP station and it cannot be determined by a third party from the exchanged messages. When FTO 210 roams to a new location, it may decide to initiate a FT protocol 250 from first AP 220 to next AP 230 which is located in the same mobility domain. As indicated previously, the R1KH of next AP 230 may store, for different FTOs (FTOk), a set of PMK-R1s {PMK-R1[FTOk, AP2]} in a FTO hash table, each PMK-R1[FTOk, AP2] being identified by a hash key PMKR1Name[FTOk, AP2] and corresponding to an FTOk which has already initiated a FT IMDA with one of the APs of the same mobility domain as of next AP 230. From the MAC address of next AP 230 mac_ap_2, S0KH of FTO 210 derives a new key PMK-R1 referred to as FT-PMK-R1[FTO, AP2] relative to next AP 230 from PMK-R0 as described previously by using the current MAC address of FTO 210 mac_fto_1 as S1KH-ID and the MAC address of next AP 230 mac_ap_2 as R1KH-ID. Once generated, it provides FT-PMK-R1[FTO, AP2] to S1KH. Once the FT-PMK-R1[FTO, AP2] received, S1KH of FTO 210 stores it and generates a SNonce to be transmitted to the R1KH of next AP 230 necessary for generating a session key PTK[FTO, AP2], For this, S1KH of FTO 210 sends an authentication Request 251 to next AP 230 with a SA field of its header set to the MAC address of the FTO 210, and a DA field set to the MAC address of next AP 230 mac_ap_2. The authentication Request 251 contains an FTE element in which are indicated the generated SNonce and the R0KH-ID set to an identifier of the network controller 225. It contains also a RSNE IE in which the PMKROName is included. At the reception of the authentication Request 251, R1KH of next AP 230 uses the received PMKROName, the MAC address of next AP 230 mac_ap_2 as R1KH-ID and the current MAC address of the FTO 210 mac_fto_1 (contained in the SA field of the authentication Request 251) as S1KH-ID to calculate a PMKRIName referred to as RCV_PMKR1Name[FTO, AP2], The RCV_PMKR1Name[FTO, AP2] is used as a hash key in its FTO hash table for retrieving the PMK-R1[FTO, AP2] corresponding to FTO 210. More precisely, the PMK-R1 corresponding to hash key equal to RCV_PMKR1Name [FTO, AP2] is extracted from FTO hash table. If next AP 230 does not have hash key equal to RCV_PMK-R1Name[FTO, AP2], the standard IEEE Std 802.11-2020 indicates that it may retrieve PMK-R1[FTO, AP2] by sending a request to the network controller 225. It is worth to note that as S1KH-ID is equal to S0KH-ID, the two keys PMK-R1[FTO, AP2] and FT-PMK-R1[FTO, AP2] are identical. Once retrieving PMK-R1[FTO, AP2], R1KH of next AP 230 generates a SNonce and uses it with the ANonce received from the authentication Request 251 to derive a session key PTKfFTO, AP2] from PMK-R1[FTO, AP2], Next, an authentication Response 252 is sent by next AP 230 to FTO 210 with a FTE IE containing the ANonce. At the reception of the authentication Response 252, the S1KH of the FTO 210 uses the received SNonce and the generated ANonce to derive the session key PTK[FTO, AP2] from the FT-PMK-R1[FTO, AP2], The FT initiation is finalized with an exchange of a re-association request 253 and a re-association response 254 exchanged between the FTO 210 and next AP 230. Next, the data exchanged between the FTO 210 and next AP 230 are encrypted with the key PTK[FTO, AP2], When a CPE FTO changes randomly its privacy parameters such as its MAC address, protocols based on fixed privacy parameters may be compromised. For example, by changing the MAC address of CPE FTO from mac_fto_0, in use when it has initiated the FT IMDA, to mac_fto_1 (different from mac_fto_0), in use when it initiates the FT protocol, makes the process of generating the session cryptographic key based on a fixed address of the CPE FTO not operable. This means that the identifier RCV_PMKR1Name[FTO, AP2] and the PMKR1Name[FTO, AP2] have different values as they have been now generated with different inputs; RCV_PMKR1Name[FTO, AP2] being computed with mac_fto_1 as S1KH-ID and PMKR1Name[FTO, AP2] being computed with mac_fto_0 as S1KH-ID. Consequently, R1KH of next AP 230 is not able to retrieve locally PMK-R1[FTO, AP2] as there is no hash key in its FTO hash table corresponding to RCV_PMKR1 Name[FTO, AP2], In such a case, the standard IEEE Std 802.11-2020 indicates that it may retrieve PMK-R1[FTO, AP2] by sending a request to the network controller 225. For this, the R1KH of next AP 230 transmits an identifier of the FTO 210 to R0KH of the network controller 225. The only available identifier being the current MAC address of the FTO 210 mac_fto_1, but this identifier is unknown for R0KH of first AP 220 as R0KH used previously mac_fto_0 as identifier for FTO 210. Consequently, the R1KH of next AP 230 is also not able to retrieve remotely PMK-R1[FTO, AP2], The indication of the standard cannot thus be used. Moreover, during the FT protocol, S0KH generates FT-PMK-R1[FTO, AP2] by using mac_fto_1 as S1KH-ID whereas PMK-R1[FTO, AP2] stored in R1KH of next AP 230 has been generated by using mac_fto_0 as S1KH-ID. In order to resolve all these problems, the invention proposes in embodiments to modify the FT mechanism by using a mobility domain identifier for the station for generating and identifying the keys PMK-R1s. Figure 3 schematically illustrates an exemplary sequence of messages 300 for operating the modified FT mechanism initiated by a CPE Client, according to one or several embodiments of the invention. The two sequences of messages 340 (341, 342,343, 344 and 345) and 350 (351, 352, 353, 354) are similar to the sequences 240 and 250 illustrated on Figure 2. One of the differences, as detailed below, is that the computation of some keys is now based on a new defined identifier of the FTO, called initial identifier or MD_STA_identifier. The latter may also be referred to as MD_STA_identifier[FTO] to explicitly designate the FTO to which the identifier relates. The MD_STA_identifier is preferably persistent at least for the time the CPE Client is associated with one of the CPE APs of the mobility domain. If the CPE Client disconnects from the mobility domain and reconnects later, the whole association process is reiterated and the CPE Client may use a different MD_STA_identifier. In some embodiments, the MD_STA_identifierof a CPE FTO is the MAC address of the FTO mac_fto_0 during the FT IMDA 340. However, if the MAC address of the FTO changes, the MD_STA_ldentifier[FTO] is kept unchanged (persistent). In some other embodiments, the MD_STA_identifier is a distinct identifier generated by the CPE AP or the CPE FTO and exchanged during the FT IMDA 340. In some embodiments, CPE FTO 310 generates an MD identifier MD_STA_identifier [FTO] and transmits that identifier in the association request (during sequence 341). Similarly, in other embodiments, CPE AP 320 generates an MD identifier MD_STAJdentifier [FTO] and transmits that identifier in the association response (during sequence 341). In some embodiments, the MD identifier MD_STA_identifier [FTO] is the Device ID specified by the task group 802.11bh which is used to allow the network to recognize a non-AP STA. In an implementation of the invention, the MD identifier may be transmitted in a dedicated field of a Fast BSS Transition (FT) Information Element (IE) as illustrated with reference to Figure 4. According to embodiments of the invention, the MD Identifier (MD_STAJdentifier) is used in the computation of the second level keys instead of the MAC addresses of CPE FTO 310, mac_fto_0 and mac_fto_1. The supplicant key holder (S0KH) of FTO 310 derives PMK-R0 from the MPMK as described previously by using the current MAC address of FTO 310 mac_fto_0 as S0KH-ID and an identifier of the network controller 325 as R0KH-ID. S0KH generates also the identifier PMKROName corresponding to PMK-R0. Next, S0KH derives the key PMK-R1 relative to first CPE AP 320 (PMK-R1[FTO, AP1]) from PMK-R0 by using MD_STA_ldentifier[FTO] as S1KH-ID and the MAC address of first CPE AP 320 mac_ap_1 as R1KH-ID. Finally, S0KH provides PMK-R1[FTO, AP1] to S1KH. The first AP 320 sends the MPMK to the Network Controller 325 in a message 342 that includes the MPMK and the current MAC address of FTO 310 mac_fto_0. The authenticator's key holder (R0KH) of Network Controller 325 derives PMK-R0 from the MPMK (provided by message 342) as described previously by using the current MAC address of FTO 310 mac_fto_0 (provided by message 342) as SOKH-ID and an identifier of the network controller 325 as ROKH-ID. ROKH generates also the identifier PMKROName corresponding to PMK-RO. Next, ROKH generates a set of PMK-R1s {PMK-R1[FTO, AP1], PMK-R1[FTO, AP2]}, each one corresponding to an APi of the mobility domain md1 (here AP1 and AP2) and derived from PMK-RO[FTO] by using the MAC address of APi (mac_ap_1 or mac_ap_2) as R1KH-ID and the MD_STA_ldentifier[FTO] as S1KH-ID. For each PMK-R1[FTO, APi], its corresponding identifier PMKR1Name[APi] is also derived from the PMKROName, the MAC address of APi as R1KH-ID and the MD_STA_ldentifier[FTO] as S1KH-ID. For instance, for first AP 320 mac_ap_1 is used as R1KH-ID; for next AP 330 mac_ap_2 is used as R1KH-ID. At step 343, ROKH transmits to R1KH of the first AP 320, through the secure channel of the distribution system (of the mobility domain), in addition to the key PMK-R1[FTO, AP2] and the associated PMKR1Name[AP1], the pair (PMKROName[FTO, AP1], MD_STA_identifier [FTO]). Similarly, ROKH transmits to R1KH of the next AP 330, through the secure channel of the distribution system (of the mobility domain), in addition to the key PMK-R1[FTO, AP2] and the associated PMKR1Name[AP2], the pair (PMKR0Name[FTO, AP2], MD_STA_identifier [FTO]). According to an implementation, once receiving the pair (PMKROName, MD_STA_identifier[FTO]), the R1KH of each CPE APi updates a second hash table, referred to as CPE FTO hash table, for which the PMKROName is used as a hash key for retrieving the key MD_STAJdentifier[FTO]. In other implementations, other structures for storing the pair (PMKROName[FTO, AP1], MD_STA_identifier[FTO]) may be used. In the example illustrated in Figure 3, the R1KH of first CPE AP 320 and the R1 KH of next CPE AP 330 update their respective CPE FTO hash tables with the hash key PMKROName[FTO, AP1] and the value MD_STA_identifier[FTO]. More generally, the R1KH of a given CPE AP may store, for different FTOs (FTOk), a set of MD_STA_ldentifier[FTOk] in a CPE FTO hash table, each MD_STA_identifier[FTOk] being identified by a hash key PMKROName[FTOk, APn] and corresponds to a FTOk which has already initiated a FT initial mobility domain association with a CPE APn of the same mobility domain as the one of the given CPE AP. When CPE FTO 310 roams from first CPE AP 320 to next CPE AP 330, both APs belonging to the same mobility domain, CPE FTO 310 may decide to initiate a FT protocol 350. From the MAC address of next AP 330 mac_ap_2, S0KH of FTO 310 derives a new key PMK-R1 referred to as FT-PMK-R1[FTO, AP2] relative to next CPE AP 330 from PMK-R0, as described previously, by using the MD_STA_identifier[FTO] as S1KH-ID and the MAC address of next CPE AP 330 mac_ap_2 as R1KH-ID. Once generated, it provides FT-PMK-R1[FTO, AP2] to S1KH. For initiating the FT protocol 350, S1KH of FTO 310 sends an authentication-Request 351 to next AP 230 with a DA field set to the MAC address of next AP 330 mac_ap_2 and a SA field of its header set to the MAC address of the FTO 310. It contains an FTE element in which are indicated the generated SNonce and the R0KH-ID set to an identifier of the network controller 325. It contains also a RSNE IE in which the PMKROName[FTO, AP1] is included. At the reception of the authentication-Request 351, R1KH of next CPE AP 330 extracts the received PMKROName[FTO, AP1] and uses it as hash key of the CPE FTO hash table in order to retrieve MD_STA_identifier[FTO], Next, R1KH uses the received PMKROName[FTO, AP1], the MAC address of next CPE AP 330 mac_ap_2 as R1 KH-ID and MD_STA_identifier [FTO] as S1 KH-ID to calculate PMKRIName referred to as RCV_PMKR1Name[FTO, AP2], The RCV_PMKR1Name[FTO, AP2] is used as a hash key in its FTO hash table for retrieving the PMK-R1[FTO, AP2] corresponding to the CPE FTO 310. More precisely, the PMK-R1 corresponding to hash key equal to RCV_PMKR1Name[FTO, AP2] is extracted from FTO hash table. It is to be noted that, as their generation is no longer based on the FTO MAC Address but the MD_STA_ldentifier[FTO], the identifiers RCV_PMKR1Name[FTO, AP2] and PMKR1 Name[FTO, AP2] are now equal although the FTO may have been assigned a different MAC address between the FT IMDA and the FT protocol. If next CPE AP 330 does not have an entry in the hash table with a key identified by RCV_PMKR1Name[FTO, AP2] for retrieving PMK-R1[FTO, AP2], R1KH of next CPE AP 320 transmits the MD Identifier MD_STA_identifier[FTO] to R0KH of first CPE AP 310 to retrieve the PMK-R1[FTO, AP2], As R0KH of first CPE AP 310 has stored the MD_STAJdentifier, it is now able to retrieve the PMK-R1[FTO, AP2], As FT-PMK-R1[FTO, AP2] and PMK-R1[FTO, AP2] have now been generated both with MD_STA_identifier[FTO] and not with two different values mac_fto_0 and mac_fto_1, they are identical. The use of the MD Identifier advantageously allows executing the FT without jeopardizing privacy. It is to be noted that defining a new identifier, namely MD_STA_identifier, does not compromise the confidentiality of the station resulting from the CPE. Indeed, contrary to the MAC address which is present in every frame, the MD_STA_identifier is only exchanged during association with AP. Accordingly, it cannot be used to track the station by listening to exchanged messages. It is also to be noted that, in the above described embodiments, the MD Identifier is used in the computation of the second level keys while usage of the MAC address of the CPE FTO is kept for the computation of the first level keys. Alternatively, the MD Identifier (MD_STA_identifier) may also be used in the computation of the first level keys instead of the MAC address of CPE FTO 310. These keys may be computed once by the CPE FTO and stored for reuse after FT. The supplicant key holder (S0KH) of CPE FTO 310 derives PMK-R0 from the MPMK, as described previously, by using MD_STA_ldentifier[FTO] as S0KH-ID and an identifier of the network controller 325 as R0KH-ID. S0KH generates also the identifier PMKROName corresponding to PMK-R0 by using MD_STA_ldentifier[FTO] as S0KH-ID and an identifier of the network controller 325 as R0KH-ID. Similarly, the authenticator's key holder (R0KH) of first CPE AP 320 derives PMK-R0[FTO] from MPMK, as described previously, by using MD_STA_ldentifier[FTO] as S0KH-ID and an identifier of the network controller 325 as R0KH-ID. R0KH generates also the identifier PMKROName corresponding to PMK-R0 by using MD_STA_ldentifier[FTO] as S0KH-ID and an identifier of the network controller 325 as R0KH-ID. The other operations are similar to those of the embodiments described above and are not repeated for here for these other embodiments. Figure 4 illustrates a Fast BSS Transition (FT) Information Element (IE) 410 in accordance with embodiments of the present invention. A new field 420 is added to the FT IE specified in the standard IEEE Std 802.11-2020. This field 420 may be considered optional for the standard and required only when implementing embodiments of the invention. The field 420 (referred to as “Optional Parameter”) contains a sub-element ID field 421, a length field 422 and a data field 423. The sub-element ID field 421 is set to a value not already assigned by the standard (i.e., between 7 and 255). For instance, sub-element ID field 421 is set to 7. The length field 422 is set to indicate the length of the MD_STA_ldentifier. The MD_STA_ldentifier being coded for instance on 12 bits. The data field 423 correspond to the value of the transmitted MD_STA_identifier. Figure 5 illustrates embodiments of the invention and the different exchanges between the different key holders. Key holder ROKH is assumed to be hosted in a first CPE AP 501, named here AP1. AP1 is involved in the first association of the CPE Client in the mobility domain. Key holder R1KH is hosted in AP1 and a next CPE AP 502, named here AP2. AP2 is involved in the FT of the station. Key holders S0KH and S1KH are hosted in the CPE Client 503 (referred to also as FTO or station). It is assumed in the illustration of Figure 5 that the MD_STA_identifier[FTO] is used for first both first and second level keys. As discussed above, according to embodiments, it is possible to not use the MD_STA_identifier[FTO] for the first level keys. During exchanges 506 representing the first association of the FTO to AP1 of the privcay domain, the FTO first determines a mobility domain identifier MD_STAJdentifier[FTO]. Based on this MD_STA_identifier[FTO], the FTO generates the set of keys to be used for the FT. According to embodiments, the FTO, more precisely S0KH in the CPE Client, first generates the primary key PMK-R0[FTO] based on the MD_STA_identifier[FTO] and the MAC address of AP1, mac_ap_1. A digest PMKROName associated with this primary key is generated along with the primary key PMK-R0[FTO], From this primary key PMK-R0[FTO], a secondary key PMK-R1[FTO, AP1] (and optionally its associated digest PMKR1Name[FTO, AP1]) is generated for this station by S0KH and transmitted to S1KH in the station. The secondary key PMK-R1[FTO, AP1] is generated based on the primary key PMK-R0[FTO], the MAC address of AP1 mac_ap_1 and the MD identifier of the station MD_STA_identifier[FTO]. Then, the station transmits data 508 comprising its identifier MD_STA_identifier[FTO] to ROKH in AP1, typically in the association request. Upon reception of MD_STAJdentifier[FTO], ROKH is able to generate the same set of keys already generated by S0KH, namely the primary key PMK-R0[FTO] and its associated digest PMKROName, and the secondary key PMK-R1[FTO, AP1] (and optionally its associated digest PMKR1Name[FTO, AP1]). In addition, ROKH further generates a secondary key PMK-R1[APi] and its associated digest PMKR1Name[APi] for each AP, APi, of the mobility domain. Each secondary key PMK-R1[APi] is generated based on the primary key PMK-R0[FTO], the identifier of the station MD_STA_identifier[FTO] and the MAC address of APi, mac_ap_i. All these secondary keys PMK-R1[APi] are stored in ROKH, typically in a table, and may be retrieved using the associated digest PMKR1Name[APi], ROKH transmits through the secure channel of the distribution system (of the mobility domain) 504 data 507 to each APi of the mobility domain. Data 507 comprises the secondary key for this station PMK-R1[FTO, APi] and its associated digest PMKR1Name[FTO, APi], In addition, according to embodiments of the invention, data 507 further comprises the station identifier MD_STA_identifier[FTO] and the digest associated with the primary key PMKROName[FTO, AP1], Each APi of the mobility domain stores the received station identifiers MD_STA_identifiers, typically in a table, where an identifier can be retrieved based on the digest PMKROName[FTO, AP1] associated with the primary key PMK-R0[FTO]. At this point, the system is ready for FT. During FT, the station associates with next AP, AP2, with exchanges. The station, based on the MAC address of AP2, mac_ap_2, its own identifier MD_STAJdentifier[FTO] and the primary key PMK-R0[FTO] is able to generate the secondary key for AP2 PMK-R1[FTO, AP2], Then, the station transmits data 509 comprising the digest of the primary key PMKROName[FTO, AP1] to AP2. Based on the received digest of the primary key PMKROName[FTO, AP1], AP2 is able to retrieve the identifier of the station MD_STA_identifier[FTO]. Then, it can generate the digest associated with the secondary key PMKR1Name[FTO, AP2] based on the digest of the primary key PMKROName[FTO], the identifier of the FTO MD_STA_identifier[FTO, AP1] and the MAC address of AP2 mac_ap_2. This digest can then be used to retrieve the stored secondary key PMK-R1[FTO, AP2] received from the first AP AP1. At this point, both the FTO and AP2 have the required set of keys for generating the shared secret used for encrypting their messages in order to complete the FT of the station from AP1 to AP2. Figure 6 illustrates the main steps of a method for FT by a station according to embodiments of the invention. The method is separated into two different phases. Phase 601 corresponding to steps occurring during the first association of the station to a first AP, AP1, of the mobility domain. Phase 602 corresponds to steps occurring during the FT, meaning a subsequent association using FT of the station to a next AP, AP2. During phase 601, the station generates an identifier MD_STA_identifier[FTO] in step 603. This identifier is used by the STA from a first association to a first AP, AP1, to the next associations to other APs of the mobility domain. When the station leaves the mobility domain and later associates anew to an AP of the mobility domain, the identifier of the station may be different. In a step 604, the station transmits this identifier MD_STA_identifier[FTO] to the first AP, AP1. This transmission is typically done in a FT IE as illustrated by Figure 4. This step is optional, for example in embodiments, the MD_STA_identifier[FTO] corresponds to the MAC address of the station at the time of this first association, and is therefore known from AP1 as it is contained in the exchanged messages between the station and the AP. In a step 605, the station generates the set of keys for FT. This set comprises the primary key PMK-R0[FTO], its associated digest PMKROName[FTO, AP1], the secondary key PMK-R1[FTO, AP1] and its associated digest PMKR1Name[FTO, AP1], These keys, and associated digests, are generated based on the MD_STA_identifier[FTO] according to embodiments of the invention as discussed above. In a step 606, the station generates the session key PTK for encrypting subsequent communications with AP1. Later on, when the station roams to a next AP, AP2, of the mobility domain during phase 602, the station executes the following steps. In a step 607, the station generates a secondary key FT-PMK-R1[FTO, AP2] for the next AP AP2 based on the MD_STA_identifier[FTO] as discussed above. In a step 608, the station transmits the digest associated with the primary key PMKROName[FTO, AP1] to AP2. In a step 609, the station generates the session key PTK[FTO, AP2] from FT-PMK-R1[FTO, AP2] for encryption of the subsequent messages exchanged with AP2. It is to be noted that some of these steps may be executed in a different order, as for example, the transmission step 604 and the key generation step 605. Figure 7 illustrates the main steps of a method for FT by a first AP, AP1, according to embodiments of the invention. All these steps occur during the first association of the station with AP1. In a first step 701, AP1 receives the identifier of the station MD_STA_identifier[FTO]. As already mentioned, in some embodiments, this identifier is not explicitly transmitted and may be determined by AP1, for example when it corresponds to the MAC address of the station at the time of the first association. In a step 702, AP1 generates the set of keys to be used for FT comprising the primary key PMK-RO[FTO] and its associated digest PMKROName[FTO, AP1]. AP1 also generates for each AP, APi, of the mobility domain a secondary key PMK-R1[FTO, APi] and its associated digest PMKR1Name[FTO, APi] based on the MD_STA_identifier[FTO] according to embodiments discussed above. In a step 703, AP1 stores the identifier of the station MD_STA_identifier[FTO] in a storing structure allowing to retrieve this identifier using the primary key digest. In an embodiment, this structure may be a table indexed by the primary key digest PMKR0Name[FTO, AP1], In a step 704, AP1 communicates or transmits to each AP, APi, of the mobility domain the corresponding secondary key PMK-R1[FTO, APi] and its associated digest PMKR1Name[FTO, APi], In addition, AP1 also communicates or transmits to each APi, the pair primary key digest PMKROName[FTO, AP1] and the identifier of the station MD_STAJdentifier[FTO]. In a step 705, AP1 generates the session key PTK[FTO, AP1] from PMK-R1[FTO, AP1] for encrypting subsequent messages exchanged with the station. Figure 8 illustrates the main steps of a method for FT by the next AP, AP2, of the mobility domain according to embodiments of the invention. These steps comprise steps 801 and 802 occurring during a phase 807 following the first association of the station with AP1 and steps 803 to 806 occurring during a phase 808 of the FT of the station to AP2. In a step 801, AP2 receives from AP1 a secondary key PMK-R1[FTO, AP2] and its associated digest PMKR1Name[FTO, AP2], In addition, AP2 also receives the pair primary key digest PMKROName[FTO, AP1] and the identifier of the station MD_STAJdentifier[FTO]. In a step 802, AP2 stores the identifier of the station MD_STA_identifier[FTO] in a storing structure allowing to retrieve this identifier using the primary key digest. In an embodiment, this structure may be a table indexed by the primary key digest PMKROName[FTO, AP1], Later on, during the fast association of the station to the next AP, AP2, in a step 803, AP2 receives the digest associated with the primary key PMKROName[FTO, AP1] from the station. In a step 804, AP2 retrieves the identifier of the station, MD_STA_identifier[FTO], using the received primary key digest PMKROName[FTO, AP1], In a step 805, AP2 generates the secondary key digest RCV_PMKR1 Name[FTO, AP2] and uses it to retrieve the secondary key PMK-R1[FTO, AP2], The received PMKROName[FTO, AP1], the MAC address of AP2 mac_ap_2 (as R1KH-ID) and MD_STA_identifier[FTO] (as S1KH-ID) are used to calculate RCV_PMKR1Name[FTO, AP2], The RCV_PMKR1Name [FTO, AP2] is used as a hash key in its FTO hash table for retrieving the PMK-R1[FTO, AP2] corresponding to the station. More precisely, the PMK-R1 corresponding to hash key equal to PMKR1Name[FTO, AP2] is extracted from FTO hash table. In a step 806, AP2 generates the session key PTK[FTO, AP2] from PMK-R1[FTO, AP2] for encrypting subsequent messages exchanged with the station. Figure 9 schematically illustrates a communication device 900, typically any of the stations of Figure 1, of a wireless network, configured to implement at least one embodiment of the present invention. The communication device 900 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 900 may comprise a communication bus 913 to which may be connected: - a central processing unit 901, such as a processor, denoted CPU; - a memory 903, 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 902 and 902’ 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 904 and 904’, respectively. Preferably the communication bus 913 may provide communication and interoperability between the various elements included in the communication device 900 or connected to it. The representation of the bus is not limiting and in particularthe central processing unit is operable to communicate instructions to any element of the communication device 900 directly or by means of another element of the communication device 900. 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 902 or 902’, in order to be stored in the memory 903 of the communication device 900 before being executed. In an embodiment, the device 900 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 above-described 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). The 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. The 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 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 parameters to be changed.

Claims

1. A wireless communication method comprising, at a station:associating with a first access point (AP) using a first media access control (MAC) address of the station;generating a first Pairwise Master Key (PMK), associated with the first AP, based on a station identifier;reassociating with a second AP using a second MAC address of the station;generating a second PMK, associated with the second AP, based on the station identifier; andgenerating a Pairwise Transient Key (PTK) based on the generated second PMK for encrypting messages exchanged between the station and the second AP.

2. The method of claim 2, further comprising:generating a primary PMK (PMK-RO) based on the station identifier; and generating a primary PMK identifier (PMKROID) for identifying the generated PMK-RO.

3. The method of claim 2, wherein the generating of the first PMK, associated with the first AP, and the generating of the second PMK, associated with the second AP, are based on the PMK-RO.

4. The method of claim 2, further comprising transmitting the primary PMK identifier (PMKROID) to the second AP.

5. A communication method comprising, at a controller:generating a primary Pairwise Master Key (PMK)-R0 based on a station identifier; generating a primary PMK identifier (PMKROID) for identifying the generated PMK-RO;generating a PMK, associated with an access point (AP), based on the station identifier;generating a PMK identifier (PMKID) for identifying the generated PMK; and transmitting, to the AP, the PMK-RO, PMKROID, PMK and PMKID for the AP to generate a Pairwise Transient Key (PTK) for encrypting messages exchanged between the station and the AP.

6. The method of claim 5, wherein the station is associated with a first AP using a first media access control (MAC) address prior reassociating with the AP using a second MAC address.

7. A wireless communication method comprising, at an access point (AP):establishing a cache table comprising, for an entry associated with a station, a plurality of parameters received from a controller, the parameters comprising: a station identifier, a primary Pairwise Master Key (PMK)-R0 identifier (PMKROID) generated based on the station identifier, a PMK, associated with the AP, generated based on the station identifier and a PMK identifier (PMKID) identifying the PMK;associating with a station using a medium access control (MAC) address of the station;receiving from the station a primary PMK identifier (PMKROID);retrieving the station identifier from an entry of the cache table having a cached PMKROID matching the received PMKROID;generating a PMKID, associated with the AP, using the retrieved station identifier, retrieving the PMK received from the controller from an entry of the cache table having a cached PMKID matching the generated PMKID; andgenerating a Pairwise Transient Key (PTK) based on the retrieved PMK for encrypting messages exchanged between the station and the AP.

8. The method of any one of claims 1 to 7, the station identifier is set to a first MAC address.

9. The method of any one of claims 1 to 7, the station identifier is set to a device identifier (Device ID) associated with the station.

10. A wireless station comprising a memory and processing circuitry configured to:associate with a first access point (AP) using a first media access control (MAC) address of the station;generate a first Pairwise Master Key (PMK), associated with the first AP, based on a station identifier;reassociate with a second AP using a second MAC address of the station;generate a second PMK, associated with the second AP, based on the station identifier; andgenerate a Pairwise Transient Key (PTK) based on the generated second PMK for encrypting messages exchanged between the station and the second AP.

11. A network controller comprising a memory and processing circuitry configured to:generate a primary Pairwise Master Key (PMK)-RO based on a station identifier;generate a primary PMK identifier (PMKROID) for identifying the generated PMK-R0;generate a PMK, associated with an access point (AP), based on the station identifier;generate a PMK identifier (PMKID) for identifying the generated PMK; andtransmit, to the AP, the PMK-RO, PMKROID, PMK and PMKID for the AP to generate a Pairwise Transient Key (PTK) for encrypting messages exchanged between the station and the AP.

12. An access point (AP) comprising a memory and processing circuitry configured to:establish a cache table comprising, for an entry associated with a station, a plurality of parameters received from a controller, the parameters comprising: a station identifier, a primary Pairwise Master Key (PMK)-R0 identifier (PMKROID) generated based on the station identifier, a PMK, associated with the AP, generated based on the station identifier and a PMK identifier (PMKID) identifying the PMK;associate with a station using a medium access control (MAC) address of the station;receive from the station a primary PMK identifier (PMKROID);retrieve the station identifier from an entry of the cache table having a cached PMKROID matching the received PMKROID;generate a PMKID, associated with the AP, using the retrieved station identifier, retrieve the PMK received from the controller from an entry of the cache table having a cached PMKID matching the generated PMKID; andgenerate a Pairwise Transient Key (PTK) based on the retrieved PMK for encrypting messages exchanged between the station and the AP.

13. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 1 to 9, when loaded into and executed by the programmable apparatus.

14. A non-transitory computer-readable storage medium storing instructions of a computer program for implementing a method according to any one of claims 1 to 9.31

Images