Apparatus and method for policy communication in wireless local area network

Abstract

An access point (AP) (110) for communicating with a non-AP site (120) in a wireless local area network (WLAN) (130). The AP (110) comprises processing circuitry (111) for generating a random number and a communication interface (113) for sending a first message to the non-AP site (120). The first message (202) comprises the random number. In response to receiving a second message from the non-AP site (120), the processing circuitry (111) is also configured to encrypt information about one or more policies. The information about the one or more policies identifies one or more policies to be applied by the non-AP site (120). The communication interface (113) is also configured to send a third message to the non-AP site (120). The third message includes the encrypted information about the one or more policies.

Description

Technical Field

[0001] The present invention relates to wireless communications and more particularly to an apparatus and method for policy communications in a wireless local area network. Background Art

[0002] In a controlled network, a wireless local area network (WLAN) infrastructure can apply network policies to WLAN devices (e.g., STAs) when non-AP stations (STAs) are authenticated and connected to the infrastructure. The network policies may include, for example, functions and rules such as packet filtering, flow classification, and traffic optimization. Typically, the network policy is associated with a user and is received from a network policy server using authentication, authorization, and accounting (AAA) and IEEE 802.11 (air) protocols. However, in traditional association methods, network policies are sometimes received and applied in the WLAN infrastructure without being sent to WLAN devices. However, in some cases, in order to apply the network policy when the security association is completed, the network policy needs to be sent to the WLAN device (e.g., based on the channel access of the WLAN device). In this case, secure delivery of policy communication is required to prevent the user's personally identifiable information (PII) from being leaked. Summary of the invention

[0003] An object of the present invention is to provide an apparatus and method for more secure policy communication in a wireless local area network.

[0004] The above and other objects are achieved by the subject matter of the independent claims. Other implementations are apparent from the dependent claims, the description and the drawings.

