Content for TS 33.401 Word version: 18.1.0

1… 4 5… 6… 6.2… 7… 7.2.5… 7.2.8 7.2.9… 7.3… 8… 9… 10… 11… 15… A… B… C… C.1.6 C.2… C.2.7 C.2.8 C.3… C.4.7 D… E… E.2… E.3… F… G… H… I… K…

G.1 Introduction G.2 LTE-WLAN aggregation security G.2.1 Protection of the WLAN Link between the UE and the WT G.2.2 Protection of the Xw interface G.2.3 Addition, modification and release of DRBs in LWA G.2.4 Derivation of keys for the DRBs in LWA G.2.5 Security key update G.2.6 Handover procedures G.2.7 Periodic local authentication procedure G.2.8 LTE and WLAN link failure G.3 Method for installing PMK
...

G (Normative) LTE - WLAN aggregation |R13| p. 152

G.1 Introduction p. 152

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.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. G.1-1: LWA architecture

Figure G.1-1: LWA architecture
(⇒ copy of original 3GPP image)

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.

G.2 LTE-WLAN aggregation security p. 153

G.2.1 Protection of the WLAN Link between the UE and the WT p. 153

The WLAN communication established between the WLAN AP and the UE shall be protected using the IEEE 802.11[39] 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 [39] clause 11.5.1.1.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 [39] clause 9.4.2.25.3. The UE should use the PSK to start the 4-way handshake.

G.2.2 Protection of the Xw interface p. 154

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.

G.2.3 Addition, modification and release of DRBs in LWA p. 154

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.

G.2.4 Derivation of keys for the DRBs in LWA p. 154

G.2.4.1 WT Counter maintenance p. 154

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 7.2.9.3 of the present specification. When this KeNB is refreshed, the WT Counter is reset to '0' as defined above.

G.2.4.2 Security key derivation p. 155

The UE and eNB shall derive the security key S-KWT of the target WT as defined in Annex A.18 of the present specification.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. G.2.4.2-1: S-KWT computation

Figure G.2.4.2-1: S-KWT computation
(⇒ copy of original 3GPP image)

G.2.5 Security key update p. 155

G.2.5.1 Security key update triggers p. 155

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.

G.2.5.2 Security key update procedures p. 155

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.

G.2.6 Handover procedures p. 156

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.

G.2.7 Periodic local authentication procedure p. 156

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.

G.2.8 LTE and WLAN link failure p. 156

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.

G.3 Method for installing PMK |R14| p. 156

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.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. G.3-1: 3GPP vendor specific EAP-LWA method

Figure G.3-1: 3GPP vendor specific EAP-LWA method
(⇒ copy of original 3GPP image)

Step 1.

When eNB wants to start LWA for the UE, it sends WT Addition Request to the WT. This request includes the UE MAC address and the S-KWT.

Step 2.

WT acknowledges the receipt of WT Addition request.

Step 3.

WT sets LWA-ID to SHA256 (S-KWT, UE MAC addr, "LWA Identity") and associates with the received S-KWT.

Step 4.

After receiving command from eNB to start LWA and deriving S-KWT, the UE derives PMKID as specified in clause G.2.1.

Step 5.

UE includes the PMKID in the WLAN Association Request.

Step 6.

The PMKSA associated with PMKID is not found at the WLAN AP.

Step 7.

The WLAN AP responds with WLAN Association Response, omitting the PMKID that is not found at the AP.

Step 8.

WLAN AP initiates EAP authentication.

Step 9.

WLAN AP sends EAP-Identity Request message.

Step 10.

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.

Step 11.

WLAN AP uses the realm and routes the EAP-Identity response to WT as AAA message.

Step 12.

WT uses LWA-ID to locate the S-KWT. If LWA-ID is not found, the WT sends EAP-Failure message, terminating the WLAN associtation.

Step 13.

WT initiates EAP-LWA, by sending AAA EAP-Request/LWA-Challenge message, by including a 128-bit random nonce, ASNonce.

Step 14.

AP forwards the EAP-Request/LWA-Challenge message to the UE.

Step 15.

UE selects a 128-bit random nonce, STANonce, and derives AUTHRES and MSK as follows:

AUTHRES = SHA256 (S-KWT, ASNonce, STANonce, "LWA AUTHRES");

MSK = SHA256 (S-KWT, ASNonce, STANonce, "LWA MSK Key Derivation").

Step 16.

UE sends EAP-Response/LWA-Challenge message with STANonce and AUTHRES.

Step 17.

WLAN AP forwards the EAP-Response/LWA-Challenge AAA message to WT.

Step 18.

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.

Step 19.

WT sends EAP-Success with MSK as AAA message to WLAN AP.

Step 20.

WLAN AP sends EAP-Success.

Step 21.

Upon receiving EAP-Success, the UE and WLAN AP perform 4-way handshake and complete WLAN association.

Step 22.

WT sends WT Association Confirm message to the eNB, confirming successful WLAN association of the UE. Note that WT may send this message anytime after step 19).