This clause describes the security functions necessary to support an UE that is simultaneously connected to an eNB and a WT for LTE-WLAN Aggregation as described in TS 36.300.
The LWA architecture is shown in Figure G.1-1.
For LTE-WLAN Aggregation the end-points of encryption remain at the respective PDCP layers of the eNB and the UE, even though the PDCP packets traverse a different path via the WLAN Access Network The WT is the termination point of the WLAN Access Network facing the eNB.
The UE-WT link needs to be secured to protect the PDCP and the WLAN signalling in the eNB from possible attacks.
Security requirements for this protection are given below.
The UE-WT link shall be integrity and confidentiality protected.
Xw interface: Control plane (Xw-C) and User plane (Xw-U) need to be integrity protected. User plane (Xw-U) encryption between eNB and WT may NOT be needed since PDCP packets are already encrypted.
Sub clauses below describe how these requirements are met.
The WLAN communication established between the WLAN AP and the UE shall be protected using the IEEE 802.11 security mechanisms. The security key for protecting the over the air WLAN link is computed from the current UE - eNB security context. Security protection within the WLAN network between WT and WLAN AP is out of scope for 3GPP.
When the eNB initially establishes LWA with the UE through a WT for a given AS security context shared between the MeNB and the UE, the eNB generates the S-KWT for the WT and sends it to the WT over the Xw. The same S-KWT is also generated by the UE.
To generate the S-KWT, the eNB shall use a counter, called a WT Counter. The WT Counter shall be incremented for every new computation of the S-KWT as described in the clause G.2.4. The WT Counter is used as freshness input into S-KWT derivation as described in the clause G.2.4, and guarantees, together with the other provisions in the present Annex G, that the same S-KWT is not re-used with the same input parameters as defined in Annex B of the present specification. The latter would result in key-stream re-use. The eNB shall send the value of the WT Counter to the UE over the RRC signalling path when it is required to generate a new S-KWT.
To establish WLAN security, the UE and WT shall use the key S-KWT as equivalent to either the PMK or PSK defined in IEEE 802.11 specification.
To use S-KWT as PMK, the UE shall initialize the PMKSA described in  clause 184.108.40.206.2 with PMKID set to Truncate-128(HMAC-SHA-256(PMK, "PMK Name" || AA || SPA)), where AA = WLAN AP MAC address and SPA = UE MAC address andstart the 4-way handshake on the WLAN link between the UE and the WLAN AP by sending association request with PMKID Information Element included in the request. In case PMKID is not found at the WLAN AP (e.g, AP is not collocated with the WT or AP does not support receipt of S-KWT from WT and initialization of PMKSA), the AP may start EAP authentication by sending EAP Identity Request. A method for the UE and the WT to install PMK and initialize PMKSA from S-KWT at such a WLAN AP is described in clause G.3.
To use S-KWT as PSK, the WT should support PSK AKMs suites 2 and 6 described in  clause 220.127.116.11.3. The UE should use the PSK to start the 4-way handshake.
The control plane signalling between eNB and WT over the Xw interface, that includes the transfer of the S-KWT and the MAC address (i.e. the UE Identity as described in TS 36.463) used to identify the S-KWT in the the WT from the eNB to the WT, shall be confidentiality and integrity protected using security protection as described in clause 5.3.4a and clause 11 of the present specification. Any user plane data between eNB and WT over Xw interface shall be allowed only for authenticated UEs.
When executing the WT Addition procedure (i.e. the initial offload of one or more radio bearers to the WT), or the WT Modification procedure requiring an update of S-KWT, the eNB shall derive an S-KWT as defined in clause G.2.4. The eNB shall forward the generated S-KWT to the WT during the WT Addition procedure or WT Modification procedure requiring key update. When offloading additional bearers to a WT after the initial offload, the S-KWT does not need to be refreshed.
The UE shall derive the S-KWT as described in clause G.2.4.
eNB releases the LWA through a WT Release procedure. Upon LWA Release Requestmessage to WT and Release LWA Configuration message to UE from eNB, both UE and WT shall release the WLAN path and delete the S-KWT key and the subsequent keys derived.
The eNB shall associate a 16-bit counter, WT Counter, with the EPS AS security context.
The WT Counter is used when computing the S-KWT. The UE and the eNB shall treat the WT Counter as a fresh input to S-KWT derivation. That is, the UE assumes that the eNB provides a fresh WT Counter for each S-KWT derivation and does not need to verify the freshness of the WT Counter.
The eNB that supports the LWA DRB offload shall initialize the WT Counter to '0' when the KeNB in the associated AS security context is established. The eNB shall set the WT Counter to '1' after the first calculated S-KWT, and monotonically increment it for each additional calculated S-KWT. The WT Counter value '0' is hence used to calculate the first S-KWT.
If the eNB decides to turn off the LWA offload connection and later decides to re-start the offloading to the same WT, the WT Counter value shall keep increasing, thus keeping the computed S-KWT fresh.
The eNB shall refresh the KeNB of the AS security context associated with the WT Counter before the WT Counter wraps around. Re-freshing the KeNB is done using intra cell handover procedure as described in clause 18.104.22.168 of the present specification. When this KeNB is refreshed, the WT Counter is reset to '0' as defined above.
The system supports update of the S-KWT. The eNB may update the S-KWT for any reason by using the S-KWT update procedure defined in clause G.2. 5.2 of the current specification. If the eNB re-keys its currently active KeNB in an AS security context, the eNB may update any S-KWT associated with that AS security context.
If the eNB decides to perform S-KWT update (see clause G.2.5.1), the eNB shall increment the WT Counter and compute a fresh S-KWT, as defined in clause G.2.4. Then the eNB shall perform a WT Modification procedure to deliver the fresh S-KWT to the WT. The eNB shall provide the value of the WT Counter used in the derivation of the S-KWT to the UE in an integrity protected RRC message. The UE shall derive the S-KWT as described in clause G.2.4.
The UE and WT shall start using a fresh S-KWT when subsequent WLAN authentication is triggered. If there are multiple S-KWT keys at the UE and the WT, the latest S-KWT shall be used. Whenever the UE or WT start using a fresh S-KWT as PMK they shall refresh the IEEE 802.11 security.
During S1 and X2 handover, when the LWA DRB connection between the UE and the WT is released, the UE shall delete the S-KWT and further keys derived based on it.
During or after handover where the LWA configuration is retained through the same WT as explained in clause 10.1.2.2 of TS 36.300, the UE may keep two sets of PDCP keys corresponding to the old PDCP and new PDCP, until an end marker packet is received from the source eNB.
After the UE receives the "end-marker packet", any received PDCP PDUs whose COUNT value is larger than the COUNT value corresponding to the Sequence Number in the "end-marker packet" shall be discarded.
The eNB terminates the PDCP for control plane and user plane for the UE. Hence, the periodic local authentication procedure can be performed between UE and eNB as described in clause 7.5 also for the case the PDCP packets that traverse the WLAN link.
Connectivity can fail on the WLAN side as well as on the LTE side. In both cases, when WLAN or LTE link failure is discovered, the UE shall delete the S-KWT, the eNB shall indicate to the WT to delete the S-KWT.
An existing IEEE 802.1x compliant AP may not support receiving S-KWT from WT and using it as the PMK. In order to support LWA with existing WLAN deployments with such APs, the UE and the WT may leverage the existing EAP authentication procedures at the AP to install PMK and create PMKSA. A 3GPP vendor specific EAP authentication method for LWA, herein after referred to as EAP-LWA, is described in this clause.
In this method, the WT maintains an association of the current UEs instructed to use LWA offloading by an eNB, and the assigned S-KWT for that UE. A new UE identity called the LWA-ID is used to identify the UE to the WT and is derived as shown in step 3 of Figure G.3-1 and is known by the UE and WT. If the WLAN AP does not have the PMK (S-KWT), upon receipt of EAP-Identity Request message from the WLAN AP, the UE sends an EAP-Identity Response message to the AP with an NAI with realm portion including the identifier of the WT where the S-KWT can be found and the LWA-ID as the user portion of the NAI. The AP routes the EAP-Identity Response message to the WT identified by the realm. Upon receipt and successful identification of the UE, the WT initiates EAP-Request Challenge to the UE to perform successful EAP authentication between the UE and WLAN AP and the installation of the PMK at the WLAN AP.
The UE responds with EAP-Identity Response message with the LWA-ID@realm as the UE identity for EAP-LWA. The LWA-ID and realm are set as follows:
LWA-ID = SHA256 (S-KWT, UE MAC addr, "LWA Identity");
realm = lwa.wtid<WTID>.mnc<MNC>.mcc<MCC>. 3gppnetwork.org;
WTID = E-UTRAN Cell Identity (ECI) of eNB;
MNC = MNC of Serving Network PLMN Identity;
MCC = MCC of Serving Network PLMN Identity.
WT derives AUTHRES and MSK as specified in step 15) and compares it with the received AUTHRES. If they are same, EAP-LWA authentication is successful, and proceeds to step 19). Otherwise EAP-Failure message is sent, terminating WLAN association procedure.