Content for  TS 24.502  Word version:  18.0.0

The UE proceeds with the establishment of IKE SA and signalling IPsec SA with the selected N3IWF by initiating an IKE_SA_INIT exchange according to IETF RFC 7296. All the IKE messages following the IKE_SA_INIT exchange are encrypted and integrity protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange as specified in IETF RFC 7296. Upon completion of the IKE_SA_INIT exchange, the UE shall initiate an IKE_AUTH exchange as specified in IETF RFC 7296 to establish an IKE SA and first child SA (signalling IPsec SA).. In the initial IKE_AUTH request message, the UE shall:

• indicate the intention to use EAP by not including the AUTH payload;
• include the IDi payload with the ID type set to ID_KEY_ID and value set to any random number; and
• include CERTREQ payload to request N3IWF's certificate if the UE is provisioned with the N3IWF root certificate,

as specified in IETF RFC 7296. Upon reception of the IKE_AUTH request message, the N3IWF shall respond with an IKE_AUTH response message including:

• an EAP-Request/5G-Start packet to inform the UE an EAP-5G session that will be used to convey the initial NAS messages (see the EAP-5G procedure described in clause 7.3.3);
• the IDr payload with the value set to N3IWF identity; and
• the CERT payload containing the N3IWF's certificate if the CERTREQ payload is included in the IKE_AUTH request message.

If IKE SA and signalling IPsec SA establishment is accepted by the network, the UE receives from the N3IWF an IKE_AUTH response message containing an EAP-Success message (as shown in Figure 7.3.2-1), which completes the EAP-5G session. No further EAP-5G packets are exchanged. The UE completes the IKE SA and signalling IPsec SA (first child SA) establishment procedure by initiating an IKE_AUTH exchange including an AUTH payload computed based on the N3IWF key as described in TS 33.501. In the IKE_AUTH request message the UE additionally shall include:

• the INTERNAL_IP4_ADDRESS attribute, the INTERNAL_IP6_ADDRESS attribute, or both, indicating the type of IP address to be used for the IP tunnels, in the CFG_REQUEST configuration payload. The INTERNAL_IP4_ADDRESS attribute shall contain no value and the length field shall be set to 0. The INTERNAL_IP6_ADDRESS attribute shall contain no value and the length field shall be set to 0; and
• the MOBIKE_SUPPORTED notify payload as specified in IETF RFC 4555 if the UE supports IETF RFC 4555.

The N3IWF shall include in the IKE_AUTH response message containing the AUTH payload:

• a single CFG_REPLY Configuration Payload including the INTERNAL_IP4_ADDRESS attribute with an IPv4 address assigned to the UE, the INTERNAL_IP6_ADDRESS attribute with an IPv6 address assigned to the UE, or both;
• the NAS_IP4_ADDRESS notify payload with an N3IWF IPv4 address assigned to transport of NAS messages, if the initial IKE_AUTH request message contained a CFG_REQUEST configuration payload with the INTERNAL_IP4_ADDRESS attribute and NAS messages are to be transmitted using IPv4 based inner IP tunnel;
• the NAS_IP6_ADDRESS notify payload with an N3IWF IPv6 address assigned to transport of NAS messages if the initial IKE_AUTH request message contained a CFG_REQUEST configuration payload with the INTERNAL_IP6_ADDRESS attribute and NAS messages are to be transmitted using IPv6 based inner IP tunnel;
• the NAS_TCP_PORT notify payload with an N3IWF TCP port number assigned to transport of NAS messages; and
• the MOBIKE_SUPPORTED notify payload as specified in RFC 4555, if the initial IKE_AUTH request message contained a MOBIKE_SUPPORTED configuration payload with the INTERNAL_IP4_ADDRESS attribute.

The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 of TS 24.302. If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute, the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute indicating support of receiving timeout period for liveness check in the CFG_REQUEST configuration payload within the IKE_AUTH request message. The N3IWF may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 of TS 24.302 indicating the timeout period for liveness check in the CFG_REPLY configuration payload of the IKE_AUTH response message containing the AUTH payload. Presence of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as input for decision on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH response message containing the AUTH payload. If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 of TS 24.302 indicating the timeout period for the liveness check is included in the CFG_REPLY configuration payload within the IKE_AUTH response message containing the AUTH payload or the UE has a pre-configured or configured timeout period, the UE shall perform the liveness check procedure as described in clause 7.8. This completes the establishment of the IKE SA and signalling IPsec SA (first child SA) between the UE and the N3IWF. Upon completion of the IKE SA and signalling IPsec SA (first child SA) establishment between the UE and the N3IWF, the UE and the N3IWF shall send further NAS messages over the TCP connection within the signalling IPsec SA (first child SA) (see example in Figure 7.3.2.2-1). An example of an IKE SA and first child SA establishment procedure is shown in Figure 7.3.2.2-1.

