7 Security for non-3GPP access to the 5G core network

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 General

Security for non-3GPP access to the 5G Core network is achieved by a procedure using IKEv2 as defined in RFC 7296 [25] to set up one or more IPsec ESP [4] security associations. The role of IKE initiator (or client) is taken by the UE, and the role of IKE responder (or server) is taken by the N3IWF.

During this procedure, the AMF delivers a key K_N3IWF to the N3IWF. The AMF derives the key K_N3IWF from the key K_AMF. The key K_N3IWF is then used by UE and N3IWF to complete authentication within IKEv2.

Security for trusted non-3GPP access to 5G Core network is defined in clause 7A.

Trusted and untrusted Non-3GPP Access Networks are IP access networks that use access technology whose specification is out of the scope of 3GPP.

Whether a non-3GPP IP access network is trusted or untrusted is not a characteristic of the access network.

In non-roaming scenario it is the HPLMN’s operator decision if a non-3GPP IP access network is used as trusted or untrusted non-3GPP access Network. When one or more of the security feature groups provided by the non-3GPP access network are considered not sufficiently secure by the home operator, the non-3GPP access may be identified as an untrusted non-3GPP access for that operator. However, this policy decision may additionally be based on reasons not related to security feature groups.

In roaming scenario, the UDM in HPLMN makes the final decision of whether a non-3GPP IP access network is used as trusted or untrusted non-3GPP access network based on the identities of the access network and the visited network. The UDM may take the VPLMN’s policy and capability returned from the AMF or roaming agreement into account

For supporting multiple DNs, the same trust relationship shall apply to all the DNs the UE connects to from a certain non-3GPP access network, i.e. it shall not be possible to access one DN using the non-3GPP access network as trusted, while access to another PDN using the same non-3GPP access network as untrusted.

7.1a Determining trust relationship in the UE

There are various possibilities to determine the trust relationship in the UE as it is described in TS 23.501 [2]. For example, the non-3GPP access networks, which are trusted, can be pre-configured in the UE. If the USIM supports non-3GPP access networks service, the home network operator may configure in the USIM a list of trusted non-3GPP access networks. In case of pre-configured information in the UE, the list of trusted non-3GPP access networks pre-configured by the home network operator in the USIM shall take precedence over information pre-configured in the ME.

7.2 Security procedures

7.2.1 Authentication for Untrusted non-3GPP Access

This clause specifies how a UE is authenticated to 5G network via an untrusted non-3GPP access network. It uses a vendor-specific EAP method called "EAP-5G", utilizing the "Expanded" EAP type and the existing 3GPP Vendor-Id, registered with IANA under the SMI Private Enterprise Code registry. The "EAP-5G" method is used between the UE and the N3IWF and is utilized for encapsulating NAS messages. If the UE needs to be authenticated by the 3GPP home network, any of the authentication methods as described in clause 6.1.3 can be used. The method is executed between the UE and AUSF as shown below.

When possible, the UE shall be authenticated by reusing the existing UE NAS security context in AMF.

Figure 7.2.1-1: Authentication for untrusted non-3GPP access

1. The UE connects to an untrusted non-3GPP access network with procedures outside the scope of 3GPP. When the UE decides to attach to 5GC network, the UE selects an N3IWF in a 5G PLMN, as described in TS 23.501 [2] clause 6.3.6.

2. 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 [25]. After step 2 all subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.

3. 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). As per the RFC 7296 [25], in the IDi the UE shall set the ID type as ID_KEY-ID in this message and set its value equal to any random number. The UE shall not use its GUTI/SUCI/SUPI as the Id in this step. If the UE is provisioned with the N3IWF root certificate, it shall include the CERTREQ payload within the IKE_AUTH request message to request N3IWF’s certificate.

4. The N3IWF responds with an IKE_AUTH response message which includes the N3IWF identity, the AUTH payload to protect the previous message it sent to the UE (in the IKE_SA_INIT exchange) and 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 UE has sent a CERTREQ payload in step 3, the N3IWF shall also include the CERT payload including N3IWF certificate.

5. The UE shall validate the N3IWF certificate and shall confirm that the N3IWF identity matches the N3IWF selected by the UE. An absence of the certificate from the N3IWF if the UE had requested the certificate or unsuccessful identity confirmation shall result in a connection failure. The UE shall send an IKE_AUTH request which includes an EAP-Response/5G-NAS packet that contains a Registration Request message containing UE security capabilities and the SUCI. If UE is already with the 5GC over 3GPP access and there is an available security context, the UE shall integrity protect the Registration Request message and shall send the 5G-GUTI instead of SUCI. The N3IWF shall refrain from sending an EAP-Identity request. The UE may ignore an EAP Identity request or respond with the SUCI it sent in the Registration Request. If the UE has registrated to the same AMF through 3GPP access, and if this is the first time that the UE connects to the 5GC through non-3GPP access, the value of corresponding UL NAS COUNT used for integrity protection is 0; else it can use the existing non-3GPP specific UL NAS COUNT for integrity protection

