Non-NAS device authentication over non-3GPP access

Abstract

For an authentication process associated with a device initiated registration process, a second key is calculated based on a first key, the first key being a key of a core network function of a core network of a cellular communication network. The second key is a key of a connection enabling function that enables a connection of the device with the core network via the local access network. A second key is calculated by inputting the first key and a particular input parameter to a key derivation function for calculating the second key. A connection with the core network is established via the connection enabling function and the core network function based on the second key.

Description

Technical Field

[0001] At least some example implementations involve techniques for authenticating non-NAS devices on non-3GPP access. Background Technology

[0002] WLAN UEs that do not support 5GC NAS (N5CW) can register to cellular networks via trusted non-3GPP access. These N5CW devices can authenticate to the cellular network using 3GPP credentials and register with the help of the Trans-Wave Function (TWIF), which provides the 5GC NAS protocol stack to the AMF of the cellular network's core network.

[0003] Furthermore, using EAP-TLS as an example, there exists an authentication process for non-5G-capable (N5GC) devices behind a residential gateway (RG) in a private network or in an isolated deployment scenario with wired access (i.e., roaming not considered).

[0004] List of abbreviations

[0005] 3GPP Third Generation Partnership Project

[0006] 5G (Fifth Generation)

[0007] 5GC 5G core

[0008] 5WWC: Wireless and wired convergence of 5G systems

[0009] AAA Certification, Authorization and Accounting

[0010] AGF Access Gateway Function

[0011] AKA Authentication and Key Negotiation

[0012] AMF Access and Mobility Management Functions

[0013] AN access network

[0014] AUN3 can authenticate non-3GPP devices

[0015] AUSF Authentication Server Functionality

[0016] EAP Extensible Authentication Protocol

[0017] gNB 5G NodeB

[0018] GUTI (Globally Unique Temporary Identifier)

[0019] HMAC Hash Message Authentication

[0020] KDF Key Export Functions

[0021] N3IWF Non-3GPP Access Interoperability Function

[0022] The N5CW WLAN does not support 5G.

[0023] NAI Network Access Identifier

[0024] NAS Non-Access Layer

[0025] NAUN3 Uncertifiable Non-3GPP Devices

[0026] PLMN Public Land Mobile Network

[0027] PMK Paired Master Key

[0028] PPP (Point-to-Point Protocol)

[0029] RG residential gateway

[0030] SEAF Safety Anchoring Function

[0031] SHA Secure Hash Algorithm

[0032] SUCI Subscriber Hidden Identifier

[0033] TNAP Trusted Non-3GPP Access Point

[0034] TNGF Trusted Non-3GPP Gateway Function

[0035] TWAP Trusted WLAN Access Point

[0036] TWIF Trusted Interoperability Function

[0037] UDM Unified Data Management

[0038] UE User Equipment

[0039] W-AGF Wired AGF

[0040] WLAN Wireless Local Access Network

[0041] Citation List

[0042] 3GPP TS 23.501 V18.1.0, hereinafter also referred to as TS 23.501

[0043] 3GPP TS 33.501 V18.1.0, hereinafter also referred to as TS 33.501

[0044] 3GPP TS 23.502 V17.6.0, hereinafter also referred to as TS 23.502

[0045] 3GPP TS 23.003 Summary of the Invention

[0046] At least some example implementations are designed to provide key freshness for devices that can register to the cellular network core using credentials of the cellular network but do not support access through a non-access stratum, which is different from access through an access network of the cellular network, and to avoid potential security vulnerabilities due to lack of forward confidentiality.

[0047] Methods, apparatuses and non-transient computer-readable storage media are provided according to at least some example embodiments, as specified in the appended claims.

[0048] In the following description, explanatory examples and exemplary embodiments will be given with reference to the accompanying drawings. Attached Figure Description

[0049] Figure 1A and Figure 1B A signaling diagram illustrating the authentication process of an N5CW device, based on an explanatory example, is shown.

[0050] Figure 2 A flowchart illustrating a process for authenticating non-NAS devices over non-3GPP access, according to at least some example embodiments, is shown.

[0051] Figure 3A and Figure 3B A signaling diagram illustrating the authentication process of an N5CW device according to at least some example embodiments is shown.

[0052] Figure 4A and Figure 4B A signaling diagram illustrating the authentication process of an AUN3 device according to at least some example embodiments is shown.

[0053] Figure 5 A signaling diagram illustrating another authentication process of an N5CW device according to at least some example embodiments is shown.

[0054] Figure 6 A schematic block diagram illustrating the configuration of a control unit that can be implemented in at least some example embodiments is shown.

[0055] Figure 7 The diagram shows... Figure 7 A.2.4-1: N5CW certification process of TS 33.501.

[0056] Figure 8 The diagram shows... Figure 7 BY-1: Authentication process for AUN3 devices (i.e., N5CW devices) that support a 5G key hierarchy, using EAP-AKA', in accordance with the change request of TS 33.501. Detailed Implementation

[0057] As previously mentioned, N5CW devices can register to the 5GC using 3GPP credentials and establish a 5GC connection via the Trusted WLAN Access Network. The reference architecture is captured in section 4.2.8.5.2 of TS 23.501. 3GPP credentials are stored as defined in section 6.1.1.1 of TS 33.501. The Trusted WLAN Interoperability Function (TWIF) provides interoperability, enabling connectivity with the 5GC, implementing the NAS protocol stack, and exchanging NAS messages with the AMF on behalf of the N5CW device. A single EAP-AKA authentication process is performed to connect the N5CW device to both the Trusted WLAN Access Network and the 5G core network.

[0058] Before giving a description of the example embodiments, reference will be made to Figure 1A and Figure 1B Describe an explanatory example. Figure 1A and Figure 1B The illustration shows the certification process for an N5CW device based on an explanatory example.

[0059] First, the N5CW device selects the PLMN and a trusted WLAN that supports "NAS-free 5G connectivity" to the PLMN by using the procedure specified in Section 6.3.12a of TS 23.501, "Access Network Selection for Devices that Do Not Support 5GC NAS over WLAN".

[0060] Then, in Figure 1A and Figure 1B In steps S101 to S110 of the diagram, the initial registration of 5GC is performed.

