Secure connection in a wireless communication network

Abstract

Various aspects of the present disclosure relate to a user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: establish, using a first key, a first secure connection with an access and mobility management function (AMF) via a first non-3GPP access network, wherein the first key is derived using an AMF key k AMF send, to the AMF over the first secure connection, a first message, wherein the first message indicates that the UE supports derivation of a second key for establishing a second secure connection with the AMF via a second non-3GPP access network, wherein the second key is derived using k AMF receive, from the AMF, a second message, wherein the second message indicates a request for the UE to derive the second key; and in response to the second message, derive the second key from k AMF .

Description

Technical Field

[0001] The topics disclosed in this document generally relate to the field of implementing secure connections in wireless communication networks. This document defines user equipment apparatus, user equipment processor, network equipment apparatus, and methods performed by the user equipment. Background Technology

[0002] A wireless communication system may include one or more network communication devices, such as base stations, which may support wireless communication for one or more user communication devices, also referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers, etc.)). Additionally, the wireless communication system can support wireless communication across various radio access technologies, including third-generation (3G) radio access technology, fourth-generation (4G) radio access technology, fifth-generation (5G) radio access technology, and other suitable radio access technologies other than 5G (e.g., sixth-generation (6G)). Summary of the Invention

[0003] The article "a" preceding an element is unrestricted and should be understood to refer to "at least one" or "one or more" of these elements. The terms "a," "at least one," "one or more," and "at least one of one or more" are interchangeable. As used herein, including in the claims, the use of "or" in a list of items (e.g., a list of items beginning with phrases such as "at least one of..." or "one or more of..." or "one or two of...") indicates an inclusive list, such that, for example, a list of at least one of A, B, or C represents A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase "based on" should not be construed as a reference to a closed set of conditions. For example, an example step described as "based on condition A" could be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "at least partially based on." Furthermore, as used herein, including in the claims, "set" can include one or more elements.

[0004] A user equipment (UE) for wireless communication is provided, the UE comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the UE: establishes a first secure connection with an Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; send a first message to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of the second key, which is used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; receive a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF The second key is derived from this.

[0005] A network device for wireless communication is provided, the network device comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network device: establishes a first secure connection with a user equipment (UE) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; receive a first message from the UE via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, which is used to establish a second secure connection with the network device via a second non-3GPP access network, wherein the second key uses k AMF To derive; and to send a second message to the UE, wherein the second message indicates a request to derive a second key for the UE.

[0006] A method is provided performed by a user equipment (UE), the method comprising: establishing a first secure connection with an access and mobility management function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; send a first message to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of the second key, which is used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; receive a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF The second key is derived from this. Attached Figure Description

[0007] Figure 1 Examples of wireless communication systems according to various aspects of this disclosure are illustrated.

[0008] Figure 2a The diagram illustrates the signaling of an untrusted, non-3GPP access authentication.

[0009] Figure 2b The diagram illustrates the signaling of an untrusted, non-3GPP access authentication.

[0010] Figure 3a The diagram illustrates the signaling pattern for trusted non-3GPP access authentication.

[0011] Figure 3b The diagram illustrates the signaling pattern for trusted non-3GPP access authentication.

[0012] Figure 4a The diagram illustrates a signaling diagram for untrusted non-3GPP access authentication according to one or more embodiments.

[0013] Figure 4b The diagram illustrates a signaling diagram for untrusted non-3GPP access authentication according to one or more embodiments.

[0014] Figure 5 It is a table of access type distinguishers and values ​​according to one or more embodiments.

[0015] Figure 6a The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0016] Figure 6b The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0017] Figure 7 It is a table of access type distinguishers and values ​​according to one or more embodiments.

[0018] Figure 8a The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0019] Figure 8b The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0020] Figure 9 It is a table of access type distinguishers and values ​​according to one or more embodiments.

[0021] Figure 10 The diagram illustrates a signaling diagram for non-3GPP access authentication according to one or more embodiments.

[0022] Figure 11 It is a table of access type distinguishers and values ​​according to one or more embodiments.

[0023] Figure 12aThe diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0024] Figure 12b The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0025] Figure 13 It is a table of access type distinguishers and values ​​according to one or more embodiments.

[0026] Figure 14 An example of a user equipment (UE) 1400 according to various aspects of this disclosure is illustrated.

[0027] Figure 15 An example of a processor 1500 according to various aspects of this disclosure is illustrated.

[0028] Figure 16 An example of a network device (NE) 1600 according to various aspects of this disclosure is illustrated.

[0029] Figure 17 The diagram illustrates a flowchart of a method performed by a UE according to various aspects of this disclosure.

[0030] Figure 18 The diagram illustrates a flowchart of a method performed by an NE according to various aspects of this disclosure. Detailed Implementation

[0031] Fifth-generation (5G) system non-3GPP access networks (e.g., access networks other than 3GPP access networks other than the 3rd Generation Partnership Project 3GPP access network) do not support standardized interfaces between two different non-3GPP access networks (e.g., between gateway functions / interoperability functions (such as Trusted Network Gateway Function (TNGF) / Non-3GPP Interoperability Function (N3IWF)) in non-3GPP access networks to allow sharing of security context between the current non-3GPP access network and the target non-3GPP access network for user equipment (UE) mobility security (re)establishment.

[0032] In current 5G systems, mobility scenarios involving non-3GPP access are not optimally addressed. For example, when a UE disconnects from the first non-3GPP access node and connects to a second non-3GPP access node, full master authentication is performed even if the 5GC has valid security context content. This results in additional signaling between the UE and the 5GC, leading to latency in the connection between the device and the network.

[0033] The implementation enables network devices (e.g., Access and Mobility Management Function (AMF)) to instruct user equipment to derive a new (second) key for a secure connection to a second non-3GPP access network (i.e., to re-enter / refresh the non-3GPP access key).

[0034] The implementation enables the use of existing security contexts available in the user equipment and network equipment to re-enter / refresh non-3GPP access network connections during UE mobility registration (mobility registration update) scenarios without requiring the network equipment to perform primary full authentication.

[0035] The implementation enables the use of existing security contexts available in the user equipment and network equipment to re-enter / refresh non-3GPP access network connections during UE mobility security re-establishment without requiring the network equipment to perform primary full authentication.

[0036] Various aspects of this disclosure are described in the context of wireless communication systems.

[0037] Figure 1 An example of a wireless communication system 100 according to various aspects of this disclosure is illustrated. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various radio access technologies. In some implementations, the wireless communication system 100 may be a 4G network, such as an LTE network or an advanced LTE (LTE-A) network. In some other implementations, the wireless communication system 100 may be an NR network, such as a 5G network, an advanced 5G (5G-A) network, or a 5G ultra-wideband (5G-UWB) network. In other implementations, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable radio access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support radio access technologies other than 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as time division multiplexing (TDMA), frequency division multiplexing (FDMA), or code division multiplexing (CDMA).

[0038] One or more NEs 102 may be distributed throughout a geographic area to form a wireless communication system 100. The one or more NEs 102 described herein may be, include, or may be referred to as a network node, base station, network element, network function, network entity, radio access network (RAN), NodeB, eNodeB (eNB), next-generation NodeB (gNB), or other suitable terms. NEs 102 and UEs 104 may communicate via a communication link, which may be a wireless or wired connection. For example, NEs 102 and UEs 104 may perform wireless communication (e.g., receive signaling, send signaling) via a Uu interface.

[0039] NE 102 can provide a geographic coverage area for which NE 102 can support services of one or more UE 104s within that geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcasting, etc.) based on one or more radio access technologies. In some implementations, NE 102 can be mobile, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies can overlap, but different geographic coverage areas can be associated with different NE 102s.

[0040] One or more UEs 104 may be distributed throughout the geographic area of ​​the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some implementations, UE 104 may be referred to as a unit, station, terminal, or client, etc. Additionally or alternatively, UE 104 may be referred to as an Internet of Things (IoT) device, Internet of Everything (IoE) device, or Machine Type Communication (MTC) device, etc.

[0041] UE 104 may be able to support direct wireless communication with other UE 104s via a communication link. For example, UE 104 may support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular V2X deployments, the communication link may be referred to as a sidelink. For example, UE 104 may support direct wireless communication with another UE 104 via a PC5 interface.

[0042] NE 102 can support communication with CN 106 or with another NE 102, or both. For example, NE 102 can interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N2, or network interfaces). In some implementations, NE 102 can communicate directly with each other. In some other implementations, NE 102 can communicate indirectly with each other (e.g., via CN 106). In some implementations, one or more NE 102 may include sub-components, such as access network entities, which may be examples of access node controllers (ANCs). The ANC can communicate with one or more UE 104s via one or more other access network transport entities (which may be referred to as radio headends, smart radio headends, or transmit-receive points (TRPs)).

[0043] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities that manage access and mobility (e.g., a mobility management entity (MME), access and mobility management functions (AMF)) and user plane entities that route packets or interconnections to external networks (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entities may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.) of one or more UEs 104 served by one or more NEs 102 associated with CN 106.

[0044] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session with CN 106 via NE 102 (e.g., a Protocol Data Unit (PDU) session, etc.). CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, etc.) between UE 104 and the application server. The PDU session may be an example of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).

[0045] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some implementations, NE 102 and UE 104 can support different resource structures. For example, NE 102 and UE 104 can support different frame structures. In some implementations, such as in 4G, NE 102 and UE 104 can support a single frame structure. In some other implementations, such as in 5G and other suitable radio access technologies, NE 102 and UE 104 can support various frame structures (i.e., multiple frame structures). NE 102 and UE 104 can support various frame structures based on one or more digital technologies.

[0046] One or more digital technologies may be supported in the wireless communication system 100, and the digital technologies may include subcarrier spacing and cyclic prefix. The first digital technology (e.g., μ=0) can be associated with the first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first digital technique (e.g., ...) associated with the first subcarrier spacing (e.g., 15 kHz) is... μ =0) can utilize one time slot per subframe. Second digital technologies (e.g., μ =1) can be associated with the second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. The third digital technology (e.g., μ =2) can be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth digital technology (e.g., μ =3) can be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth digital technology (e.g., μ =4) can be associated with the fifth subcarrier spacing (e.g., 240 kHz) and the normal cyclic prefix.

[0047] The time intervals of resources (e.g., communication resources) can be organized according to frames (also called radio frames). Each frame can have a duration, for example, 10 milliseconds (ms). In some implementations, each frame can include multiple subframes. For example, each frame can include 10 subframes, and each subframe can have a duration, for example, 1 ms. In some implementations, each frame can have the same duration. In some implementations, each subframe of a frame can have the same duration.

[0048] Alternatively or concurrently, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may include a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more digital technologies supported in the wireless communication system 100. For example, a first digital technology, a second digital technology, a third digital technology, a fourth digital technology, and a fifth digital technology (i.e., ...) associated with corresponding subcarrier intervals of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz. μ =0、 μ =1、 μ =2、 μ =3、 μ=4) One time slot per subframe, two time slots per subframe, four time slots per subframe, eight time slots per subframe, and 16 time slots per subframe can be used, respectively. Each time slot can include a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of time slots in a subframe can depend on the digital technology. For a normal cyclic prefix, a time slot can include 14 symbols. For an extended cyclic prefix (e.g., for a 60 kHz subcarrier spacing), a time slot can include 12 symbols. The relationship between the number of symbols per time slot, the number of time slots per subframe, and the number of time slots per frame for both normal and extended cyclic prefixes can depend on the digital technology. It should be understood that for the first digital technology (e.g., quantity) associated with the first subcarrier spacing (e.g., 15 kHz), μ The reference of =0 can be used interchangeably between subframes and time slots.

[0049] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, frequency channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 can support one or more operating frequency bands, such as frequency range names FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, network entity 102 and UE 104 can perform wireless communication on one or more operating frequency bands. In some implementations, FR1 can be used by network entity 102 and UE 104, as well as other devices or apparatuses, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by network entity 102 and UE 104, as well as other devices or apparatuses, for short-range, high data rate capabilities.

[0050] FR1 can be associated with one or more digital technologies (e.g., at least three digital technologies). For example, FR1 can be associated with the following: a first digital technology (e.g., μ =0), which includes a 15 kHz subcarrier spacing; second digital technology (e.g., μ =1), which includes a 30 kHz subcarrier spacing; third digital technology (e.g., μ =2), which includes a subcarrier spacing of 60 kHz. FR2 can be associated with one or more digital technologies (e.g., at least two digital technologies). For example, FR2 can be associated with a third digital technology (e.g., μ=2), which includes a 60 kHz subcarrier spacing; fourth digital technology (e.g., μ =3), which includes a subcarrier spacing of 120 kHz.

[0051] Figure 2a The diagram illustrates a signaling scheme for authentication of untrusted, non-3GPP access, generally indicated by reference numeral 200.

[0052] Signaling diagram 200 includes UE 210, untrusted non-3GPP access network 220, N3IWF 230, AMF 240 and AUSF 250.

[0053] Signaling diagram 200 illustrates the first part of a procedure that can be executed when UE 210 disconnects from and reconnects to the first N3IWF 230. Signaling diagram 200 also illustrates the first part of a procedure that can be executed when UE 210 disconnects from and connects to the second N3IWF 250.

[0054] When UE 210 disconnects from and reconnects to the first N3IWF 230 or connects to the second N3IWF 230, AMF 240 will perform full master authentication even if AMF 240 has a valid security context available. The full master authentication process performed by AMF 240 can be described as Section 7.2.1 of 3GPP Technical Specification (TS) 33.501 V18.3.0.

[0055] Authentication for untrusted, non-3GPP access can be described as follows.

[0056] UE 210 authenticates to the 5G network via an untrusted non-3GPP access network 220. It uses a vendor-specific extensible authentication protocol (EAP) method called “EAP-5G,” utilizing an “extended” EAP type and an existing 3GPP vendor ID to register with the Internet Assigned Numbers Authority (IANA) under the SMI Private Enterprise Code Registry. The “EAP-5G” method is used between UE 210 and N3IWF230 and is used to encapsulate NAS messages. If UE 210 is authenticated by the 3GPP home network, any authentication method described in Section 6.1.3 of TS33.501 V18.3.0 can be used. This method is performed between UE 210 and AUSF 250, as... Figure 2a and Figure 2b As shown

[0057] Where possible, UE210 should be authenticated by reusing the existing UE NAS security context in AMF 240.

[0058] Signalling diagram 200 includes the following steps:

[0059] In step 271a, UE 210 connects to an untrusted non-3GPP access network 220. When UE 210 decides to attach to a 5GC network, UE 210 selects N3IWF 230 in the 5G PLMN as described in Clause 6.3.6 of 3GPP TS 23.501 V18.3.0[2].

[0060] In step 272, UE 210 continues to establish an IPsec security association (SA) with the selected N3IWF 230 by initiating an initial Internet Key Exchange (IKE) exchange in accordance with IKE protocol version 2 (IKEv2) RFC 7296. After step 272, all subsequent IKE messages are encrypted and protected for integrity using the IKE SA established in this step.

[0061] In step 273, UE 210 should initiate an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange should use EAP signaling (in this case, EAP-5G signaling). According to IKEv2 RFC 7296, in IDi, UE 210 should set the ID type in this message to ID_KEY-ID and set its value to any random number. In this step, UE 210 should not use its Globally Unique Temporary Identifier (GUTI) / Subscription Hidden Identifier (SUCI) / Subscription Permanent Identifier (SUPI) as the ID. If UE 210 is supplied with N3IWF 230 root credentials, it should include a credential request (CERTREQ) payload in the IKE_AUTH request message to request credentials for N3IWF 230.

[0062] In step 274, N3IWF 230 responds with an IKE_AUTH response message, which includes the N3IWF 230 identity, an AUTH payload (in the IKE_SA_INIT exchange) to protect previous messages sent to UE 210, and an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet notifies UE 210 to initiate an EAP-5G session, i.e., to begin sending Non-Access Stratum (NAS) messages encapsulated within EAP-5G packets. If UE 210 has already sent a CERTREQ payload in step 273, N3IWF 230 should also include a CERT payload containing N3IWF 230 credentials.

[0063] In step 275, UE 210 should verify the N3IWF 230 credentials and confirm that the N3IWF identity matches the N3IWF 230 selected by UE 230. If UE 210 has already requested credentials or identity verification is unsuccessful, the lack of credentials in N3IWF 230 will result in connection failure. UE 210 should send an IKE_AUTH request, which includes an EAP-Response / 5G-NAS packet containing a registration request message that includes UE 210's security capabilities and SUCI. If UE 210 has already accessed 5GC via 3GPP and a usable security context exists, UE 210 should perform integrity protection on the registration request message and should send a 5G-GUTI instead of a SUCI. N3IWF 230 should avoid sending an EAP identity request. UE 210 may ignore the EAP identity request or respond with the SUCI it sent in the registration request. If UE 210 has already registered to the same AMF 240 via 3GPP access, and if this is the first time UE 210 has connected to 5GC via non-3GPP access, the value of the corresponding uplink non-access stratum count (UL NAS count) used for integrity protection is 0; otherwise, it can use the existing non-3GPP specific UL NAS count for integrity protection.

