Tech-invite3GPPspaceIETF RFCsSIP

Content for  TS 33.501  Word version:  17.4.1

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.1.3…   6.1.4   6.2…   6.2.2…   6.3…   6.5…   6.7…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   13…   13.2.2…   13.2.4   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   I…   J…   K…   O…   P…   S…   U…   X…   Y…


S (Normative)  Support for Non-seamless WLAN offload (NSWO) in 5GS |R17|Word‑p. 259

S.1  IntroductionWord‑p. 259

Non-seamless WLAN offload (NSWO) is an optional capability of a UE supporting WLAN radio access. A UE supporting non-seamless WLAN offload may, while connected to WLAN access, route specific IP flows via the WLAN access without traversing the 3GPP core network.
The present Annex specifies the support for authentication for NSWO in 5GS (5G NSWO).

S.2  GeneralWord‑p. 259

5G NSWO shall use EAP-AKA', as specified in RFC 5448, for authentication. The EAP-AKA' implementations shall comply with the EAP-AKA' profile specified in Annex F of the present document.
A new network function, called NSWO NF, is introduced to support authentication for NSWO in 5GS. The NSWO NF interfaces to the WLAN access network using SWa interface and interfaces to the AUSF using Service Based Interface (SBI).

S.3  Authentication procedureWord‑p. 259

An HPLMN that supports 5G NWSO and wants the UE to use 5G NSWO shall configure the UE to use 5G NSWO. This configuration shall be either on the USIM or ME, with configuration on the USIM taking precedence over the ME.
A UE that supports 5G NSWO and is configured to use 5G NSWO shall always use 5G NSWO (i.e., it shall not use EPS NSWO defined in TS 23.402).
Reproduction of 3GPP TS 33.501, Fig. S.3-1: Non-seamless WLAN offload (NSWO) in 5GS, Authentication procedure
Step 1.
When the UE decides to perform NSWO, the UE establishes a WLAN connection between the UE and the WLAN Access Network (AN), using procedures specified in IEEE 802.11[80].
Step 2.
The WLAN AN sends an EAP Identity/Request to the UE.
Step 3.
The UE sends an EAP Response/Identity message. The UE shall use the SUCI in NAI format (i.e., username@realm format) as its identity irrespective of whether SUPI Type configured on the USIM is IMSI or NAI. If the SUPI Type configured on the USIM is IMSI, the UE shall construct the SUCI in NAI format with username containing the encrypted MSIN and the realm part containing the MCC/MNC.
Step 4.
The EAP Response/Identity message shall be routed over the SWa interface towards the NSWO NF based on the realm part of the SUCI.
Step 5.
The NSWO NF shall send the message Nausf_UEAuthentication_Authenticate Request with SUCI, Serving Network name and NSWO indicator towards the AUSF. NSWO_indicator is used to indicate to the AUSF that the authentication request is for Non-seamless WLAN offload purposes. The NSWO NF shall set the Serving Network name to "5G:NSWO".
Step 6.
The AUSF (acting as the EAP authentication server) shall send a Nudm_UEAuthentication_Get Request to the UDM including SUCI and the NSWO indicator.
Step 7.
Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF. SIDF shall de-conceal SUCI to gain SUPI before UDM can process the request. Based on the NSWO indicator, the UDM/ARPF shall select the EAP-AKA' authentication method. UDM shall generate and include the EAP-AKA' authentication vector (RAND, AUTN, XRES, CK' and IK') and may include SUPI to AUSF in a Nudm_UEAuthentication_Get Response message.
Step 8.
The AUSF shall store XRES for future verification. The AUSF shall send the EAP-Request/AKA'-Challenge message to the NSWO NF in a Nausf_UEAuthentication_Authenticate Response message.
Step 9.
The NSWO NF shall send the EAP-Request/AKA'-Challenge message to the WLAN AN over the SWa interface.
Step 10.
The WLAN AN forwards the EAP-Request/AKA'-Challenge message to the UE.
Step 11.
At receipt of the RAND and AUTN in the EAP-Request/AKA'-Challenge message, the ME shall construct the SN name by setting it to "5G:NSWO", and the USIM in the UE shall verify the freshness of the AV' by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. The ME shall derive CK' and IK' according to Annex A.3. If the verification of the AUTN fails on the USIM, then the USIM and ME shall proceed as described in sub-clause The UE may derive MSK from CK' and IK' as per Annex F and as described in RFC 5448. When the UE is performing NSWO authentication, the KAUSF shall not be generated by the UE.
Step 12.
The UE shall send the EAP-Response/AKA'-Challenge message to the WLAN AN.
Step 13.
The WLAN AN forwards the EAP-Response/AKA'-Challenge message over the SWa interface to the NSWO NF.
Step 14.
The NSWO NF shall send the Nausf_UEAuthentication_Authenticate Request with EAP-Response/AKA'-Challenge message to AUSF.
Step 15.
The AUSF shall verify if the received response RES matches the stored and expected response XRES. If the AUSF has successfully verified, it continues as follows to step 16, otherwise it returns an error to the NSWO NF. The AUSF shall derive the required MSK key from CK' and IK' as per Annex F and as described in RFC 5448, based on the NSWO indicator received in step 5. The AUSF shall not generate the KAUSF.
Step 16.
The AUSF shall send Nausf_UEAuthentication_Authenticate Response message with EAP-Success and MSK key to NSWO NF. The AUSF may optionally provide the SUPI to NSWO NF.The AUSF/UDM shall not perform the linking increased home control to subsequent procedures (as stated in present document clause 6.1.4).
Step 17.
The NSWO NF shall send the EAP-success and MSK to WLAN AN over the SWa interface. The EAP-Success message is forwarded from WLAN AN to the UE.
Step 18.
Upon receiving the EAP-Success message, the UE derives the MSK as specified in step 11, if it has not derived the MSK earlier. The UE uses MSK to perform 4-way handshake to establish a secure connection with the WLAN AN.

T (Normative)  Security for edge computing |R17|Word‑p. 262

T.1  GeneralWord‑p. 262

The 5G Edge computing service is described in TS 23.548. It defines the enhancements of 5G System to support Edge Computing.

T.2  Security of network exposure to edge application serverWord‑p. 262

It is defined in the TS 23.548, clause 6.4 that the network could expose network information to the local AF with two scenarios, i.e.
  • Case 1: L-PSA UPF may expose the network information to local AF via Local NEF, or
  • Case 2: L-PSA UPF may expose the network information to local AF directly. However, How to deliver the information on N6 is out of scope.
For the Case 1, the Security aspects of Network Exposure Function specified in clause 12 shall be used for the network information exposure.

Up   Top   ToC