[0061] Specifically, in S101, the N5CW device is associated with a trusted WLAN network, and the EAP-AKA authentication process is initiated.

[0062] In S102a, S102b, and S102c, the N5CW device provides its Network Access Identifier (NAI). Trusted WLAN Access Points (TWAPs) select a Trusted WLAN Interoperability Function (TWIF) based on the received domain information and send an AAA request to the selected TWIF.

[0063] If the N5CW device registers with the 5GC via 3GPP access for the first time when initiating the above process, then the NAI includes the SUCI. The SUCI is constructed as specified in Clause 6.12.2 of TS 23.501.

[0064] If the N5CW device has already registered with the 5GC via 3GPP access when initiating the above process, then the NAI includes the 5G-GUTI assigned to the N5CW device via 3GPP access. This allows TWIF to select the same AMF as the AMF serving the N5CW device via 3GPP access in the following step S104a.

[0065] In S103, TWIF creates a 5GC registration request message on behalf of the N5CW device. TWIF populates the parameters in the registration request message with default values, which are the same for all N5CW devices that do not support 5G NAS. The registration type indicates "Initial Registration".

[0066] In S104a and S104b, TWIF selects AMF (e.g., if provided by an N5CW device, by using 5G-GUTI in NAI) and sends an N2 message to AMF, which includes a registration request, user location, and AN type.

[0067] In S105, if the AMF triggers the authentication process, it sends a request to the ASF by sending a Nausf_UEAuthentication_Authenticate request message. The Nausf_UEAuthentication_Authenticate request message contains either SUCI or SUPI (if a valid 5G-GUTI is received by the AMF). The request message also contains an indication that the request is from the N5CW device.

[0068] In S106, AUSF sends a Nudm_UEAuthentication_Get request to UDM, which includes SUCI or SUPI and an N5CW indication.

[0069] In S107, upon receiving a Nudm_UEAuthentication_Get request, if a SUCI is received, the UDM invokes SIDF. Before the UDM can process the request, SIDF de-conceals the SUCI to obtain a SUPI. The UDM can select the authentication method based on the "realm" portion of the SUPI, the N5CW device indicator, a combination of the "realm" portion and the N5CW device indicator, or a UDM-local policy.

[0070] In S108, the EAP-AKA procedure will be triggered to perform mutual authentication between the N5CW device and the home network as specified in Clause 6.1.3.1 of TS 33.501.

[0071] The EAP-AKA message occurs between the N5CW device and the AUSF. Through the N2 interface, the EAP message is encapsulated within a NAS authentication message. EAP-AKA messages exchanged between the N5CW device and TWIF are encapsulated in Layer-2 packets, such as IEEE 802.3 / 802.1x packets, IEEE 802.11 / 802.1x packets, PPP packets, etc.

[0072] In S109, a NAS security context is not required in this scenario. As specified in Annex A.9 of TS 33.501, the AMF receives the K... AMF Key export K TWIF Key. The NAS security between AMF and TWIF is similar to an unauthenticated emergency call being established, i.e., with NULL encryption and NULL integrity protection.

[0073] In S110a, the AMF sends a NAS security mode command to the TWIF. The NAS security mode command includes an EAP success message and the null security algorithm.

[0074] In S110b, TWIF does not directly forward the EAP success message to N5CW, but instead stores the EAP success message and waits for K. TWIF Key generation and reception from AMF.

[0075] In S110c, TWIF sends a NAS security mode completion message to AMF.

[0076] Then, in S111, the AMF sends the N2 initial context setting request and sets K TWIF The key is provided to TWIF.

[0077] In steps S112a to S112f, TWIF uses K as specified in Appendix A.22 of TS 33.501. TNGF Key export TNAP key K TNAP The TNAP key and EAP success message are sent to the trusted WLAN access point, which then successfully forwards the EAP to the N5CW device. The TNAP 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 and the TWIF to transmit all user plane services of the N5CW device to the TWIF. This connection is later bound to an N3 connection created for the N5CW device.

[0078] In S113, TWIF should send an N2 initial context setting response message to AMF.

[0079] As indicated in S114, the following steps are captured after step 9h in Clause 4.12b.2 of TS 23.502.

[0080] As mentioned above, N5CW devices or AUN3 (N5GC) devices do not support NAS access on non-3GPP networks.

[0081] Furthermore, N5GC devices cannot export the 5G key hierarchy. These devices reside in wired networks and require access to the converged 5G core. It's important to note that N5GC device authentication can be based on additional EAP methods beyond EAP-AKA.

[0082] Since the N5CW and AUN3 devices do not support NAS over non-3GPP access, there is no standardization, and it is unclear what parameters should be used in key generation for AUN3 / N5CW devices.

[0083] In the 5GS, according to A.9 of TS 33.501, the NAS count is used as the input parameter P0 of the Key Derivation Function (KDF). However, the NAS count cannot be used in AUN3 / N5CW devices because they do not support the NAS protocol.

[0084] For example, generating K without NAS counts based on relevant work. TWIF Key (K) WAGF’ The key generation method alone cannot completely solve the key generation problem because there is no freshness in key generation. Therefore, whenever an AUN3 / N5CW device exits and reconnects to a WLAN / TWIF (WLAN / W-AGF) connection, TWIF (W-AGF) sends a request to the AMF. Since the AMF already has the security context, it will generate the same key again. TWIF (K) WAGF’ This lack of forward confidentiality could lead to potential security vulnerabilities.

[0085] In the following text, reference will be made to Figures 2 to 6 Describe an example implementation.

[0086] First, refer to Figure 2 , Figure 2 The illustrations illustrate processes 1 and 2 for non-NAS device authentication over non-3GPP access, according to at least some example embodiments.

[0087] It is important to note that non-3GPP access is an example of access that differs from access on the access network of a cellular communication network.

[0088] According to at least some example embodiments, process 1 is performed by a device such as an N5CW device, an N5GC device, or an AUN3 device, each of which can be configured as a user equipment (UE) and each of which can register to the core network of the cellular communication network using credentials of the cellular communication network (e.g., 3GPP credentials), but does not support non-access strata on access networks different from access on the access network of the cellular communication network.