[0064] N3IWF 230 does not send an EAP identity request because UE 210 includes its identity in the IKE_AUTH request in message 275. This is in accordance with Clause 3.16 of IKEv2 RFC 7296.

[0065] In step 276, N3IWF 230 shall select AMF 240 in accordance with Clause 6.5.3 of TS 23.501 V18.3.0. N3IWF 230 shall forward the registration request received from UE 210 to AMF 240.

[0066] In step 277, if AMF 240 receives the 5G-GUTI and registration is protected by integrity, it can use the security context to verify the integrity protection, as described in Section 6.4.6 of TS 33.501 V18.3.0. If UE 210 has already registered to the same AMF 240 via 3GPP access, and if this is the first time AMF 240 has received NAS signaling from UE 210 via non-3GPP access, the corresponding UL NAS count used for integrity verification is 0; otherwise, it can use an existing non-3GPP specific UL NAS count for integrity verification. If integrity is successfully verified, UE 210 is instructed to be authenticated by AMF 240. If integrity is successfully verified and no newer security context is activated on 3GPP access, steps 278 through 281 can be skipped. If integrity is successfully verified and the newer security context has been activated via 3GPP access, authentication can be skipped. However, AMF 240 should activate the newer context using the NAS Spica Mobility Core Solution (SMC) procedure, as described in step 278 and thereafter. Otherwise, AMF 240 should authenticate UE 210.

[0067] If AMF 240 decides to authenticate UE 210, it should use one of the methods in Section 6.1.3 of TS 33.501 V18.3.0. In this case, AMF 240 should send a key request to the Authentication and Key Management Function (AUSF) 250. AUSF 250 can initiate the authentication process as specified in Section 6.1.3 of TS 33.501 V18.3.0. Between AMF 240 and UE 210, the authentication packet is encapsulated within a NAS authentication message, and the NAS authentication message is carried in the N2 signaling between AMF 230 and N3IWF 230, and then encapsulated within an EAP-5G / 5G-NAS packet between N3IWF 240 and UE 210.

[0068] In the final authentication message from the home network, AUSF 250 should retrieve the information from k. AUSF The derived anchor key k SEAF Send to the Security Anchor Function (SEAF). SEAF should be sent from k SEAF Derive k AMF The SEAF is then sent to AMF 240, which uses it to derive the NAS security key. If the EAP-Authentication and Key Protocol (AKA) is used for authentication as described in Section 6.1.3.1 of TS 33.501V18.3.0, then AUSF 250 should include EAP-Success. UE 210 also derives the anchor key k. SEAFAnd from this key, k is derived. AMF Then, the NAS security key is derived. The NAS COUNTS associated with the NAS connection identifier "0x02" is set at UE 210 and AMF 240.

[0069] In step 278, AMF 240 should send a Security Mode Command (SMC) to UE 210 to activate NAS security associated with the NAS connection identifier “0x02”. This message is first sent to N3IWF 230 (within the N2 message). If EAP-AKA’ is used for authentication, AMF 240 should encapsulate the EAP-Success received from AUSF 250 within the SMC message.

[0070] In step 279, N3IWF 230 should forward the NAS SMC to UE210 within the EAP-Request / 5G-NAS packet.

[0071] Figure 2b The diagram illustrates a signaling scheme for authentication of untrusted, non-3GPP access, generally indicated by reference numeral 205.

[0072] Signaling diagram 205 includes UE 210, untrusted non-3GPP access network 220, N3IWF 230, AMF 240 and AUSF 250.

[0073] Signaling diagram 205 illustrates... Figure 2a The signaling diagram 205 illustrates the subsequent procedures of the first part of the process shown in signaling diagram 200. Signaling diagram 205 illustrates the second part of the procedures that can be executed when UE 210 disconnects from and reconnects to the first N3IWF 230. Signaling diagram 205 also illustrates the second part of the procedures that can be executed when UE 210 disconnects from and connects to the second N3IWF 230.

[0074] Signaling diagram 205 includes the following steps.

