Section: 7A.2.1 Authentication for trusted non-3GPP access
Content: This clause specifies how a UE is authenticated to 5G network via a trusted non-3GPP access network. This is based on the specified procedure in TS 23.502[ Procedures for the 5G System (5GS) ]  [8] clause 4.12a.2.2 "Registration procedure for trusted non-3GPP access". The authentication procedure is similar to the authentication procedure for Untrusted non-3GPP access defined in clause 7.2.1 with few differences, which are mentioned below: Figure 7A.2.1-1: Registration \ Authentication and PDU Session establishment for trusted non-3GPP access 0. The UE selects a PLMN and a TNAN for connecting to this PLMN by using the Trusted Non-3GPP Access Network selection procedure specified in TS 23.501[ System architecture for the 5G System (5GS) ]  [2] clause 6.3.12. During this procedure, the UE discovers the PLMNs with which the TNAN supports trusted connectivity (e.g. "5G connectivity"). 1. A layer-2 connection is established between the UE and the TNAP. In case of IEEE 802.11 [80], this step corresponds to an 802.11 [80] Association. In case of PPP, this step corresponds to a PPP LCP negotiation. In other types of non-3GPP access (e.g. Ethernet), this step may not be required. 2-3. An EAP authentication procedure is initiated. EAP messages shall be encapsulated into layer-2 packets, e.g. into IEEE 802.3/802.1x packets, into IEEE 802.11/802.1x packets, into PPP packets, etc. The UE provides a NAI that triggers the TNAP to send a AAA request to a TNGF. Between the TNAP and TNGF the EAP packets are encapsulated into AAA messages. 4-10. An EAP-5G procedure is executed as specified in clause 7.2.1with the following modifications: - The EAP-5G packets shall not be encapsulated into IKEv2 packets. The UE shall also include a UE Id in the AN parameter, e.g. a 5G-GUTI if available from a prior registration to the same PLMN. - A KTNGF as specified in clause Annex A.9 (equivalent to KN3IWF) is created in the UE and in the AMF after the successful authentication. The KTNGF is transferred from the AMF to TNGF in step 10a (within the N2 Initial Context Setup Request). - The TNAP is a trusted entity. The TNGF shall generate the KTNAP as specified in Annex A.22 and transfers it from TNGF to TNAP in step 10b (within a AAA message). - After receiving the TNGF key from AMF in step 10a, the TNGF shall send to UE an EAP-Request/5G-Notification packet containing the "TNGF Contact Info", which includes the IP address of TNGF. After receiving an EAP-Response/5G-Notification packet from the UE, the TNGF shall send message 10d containing the EAP-Success packet. 11. The common TNAP key is used by the UE and TNAP to derive security keys according to the applied non-3GPP technology and to establish a security association to protect all subsequent traffic. In case of IEEE 802.11 [80], the KTNAP is the Pairwise Master Key (PMK) and a 4-way handshake is executed (see IEEE 802.11 [80]) which establishes a security context between the WLAN AP and the UE that is used to protect unicast and multicast traffic over the air. All messages between UE and TNAP are encrypted and integrity protected from this step onwards. NOTE 1: whether step 11 is performed out of the scope of this document. The current procedure assumes the encryption protection over Layer-2 between UE and TNAP is to be enabled. 12. The UE receives IP configuration from the TNAN, e.g. with DHCP. 13. The UE shall initiate an IKE_INIT exchange with the TNGF. The UE has received the IP address of TNGF during the EAP-5G signalling in step 9b, subsequently, the UE shall initiate an IKE_AUTH exchange and shall include the same UE Id (i.e. SUCI or 5G-GUTI) as in the UE Id provided in step 5. The common KTIPSe is used for mutual authentication. The key KTIPSec is derived as specified in Annex A.22.NULL encryption is negotiated as specified in RFC 2410 [81]. After step 13c, an IPsec SA is established between the UE and TNGF (i.e. a NWt connection) and it is used to transfer all subsequent NAS messages. This IPsec SA does not apply encryption but only apply integrity protection. 14. After the NWtp connection is successfully established, the TNGF responds to AMF with an N2 Initial Context Setup Response message. 14a. The AMF may determine whether the TNGF is appropriate for the slice selected as defined in clause 4.12.2.2 of TS 23.502[ Procedures for the 5G System (5GS) ] [8]. If it is compatible with the selected TNGF, then proceed with steps 15 to step 19. Otherwise, the AMF shall proceed with step 20 to step 22, and step 15 to step 19 are skipped. Case a): 15. Finally, the NAS Registration Accept message is sent by the AMF and is forwarded to UE via the established NWt connection. 16-18. The UE initiates a PDU session establishment. This is carried out exactly as specified in TS 23.502[ Procedures for the 5G System (5GS) ]  [8] clause 4.12a.5. The TNGF may establish one or more IPSec child SA’s per PDU session. 19. User plane data for the established PDU session is transported between the UE and TNGF inside the established IPSec child SA Case b:) 20. The AMF may trigger the UE policy update procedure and update the UE policy as defined in step 17 and step 18 in clause 4.12a.2.2 of TS 23.502[ Procedures for the 5G System (5GS) ] [8]. 21. The AMF shall send a Registration Reject message via TNGF to the UE as defined in step 19 to step21 in clause 4.12a.2.2 of TS 23.502[ Procedures for the 5G System (5GS) ] [8]. The Registration Reject message is ciphered and integrity protected, and a new 5G-GUTI is provided to the UE. 22. The UE shall decipher and verify the integrity of the Registration Reject message. If verification is successful, then the UE proceeds with step 21 in clause 4.12.2.2 of TS 23.502[ Procedures for the 5G System (5GS) ] [8], and sends an integrity protected Registration request message to the AMF via a new selected TNGF..