[0089] In step S211, a registration process is initiated to register with the core network of the cellular communication network and establish a connection with the core network via the local access network. Then, process 1 proceeds to step S213.

[0090] The local access network may include at least one of trusted WLAN AP or RG (RG (WLAN AP), 5G-RG).

[0091] According to at least some example embodiments, S211 corresponds to Figure 3A S301, Figure 4A S401a and Figure 5 The S501 will be described later.

[0092] In step S213, regarding the authentication process associated with the registration process, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function used to calculate the second key. The first key is the key for core network functions, and the second key is the key for the connection enable function that enables connection to the core network. Then, process 1 proceeds to step S215.

[0093] According to at least some example embodiments, the core network function includes AMF, and the first key includes key K. AMF The connection enable function includes TWIF, and the second key includes key K. TWIF Furthermore, the first key may include key K. TWIF Furthermore, the first key may include the key PMK, and the second key may include the WLAN key.

[0094] Furthermore, according to at least some example embodiments, the core network function includes AMF, and the first key includes key K. AMF Furthermore, the connectivity enablement features include W-AGF or 5G-RG, and the second key includes key K. WAGF Or key K RG Furthermore, the first key may include key K. WAGF Or key K RGFurthermore, the first key may include the key PMK, and the second key may include the WLAN key.

[0095] In step S215, a connection to the core network is established based on the second key via connectivity enable function and core network function. Then, process 1 ends.

[0096] According to at least some example embodiments, S215 corresponds to Figure 3B S312e and Figure 4B The S409 will be described later.

[0097] According to at least some example embodiments, a first key is obtained via an authentication and key negotiation process performed between the device, the local access network, and the core network in association with the registration process, the registration process being associated with an authentication process as the main authentication process. Figure 4A (S404).

[0098] According to at least some example embodiments, the authentication and key negotiation process is performed for each registration process initiated by the device, as will be discussed later. Figure 5 Solution 3, as illustrated, is described in more detail.

[0099] According to at least some example embodiments, specific input parameters include the non-access stratum NAS count (uplink NAS COUNT) P0. Specific input parameters may also include parameter FC, the length L0 of the uplink NAS COUNT, the access type distinguisher P1, and the length L1 of the access type distinguisher.

[0100] The key derivation function can include HMAC-SHA-256(key, S), where "key" is the first key and the input S is formed by S = FC||P0||L0||P1||L1. Then, the second key is computed as the derivation key = HMAC-SHA-256(key, S).

[0101] According to at least some example embodiments, the NAS count is a fixed constant value, as described in more detail later in Solution 1.

[0102] According to at least some example embodiments, the NAS count is determined based on at least one of a random value or a counter value, as will be discussed later. Figure 3A and Figure 3B In the illustrated solution 2 and Figure 4A and Figure 4B The solution illustrated in 2b is described in more detail.

[0103] According to at least some example embodiments, at least one of a random value or an initial value of a counter value is obtained from a core network function via a payload associated with the authentication process (see, for example...). Figure 3B (S312c).

[0104] According to at least some example embodiments, a counter value is incremented when a device identifier associated with a registration process that is not the primary authentication process is requested (see, for example, see...). Figure 3A (S302a).

[0105] According to at least some example embodiments, random values ​​are obtained via a payload associated with a registration process that is not a primary authentication process (see, for example...). Figure 3B (S312c).

[0106] Figure 2 The process 2 shown in the diagram can be performed by core network functions such as AMF and SEAF.

[0107] In step S221, regarding the authentication process associated with the registration process initiated by the device (e.g., the registration process initiated in S211), the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function used to calculate the second key. The first key is a key for core network functions, and the second key is a key for connection enabling functions that enable the connection between the device and the core network via the local access network. Then, process 2 proceeds to step S223.

[0108] According to at least some example embodiments, S221 corresponds to Figure 3A S309 and Figure 4B S405.

[0109] In step S223, a connection between the device and the core network is established via the connection enable function based on the second key.

[0110] According to at least some example embodiments, S223 corresponds to Figure 3B S313.

[0111] The descriptions of the first key, second key, core network functions, connection enabling functions, specific input parameters, and key derivation functions in Process 1 also apply to Process 2.

[0112] According to at least some example embodiments, a first key is provided via an authentication and key negotiation process performed between the device, the local access network, and the core network in association with the registration process, which is associated with an authentication process as the main authentication process (see [link to documentation]). Figure 4A (S405).

[0113] According to at least some example embodiments, the authentication and key negotiation process is performed for each registration process initiated by the device, as will be described below. Figure 5 Solution 3, as illustrated, is described in more detail.

[0114] According to at least some example embodiments, the NAS count is a fixed constant value, as described above for process 1.

[0115] According to at least some example embodiments, the NAS count is determined based on at least one of a random value or a counter value, as described above for process 1.

[0116] According to at least some example embodiments, at least one of a random value or an initial value of a counter value is provided to the connection enable function via a payload associated with the authentication process (see [link]). Figure 3B (S310a).

[0117] According to at least some example embodiments, when requesting registration of a device associated with a registration process that is not the primary authentication process, a counter value is incremented (see [link to documentation]). Figure 3A (S309).

[0118] According to at least some example embodiments, a random value is provided to the connection enable function via a payload associated with a registration process that is not the primary authentication process (see [link]). Figure 3B (S310a).

[0119] The solutions mentioned above—Solution 1, Solution 2, Solution 2b, and Solution 3—will be described in more detail below. First, a brief overview of the solutions is given below:

[0120] Solution 1 (No Key Freshness in N5CW Devices): In A.9 of TS 33.501, the NAS count value of parameter P0 used as the Key Derivation Function (KDF) is set to a constant value, such as 0x00 or 0xff. In other words, the UE (N5CW device) and AMF can generate the same key as defined by the standard (00 or FF or any other agreed constant).