[0075] In step 280, UE 210 completes authentication (if in Figure 2a The NAS security context is initiated in step 277 of the NAS SMC, and a NAS security context is created or another NAS security context is activated based on the key set identifier (ngKSI) received in the NAS SMC. UE 210 shall respond to the NAS SMC it receives from AMF 240 based on the selected algorithm and parameters, as described in Clause 6.7.2 of TS 33.501V18.3.0. UE 210 shall encapsulate the NAS SMC Complete in the EAP-5G response.

[0076] In step 281, N3IWF 230 should forward the NAS packet containing NAS SMC Complete to AMF 240 via the N2 interface.

[0077] In step 282, upon receiving NAS SMC Complete from UE 210 or upon successful integrity protection verification, AMF 240 initiates a Next Generation Application Protocol (NGAP) procedure to establish the AN context. AMF 240 should use the uplink NAS count associated with the NAS connection identifier “0x02” as defined in Annex A.9 of TS 33.501V18.3.0 to calculate the N3IWF key k. N3IWF This is used to establish an IPsec security association (SA) between UE 210 and N3IWF 230, and should be included in the NGAP initial context establishment request sent to N3IWF 230.

[0078] In step 283, when the N3IWF key k is received... N3IWF When the N3IWF 230 sends an EAP-Success / EAP-5G request to the UE 210 during the NGAP initial context establishment request, this completes the EAP-5G session, and no further EAP-5G packets are exchanged. If the N3IWF 230 does not receive k from the AMF 240... N3IWF If so, N3IWF 220 should respond with EAP-Failure.

[0079] In step 284, the N3IWF key k is used. N3IWF An IPsec SA is established between UE 210 and N3IWF 230. This key is created in UE 210 using the uplink NAS count associated with the NAS connection identifier “0x02” as defined in Annex A.9 of TS 33.501 V18.3.0, and is received by N3IWF 230 from AMF 240 in step 282.

[0080] In step 285, after successfully establishing an IPsec SA between UE 210 and N3IWF 230, N3IWF 230 should send an NGAP Initial Context Establishment Response Message to AMF 240.

[0081] In step 285a, AMF 240 can determine whether N3IWF 230 is suitable for the selected slice as defined in Clause 4.12.2.2 of TS 23.502 V18.3.0. If it is compatible with the selected N3IWF 230, proceed to steps 286 and 287. Otherwise, AMF 240 will proceed to steps 288 through 290, and steps 286 through 287 will be skipped.

[0082] In signaling diagrams 200 and 205, the AMF 240 cannot provide the N3IWF230 with a new non-3GPP access key (e.g., k) without performing a full master authentication run. N2IWF UE 210 can connect to the same AMF 240 via a different target N3IWF 230 in mobility situations, but the current authentication process does not allow AMF 240 to reuse the UE NAS security context to refresh or re-enter the N3IWF key for non-3GPP access connections of UE 210 and N3IWF 230.

[0083] Figure 3a The diagram illustrates a signaling diagram for trusted non-3GPP access authentication, generally indicated by reference numeral 300. Signaling diagram 300 can represent registration / authentication and Packet Data Unit (PDU) session establishment for trusted non-3GPP access.

[0084] Signaling diagram 300 includes UE 310, Trusted Non-3GPP Access Network (TNAN) 320, AMF 340, and AMF 350. TNAN 320 includes Trusted Non-3GPP Access Point (TNAP) 322 and Trusted Non-3GPP Gateway Function (TNGF) 324.

[0085] Signaling diagram 300 illustrates the first part of a procedure that can be executed when UE 310 disconnects from and reconnects to the first TNGF 324. Signaling diagram 300 also illustrates the first part of a procedure that can be executed when UE 310 disconnects from and connects to the second TNGF 324.

[0086] When UE 310 disconnects from the first TNGF 324 and reconnects to the first TNGF 324 or connects to a new second TNGF 324, full master authentication is performed even if AMF 340 has a valid security context available; as described in Section 7A.2.1 of 3GPPTS 33.501 V18.3.0.

[0087] Signaling diagram 300 includes the following steps.

[0088] In step 0, UE 310 selects a Public Land Mobile Network (PLMN) and a Trusted Non-3GPP Access Network (TNAN) 320 for connecting to the PLMN using the Trusted Non-3GPP Access Network Selection Procedure as specified in Clause 6.3.12 of TS 23.501 V18.3.0. During this procedure, UE 310 discovers that the TNAN 320 supports the PLMN with which it has a trusted connection (e.g., a “5G connection”).

[0089] In step 371, a Layer 2 (L2) connection is established between UE 310 and TNAP 322. In the case of IEEE 802.11, this step corresponds to 802.11 association. In the case of Point-to-Point Protocol (PPP), this step corresponds to PPP Link Control Protocol (LCP) negotiation. In other types of non-3GPP access (e.g., Ethernet), this step may not be required.

[0090] In steps 372-373, the EAP authentication process is initiated. The EAP message should be encapsulated into Layer 2 packets, such as IEEE 802.3 / 802.1x packets, IEEE 802.11 / 802.1x packets, PPP packets, etc. UE 310 provides a Network Access Identifier (NAI), which triggers TNAP 322 to send an Authentication, Authorization, and Accounting (AAA) request to TNGF 324. Between TNAP 322 and TNGF 324, the EAP packet is encapsulated into an AAA message.

[0091] In step 372, UE 310 sends an L2 message to TNAP 322, which may include EAP-Req / Identity.

[0092] In step 373, UE 310 sends an L2 message to TNAP 322, which may include EAP-Res / Identity and / or username@domain.

[0093] In steps 374-380, the EAP-5G procedure is performed in accordance with Clause 7.2.1 of TS 33.501 V18.3.0, with the following modifications: • EAP-5G packets should not be encapsulated as IKEv2 packets. UE 310 should also include the UE Id in the AN parameters, for example, 5G-GUTI (if available from a previous registration to the same PLMN). • After successful authentication, create the k specified in Annex A.9 of TS 33.501 V18.3.0 in UE 310 and AMF 340. TNGF (equivalent to k) N3IWFIn step 380a (within the N2 initial context establishment request), k TNGF Transfer from AMF 340 to TNGF 324. •TNAP 322 is a trusted entity. TNGF 324 should be generated in accordance with Annex A.22 of TS 33.501 V18.3.0. TNAP And in step 10b, it is transmitted from TNGF to TNAP (within the AAA message). • In step 380a, the TNGF key k is received from the AMF 340. TNGF Subsequently, TNGF 324 should send an EAP request / 5G notification packet containing "TNGF Contact Info" to UE 310, which includes the IP address of TNGF 324. After receiving the EAP response / 5G notification packet from the UE, TNGF should send message 10d containing the EAP-Success packet.

[0094] In step 374, TNGF 324 sends an AAA message to TNAP 322, which may include (EAP-REQ / 5G-Start).

[0095] In step 375, UE 310 sends an L2 message to TNAP 322, which may include ( ] NAS-PDU (Reg.Req). TNAP 322 sends an AAA message to TNGF 324, which may include (EAP-Res / 5G-NAS / AN-Params (Single Network Slice Selection Auxiliary Information (S-NSSAI) or 5G GUTI, ...) and NAS-PDU (Reg.Request).

[0096] In step 376b, TNGF 324 sends an N2 message to AMF 340, which may include a registration request.

[0097] In step 377a, TNGF 324 and AMF f340 exchange N2 messages, which may include (identity Req. / Res.).

[0098] In step 377b, TNAP 322 and TNGF 324 exchange AAA messages, which may include (EAP-REQ / RES / 5G-NAS / NAS-PDU (identity Req / Res)).

[0099] In step 378a, AMF 340 sends a Nausf_UEAuthentication authentication request to AUSF 350, which may include SUPI or SUCI.

[0100] In step 378c, AUSF 350 sends a Nausf_UEAuthentication authentication response to AMF 340, which may include a SEAF key and / or an EAP-Success indication.

[0101] In step 379b, TNGF 324 sends an AAA message to TNAP 322, which may include (EAP-REQ / 5G-NAS / NAS-PDU [SMC Request (EAP-SUCCESS)]). TNAP 322 sends an L2 message to UE 310, which may include (EAP-REQ / 5G-NAS / NAS-PDU [SMC Request (EAP-SUCCESS)], TNGF address).

[0102] In step 379c, TNAP 322 sends an AAA message to TNGF 324, which may include (EAP-Res / 5G-NAS / SMC Complete).

[0103] In step 380a, AMF 340 may send an N2 message to TNGF 324, which may include an initial context establishment request and / or k TNGF .

[0104] In step 380b, TNGF 324 sends an AAA message to TNAP 322, which may include (EAP-Req / 5G notification / TNGF address). TNAP 322 may send an L2 message to UE 310, which may include (EAP-Req / 5G notification / TNGF address).

[0105] In step 380c, UE 310 may send an L2 message to TNAP 322, which may include (EAP-Res / 5G notification / ). TNAP 322 may send an AAA message to TNGF 324, which may include (EAP-Res / 5G notification / ).

[0106] In step 380d, TNGF 324 sends an AAA message to TNAP 322, which may include the TNAP key and / or an EAP-Success indication.

[0107] Figure 3bThe diagram illustrates a signaling diagram for trusted non-3GPP access authentication, generally indicated by reference numeral 305. Signaling diagram 305 can represent registration / authentication and Packet Data Unit (PDU) session establishment for trusted non-3GPP access.

[0108] Signaling diagram 305 includes UE 310, Trusted Non-3GPP Access Network (TNAN) 320, AMF 340, and AMF 350. TNAN 320 includes Trusted Non-3GPP Access Point (TNAP) 322 and Trusted Non-3GPP Gateway Function (TNGF) 324.

[0109] Signaling diagram 305 illustrates Figure 3a The signaling diagram 305 illustrates the follow-up process to the first part of the procedure shown in signaling diagram 300. Signaling diagram 305 illustrates the second part of the procedure that can be executed when UE 310 disconnects from and reconnects to the first TNGF 324. Signaling diagram 305 also illustrates the second part of the procedure that can be executed when UE 310 disconnects from and connects to the second TNGF 324.

[0110] Signaling diagram 305 includes the following steps.

[0111] In step 381, UE 310 and TNAP 322 use the public TNAP key (k TNAP The security key is derived based on the non-3GPP technology used, and a security association is established to protect all subsequent services. In the case of IEEE 802.11, k TNAP It uses a pair of master keys (PMK) and performs a 4-way handshake (see IEEE 802.11) to establish a security context between the wireless LAN (WLAN) access point (AP) and the UE 310. This security context is used to protect over-the-air unicast and multicast services. From this step onwards, all messages between the UE 310 and the TNAP 322 are encrypted and protected for integrity.

[0112] In step 382, ​​UE 310 receives Internet Protocol (IP) configuration from TNAN 320, for example, using Dynamic Host Configuration Protocol (DHCP).

[0113] In step 383, UE 310 should initiate an IKE_INIT exchange with TNGF 324. UE 310 has already received the IP address of TNGF 324 during the EAP-5G signaling in step 379b. Subsequently, UE 310 should initiate an IKE_AUTH exchange, and should include the same UE Id as provided in step 375 (i.e., SUCI or 5G-GUTI). Public KTIPSe Used for mutual authentication. Key K TIPSec Derived according to Annex A.22 of TS 33.501 V18.3.0. NULL encryption is negotiated according to RFC 2410. After step 383c, an IPsec SA (i.e., NWt connection) is established between UE 310 and TNGF 324 and used to transmit all subsequent NAS messages. This IPsec SA is not encrypted; only integrity protection is applied.

[0114] In step 384, after successfully establishing the NWtp connection, TNGF 324 responds to AMF 340 with an N2 Initial Context Establishment Response message.

[0115] In step 384a, AMF 340 can determine whether TNGF 324 is suitable for the selected slice as defined in Section 4.12.2.2 of TS 23.502 V18.3.0. If it is compatible with the selected TNGF 324, proceed to steps 385 through 389. Otherwise, AMF 340 should proceed to steps 390 through 392, and steps 385 through 389 are skipped.

[0116] Without performing a full master authentication operation, the existing authentication process for trusted non-3GPP access cannot enable AMF 340 to transmit authentication data to TNGF (k...). TNGF A new non-3GPP access key is provided. UE 310 can connect to the same AMF 340 via a different target TNGF 324 in mobility situations, but the current authentication process does not allow AMF 340 to reuse the UE NAS security context to refresh or re-enter the TNGF key of UE 310 and TNGF 324 during non-3GPP access connections.

[0117] In some embodiments (e.g., for UE mobility), the AMF can re-enter / refresh the non-3GPP access key. In some embodiments, in the case of a trusted non-3GPP access connection, the AMF can re-enter / refresh the TNGF key. In some embodiments, in the case of an untrusted non-3GPP access connection, the AMF can re-enter / refresh a new N3IWF key. In some embodiments, in the case of trusted WLAN access, the AMF can re-enter / refresh the TWIF key. In some embodiments, the AMF can re-enter / refresh the W-AGF key in the case of 5G-RG to provide a fresh / new non-3GPP access key (Ktngf) to the target 3GPP access node (i.e., the target TNGF / N3IWF / WLAN-AP / W-5GAN). / Kn3iwf / Ktwif / Kwagf It also instructs the UE to refresh / re-enter the required non-3GPP access key so that the UE / N5CW device / 5G-RG device can derive the same key as the network, thereby re-establishing a secure connection on the target non-3GPP access network.

[0118] Figure 4a The diagram illustrates a signaling diagram for authentication of untrusted non-3GPP access according to one or more embodiments, generally indicated by reference numeral 400.

[0119] Signaling diagram 400 includes UE 410, Trusted Non-3GPP Access Network (TNAN) 420, AMF 440, and AMF 450. TNAN 420 includes Trusted Non-3GPP Access Point (TNAP) 422 and Trusted Non-3GPP Gateway Function (TNGF) 424.

[0120] Signaling diagram 400 illustrates the first part of a procedure that can be executed when UE 410 disconnects from and reconnects to the first TNGF 424. Signaling diagram 400 also illustrates the first part of a procedure that can be executed when UE 410 disconnects from and connects to the second TNGF 424.

[0121] In some embodiments, signaling figure 400 illustrates a method for refreshing a non-3GPP access network key during a UE mobility registration update involving changes to the 3GPP access network.

[0122] In some embodiments, signaling diagram 400 illustrates how the UE security context available in UE 410 / AMF 440 during a UE mobility registration (mobility registration update) scenario can be used to re-enter / refresh a non-3GPP access network connection without performing primary full authentication.

[0123] In some embodiments, signaling diagram 400 illustrates how to notify UE 410 of a non-3GPP access network re-entry / refresh (occurring at the network) so that UE 410 refreshes / re-enters the non-3GPP access key similar to the network, thereby re-establishing security on the new target non-3GPP access network connection.

[0124] In some embodiments, when UE 410 connects to an untrusted non-3GPP access network (i.e., a new target AP and a new N3IWF) in a mobility situation, signaling diagram 400 can be reused to re-enter / refresh the N3IWF key between UE 410 and N3IWF.

[0125] In some embodiments, signaling diagram 400 illustrates N3IWF re-entry / refresh during UE mobility scenarios (registration / authentication / PDU session establishment / modification) for untrusted non-3GPP access.

[0126] In some embodiments, signaling diagram 400 includes the following steps.

[0127] In step 471, UE 410 connects to an untrusted non-3GPP access network 420. When UE 410 decides to attach to a 5G core (5GC) network, UE 410 selects N3IWF in the 5G Public Land Mobile Network (PLMN) as described in Section 6.3.6 of TS 23.501V18.3.0.

[0128] In step 472, UE 410 continues to establish an IPsec security association (SA) with the selected N3IWF by initiating an IKE initial exchange in accordance with RFC 7296. After step 472, all subsequent IKE messages are encrypted and protected for integrity using the IKE SA established in this step.

[0129] In step 473, UE 410 should initiate an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange should use EAP signaling (in this case, EAP-5G signaling). According to RFC 7296, in IDi, UE 410 should set the ID type in this message to ID_KEY-ID and set its value to any random number. In this step, UE 410 should not use its GUTI / SUCI / SUPI as the ID. If UE 410 is supplied with N3IWF root credentials, it should include a CERTREQ payload in the IKE_AUTH request message to request N3IWF credentials.

[0130] In step 474, the N3IWF responds with an IKE_AUTH response message, which includes the N3IWF identity, an AUTH payload (in the IKE_SA_INIT exchange) to protect previous messages sent to UE 410, and an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet notifies UE 410 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within the EAP-5G packet. If UE 410 has already sent a CERTREQ payload in step 473, the N3IWF should also include a CERT payload containing the N3IWF credentials.

[0131] In step 475, UE 410 should verify the N3IWF credentials and confirm that the N3IWF identity matches the N3IWF selected by UE 410. If UE 410 has already requested credentials or identity verification is unsuccessful, the lack of credentials in the N3IWF will cause connection failure. UE 410 should send an IKE_AUTH request, which includes an EAP-Response / 5G-NAS packet containing a registration request message that includes UE security capabilities, UE non-3GPP access key refresh capabilities, and SUCI. If UE 410 already has 5GC through 3GPP access and a usable security context exists, UE 410 should perform integrity protection on the registration request message and should send a 5G-GUTI instead of a SUCI. The N3IWF should avoid sending an EAP identity request. UE 410 may ignore the EAP identity request or respond with the SUCI it sent in the registration request. If UE 410 has already registered to the same AMF 440 via 3GPP access, and if this is the first time UE 410 has connected to 5GC via non-3GPP access, the value of the corresponding uplink non-access stratum count (UL NAS count) used for integrity protection is 0; otherwise, it can use the existing non-3GPP specific UL NAS count for integrity protection.

[0132] The UE non-3GPP access key refresh capability indicates that UE 410 supports one or more key refreshes (or re-entries): TNGF key refresh, N3IWF key refresh, etc.

[0133] In some embodiments, the N3IWF does not send an EAP identity request because UE 410 includes its identity in the IKE_AUTH request in message 5. This complies with section 3.16 of RFC 7296.

[0134] In steps 476a to 476b, the N3IWF shall select the AMF 440 in accordance with Clause 6.5.3 of TS 23.501 V18.3.0. The N3IWF will forward the registration request received from UE 410 to the AMF 440. The registration request message includes UE security capabilities, UE non-3GPP access key refresh capabilities, and SUCI.

[0135] In step 477a, if AMF 440 receives the 5G-GUTI and registration is protected by integrity, it can use the security context to verify the integrity protection (including integrity protection of the UE's security capabilities and the UE's non-3GPP access key refresh capability received in the registration request message), as described in Section 6.4.6 of TS 23.501 V18.3.0. If UE 410 has already registered to the same AMF 440 via 3GPP access, and if this is the first time AMF 440 has received the UE's NAS signaling via non-3GPP access, the corresponding UL NAS count used for integrity verification is 0; otherwise, it can use the existing non-3GPP specific UL NAS count for integrity verification. If integrity is successfully verified, UE 410 is instructed to be authenticated by AMF 440. If integrity is successfully verified and no new security context is activated via 3GPP access, steps 478 to 481 can be skipped. If integrity is successfully verified and the newer security context has been activated via 3GPP access, authentication can be skipped, but AMF 440 should activate the newer context using the NAS SMC procedure, as described in step 478 and thereafter. Otherwise, AMF 440 can authenticate UE 410.

[0136] If AMF 440 decides to authenticate UE 410, it should use one of the methods in Section 6.1.3 of TS 23.501 V18.3.0. In this case, AMF 440 should send a key request to AUSF 450. AUSF 450 can initiate the authentication process specified in Section 6.1.3 of TS 23.501 V18.3.0. Between AMF 440 and UE 410, the authentication packet is encapsulated in a NAS authentication message, and the NAS authentication message is carried in the N2 signaling between AMF 440 and N3IWF, and then encapsulated in an EAP-5G / 5G-NAS packet between N3IWF and UE 410.

[0137] In the final authentication message from the home network, AUSF 450 should retrieve the information from k. AUSF The anchor key k derived from it SEAF Send to SEAF. SEAF should receive from k SEAF Derivation of k AMF This key is then sent to AMF 440, which uses it to derive the NAS security key. If EAP-AKA' is used for authentication as described in Section 6.1.3.1 of TS 23.501 V18.3.0, then AMF 450 should include EAP-Success. UE 410 also derives the anchor key k. SEAF And derive k from that key.AMF Then, the NAS security key is derived. The NAS count associated with the NAS connection identifier "0x02" is set at UE 410 and AMF440.

[0138] In step 477b, alternatively, if the UE 410's non-3GPP access key refresh capability is indicated / provided by the UE 410, the AMF 440 may determine to skip primary full authentication based on a local policy and perform the following actions to re-enter / refresh the non-3GPP access network key:

[0139] If UE 410 uses untrusted non-3GPP access in mobility scenarios, AMF 440 retrieves the UE context and the latest k based on 5G-GUTI. AMF And derive the fresh N3IWF key k N3IWF A fresh N3IWF key is derived using the following input, but the access type distinguisher can use a value associated with 'N3IWF refresh / re-enter'.

[0140] In some embodiments, the 'N3IWF refresh / re-enter' process is as follows.

[0141] When the latest k message received from UE 410 and AMF 440 (either the latest NAS message received from UE 410 or a NAS message containing registration requests / PDU session establishment / modifications during UE mobility) AMF The key k is derived from the uplink NAS count. gNB k WAGF k TNGF k TWIF and k N3IWF / k N3IWF When doing so, the following parameters should be used to form the input S of the KDF. - FC=0x6E - P0 = Uplink NAS Count - L0 = Length of the uplink NAS count (i.e., 0x00 0x04) - P1=Access type distinguisher - L1 = Length of the access type distinguisher (i.e., 0x00 0x01) - P2 = Freshness parameter (e.g., count / random number / temporary value) - L2 = Length of the freshness parameter (i.e., 0x00 0x01)

[0142] In some embodiments, P2 and L2 can be used for additional input for 'N3IWF refresh / re-typing'.

[0143] Figure 5 It is a table of access type distinguishers and values ​​according to one or more embodiments, generally indicated by reference numeral 500 in the accompanying drawings.

[0144] In some embodiments, the value of the "3GPP Access" access type distinguisher is 0x01. In some embodiments, the value of the "Non-3GPP Access" access type distinguisher is 0x02. In some embodiments, the value of the "Non-3GPP Access Key Refresh / Re-enter" access type distinguisher is 0x03. In some embodiments, the value of the "N3IWF Refresh / Re-enter" access type distinguisher is 0x03 or 0x04. In some embodiments, the value of the "TNGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "WAGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "TWIF Refresh / Re-enter" access type distinguisher is 0x03 or 0x07.

[0145] Values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and values ​​0xf1 through 0xff are reserved for private use.

[0146] In deriving k gNB When doing so, the access type distinguisher should be set to the 3GPP value (0x01). In deriving k... N3IWF k WAGF k TWIF or k TNGF At that time, the access type distinguisher should (initially) be set to a non-3GPP value (0x02).

[0147] The input key KEY should be 256 bits. AMF .

[0148] This feature is applied when establishing encrypted 5G radio bearers and when performing dynamic key changes.

[0149] return Figure 4aIn step 478, AMF 440 may send a Security Mode Command (SMC) to UE 410 to activate NAS security associated with the NAS connection identifier “0x02”. This message is first sent to N3IWF (within the N2 message). If EAP-AKA’ is used for authentication, AMF 440 should encapsulate the EAP-Success received from AMF 450 within the SMC message. AMF 450 may instruct (in this step or later in step 482) an N3IWF key refresh instruction / non-3GPP access key refresh instruction, and a freshness parameter (if used in the N3IWF key refresh) to inform / notify UE 410 to perform an N3IWF key refresh (same as the network), thereby re-establishing security for the new 3GPP access network (through which UE 410 connects to the network).

[0150] In step 479, the N3IWF should forward the NAS SMC to the UE 410 within the EAP request / 5G-NAS packet (as well as the N3IWF key refresh indication / non-3GPP access key refresh indication, and freshness parameters (if received from AMF 440 in step 478)).

[0151] In step 480, UE 410 completes authentication (if initiated in step 477) and creates a NAS security context, or alternatively, activates another NAS security context based on the ngKSI received in the NAS SMC. UE 410 should respond to the NAS SMC it receives from AMF 440 based on the selected algorithm and parameters, as described in Section 6.7.2 of TS 23.501 V18.3.0. UE 410 should encapsulate the NAS SMC Complete in an EAP-5G response.

[0152] Figure 4b The diagram illustrates a signaling diagram for authentication of untrusted non-3GPP access according to one or more embodiments, generally indicated by reference numeral 405.

[0153] Signaling diagram 405 includes UE 410, Trusted Non-3GPP Access Network (TNAN) 420, AMF 440, and AMF 450. TNAN 420 includes Trusted Non-3GPP Access Point (TNAP) 422 and Trusted Non-3GPP Gateway Function (TNGF) 424.

[0154] Signaling diagram 405 illustrates the process from... Figure 4aSignaling diagram 400 illustrates the process that begins with the first part of the procedure. Signaling diagram 405 illustrates the second part of the procedure that can be executed when UE 410 disconnects from and reconnects to the first TNGF 424. Signaling diagram 405 also illustrates the first part of the procedure that can be executed when UE 410 disconnects from and connects to the second TNGF 424.

[0155] In some embodiments, signaling diagram 405 includes the following steps.

[0156] In step 481, N3IWF should forward the NAS packet containing NAS SMC Complete to AMF 440 via the N2 interface.

[0157] In step 482, upon receiving NAS SMC Complete from UE 410 or upon successful integrity protection verification, AMF 440 initiates an NGAP procedure to establish an AN context. AMF 440 should use the uplink NAS count associated with the NAS connection identifier “0x02” or, in mobility scenarios, the uplink NAS count associated with the non-3GPP access key refresh / re-entry (or) N3IWF refresh / re-entry identifier “0x03 or 0x04” (as defined in step 477b) to calculate the fresh N3IWF key k. N3IWF (For UE 410 mobility case k) N3IWF (If not performed in step 477b), to establish an Ipsec SA between UE 410 and the (new) N3IWS, and should be included in the NGAP Initial Context Establishment Request sent to N3IWF along with the N3IWF Key Refresh Instruction / Non-3GPP Access Key Refresh Instruction and freshness parameter (if used in N3IWF Key Refresh) in the message, to inform / notify UE 410 to perform N3IWF Key Refresh (same as the network), thereby re-establishing security for the new 3GPP access network (through which UE 410 connects to the network).

[0158] In step 483, upon receiving the N3IWF key k N3IWF Upon receiving the NGAP Initial Context Establishment Request, the N3IWF sends EAP-Success / EAP-5G, along with an N3IWF Key Refresh Indicator / Non-3GPP Access Key Refresh Indicator and freshness parameters (if received in step 482) to the UE 410. This completes the EAP-5G session, and no further EAP-5G packets are exchanged. If the N3IWF does not receive k from the AMF 440... N3IWFIf so, N3IWF should respond with EAP-Failure.

[0159] In step 484, after receiving the N3IWF key refresh instruction / non-3GPP access key refresh instruction, UE 410 determines to perform a network-like N3IWF key refresh. UE 410 derives the fresh N3IWF key according to the network-like "N3IWF refresh / re-entry" procedure (in step 477b). The freshness parameter (if received from TNGF 424) can also be used as the fresh N3IWF key (k). N3IWF Additional inputs derived from this.

[0160] In step 495a, an Ipsec SA is established between UE 410 and N3IWF using the N3IWF key KN3IWF, which is created in UE 410 using the uplink NAS count associated with the NAS connection identifier “0x02” as defined in Annex A.9 of TS 33.501 V18.3.0, and received by N3IWF from AMF 440 in step 482.

[0161] For mobility scenarios: use the fresh N3IWF key KN3IWF An Ipsec SA is established between UE 410 and the new N3IWF. This key is created in UE 410 using the uplink NAS count associated with the NAS connection identifier "Non-3GPP Access Key Refresh / Re-enter (or) N3IWF Refresh / Re-enter Identifier" 0x03 or 0x04, as follows: Figure 5 As shown, and received by N3IWF from AMF 440 in step 482.

[0162] In step 485b, when an Ipsec SA is successfully established between UE 410 and N3IWF, N3IWF should send an NGAP Initial Context Establishment Response Message to AMF 440. This message includes a 5G-GUTI, a successful handover indication for non-3GPP access UEs, and the current AP identifier (used for the latest UE location information).

[0163] In step 484a, AMF 440 can determine whether N3IWF is suitable for the selected slice as defined in Section 4.12.2.2 of TS 23.502 V18.3.0. If it is compatible with the selected N3IWF, then proceed to steps 485a-b (NAS registration acceptance case a). Otherwise, AMF 440 will proceed to alternative steps 485a-b (NAS registration rejection case b).

[0164] If AMF 440 accepts the registration, and if AMF 440 receives a successful handover indication of mobility for a non-3GPP access UE and a current AP identifier (for the latest UE location information) in step 485b, then AMF 440 stores the received information as part of the UE context.

[0165] In some embodiments, the NAS registration acceptance status, step 487a includes: when AMF 440 receives the NGAP initial context establishment response from UE 410, AMF 440 should send the NAS registration acceptance message of UE 410 to N3IWF via N2.

[0166] Step 487b includes: Upon receiving the NAS registration acceptance message from AMF 440, N3IWF should forward it to UE 410 via the established Ipsec SA. All other NAS messages between UE 410 and N3IWF should be sent via the established Ipsec SA.

[0167] In some embodiments, in the case of NAS registration rejection, step 487a includes: AMF 440 may trigger the UE policy update process and update the UE policy defined in steps 485 and 486 of Clause 4.12.2.2 of TS 23.502 V18.3.0.

[0168] Step 487b includes: AMF 440 shall send a registration rejection message to UE 410 via N3IWF, as described in step 17 of Section 4.12.2.2 of TS23.502V18.3.0. The registration rejection message is encrypted and protected for integrity, and a new 5G-GUTI is provided to UE 410.

[0169] In some embodiments, UE 410 shall decrypt and verify the integrity of the registration rejection message. If the verification is successful, UE 410 shall proceed to step 488 in section 4.12.2.2 of TS 23.502 V18.3.0 and send an integrity-protected registration request message to AMF 440 via the newly selected N3IWF.

[0170] Figure 6a The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments, generally indicated by reference numeral 600.

[0171] Signaling diagram 600 includes UE 610, Trusted Non-3GPP Access Network (TNAN) 620, AMF 640, and ASF 650. TNAN 620 includes Trusted Non-3GPP Access Point (TNAP) 622 and Trusted Non-3GPP Gateway Function (TNGF) 624.

[0172] Signaling diagram 600 illustrates the first part of a procedure that can be executed when UE 610 disconnects from and reconnects to the first TNGF 624. Signaling diagram 600 also illustrates the first part of a procedure that can be executed when UE 610 disconnects from and connects to the second TNGF 624.

[0173] In some embodiments, signaling diagram 600 illustrates TNGF 624 re-entry / refresh during UE mobility scenarios (registration / authentication / PDU session establishment / modification) - trusted non-3GPP access.

[0174] In some embodiments, the authentication process in signaling diagram 600 illustrates the TNGF 624 re-entry / refresh aspect, where UE 610 connects to a trusted non-3GPP access network (i.e., the new target TNAP 622 and the new TNGF 624) during mobility.

[0175] In some embodiments, signaling diagram 600 includes the following steps.

[0176] UE 610 selects a PLMN and a TNAN 620 for connection to that PLMN using the trusted non-3GPP access network selection procedure specified in Clause 6.3.12 of TS 23.501 V18.3.0. During this procedure, UE 610 discovers that the TNAN 620 supports a PLMN with which it has a trusted connection (e.g., a "5G connection").

[0177] In step 671, a Layer 2 connection is established between UE 610 and TNAP 622. In the case of IEEE 802.11, this step corresponds to IEEE 802.11 association. In the case of PPP, this step corresponds to PPP LCP negotiation. In other types of non-3GPP access (e.g., Ethernet), this step may not be required.

[0178] In steps 672 and 673, the EAP authentication process is initiated. The EAP message should be encapsulated into Layer 2 packets, such as IEEE 802.3 / 802.1x packets, IEEE 802.11 / 802.1x packets, PPP packets, etc. UE 610 provides a NAI, which triggers TNAP to send an AAA request to TNGF. Between TNAP and TNGF, the EAP packet is encapsulated into an AAA message.

[0179] In steps 674 to 681, the EAP-5G procedure is performed in accordance with Clause 7.2.1 of TS 23.501 V18.3.0, with the following modifications.

[0180] EAP-5G packets should not be encapsulated as IKEv2 packets. UE 610 should also include the UE ID, for example, 5G-GUTI (if obtainable from previous registrations to the same PLMN), in the AN parameters. UE 610 should include a registration request message containing UE security capabilities, UE non-3GPP access key refresh capabilities, and SUCI.

[0181] The UE non-3GPP access key refresh capability indicates that UE 610 supports one or more key refreshes (or re-entries): TNGF key refresh, N3IWF key refresh, etc.

[0182] Following successful authentication (if performed), create the k specified in Annex A.9 of TS 33.501 V18.3.0 in UE 610 and AMF 640. TNGF (equivalent to k) N3IWF In step 680a (within the N2 initial context establishment request), k TNGF Transfer from AMF640 to TNGF 624.

[0183] In some embodiments, in mobility scenarios, if the UE's non-3GPP access key refresh capability is indicated / provided by the UE610, the AMF 640 can determine to skip primary full authentication based on local policies and perform the following operations to re-enter / refresh the non-3GPP access network key:

[0184] If UE 610 uses untrusted non-3GPP access in mobility scenarios, AMF 640 retrieves the UE context and the latest k based on 5G-GUTI. AMF And derive the fresh TNGF key (k TNGF The fresh TNGF key is derived using the following input, but the access type distinguisher can use a value associated with 'TNGF refresh / re-enter'.

[0185] In some embodiments, the 'TNGF refresh / retype' process may include the following.

[0186] When the latest k message received from UE 610 and AMF 640 (either the latest NAS message received from UE 610 or a NAS message containing registration requests / PDU session establishment / modifications during UE mobility) AMF The key k is derived from the uplink NAS count. gNB k WAGF k TNGF / k TNGF kTWIF and k N3IWF / k N3IWF When doing so, the following parameters should be used to form the input S of the KDF. - FC=0x6E - P0 = Uplink NAS Count - L0 = Length of the uplink NAS count (i.e., 0x00 0x04) - P1=Access type distinguisher - L1 = Length of the access type distinguisher (i.e., 0x00 0x01) - P2 = Freshness parameter (e.g., count / random number / temporary value) - L2 = Length of the freshness parameter (i.e., 0x00 0x01)

[0187] In some embodiments, P2 and L2 can be used for additional input for 'TNGF refresh / re-typing'.

[0188] Figure 7 It is a table of access type distinguishers and values ​​according to one or more embodiments, generally indicated by reference numeral 700 in the accompanying drawings.

[0189] In some embodiments, the value of the "3GPP Access" access type distinguisher is 0x01. In some embodiments, the value of the "Non-3GPP Access" access type distinguisher is 0x02. In some embodiments, the value of the "Non-3GPP Access Key Refresh / Re-enter" access type distinguisher is 0x03. In some embodiments, the value of the "N3IWF Refresh / Re-enter" access type distinguisher is 0x03 or 0x04. In some embodiments, the value of the "TNGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "WAGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "TWIF Refresh / Re-enter" access type distinguisher is 0x03 or 0x07.

[0190] Values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and values ​​0xf1 through 0xff are reserved for private use.

[0191] In deriving k gNB When doing so, the access type distinguisher should be set to the 3GPP value (0x01). In deriving k... N3IWF k WAGF k TWIF or k TNGF At that time, the access type distinguisher should (initially) be set to a non-3GPP value (0x02).

[0192] In some embodiments, the input key KEY should be a 256-bit key. AMF .

[0193] This feature is applied when establishing encrypted 5G radio bearers and when performing dynamic key changes.

[0194] Figure 6b The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments.

[0195] Signaling diagram 605 includes UE 610, Trusted Non-3GPP Access Network (TNAN) 620, AMF 640, and ASF 650. TNAN 620 includes Trusted Non-3GPP Access Point (TNAP) 622 and Trusted Non-3GPP Gateway Function (TNGF) 624.

[0196] Signaling diagram 605 illustrates the process from... Figure 6a Signaling diagram 600 illustrates the process that begins in the first part. Signaling diagram 605 illustrates the second part of the process that can be executed when UE 610 disconnects from and reconnects to the first TNGF 624. Signaling diagram 605 also illustrates the first part of the process that can be executed when UE 610 disconnects from and connects to the second TNGF 624.

[0197] In some embodiments, signaling diagram 605 includes the following steps.

[0198] AMF 640 may instruct in the N2 message (as option 1 in step 680a (SMC), or later in step 681a) (N2 Initial Context Establishment Request) TNGF key refresh instruction / non-3GPP access key refresh instruction, freshness parameter (if used in TNGF re-entry) to inform / notify UE 610 to perform a TNGF key refresh (same as the network) via TNGF 624, thereby re-establishing security for the new 3GPP access network (through which UE 610 connects to the network).

[0199] In some embodiments, upon receiving NAS SMC Complete from UE 610 or upon successful integrity protection verification, AMF 640 initiates an NGAP procedure to establish an AN context. AMF 640 should use the uplink NAS count associated with the NAS connection identifier “0x02” in step 681a-option 2, or, in mobility scenarios, the uplink NAS count associated with the non-3GPP access key refresh / re-entry (or) TNGF refresh / re-entry identifier “0x03 or 0x05”, to calculate the fresh TNGF key k.TNGF (For UE mobility case k) TNGF (If not performed in step 680a-option 1), to establish an IPsec SA between UE 610 and (new) TNGF 624, and should be (k TNGF Together with the TNGF key refresh instruction / non-3GPP access key refresh instruction and freshness parameter (if used in TNGF key refresh) in the message, it is included in the NGAP initial context establishment request sent to TNGF 624 to inform / notify UE 610 to perform TNGF retyping (same as the network) to re-establish security for the new 3GPP access network (through which UE 610 connects to the network).

[0200] TNAP 622 is a trusted entity. TNGF 624 should generate k according to Annex A.22 of TS 33.501 V18.3.0. TNAP And in step 681e, it is transmitted from TNGF 624 to TNAP 622 (within the AAA message).

[0201] In some embodiments, in option 2, TNGF 624 may send a freshness parameter (if received from AMF 640 in the preceding steps 680a / 681a) in step 681b along with a TNGF key refresh indication / non-3GPP access key refresh indication to inform / notify UE 610 to perform TNGF re-entry (same as the network) to re-establish security for the new 3GPP access network (through which the UE connects to the network).

[0202] In step 681a, after receiving the TNGF key from AMF 640, TNGF 624 should send an EAP request / 5G notification packet containing “TNGF Contact Info” to UE 610, which includes the IP address of TNGF 624 (optionally, as in option 2) and a TNGF key refresh indication / non-3GPP access key refresh indication, freshness parameters (if received from AMF 640 in previous steps 680a / 681a). After receiving the EAP response / 5G notification packet from UE 610, TNGF 624 should send message 681e, which contains the EAP-Success packet (optionally, as in option 3) and the TNGF key refresh indication / non-3GPP access key refresh indication and freshness parameter (if received from AMF in the preceding steps 680a / 681a), to inform / notify UE 610 to perform TNGF re-entry (same as the network), thereby re-establishing security for the new 3GPP access network (through which UE 610 connects to the network).

[0203] In step 681f, after receiving the TNGF key refresh instruction / non-3GPP access key refresh instruction, UE 610 determines to perform a TNGF re-entry similar to that performed on the network. UE 610 derives the fresh TNGF key according to a network-like 'TNGF refresh / re-entry' process (as described above). The freshness parameter (if received from the TNGF) can also be used as the fresh TNGF key (KTNGF). Additional inputs derived from the derivation.

[0204] In step 682a, UE 610 and TNAP 622 use the public TNAP key (derived from the fresh TNGF key) to derive a security key according to the applied non-3GPP technology and establish a security association to protect all subsequent services. In the case of IEEE 802.11, k TNAP It uses a pair of master keys (PMK) and performs a 4-way handshake (see IEEE 802.11). This handshake establishes a security context between the WLAN AP and UE 610, which is used to protect over-the-air unicast and multicast services. From this step onwards, all messages between UE 610 and TNAP 622 are encrypted and protected for integrity.

[0205] The current procedure assumes that layer 2 cryptographic protection between UE 610 and TNAP 622 will be enabled.

[0206] In step 682b, UE 610 receives IP configuration from TNAN, for example, using DHCP.

[0207] In step 683, UE 610 should initiate an IKE_INIT exchange with TNGF. Having already received TNGF's IP address during the EAP-5G signaling in step 9b, the UE should subsequently initiate an IKE_AUTH exchange, including the same UE Id as provided in step 675 (i.e., SUCI or 5G-GUTI). Public K TIPSe Used for mutual authentication. Key K TIPSec Derived according to Annex A.22 of TS 33.501 V18.3.0. NULL encryption is negotiated according to RFC 2410. After step 683c, an IPsec SA (i.e., NWt connection) is established between UE 610 and TNGF 624 and used to transmit all subsequent NAS messages. This IPsec SA is not encrypted; only integrity protection is applied.

[0208] In step 684a, after successfully establishing the NWtp connection, TNGF 624 sends an N2 initial context establishment response message to AMF 640. This message includes a 5G-GUTI, a successful handover indication for non-3GPP access UE mobility, and the current AP identifier (for the latest UE location information).

[0209] In step 684b, AMF 640 can determine whether TNGF 624 is suitable for the selected slice as defined in Section 4.12.2.2 of TS 23.502 V18.3.0. If it is compatible with the selected TNGF 624, then proceed to steps 685a-b (NAS registration acceptance case a). Otherwise, AMF 640 will proceed to alternative steps 685a-b (NAS registration rejection case b).

[0210] If AMF 640 accepts registration, and if AMF 640 receives a successful mobility handover indication and current AP identifier (for the latest UE location information) for a non-3GPP access UE in step 684b, then AMF 640 stores the received information as part of the UE context.

[0211] NAS registration acceptance status a): 15a-b. Finally, the NAS registration acceptance message is sent by AMF 640 and forwarded to UE 610 via the established NWt connection.

[0212] UE 610 initiates PDU session establishment. This is done entirely in accordance with Clause 4.12a.5 of TS 23.502 V18.3.0. TNGF 624 can establish one or more IPSec subSAs for each PDU session.

[0213] User plane data for established PDU sessions is transmitted between UE 610 and TNGF624 within the established IPSec sub-SA.

[0214] NAS registration rejection case b): In steps 685a-b, AMF 640 may trigger the UE policy update process and update the UE policy as defined in steps 687 and 688 of Section 4.12a.2.2 of TS 23.502 V18.3.0.

[0215] AMF 640 shall send a registration rejection message to UE 610 via TNGF 624, as described in steps 689 to 691 of section 4.12a.2.2 of TS 23.502 V18.3.0. The registration rejection message is encrypted and protected for integrity, and a new 5G-GUTI is provided to UE 610.

[0216] UE 610 should decrypt and verify the integrity of the registration rejection message. If the verification is successful, UE 610 proceeds to step 691 in section 4.12.2.2 of TS 23.502 V18.3.0 and sends an integrity-protected registration request message to AMF 610 via the newly selected TNGF 624.

[0217] In some embodiments, the N5CW device does not support NAS with non-3GPP access, for k TWIF During key generation, the uplink NAS count should be set to 0, see section 7A.2.4. Similarly, AUN3 devices do not support NAS accessed outside of 3GPP, for k WAGF For key generation, the uplink NAS count should be set to 0, see Section 7B.7.3.

[0218] Figure 8a The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments, generally indicated by reference numeral 800.

[0219] Signaling diagram 800 includes a non-5G WLAN (N5CW) device 810, a trusted WLAN access network 820, an AMF / SEAF 840, an AUSF 850, and a unified data management (UDM) 860. The trusted WLAN access network 820 includes a trusted WLAN access point 822 and a trusted WLAN interoperability function (TWIF) 824.

[0220] Signaling diagram 800 illustrates the first part of a process that can be executed when the N5CW device 810 disconnects from and reconnects to the first TWIF 824. Signaling diagram 800 also illustrates the first part of a process that can be executed when the N5CW device 810 disconnects from and connects to the second TWIF 824.

[0221] In some embodiments, signaling diagram 800 illustrates TWIF 824 re-entry / refresh during UE mobility scenarios (registration / authentication / PDU session establishment / modification) - trusted non-3GPP access.

[0222] The N5CW device 810 may be a 5GC NAS device that does not support WLAN. In some embodiments, signaling diagram 800 illustrates the mobility of the N5CW device 810 with trusted non-3GPP access.

[0223] The N5CW device 810 can register to the 5GC using 3GPP credentials and establish a 5GC connection via the trusted WLAN access network 822. The TWIF 824 provides interoperability, enabling the connection to the 5GC, implementing the NAS protocol stack, and exchanging NAS messages with the AMF / SEAF 840 on behalf of the N5CW device 810.

[0224] In some embodiments, the N5CW device 810 provides functionality similar to that of UE 410 or UE 610 described above with respect to Figures 4 and 6, respectively. In some embodiments, the TWIF 824 provides functionality similar to that of TNGF 424 or TNGF 624 described above with respect to Figures 4 and 6, respectively.

[0225] In some embodiments, signaling diagram 800 illustrates a TWIF key refresh process during (re)authentication of a device that does not support 5GC NAS access via WLAN.

[0226] In some embodiments, signaling diagram 800 includes the following steps.

[0227] In step 870, the N5CW device 810 selects a PLMN and a trusted WLAN that supports “NAS-free 5G connectivity” to that PLMN.

[0228] Steps 871 to 880 illustrate the initial registration / registration update resulting from mobility to 5GC.

[0229] In step 871, the N5CW device 810 is associated with a trusted WLAN network, and the EAP-AKA authentication process is initiated.

[0230] In step 872, the N5CW device 810 should provide its Network Access Identity (NAI). The Trusted WLAN Access Point (TWAP) 822 selects a Trusted WLAN Interoperability Function (TWIF) 824, for example, based on the received domain, and sends an AAA request to the selected TWIF 824.

[0231] If the N5CW device 810 is first registered with the 5GC via 3GPP access when the above process is initiated, then the NAI should include the SUCI. The SUCI should be constructed in accordance with the provisions of Clause 6.12.2.

[0232] If the N5CW device 810 has already registered with the 5GC via 3GPP access when the above process is initiated, the NAI includes the 5G-GUTI assigned to the N5CW device 810 via 3GPP access. This enables the TWIF 824 to select the same AMF 840 as the AMF serving the N5CW device 810 via 3GPP access in step 874a below.

[0233] If the N5CW device 810 has already registered with the 5GC (previously) via non-3GPP access, and if it is related to a mobility scenario, then when the above process is initiated, the NAI includes the 5G-GUTI assigned to the N5CW device 810 via 3GPP access. This allows TWIF 824 to select the same AMF 840 as the AMF serving the N5CW device 810 via 3GPP access in step 874a below. UE non-3GPP access key refresh capability and SUCI.

[0234] The UE non-3GPP access key refresh capability indicates that the UE supports one or more key refreshes (or re-entries): TNGF key refresh, N3IWF key refresh, TWIF key refresh, etc.

[0235] In step 873, TWIF 824 should create a 5GC registration request message on behalf of N5CW device 810. TWIF 824 should populate the parameters in the registration request message with default values, which are the same for all N5CW devices that do not support 5G NAS, and additionally, it includes UE non-3GPP access key refresh capability (if provided by the UE). The registration type indicates "Initial Registration" or "Register for Mobility Update".

[0236] In steps 874a-874b, TWIF 824 should select AMF 840 (e.g., if provided by N5CW device 810, by using 5G-GUTI in NAI) and should send an N2 message to AMF 840, which includes a registration request, user location, UE non-3GPP access key refresh capability, and AN type.

[0237] In 875a-875b, if the authentication process is triggered by the AMF 840, it can perform primary authentication for the UE 810 by interacting with the AMF 850 ​​and UDM 860. The AMF 840 can also initiate primary authentication even if it already has a security context identified by the 5G-GUTI.

[0238] In this case, steps 875 and 876 are skipped. Alternatively, in mobility scenarios, if the UE 810's non-3GPP access key refresh capability (with a TWIF key refresh support indication) is received by the AMF 840, the AMF 840 can determine to skip primary full authentication based on local policies and perform the following actions to re-enter / refresh the non-3GPP access network key:

[0239] If the N5CW 810 uses trusted non-3GPP access in mobility scenarios, the AMF 840 retrieves the UE context and the latest k based on 5G-GUTI. AMF And derive the fresh TWIF key (k TWIF A fresh TWIF key is derived using the following input, but the access type distinguisher can use a value associated with 'TWIF refresh / re-enter'.

[0240] In some embodiments, the 'TWIF refresh / re-entry' procedure includes the following. When the latest k (the most recent NAS message received from the UE or the NAS message containing registration requests / PDU session establishment / modifications during UE mobility) is received from the UE 810 and AMF840, it is refreshed. AMF The key k is derived from the uplink NAS count. gNB k WAGF k TNGF / k TNGF k TWIF / k TWIF and k N3IWF / k N3IWF When doing so, the following parameters should be used to form the input S of the KDF. - FC=0x6E - P0 = Uplink NAS Count - L0 = Length of the uplink NAS count (i.e., 0x00 0x04) - P1=Access type distinguisher - L1 = Length of the access type distinguisher (i.e., 0x00 0x01) - P2 = Freshness parameter (e.g., count / random number / temporary value) - L2 = Length of the freshness parameter (i.e., 0x00 0x01)

[0241] In some embodiments, P2 and L2 should be used as additional inputs for 'TWIF refresh / re-enter' because using NAS count '0' as the default value for the N5CW device does not guarantee uniqueness / freshness.

[0242] Figure 9 It is a table of access type distinguishers and values ​​according to one or more embodiments, generally indicated by reference numeral 900 in the drawings.

[0243] In some embodiments, the value of the "3GPP Access" access type distinguisher is 0x01. In some embodiments, the value of the "Non-3GPP Access" access type distinguisher is 0x02. In some embodiments, the value of the "Non-3GPP Access Key Refresh / Re-enter" access type distinguisher is 0x03. In some embodiments, the value of the "N3IWF Refresh / Re-enter" access type distinguisher is 0x03 or 0x04. In some embodiments, the value of the "TNGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "WAGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "TWIF Refresh / Re-enter" access type distinguisher is 0x03 or 0x07.

[0244] Values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and values ​​0xf1 through 0xff are reserved for private use.

[0245] In deriving k gNB When doing so, the access type distinguisher should be set to the 3GPP value (0x01). In deriving k... N3IWF k WAGF k TWIF or k TNGF At that time, the access type distinguisher should (initially) be set to a non-3GPP value (0x02).

[0246] In some embodiments, the input key KEY should be a 256-bit key. AMF .

[0247] This feature is applied when establishing encrypted 5G radio bearers and when performing dynamic key changes.

[0248] Back Figure 8aThe AMF 840 can instruct in the N2 message (as option 1 in step 880a (SMC) or later in step 881a (N2 Initial Context Establishment Request) TNGF key refresh instruction / non-3GPP access key refresh instruction, freshness parameter (if used in TNGF key renewal) to inform / notify the UE (via TNGF) to perform TNGF re-entry (same as the network), thereby re-establishing security for the new 3GPP access network (through which the UE connects to the network).

[0249] In step 876, similar to an unauthenticated emergency call, NAS security is established between the AMF 840 and TWIF 824 using NULL encryption and NULL integrity protection.

[0250] The N5CW device does not support NAS; therefore, it is not possible to use a NAS counter on the N5CW device.

[0251] In step 877, AMF 840 should send a NAS secure mode command to TWIF 824. The NAS secure mode command should include an EAP-Success message and a NULL security algorithm.

[0252] Figure 8b The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments, generally indicated by reference numeral 805.

[0253] Signaling diagram 805 includes a non-5G WLAN (N5CW) device 810, a trusted WLAN access network 820, an AMF / SEAF 840, an AUSF 850, and a unified data management (UDM) 860. The trusted WLAN access network 820 includes a trusted WLAN access point 822 and a trusted WLAN interoperability function (TWIF) 824.

[0254] Signaling diagram 805 illustrates the process from... Figure 8a Signaling diagram 800 illustrates the process that begins in the first part. Signaling diagram 805 illustrates the second part of the process that can be executed when the N5CW device 810 disconnects from and reconnects to the first TWIF 824. Signaling diagram 800 illustrates the second part of the process that can be executed when the N5CW device 810 disconnects from and connects to the second TWIF 824.

[0255] In some embodiments, signaling diagram 805 includes the following steps.

[0256] In step 878a, TWIF 824 should not directly forward the EAP-Success message to N5CW, but should instead store the EAP-Success message and wait for fresh data. TWIF .

[0257] In step 878b, TWIF 824 should send a NAS security mode completion message to AMF 840.

[0258] In step 879, AMF 840 sends an N2 initial context establishment request and provides fresh K to TWIF 824. TWIF Key (K) TWIF ), TNGF key refresh indicator / non-3GPP access key refresh indicator, freshness parameter (used for fresh TWIF generation).

[0259] In steps 880a to 880c, TWIF 824 should be from k TNGF Derivation of TNAP key k TNAP The TNAP key, EAP-Success message, TNGF key refresh indication / non-3GPP access key refresh indication, and freshness parameter are sent to a trusted WLAN access point, which then forwards the EAP-Success message to the N5CW device 810.

[0260] In step 881, after receiving a TWIF key refresh instruction / non-3GPP access key refresh instruction, the N5CW device 810 determines to perform a network-like TWIF re-entry. The UE derives the fresh TWIF key according to a network-like 'TWIF refresh / re-entry' process (as described above). A freshness parameter (if received from TWIF) can also be used as the fresh TWIF key (k). TWIF Additional inputs derived from the derivation.

[0261] In steps 882a to 882b, the TNAP key (derived from the fresh TWIF key) corresponds to the PMK (Pair Master Key), which is used to protect WLAN air interface communications according to IEEE 802.11. A Layer 2 or Layer 3 connection is established between the trusted WLAN access point 822 and TWIF 824 to transmit all user plane services of the N5CW device 810 to TWIF 824. This connection is later bound to an N3 connection created for the N5CW device 810.

[0262] In step 883, TWIF should send an N2 Initial Context Establishment Response message to AMF 840, which includes a 5G-GUTI, a successful mobility handover indication for non-3GPP access UE / N5CW device 810, and a current AP identifier (for the latest N5CW location information).

[0263] In step 884, AMF 840 can determine whether the TNGF is suitable for the selected slice as defined in Section 4.12.2.2 of TS 23.502 V18.3.0. If it is compatible with the selected TNGF, the process continues (NAS registration acceptance case a). Otherwise, AMF 840 proceeds to the alternative steps (NAS registration rejection case b).

[0264] If AMF 840 accepts registration, and if AMF 840 receives a successful mobility handover indication and current AP identifier (for the latest UE location information) from a non-3GPP access UE / N5CW device 810 in step 884, then AMF 840 stores the received information as part of the UE / N5CW device 810 context.

[0265] Figure 10 The diagram illustrates a signaling diagram for non-3GPP access authentication according to one or more embodiments, generally indicated by reference numeral 1000.

[0266] Signaling diagram 1000 includes a fifth-generation residential gateway (5G-RG) 1010, a wired access gateway function 1020, an AMF 1040, and an AUSF 1050.

[0267] Signaling diagram 1000 illustrates the procedures that can be performed when the 5G-RG 1010 disconnects from and reconnects to the first W-AGF 1020. Signaling diagram 1000 also illustrates the procedures that can be performed when the 5G-RG disconnects from and connects to the second W-AGF 1020.

[0268] To support the convergence of wireless and wired networks for 5G systems, two new network entities have been introduced: the 5G-RG 1010 and the Fixed Network Residential Gateway (FN-RG).

[0269] The 5G-RG 1010 acts as a 5G UE and can connect to the 5GC via a wired access network (W-5GAN) or fixed radio access (FWA). The 5G-RG 1010 also acts as an endpoint of the N1 and provides NAS signaling connectivity to the 5GC on behalf of the authentic non-3GPP (AUN3) devices behind the 5G-RG 1010.

[0270] The FN-RG can connect to the 5GC via the wired access network (W-5GAN). The W-AGF 1020 performs the registration process on behalf of the FN-RG. It acts as an endpoint of N1 and provides NAS signaling connectivity to the 5GC on behalf of the FN-RG.

[0271] 5G-enabled UEs can connect to the 5GC via the RG, and the RG connects to the 5GC via the wired access network (W-5GAN) or NG-RAN. UEs support untrusted non-3GPP access and / or trusted non-3GPP access.

[0272] From 5GC's perspective, 5G-RG 1010 is a UE, therefore it should be certified using the authentication framework defined in 3GPP. In the case of 5G-RG mobility, it can be done as follows: Figure 10 The following process adjustments are performed to support W-AGF keys (k WAGF Re-enter / refresh.

[0273] In some embodiments, signaling diagram 1000 includes the following steps.

[0274] In step 1071, the 5G-RG 1010 establishes a wired access control plane (W-CP) connection with the wired 5G access network (W-5GAN).

[0275] In step 1072, the 5G-RG 1010 should use the W-CP protocol stack to send a message containing a registration message, which includes UE security capabilities, UE non-3GPP access key refresh capabilities, and SUCI.

[0276] If a security context is available, the 5G-RG 1010 should perform integrity protection on the registration request message and should send 5G-GUTI instead of SUCI. If the 5G-RG 1010 has already registered to the same AMF 1040 via the Next Generation Random Access Network (NG RAN), and if this is the first time the 5G-RG 1010 has connected to the 5GC via W-5GAN, the corresponding UL NAS count used for integrity verification is 0; otherwise, it can use existing non-3GPP specific UL NAS counts for integrity protection.

[0277] The UE non-3GPP access key refresh capability indicates that the UE supports one or more key refreshes (or re-entries): TNGF key refresh, N3IWF key refresh, TWIF key refresh, W-AGF key refresh, etc.

[0278] In some embodiments, the 5G-RG 1010 can transmit W-AGF key refresh / re-entry capability instead of UE non-3GPP access key refresh capability.

[0279] In this process, the #UE non-3GPP access key refresh capability can also be referred to as W-AGF key refresh / re-entry capability or 5G-RG mobility support capability.

[0280] Since 5G-RG 1010 will not use non-3GPP access, and in order to avoid creating a new security context category, non-3GPP specific security context is used to refer to the security context of using 5G-RG 010 via wired access.

[0281] In steps 1073a to 1073b, W-AGF 1020 shall select AMF 1040 in accordance with TS 23.316. Then, W-AGF 1020 shall forward the registration request received from the UE to the selected AMF 1040 within the N2 initial UE message.

[0282] In step 1074, the AMF 1040 receives the 5G-GUTI and registers that it is protected by integrity, and it can use the security context to verify the integrity protection.

[0283] If the AMF 1040 has a usable UE context, i.e., k related to 5G-GUTI AMF If so, the AMF 1040 can determine to skip master authentication and determine to refresh / re-enter the W-AGF key.

[0284] In step 1074, AMF 1040 should send a Security Mode Command (SMC) to the UE (e.g., 5G-RG 1010) to activate NAS security associated with the NAS connection identifier “0x02”. This message is first sent to W-AGF 1020 (within the N2 message). If EAP-AKA’ is used for authentication, AMF 1040 should encapsulate the EAP-Success received from AUSF 1050 within the SMC message.

[0285] In step 1076, W-AGF 1020 should forward the NAS SMC to 5G-RG 1010.

[0286] In step 1077, W-AGF 1020 should forward the NAS packet containing NAS SMC Complete to AMF 1040 via the N2 interface.

[0287] In step 1078, upon receiving NAS SMC Complete (5G-RG 1010) from the UE or upon successful integrity protection verification, the AMF 1040 initiates an NGAP procedure to establish an AN context. The AMF 1040 should use the uplink NAS count associated with the NAS connection identifier “0x02” and / or use the following add-in adaptive method to calculate the fresh W-AGF1020 key k. WAGF This key is equivalent to the fresh key k. N3IWF .

[0288] If the 5G-RG 1010 uses wired access, i.e., connects to the 5G core via the WAGF 1020 during mobility scenarios, then the AMF 1040 retrieves the UE context and the latest k based on the 5G-GUTI. AMF And derive the fresh WAGF key (k WAGF The fresh WAGF key is derived using the following input, but the access type distinguisher can use a value associated with 'WAGF refresh / re-enter'.

[0289] In some embodiments, the 'WAGF refresh / retype' process may involve the following.

[0290] When the latest k from the UE and AMF 1040 (the most recent NAS message received from the UE or the NAS message containing the registration request / PDU session establishment / modification during UE mobility) AMF The key k is derived from the uplink NAS count. gNB k WAGF / k WAGF k TNGF / k TNGF k TWIF / k TWIF and k N3IWF / k N3IWF When doing so, the following parameters should be used to form the input S of the KDF. - FC=0x6E - P0 = Uplink NAS Count - L0 = Length of the uplink NAS count (i.e., 0x00 0x04) - P1=Access type distinguisher - L1 = Length of the access type distinguisher (i.e., 0x00 0x01) - P2 = Freshness parameter (e.g., count / random number / temporary value) - L2 = Length of the freshness parameter (i.e., 0x00 0x01)

[0291] P2 and L2 can be used for additional input for 'WAGF refresh / retype'.

[0292] Figure 11 It is a table of access type distinguishers and values ​​according to one or more embodiments, generally indicated by reference numeral 1100 in the accompanying drawings.

[0293] In some embodiments, the value of the "3GPP Access" access type distinguisher is 0x01. In some embodiments, the value of the "Non-3GPP Access" access type distinguisher is 0x02. In some embodiments, the value of the "Non-3GPP Access Key Refresh / Re-enter" access type distinguisher is 0x03. In some embodiments, the value of the "N3IWF Refresh / Re-enter" access type distinguisher is 0x03 or 0x04. In some embodiments, the value of the "TNGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "WAGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "TWIF Refresh / Re-enter" access type distinguisher is 0x03 or 0x07.

[0294] Values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and values ​​0xf1 through 0xff are reserved for private use.

[0295] In deriving k gNB When doing so, the access type distinguisher should be set to the 3GPP value (0x01). In deriving k... N3IWF k WAGF k TWIF or k TNGF At that time, the access type distinguisher should (initially) be set to a non-3GPP value (0x02).

[0296] In some embodiments, the input key KEY should be a 256-bit key. AMF .

[0297] This feature is applied when establishing encrypted 5G radio bearers and when performing dynamic key changes.

[0298] return Figure 10In steps 1079a to 1079b, upon receiving the completion notification of NAS security mode, AMF 1040 should send an N2 Initial Context Establishment Request message, along with a WAGF key refresh indication / non-3GPP access key refresh indication, and a freshness parameter (if used for WAGF re-entry), to W-AGF 1020 to re-establish security for wired access to the network. This message includes the freshness parameter. WAGF In addition, the WAGF 1020 can forward the WAGF key refresh instruction / non-3GPP access key refresh instruction and freshness parameters (if used in WAGF re-entry) to the 5G-RG 1010.

[0299] In step 1080, after receiving the WAGF key refresh instruction / non-3GPP access key refresh instruction, the 5G-RG 1010 device determines to perform a network-like WAGF re-entry. The 5G-RG UE 1080 derives the fresh WAGF key according to the description of the network-like 'WAGF refresh / re-entry' process (as described above). A freshness parameter (if received) can also be used as the fresh WAGF key (k). WAGF Additional inputs derived from this.

[0300] In step 1081, a secure connection is established between the 5G-RG 1010s using the fresh WAGF key.

[0301] In steps 1082 to 1083, W-AGF 1020 sends an N2 Initial Context Response message to AMF 1040. This message includes a 5G-GUTI, a successful mobility handover indication for the non-3GPP access UE / 5G-RG 1010 device, and a current AP identifier (used for the latest 5G-RG location information). AMF 1040 stores the received current AP identifier (used for the latest 5G-RG 1010 location information) along with the 5G-GUTI as part of the UE context.

[0302] Upon receiving the NAS registration acceptance message from AMF 1040, W-AGF 1020 should forward it to 5G-RG 1010 via the established W-CP. All other NAS messages between UE 1010 and W-AGF 1020 should be sent via the established W-CP.

[0303] If FN RG is involved instead of 5G-RG 1010, the above process can be reused in mobility scenarios if the primary authentication is performed during initial registration; otherwise, it may not be feasible.

[0304] Figure 12aThe diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments, generally indicated by reference numeral 1200.

[0305] Signaling diagram 1200 includes user equipment (UE) 1210, trusted non-3GPP access network 1220, and AMF 1240. Trusted non-3GPP access network 1220 includes a first trusted non-3GPP access point (TNAP 1) 1222, a second trusted non-3GPP access point (TNAP2) 1223, and a trusted non-3GPP gateway function (TNGF) 1223.

[0306] Signaling diagram 1200 illustrates the first part of a method for refreshing a non-3GPP access network key during the UE 1210 mobility security re-establishment process.

[0307] Signaling diagram 1200 illustrates how the non-3GPP access key (TNGF key in the case of trusted non-3GPP access / N3IWF key in the case of untrusted non-3GPP access) can be retrieved from the AMF (which manages the UE security context) during UE mobility scenarios.

[0308] In some embodiments, signaling diagram 1200 includes the following steps.

[0309] In step 1271, UE 1210 establishes a Layer 2 (L2) connection with TNAP2 1223.

[0310] In step 1272, TNAP 2 (in a new mobility domain / belonging to a different TNGF) typically initiates an EAP session by requesting UE identity.

[0311] In step 1273, UE 1210 provides a Network Access Identifier (NAI), which contains Username=Reauth-ID and Domain=nai.5gc.tngf <tngf-id>.mnc <mnc>.mcc <mcc>.3gppnetwork.org and UE non-3GPP access key refresh capability. Reauth-ID and TNGF-ID are received when UE 1219 first connects to TNGF 1224, for example, through initial registration via TNGF 1224. UE 1210 provides username=Reauth-ID, 5G-GUTI and UE non-3GPP access key refresh capability because UE 1210 does not want to initiate NAS signaling with 5GC, but due to the different mobility domain, UE 1210 may need to refresh the security key in order to securely (re)establish with the new non-3GPP access network (the new TNAP (TNAP2 1223) and the new target TNGF 1224).

[0312] When UE 1210 performs initial registration via TNGF 1224, the UE 1210 context (e.g., TNGF key, UEID) is created / provided in TNGF 1224.

[0313] The UE non-3GPP access key refresh capability indicates that UE 1210 supports one or more key refreshes (or re-entries): TNGF key refresh, N3IWF key refresh, TWIF key refresh, W-AGF key refresh, etc.

[0314] As an option, 5G-GUTI can be sent as NAI and Re-auth ID (which may include TNGF ID, MCC, MNC).

[0315] In some embodiments, if TNGF 1224 provides a Re-auth ID during registration, UE 1210 may provide the received Re-auth in step 1271.

[0316] In some embodiments, in step 1273, UE 1210 may send UE non-3GPP access key refresh capability within a registration request message in the NAS PDU, and then TNAP2 1223 may forward it to TNGF1224 in step 1274, and TNGF 1224 may forward it to AMF 1240 in step 1276a.

[0317] In steps 1274a to 1274b, TNAP1 1222 selects TNGF 1224 in the receive domain (based on TNG1-ID; if TNGF 1224 is not found, TNAP2 1223 can select the TNGF 1223 connected to it to ultimately connect to the 5G core or 3GPP system), and forwards the NAI, 5G-GUTI, and the received UE non-3GPP access key refresh capability to TNGF 12204 in the AAA. Furthermore, TNAP2 1223 also includes its TNAP ID in TNGF 1224.

[0318] In step 1275, TNGF 1224 discovers that UE 1210 cannot be identified by the received Reauth-ID, and that no UE context / security context exists for UE 1210. Therefore, it determines that the security context needs to be retrieved from AMF 1240 based on 5G-GUTI.

[0319] Figure 12b The diagram illustrates a signaling diagram for trusted non-3GPP access authentication according to one or more embodiments, generally indicated by reference numeral 1205.

[0320] Signaling diagram 1205 includes user equipment (UE) 1210, trusted non-3GPP access network 1220, and AMF 1240. Trusted non-3GPP access network 1220 includes a first trusted non-3GPP access point (TNAP 1) 1222, a second trusted non-3GPP access point (TNAP2) 1223, and a trusted non-3GPP gateway function (TNGF) 1223.

[0321] Signaling diagram 1205 illustrates the process from... Figure 12a The first part of the process is shown in signaling diagram 1200. Signaling diagram 1205 illustrates the second part of the method for refreshing the non-3GPP access network key during the UE 1210 mobility security re-establishment process.

[0322] In some embodiments, signaling diagram 1205 includes the following steps.

[0323] In step 1276a, AMF 1240 is selected based on 5G-GUTI, and a key request message (in any N2 message) is sent along with 5G-GUTI, and a NAS PDU (containing a registration request) is received from UE 1210.

[0324] In step 1276b, AMF 1240 retrieves the UE context (i.e., the AMF key KAMF) based on 5G-GUTI, and derives the fresh TNGF key (e.g., k) in the following manner. TNGF ).

[0325] In some embodiments, in mobility scenarios, if the UE's non-3GPP access key refresh capability is indicated / provided by UE1210, AMF 1240 can determine to skip primary full authentication based on local policies and perform the following to re-enter / refresh the non-3GPP access network key:

[0326] If UE 1210 uses untrusted non-3GPP access in mobility scenarios, then based on 5G-GUTI, AMF1240 retrieves the UE context and the latest k AMF And derive the fresh TNGF key (k TNGF The fresh TNGF key is derived using the following input, but the access type distinguisher can use a value associated with 'TNGF refresh / re-enter'.

[0327] In some embodiments, the 'TNGF refresh / retype' process may include the following.

[0328] When the latest k message received from UE 1210 and AMF 1240 (either the latest NAS message received from the UE or a NAS message containing registration requests / PDU session establishment / modifications during UE mobility) AMF The key k is derived from the uplink NAS count. gNB k WAGF k TNGF / k TNGF k TWIF and k N3IWF / k N3IWF When using this method, the following parameters should be used to form the input S of the key distribution function (KDF). - FC=0x6E - P0 = Uplink NAS Count - L0 = Length of the uplink NAS count (i.e., 0x00 0x04) - P1=Access type distinguisher - L1 = Length of the access type distinguisher (i.e., 0x00 0x01) - P2 = Freshness parameter (e.g., count / random number / temporary value) - L2 = Length of the freshness parameter (i.e., 0x00 0x01)

[0329] P2 and L2 can be used for additional input in 'TNGF refresh / retype'.

[0330] Figure 13 It is a table of access type distinguishers and values ​​according to one or more embodiments, generally indicated by reference numeral 1300 in the accompanying drawings.

[0331] In some embodiments, the value of the "3GPP Access" access type distinguisher is 0x01. In some embodiments, the value of the "Non-3GPP Access" access type distinguisher is 0x02. In some embodiments, the value of the "Non-3GPP Access Key Refresh / Re-enter" access type distinguisher is 0x03. In some embodiments, the value of the "N3IWF Refresh / Re-enter" access type distinguisher is 0x03 or 0x04. In some embodiments, the value of the "TNGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "WAGF Refresh / Re-enter" access type distinguisher is 0x03 or 0x05. In some embodiments, the value of the "TWIF Refresh / Re-enter" access type distinguisher is 0x03 or 0x07.

[0332] Values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and values ​​0xf1 through 0xff are reserved for private use.

[0333] In deriving k gNB When doing so, the access type distinguisher should be set to the 3GPP value (0x01). In deriving k... N3IWF k WAGF k TWIF or k TNGF At that time, the access type distinguisher should (initially) be set to a non-3GPP value (0x02).

[0334] In some embodiments, the input key KEY should be a 256-bit key. AMF .

[0335] This feature is applied when establishing encrypted 5G radio bearers and when performing dynamic key changes.

[0336] In step 1276c, AMF 1240 sends an N2 Initial Context Establishment Request (or in any N2 message / key response message), a fresh TNGF key (K TNGF ), and may include a TNGF key refresh indication (if the TNGF key is refreshed at the AMF level), a freshness parameter (if used for K) TNGF generate).

[0337] In step 1277, TNGF 1224 stores the received K TNGF TNGF 1224 can derive new Re-auth IDs (which are outside the scope of this document), new TNAP keys, and store them.

[0338] In steps 1278a to 1278b, TNGF 1224 completes the EAP-5G session by sending an EAP-Success packet, a TNGF key refresh indication and freshness parameter to the UE, and sending a new TNAP key to TNAP2 1223.

[0339] In step 1279, after receiving the TNGF key refresh indication / non-3GPP access key refresh indication, UE 1210 determines to perform a network-like TNGF re-entry. UE 1210 derives the fresh TNGF key as described in the network-like 'TNGF refresh / re-entry' procedure (as described above). The freshness parameter (if received from TNGF 1224) can also be used as the fresh TNGF key (k). TNGF Additional inputs derived from the new TNGF key. Furthermore, UE 1210 derives the TNAP key from the new TNGF key.

[0340] In steps 1280a to 1280b, a new TNAP key is applied to establish over-the-air security between UE 1210 and TNAP2 1223. If necessary, UE 1210 may receive new IP configuration information (e.g., a new IP address).

[0341] In step 1281, UE 1210 resumes communication with the new TNGF 1224 via TNAP2 1223.

[0342] In step 1282, TNGF 1224 sends an N2 initial context establishment update / response message with the UE ID (e.g., 5G-GUTI) and the current new TNAP identifier (or in any N2 message, sends information to update AMF 1240 using the current location information of UE 1210).

[0343] The AMF 1240 uses the current service TNAP identifier to update the UE location information / UE context.

[0344] AMF 1240 sends an N2 Initial Context Establishment Update Acknowledgment / Response Message with a success / acknowledgment indication to TNGF 1224 (in any N2 message).

[0345] In some embodiments, if an AP is involved instead of TNAP 1222 / 1223 and N3IWF is involved instead of TNGF1224, the steps described above can replace all TNGF keys with N3IWF keys for use in UE mobility to untrusted non-3GPP access scenarios.

[0346] In some embodiments, if a trusted WLAN AP is involved instead of TNAP 1222 / 1223 and TWIF is involved instead of TNGF 1224, the steps described above can replace all TNGF keys with TWIF keys to apply to mobility of N5CW devices (with 3GPP credentials but no NAS) in trusted non-3GPP access scenarios.

[0347] In some embodiments, if W-AGF is involved instead of TNGF 1224, the steps described above can replace all TNGF keys with W-AGF keys to apply to 5G-RG mobility in wired access scenarios.

[0348] In one aspect, a user equipment (UE) for wireless communication includes: at least one memory; and at least one processor coupled to the at least one memory and configured such that the UE: establishes a first secure connection with an Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; send a first message to the AMF via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, which establishes a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; receive a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF Derive the second key.

[0349] Such user equipment (UE) enables the Access and Mobility Management (AM) functions to instruct the UE to derive a second key for establishing a second secure connection with the AMF via a second non-3GPP access network. This arrangement offers the following advantages: during UE mobility registration involving changes to the non-3GPP access network or UE mobility security re-establishment, the AMF is not required to perform an additional full master authentication operation. This typically reduces signaling overhead between the UE and the mobile network. It also typically reduces latency in establishing the connection between the UE and the mobile network.

[0350] User equipment can be a remote unit. User equipment can be a remote device. User equipment can be a wireless communication device. User equipment can be a mobile device. User equipment can be a mobile phone. User equipment can be a non-5G wireless local area network (WLAN) (N5CW) device. User equipment can be a 5G residential gateway (5G-RG) device. User equipment can be a fixed network residential gateway (FN-RG) device.

[0351] Access and mobility management functions can be part of a mobile communication network. The mobile communication network can be a 3GPP mobile communication network. A 3GPP mobile communication network is defined by 3GPP standards. The mobile communication network can also be a 5G network.

[0352] Mobile communication networks may also include an authentication server function (AUSF).

[0353] The first non-3GPP access network can be any type of access network that is not based on the 3rd Generation Partnership Project (3GPP) standards or protocols. The first non-3GPP access network can be a Wi-Fi access network. The first non-3GPP access network can be a fixed-line network. The first non-3GPP access network can be a satellite network. The first non-3GPP access network can be a Bluetooth network. The first non-3GPP access network can be an Ethernet LAN.

[0354] User equipment (UE) can connect to a first non-3GPP access network. UE can establish a secure connection with the first non-3GPP access network. UE can select a first non-3GPP interoperability function (N3IWF). The first N3IWF facilitates interoperability and communication between the mobile communication network and the first non-3GPP access network. The first non-3GPP interoperability function can be part of a fifth-generation 5G network (e.g., a 5G Public Land Mobile Network (PLMN)). The first N3IWF facilitates interoperability and communication between the 5G network and the first non-3GPP access network.

[0355] The first non-3GPP access network may include a first non-3GPP access point. The first non-3GPP access network may include a first non-3GPP gateway function.

[0356] The first non-3GPP access network can be a first trusted non-3GPP access network (TNAN). The first TNAN may include a first trusted non-3GPP access point (TNAP). The first TNAN may include a first trusted non-3GPP gateway function (TNGF). The first non-3GPP access network can also be a first untrusted non-3GPP access network. The first untrusted non-3GPP access network may include a first untrusted non-3GPP gateway function.

[0357] The first secure connection can be an Internet Protocol Security (IPsec) Security Association (SA). The first secure connection can include an IPsec Security Association (SA) between the user equipment and a first non-3GPP access network.

[0358] The first key can be the first trusted non-3GPP gateway function TNGF key k. TNGF The first key can be the first non-3GPP access interoperability function N3IWF key. The first key can be the first trusted wireless LAN interoperability function TWIF key. The first key can be the first wired access gateway function W-AGF key.

[0359] AMF key k AMF It can be a 256-bit AMF key k A MF .

[0360] The UE can have the AMF key k AMF Access. The UE can be provided with an AMF key k AMF The UE can derive the AMF key k. AMF .

[0361] AMF can have a key k for AMF. AMF Access. AMF can derive the AMF key k. AMF AMF can be provided with an AMF key k. AMF The AMF can be derived from the Security Anchor Function Key KSEAF received from the Authentication Server Function (AUSF). This key can be provided with the AMF key k from the Security Anchor Function SEAF. AMF .

[0362] AMF can derive a first key from AMF key k. AMF can send the first key to the first non-3GPP access network. AMF can derive a second key from AMF key k. AMF can send the second key to the first non-3GPP access network.

[0363] The first message can be a registration request message. The first message can be a registration update request message. The first message can be a mobility registration update request message.

[0364] The second key can be different from the first key. The second key can be a refresh of the first key. The second key can be a re-entry of the first key. The second key can be derived from the same AMF key k as the first key. AMF The derivation of the second key can include the same process as the derivation of the first key.

[0365] The second key can be a second trusted non-3GPP gateway function TNGF key k. TNGF The second key can be a second non-3GPP access interoperability function (N3IWF) key. The second key can be a second trusted wireless LAN (WLAN) interoperability function (TWIF) key. The second key can be a second wired access gateway function (W-AGF) key.

[0366] A second non-3GPP access network can be any type of access network that is not based on the 3GPP (3rd Generation Partnership Project) standards or protocols. A second non-3GPP access network can be a Wi-Fi access network. A second non-3GPP access network can be a fixed-line network. A second non-3GPP access network can be a satellite network. A second non-3GPP access network can be a Bluetooth network. A second non-3GPP access network can be an Ethernet LAN.

[0367] User equipment (UE) can connect to a second non-3GPP access network. UE can establish a secure connection with the second non-3GPP access network. UE can select a second non-3GPP interoperability function (N3IWF). The second N3IWF can be the same as the first N3IWF. The second N3IWF can be part of a mobile communication network. The second N3IWF can facilitate interoperability and communication between the mobile communication network and the second non-3G access network. The second N3IWF can be part of a 5G network (e.g., a 5G Public Land Mobile Network, PLMN). The second N3IWF can facilitate interoperability and communication between the 5G network and the second non-3GPP access network.

[0368] The second non-3GPP access network can be the same as the first non-3GPP access network. The second non-3GPP access network can be different from the first non-3GPP access network.

[0369] The second non-3GPP access network may include a second non-3G access point. The second non-3GPP access network may include a second non-3GPP gateway function.

[0370] The second non-3GPP access network can be a second trusted non-3GPP access network (TNAN). The second TNAN may include a second trusted non-3GPP access point (TNAP). The second TNAN may include a second trusted non-3GPP gateway function (TNGF). The second non-3GPP access network can also be a second untrusted non-3GPP access network. The second untrusted non-3GPP access network may include a second untrusted non-3GPP access point. The second untrusted non-3GPP access network may include a second untrusted non-3GPP gateway function.

[0371] The second secure connection can be an Internet Protocol Security (IPsec) Security Association (SA). This second secure connection can include an IPsec Security Association (SA) between the user equipment and a second non-3GPP access network.

[0372] The second message may have already been sent from the AMF to the user equipment via the first non-3GPP access network.

[0373] The second message may include information from the Next Generation Application Protocol (NGAP) Initial Context Establishment Request message. The NGAP Initial Context Establishment Request message may have been sent from the AMF to the first non-3GPP access network. The NGAP Initial Context Establishment Request message may have been sent from the AMF to the second non-3GPP access network.

[0374] In some embodiments, at least one processor coupled to at least one memory is further configured to enable the UE to establish a second secure connection with the AMF via a second non-3GPP access network using a second key.

[0375] When establishing a second secure connection with the AMF, the second non-3GPP access network can send a Next Generation Application Protocol (NGAP) Initial Context Establishment Response message to the AMF.

[0376] In some embodiments, the second non-3GPP access network includes one or more of the following: a trusted non-3GPP gateway function (TNGF); a non-3GPP access interoperability function (N3IWF); a trusted wireless local area network (WLAN) interoperability function (TWIF); or a wired access gateway function (W-AGF).

[0377] In some embodiments, the second key is one of the following: TNGF key; N3IWF key; TWIF key; or W-AGF key.

[0378] The second key can be a trusted non-3GPP gateway function key k used for trusted non-3GPP gateway functions in a second non-3GPP access network. TNGF The second key can be a non-3GPP interoperability key k used for non-3GPP interoperability functions in a second non-3GPP access network. N3IWF The second key can be a trusted WLAN interoperability key k used for trusted WLAN interoperability in a second non-3GPP access network. TWIF The second key can be the wired access gateway function key k used for wired access gateway functions in a second non-3GPP access network. WAGF .

[0379] In some embodiments, at least one processor coupled to at least one memory is further configured such that the UE derives a second key using one or more of the following: an uplink non-access stratum NAS count, the length of the uplink NAS count, an access type distinguisher, or the length of the access type distinguisher.

[0380] The uplink UL non-access stratum NAS count can depend on whether the user equipment has already registered with the same AMF via 3GPP access. The uplink UL non-access stratum NAS count value can be used for integrity protection. When the UE first connects to the 5GC via non-3GPP access, the uplink UL non-access stratum NAS count value can be zero. The uplink UL non-access stratum NAS count value can be used for integrity protection. The uplink UL non-access stratum NAS count value can be an existing non-3GPP specific UL NAS count used for integrity protection.

[0381] The length of the uplink UL NAS count can correspond to the number of bits in the uplink UL NAS count value. The length of the uplink UL NAS count can be 0x00 0x04.

[0382] The access type distinguisher value can be predefined. The access type distinguisher value can be 0x00 and 0x03 to 0xf0; these values ​​can be reserved for future use. The access type distinguisher value can be 0xf1 to 0xff; these values ​​can be reserved for private use. When deriving the gNodeB key k... gNB At that time, the access type distinguisher can have a value of 0x01 (3GPP value). When deriving k N3IWF k WAGF k TWIF or k TNGF Initially, the access type distinguisher value can be 0x02 (a non-3GPP value). When the second key is a non-3GPP access key, the access type distinguisher value can be 0x03. When the second key is a non-3GPP interoperability function N3IWF key k... N3IWF When the access type distinguisher is 0x03 or 0x04, the value of the second key is a trusted non-3GPP gateway function TNGF key k. TNGF At this time, the access type distinguisher can have a value of 0x03 or 0x05. When the second key is a wired access gateway function WAGF key k... WAGF When the access type distinguisher is 0x03 or 0x06, the value of the second key is a trusted WLAN interoperability key k. TWIF At that time, the value of the access type distinguisher can be 0x03 or 0x07.

[0383] The length of the access type distinguisher can correspond to the number of bits in the access type distinguisher.

[0384] In some embodiments, at least one processor coupled to at least one memory is further configured such that the UE derives a second key using a freshness parameter.

[0385] The freshness parameter can correspond to the fact that AMF has been from k AMF The number of times the key is derived. The first key can be AMF from k. AMF The first derived key. The freshness parameter corresponding to the first key can be 1. The second key can be an AMF derived from k. AMF The second derived key. The freshness parameter corresponding to the second key can be 2. The freshness parameter corresponding to the nth key can be n.

[0386] In some embodiments, at least one processor coupled to at least one memory is further configured such that the UE derives a second key using the length of the freshness parameter.

[0387] The length of the freshness parameter can correspond to the number of bits in the freshness parameter. The length of the freshness parameter can be 0x00 0x01.

[0388] In some embodiments, the freshness parameter is one of a count, a counter, a random number, or a temporary value.

[0389] A temporary value can be any number used only once. A temporary value can be a random number. A temporary value can be a pseudo-random number.

[0390] In some embodiments, the freshness parameter is received by the UE from the AMF.

[0391] The freshness parameter can be received by the UE from the AMF via the first non-3GPP access network. The freshness parameter can also be received by the UE from the AMF via the second non-3GPP access network.

[0392] In some embodiments, the first non-3GPP access network is different from the second non-3GPP access network.

[0393] The first non-3GPP access network can be a physically different entity from the second non-3GPP access network. The first non-3GPP access network may include components that are physically different from the second non-3GPP access network. The first non-3GPP access network may be located in physically different locations from the second non-3GPP access network.

[0394] In one aspect, a processor for wireless communication includes: at least one controller coupled to at least one memory and configured such that the processor: establishes a first secure connection with an Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; output a first message to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of the second key, which establishes a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; from the AMF input a second message, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF Derive the second key.

[0395] Such a processor enables the access and mobility management functions to instruct the user equipment (UE) to derive a second key for establishing a second secure connection with the AMF via a second non-3GPP access network. This arrangement offers the advantages that the AMF does not need to perform additional full master authentication operations during UE mobility registration involving changes to the non-3GPP access network or UE mobility security re-establishment. This typically reduces signaling overhead between the UE and the mobile network. It also typically reduces latency in establishing the connection between the UE and the mobile network.

[0396] The processor can be part of a user device.

[0397] In one aspect, a network device for wireless communication includes: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network device: establishes a first secure connection with a user equipment (UE) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; receive a first message from the UE via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, which is used to establish a second secure connection with the network device via a second non-3GPP access network, wherein the second key uses k AMF To derive; and to send a second message to the UE, wherein the second message indicates a request to derive a second key for the UE.

[0398] Such a network device can instruct the user equipment (UE) to derive a second key for establishing a second secure connection with the network device via a second non-3GPP access network. This arrangement offers the following advantages: during UE mobility registration involving changes to the non-3GPP access network or UE mobility security re-establishment, the network device does not need to perform additional full master authentication. This often reduces signaling overhead between the UE and the mobile communication network. It also often reduces latency in establishing the connection between the UE and the mobile communication network.

[0399] Network equipment can be a network entity. Network equipment can be a base station. Network equipment can be a network function. Network equipment can be a core network. Network equipment can be part of a mobile communication network. Network equipment can be an eNodeB (eNB). Network equipment can be a gNodeB (gNB). Network equipment can be an Access and Mobility Management Function (AMF).

[0400] In the case that the second non-3GPP access network is a trusted non-3GPP access network, the second key can be a new TNGF key (k TNGF In the case where the second non-3GPP access network is an untrusted non-3GPP access network, the second key can be a new N3IWF key (k N3IWF In the case where the second non-3G access network is a trusted wireless local area network (WLAN) access network, the second key can be a new TWIF key (k TWIF When the user equipment is a 5G residential gateway (5G-RG), the second key can be a new W-AGF key (k WAGF ).

[0401] The network device itself can derive a second key. The network device can derive the same second key as the user equipment. The network device can provide the second key to a second non-3GPP access network. The network device can provide the second key to nodes in the second non-3GPP access network. For example, a node in the second non-3GPP access network could be TNGF / N3IWF / WLAN-AP / W-5GAN.

[0402] In one aspect, a method performed by a user equipment (UE) includes: establishing a first secure connection with an access and mobility management function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; send a first message to the AMF via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, which establishes a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; receive a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF Derive the second key.

[0403] This approach enables the Access and Mobility Management (AMF) functions to instruct the User Equipment (UE) to derive a second key for establishing a second secure connection with the AMF via a second non-3GPP access network. This arrangement offers the following advantages: during UE mobility registration involving changes to the non-3GPP access network or UE mobility security re-establishment, the AMF is not required to perform an additional full master authentication operation. This typically reduces signaling overhead between the UE and the mobile network. It also typically reduces latency in establishing the connection between the UE and the mobile network.

[0404] In some embodiments, the method further includes: establishing a second secure connection with the AMF via a second non-3GPP access network using a second key.

[0405] When establishing a second secure connection with the AMF, the second non-3GPP access network can send a Next Generation Application Protocol (NGAP) Initial Context Establishment Response message to the AMF.

[0406] In some embodiments, the second non-3GPP access network includes one or more of the following: a trusted non-3GPP gateway function (TNGF); a non-3GPP access interoperability function (N3IWF); a trusted wireless local area network (WLAN) interoperability function (TWIF); or a wired access gateway function (W-AGF).

[0407] In some embodiments, the second key is one of the following: TNGF key; N3IWF key; TWIF key; or W-AGF key.

[0408] In some embodiments, the step of deriving the second key further includes using one or more of the following to derive the second key: uplink non-access stratum NAS count, the length of the uplink NAS count, the access type distinguisher, or the length of the access type distinguisher.

[0409] In some embodiments, the step of deriving the second key further includes using a freshness parameter.

[0410] In some embodiments, the derivation step further includes using the length of the freshness parameter.

[0411] In some embodiments, the freshness parameter is one of a count, a counter, a random number, or a temporary value.

[0412] In one aspect, a UE in a network sends a non-3GPP access key refresh capability to an AMF via a non-3GPP access network; receives one or more of a key refresh request indication and a freshness parameter from the AMF via the non-3GPP access network; derives a fresh non-3GPP access key in response to the key refresh request indication; and establishes security with a target new non-3GPP access network using the fresh non-3GPP access key during mobility; wherein the non-3GPP access key refresh capability indicates one or more of a TNGF key refresh support indication, an N3IWF re-entry support indication, a TWIF key refresh support indication, and a W-AGF key refresh support indication; wherein the key refresh request indication specifies one of a TNGF key refresh, an N3IWF key refresh, a TWIF key refresh, and a W-AGF key refresh.

[0413] In some embodiments, the UE is further configured to: derive a fresh TNGF key in response to receiving a TNGF key refresh request indication.

[0414] In some embodiments, the UE is further configured to: derive a fresh N3IWF key in response to receiving an N3IWF key refresh request indication.

[0415] In some embodiments, the UE is further configured to: derive a fresh TWIF key in response to receiving a TWIF key refresh request indication.

[0416] In some embodiments, the UE is also configured to: derive a fresh WAGF key in response to receiving a WAGF key refresh request indication.

[0417] In some embodiments, deriving the fresh TNGF key includes from k AMF Derive the TNGF key using any one or more of the following input parameters: P0 = uplink NAS count, L0 = length of uplink NAS count (i.e., 0x00 0x04), P1 = access type distinguisher for (non-3GPP access) key refresh / re-entry 'specific code' / (non-3GPP access) TNGF refresh / re-entry 'special code' / non-3GPP access '0x02', L1 = length of access type distinguisher (e.g., 0x00 0x01), P2 = freshness parameter (e.g., count / random number / temporary value), L2 = length of freshness parameter (i.e., 0x00 0x01).

[0418] In some embodiments, deriving the fresh N3IWF key includes from k AMF Derive the N3IWF key using any one or more of the following input parameters: P0 = uplink NAS count, L0 = length of uplink NAS count (i.e., 0x00 0x04), P1 = access type distinguisher for (non-3GPP access) key refresh / re-entry 'specific code' / (non-3GPP access) N3IWF refresh / re-entry 'special code' / non-3GPP access '0x02', L1 = length of access type distinguisher (e.g., 0x00 0x01), P2 = freshness parameter (e.g., count / random number / temporary value), L2 = length of freshness parameter (i.e., 0x00 0x01).

[0419] In some embodiments, deriving a fresh TWIF key includes from k AMF Derive the TWIF key using any one or more of the following input parameters: P0 = uplink NAS count, L0 = length of uplink NAS count (i.e., 0x00 0x04), P1 = access type distinguisher for (non-3GPP access) key refresh / re-entry 'specific code' / (non-3GPP access) TWIF refresh / re-entry 'specific code' / non-3GPP access '0x02', L1 = length of access type distinguisher (e.g., 0x00 0x01), P2 = freshness parameter (e.g., count / random number / temporary value), L2 = length of freshness parameter (i.e., 0x00 0x01).

[0420] In some embodiments, deriving the fresh WAGF key includes from k AMF Derive the WAGF key using any one or more of the following input parameters: P0 = uplink NAS count, L0 = length of uplink NAS count (i.e., 0x00 0x04), P1 = access type distinguisher for (non-3GPP access) key refresh / re-entry 'specific code' / (non-3GPP access) WAGF refresh / re-entry 'special code' / non-3GPP access '0x02', L1 = length of access type distinguisher (e.g., 0x00 0x01), P2 = freshness parameter (e.g., count / random number / temporary value), L2 = length of freshness parameter (i.e., 0x00 0x01).

[0421] Figure 14 An example of a UE 1400 according to various aspects of this disclosure is illustrated. UE 1400 may include a processor 1402, a memory 1404, a controller 1406, and a transceiver 1408. The processor 1402, memory 1404, controller 1406, or transceiver 1408, or various combinations thereof, or various components thereof, may be examples of parts for performing various aspects of this disclosure described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0422] Processor 1402, memory 1404, controller 1406, or transceiver 1408, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured or otherwise supporting components for performing the functions described in this disclosure.

[0423] Processor 1402 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some implementations, processor 1402 may be configured to operate memory 1404. In other implementations, memory 1404 may be integrated into processor 1402. Processor 1402 may be configured to execute computer-readable instructions stored in memory 1404 to cause UE 1400 to perform various functions of this disclosure.

[0424] Memory 1404 may include volatile or non-volatile memory. Memory 1404 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1402, cause UE 1400 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1404 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, including any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0425] In some implementations, processor 1402 and memory 1404 coupled to processor 1402 can be configured such that UE 1400 performs one or more functions described herein (e.g., processor 1402 executes instructions stored in memory 1404). For example, according to the examples disclosed herein, processor 1402 can support wireless communication at UE 1400. UE 1400 can be configured to support components for: establishing a first secure connection with Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses AMF key k. AMF To derive; send a first message to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of the second key, which is used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; receive a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF The second key is derived from this.

[0426] Controller 1406 can manage input and output signals for UE 1400. Controller 1406 can also manage peripheral devices not integrated into UE 1400. In some implementations, controller 1406 can utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, controller 1406 can be implemented as part of processor 1402.

[0427] In some implementations, UE 1400 may include at least one transceiver 1408. In other implementations, UE 1400 may have more than one transceiver 1408. Transceiver 1408 may represent a wireless transceiver. Transceiver 1408 may include one or more receiver chains 1410, one or more transmitter chains 1412, or a combination thereof.

[0428] Receiver chain 1410 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1410 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1410 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1410 may include at least one demodulator configured to demodulate the received signal and acquire transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1410 may include at least one decoder for decoding the demodulated signal to receive transmitted data.

[0429] Transmitter chain 1412 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1412 may include at least one modulator for modulating data onto a carrier signal to prepare the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes such as phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1412 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1412 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0430] Figure 15 An example of a processor 1500 according to various aspects of this disclosure is illustrated. Processor 1500 may be an example of a processor configured to perform various operations according to the examples described herein. Processor 1500 may include a controller 1502 configured to perform various operations according to the examples described herein. Processor 1500 may optionally include at least one memory 1504, which may be, for example, an L1 / L2 / L3 cache. Additionally or alternatively, processor 1500 may optionally include one or more arithmetic logic units (ALUs) 1506. One or more of these components may be electronically communicated or otherwise coupled (e.g., operative ground, communicative ground, functional ground, electronic ground, electrical ground) via one or more interfaces (e.g., buses).

[0431] Processor 1500 may be a processor chipset and includes a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receive, acquire, retrieve, send, output, forward, store, determine, identify, access, write, read) according to the examples described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to the processor chipset or included in the processor chipset (e.g., processor 1500)) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), etc.).

