Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.502  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   7…   7.3…   7.3A…   7.4…   7.6…   7.9…   7A…   8…   9…

 

7.3A  IKE SA establishment procedure for trusted non-3GPP access |R16|

7.3A.1  General

A trusted non-3GPP access network (TNAN) includes a trusted non-3GPP access point (TNAP) and a trusted non-3GPP gateway function (TNGF). The TNAN and a UE initiate an exchange of EAP-Request and EAP-Response messages including Identity as specified in IETF RFC 3748 [9] for link layer authentication of the UE by the TNAP. Upon completion of the EAP-Request/Response messages, an exchange of the EAP-5G messages are initiated once the UE receives an EAP-Request/5G-Start from the TNGF. The UE also at that time informs the upper layers that the access stratum connection is established.
An exchange of the NAS messages which are encapsulated in EAP-5G messages occur until the UE is authenticated by the 5GCN. Upon completion of the UE authentication and reception of the EAP-Success by the UE, the UE and the TNAP employs the TNAP key to establish access specific layer-2 security such as 4-way handshake in case IEEE 802.11 [19] is used between the TNAP and the UE.
Upon completion of successful establishment of access specific layer-2 security, the UE is configured with an IP address by TNAN by e.g. DHCP and the UE initiates an IKE_SA_INIT exchange as specified in IETF RFC 7296 [6].
The UE establishes the IP based secure connection by establishing an IKE SA and first child SA for NAS signalling traffic to the TNGF over NWt. Once the UE establishes the IKE SA and the signalling IPsec SA with the TNGF, the UE initiates establishment of a TCP connection for transport of NAS message with TNGF, secured using the signalling IPsec SA. The UE and the TNGF exchanges NAS messages over the TCP connection once it is established. Additional child SAs (user plane IPsec SAs) can be established to transfer user plane traffic (see subclause 7.5).
An example of an IKE SA and first child SA establishment procedure is shown in figure 7.3A.1-1.The figure illustrates that EAP messages are employed for the communication between the UE and the TNAP while the TNAP is transparent to the communication between the UE and the TNGF when employing EAP-5G messages. Link layer protocol is used to exchange these messages between the UE and the TNAN. The internal protocol used for the communications between the TNAP and the TNGF, is illustrated as dashed lines in this figure and is out of the scope of 3GPP.
Reproduction of 3GPP TS 24.502, Figure 7.3A.1-1: IKE SA and first child SA establishment procedure for UE registration over trusted non-3GPP access
Up

7.3A.2  EAP session over non-3GPP accessWord‑p. 42

7.3A.2.1  General

The UE and the TNAN establishes a connection depending on the access link between the UE and the TNAP. For instance if the TNAP is a trusted WLAN access point, IEEE 802.11 [19] describes the connection between the UE and the TNAP. If the access link between the UE and the TNAP is Point-to-Point Protocol (PPP) as specified in IETF RFC 1661 [32], the Link Control Protocol (LCP) as specified in IETF RFC 1570 [33] describes the connection between the UE and the TNAP.
In the trusted non-3GPP access network:
  1. the TNAP and the UE exchange EAP-request/Identity message and EAP-response/Identity message; and
  2. the TNGF and the UE exchange EAP messages of EAP-5G method,
encapsulated in the link layer protocol packets such as IEEE 802.11/802.1x packets or PPP packets until successful authentication of the UE by the AMF. The link layer protocol packets are transmitted between the UE and the TNAN.
The EAP-5G method is utilized for encapsulating the NAS message to initiate the UE registration to the AMF via the TNGF. As described in subclause 7.3.3, 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).
Up

7.3A.2.2  Identity transaction

Upon reception of EAP-Request/Identity message (as described in IETF RFC 3748 [9]), encapsulated in the link layer protocol packets from the TNAP, the UE shall:
  1. construct an EAP-Response/Identity message as described in IETF RFC 3748 [9] containing an NAI as specified in subclause 28.7.3 of TS 23.003 to request the PLMN with trusted 5G connectivity capability; and
  2. transmit the EAP-Response of identity type encapsulated in the link layer protocol packets towards the TNAP.
Up

7.3A.2.3  EAP-5G session initiation

The UE and the TNGF shall exchange EAP-5G messages. The TNGF on reception of the NAI by TNAP and passed on to TNGF, shall initiate EAP-5G session by sending an EAP-Request/5G-Start message. Upon reception of an EAP-Request/5G-Start message, the UE shall send an EAP-Response/5G-NAS message encapsulated in link layer protocol packets. In the EAP-Response/5G-NAS message, the UE shall include:
a) a NAS-PDU field containing a NAS message, for example, a REGISTRATION REQUEST message; and
b) an AN-parameters field containing access network parameters, such as UE identity, selected PLMN ID, requested NSSAI and establishment cause, see TS 23.502.
The UE identity shall be 5GS mobile identity of type 5G-GUTI, if available, otherwise it shall be the 5GS mobile identity of type SUCI. The 5GS mobile identities of type 5G-GUTI and of type SUCI are specified in TS 24.501.
The TNGF on reception of EAP-Response/5G-NAS message, forwards the NAS message to the AMF.
The TNAN, on reception of the NAS messages from the AMF, shall send an EAP-Request/5G-NAS message encapsulated in the link layer protocol packets towards the UE via the TNAP.
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 TNGF, shall be inserted in NAS-PDU field of an EAP-Response/5G-NAS (UE to TNGF direction) and EAP-Request/5G-NAS (TNGF to UE direction) message.
The UE, on reception of the EAP-Request/5G-NAS message including a NAS-PDU field containing a NAS message e.g. for security establishment, shall send a response with EAP-Response/5G-NAS message including a NAS-PDU field containing a NAS message related to the NAS security context to the TNGF.
The TNGF, on reception of the TNGF key shall construct an EAP-Request/5G-Notification message that includes an AN-parameters field containing the access network parameters, such as TNGF IPv4 contact information, TNGF IPv6 contact information, or both, see TS 23.502. The TNGF shall send the EAP-Request/5G-Notification message encapsulated in the link layer protocol packets towards the UE via the TNAP. The UE shall acknowledge by sending an EAP-Response/5G-Notification message encapsulated in the link layer protocol packets.
Up