[0121] Solution 2 (For Key Freshness in N5CW Devices): After master authentication, the N5CW device and AMF begin using the same initial value for a counter. The counter value increments with each authentication and is used as input parameter P0 for the KDF. The initial value can be generated by the AMF, for example, based on a generated random number and sent to the UE via EAP, or both the UE and AMF can use a constant value such as 0x00 or 0xFF as the initial value. A constant initial value can be shared beforehand or known to both the UE and AMF. Alternatively, a varying initial value can be generated without randomness, for example, based on a sequence. In other words, the N5CW device and AMF generate the same counter value, or the AMF provides the counter value to the UE via the EAP payload. This counter value will increment each time to maintain freshness. For example, the N5CW device increments the counter when requested to provide the UE's identifier. The AMF should increment the counter when it has a security context that is already available.

[0122] - Solution 2b (for key freshness in AUN3 devices connected via RG): Same operation as in Solution 2, now applied to AUN3 devices.

[0123] Solution 3 (Full Authentication): When the N5CW device reconnects via TWIF and an AMF security context already exists, the AMF initiates master authentication, generating a fresh key. In this way, master authentication is performed every time the N5CW device is reattached.

[0124] Solution 1

[0125] In the case of N5CW devices, the NAS counter value (P0) can be set to "0x00" or "0xFF" or any fixed constant value. This allows the UE and AMF to generate the same key defined by the standard (00 or FF or any other agreed constant).

[0126] As specified in Annex A.9 of TS 33.501, when from K AMF and the uplink NAS COUNT exported key K in UE and AMF gNB K WAGF K TNGF K TWIF and K N3IWF When doing so, the following parameters should be used to form the input S (key derivation function) of the KDF.

[0127] -FC=0x6E

[0128] -P0=Uplink NAS COUNT

[0129] -L0 = the length of the uplink NAS COUNT (i.e., 0x00 0x04).

[0130] -P1=Access type distinguisher

[0131] -L1 = Length of the access type distinguisher (i.e., 0x00 0x01)

[0132] The values ​​for the access type distinguisher are defined in Table 1 below. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use.

[0133] Exporting K gNB When tracing, the access type distinguisher should be set to the 3GPP value (0x01). In exporting K... N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02). Table 1: Access Type Differentiator

[0134]

[0135] To generate K TWIF The input key KEY is a 256-bit key K. AMF .

[0136] This feature is used when establishing an encrypted 5G radio bearer and performing instant key changes.

[0137] Since the N5CW device does not support NAS on non-3GPP access, therefore, for the N5CW device, in order to generate K... TWIF P0 is set to 0, and L0 contains K. TWIF The length of P0 during key generation. Alternatively, the NAS count P0 can be set to "0x00" or "0xFF" or any fixed constant value.

[0138] Solution 2

[0139] Figure 3A and Figure 3B The signaling diagram for Solution 2 is shown. Figure 3A Steps S301 to S304b are similar Figure 1A Steps S101 to S104b.

[0140] Upon receiving the N2 message from S304b, the AMF detects the presence of a security context and generates a fresh key via a new RAND / COUNT. In this context, the NAS count is determined from the new RAND / COUNT, and K...TWIF Using fresh NAS counts from K AMF Exported.

[0141] exist Figure 3B In S310a, AMF provides a new RAND / COUNT to TWIF in the N2 message NAS security mode command.

[0142] Figure 3B Steps S310b to S312a are similar Figure 1B Steps S110b to S112a.

[0143] exist Figure 3B In the S312b, TWIF provides a new RAND / COUNT to the trusted WLAN AP in the AAA response.

[0144] exist Figure 3B In the S312c, the trusted WLAN AP provides a new RAND / COUNT to the N5CW device in the EAP success message.

[0145] The N5CW device then uses the new RAND / COUNT to determine the fresh NAS count P0 for use from K. AMF Calculate K TWIF .

[0146] The remainder of steps S312d and S312e to S314 are similar. Figure 1B Steps S112d to S114.

[0147] According to Solution 1, after primary authentication, the N5CW and AMF generate the same counter value (e.g., =0), or the AMF provides the UE with a counter value (COUNT) via the EAP payload (e.g., the initial value of the counter) or a newly generated random number (RAND) (also referred to as the random value in this specification). This counter value is incremented each time to maintain freshness. The N5CW device can increment the counter value when requested to provide the UE identifier. The AMF increments the counter when it has an already available security context.

[0148] K TWIF The generation is similar to that described above for solution 1.

[0149] Solution 2, Option A

[0150] When from K AMF and the uplink NAS COUNT exported key K in UE and AMF gNB K WAGF K TNGF K TWIF and KN3IWF When doing so, the following parameters should be used to form the input S of the KDF.

[0151] -FC=0x6E

[0152] -P0=COUNTER received from AMF

[0153] -L0 = the length of COUNTER (i.e., 0x00 0x04)

[0154] -P1=Access type distinguisher

[0155] -L1 = Length of the access type distinguisher (i.e., 0x00 0x01)

[0156] The values ​​for the access type distinguisher are defined in Table 1 above. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use.

[0157] Exporting K gNB When tracing, the access type distinguisher should be set to the 3GPP value (0x01). In exporting K... N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02).

[0158] To generate K TWIF The key should be a 256-bit key. AMF .

[0159] This feature is used when establishing an encrypted 5G radio bearer and performing instant key changes.

[0160] According to Solution 2, Option A, the counter value will increment with each key refresh.

[0161] Solution 2, Option B

[0162] When from K AMF and the uplink NAS COUNT exported key K in UE and AMF gNB K WAGF K TNGF K TWIF and K N3IWF When doing so, the following parameters should be used to form the input S of the KDF.

[0163] -FC=0x6E

[0164] -P0=RAND received from AMF

[0165] -L0 = the length of RAND (i.e., 0x00 0x04).

[0166] -P1=Access type distinguisher

[0167] -L1 = Length of the access type distinguisher (i.e., 0x00 0x01)

[0168] The values ​​for the access type distinguisher are defined in Table 1 above. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use.

[0169] Exporting K gNB When tracing, the access type distinguisher should be set to the 3GPP value (0x01). In exporting K... N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02).

[0170] To generate K TWIF The key should be a 256-bit key. AMF .

[0171] This feature is used when establishing an encrypted 5G radio bearer and performing instant key changes.

[0172] like Figure 3B As shown in the diagram, the RAND value will be provided to the UE by the AMF.

[0173] Solution 2b