[0432] Controller 1502 can be configured to manage and coordinate various operations of processor 1500 (e.g., signaling, receiving, acquiring, retrieving, sending, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading) to enable processor 1500 to support various operations of the UE according to the examples described herein. For example, controller 1502 can operate as a control unit of processor 1500 to generate control signals for managing the operation of various components of processor 1500. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating operation timing.

[0433] Controller 1502 can be configured to fetch (e.g., fetch, retrieve, receive) instructions from memory 1504 and determine subsequent instructions(s) to be executed, enabling processor 1500 to support various operations according to the examples described herein. Controller 1502 can be configured to track the memory addresses of instructions associated with memory 1504. Controller 1502 can be configured to decode instructions to determine the operations to be performed and the operands involved. For example, controller 1502 can be configured to interpret instructions and determine control signals to be output to other components of processor 1500, enabling processor 1500 to support various operations according to the examples described herein. Additionally or alternatively, controller 1502 can be configured to manage data flow within processor 1500. Controller 1502 can be configured to control data transfers between registers, arithmetic logic unit (ALU), and other functional units of processor 1500.

[0434] Memory 1504 may include one or more caches (e.g., memory or other memory, such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc., local to or included in processor 1500). In some implementations, memory 1504 may reside within or on the processor chipset (e.g., locally to processor 1500). In other implementations, memory 1504 may reside outside the processor chipset (e.g., remotely from processor 1500).

