The UE connects to an untrusted non-3GPP access network with any appropriate authentication procedure and it is assigned an IP address. For example, a non-3GPP authentication method can be used, e.g. no authentication (in the case of a free WLAN), EAP with pre-shared key, username/password, etc. When the UE decides to attach to 5GC network, the UE selects an N3IWF in a 5G PLMN, as described in TS 23.501, clause 6.3.6
The UE proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF by initiating an IKE initial exchange according to RFC 7296 . After step 2, all subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.
The UE shall initiate an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, which indicates that the IKE_AUTH exchange shall use EAP signalling (in this case EAP-5G signalling). If the UE supports MOBIKE, it shall include a Notify payload in the IKE_AUTH request, as specified in RFC 4555 , indicating that MOBIKE is supported. In addition, as specified in TS 33.501
, if the UE is provisioned with the N3IWF root certificate, it shall include the CERTREQ payload within the IKE_AUTH request message to request the N3IWF's certificate.
The N3IWF responds with an IKE_AUTH response message, which includes an EAP-Request/5G-Start packet. The EAP-Request/5G-Start packet informs the UE to initiate an EAP-5G session, i.e. to start sending NAS messages encapsulated within EAP-5G packets. If the N3IWF has received a CERTREQ payload from the UE, the N3IWF shall include the CERT payload in the IKE_AUTH response message conaining the N3IWF's certificate. How the UE uses the N3IWF's certificate is specified in TS 33.501
The UE shall send an IKE_AUTH request, which includes an EAP-Response/5G-NAS packet that contains the Access Network parameters (AN parameters) and a Registration Request message. The AN parameters contain information that is used by the N3IWF for selecting an AMF in the 5G core network. This information includes e.g. the GUAMI, the Selected PLMN ID (or PLMN ID and NID, see TS 23.501, clause 5.30
), the Requested NSSAI and the Establishment cause. The Establishment cause provides the reason for requesting a signalling connection with 5GC. Whether and how the UE includes the Requested NSSAI as part of the AN parameters is dependent on the value of the Access Stratum Connection Establishment NSSAI Inclusion Mode parameter, as specified in clause 5.15.9 of TS 23.501
The N3IWF does not send an EAP-Identity request because the UE includes its identity in the first IKE_AUTH. This is in line with RFC7296, clause 3.16.
The N3IWF shall select an AMF based on the received AN parameters and local policy, as specified in TS 23.501, clause 6.3.5
. The N3IWF shall then forward the Registration Request received from the UE to the selected AMF within an N2 message. This message contains N2 parameters that include the Selected PLMN ID and the Establishment cause.
The selected AMF may decide to request the SUCI by sending a NAS Identity Request message to UE. This NAS message and all subsequent NAS messages are sent to UE encapsulated within EAP/5G-NAS packets.
The AMF may decide to authenticate the UE by invoking an AUSF. In this case, the AMF shall select an AUSF as specified in TS 23.501, clause 6.3.4
based on SUPI or SUCI.
The AUSF executes the authentication of the UE as specified in TS 33.501
. The AUSF selects a UDM as described in TS 23.501, clause 6.3.8
and gets the authentication data from UDM. The authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are encapsulated within EAP/5G-NAS packets. After the successful authentication:
In step 8h, the AUSF shall send the anchor key (SEAF key) to AMF which is used by AMF to derive NAS security keys and a security key for N3IWF (N3IWF key). The UE also derives the anchor key (SEAF key) and from that key it derives the NAS security keys and the security key for N3IWF (N3IWF key). The N3IWF key is used by the UE and N3IWF for establishing the IPsec Security Association (in step 11).
In step 8h, the AUSF shall also include the SUPI, if in step 8a the AMF provided to AUSF a SUCI.
EAP-AKA' or 5G-AKA are allowed for the authentication of UE via non-3GPP access, as specified in TS 33.501
. Figure 126.96.36.199-1 only shows authentication flow using EAP-AKA'. Authentication methods other than EAP-AKA' or 5G-AKA are also allowed for UE accessing SNPN services via a PLMN, as specified in TS 33.501
, Annex I.
The AMF shall send a NAS Security Mode Command to UE in order to activate NAS security. If an EAP-AKA' authentication was successfully executed in step 8, the AMF shall encapsulate the EAP-Success received from AUSF within the NAS Security Mode Command message.
The N3IWF shall forward the NAS Security Mode Command message to UE within an EAP/5G-NAS packet.
The UE completes the EAP-AKA' authentication (if initiated in step 8), creates a NAS security context and an N3IWF key and sends the NAS Security Mode Complete message within an EAP/5G-NAS packet.
The N3IWF relays the NAS Security Mode Complete message to the AMF.
Upon receiving NAS Security Mode Complete, the AMF shall send an NGAP Initial Context Setup Request message that includes the N3IWF key.
This triggers the N3IWF to send an EAP-Success to UE, which completes the EAP-5G session. No further EAP-5G packets are exchanged.
The IPsec SA is established between the UE and N3IWF by using the common N3IWF key that was created in the UE in step 9c and received by the N3IWF in step 10a. This IPsec SA is referred to as the "signalling IPsec SA". After the establishment of the signalling IPsec SA, the N3IWF notifies the AMF that the UE context (including AN security) was created by sending a NGAP Initial Context Setup Response. The signalling IPsec SA shall be configured to operate in tunnel mode and the N3IWF shall assign to UE an "inner" IP address. If the N3IWF has received an indication that the UE supports MOBIKE (see step 3), then the N3IWF shall include a Notify payload in the IKE_AUTH response message sent in step 11a, indicating that MOBIKE shall be supported, as specified in RFC 4555 .
All subsequent NAS messages exchanged between the UE and N3IWF shall be sent via the signalling IPsec SA and shall be carried over TCP/IP. The UE shall send NAS messages within TCP/IP packets with source address the "inner" IP address of the UE and destination address the NAS_IP_ADDRESS that is received in step 11a. The N3IWF shall send NAS messages within TCP/IP packets with source address the NAS_IP_ADDRESS and destination address the "inner" IP address of the UE. The TCP connection used for reliable NAS transport between the UE and N3IWF shall be initiated by the UE right after the signalling IPsec SA is established in step 11a. The UE shall send the TCP connection request to the NAS_IP_ADDRESS and to the TCP port number specified in TS 24.502
The AMF sends the NAS Registration Accept message to the N3IWF. The N2 Message includes the Allowed NSSAI for the access type for the UE.
The N3IWF forwards the NAS Registration Accept to UE via the established signalling IPsec SA. If the NAS Registration Request message is received by the N3IWF before the IPsec SA is established, the N3IWF shall store it and forward it to the UE only after the establishment of the signalling IPsec SA.
The AMF provides the Access Type set to "Non-3GPP access" to the UDM when it registers with the UDM.
The Access Type is set to "Non-3GPP access" even when the UE accesses SNPN services via PLMN over 3GPP access.