[0005] According to a first aspect, an access point (AP) is provided. The AP is used to communicate with a non-AP station in a wireless local area network (WLAN) (specifically, a WLAN based on IEEE 802.11). The AP includes a processing circuit, which is used to generate a random number (also called an authenticator's random number or ANonce). The AP also includes a communication interface, which is used to send a first message to the non-AP station. The first message includes the random number. In response to receiving a second message from the non-AP station, the processing circuit is also used to encrypt information about one or more policies. The information about the one or more policies identifies one or more policies to be applied by the non-AP station. The communication interface is also used to send a third message to the non-AP station. The third message includes the encrypted information about the one or more policies.

[0006] In another possible implementation of the first aspect, the first message is a first Extensible Authentication Protocol over Local Area Network (EAPOL) key message, the second message is a second EAPOL key message, and the third message is a third EAPOL key message of a four-way handshake between the AP and the non-AP station. The second EAPOL key message includes another random number (also called a requester's random number or SNonce).

[0007] In yet another possible implementation manner of the first aspect, in response to sending the third EAPOL-Key message to the non-AP station, the communication interface is further configured to receive a fourth EAPOL-Key message from the non-AP station.

[0008] In another possible implementation of the first aspect, the processing circuit is used to derive one or more cryptographic keys based on the random number and / or the other random number. In one implementation, the processing circuit is used to derive the one or more cryptographic keys based on the random number and / or the other random number and credential information and other parameters in the message. The credential information may include a password or a key associated with a certificate, which is configured on the device.

[0009] In another possible implementation manner of the first aspect, the second EAPOL-Key message includes a request by the non-AP station for the information about the one or more policies.

[0010] In another possible implementation of the first aspect, the first message is an 802.11 authentication response, the second message is an association request, and the third message is an association response for a fast transition or a fast initial link establishment between the AP and the non-AP station.

[0011] In another possible implementation of the first aspect, in response to receiving an 802.11 authentication request from the non-AP station, the communication interface is configured to send the 802.11 authentication response to the non-AP station. The 802.11 authentication request includes another random number (also referred to as a requester's random number or SNonce).

[0012] In another possible implementation of the first aspect, the processing circuit is used to derive one or more cryptographic keys based on the random number and / or the other random number. In one implementation, the processing circuit is used to derive the one or more cryptographic keys based on the random number and / or the other random number and credential information and other parameters in the message. The credential information may include a password or a key associated with a certificate, which is configured on the device.

[0013] In another possible implementation manner of the first aspect, the association response includes a mobility domain element (MDE). The encrypted information about the one or more policies is part of the MDE.

[0014] In another possible implementation manner of the first aspect, the 802.11 authentication request of the non-AP station includes a request by the non-AP station for the information about the one or more policies.

[0015] In yet another possible implementation manner of the first aspect, the third message including the encrypted information about the one or more policies includes information about the number of the one or more policies.

[0016] In another possible implementation of the first aspect, the third message including the encrypted information about the one or more policies includes an indicator of the corresponding type of the one or more policies and / or information about the corresponding size of the one or more policies.

[0017] In yet another possible implementation of the first aspect, the communication interface is used to receive the information about the one or more policies from a policy server.

[0018] According to a second aspect, a method of operating an access point (AP) is provided. The AP is used to communicate with non-AP stations in a wireless local area network (WLAN).

[0019] The method comprises the following steps: generating a random number (also called an authenticator's random number or ANonce).

[0020] The method further includes the following steps: sending a first message to the non-AP site, wherein the first message includes the random number.

[0021] The method further includes the step of encrypting information about one or more policies in response to receiving a second message from the non-AP station, wherein the information about the one or more policies identifies one or more policies to be applied by the non-AP station.

[0022] The method further comprises the step of sending a third message to the non-AP station, wherein the third message comprises the encrypted information about the one or more policies.

[0023] The method provided in the second aspect of the present invention can be performed by the AP provided in the first aspect of the present invention. Therefore, other features of the method provided in the second aspect of the present invention are directly implemented by the functions of the AP provided in the first aspect of the present invention and its above-mentioned and below-mentioned different implementation modes.

[0024] According to a third aspect, a computer program product is provided, wherein the computer program product comprises program code, and when the program code is executed by a computer or a processor, the program code enables the computer or the processor to perform the method provided by the second aspect.

[0025] According to a fourth aspect, the present invention provides a method for exchanging policy information between an access point (AP) and a non-AP station in a wireless local area network (WLAN). The method includes: the AP and the non-AP station exchanging authentication messages, and deriving a key from the authentication messages. The method also includes: the AP sending a policy information request to the non-AP station. In addition, the method also includes: the AP receiving a policy information response from the non-AP station.

[0026] In yet another possible implementation manner of the fourth aspect, the policy information request is a modified EPCS priority access enablement request frame.

[0027] In yet another possible implementation manner of the fourth aspect, the modified EPCS priority access enabling request includes a policy multilink element that replaces the priority access multilink element.

[0028] In yet another possible implementation manner of the fourth aspect, the policy information response is a modified EPCS priority access enable response frame.

[0029] In yet another possible implementation manner of the fourth aspect, the modified EPCS priority access enable response frame includes a policy multilink element that replaces the priority access multilink element.

[0030] According to a fifth aspect, the present invention provides a method for exchanging policy information between an access point (AP) and a non-AP station in a wireless local area network (WLAN). The method includes: the AP and the non-AP station exchanging authentication messages, and deriving a key from the authentication messages. The method also includes: the non-AP station sending a policy information request to the AP. In addition, the method also includes: the non-AP station receiving a policy information response from the AP.

[0031] In yet another possible implementation manner of the fifth aspect, the policy information request is a modified EPCS priority access enablement request frame.

[0032] In yet another possible implementation manner of the fifth aspect, the modified EPCS priority access enabling request includes a policy multilink element that replaces the priority access multilink element.

[0033] In yet another possible implementation manner of the fifth aspect, the policy information response is a modified EPCS priority access enable response frame.

[0034] In another possible implementation manner of the fifth aspect, the modified EPCS priority access enable response frame includes a policy multilink element that replaces the priority access multilink element.

[0035] According to a sixth aspect, the present invention provides an access point (AP). The AP is used to communicate with a non-AP site in a wireless local area network (WLAN), and the AP includes a communication interface, and the communication interface is used to exchange authentication messages with the non-AP site and derive a key from the authentication message. The communication interface is also used to send a policy information request to the non-AP site. In addition, the communication interface is also used to receive a policy information response from the non-AP site.

[0036] In another possible implementation manner of the sixth aspect, the policy information request is a modified EPCS priority access enablement request frame.

[0037] In another possible implementation manner of the sixth aspect, the modified EPCS priority access enabling request includes a policy multilink element that replaces the priority access multilink element.

[0038] In another possible implementation manner of the sixth aspect, the policy information response is a modified EPCS priority access enable response frame.

[0039] In another possible implementation manner of the sixth aspect, the modified EPCS priority access enable response frame includes a policy multilink element that replaces the priority access multilink element.

[0040] According to a seventh aspect, the present invention provides a non-AP site. The non-AP site is used to communicate with an AP in a wireless local area network (WLAN), and the non-AP site includes a communication interface, the communication interface is used to exchange authentication messages with the AP, and derive a key from the authentication message. The communication interface is also used to send a policy information request to the AP site. In addition, the communication interface is also used to receive a policy information response from the AP.

[0041] In another possible implementation manner of the seventh aspect, the policy information request is a modified EPCS priority access enablement request frame.

[0042] In another possible implementation manner of the seventh aspect, the modified EPCS priority access enabling request includes a policy multilink element that replaces the priority access multilink element.

[0043] In another possible implementation manner of the seventh aspect, the policy information response is a modified EPCS priority access enable response frame.

[0044] In another possible implementation manner of the seventh aspect, the modified EPCS priority access enable response frame includes a policy multilink element that replaces the priority access multilink element.

[0045] According to an eighth aspect, the present invention provides a computer-implemented data structure for any of the methods of the fourth aspect and the fifth aspect. The data structure includes a policy information request, the policy information request includes a category field, a protected EHT action field, a dialog token field, and a policy multilink element field.

[0046] According to a ninth aspect, the present invention provides a computer-implemented data structure for any one of the sixth aspect and the seventh aspect. The data structure includes a policy information response, the policy information response including a category field, a protected EHT action field, a dialog token field, a status code field, and a policy multilink element field.

[0047] The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages are apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. In the accompanying drawings:

[0049] Figure 1 An exemplary wireless local area network is shown;

[0050] Figure 2a A signaling diagram between an AP and a non-AP station using a four-way handshake provided by an embodiment is shown;

[0051] Figure 2b A signaling diagram between an AP and a non-AP station using a request / response-based four-way handshake provided by an embodiment is shown;

[0052] Figure 3a A signaling diagram between an AP and a non-AP station using fast transition message exchange provided by one embodiment is shown;

[0053] Figure 3b A signaling diagram between an AP and a non-AP station using a request / response based fast transition message exchange provided by one embodiment is shown;

[0054] Figure 3c A signaling diagram between an AP and a non-AP station using a fast initial link setup message exchange provided by one embodiment is shown;

[0055] Figure 3d shows sites using a request / response based fast initial link establishment message exchange;

[0056] Figures 4a to 4d A data structure of policy key data encapsulation generated by an AP provided by an embodiment is shown;

[0057] Figure 5 A flowchart showing the steps of a method for operating an AP in a WLAN provided by an embodiment;

[0058] Figure 6a and Figure 6bThe data structures of the EPCS priority access enable request frame (IEEE 802.11 draft 1.4) of the prior art and the modified EPCS priority access enable request frame of the present invention are respectively shown;

[0059] Figure 6c and Figure 6d The data structures of the EPCS priority access enable response frame (IEEE 802.11 draft 1.4) of the prior art and the modified EPCS priority access enable response frame of the present invention are respectively shown;

[0060] Figure 7 A signaling diagram for exchanging policy information between an AP and a non-AP station provided by an embodiment is shown.

[0061] In the following, identical reference signs refer to identical or at least functionally equivalent features. DETAILED DESCRIPTION

[0062] In the following description, reference is made to the accompanying drawings that form a part of the present invention, which illustrate specific aspects of embodiments of the present invention or specific aspects in which embodiments of the present invention may be used by way of illustration. It should be understood that embodiments of the present invention may be used in other aspects and include structural or logical changes that are not depicted in the accompanying drawings. Therefore, the following specific embodiments should not be understood in a restrictive sense, and the scope of the present invention is defined by the appended claims.

[0063] For example, it should be understood that the disclosure related to describing a method may also be applicable to a corresponding device or system for performing the method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units (e.g., functional units) to perform the described one or more method steps (e.g., one unit performs one or more steps, or multiple units perform one or more of the multiple steps respectively), even if such one or more units are not explicitly described or illustrated in the drawings. On the other hand, for example, if a specific device is described based on one or more units (e.g., functional units), the corresponding method may include a step to perform the function of one or more units (e.g., one step performs the function of one or more units, or multiple steps perform the function of one or more of the multiple units respectively), even if such one or more steps are not explicitly described or illustrated in the drawings. In addition, it is understood that, unless otherwise explicitly stated, the features of the various exemplary embodiments and / or aspects described herein may be combined with each other.

[0064] Figure 1An exemplary wireless local area network (WLAN) 130 is shown, and the WLAN 130 includes an access point (AP) 110, and the AP 110 is used to communicate with a non-AP site 120. The non-AP site 120 can be a smartphone 120, etc. The WLAN 130 may include a plurality of other APs or non-AP sites 110'. The WLAN 130 may be connected to a subscription service provider network (SSPN) 140, SSPN 140, through a gateway 131. The SSPN 140 may include a policy server 150 and an authentication, authorization and accounting (AAA) server 160. Alternatively, the WLAN 130 may include the policy server 150 and / or the AAA server 160.

[0065] like Figure 1 As shown, AP 110 includes a processing circuit 111 and a communication interface 113 (specifically, a wireless communication interface 113 based on the IEEE 802.11 standard framework). The processing circuit 111 can be implemented in hardware and / or software, and can include a digital circuit, or both an analog circuit and a digital circuit. The digital circuit can include components such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), or a general-purpose processor. AP 110 may also include a memory 115, which is used to store executable program code. When the executable program code is executed by the processing circuit 111, the executable program code enables AP 110 to perform the functions and methods described herein.

[0066] Before describing various embodiments of the AP 110 in detail, some technical background and terminology are introduced below using one or more of the following abbreviations:

[0067] AAA Authentication, Authorization and Accounting

[0068] AP Access Point

[0069] BSS Basic Service Set

[0070] CID Company Identifier

[0071] DIAMETER authentication, authorization, and accounting protocol for computer networks

[0072] EDCA Enhanced Distributed Channel Access

[0073] EHT Extremely High Throughput

[0074] EPCS Emergency Preparedness Communications service

[0075] FILS Fast Initial Link Setup

[0076] FT Fast Transition

[0077] KDE Key Data Encapsulation

[0078] LDAP Lightweight Directory Access Protocol

[0079] MLD Multi-Link Device

[0080] MLO Multi-Link Operation

[0081] OUI Organizationally Unique Identifier

[0082] PII Personally Identifiable Information

[0083] PTK Pairwise Transient Key

[0084] QoS Quality of Service

[0085] RADIUS Remote Authentication Dial-In User Service

[0086] RSNA Robust Security Network Association

[0087] STA Station

[0088] SSPN Subscription Service Provider Network

[0089] TID Traffic Identifier

[0090] For example, in a conventional method, when a non-AP station 120 associates with an AP 110 in a WLAN 130, the communication interface 113 of the AP 110 may communicate with the AAA server 160 through an authentication protocol such as RADIUS or DIAMETER. The AAA server 160 and the non-AP station 120 may perform mutual authentication. When the authentication is successful, the AAA server 160 may retrieve a policy for the non-AP station 120 from the policy server 150 through a protocol such as LDAP, and send the authentication result together with the policy back to the communication interface 113 of the AP 110. When the authentication is successful, the non-AP station 120 may establish a network connection, and the communication interface 113 of the AP 110 may apply a network policy for the STA 120. The network policy may include functions such as packet filtering, flow classification, and traffic optimization.

[0091] Within IEEE 802.11, information transmitted between two peer STAs that may help determine information about the identity of a device user is considered personally identifiable information (PII). One recognized method to reduce the leakage of PII within IEEE 802.11 messages is to encrypt messages between non-AP stations 120 and AP 110 and to minimize the information exchanged when establishing network access.

[0092] An EDCA parameter set is defined as a set of IEEE 802.11 channel access parameters to achieve traffic optimization. AP 110 may use beacons and probe responses to advertise the EDCA parameter set to be used for communications in a BSS (i.e., non-AP sites 120 and their associated APs 110). These announcements are broadcast from AP 110 to all non-AP sites 120 in the clear (e.g., unencrypted).

[0093] In addition, IEEE 802.11be defines a feature called Multi-Link Operation (MLO) that allows two MLDs (AP MLD and non-AP MLD) to communicate over multiple independent wireless connections or links. One feature of MLO is called TID-to-link mapping. TID-to-link mapping allows two MLDs to negotiate which traffic types to transmit between them over which link. TID-to-link mapping can be negotiated (i) during the association request and response messages, or (ii) through action frames after the devices have successfully associated. However, in option (i), the TID-to-link mapping information is transmitted in clear text, which compromises the security of the information, while in option (ii), the action frame, although having an encrypted payload, still allows the source and destination addresses to be tracked, which leaks PII.

[0094] In a controlled network, when a STA successfully associates with the network, the AP infrastructure receives the network policy from the AAA infrastructure. The network policy is applied in the AP and is not sent to the STA.

[0095] Different from the packet filtering and traffic optimization policies applied in AP 110, other policies such as TID to link mapping or uplink EDCA channel access parameters need to be sent to non-AP stations 120. Other policies such as TID to link mapping are negotiated when exchanging 802.11 association request / response frames, or through management frame exchange after a successful association.

[0096] The problem is that during the IEEE 802.11 association / four-way handshake exchanges, STA-specific policies are not sent in a secure manner from AP 110. These policies are transmitted in the clear (e.g., unencrypted) during these exchanges, or in a separate frame exchange after these exchanges are completed.

[0097] If authentication is performed with a STA using an authentication protocol such as Extensible Authentication Protocol (EAP) that requires an AAA server, the AP infrastructure may need to assign a policy to the STA after exchanging association request / response frames and completing the association.

[0098] Accordingly, at the time of the IEEE 802.11 association / four-way handshake exchange, there is no mechanism for non-AP station 120 to request a policy from policy server 150 through AP 110 and AAA server 160 and receive a response in a secure manner.

[0099] For example, EDCA channel access parameters are broadcast to the BSS (i.e., in beacons and probe responses), and the TID-to-link mapping policy is transmitted (i) in the clear during the IEEE 802.11 association / four-way handshake exchange, or (ii) in a separate frame exchange after the IEEE 802.11 association / four-way handshake exchange is completed. Another issue is that in these examples, PII is leaked. Policy data is transmitted in the clear or within the encrypted payload of a protected frame (e.g., TID-to-link mapping after an association exchange), which still leaks the source and destination addresses of the protected frame exchange.

[0100] Figure 2a FIG. 1 is a flowchart showing steps implemented by the processing circuit 111 of the AP 110 through a four-way handshake of a Robust Security Network Association (RSNA) according to an embodiment. It should be understood that Figure 2a and the following Figures 2b to 3d Only a few selected parameters of the message are shown.

[0101] exist Figure 2a In step 201, the processing circuit 111 of the AP 110 is used to generate a random number (also called ANonce) of the authenticator. The communication interface 113 of the AP 110 sends a first message 202 to the non-AP station 120 (or simply "STA 120"). The first message 202 includes the random number and other parameters not shown. Figure 2a As shown, the first message 202 may be a first Extensible Authentication Protocol over Local Area Network (EAPOL) key message of a four-way handshake between the AP 110 and the non-AP station 120 .

[0102] exist Figure 2a In step 203, communication interface 113 may receive second message 204 from non-AP station 120. Second message 204 may be a second EAPOL-Key message of a four-way handshake between AP 110 and non-AP station 120. The second EAPOL-Key message may include a supplicant's random number (also referred to as SNonce).

[0103] exist Figure 2a In step 205, in response to sending the second message 204, the non-AP station 120 may derive a pairwise transient key (PTK) based on ANonce and SNonce as well as stored credential information and other parameters in the message.

[0104] exist Figure 2a In step 207, in response to receiving the second message 204 from the non-AP site 120, the processing circuit 111 of the AP 110 can also derive the corresponding PTK, i.e., one or more cryptographic keys, based on the ANonce and / or SNonce and the stored credential information and other parameters in the message not shown. Specifically, based on the one or more cryptographic keys, the processing circuit 111 is also used to encrypt information about one or more policies. The information about one or more policies identifies the one or more policies to be applied by the non-AP site 120.

[0105] exist Figure 2a In step 209, the communication interface 113 is further configured to send a third message 210 to the non-AP site 120. The third message 210 includes encrypted information about the one or more policies. As further described below, the information about the one or more policies may be included in a policy key data encapsulation (KDE) 400. The communication interface 113 may be configured to receive information about the one or more policies from the policy server 150. The third message 210 may be a third EAPOL key message of a four-way handshake between the AP 110 and the non-AP site 120. The third message 210 including the encrypted information about the one or more policies may include a number 401 of the one or more policies (e.g., Figure 4a The third message 210 may also include an indicator of the corresponding type 405 of the one or more policies and / or information about the corresponding size 407 of the one or more policies. In addition, the AP 110 may send a capability bit to indicate whether the AP 110 and / or other APs 110′ in the WLAN 130 supports the one or more policies.

[0106] exist Figure 2a In step 211 , in response to sending the third EAPOL-Key message to the non-AP station 120 , the communication interface 113 may also be configured to receive a fourth EAPOL-Key message from the non-AP station 120 .

[0107] Figure 2b FIG. 1 is a flowchart showing the steps of the processing circuit 111 of the AP 110 implemented by the RSNA request / response based four-way handshake. Figure 2a The different steps of the embodiment.

[0108] exist Figure 2bIn step 205, in response to receiving the first message 202, the non-AP station 120 may derive the PTK based on the random number and the stored credential information and other parameters within the message. The non-AP station 120 may also be configured to encrypt a request for information about one or more policies.

[0109] exist Figure 2b In step 203, the second EAPOL-Key message received by AP 110 may also include a request from non-AP station 120 for information about one or more policies.

[0110] exist Figure 2b In step 207, specifically, based on one or more cryptographic keys, the processing circuit 111 may also be configured to encrypt a response to the requested information regarding the one or more policies.

[0111] exist Figure 2b In step 209, the third EAPOL-Key message sent from AP 110 may also include a response to the requested information about one or more policies.

[0112] Figure 3a The flowchart of the steps implemented by the processing circuit 111 of the AP 110 through the fast initial link setup (FILS) according to an embodiment is shown. As described above, the communication interface 113 is used to send the first message 202 and the third message 210 to the non-AP station 120. In addition, the communication interface 113 is used to receive the second message 204 from the non-AP station 120. The following only describes the steps related to the above. Figure 2a The different steps of the embodiment.

[0113] As shown in step 301, before sending the first message 202, the communication interface 113 may be used to receive an 802.11 authentication request from the non-AP station 120. The 802.11 authentication request may include a requester's random number SNonce. The 802.11 authentication request from the non-AP station 120 may also include a request from the non-AP station 120 for information about one or more policies.

[0114] like Figure 3aAs further shown in steps 303 to 307 in FIG. 1 , the first message 202 may be an 802.11 authentication response, the second message 204 may be an association request, and the third message 210 may be an association response of FILS between the AP 110 and the non-AP site 120. Therefore, information about one or more policies (specifically, the policy KDE 400) may be transmitted between the AP 110 and the non-AP site 120 via a FILS association (reassociation) request / response. In addition, the AP 110 may send a capability bit to indicate whether the AP 110 and / or other APs 110′ in the WLAN 130 support one or more policies.

[0115] exist Figure 3a In step 307, information about one or more policies (specifically policy KDE 400) may be piggybacked (ie, transmitted) in the FILS exchange association (reassociation) response frame. In this case, the key transfer element may carry key information, as shown in policy KDE 400.

[0116] Figure 3b FIG. 1 is a flowchart showing the steps implemented by the processing circuit 111 of the AP 110 through a fast conversion based on request / response according to an embodiment. Figure 3a The different steps of the embodiment.

[0117] like Figure 3b As further shown in steps 303 to 307 in FIG. 1 , the first message 202 may be an 802.11 authentication response, the second message 204 may be an association request, and the third message 210 may be an association response of a fast transition (FT) between the AP 110 and the non-AP site 120 using a specific fast (BSS) transition authentication algorithm (Fast Transition Authentication Algorithm, FTAA). Therefore, information about one or more policies (specifically, policy KDE 400) may be transmitted between the AP 110 and the non-AP site 120 via a FT association (reassociation) request / response. The policy KDE 400 may be piggybacked (i.e., transmitted) within the FT exchange association (reassociation) response frame. The Mobility Domain Element (MDE) may carry key information including the policy KDE 400. In other words, the association response may include the MDE, and the encrypted information about the one or more policies may be part of the MDE.

[0118] Figure 3c FIG. 1 is a flowchart showing the steps implemented by the processing circuit 111 of the AP 100 through the FILS according to an embodiment. Figure 3aThe different steps of the embodiment.

[0119] exist Figure 3c In step 205, in response to receiving the first message 202, the non-AP station 120 may derive the PTK based on the ANonce and / or SNonce and other parameters within the message. The non-AP station 120 may also be configured to encrypt a request for information about one or more policies.

[0120] exist Figure 3c In step 305, the second message 204 received by the AP 110 may also include a request from the non-AP station 120 for information about one or more policies.

[0121] exist Figure 3c In step 207, specifically, based on one or more cryptographic keys, the processing circuit 111 may also be configured to encrypt a response to the requested information regarding the one or more policies.

[0122] exist Figure 3c In step 307, the third message 210 sent from AP 110 may also include a response to the requested information about one or more policies. In addition, AP 110 may send a capability bit to indicate whether AP 110 and / or other APs 110' in WLAN 130 support one or more policies.

[0123] Figure 3d FIG. 1 is a flowchart showing steps of the processing circuit 111 of the AP 110 provided by an embodiment to implement the fast initial link establishment based on request / response. Figure 3b The different steps of the embodiment.

[0124] exist Figure 3d In step 205, in response to receiving the first message 202, the non-AP station 120 may derive the PTK based on the ANonce and / or SNonce and stored credential information and other parameters within the message. The non-AP station 120 may also be configured to encrypt a request for information about one or more policies.

[0125] exist Figure 3d In step 305, the second message 204 received by the AP 110 may also include a request from the non-AP station 120 for information about one or more policies.

[0126] exist Figure 3d In step 207, specifically, based on one or more cryptographic keys, the processing circuit 111 may also be configured to encrypt a response to the requested information regarding the one or more policies.

[0127] exist Figure 3dIn step 307, the third message 210 sent from AP 110 may also include a response to the requested information about one or more policies. In addition, AP 110 may send a capability bit to indicate whether AP 110 and / or other APs 110' in WLAN 130 support one or more policies.

[0128] Figures 4a to 4d The data structure of the policy KDE 400 is shown. The policy KDE 400 may include the above Figures 2a to 3d The policy information of the second message 204 and / or the policy information of the third message 210 of the four-way handshake, or the association request / response message. The policy KDE 400 may be transmitted in a secure manner before the non-AP station 120 establishes network access. The policy KDE 400 allows the AP 110 to securely provide a set of policies to the non-AP station 120 during the association / four-way handshake exchange.

[0129] A new KDE selector may be generated according to Table 12-10 of IEEE 802.11 REVme D1.0 to indicate that the KDE is a "Policy KDE." The OUI associated with this entry may be "00-0F-AC," and so on.

[0130] like Figure 4a As shown, the data field of the policy KDE 400 may include information on a policy quantity 401 in units of a single octet (ie, byte) and a policy field 403 in units of variable octets.

[0131] like Figure 4b As further shown, the policy field 403 may include an indicator of a policy type 405, an indicator of policy data 409 (i.e., information about one or more policies in units of variable octets), and an indicator of a size 407 (i.e., the length 407 of the information about one or more policies in units of a single octet).

[0132] Table 1: Policy type definitions

[0133]

[0134]

[0135] As shown in Table 1, various policy types 405 may be defined.

[0136] If the policy type 405 is illustratively set to 1 or 2, then an upstream TID-to-link mapping of a non-AP MLD or a downstream (unicast) TID-to-link mapping of a non-AP MLD may be defined.

[0137] If the policy type 405 is illustratively set to 3, uplink EDCA parameters may be defined.

[0138] If the policy type 405 is illustratively set to 4, a security association identifier or policy for assisting a security association between the non-AP station 120 and the AP 110 may be defined.

[0139] If the policy type 405 is illustratively set to 5, an aware STA that needs a policy to set an awareness threshold, filter, and privacy value, such as the non-AP station 120, may be defined.

[0140] If the policy type 405 is illustratively set to 6, an aware STA that needs a policy to set a ranging threshold, a frame rate, and privacy, such as the non-AP station 120, may be defined.

[0141] If the policy type 405 is illustratively set to 127, all available policies in the AP may be returned in the response message.

[0142] If policy type 405 is illustratively set to 126, then the removal policy type is used, for example, when AP 110 wishes to remove any applied policies in non-AP station 120. If a policy needs to be changed or removed, AP 110 may do so by sending an EAPOL-Key message (e.g., Figure 2a and Figure 2b ) or by including the policy KDE 400 in a protected management frame (as shown in Figure 3b or Figure 3d as shown) to transfer the policy.

[0143] If the policy type 405 is illustratively set to 128 to 255, the policy type 405 may only be used for requests from non-AP stations 120 to AP 110 (as described above). Figure 2b , Figure 3b and Figure 3d In this case, the policy type 405 has bit 7 (+128) set to indicate the direction of the message.

[0144] Figure 4c The policy data field encoding of the EDCA parameter set is shown. In this case, the policy type 405 can be set to 3, as shown in Table 1. The definition of the EDCA parameter set control 411 and data field 413 can be set as defined in 9.4.2.28 of IEEE 802.11 REVmeD1.0. For MLD, the policy can define a link-specific EDCA parameter set 413, that is, the EDCA parameter set 413 is different for each link and may even only apply to one link.

[0145] Figure 4dThe policy data field encoding of the TID to link mapping is shown. In this case, the policy type 405 can be set to 1 or 2 according to the upstream direction or downstream direction of Table 1. The TID to link mapping control 415 can be set as defined in Section 9.4.2.295d of IEEE802.11be D1.4, and the link mappings 417, 419, 421 of TID i (in the current example, 0≤i≤7) can be set as defined in 9.4.2.295d.

[0146] Advantageously, the STA-specific policy information exchanged during the four-way handshake optimizes the connection process. In addition to the policies described above, there are other IEEE 802.11 policies that can utilize this mechanism. Non-AP site 120 can also request STA-specific policy information by sending a request to AP 110 that is forwarded to policy server 150 in WLAN 130 and / or SSPN 140.

[0147] Figure 5 A flow chart showing steps of a method 500 for operating an AP 110 in a WLAN 130 is provided in accordance with one embodiment.

[0148] The method 500 comprises step 501: generating a random number ANonce of the authenticator.

[0149] The method 500 further comprises step 503: sending a first message 202 to the non-AP station 120, wherein the first message 202 comprises a random number and other parameters not shown.

[0150] The method 500 further includes step 505 of encrypting information about the one or more policies in response to receiving the second message 204 from the non-AP station 120 , wherein the information about the one or more policies identifies the one or more policies to be applied by the non-AP station 120 .

[0151] The method 500 further includes step 507: sending a third message 210 to the non-AP station 120, wherein the third message 210 includes encryption information about one or more policies.

[0152] Since the method 500 may be implemented by the AP 110, other features of the method 500 are directly implemented by the functions of the AP 110 and its various embodiments described above and below.

[0153] Figure 6a and Figure 6b The data structures of the EPCS priority access enable request frame of the prior art (IEEE 802.11 draft 1.4) and the modified EPCS priority access enable request frame of the present invention are respectively shown.

[0154] An alternative method is to redefine the existing EPCS priority access enable request (defined in Table 9-623h IEEE802.11 Draft 1.4) to allow the request to carry the policy KDE instead of the EDCA parameter set. The advantage of this is that in addition to the EDCA parameter set, the EPCS priority access enable message can also be used for other policies.

[0155] Figure 6c and Figure 6d The data structures of the EPCS priority access enable response frame of the prior art (IEEE 802.11 draft 1.4) and the modified EPCS priority access enable response frame of the present invention are respectively shown.

[0156] Similar redefinition can be used to adjust the existing EPCS priority access enable response (defined in Table 9-623i IEEE802.11 Draft 1.4) to allow the response to carry the policy KDE instead of the EDCA parameter set. The advantage of this is that in addition to the EDCA parameter set, the EPCS priority access enable message can also be used for other policies.

[0157] Figure 7 A flowchart showing steps implemented by the processing circuit 111 of the AP 110 for policy information exchange according to one embodiment is shown.

[0158] exist Figure 7 In step 701, an access point (AP) and a non-AP station in a wireless local area network (WLAN) exchange authentication messages, and each derives a key from the authentication message. It is easy for those skilled in the art to understand that the process can be triggered by either the access point (AP) or the non-AP station.

[0159] exist Figure 7 In step 702, the AP sends a policy information request to the non-AP station. Alternatively, the non-AP station may be the station that sends the policy information request.

[0160] exist Figure 7 In step 703, the non-AP station sends a policy information response to the AP. If in step 702, the non-AP station is the station that sends the policy information request, it is easy for those skilled in the art to understand that step 703 includes the AP sending a policy information response.

[0161] Those skilled in the art will understand that the "blocks" ("units") in the various figures (methods and devices) represent or describe the functions of an embodiment of the present invention (and not necessarily independent "units" in hardware or software), thereby equally describing the functions or features of the device embodiments and the method embodiments (unit = step).

[0162] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the described embodiments of the device are merely exemplary. For example, unit division is merely a logical function division, and other division methods may be used in actual implementation. For example, multiple units or components may be merged or integrated into another system, or some features may be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or described may be implemented through some interfaces. The indirect coupling or communication connection between devices or units may be implemented in electronic, mechanical or other forms.

[0163] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one location, or may be distributed over multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.

[0164] In addition, the functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

Claims

1. An access point (AP) (110), characterized in that: The AP (110) is used to communicate with a non-AP station (120) in a wireless local area network (WLAN) (130), wherein the AP (110) includes: A processing circuit (111) for generating a random number; and A communication interface (113) configured to send a first message (202) to the non-AP site (120), wherein the first message (202) includes the random number; wherein, in response to receiving a second message (204) from the non-AP station (120), the processing circuit (111) is further configured to encrypt information regarding one or more policies, wherein the information regarding the one or more policies identifies one or more policies to be applied by the non-AP station (120); The communication interface (113) is further configured to send a third message (210) to the non-AP site (120), wherein the third message (210) includes the encryption information related to the one or more policies.

2. The AP (110) according to claim 1, characterized in that: The first message (202) is a first Extensible Authentication Protocol over LAN (EAPOL) Key message, the second message (204) is a second EAPOL Key message, and the third message (210) is a third EAPOL Key message of a four-way handshake between the AP (110) and the non-AP station (120), wherein the second EAPOL Key message includes another random number.

3. The AP (110) according to claim 2, characterized in that: In response to sending the third EAPOL-Key message to the non-AP station (120), the communication interface (113) is further configured to receive a fourth EAPOL-Key message from the non-AP station (120).

4. The AP (110) according to claim 2 or 3, characterized in that: The processing circuit (111) is used for deriving one or more cryptographic keys based on the random number and / or the other random number.

5. The AP (110) according to any one of claims 2 to 4, characterized in that: The second EAPOL-Key message includes a request by the non-AP station (120) for the information regarding the one or more policies.

6. The AP (110) according to claim 1, characterized in that: The first message (202) is an 802.11 authentication response, the second message (204) is an association request, and the third message (210) is an association response for a fast transition or a fast initial link establishment between the AP (110) and the non-AP station (120).

7. The AP (110) according to claim 6, characterized in that: In response to receiving the 802.11 authentication request of the non-AP station (120), the communication interface (113) is used to send the 802.11 authentication response to the non-AP station (120), wherein the 802.11 authentication request includes other random numbers.

8. The AP (110) according to claim 7, characterized in that: The processing circuit (111) is used for deriving one or more cryptographic keys based on the random number and / or the other random number.

9. The AP (110) according to any one of claims 6 to 8, characterized in that: The association response includes a mobile domain element (MDE), and wherein the encrypted information regarding the one or more policies is part of the MDE.

10. The AP (110) according to any one of claims 6 to 9, characterized in that: The 802.11 authentication request of the non-AP station (120) includes a request by the non-AP station (120) for the information regarding the one or more policies.

11. The AP (110) according to any one of the preceding claims, characterized in that: The third message (210) including the encrypted information about the one or more policies includes information about the number (401) of the one or more policies.

12. The AP (110) according to any one of the preceding claims, characterized in that: The third message (210) comprising the encrypted information about the one or more policies comprises an indicator of a respective type (405) of the one or more policies and / or information about a respective size (407) of the one or more policies.

13. The AP (110) according to any one of the preceding claims, characterized in that: The communication interface (113) is used to receive the information about the one or more policies from a policy server (150).

14. A method (500) of operating an access point (AP) (110), characterized in that: The AP (110) is used to communicate with a non-AP station (120) in a wireless local area network (WLAN) (130), and the method (500) includes: Generate (501) a random number; sending (503) a first message (202) to the non-AP site (120), wherein the first message (202) includes the random number; encrypting (505) information about one or more policies in response to receiving a second message (204) from the non-AP station (120), wherein the information about the one or more policies identifies one or more policies to be applied by the non-AP station (120); A third message (210) is sent (507) to the non-AP station (120), wherein the third message (210) includes the encrypted information regarding the one or more policies.

15. A computer program product, characterized in that The computer program product comprises a computer-readable storage medium for storing program code which, when executed by a computer or a processor, causes the computer or the processor to perform the method (500) according to claim 14.

Images