[0435] Memory 1504 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1500, cause processor 1500 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as system memory or another type of memory. Controller 1502 and / or processor 1500 may be configured to execute computer-readable instructions stored in memory 1504 to cause processor 1500 to perform various functions. For example, processor 1500 and / or controller 1502 may be coupled to or coupled to memory 1504, and processor 1500, controller 1502, and memory 1504 may be configured to perform the various functions described herein. In some examples, processor 1500 may include multiple processors, and memory 1504 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be configured individually or collectively to perform the various functions described herein.

[0436] One or more ALU 1506s can be configured to support a variety of operations as described in the examples herein. In some implementations, one or more ALU 1506s may reside within or on a processor chipset (e.g., processor 1500). In some other implementations, one or more ALU 1506s may reside outside the processor chipset (e.g., processor 1500). One or more ALU 1506s can perform one or more calculations on data, such as addition, subtraction, multiplication, and division. For example, one or more ALU 1506s can receive input operands and an opcode that determines the operation to be performed. One or more ALU 1506s can be configured with various logic and arithmetic circuitry, including adders, subtractors, shifters, and logic gates, to process and manipulate data according to the operations. Alternatively or concurrently, one or more ALU 1506s may support logical operations such as AND, OR, XOR, NOR, and NAND, enabling one or more ALU 1506s to handle conditional operations, comparisons, and bitwise operations.

