S3-160254
3GPP TSG-SA3 Meeting #82
Dubrovnik, Croatia, 1st Feb 2016 - 5th Feb 2016
CR-Form-v11.1
CHANGE REQUEST
33.401 CR
0565
rev
-
Current version:
13.1.0
For HELP on using this form: comprehensive instructions can be found at
http://www.3gpp.org/Change-Requests.
Proposed change affects:
UICC apps
ME X Radio Access Network X
Title:
CR to 33.401 to add LWA solution
Source to WG:
Source to TSG:
BlackBerry UK Ltd, Broadcom Corp.
Work item code:
LTE_WLAN_radio-Core /Rel-13
B
Category:
Core Network
Date: 2016-01-22
Release: Rel-13
Use one of the following categories:
F (correction)
A (mirror corresponding to a change in an earlier
release)
B (addition of feature),
C (functional modification of feature)
D (editorial modification)
Detailed explanations of the above categories can
be found in 3GPP TR 21.900.
Use one of the following releases:
Rel-8
(Release 8)
Rel-9
(Release 9)
Rel-10 (Release 10)
Rel-11 (Release 11)
Rel-12 (Release 12)
Rel-13 (Release 13)
Rel-14 (Release 14)
Reason for change:
A security solution is needed for the connection between the UE and WLAN
supporting LTE WLAN Aggregation (LWA).
Summary of change:
Introduces a mechanism for a UE to gain access over WLAN and is
authenticated and authorised to convey user plane packets.
Features include;




Use of WPA2-Enterprise as defined in IEEE 802.1X
Modification to parameter inputs to EAP-AKA’ KDF
Definition of a new string input WT Counter
Definition of new EAP method EAP-LWA
Consequences if not
approved:
Unsecure LWA connection between the UE and WLAN AP.
Clauses affected:
3.1, 3.2, 4, 5.1.3.1, 5.1.4.1, 6.2, 6.5, 8.0, X, A.X
Other specs
affected:
(show related CRs)
Y N
X Other core specifications
X Test specifications
X O&M Specifications
TS/TR ... CR ...
TS/TR ... CR ...
TS/TR ... CR ...
Other comments:
3GPP
Page |1
S3-160051
*****************************************Start of change*****************************************
Annex X (Normative)
LTE - WLAN aggregation via Xw interface
X.1
Introduction
This clause describes the security functions necessary to support a UE that is simultaneously connected to an eNB and a
WT for LTE-WLAN Aggregation as described in TS 36.300 [30].
The LWA architecture is shown in Figure X.1-1.
S1-MME
S1-U
MeNB
RRC
Xw
PDCP
RRC
WT
PDCP
RLC
RLC
MAC
MAC
PHY
PHY
NAS
UE
Figure X.1-1 LWA architecture
For LTE-WLAN aggregation the end-points of user plane encryption remain at the respective PDCP layers of the
MeNB and the UE. For this reason user plane traffic does not require additional encryption between UE and WT,
however, 802.11 management (control) frames do benefit from encryption on the WLAN air interface.
A UE needs to be authenticated and authorised to access the WLAN in order to open the WLAN controlled port and to
enable user plane packets to flow through the WLAN network.
X.2 LTE-WLAN aggregation security
X.2.1 Authentication and authorisation to utilise the WLAN
The UE obtains authorisation to utilise WLAN resources by successfully completing an 802.1X authentication
procedure over the WLAN using a variant of EAP-AKA’ in which the MeNB takes on the role of EAP server. In
addition input key and string parameters to EAP-AKA’ are modified, this leads to the definition of a new EAP method
defined in X.2.4 called EAP-LWA.
X.2.2 Authentication handling by MeNB
In Figure X.2-1 the MeNB plays the role of EAP server as defined for EAP-AKA’.
3GPP
Page |2
S3-160051
MME
MeNB performs EAP
Authentication Server role
S1
EAP
messaging
WLAN-GW
Figure X.2-1 System architecture based on use of 802.1X authentication
Characteristics of the solution are;

EAP messaging between UE and WLAN (authenticator) is the same as for EAP-AKA’

EAP messaging between MeNB <-> WLAN is the same as that between WLAN and 3GPP AAA server for
the case of conventional EAP-AKA’.

The MeNB is capable of autonomously completing the EAP authentication procedure with the UE (without
accessing a 3GPP AAA server/HSS).
Figure Figure X.2-2 illustrates a message sequence chart for the case where the MeNB takes on the role of EAP
authentication server.
3GPP
Page |3
S3-160051
UE
AP
MeNB1
WLC
1. Addition of WLAN
triggered
2. RRC (Initiate WLAN-LTE aggregation mode)
3. Authentication Frame (Request)
Open System authentication
4. Authentication Frame (Response)
5. Association
Configuration change only:
NAI→ eNB IP address
6. EAPOL Start
Message
sequence
chart as per
legacy carrier
grade WLAN
7. Request/Identity
8-1. Response/Identity
8-2. Proprietary msg relay
8-3. Access Request
9-1. EAP Request/Method
9-2. Proprietary msg relay
9-3. Access challenge
10-1. EAP Response/Method
10-2. Proprietary msg relay
11-1. EAP Success
12. PMK is
known
11-2. Proprietary msg relay
10-3. Access Request
11-3. Access Accept
12. PMK is
known
13. EAPOL-Key (Anonce)
14. EAPOL-Key (Snonce, MIC)
4-way handshake
15. EAPOL-Key (Anonce,
MIC)
16. EAPOL-Key (Ack of msg 3)
17. PTK installed
17. PTK installed
18. AP opens the
controlled port
19. DHCP configuration (if necessary) and data transfer
1
MeNB
MeNB1== MeNB
MeNB modified
modified to
to support
support LWA
LWA
Figure X.2-2 Message exchange for WPA2-Enterprise authentication with MeNB as EAP authentication server.
X.2.3 Routing of authentication and authorisation traffic from WLAN to MeNB
In a conventional carrier grade WLAN, the WLAN determines to which AAA server it should forward EAP signalling
based on the NAI (Network Access Identifier). Specifically the WLAN performs a table look up or DNS query using
the realm information which comprises part of the NAI. The UE sends the WLAN an NAI containing a realm part of
that includes an identifier of the MeNB, this is provided in addition to the identifier of the operator’s network realm that
is already provided as part of the legacy NAI definition. With this modification the WLAN has sufficient information
to route the EAP signalling to the correct eNB.
A new Root NAI definition to support the architecture given in Figure X.2-1 is shown here;
3GPP
Page |4
S3-160051
"2<IMSI>@wlan.enbid<ENBID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org”
Where the modifications to the Root NAI defined in [23.003v13.4.0 clause 19.3.2] are shown in yellow highlight:

The ‘2’ indicates to the WLAN that this NAI corresponds to the new authentication method, whereby EAP
messaging is routed to the MeNB, and not directly a 3GPP AAA Server.

The enbid<ENBID> is an identifier of the eNB to which the EAP messaging should be forwarded. The UE
can be notified of this ENBID via the RRC signalling message that is used to instruct the UE to add the WLAN
access.

Alternatively the C-RNTI could be used instead of the IMSI, if passing the IMSI over the UE – WLAN
interface is viewed as a security issue.
In a similar way the modification to the Decorated NAI, for use when the UE is roaming in a VPLMN is as follows:
"wlan.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org
!2<IMSI>@wlan.enbid<ENBID>.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org",
X.2.4 EAP-LWA
The 3GPP AAA server running EAP-AKA’ uses CK’ and IK’ as defined in RFC5448 and 3GPP 33.402. Since the
MeNB will not have access to the HSS in this solution it uses the KeNB and WT Counter (defined below in section
X.2.4.1) to generate a new key S-KWT to be used as the input key to the KDF for authenticating the UE to the WLAN.
Given this solution modifies the EAP-AKA’ input key and string to the KDF the creation of a new method name EAPLWA is viewed as necessary to distinguish this solution from EAP-AKA’. Apart from the modified input parameters,
there is no other change to the execution of EAP-AKA’.
Stepwise description is;

In the UE/MeNB, CK’|IK’ are replaced with KeNB.

In the UE/MeNB KeNB is the input key and WT Counter the input string to KDF to generate S-KWT

The UE is passed WT Counter via the RRC procedures when it is triggered to move to the WLAN. The UE
knows KeNB from other RRC procedures.

The UE/MeNB use S-KWT as the key input along with the string “EAP-LWA” | Identity, exactly as used in
EAP-AKA’ to generate the PMK.
Pictorially this solution can be shown as;
KeNB
WT
Counter
K
D
F
S-KWT
EAP-LWA
|Identity
K
D
F
PMK
Figure X.2-3. UE/MeNB key derivation using EAP-LWA.
3GPP
Page |5
S3-160051
X.2.4.1 Generation of S-KWT
The UE and MeNB shall derive the key S-KWT as follows;
MeNB/UE
KeNB
WT Counter
KDF
256
S-KWT
Derivation of S-KWT for LWA
This input string is used when the MeNB and UE derive S-KWT from KeNB during LTE WiFi Aggregation. The
following input parameters shall be used:
-
FC = 0x1D
-
P0 = Value of the WT Counter as a non-negative integer
-
L0 = length of the WT Counter value (i.e. 0x00 0x02)
The input key shall be KeNB of the MeNB.
X.2.4.2 WT Counter maintenance
The MeNB 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 MeNB shall treat the WT Counter as a fresh input
to S-KWT derivation. That is, the UE assumes that the MeNB provides a fresh WT Counter for each S-KWT derivation
and does not need to verify the freshness of the WT Counter.
NOTE: The value of the WT Counter is integrity and replay protected when sent over the air in the RRC signaling,
and so force re-use of the same WT Counter and computation of the same S-KWT is prevented.
The MeNB maintains the value of the counter WT Counter for a duration of the current AS security context between
UE and MeNB. The UE does not need to maintain the WT Counter after it has computed the S-KWT since the MeNB
provides the UE with the current WT Counter value when the UE needs to compute a new S-KWT.
The MeNB 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 MeNB 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 MeNB 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 MeNB 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.
X.2.5
Protection of the Xw reference point
The control plane signalling between MeNB and WT over the Xw reference point shall be confidentiality and integrity
protected using security protection as described in clause 5.3.4a and clause 11of the present specification. Any user
plane data between MeNB and WT over Xw reference point shall be allowed only for authenticated UEs.
X.2.6
Security key update
Key renewal is supported using the fast re-authentication procedure as detailed in Section 6.3 of this specification.
3GPP
Page |6
S3-160051
X.2.7
Handover procedures
During S1 and X2 inter eNB handover, the connection between the UE and the WT is released and keying information
in the WLAN and the UE is deleted.
Existing 802.11 methods are employed for managing security aspects associated with inter-AP handover.
*****************************************End of change*****************************************
3GPP
Page |7
S3-160051