If IKE SA and signalling IPsec SA establishment is not accepted by the network, the UE receives from the N3IWF an IKE_AUTH response message including a Notify payload with an error type. Upon receiving the IKE_AUTH response message with a Notify payload with an error type other than a CONGESTION Notify payload, the UE shall pass the error indication to the upper layer along with the encapsulated NAS messages, if any, within EAP/5G-NAS packet. After the N3IWF receives from the UE an IKE_AUTH request message, the N3IWF shall construct an IKE_AUTH response message including a CONGESTION Notify payload as defined in clause 9.2.4.2 and a N3GPP_BACKOFF_TIMER Notify payload as defined in clause 9.3.1.7. if the N3IWF decides to not accept the IKE SA and signalling IPsec SA establishment based on the OVERLOAD START message received from the AMF(s) as specified in TS 29.413. The N3IWF shall send the IKE_AUTH response message to the UE.Upon reception of the IKE_AUTH response message including:

1. a CONGESTION Notify payload as defined in clause 9.2.4.2; and
2. a N3GPP_BACKOFF_TIMER Notify payload as defined in clause 9.3.1.7; and

after the UE authenticates the network or the N3IWF as specified in TS 33.501, the UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA as specified in RFC 7296. In addition, the UE shall inform the upper layers that the access stratum connection has been released, and:

1. if the back-off timer value in N3GPP_BACKOFF_TIMER Notify payload indicates neither zero nor deactivated, the UE shall start the Tw3 timer with the value provided and the UE shall not retry the IKE SA and signalling IPsec SA establishment procedure to the same N3IWF until:
   • timer Tw3 expires;
   • the UE is switched off;
   • the UICC containing the USIM is removed;
   • an access attempt occurs due to emergency services; or
   • the UE needs to request one or more S-NSSAIs that were not included in the requested NSSAI provided to the N3IWF previously;
2. if the back-off timer value in N3GPP_BACKOFF_TIMER Notify payload indicates that this timer is deactivated, the UE shall not retry the IKE SA and signalling IPsec SA establishment procedure to the same N3IWF until:
   • the UE is switched off;
   • the UICC containing the USIM is removed;
   • an access attempt occurs due to emergency services; or
   • the UE needs to request one or more S-NSSAIs that were not included in the requested NSSAI provided to the N3IWF previously; and
3. if the back-off timer value in N3GPP_BACKOFF_TIMER Notify payload indicates zero, the UE may retry the IKE SA and signalling IPsec SA establishment procedure to an N3IWF from the same PLMN.

Upon receiving the IKE_AUTH response message with a Notify payload with an error type, if the EAP-5G session establishment has already been started, the UE shall perform a local termination of the EAP-5G session.

A vendor-specific EAP method (EAP-5G) is used to encapsulate NAS messages between the UE and the N3IWF. The EAP-5G packets utilize the "Expanded" EAP type and the existing 3GPP Vendor-Id registered with IANA under the SMI Private Enterprise Code registry (i.e. 10415). The EAP-5G method is utilized only for encapsulating the NAS messages. The EAP-5G method is not utilized to authenticate the UE in untrusted non-3GPP network.

The UE and the N3IWF shall exchange EAP-5G messages within IKE_AUTH request and IKE_AUTH response messages. The N3IWF on reception of an IKE_AUTH request with no AUTH payload shall start an EAP-5G session by sending an EAP-Request/5G-Start message. The UE acknowledges start of the EAP-5G session by sending an EAP-Response/5G-NAS message which shall include:

1. a NAS-PDU field containing a NAS message, for example, a REGISTRATION REQUEST message; and
2. an AN-parameters field containing access network parameters, such as GUAMI, selected PLMN ID, requested NSSAI, establishment cause, selected NID if the UE is accessing SNPN services via a PLMN or the UE is accessing SNPN services via untrusted non-3GPP access network, and onboarding indication if the UE is accessing SNPN for onboarding services in SNPN via untrusted non-3GPP access network (see TS 23.502).

The N3IWF, on reception of NAS messages from the UE within an EAP-Response/5G-NAS message, shall forward the NAS message to the AMF. The N3IWF, on reception of NAS messages from the AMF, shall include the NAS message within an EAP-Request/5G-NAS message. The N3IWF shall transmit the EAP-Request/5G-NAS message to the UE. The EAP-Request/5G-NAS message shall include a NAS-PDU field that contains a NAS message. Further NAS messages between the UE and the AMF, via the N3IWF, shall be inserted in NAS-PDU field of an EAP-Response/5G-NAS (UE to N3IWF direction) and EAP-Request/5G-NAS (N3IWF to UE direction) message.

Upon completion of successful authentication and on reception of the N3IWF key from the AMF, the N3IWF shall complete the EAP-5G session by sending an EAP-Success message. On reception of the EAP-Success message from the N3IWF, the UE proceeds to establish an IKE SA and signalling IPsec SA as described in clause 7.3.2. An example of an EAP-5G session after successful authentication is shown in Figure 7.3.3.2-1.

Upon receiving indication from the upper layer that no 5G-NAS messages need to be transmitted between the UE and N3IWF, the UE shall terminate the EAP-5G session by sending an EAP-Response/5G-Stop message to the N3IWF. On reception of EAP-Response/5G-Stop message, the N3IWF shall complete the EAP-5G session by sending an EAP-Failure message to the UE. On reception of the EAP-Failure message from the N3IWF, the UE shall delete any context related to IKE SA without requiring an explicit INFORMATIONAL exchange carrying a Delete payload as specified in RFC 7296. Figure 7.3.3.3-1 shows an example the EAP-5G session completion after registration reject.