[0437] Based on the examples disclosed herein, processor 1500 can support wireless communication. Processor 1500 can be configured or operable to support components for: establishing a first secure connection with an Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; send a first message to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of the second key, which is used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF To derive; receive a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE; and in response to the second message, from k AMF The second key is derived from this.

[0438] Figure 16 An example of an NE 1600 according to various aspects of this disclosure is illustrated. The NE 1600 may include a processor 1602, a memory 1604, a controller 1606, and a transceiver 1608. The processor 1602, memory 1604, controller 1606, or transceiver 1608, or various combinations thereof, or various components thereof, may be examples of parts for performing various aspects of this disclosure described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0439] Processor 1602, memory 1604, controller 1606, or transceiver 1608, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured to or otherwise supporting components for performing the functions described in this disclosure.

[0440] Processor 1602 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some implementations, processor 1602 may be configured to operate memory 1604. In other implementations, memory 1604 may be integrated into processor 1602. Processor 1602 may be configured to execute computer-readable instructions stored in memory 1604 to cause NE 1600 to perform various functions of this disclosure.

[0441] Memory 1604 may include volatile or non-volatile memory. Memory 1604 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1602, cause NE 1600 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1604 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, including any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0442] In some implementations, processor 1602 and memory 1604 coupled to processor 1602 can be configured such that NE 1600 performs one or more functions described herein (e.g., processor 1602 executes instructions stored in memory 1604). For example, according to the examples disclosed herein, processor 1602 can support wireless communication at NE 1600. NE 1600 can be configured to support components for: establishing a first secure connection with user equipment (UE) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To derive; receive a first message from the UE via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, which is used to establish a second secure connection with the network device via a second non-3GPP access network, wherein the second key uses k AMF To derive; and to send a second message to the UE, wherein the second message indicates a request to derive a second key for the UE.