7.3A.2.4  EAP-5G session completion initiated by the networkWord‑p. 43
Upon completion of successful authentication and on reception of the acknowledgement from the UE that it had received the access network parameters, the TNAN shall send an EAP-Success message encapsulated in the link layer protocol packets towards the UE via the TNAP.

7.3A.2.5  EAP-5G session completion initiated by the UE

For trusted non-3GPP access, the procedure for when the EAP-5G session completion initiated by the UE, is the same as that of untrusted non-3GPP access as described in subclause 7.3.3.3 with the difference that the N3IWF shall be replaced by the TNGF.

7.3A.3  IKE SA and signalling IPsec SA establishment procedure

7.3A.3.1  IKE SA and signalling IPsec SA establishment initiation

In a trusted non-3GPP access network, once the EAP- 5G authentication is successfully complete and the UE is configured with a local IP address, the UE shall use the TNGF IP address received in the EAP-Request/5G-Notification message (see subclause 7.3A.2.3) to establish a secure connection between the UE and the TNGF over NWt to exchange NAS signalling messages with the AMF. The UE shall establish the secure connection by establishing an IKE SA and signalling IPsec SA (first child SA) by initiating the IKE_SA_INIT exchange and then IKE_AUTH exchange for mutual authentication with the TNGF and NULL encryption as specified in IETF RFC 2410 [34]. The UE shall set the IDi payload of the IKE_AUTH request message in the IKE_AUTH exchange (see IETF RFC 7296 [6]) to the NAI format of 5G-GUTI or the NAI format of SUCI as specified in TS 23.003, depending on the employed UE identity in the EAP-Response/5G-NAS message at the time of EAP-5G session initiation according to subclause 7.3A.2.3.
Up

7.3A.3.2  IKE SA and signalling IPsec SA establishment accepted by the network

The UE shall establish the IKE SA and signalling IPsec SA (first child SA) according to subclause 7.3.2.2 with the difference that the N3IWF is replaced by the TNGF.
Upon completion of the IKE SA and signalling IPsec SA (first child SA) establishment between the UE and the TNGF, the UE and the TNGF shall send further NAS messages over the TCP connection within the signalling IPsec SA (first child SA).

7.3A.3.3  IKE SA and signalling IPsec SA establishment not accepted by the network

For trusted non-3GPP access, the procedure for when the IKE SA and signalling IPsec SA establishment are not accepted by the network, is the same as that of the untrusted non-3GPP access as described in subclause 7.3.2.3 with the difference that the N3IWF shall be replaced by the TNGF.

7.3A.4  Procedure for devices without NAS support

7.3A.4.1  General

A trusted non-3GPP access network (TNAN) may be implemented as a trusted WLAN access network (TWAN) which supports a WLAN access technology such as the one described in IEEE 802.11 [19]. A non 5G capable over WLAN (N5CW) device does not support 5G NAS signalling over WLAN, but may access 5GCN via a TWAN supporting a trusted WLAN interworking function (TWIF). An N5CW device may be a 5G UE with capability for 5G NAS signalling over 3GPP access although it lacks capability of NAS signalling over WLAN.
Up

7.3A.4.2  N5CW device registration over trusted WLAN access networkWord‑p. 44
A trusted WLAN access network (TWAN) includes a trusted WLAN access point (TWAP) and a trusted WLAN interworking function (TWIF) as illustrated in figure 7.3A.4.2-1.
Reproduction of 3GPP TS 24.502, Figure 7.3A.4.2-1: Trusted WLAN Access Network
Up
The EAP-AKA' authentication procedure is executed for connecting the N5CW device to a TWAN according to TS 33.501.
The TWAN and an N5CW device initiate an exchange of EAP-Request/Identity message and EAP-Response/Identity message as specified in IETF RFC 3748 [9] for link layer authentication of the UE by the TWAP. In the trusted WLAN access network, the TWAP and the N5CW device exchange EAP-Request/Identity message and EAP-Response/Identity message, encapsulated in the link layer protocol packets i.e. IEEE 802.11/802.1x packets.
Upon reception of EAP-Request/Identity message encapsulated in the IEEE 802.11/802.1x packets from the TWAP, the N5CW device shall:
  1. construct an EAP-Response/Identity message as described in IETF RFC 3748 [9] containing an NAI as specified in subclause 28.7 of TS 23.003 to Request the PLMN with trusted 5G connectivity without NAS signalling capability; and
  2. transmit the EAP-Response of identity type encapsulated in the link layer protocol packets towards the TWAP.
The TWAP conveys the information provided by the N5CW device to the TWIF which initiates the registration and the PDU session establishment to obtain an IP address, on behalf of the N5CW device to an AMF according to TS 24.501.
An exchange of the EAP request and EAP response as described in IETF RFC 3748 [9] occurs until the N5CW device is authenticated by the 5GCN with the EAP authentication described in TS 33.501. Upon completion of the N5CW device authentication and reception of the EAP-Success by the N5CW device, the N5CW device and the TWAP use the TWAP key to establish access specific layer-2 security 4-way handshake according to IEEE 802.11 [19].
Up


Up   Top   ToC