NOTE: The N3IWF does not send an EAP-Identity request because the UE includes its identity in the IKE_AUTH request in message 5. This is in line with RFC 7296 [25], clause 3.16.

6. The N3IWF shall select an AMF as specified in TS 23.501 [2], clause 6.5.3. The N3IWF forwards the Registration Request received from the UE to the AMF.

7. If the AMF receives a 5G-GUTI and the Registration is integrity protected, it may use the security context to verify the integrity protection as describe in clause 6.4.6. If the UE has registrated to the same AMF through 3GPP access, and if this is the first time that the AMF receives UE’s NAS signalling through non-3GPP access, the value of corresponding UL NAS COUNT used for integrity verification is 0; else it can use the existing non-3GPP specific UL NAS COUNT for integrity verification. If integrity is verified successfully, it indicates that UE is authenticated by AMF.If integrity is verified successfully and no newer security context has been activated over the 3GPP access, then step 8 to step 11 may be skipped. If integrity is verified successfully and a newer security context has been activated over the 3GPP access then authentication may be skipped but the AMF shall activate the newer context with a NAS SMC procedure as described in step 8 and onwards. Otherwise, the AMF shall authenticate the UE.

If the AMF decides to authenticate the UE, it shall use one of the methods from clause 6.1.3. In this case, the AMF shall send a key request to the AUSF. The AUSF may initiate an authentication procedure as specified in clause 6.1.3. Between AMF and UE, the authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are carried in N2 signalling between the AMF and N3IWF, and then are encapsulated within EAP-5G/5G-NAS packets between the N3IWF and the UE.

In the final authentication message from the home network, the AUSF shall send the anchor key K_SEAF derived from K_AUSF to the SEAF. The SEAF shall derive the K_AMF from K_SEAF and send it to the AMF which is used by the AMF to derive NAS security keys. If EAP-AKA’ is used for authentication as described in clause 6.1.3.1, then the AUSF shall include the EAP-Success. The UE also derives the anchor key K_SEAF and from that key it derives the K_AMF followed by NAS security keys. The NAS COUNTs associated with NAS connection identifier "0x02" are set at the UE and AMF.

8. The AMF shall send a Security Mode Command (SMC) to the UE in order to activate NAS security associated with NAS connection identifier "0x02". This message is first sent to N3IWF (within an N2 message). If EAP-AKA’ is used for authentication, the AMF shall encapsulate the EAP-Success received from AUSF within the SMC message.

9. The N3IWF shall forward the NAS SMC to UE within an EAP-Request/5G-NAS packet.

10. The UE completes the authentication (if initiated in step 7) and creates a NAS security context or activates another one based on the received ngKSI in the NAS SMC. UE shall respond to the NAS SMC it received from the AMF based on the selected algorithms and parameters as described in clause 6.7.2. The UE shall encapsulate the NAS SMC Complete in the EAP-5G Response.

11. The N3IWF shall forward the NAS packet containing NAS SMC Complete to the AMF over the N2 interface.

12. The AMF upon reception of the NAS SMC Complete from the UE or upon success of integrity protection verification, initiates the NGAP procedure to set up the AN context. AMF shall compute the N3IWF key, K_N3IWF, using the uplink NAS COUNT associated with NAS connection identifier "0x02" as defined in Annex A.9 for the establishment of the IPsec SA between the UE and the N3IWF and shall include it in the NGAP Initial Context Setup Request sent to the N3IWF.

13. N3IWF sends an EAP-Success/EAP-5G to the UE upon reception of the NGAP Initial Context Setup Request containing the N3IWF key, KN3IWF. This completes the EAP-5G session and no further EAP-5G packets are exchanged. If the N3IWF does not receive the K_N3IWF from AMF, the N3IWF shall respond with an EAP-Failure

14. The IPsec SA is established between the UE and N3IWF by using the N3IWF key K_N3IWF that was created in the UE using the uplink NAS COUNT associated with NAS connection identifier "0x02" as defined in Annex A.9 and was received by N3IWF from the AMF in step 12.

15. Upon successful establishment of the IPsec SA between the UE and the N3IWF, the N3IWF shall send the NGAP Initial Context Setup Response message to the AMF.

16. When NGAP Initial Context Setup Response for the UE is received by the AMF, AMF shall send the NAS Registration Accept message for the UE over the N2 towards the N3IWF.

17. Upon receiving the NAS Registration Accept message from the AMF, the N3IWF shall forward it to the UE over the established IPsec SA. All further NAS messages between the UE and the N3IWF shall be sent over the established IPsec SA.