[0443] Controller 1606 can manage input and output signals used by NE 1600. Controller 1606 can also manage peripheral devices not integrated into NE 1600. In some implementations, controller 1606 can utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, controller 1606 can be implemented as part of processor 1602.

[0444] In some implementations, the NE 1600 may include at least one transceiver 1608. In other implementations, the NE 1600 may have more than one transceiver 1608. The transceiver 1608 may represent a wireless transceiver. The transceiver 1608 may include one or more receiver chains 1610, one or more transmitter chains 1612, or a combination thereof.

[0445] Receiver chain 1610 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1610 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1610 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1610 may include at least one demodulator configured to demodulate the received signal and acquire transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1610 may include at least one decoder for decoding the demodulated signal to receive transmitted data.

[0446] Transmitter chain 1612 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1612 may include at least one modulator for modulating data onto a carrier signal to prepare the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes such as phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1612 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0447] Figure 17 A flowchart illustrating a method according to various aspects of this disclosure is shown. The operation of this method can be implemented by a UE as described herein. In some implementations, the UE can execute a set of instructions to control the functional elements of the UE to perform the described functions.

[0448] At 1702, the method may include: establishing a first secure connection with an Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF This can be derived from the examples described in this article. The operations of 1702 can be performed according to these examples. In some implementations, aspects of the operations of 1702 can be derived from references. Figure 14 The UE is used to execute this.