[0174] Figure 4A and Figure 4B The diagram illustrates the signaling process of an AUN3 device (i.e., an N5CW device) that uses EAP-AKA' to support a 5G key hierarchy.

[0175] In step S401a, the AUN3 device establishes a WLAN connection with the WLAN access network (AN) using the procedure specified in IEEE 802.11.

[0176] In steps S401b and S401c, L2 connection and EAP identifier retrieval are performed. The AUN3 device sends back an EAP response / identification message. The AUN3 device uses SUCI in the NAI format (i.e., the username@realm format specified in Clause 28.7.3 of TS 23.003).

[0177] In steps S402b, S403b, and S403c, if the RG is a 5G-RG, the 5G-RG sends a NAS registration request message to the AMF, including the new encryption indicator required by the received SUCI and AUN3 devices.

[0178] In S404, the authentication process of EAP-AKA is performed as defined in Section 6.1.3.1 of TS 33.501.

[0179] In S405, based on the instructions in step S403b, the AMF derives the RG key as defined below.

[0180] In S406, the AMF sends the NAS security mode command mode and provides the RG key (KRG) to the RG.

[0181] In step S407a, 5G-RG derives the PMK key from the RG key (KRG).

[0182] In S408a and S408b, the RG and AUN3 devices will export the WLAN key from the PMK.

[0183] In S409, the AUN3 device performs a four-way handshake to establish a secure connection with the WLAN AN.

[0184] When from K AMF and the uplink NAS COUNT exported key K in UE and AMF gNB K WAGF K TNGF K TWIF and K N3IWF When doing so, the following parameters should be used to form the input S of the KDF.

[0185] -FC=0x6E

[0186] -P0=Uplink NAS COUNT

[0187] -L0 = the length of the uplink NAS COUNT (i.e., 0x00 0x04).

[0188] -P1=Access type distinguisher

[0189] -L1 = Length of the access type distinguisher (i.e., 0x00 0x01)

[0190] The values ​​for the access type distinguisher are defined in Table 2. Values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and values ​​0xf1 through 0xff are reserved for private use.

[0191] Exporting K gNBWhen tracing, the access type distinguisher should be set to the 3GPP value (0x01). In exporting K... N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02). Table 2: Access Type Differentiators

[0192]

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

[0194] This feature is used when establishing an encrypted 5G radio bearer and performing instant key changes.

[0195] Since AUN3 devices supporting 5G key hierarchy (i.e., N5CW devices) do not support NAS on non-3GPP access, P0 is set to 0 for N5CW devices, and L0 contains K. TWIF Key or K RG The length of P0 during generation.

[0196] Solution 3

[0197] Figure 5 The signaling diagram for Solution 3 is shown.

[0198] Steps S501 to S504b correspond to Figure 3A Steps S301 to S304b.

[0199] In step S504c, the AMF detects that it already has a security context identified by the GUTI. However, since the request in S504b originated from TWIF and key refresh is not supported, the AMF performs full authentication. Therefore, the remainder of the process is identical to that defined in Section 7A.2.4-1 of TS 33.501. In other words, the remainder of the process corresponds to Figure 1A and Figure 1B Steps S105 to S113.

[0200] According to Solution 3, when TWIF requests AMF to provide K twif Once the key and the AMF already have the security context, the AMF should initiate master authentication. In this way, master authentication is performed every time the N5CW device is reattached.

[0201] Now for reference Figure 6 , Figure 6Simplified block diagrams of control units 610 and 620 applicable to at least some example embodiments are illustrated. According to implementation examples, Figure 2 Process 1 is implemented by the control unit 610, and Figure 2 Process 2 is implemented by the control unit 620.

[0202] Control units 610 and 620 include processing resources (e.g., processing circuitry) 611 and 621, memory resources (e.g., memory circuitry) 612 and 622, and interfaces (e.g., interface circuitry) 613 and 623 coupled via wired or wireless connections 614 and 624.

[0203] Control units 610 and 620 can be coupled to each other via connection 63, which represents a connection via several entities (e.g., WLANAP (RG) and TWIF (W-AGF)).

[0204] According to the example implementation, memory resources 612 and 622 are of any type suitable for the local technical environment and are implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. Processing resources 611 and 621 are of any type suitable for the local technical environment and, as non-limiting examples, include one or more of general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures.

[0205] According to the implementation example, memory resources 612, 622 include one or more non-transient computer-readable storage media that store one or more programs that, when executed by processing resources 611, 621, enable control units 610, 620 to function as UE (e.g., N5CW device, AUN3 device) and AMF, respectively, as described above.

[0206] According to at least some example embodiments, AMF is hardware that includes software, or simply software that can be executed by at least one processor of one or more computers (e.g., a distributed computing system or a cloud computing system).

[0207] According to the example, control unit 610 is executing Figure 2 The apparatus of process 1 may be included therein. For example, the control unit 610 may be a user device or may be included therein.

[0208] According to the example, control unit 620 is executing Figure 2 The apparatus of process 2 may be included therein. For example, the control unit 620 may be the core network of a cellular communication network or may be included therein.

[0209] The UE can include cellular phones, smartphones, laptops, handheld devices, tablets, vehicles, etc. The UE can be of a fixed shape or can be used with different shape factors.

[0210] Furthermore, as used in this application, the term "circuit system" may refer to one or more of the following:

[0211] (a) Hardware-only implementations (such as implementations in analog and / or digital-only circuit systems); and

[0212] (b) A combination of hardware circuitry and software, such as (if applicable):

