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

Abstract

A communication method and a device in a communication network 100 for operating with enhanced data privacy features. The method comprises generating a Pairwise Master Key (PMK) and a first PMK identi

Description

TECHNICAL FIELD The present disclosure relates to wireless communications. BACKGROUND 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 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.11aq 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 or STA, 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, the IEEE 802.11 working group has further initiated the 802.11bi task group to address other privacy requirements and specify corresponding Enhanced Data Privacy (EDP) features that the Client could implement in the next version of standard 802.11. One of the specified EDP features is the ability for a Client to change randomly its MAC address while it is associated with an AP, without any loss of connection. Another specified EDP feature is that this change is to be also effective when the client operates a BSS Transition mechanism (roaming) between two APs belonging to a same ESS. However, if the introduction of the RCM mechanism and the EDP features enhanced strongly the privacy of the user, at the same time, it has also broken the commercial services using the MAC address of the STA as permanent identifier to identify and recognize the user by the APs and network services. One issue resulting from a MAC address change and that is still not addressed relates to mechanisms for shorter re-authentications aimed to reduce handoff times. Caching mechanisms, such as the Fast BSS Transition (FT) mechanism specified in the IEEE 802.11r amendment, known in the art to speed reauthentication by reusing cached information fail when the client changes its MAC address. Current methods thus need to run a full authentication each time a client re-associates or roams to an AP. SUMMARY OF THE DISCLOSURE The present disclosure seeks to overcome the foregoing concerns. In this context, the present disclosure provides a communication method in a communication network, comprising: generating a Pairwise Master Key (PMK) and a first PMK identifier for identifying the PMK, the generating is based on a first media access control (MAC) address of a station; generating a second PMK identifier for identifying the PMK based on a second MAC address of the station; and updating mapping information for identifying the PMK using the second PMK identifier. Optional features are defined below with reference to methods, while they can be transposed into device features. In some embodiments, the method further comprising determining a change of the MAC address of the station from the first MAC to the second MAC address. In some embodiments, the change of the MAC address of the station is performed while the station is associated with a first AP. In some embodiments, the determining of the change comprises receiving a notification from the first AP notifying that the MAC address of the station changed from the first MAC address to the second MAC address. In some embodiments, the first and the second PMK identifiers are communicated to a second AP of the communication network. In some embodiments, the first and the second PMK identifiers are communicated to the first AP. In some embodiments, the method further comprising associating the first PMK identifier with the second PMK identifier. In some embodiments, the generating of the first PMK identifier comprises: generating a primary PMK (PMK-RO) and a primary PMK identifier (PMKROName) based on the first MAC address of a station; and wherein the generating the first PMK identifier is further based on PMKROName and the generating of the PMK is based on PMK-RO. In some embodiments, the generating of the second PMK identifier is further based on PMK-RO. In some embodiments, the associating is based on the primary PMK identifier (PMKROName). In some other embodiments, the associating is based on an Identifiable Random MAC (IRM) address. According to another aspect, the present disclosure provides a wireless communication method comprising, at an access point (AP): receiving, from a controller, a Pairwise Master Key (PMK) and a first PMK identifier for identifying the PMK generated based on a first media access control (MAC) address of a station; storing in a cache table an entry associating the first PMK identifier with the PMK received from the controller; receiving, from the controller, a second PMK identifier for identifying the PMK generated based on a second MAC address of the station; and updating the cache table entry for associating the second PMK identifier with the PMK. In some embodiments, the method further comprising: associating with a station; determining a PMK identifier associated with the station; retrieving, from the cache table, a cached PMK which associated PMK identifier matches the determined PMK identifier; and generating a Pairwise Transient Key (PTK) based on the retrieved PMK for encrypting messages exchanged between the station and the AP. In some embodiments, the PMK identifier is determined from an information element received from the station in association request. In some embodiments, determining the PMK identifier comprises: receiving, from the station, a primary PMK identifier (PMKROName) in Authentication request; and generating the PMK identifier (PMKRIName) based on PMKROName and the MAC address of the station. In some embodiments, the method further comprising: receiving, from the station, a PMK identifier (PMKR1Name_RCV) in association request; checking if the received PMKR1Name_RCV matches the generated PMKRIName, and if there is no matching, the association is refused. 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; Figures 2A and 2B schematically illustrate exemplary sequences of messages for operating a FT initiated by a client; Figure 2C schematically illustrates an exemplary sequence of messages for updating key identifiers triggered by a FTO MAC address change according to embodiments of the invention; Figure 3 schematically illustrates exemplary sequences of messages for updating key identifiers triggered by a STA according to an embodiment of the invention; Figure 4 illustrates, using a flowchart, main steps of a communication method at a communication device, according to various embodiments of the disclosure; and Figure 5 schematically illustrates a communication device of a wireless network, configured to implement at least one embodiment of the present invention. 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 station (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 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 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 (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 the ESS area, and re-associate again either with the same first AP or with another AP of the ESS, e.g., when the STA is switched on or moved back within the ESS area. Fast Transition (FT) exemplary embodiment In a basic BSS transition, a client connected to a current 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 a 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 and 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 a network controller in 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 network controller, unless otherwise stated. It is to be understood that the logical functions of the network controller and the first AP may be collocated in a same communication apparatus. 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 corresponding 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. 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 for example 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 may be computed as: PMK-ROName-Salt = L(R0-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 may also be 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 may be 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 S1KH (SNonce), a 256-bit random bit string contributed by R1KH (ANonce), the client’s MAC address (STA-ADDR) and the AP’s MAC address (also named BSSID). The key derivation function may also be the Key Derivation Function KDF-Hash-Length specified in sections 12.7.1.6.2 and 12.7.1.6.5 of the standard lEEEStd 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. Figures 2A and 2B schematically illustrate exemplary sequences of messages for operating a FT initiated by a client. Figure 2A illustrates a first sequence of messages 240 referred to as FT initial mobility domain association (IMDA) involving the FTO 210, a first AP 220 (AP1) and a Network Controller 225. FT initial mobility domain association is typically the first association within the ESS. In addition to Association Request and Response frames, Reassociation Request and Response frames are supported in the initial mobility domain association to enable both FT and non-FT APs to be present in a single ESS. Figure 2B illustrates a second sequence of messages 250 referred to as FT protocol involving the FTO 210 and target 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 the first AP 220 is referred to as mac_ap1 and the MAC address of AP 230 is referred to as mac_ap2. It is assumed in this embodiment that the FTO and the APs are CPE-capable; meaning that the FTO implements one or more Client Privacy Enhancements (CPE) features including the ability to change randomly its privacy parameters such as its MAC address while it is associated with a current AP without any loss of connection. Different values mac_fto_0, mac_fto_1, etc. may thus be used to refer to the MAC address of FTO 210. mac_fto_0 is chosen to designate the MAC address of FTO 210 during the FT IMDA. The FT capability of APs, including first AP 220, is advertised in the Beacon and Probe Response frames (not illustrated) by including a Mobility Domain Information Element (MDE). The MDE is advertised in the Beacon and Probe Response frames to indicate the MDID, FT capability, and the FT policy. Next, FTO 210 initiates the FT IMDA 240 by initiating a Client Authentication / Association exchange 241. For this, FTO 210 transmits an authentication request to AP 220. After receiving the authentication request, 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. Upon successful authentication, FTO 210 sends an association request with a Robust Security Network Information Element (RSNE) indicating the Authentication and Key Management (AKM) and a Mobility Domain Information Element (MDE) indicating its support of the FT procedure. 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 (FTE) 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). The PMKROName is used to identify the PMK-R0. 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, 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_ap1 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 (ROKH) of Network Controller 225 derives PMK-RO 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 SOKH-ID and an identifier of the network controller 225 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 as previously described by using the current MAC address of FTO 210 mac_fto_0 as S1KH-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_ap1 and a second one PMK-R1[FTO, AP2] is generated relative to next AP 230 by using its MAC address mac_ap2. 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 S1 KH-ID and the MAC address of APi (mac_ap1 for first AP 220 or mac_ap2 for next AP 230) as R1 KH-ID. The PMKR1Name[APi] is used to identify the PMK-R01[APi]. Once generated, ROKH 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 toAP230 including the PMK-R1[FTO, AP2] and its corresponding PMKR1Name[AP2]. Of course, similar messages may be sent to other APs of the mobility domain. Once the PMK-R1 [FTO, APi] and the associated PMKR1 Name[APi] received, the R1KH of each APi saves these parameters in a cache table for later retrieval. A full context resulting from a successful authentication may be cached, for example using a Pairwise Master Key Security Association (PMKSA) table. Typically, a PMKSA is created and cached by the FTO when authentication completes successfully and by APi when the PMK-R1[APi] is received. Each PMKSA[FTO] has a unique identifier, typically PMKR1Name[FTO, APi], PMKR1Name[FTO, APi] may be used as a key (index) to identify the elements of the PMKSA table and update them. The PMKSA table of a given APi contains a set of PMK-R1s {PMK-R1[FTOk, APi]} corresponding to different FTOs (FTOk). De facto, the R1KH of first AP 220 updates its cached PMKSA table with the key PMKR1Name[AP1] and the value PMK-R1[FTO, AP1], and the R1KH of next AP 230 updates its cached PMKSA table with the key PMKR1Name[AP2] and the value PMK-R1[FT0, 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 confirm the existence of a same PMK on both sides (AP and Client), to ensure that the security association keys are fresh and to synchronize the installation of one or more temporal keys into the MAC. When FTO 210 roams within the mobility domain to a new location covered by target AP 230, it may decide to initiate a FT protocol from first AP 220 to target AP 230. Reference is made now to Figure 2B that illustrates the sequence of messages related to the FT protocol 250. In this illustration, it is assumed that FTO 210 has not yet changed its MAC address, i.e., it’s mac_fto_0. As indicated previously, the R1KH of AP 230 may store, for different FTOs (FTOk), a set of PMK-R1s {PMK-R1[FTOk, AP2]} in its cached PMKSA tables, each PMK-R1[FTOk, AP2] being identified by a 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 target AP 230. From the MAC address of AP 230 mac_ap2, S0KH of FTO 210 derives a new key PMK-R1 referred to as FT-PMK-R1[FTO, AP2] relative to AP 230 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 AP 230 mac_ap2 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 target AP 230 necessary for generating a session key PTK[FTO, AP2], For this, S1KH of FTO 210 sends an authentication Request 251 to AP 230 with a TA field of its header set to the MAC address of the FTO 210, and a RA field set to the MAC address of AP 230 mac_ap2. 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 in which the PMKROName is included. At the reception of the authentication Request 251, R1KH of AP 230 uses the received PMKROName, the MAC address of AP 230 mac_ap2 as R1KH-ID and the current MAC address of the FTO 210 mac_fto_0 (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 key in its FTO cache table for retrieving the PMK-R1[FTO, AP2] corresponding to FTO 210. More precisely, the PMK-R1 corresponding to key equal to RCV_PMKR1Name [FTO, AP2] is extracted from cached PMKSA table. If next AP 230 does not have a 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 equal. Once retrieving PMK-R1[FTO, AP2], R1KH of target AP 230 generates a ANonce and uses it with the SNonce received from the authentication Request 251 to derive a session key PTK[FTO, AP2] from PMK-R1[FTO, AP2], An authentication Response 252 is sent by AP 230 to FTO 210 with an FTE containing the ANonce. At the reception of the authentication Response 252, the S1KH of the FTO 210 uses the received ANonce and the generated SNonce 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 and including each one a RSNE in which the PMKR1 Name is included. 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 IM DA, to mac_fto_1 (different from mac_fto_0), prior initiating an FT protocol, makes the process of generating the session cryptographic key based on a fixed address of the CPE FTO not operable. This would mean 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[FT0, 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 key in its cached PMKSA 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 target 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 would generate FT-PMK-R1[FTO, AP2] by using mac_fto_1 as S1KH-ID whereas PMK-R1[FTO, AP2] stored in R1KH of target AP 230 has been generated by using mac_fto_0 as S1KH-ID. These problems are solved according to embodiments of the invention by updating PMK-R1 keys identifiers whenever a FTO MAC address changes. Figure 2C schematically illustrates an exemplary sequence of messages for updating key identifiers triggered by a FTO MAC address change according to embodiments of the invention. The illustrated sequence of messages 260 applies whenever a FTO MAC address changes. This may occur several times while the FTO is associated with a same AP and / or with different APs. For example, it may occur when the FTO is associated with another AP than first AP 210 during which IMDA was performed, i.e., after the FTO has performed one or more (successive) transitions to one or more target APs. Thus, generally, the sequence of messages applies if the FTO, while associated with a current AP, changes its MAC address from mac_fto_x to mac_fto_y. Some of the messages involve any other AP of the mobility domain. For simplicity, the sequence of messages is illustrated by considering that the change occurs while the FTO is associated with AP1 220 with MAC address mac_fto_0, after IMDA 240 was completed. Only AP2 230 is illustrated that may represent any other AP of the mobility domain. A change of FTO MAC address may be initiated by the FTO or by the AP. Alternatively, the FTO and the AP may agree / synchronize on a time instant for changing the FTO MAC address. The protocol for agreeing between the FTO and the AP on the time to change the MAC address is out of the scope of this disclosure. The sequence 260 starts by sending a message 261 to the controller 225 when AP 220, with which the FTO is currently associated, determines a change of FTO 210 MAC address, i.e., from mac_fto_0 to mac_fto_1. As discussed above, FTO 210 and AP 220 may agree on a time instant for changing the MAC address. Starting the procedure, i.e., sending the message 261, may be performed only after FTO 210 changed its MAC address or by anticipation prior the time instant at which the FTO 210 MAC address needs to be changed. Starting the procedure by anticipation allows to reduce the time for updating PMK-R1 keys identifiers and allows the FTO to quickly perform a successful transition to a target AP. The message 261 contains mapping information necessary for the controller to update PMK-R1 keys identifiers for the different APs of the mobility domain. Different mapping information may be envisaged depending on implementation at controller. According to one implementation, the controller maintains in a cached PMKSA table comprising the previously computed PMKROName[FTO] and the current MAC address of the FTO (mac_fto_0). In this implementation, AP1 provides the couple (PMKROName, mac_fto_1) to the controller in order for the controller to update its cached PMKSA table and associate PMKR0Name[FTO] now with mac_fto_1. The controller then computes the updated PMK-R1 keys identifiers as follows: P_PMKR1Name[APi] = ft / ncf / on(PMKR0Name, mac_fto_0, mac_api); N_ PMKR1Name[APi] = ft / ncf / on(PMKR0Name, mac_fto_1, mac_api); where P_PMKR1Name corresponds to previous PMKRIName based on mac_fto_0 and N_PMKR1Name corresponds to new PMKRIName based on mac_fto_1, and function corresponds for example to the function described previously for deriving the second level keys identifiers. Note that in general, if at least one previous change already occurred, and now the FTO is changing from mac_fto_x to mac_fto_y, then the cached MAC address corresponds to mac_fto_x and AP1 provides the couple (PMKROName, mac_fto_y) to the controller to compute P_PMKR1Name[APi] and N_PMKR1Name[APi] based on mac_fto_x and mac_fto_y, respectively. The controller then distributes, to APi of the mobility domain (here AP1 and AP2), messages (262, 263) comprising mapping information (P_PMKR1Name[APi], N_ PMKR1Name[APi]). Each AP receiving the mapping information updates its cache table by replacing, as a key, P_PMKR1Name[APi] by N_PMKR1Name[APi] for retrieving the corresponding PMK-R1[APi]. According to another implementation, the controller maintains in its cached PMKSA table the previously computed PMKROName[FTO], but not the previous MAC address of the FTO (mac_fto_0). In this implementation, AP1 provides the mapping (PMKROName, mac_fto_0, mac_fto_1) to the controller in order for the controller to determine the P_PMKR1Name[APi] and N_PMKR1Name[APi]. Identifiable Random MAC address (IRM) exemplary embodiment IEEE 802.11 WG has initiated the creation of the task group 802.11bh for specifying Enhanced Data Privacy (EDP) features allowing any AP of a given ESS to recognize the non-AP station when it returns to that ESS even if the non-AP station has changed its MAC address. Two EDP features have been then specified. The first one, referred to as device ID, is based on a permanent device ID provided by an AP of a given ESS to a Client during a first association and that the Client can then report back to any AP of the same ESS during future associations. The second one, referred to as Identifiable Random MAC (IRM), is based on a random MAC address, different from the address the Client is currently using, provided by the Client during association and then used for a next association. These features allow to recognize a STA operating Randomized and Changing MAC (RCM) even if the STA changes (roams) from one AP to another within the ESS or the STA disconnects and reconnects later on to the ESS (after a disassociation period). Figure 3 schematically illustrates exemplary sequences of messages for updating key identifiers triggered by a STA according to an embodiment of the invention. It is assumed in this embodiment that the AP station and the non-AP station are IRM capable. When a non-AP station (Client or STA) 310 intends to associate with an AP 320 for which it has not cached Pairwise Master Key (PMK), it launches an association procedure 330 in which it indicates in the Robust Security Network Information Element (RSNE) of the Association Request frame 332 its supported Group and Pairwise Cipher and Authentication and Key Management (AKM) suites and set the field “PMKID count” to 0. In complement, STA 310 indicates during the association procedure 330 its activation of IRM for a particular ESS by setting the IRM Active field to 1 in the Extended RSN Capabilities field (section 9.4.2.241 (RSNXE) of the standard IEEE Std 802.11-2020) in the (Re)Association Request frame 332. Similarly, AP 320 indicates its activation of IRM by setting the IRM Active field to 1 in the Extended RSN Capabilities field in the (Re)Association Response frame333. AP 320 may also indicate its activation of IRM by setting the IRM Active field to 1 in the Extended RSN Capabilities field in in Beacon and Probe Response frames. If the negotiated Group and Pairwise Cipher and Authentication and Key Management (AKM) suites involves extensible authentication protocols (EAP) and remote authentication dial-in user service (RADIUS) as it is typically the case in enterprise environment, many EAP messages are exchanged between the non-AP STA (Client) 310 and the AP 320 (messages 341) and between the AP 320 and the Network Controller 325 (messages 342) in which the RADIUS server is embedded in order to check the authenticity of the client 310 and generate from the Master Session Key (MSK) 301 and distributes a PMK 302 to both client and AP through a secure communication channel. From its PMK 302, the Client 310 and the AP 320 computes an identifier PM KID, referred to as PMK-ID-RCM, computed as: PMKID-RCM = Truncate-128(HMAC-SHA-1(PMK, “PMK Name” || AA || SPA)); wherein HMAC and MD5 are cryptographic hash function specified in IETF RFC 2104 and FIPS 180-4. Truncate-N(S) is bits 0 to N-1 of the bit string S starting from the left, AA the MAC address of the AP 320 and SPA the current MAC address of the Client 310. The identifier PMKID is the identifier used by the AP to identify and retrieve directly a PMK previously shared between the STA and the AP in next association requests without performing again extensible authentication protocols (EAP) and remote authentication dial-in user service (RADIUS). After installing the PMK 302, the AP 320 initiates the 4-way handshake 350 to generate the session cryptographic key used to encrypt the further data to be transmitted. 4 Messages are exchanged 351, 352, 353 and 354 are exchanged during the 4-way handshake 350. In message 4 (354) of the 4-way handshake 350, Client 310 includes an IRM KDE which contains the new IRM MAC address that it has generated which corresponds to the MAC address that the Client 310 will be used at the next association with the AP 320. The new IRM MAC address is referred to as IRM-MAC-Address. At the end of the 4-way handshake, both Client 310 and AP 320 generates a PTK, referred to as PTK1 303, based on the PMK 302. When the Client 310 or the AP 320 operates a disassociation 355 of the Client 310, both compute a new PMKID, referred to as PM KID-1 RM 304, based on the address IRM-MAC-Address: PMKID-IRM = Truncate-128(HMAC-SHA-1(PMK, “PMK Name” || AA || SPA)); wherein AA the MAC address of the AP 320 and SPA the address IRM-MAC-Address. The AP 320 updates its mapping information by replacing locally the PMKID of the Client PMKID-RCM by the PMKID PMKID-IRM to identify the cached PMK. When the non-AP STA (Client) 310 intends to associate with an AP for which it has cached a Pairwise Master Key (PMK) relative to it, it initiates an association procedure 360 in which it indicates in the Robust Security Network Information Element (RSNE) of the Association Request frame 362 its supported Group and Pairwise Cipher and Authentication and Key Management (AKM) suites and includes in the field “PMKID List” the PMKID-IRM. At the reception of the Association Request frame 362, the AP 320 extracts the PMKID-IRM from the field “PMKID List” of the RSNE and retrieves locally the corresponding PMK 302 of the Client 310. Next it initiates the 4-way handshake 370 and at the 4-way handshake 370 end of the both Client 310 and AP 320 generates a PTK, referred to as PTK2 305, based on the PMK 302. Note that the AP the STA (re)associates with may be the AP 320 the STA just deassociates from or another AP of the ESS that received the address IRM-MAC-Address from AP 320 (and that previously cached the PMK). Figure 4 illustrates, using a flowchart, main steps of a communication method at a communication device, according to various embodiments of the disclosure. These steps are for instance performed by the network controller or by an AP according to the FT exemplary embodiment and / or the IRM exemplary embodiment. The method starts (step 410) by generating a Pairwise Master Key (PMK) and a first PMK identifier for identifying the PMK, the generating is based on a first media access control (MAC) address of a station. At an optional step 411, the generated PMK and the PMK identifier are communicated to an AP or within the AP if the generation is performed internally. At step 412, a second PMK identifier for identifying the PMK based on a second MAC address of the station is generated. This may be triggered by the determination that the station has changed, or is about to change, its MAC address. At step 413, mapping information at the AP is updated for identifying the PMK using the second PMK identifier. In the FT exemplary embodiment, the first PMK identifier and the second PMK identifier may represent the previous PMKRIName and the new PMKRIName, respectively. In the IRM exemplary embodiment, the first PMK identifier and the second PMK identifier may represent PMKID-RCM and PMKID-IRM, respectively. Described embodiments of the invention advantageously allow to perform the necessary key identifiers updates prior their use in a later stage, for example during a FT protocol or during a reassociation. Shorter re-authentications are achieved even if the MAC address changes. The described embodiments advantageously ensure that legacy protocols relying on a fixed MAC address remain operable without adaptation. Thus, for example, AP and non-AP stations continue to execute conventional IMDA and FT protocol while still supporting the ability for a Client to change randomly its MAC address while it is associated with an AP. Also, PMK keys (e.g., PMK-R1 for FT exemplary embodiment or PMK for IRM exemplary embodiment) are not re-computed which saves time and resources. Figure 5 schematically illustrates a communication device 500, 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 500 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 500 may comprise a communication bus 513 to which may be connected: - a central processing unit 501, such as a processor, denoted CPU; - a memory 503, 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 502 and 502’ 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 504 and 504’, respectively. Preferably the communication bus 513 may provide communication and interoperability between the various elements included in the communication device 500 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 500 directly or by means of another element of the communication device 500. 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 502 or 502’, in order to be stored in the memory 503 of the communication device 500 before being executed. In an embodiment, the device 500 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 communication method in a communication network, the method comprising:generating a Pairwise Master Key (PMK) and a first PMK identifier for identifying the PMK, the generating is based on a first media access control (MAC) address of a station;generating a second PMK identifier for identifying the PMK based on a second MAC address of the station; andupdating mapping information for identifying the PMK using the second PMK identifier.

2. The method of claim 1, further comprising determining a change of the MAC address of the station from the first MAC to the second MAC address.

3. The method of claim 2, wherein the change of the MAC address of the station is performed while the station is associated with a first AP.

4. The method of claim 3, wherein the determining of the change comprises receiving a notification from the first AP notifying that the MAC address of the station changed from the first MAC address to the second MAC address.

5. The method of claim 3, wherein the first and the second PMK identifiers are communicated to a second AP of the communication network.

6. The method of claim 3, wherein the first and the second PMK identifiers are communicated to the first AP.

7. The method of any one of claims 1 to 6, further comprising associating thefirst PMK identifier with the second PMK identifier.

8. The method of claim 1, wherein the generating of the first PMK identifier comprises:generating a primary PMK (PMK-RO) and a primary PMK identifier (PMKROName) based on the first MAC address of a station; andwherein the generating the first PMK identifier is further based on PMKROName and the generating of the PMK is based on PMK-RO.

9. The method of claim 8, wherein the generating of the second PMK identifier is further based on PMK-RO.

10. The method of claims 7 and 8, wherein the associating is based on the primary PMK identifier (PMKROName).

11. The method of claim 7, wherein the associating is based on an Identifiable Random MAC (IRM) address.

12. A wireless communication method comprising, at an access point (AP):receiving, from a controller, a Pairwise Master Key (PMK) and a first PMK identifier for identifying the PMK generated based on a first media access control (MAC) address of a station;storing in a cache table an entry associating the first PMK identifier with the PMK received from the controller;receiving, from the controller, a second PMK identifier for identifying the PMK generated based on a second MAC address of the station; andupdating the cache table entry for associating the second PMK identifier with the PMK.

13. The method of claim 12, comprising:associating with a station;determining a PMK identifier associated with the station;retrieving, from the cache table, a cached PMK which associated PMK identifier matches the determined PMK identifier; andgenerating a Pairwise Transient Key (PTK) based on the retrieved PMK for encrypting messages exchanged between the station and the AP.

14. The method of claim 13, wherein the PMK identifier is determined from an information element received from the station in association request.

15. The method of claim 13, wherein determining the PMK identifier comprises:receiving, from the station, a primary PMK identifier (PMKROName) in Authentication request; andgenerating the PMK identifier (PMKRIName) based on PMKROName and the MAC address of the station.

16. The method of claim 14, further comprising:receiving, from the station, a PMK identifier (PMKR1Name_RCV) in association request;checking if the received PMKR1Name_RCV matches the generated PMKRIName, and if there is no matching, the association is refused.

17. A wireless communication device comprising at least one microprocessorconfigured for carrying out the steps of the method of Claim 1 or 12.

18. 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 the method of Claim 1 or 12.

Images