[0449] At 1704, the method may include: sending a first message to the AMF via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, the second key being used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses k AMF This can be derived from the examples described in this article. The operation of 1704 can be performed according to these examples. In some implementations, aspects of the operation of 1704 can be derived from the references. Figure 14 The UE is used to execute this.

[0450] At 1706, the method may include: receiving a second message from the AMF, wherein the second message indicates a request to derive a second key for the UE. The operation of 1706 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1706 can be derived from references... Figure 14 The UE is used to execute this.

[0451] At 1708, the method may include: in response to the second message, from k AMF The second key is derived. The operations of 1708 can be performed according to the examples described in this document. In some implementations, aspects of the operations of 1708 can be derived from references. Figure 14 The UE is used to execute this.

[0452] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0453] Figure 18 A flowchart illustrating a method according to various aspects of this disclosure is shown. The operation of this method can be implemented by an NE as described herein. In some implementations, the NE can execute an instruction set to control the functional elements of the NE to perform the described functions.

[0454] At 1802, the method may include: establishing a first secure connection with a user equipment (UE) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF This can be derived from the examples described in this article. The operations of 1802 can be performed according to these examples. In some implementations, aspects of the operations of 1802 can be derived from references. Figure 16 The NE is used to execute this.

[0455] At 1804, the method may include: receiving a first message from the UE via a first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, the second key being used to establish a second secure connection with a network device via a second non-3GPP access network, wherein the second key uses k AMF This can be derived from the examples described in this article. The operation of 1804 can be performed according to these examples. In some implementations, aspects of the operation of 1804 can be derived from the references. Figure 16 The NE is used to execute this.

[0456] At 1806, the method may include: sending a second message to the UE, wherein the second message indicates a request to derive a second key for the UE. The operation of 1806 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1806 can be derived from references... Figure 16 The NE is used to execute this.

[0457] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0458] The description provided herein is intended to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0459] The following abbreviations are relevant to the areas covered in this document: 5GC, 5G Core Network; 5G-AN, 5G Access Network; 5G LAN, 5G Local Area Network; 5G-BRG, 5G Broadband Residential Gateway; 5G-CRG, 5G Wired Residential Gateway; 5G-RG, 5G Residential Gateway; NG-RAN, 5G Radio Access Network; 5G AV, 5G Authentication Vector; 5G HE AV, 5G Home Environment Authentication Vector; 5G NSWO, 5G Non-Seamless WLAN Offload; 5G SE AV, 5G Service Environment Authentication Vector; ABBA, Reverse Underbidding Between Architectures; AEAD, Authentication Encryption with Related Data; AES, Advanced Encryption Standard; AKA, Authentication and Key Negotiation; AMF, Access and Mobility Management Function; ARPF, Authentication Credential Repository and Processing Function; AUN3, Authentication Non-3GPP Device; AUSF, Authentication Server Function; AUTN, Authentication Token; CCA, Client Credential Assertion; CH, Credential Holder; CIoT, Cellular Internet of Things; cNRF, Consumer NRF; CP, Control Plane; CTR, Counter (Mode). CU, Central Unit; DCS, Default Credential Server; DN, Data Network; DNN, Data Network Name; DU, Distributed Unit; EAP, Extensible Authentication Protocol; EMSK, Extended Master Session Key; EN-DC, E-UTRA-NR Dual Connectivity; ENSI, External Network Slice Information; EPS, Evolved Packet System; FT, Fast BSS Transition; FN-BRG, Fixed Network Broadband RG; FN-CRG, Fixed Network Cable RG; FN-RG, Fixed Network RG; gNB, NR Node B; GUTI, Globally Unique Temporary UE Identity; HRES, Hash response; HXRES, expected hash response; IKE, Internet Key Exchange; KSI, Key Set Identifier; MeNB, Master eNB; MN, Master Node; MSK, Master Session Key; N3IWF, Non-3GPP Interoperability Function; NAI, Network Access Identifier; NAS, Non-Access Stratum; NDS, Network Domain Security; NF, Network Function; NG, Next Generation; ng-eNB, Next Generation Evolved Node B; ngKSI, Key Set Identifier in 5G; N5CW, WLAN supporting non-5G; N5GC, supporting non-5G; NIA, 5G Integrity Algorithm; N R, New Radio; NR-DC, NR-NR Dual Connectivity; NSSAI, Network Slice Selection Auxiliary Information; NSSAA, Network Slice Specific Authentication and Authorization; Non-Seamless WLAN Offload; NOUNCE, Number Used Once; NSWOF, Non-Seamless WLAN Offload Function; PDN, Packet Data Network; PEI, Permanent Device Identifier; RES, Response; RAND, Random; SCG, Secondary Cell Group; SEAF, Security Anchor Function; SgNB, Secondary gNB; SIDF, Subscription Identifier Dehiding Function; SMC, Security Mode Command; SMF, Session Management Function;SN, Secondary Node; SN Id, Serving Network Identifier; SUCI, Subscription Hidden Identifier; SUPI, Subscription Persistent Identifier; TLS, Transport Layer Security; TNAN, Trusted Non-3GPP Access Network; TNAP, Trusted Non-3GPP Access Point; TNGF, Trusted Non-3GPP Gateway Function; TWAP, Trusted WLAN Access Point; TWIF, Trusted WLAN Interoperability Function; TSC, Time-Sensitive Communications; UE, User Equipment; UDM, Unified Data Management; UDR, Unified Data Repository; ULR, Update Location Request; UP, User Plane; UPF, User Plane Function; URLLC, Ultra-Reliable Low-Latency Communications; USIM, Universal Subscriber Identity Module; W-5GAN, Wired 5G Access Network; W-5GBAN, Wired BBF Access Network; W-5GCAN, Wired 5G Cable Access Network; W-AGF, Wired Access Gateway Function; XRES, Expected Response.< / mcc> < / mnc>

Claims

1. A user equipment (UE) for wireless communication, the UE comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured such that the UE: A first secure connection is established with the Access and Mobility Management Function (AMF) via a first non-3GPP access network using a first key, wherein the first key uses the AMF key k. AMF To deduce; A first message is sent to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, the second key being used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses the k AMF To deduce; Receive a second message from the AMF, wherein the second message indicates a request to derive the second key for the UE; as well as In response to the second message, from the k AMF The second key is derived.

2. The UE of claim 1, wherein the at least one processor coupled to the at least one memory is further configured such that the UE: uses the second key to establish the second secure connection with the AMF via the second non-3GPP access network.

3. The UE according to any one of the preceding claims, wherein the second non-3GPP access network includes one or more of the following: a trusted non-3GPP gateway function (TNGF); a non-3GPP access interoperability function (N3IWF); a trusted wireless local area network (WLAN) interoperability function (TWIF); or a wired access gateway function (W-AGF).

4. The UE according to any one of the preceding claims, wherein the second key is one of the following: a TNGF key; an N3IWF key; a TWIF key; or a W-AGF key.

5. The UE according to any one of the preceding claims, wherein the at least one processor coupled to the at least one memory is further configured such that the UE derives the second key using one or more of the following: an uplink non-access stratum (NAS) count, the length of the uplink NAS count, an access type distinguisher, or the length of the access type distinguisher.

6. The UE according to any one of the preceding claims, wherein the at least one processor coupled to the at least one memory is further configured such that the UE: uses a freshness parameter to derive the second key.

7. The UE of claim 6, wherein the at least one processor coupled to the at least one memory is further configured such that the UE: derives the second key using the length of the freshness parameter.

8. The UE according to claim 6 or 7, wherein the freshness parameter is one of a count, a counter, a random number, or a temporary value.

9. The UE according to any one of claims 6 to 8, wherein the freshness parameter is received by the UE from the AMF.

10. The UE according to any one of the preceding claims, wherein the first non-3GPP access network is different from the second non-3GPP access network.

11. A processor for wireless communication, the processor comprising: At least one controller, coupled to at least one memory, and configured such that the processor: A first secure connection is established via a first non-3GPP access network and the Access and Mobility Management Function (AMF) using a first key, wherein the first key uses the AMF key k. AMF To deduce; A first message is output to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, the second key being used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses the k AMF To deduce; A second message is input from the AMF, wherein the second message indicates a request to derive the second key for the UE; as well as In response to the second message, from the k AMF The second key is derived.

12. A network device for wireless communication, the network device comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured such that the network device: A first secure connection is established with a user equipment (UE) via a first non-3GPP access network using a first key, wherein the first key uses an AMF key k. AMF To deduce; A first message is received from the UE via the first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, the second key being used to establish a second secure connection with the network device via a second non-3GPP access network, wherein the second key uses the k AMF To deduce; as well as A second message is sent to the UE, wherein the second message indicates a request to derive the second key for the UE.

13. A method performed by a user equipment (UE), the method comprising: A first secure connection is established via a first non-3GPP access network and the Access and Mobility Management Function (AMF) using a first key, wherein the first key uses the AMF key k. AMF To deduce; A first message is sent to the AMF via the first secure connection, wherein the first message indicates that the UE supports the derivation of a second key, the second key being used to establish a second secure connection with the AMF via a second non-3GPP access network, wherein the second key uses the k AMF To deduce; Receive a second message from the AMF, wherein the second message indicates a request to derive the second key for the UE; as well as In response to the second message, from the k AMF The second key is derived from this.

14. The method of claim 13, further comprising: Using the second key, a second secure connection is established with the AMF via the second non-3GPP access network.

15. The method according to any one of claims 13 or 14, wherein the second non-3GPP access network comprises one or more of the following: a trusted non-3GPP gateway function (TNGF); a non-3GPP access interoperability function (N3IWF); a trusted wireless local area network (WLAN) interoperability function (TWIF); or a wired access gateway function (W-AGF).

16. The method according to any one of claims 13 to 15, wherein the second key is one of the following: a TNGF key; an N3IWF key; a TWIF key; or a W-AGF key.

17. The method of any one of claims 13 to 16, wherein the step of deriving the second key further comprises using one or more of the following: an uplink non-access stratum NAS count, the length of the uplink NAS count, an access type distinguisher, or the length of the access type distinguisher.

18. The method of any one of claims 13 to 17, wherein the step of deriving the second key further includes using a freshness parameter.

19. The method according to any one of claims 13 to 18, wherein the derived step further includes using the length of the freshness parameter.

20. The method according to any one of claims 13 to 19, wherein the freshness parameter is one of the following: a count, a counter, a random number, or a temporary value.

Images