[0213] (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and

[0214] (ii) Any part having software (including (multiple) digital signal processors), hardware processors, software, and (multiple) memories, which work together to enable a device such as a mobile phone or server to perform various functions.

[0215] (c) Multiple hardware circuits and / or multiple processors, such as multiple microprocessors or a portion thereof, that require software (e.g., firmware) to operate, but the software may not be present when operation is not required.

[0216] This definition of "circuit system" applies to all uses of the term in this application, including in any claim. As yet another example, as used herein, the term "circuit system" also covers implementations of hardware circuitry or processors (or processors) alone, or a portion thereof, and their accompanying software and / or firmware. For example, and if applicable to a particular claim element, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for mobile devices or similar integrated circuits used in servers, cellular network devices, or other computing or network devices.

[0217] The term “non-transient” as used in this article refers to the limitation on the medium itself (i.e., tangible, not signal), rather than the limitation on the persistence of data storage (e.g., RAM and ROM).

[0218] It is important to note that, as used in this article, “at least one of the following: ” and “at least one of ” and similar wording indicate at least any one element or at least any two or more elements or at least all elements, wherein the list of two or more elements is joined by “and” or “or”.

[0219] In embodiments, an apparatus for executing at least some of the described embodiments includes at least one processor and at least one memory, the memory including instructions that, when executed by the at least one processor, cause the apparatus to perform functionality according to any of the described embodiments. According to one aspect, when the at least one processor executes the instructions, the instructions cause the apparatus to perform functionality according to any of the described embodiments. According to another embodiment, an apparatus for executing at least some embodiments includes at least one processor and at least one memory including instructions, wherein the at least one processor and the instructions perform at least some functionality according to any of the described embodiments. Thus, at least one processor, memory, and instructions form a processing unit for executing at least some of the described embodiments. According to yet another embodiment, an apparatus for executing at least some embodiments includes a circuit system including at least one processor and at least one memory instruction. When activated, the circuit system causes the apparatus to perform at least some functionality according to any of the described embodiments.

[0220] It should be understood that the above description is illustrative and should not be construed as restrictive. Various modifications and applications will arise for those skilled in the art without departing from the true spirit and scope defined by the appended claims.

[0221] The following text indicates the change request for TS 33.501:

[0222] 7A.2.4 does not support authentication of 5GC NAS devices connected via WLAN.

[0223] The N5CW device can register to the 5GC using 3GPP credentials and establish a 5GC connection via the Trusted WLAN Access Network. The reference architecture is captured in section 4.2.8.5.2 of TS 23.501[2]. The 3GPP credentials are stored as defined in section 6.1.1.1. The Trusted WLAN Interoperability Function (TWIF) provides interoperability, implements the connection to the 5GC, implements the NAS protocol stack, and exchanges NAS messages with the AMF on behalf of the N5CW device. A single EAP-AKA' authentication process is performed to connect the N5CW device to both the Trusted WLAN Access Network and the 5G core network.

[0224] refer to Figure 7 :

[0225] 0. The N5CW device selects the PLMN and a trusted WLAN that supports “NAS-free 5G connectivity” to the PLMN by using the procedure specified in Section 6.3.12a of TS 23.501[2] “Access network selection for devices that do not support 5GC NAS over WLAN”.

[0226] Steps 1 to 10: Initial registration with 5GC.

[0227] 1. The N5CW device associates with a trusted WLAN network and initiates the EAP-AKA authentication process.

[0228] 2. The N5CW device should provide its Network Access Identifier (NAI). Trusted WLAN Access Points (TWAPs) may select a Trusted WLAN Interoperability Function (TWIF) based on the received domain information and send an AAA request to the selected TWIF.

[0229] If the N5CW device is registering with the 5GC via 3GPP access for the first time when initiating the above process, then the NAI should include the SUCI. The SUCI should be constructed as specified in Clause 6.12.2.

[0230] If the N5CW device has already registered with the 5GC via 3GPP access when initiating the above process, then the NAI includes the 5G-GUTI assigned to the N5CW device via 3GPP access. This allows TWIF to select the same AMF as the AMF serving the N5CW device via 3GPP access in step 4a below.

[0231] 3. TWIF should create a 5GC registration request message on behalf of the N5CW device. TWIF 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. The registration type indicates "Initial Registration".

[0232] 4. TWIF should select AMF (e.g., if provided by an N5CW device, by using 5G-GUTI in NAI) and should send an N2 message to AMF, which includes the registration request, user location and AN type.

[0233] 5. If the AMF triggers the authentication process, it sends a request to the ASF by sending a Nausf_UEAuthentication_Authenticate request message. The Nausf_UEAuthentication_Authenticate request message contains either SUCI or SUPI (if the AMF receives a valid 5G-GUTI). The request message also contains an indication that the request is from an N5CW device.

[0234] In this version of the manual, the AMF should initiate master authentication even if it already has a security context identified by 5G-GUTI. In this way, master authentication is performed each time the N5CW device is reattached, and the KTWIF key at the UE is refreshed.

[0235] 6. AUSF should send a Nudm_UEAuthentication_Get request to UDM, which includes SUCI or SUPI and an N5CW indication.

[0236] 7. Upon receiving a Nudm_UEAuthentication_Get request, if a SUCI is received, the UDM should invoke SIDF. SIDF should remove the SUCI to obtain a SUPI before the UDM can process the request. The UDM can select the authentication method based on the "Domain" portion of the SUPI, the N5CW device indicator, a combination of the "Domain" portion and the N5CW device indicator, or a UDM-local policy.

[0237] 8. The EAP-AKA procedure will be triggered to perform mutual authentication between the N5CW device and the home network as specified in Section 6.1.3.1.

[0238] The EAP-AKA message occurs between the N5CW device and the AUSF. Through the N2 interface, the EAP message is encapsulated within a NAS authentication message. EAP-AKA messages exchanged between the N5CW device and the TWIF should be encapsulated in Layer-2 packets, such as IEEE 802.3 / 802.1x packets, IEEE 802.11 / 802.1x packets, PPP packets, etc.

[0239] 9. NAS security context is not required in this scenario. AMF should receive the K... AMF Key export K TWIF The key is as specified in Annex A.9. The NAS security between AMF and TWIF is similar to that of an unauthenticated emergency call being established, i.e., with null encryption and null integrity protection.

[0240] Note: The N5CW device does not support NAS; therefore, it is not possible to use a NAS counter in the N5CW device.

[0241] 10a. AMF should send a NAS security mode command to TWIF. The NAS security mode command should include an EAP success message and a null security algorithm.

[0242] 10b. TWIF should not directly forward the EAP success message to N5CW, but should instead store the EAP success message and wait for K. TWIF .

[0243] 10c. TWIF should send a NAS security mode completion message to AMF.

[0244] 11. AMF sends an N2 Initial Context Setup Request and sets K TWIFThe key is provided to TWIF.

[0245] 12. TWIF should be from the K specified in Appendix A.22 TNGF Key export TNAP key K TNAP The TNAP key and EAP success message are sent to a trusted WLAN access point, which then forwards the EAP to the N5CW device. The TNAP key corresponds to a PMK (pair master key), which is used to protect WLAN air interface communications in accordance with IEEE 802.11

[80] . A layer-2 or layer-3 connection is established between the trusted WLAN access point and the TWIF to transmit all user plane services of the N5CW device to the TWIF. This connection is later bound to an N3 connection created for the N5CW device.

[0246] 13. TWIF should send an N2 Initial Context Setup response message to AMF.

[0247] 14. The following steps are captured in section 4.12b.2 of TS 23.502[8].

[0248] A.9 K gNB K WAGF K TNGF K TWIF and K N3IWF Exported functions

[0249] When from K AMF and the uplink NAS COUNT exported key K in UE and AMF gNB K WAGF K TNGF K TWIF and K N3IWF When doing so, the following parameters should be used to form the input S of the KDF.

[0250] -FC=0x6E

[0251] -P0=Uplink NAS COUNT

[0252] -L0 = the length of the uplink NAS COUNT (i.e., 0x00 0x04).

[0253] -P1=Access type distinguisher

[0254] -L1 = Length of the access type distinguisher (i.e., 0x00 0x01)

[0255] The values ​​for the access type distinguisher are defined in Table A.9-1. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use.

[0256] When exporting KgNB, the access type distinguisher should be set to a 3GPP value (0x01). N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02). Table A.9-1: Access Type Differentiator

[0257]

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

[0259] This feature is used when establishing an encrypted 5G radio bearer and performing instant key changes.

[0260] Since the N5CW device does not support NAS over non-3GPP access, P0 is set to 0 for the N5CW device, and L0 contains the length of P0 in the KTWIF key generation.

[0261] Authentication of AUN3 (i.e., N5CW) devices supporting 5G key hierarchy behind 7B.Y 5G-RG

[0262] AUN3 devices that support the 5G key hierarchy are also known as N5CW devices. AUN3 devices that support the 5G key hierarchy behind 5G-RG (i.e., N5CW devices) are registered to 5GC by 5G-RG and are certified by 5GC using EAP-AKA' as specified in RFC 5448

[12] .

[0263] Editor's note: The AUN3 device following FN-RG is certified as FFS and is aligned with SA2.

[0264] refer to Figure 8 :

[0265] 1a. The AUN3 device establishes a WLAN connection with the WLAN access network (AN) using the procedure specified in IEEE 802.11.

[0266] 1b, 1c. Perform L2 connection and EAP identifier retrieval. The AUN3 device sends back an EAP response / identification message. The AUN3 device uses SUCI in the NAI format (i.e., the username@realm format specified in Clause 28.7.3 of TS 23.003).

[0267] 2b, 3b, 3c. If the RG is 5G-RG, the 5G-RG sends a NAS registration request message to the AMF, including the new indicators required for encryption by the received SUCI and AUN3 devices.

[0268] 4. Perform the authentication process of EAP-AKA as defined in Section 6.1.3.1 of TS 33.501[4].

[0269] 5. Based on the instructions in step 3, the AMF derives the RG key as defined in A.9.

[0270] 6. AMF sends the NAS security mode command mode and provides the RG key (KRG) to RG.

[0271] 7. Derive the PMK key from the RG key (KRG) in 5G-RG.

[0272] 8. The RG and AUN3 devices will export the WLAN key from PMK.

[0273] 9. The AUN3 device performs a four-way handshake to establish a secure connection with the WLAN AN.

[0274] A.9 K gNB K WAGF K TNGF K TWIF K N3IWF K RG Exported functions

[0275] When from K AMF and the uplink NAS COUNT exported key K in UE and AMF gNB K WAGF K TNGF K TWIF and K N3IWF When doing so, the following parameters should be used to form the input S of the KDF.

[0276] -FC=0x6E

[0277] -P0=Uplink NAS COUNT

[0278] -L0 = the length of the uplink NAS COUNT (i.e., 0x00 0x04).

[0279] -P1=Access type distinguisher

[0280] -L1 = Length of the access type distinguisher (i.e., 0x00 0x01)

[0281] The values ​​for the access type distinguisher are defined in Table A.9-1. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use.

[0282] When exporting KgNB, the access type distinguisher should be set to a 3GPP value (0x01). N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02). Table A.9-1: Access Type Differentiator

[0283]

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

[0285] This feature is used when establishing an encrypted 5G radio bearer and performing instant key changes.

[0286] Since AUN3 devices supporting 5G key hierarchy (i.e., N5CW devices) do not support NAS on non-3GPP access, P0 must be set to 0 for N5CW devices, and L0 must contain K. WAGF Key or K RG The length of P0 during generation.

Claims

1. A method used by a device, the method comprising: Initiate a registration process to register with the core network of the cellular communication network and establish a connection with the core network via the local access network; Regarding the authentication process associated with the registration process, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function for calculating the second key, wherein the first key is a key for core network functions and the second key is a key for enabling the connection to the core network. as well as Based on the second key, the connection is established with the core network via the connection enable function and the core network function.

2. The method of claim 1, wherein the device is capable of registering to the core network using credentials of the cellular communication network, but does not support access via a non-access stratum, which is different from access via the access network of the cellular communication network.

3. The method according to claim 1 or 2, further comprising: The first key is obtained via an authentication and key negotiation process performed in conjunction with the registration process, which is performed between the device, the local access network, and the core network, and the registration process is associated with the authentication process, which is the main authentication process.

4. The method of claim 3, wherein the authentication and key negotiation process is performed for each registration process initiated by the device.

5. The method according to any one of claims 1 to 3, wherein the specific input parameter includes a non-access stratum NAS count.

6. The method of claim 5, wherein the NAS count is a fixed constant value.

7. The method according to claim 5, further comprising: The NAS count is determined based on at least one of a random value or a counter value.

8. The method according to claim 7, further comprising: At least one of the random value or the initial value of the counter value is obtained from the core network function via a payload associated with the authentication process.

9. The method according to claim 7 or 8, further comprising: When a request is made to provide the identifier of the device associated with the registration process, the counter value is incremented, and the registration process is associated with the authentication process that is not the main authentication process.

10. The method according to claim 7 or 8, further comprising: The random value is obtained via a payload associated with the registration process, which is associated with the authentication process that is not the main authentication process.

11. A method used by core network functions of a cellular communication network, the method comprising: Regarding the authentication process associated with the registration process initiated by the device, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function for calculating the second key, wherein the first key is the key of the core network function and the second key is the key of the connection enabling function that enables the connection between the device and the core network via the local access network. as well as Based on the second key, the connection between the device and the core network is established via the connection enable function.

12. The method of claim 11, further comprising: The first key is provided via an authentication and key negotiation process performed in conjunction with the registration process, which is associated with an authentication process that serves as the primary authentication process, between the device, the local access network, and the core network.

13. The method of claim 12, wherein the authentication and key negotiation process is performed for each registration process initiated by the device.

14. The method of claim 11 or 12, wherein the specific input parameter includes a non-access stratum NAS count.

15. The method of claim 14, wherein the NAS count is a fixed constant value.

16. The method of claim 14, further comprising: The NAS count is determined based on at least one of a random value or a counter value.

17. The method of claim 16, further comprising: The connection enable function is provided with at least one of the random value or the initial value of the counter value via a payload associated with the authentication process.

18. The method according to claim 16 or 17, further comprising: When a request is made to register the device in association with the registration process, which is associated with an authentication process that is not the primary authentication process, the counter value is incremented.

19. The method according to claim 16 or 17, further comprising: The random value is provided to the connection enable function via a payload associated with the registration process, which is associated with the authentication process that is not the primary authentication process.

20. A non-transient computer-readable storage medium storing a program, said program, when executed by a computer, causes the computer to at least: Initiate a registration process to register with the core network of the cellular communication network and establish a connection with the core network via the local access network; Regarding the authentication process associated with the registration process, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function for calculating the second key, wherein the first key is a key for core network functions and the second key is a key for enabling the connection to the core network. as well as Based on the second key, the connection is established with the core network via the connection enable function and the core network function.

21. A non-transient computer-readable storage medium storing a program, said program, when executed by a computer, causes the computer to at least: Regarding the authentication process associated with the device-initiated registration process, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function used to calculate the second key. The first key is a key for the core network function of the cellular communication network's core network, and the second key is a key for a connection-enabling function that enables the device's connection to the core network via the local access network; and Based on the second key, the connection between the device and the core network is established via the connection enable function.

22. An apparatus comprising at least one processor and at least one memory, the at least one memory including computer program code, the at least one memory and the computer program code being configured together with the at least one processor to cause the apparatus to at least: Initiate a registration process to register with the core network of the cellular communication network and establish a connection with the core network via the local access network; Regarding the authentication process associated with the registration process, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function for calculating the second key, wherein the first key is a key for core network functions and the second key is a key for enabling the connection to the core network. as well as Based on the second key, the connection is established with the core network via the connection enable function and the core network function.

23. The apparatus of claim 22, wherein the apparatus is capable of registering to the core network using credentials of the cellular communication network, but does not support access via a non-access stratum, the access being different from access via an access network of the cellular communication network.

24. The apparatus of claim 22 or 23, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: The first key is obtained via an authentication and key negotiation process performed in conjunction with the registration process, which is performed between the device, the local access network, and the core network, and the registration process is associated with the authentication process, which is the main authentication process.

25. The apparatus of claim 24, wherein the authentication and key negotiation process is performed for each registration process initiated by the device.

26. The apparatus of any one of claims 22 to 24, wherein the particular input parameter includes a non-access stratum (NAS) count.

27. The apparatus of claim 26, wherein the NAS count is a fixed constant value.

28. The apparatus of claim 27, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: The NAS count is determined based on at least one of a random value or a counter value.

29. The apparatus of claim 28, wherein the at least one memory and the computer program code are configured together with the at least one processor to further: At least one of the random value or the initial value of the counter value is obtained from the core network function via a payload associated with the authentication process.

30. The apparatus of claim 28 or 29, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: When a request is made to provide the identifier of the device associated with the registration process, the counter value is incremented, and the registration process is associated with the authentication process that is not the main authentication process.

31. The apparatus of claim 28 or 29, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: The random value is obtained via a payload associated with the registration process, which is associated with the authentication process that is not the main authentication process.

32. An apparatus comprising at least one processor and at least one memory, the at least one memory including computer program code, the at least one memory and the computer program code being configured together with the at least one processor to cause the apparatus to at least: Regarding the authentication process associated with the device-initiated registration process, the second key is calculated based on the first key by inputting a first key and specific input parameters into a key derivation function used to calculate the second key. The first key is a key for the core network function of the cellular communication network's core network, and the second key is a key for a connection-enabling function that enables the device's connection to the core network via the local access network; and Based on the second key, the connection between the device and the core network is established via the connection enable function.

33. The apparatus of claim 32, wherein the at least one memory and the computer program code are configured together with the at least one processor to further: The first key is provided via an authentication and key negotiation process performed in conjunction with the registration process, which is associated with the authentication process as the primary authentication process, between the device, the local access network, and the core network.

34. The apparatus of claim 33, wherein the authentication and key negotiation process is performed for each registration process initiated by the apparatus.

35. The apparatus of claim 32 or 33, wherein the specific input parameter includes a non-access stratum NAS count.

36. The apparatus of claim 35, wherein the NAS count is a fixed constant value.

37. The apparatus of claim 35, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: The NAS count is determined based on at least one of a random value or a counter value.

38. The apparatus of claim 37, wherein the at least one memory and the computer program code are configured together with the at least one processor to further: The connection enable function is provided with at least one of the random value or the initial value of the counter value via a payload associated with the authentication process.

39. The apparatus of claim 37 or 38, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: When a request is made to register the device in association with the registration process, which is associated with an authentication process that is not the primary authentication process, the counter value is incremented.

40. The apparatus of claim 37 or 38, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to further: The random value is provided to the connection enable function via a payload associated with the registration process, which is associated with the authentication process that is not the primary authentication process.

Images