SECURE INFORMATION PUSHING BY SERVICE APPLICATIONS IN COMMUNICATION NETWORKS

Abstract

This disclosure generally relates to securely pushing messages from an AF to a User Equipment (UE) in communication networks. Performed by a wireless device in a wireless network, the method includes receiving, from a first network element hosting an Application Function (AF), a message comprising one of: an AKMA (Authentication and Key Management for Applications) key identifier (ID) identifying an AKMA anchor key of the wireless device; or a set of parameters indicative of the AKMA key ID; and storing the AKMA key ID and an AF key associated with the first network element in a security context, wherein the first network element outside of a core network of the wireless network.

Description

TECHNICAL FIELD

This disclosure relates to securely pushing messages from an Application Function entity to a User Equipment (UE) in communication networks.

BACKGROUND

In a communication network, the mutual authentication of a User Equipment (UE) and the communication network may be performed to allow only authenticated UE and the authenticated communication network to communicate with each other. Application Function entities may provide various application services to the UE once authenticated. Efficient and robust authentication mechanism involving various network elements is critical to provide secure communication between Application Function entity and the UE, and to protect the credentials of the UE and the Application Function entity.

SUMMARY

This disclosure relates to securely pushing messages from an Application Function entity to a User Equipment (UE) in communication networks, and in particular, to establishing a security mechanism between the UE and the Application Function entity for perform such message push securely.

In one embodiment, the present disclosure describes a method for wireless communication. Performed by a wireless device in a wireless network, the method includes receiving, from a first network element hosting an Application Function (AF), a message comprising one of: an AKMA (Authentication and Key Management for Applications) key identifier (ID) identifying an AKMA anchor key of the wireless device; or a set of parameters indicative of the AKMA key ID; and storing the AKMA key ID and an AF key associated with the first network element in a security context, wherein the first network element outside of a core network of the wireless network.

In another embodiment, the present disclosure describes a method for wireless communication. Performed by a first network element in a wireless network in a wireless network, the first network element hosting an application function, the method includes receiving a first message from a second network element in the wireless network, the first message comprising configuration information for securely pushing a message from the first network element to a wireless device under an AKMA framework, and the second network element hosting an AKMA Anchor Function (AAnF); and generating a security context for pushing the message from the first network element to the wireless device based on the first message, wherein the first network element is outside a core network of the wireless network.

In another embodiment, the present disclosure describes a method for wireless communication. Performed by a first network element in a wireless network, the first network element hosting an AKMA anchor function, the method includes determining configuration information for securely pushing a message from a second network element hosting an application function to a wireless device under an AKMA framework, wherein the second network element is outside of a core network of the wireless network.

In another embodiment, the present disclosure describes a method for wireless communication. Performed by a first network element in a wireless network, the first network element hosting an authentication function, the method includes receiving, from a second network element hosting an AKMA anchor function, a first message requesting an AKMA context for a wireless device in the wireless network, the first message comprising a SUPI of the wireless device; transmitting, to a third network element, a second message comprising the SUPI of the wireless device to request the AKMA context; and receiving, from the third network element, a third message comprising: an Authentication Vector (AV) corresponding to an authentication method; and an authentication method indicator indicting the authentication method, wherein the authentication method comprises one of a 5G-AKA method or an EAP-AKA′ method.

In another embodiment, a network element or wireless device comprising a processor and a memory is disclosed. The processor may be configured to read computer code from the memory to implement any of the methods above.

In yet another embodiment, a computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon is disclosed. The computer code, when executed by a processor, may cause the processor to implement any one of the methods above.

The above embodiments and other aspects and alternatives of their implementations are explained in greater detail in the drawings, the descriptions, and the claims below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary communication network including various terminal devices, a carrier network, data network, and service applications.

FIG. 2 shows exemplary network functions or network nodes in a communication network.

FIG. 3 shows exemplary network functions or network nodes in a wireless communication network.

FIG. 4 shows an exemplary network model for an Authentication and Key Management for Applications (AKMA) framework.

FIG. 5 shows an exemplary key hierarchy under the AKMA framework.

FIG. 6 shows an exemplary logic flow for establishing security context between the UE and the Application Function.

DETAILED DESCRIPTION

An exemplary communication network, shown as 100 in FIG. 1, may include terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. The carrier network 102, for example, may include access networks 120 and a core network 130. The carrier network 102 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among terminal devices 110 and 112, between the terminal devices 110 and 112 and the service applications 140, or between the terminal devices 110 and 112 and the other data networks 150. Communication sessions and corresponding data paths may be established and configured for such data transmission. The Access networks 120 may be configured to provide terminal devices 110 and 112 network access to the core network 130. The Access network 120 may, for example, support wireless access via radio resources, or wireline access. The core network 130 may include various network nodes or network functions configured to control the communication sessions and perform network access management and data traffic routing. The service applications 140 may be hosted by various application servers that are accessible by the terminal devices 110 and 112 through the core network 130 of the carrier network 102. A service application 140 may be deployed as a data network outside of the core network 130. Likewise, the other data networks 150 may be accessible by the terminal devices 110 and 112 through the core network 130 and may appear as either data destination or data source of a particular communication session instantiated in the carrier network 102.

The core network 130 of FIG. 1 may include various network nodes or functions geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or as software entities. A network node may each be configured with one or more types of network functions. These network nodes or network functions may collectively provide the provisioning and routing functionalities of the core network 130. The term “network nodes” and “network functions” are used interchangeably in this disclosure.

FIG. 2 further shows an exemplary division of network functions in the core network 130 of a communication network 200. While only single instances of network nodes or functions are illustrated in FIG. 2, those having ordinary skill in the art readily understand that each of these network nodes may be instantiated as multiple instances of network nodes that are distributed throughout the core network 130. As shown in FIG. 2, the core network 130 may include but is not limited to network nodes such as access management network node (AMNN) 230, authentication network node (AUNN) 260, network data management network node (NDMNN) 270, session management network node (SMNN) 240, data routing network node (DRNN) 250, policy control network node (PCNN) 220, and application data management network node (ADMNN) 210. Exemplary signaling and data exchange between the various types of network nodes through various communication interfaces are indicated by the various solid connection lines in FIG. 2. Such signaling and data exchange may be carried by signaling or data messages following predetermined formats or protocols.

The implementations described above in FIGS. 1 and 2 may be applied to both wireless and wireline communication systems. FIG. 3 illustrates an exemplary cellular wireless communication network 300 based on the general implementation of the communication network 200 of FIG. 2. FIG. 3 shows that the wireless communication network 300 may include user equipment (UE) 310 (functioning as the terminal device 110 of FIG. 2), radio access network (RAN) 320 (functioning as the access network 120 of FIG. 2), data network (DN) 150, and core network 130 including access management function (AMF) 330 (functioning as the AMNN 230 of FIG. 2), session management function (SMF) 340 (functioning as the SMNN 240 of FIG. 2), application function (AF) 390 (functioning as the ADMNN 210 of FIG. 2), user plane function (UPF) 350 (functioning as the DRNN 250 of FIG. 2), policy control function 322 (functioning as the PCNN 220 of FIG. 2), authentication server function (AUSF) 360 (functioning as the AUNN 260 of FIG. 2), and universal data management (UDM) function 370 (functioning as the UDMNN 270 of FIG. 2). Again, while only single instances for some network functions or nodes of the wireless communication network 300 (the core network 130 in particular) are illustrated in FIG. 3, those of ordinary skill in the art readily understand that each of these network nodes or functions may have multiple instances that are distributed throughout the wireless communication network 300. While the AF 390 is depicted as part of the core network 130 in FIG. 3, they may be considered as associated with particular service applications 140 and may be considered as being outside of the core network 140.

In FIG. 3, the UE 310 may be implemented as various types of mobile devices that are configured to access the core network 130 via the RAN 320. The UE 310 may include but is not limited to mobile phones, laptop computers, tablets, Internet-Of-Things (IoT) devices, distributed sensor network nodes, wearable devices, and the like. The UE may also be Multi-access Edge Computing (MEC) capable UE that supports edge computing. The RAN 320 for example, may include a plurality of radio base stations distributed throughout the service areas of the carrier network. The communication between the UE 310 and the RAN 320 may be carried in over-the-air (OTA) radio interfaces as indicated by 311 in FIG. 3.

Continuing with FIG. 3, the UDM 370 may form a permanent storage or database for user contract and subscription data. The UDM may further include an authentication credential repository and processing function (ARPF, as indicated in 370 of FIG. 3) for storage of long-term security credentials for user authentication, and for using such long-term security credentials as input to perform computation of encryption keys as described in more detail below. To prevent unauthorized exposure of UDM/ARPF data, the UDM/ARPF 370 may be located in a secure network environment of a network operator or a third-party.

The AMF/SEAF 330 may communicate with the RAN 320, the SMF 340, the AUSF 360, the UDM/ARPF 370, and the PCF 322 via communication interfaces indicated by the various solid lines connecting these network nodes or functions. The AMF/SEAF 330 may be responsible for UE to non-access stratum (NAS) signaling management, and for provisioning registration and access of the UE 310 to the core network 130 as well as allocation of SMF 340 to support communication need of a particular UE. The AMF/SEAF 330 may be further responsible for UE mobility management. The AMF may also include a security anchor function (SEAF, as indicated in 330 of FIG. 3) that, as described in more detail below, and interacts with AUSF 360 and UE 310 for user authentication and management of various levels of encryption/decryption keys. The AUSF 360 may terminate user registration/authentication/key generation requests from the AMF/SEAF 330 and interact with the UDM/ARPF 370 for completing such user registration/authentication/key generation.

The SMF 340 may be allocated by the AMF/SEAF 330 for a particular communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for allocating UPF 350 to support the communication session and data flows therein in a user data plane and for provisioning/regulating the allocated UPF 350 (e.g., for formulating packet detection and forwarding rules for the allocated UPF 350). Alternative to being allocated by the SMF 340, the UPF 350 may be allocated by the AMF/SEAF 330 for the particular communication session and data flows. The UPF 350 allocated and provisioned by the SMF 340 and AMF/SEAF 330 may be responsible for data routing and forwarding and for reporting network usage by the particular communication session. For example, the UPF 350 may be responsible for routing end-end data flows between UE 310 and the DN 150, between UE 310 and the service applications 140. The DN 150 and the service applications 140 may include but are not limited to data network and services provided by the operator of the wireless communication network 300 or by third-party data network and service providers.

The PCF 322 may be responsible for managing and providing various levels of policies and rules applicable to a communication session associated with the UE 310 to the AMF/SEAF 330 and SMF 340. As such, the AMF/SEAF 330, for example, may assign SMF 340 for the communication session according to policies and rules associated with the UE 310 and obtained from the PCF 322. Likewise, the SMF 340 may allocate UPF 350 to handle data routing and forwarding of the communication session according to policies and rules obtained from the PCF 322.

While FIGS. 1-3 and the various exemplary implementations described below are based on cellular wireless communication networks, the scope of this disclosure is not so limited and the underlying principles are applicable to other types of wireless and wireline communication networks.

Network identity and data security in the wireless communication network 300 of FIG. 3 may be managed via user authentication processes provided by the AMF/SEAF 330, the AUSF 360, and the UDM/ARPF 370. In particularly, the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370. Communication sessions established for the UE 310 after user authentication to the wireless communication network 300 may then be protected by the various levels of encryption/decryption keys. The generation and management of the various keys may be orchestrated by the AUSF 360 and other network functions in the communication network 300.

AKMA Framework

In the wireless communication network, the Application Function (AF) may provide application service to a UE. AF may or may not resides in of the core network. In certain scenarios, the AF may need to push a message on its own initiative to the UE (e.g., the AF may push various notification to the UE according to the service subscribed to the AF by the UE). In further disclosure below, various embodiments are disclosed to facilitate the AF to securely push the message to the UE under an Authentication and Key Management for Applications (AKMA) framework. The AKMA framework may be based on various authentication procedures such as the 5G Authentication and Key Agreement (5G-AKA) method, the Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA′) method, the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) method, or the like.

FIG. 4 illustrates an exemplary network model 400 for implementing an AKMA framework. This model includes various network elements. Each network element may be implemented as a physical entity, or a logical entity providing a particular set of network functions. A logical entity may be based on software, hardware, firmware, of any combination thereof. For example, a logical entity may include a server providing the function. For another example, a logical entity may be implemented based on cloud-based service or platform, such as Software as a service (SaaS), Platform as a service (PaaS), etc.

The AKMA Anchor Function (AAnF) 412 provides a security anchor function in the Home Public Land Mobile Network (HPLMN). The AAnF stores the AKMA Anchor Key (K_AKMA) for AKMA service, which is received from the Authentication Server Function (AUSF) 416 after the UE 424 completes a successful primary authentication. The AAnF may also generate the key material to be used between the UE and the Application Function (AF) 420 and maintains UE AKMA contexts.

The AF 420 may provide application service to the UE. Under the AKMA framework, the AF may request for its AKMA Application Key, denoted as K_AF, from the AAnF using an identifier for the K_AKMA. The identifier may include an AKMA Key Identifier (A-KID). The AAnF may only provide the K_AF to the AF after the AF is authenticated and authorized by the operator network. The AF may be located inside or outside the operator's network. In this disclosure, for simplicity, the AKMA Application Key (K_AF) may also be referred to as the AF key.

The Network Exposure Function (NEF) 410 may be configured to enable and authorize external AFs to access the AKMA service and forward the AKMA service request towards the AAnF. The NEF may also perform the AAnF selection in case there are multiple AAnFs.

The AUSF 416 may provide the Subscription Permanent Identifier (SUPI) and AKMA key material (e.g., A-KID, K_AKMA) of the UE to the AAnF. The AUSF may also perform the AAnF selection.

The UDM may store AKMA subscription data of the subscriber (or the UE subscribed to the wireless communication network).

Referring to FIG. 4, various interfaces may be involved in the AKMA framework. These interfaces may include Nnef, Naanf, Nudm, Uausf, and Namf and may be referred to as Service Based Interface (SBI), as each interface corresponds to a service provided by a network element. For example, Nnef represnets the SBI utilized by the NEF; Naanf represents the SBI utilized by the AAnF; and Nudm represents the SBI utilized by the UDM. The network elements may interact with each other via the various SBIs. The SBI may provide security protection. For example, the SBI may be confidentiality, integrity and replay protected.

FIG. 4 shows the implementation where the AAnF is deployed as a standalone function. Other deployment options may be chosen. For example, the AAnF may be co-located with the AUSF, or the AAnF may be co-located with the NEF.

Under the AKMA framework, there may be various keys involved, and these keys may be organized in a hierarchical structure as shown in FIG. 5. The example key hierarchy of FIG. 5 may include the following keys at different level: K_AUSF, K_AKMA, and K_AF. These keys may be derived and stored in parallel on both the network side and the Mobile Equipment (ME) side. The ME refers to a portion of a UE along with other portions of UE such as a Universal Subscriber Identity Module (USIM).

After a successful primary authentication between the UE and the wireless communication network (e.g., UE authenticated by the operator), the AUSF and/or the UE may derive the K_AUSF based on an Integrity Key (IK) of the UE, and a Cipher Key (CK) of the UE. AUSF may alternatively derive the K_AUSF based on a transformation of the Integrity Key (denoted as IK′) of the UE, and a transformation of the Cipher Key (denoted as CK′) of the UE.

Based on the K_AUSF, the ME and the AUSF may each derive the K_AKMA based on the K_AUSF, and the SUPI of the UE, by using a Key Derivation Function (KDF).

Then based on the K_AKMA, the ME and the AAnF may each derive the K_AF based on the K_AKMA, and an identifier of the AF, also similarly by using a KDF. It is to be noted that a UE may store multiple K_AF, each corresponding to an AF.

The various keys described herein may each have a lifetime. For example, the K_AKMA may be refreshed until the next successful primary authentication. For another example, the K_AF may be provisioned with a lifetime, for example, by the AAnF.

In this disclosure, various embodiments are disclosed aiming to establish secure communication between the AF and the UE utilizing security context based on the AKMA framework. The security context may be stored in the AF and the UE, therefore secure communication may be achieved based on the security context. Details including interactions between various network elements are described below.

AF and UE AKMA Configuration

FIG. 6 shows exemplary steps for configuring AKMA security context on the AF and the UE. In this disclosure, the steps in each embodiment are for illustration purposes only and other alternatives may be derived based on the disclosed embodiments. For example, only part of the steps may need to be performed. For another example, the sequence of the steps may be adjusted. For another example, several steps may be combined (e.g., several messages may be combined in one message). For yet another example, a single step may be split (e.g., one message may be sent via two sub-messages).

With reference to FIG. 6, the exemplary steps are described in details below.

Step 1

In order to push messages securely to the UE, a security context (may also be referred to as a security configuration, an AKMA security context) may be set up on both the Application Function (AF) side and the UE side. For example, the security context may be based on the AKMA framework and may include an AKMA anchor key (or an ID of the AKMA anchor key (A-KID)) of the UE, and an AF key of the UE. Alternatively, the security context may include a binding of the AKMA anchor key (or A-KID) of the UE and the AF key of the UE. This binding may be referred to as a Security Association (SA). As described earlier, in this disclosure, the AKMA anchor key of the UE and the AF key of the UE may be denoted as K_AKMA and K_AF, respectively.

To obtain the security context, the AF may send a request to the AAnF, to request security context related configuration information. The request may include the AF ID (i.e., the identifier of the AF), and/or identity of the UE, e.g., Generic Public Subscription Identifier (GPSI), 5G-GUTI, or SUPI of the UE. In one implementation, the GPSI may be used when the AF is located outside the operator's network. Otherwise the SUPI may be used.

In one implementation, the AF may be allocated outside of the core network.

In one implementation, the AF may not have a direct access to the core network. For example, the AF may not have a direct access to the AAnF. In this case, the AF may send the request message to the core network via a relay network element such as an NEF.

In one implementation, the AF may already have an A-KID of the UE and a valid AF key (K_AF) of the UE available. In this case, the AF may directly jump to step 12 below, and send the A-KID directly to the UE, so the UE may establish the security association (SA) and/or store the security context.

Steps 2a & 2b

Upon receiving the request message from the AF in step 1, if the identity of the UE in the request message is in the form of GPSI or another format other than SUPI, the AAnF may retrieve the SUPI of the UE from the UDM. In particular, the AAnF may send to the UDM in step 2a a UE ID request which may include the GPSI and an ID type indicator. The ID type indicator may indicate the ID type for the ID requested. For example, the ID type indicator may indicate the ID in the form of SUPI is requested. The UDM may reply with the SUPI of the UE in a UE ID response message in step 2b.

If the identity of the UE in the request message is already in the form of SUPI, then steps 2a & 2b may be skipped.

Step 3

Based on the SUPI of the UE, the AAnF may check if a corresponding AKMA security context of the UE (SUPI, K_AKMA and/or A-KID) exists locally in the AAnF. In case that the AAnF already has the AKMA context, steps 4-8 below may be skipped.

Step 4

In step 3 above, the AAnF may determine that the AKMA security context for the UE is not available. The AAnF may then select an AUSF based on its local policy and forward an AKMA Security Context Request to the selected AUSF. The AKMA Security Context Request may include the SUPI of the UE.

In one implementation, the AAnF may be provisioned with AUSF function, or the AAnF and the AUSF may be co-located. In this case, the AAnF may directly interact with the UDM to request the AKMA Security Context Request from the UDM and jump to step 9 below.

Step 5

Upon receiving the AKMA Security Context Request from the AAnF, the AUSF may send an Authentication Request to the UDM. The Authentication Request may be used to request the AKMA security context and may include the SUPI of the UE.

Step 6

The UDM may determine the authentication method according to the UE subscription data of the UE. In one implementation, the UDM may retrieve the UE subscription data based on the SUPI of the UE.

If the authentication method is EAP-AKA′, the UDM may reply to the AUSF with an EAP-AKA′ Authentication Vector (AV). The EAP-AKA′ AV may include at least one of:

• • a random number (RAND), which may be used as a challenge;
  • an authentication token (AUTN), which may be used for proving the challenge's freshness and authenticity;
  • an expected response (XRES) to the challenge in an authentication procedure;
  • a transformation of the cipher key of the UE (transformed key denoted as CK′); or
  • a transformation of the integrity key of the UE (transformed key denoted as IK′).

The transformation of the cipher key and the integrity key may be based on a predetermined algorithm, such as a KDF.

If the authentication method is 5G AKA, the UDM may reply to the AUSF with a 5G Home Environment Authentication Vector (5G HE AV). The 5G HE AV may include at least one of:

• • a random number (RAND), which may be used as a challenge;
  • an authentication token (AUTN), which may be used for proving the challenge's freshness and authenticity;
  • an expected response (XRES*) to the challenge in an authentication procedure;
  • an AUSF key (K_AUSF) of the UE.

The reply message to the AUSF may further include an authentication method indicator, which indicates what authentication method is chosen (e.g., 5G AKA, EAP-AKA′, or EAP-TLS).

In one implementation, the reply message to the AUSF may further include a Routing Indicator (RID) of the UE.

Step 7

Upon receiving the response from the UDM, depending on the authentication method, the AUSF may retrieve the AUSF key (K_AUSF) from the response message directly, or may need to derive or generate K_AUSF.

If the authentication method indicator indicates that EAP-AKA′ is used as the authentication method, the AUSF may derive K_AUSF based on CK′ and IK′.

If the authentication method indicator indicates that 5G AKA is used as the authentication method, the AUSF may retrieve K_AUSF from the response message directly.

Next, the AUSF may generate the AKMA Anchor Key (K_AKMA) and the A-KID based on K_AUSF.

In one implementation, K_AKMA may be derived by: K_AKMA=KDF (SUPI, K_AUSF). KDF refers to Key Derivation Function. For example, the KDF may include HMAC-SHA-256 (256-bit Hash-based Message Authentication Code for Secure Hash Algorithm). When using HMAC-SHA-256, the output of the KDF may be a 256-bits key. In one implementation, the output key may further be truncated, for example, to 128 bits. When deriving K_AKMA using KDF as described above, SUPI of the UE may be used as a key, and K_AUSF may be used as an input.

As described above, A-KID may be used to identify K_AKMA of the UE. In one implementation, A-KID may be represented in a Network Access Identifier (NAI) format, i.e. username@realm. The username part may include the RID of the UE and an AKMA Temporary UE Identifier (A-TID) of the UE, and the realm part may include Home Network Identifier of the UE. In one implementation, A-TID may be derived based on K_AUSF using a KDF. For example, A-TID=KDF (K_AUSF, “AKMA”), i.e., the KDF uses string “AKMA” as the input, and K_AUSF as the key. The RID may be received from the UDM as part of the response message in step 6.

In one implementation, K_AKMA or A-KID derived in this step may be served as part of the AKMA context of the UE, which is describe in detail in steps below.

Step 8

As a response to the AKMA Security Context Request received from the AAnF in step 4, the AUSF may send a reply message to the AAnF. The reply message may include at least one of:

• • the random number (RAND) from the EAP-AKA′ AV or the 5G HE AV, depending on the selected authentication method as indicated in step 6;
  • an authentication token (AUTN) from the EAP-AKA′ AV or the 5G HE AV, depending on the selected authentication method as indicated in step 6;
  • the authentication method indicator; or
  • the AKMA context of the UE.

The AKMA context of the UE may include K_AKMA of the UE and A-KID identifying K_AKMA.

In one implementation, the reply message may further include the SUPI of the UE.

Step 9

Upon receiving the AKMA context response message from the AUSF, the AAnF may derive the Application Key (K_AF) of the UE from K_AKMA of the UE. For example, the application key may be determined by K_AF=KDF (AF-ID, K_AKMA), where AF-ID is the identifier of the AF.

Based on the response from the AUSF, the AAnF may be able to derive the AKMA security context related configuration information for the UE and the AF.

In one implementation, the AAnF may not have the AKMA context of the UE in step 3. In this case, the AAnF may generate or derive the AKMA security context related configuration information which may include:

• • A-KID identifying the K_AKMA of the UE;
  • K_AF of the UE corresponding to the AF;
  • a lifetime of the AKMA security context related configuration information, e.g., a valid time period for the security key such as K_AF;
  • the random number (RAND) from the EAP-AKA′ AV or the 5G HE AV, which is received by the AAnF in the step 8;
  • an authentication token (AUTN) from the EAP-AKA′ AV or the 5G HE AV, which is received by the AAnF in the step 8; or
  • the authentication method indicator.

In one implementation, in step 3, the AAnF may already have the AKMA context of the UE. In this case, step 4 to step 8 may be skipped. The AAnF may generate the AKMA security context related configuration information which may include:

• • A-KID identifying the K_AKMA of the UE;
  • K_AF of the UE; or
  • a lifetime of the AKMA security context related configuration information, e.g., a valid time period for the security key such as K_AF.

Step 10

Once the AKMA security context related configuration information is generated or derived, the AAnF may send the AKMA security context related configuration information to the AF.

Step 11

Based on the response message received in step 10, the AF may store A-KID and K_AF of the UE in an AKMA security context (or AKMA security association, i.e., the association of the A-KID and the K_AF).

Step 12

The AF may forward the AKMA security context related configuration information to the UE.

In one implementation, the AAnF does not have the AKMA context of the UE in step 3. In this case, the AKMA security context related configuration information may include at least one of:

• • the random number (RAND) from the EAP-AKA′ AV or the 5G HE AV;
  • an authentication token (AUTN) from the EAP-AKA′ AV or the 5G HE AV; or
  • the authentication method indicator.

In one implementation, in step 3, the AAnF may already have the AKMA context of the UE. In this case, the AKMA security context related configuration information may include A-KID identifying the K_AKMA of the UE.

Step 13

Once receives the AKMA security context related configuration information from the AF, the UE may store A-KID and K_AF in an AKMA security context (or AKMA security association, i.e., the association of the A-KID and the K_AF).

In one implementation, the AAnF does not have the AKMA context of the UE in step 3 (this condition may be implied by the received AKMA security context related configuration information, e.g., by determining that A-KID does not present). In this case, the UE may first verify the freshness and integrity of the received AKMA security context related configuration information, for example, by checking the received AUTN. If the verification passes, the UE may derive K_AUSF based on the authentication method indicated by the authentication method indicator. Specifically, in a case that 5G AKA authentication method is used, the UE may calculate K_AUSF based on CK and IK of the UE (with CK and IK retrieved from USIM of the UE). In a case that EAP-AKA′ authentication method is used, the UE may derive CK′ and IK′ from CK and IK, respectively, and then calculate K_AUSF based on CK′ and IK′. The UE may then derive K_AKMA, and A-KID in a similar way as in step 7. The UE may further derive K_AF in a similar way as in step 9. The UE may store A-KID and K_AF of the UE in an AKMA security context (or AKMA security association, i.e., the association of the A-KID and the K_AF).

In one implementation, in step 3, the AAnF may already have the AKMA context of the UE (this condition may similarly be implied by the received AKMA security context related configuration information, e.g., by determining that A-KID does present). In this case, the UE may compare the received A-KID with an A-KID locally stored by the UE. If there is a match, the UE may look up the K_AF corresponding to the AF which may be stored locally in the UE, and proceed to storing A-KID and K_AF of the UE in an AKMA security context (or AKMA security association, i.e., the association of the A-KID and the K_AF).

Step 14

Once the UE stores the AKMA security context or establishes the AKMA security association, the UE may acknowledge to the AF.

Step 15

Till this step, the UE and the AF may have each established the AKMA security association or have stored the AKMA security context. The AF may push message securely to the UE based on the AKMA security context.

In the embodiments above, to establish a secure link between the AF and the UE such that the AF may push messages to the UE securely, the AF may request for AKMA related configuration from the core network. In one implementation, the core network may send AKMA context (e.g., A-KID and K_AF) of the UE to the AF and the AF may forward the AKMA context to the UE. The AF and the UE may each be provisioned with the AKMA security context, which associates the A-KID and K_AF. The AF may then proceed to pushing messages to the UE securely.

The accompanying drawings and description above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and”, “or”, or “and/or,” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1. A method for wireless communication, performed by a wireless device in a wireless network, the method comprising: receiving, from a first network element hosting an Application Function (AF), a message comprising one of: an AKMA (Authentication and Key Management for Applications) key identifier (ID) identifying an AKMA anchor key of the wireless device; ora set of parameters indicative of the AKMA key ID; andstoring the AKMA key ID and an AF key associated with the first network element in a security context,wherein the first network element outside of a core network of the wireless network.

2. The method of claim 1, further comprising: receiving a secured message pushed from the first network element protected by the security context.

3. The method of claim 1, wherein storing the AKMA key ID and the AF key in the security context comprises: in response to the AKMA key ID received from the message and an existing AKMA key ID stored in the wireless device being the same, storing the AKMA key ID and the AF key associated with the first network element in the security context.

4. The method of claim 1, wherein: the message comprises the set of parameters;the set of parameters comprises at least one of: a random number and an authentication token from an authentication vector (AV), the AV being corresponding to an authentication method; oran authentication method indicator indicating the authentication method; andthe authentication method comprises one of: a 5G Authentication and Key Agreement (5G-AKA) method; oran Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA′) method.

5. The method of claim 4, further comprising: in response to the authentication method indicator indicating the 5G-AKA method as the authentication method, deriving an Authentication Server Function (AUSF) key according to a cipher key (CK) of the wireless device and an integrity key (IK) of the wireless device, both keys being provisioned in the wireless device; andin response to the authentication method indicator indicating the EAP-AKA′ method as the authentication method, deriving the AUSF key according to a transformation of the CK and a transformation of the IK.

6. The method of claim 5, further comprising: deriving the AKMA anchor key of the wireless device based on a Subscription Permanent Identifier (SUPI) of the wireless device and the AUSF key;deriving the AKMA key ID based on the AUSF key and at least one of: an AKMA Temporary Identifier (A-TID) of the wireless device;a Routing Indicator (RID) of in the wireless device; ora home network identifier of the wireless device; andderiving the AF key based on the AKMA anchor key and an identifier of the first network element.

7. The method of claim 6, wherein deriving the AKMA anchor key of the wireless device based on the SUPI of the wireless device and the AUSF key comprises: deriving the AKMA anchor key of the wireless device based on the SUPI of the wireless device and the AUSF key using a Hash-based Message Authentication Code for Secure Hash Algorithm (HMAC-SHA).

8-13. (canceled)

14. A method for wireless communication, performed by a first network element in a wireless network, the first network element hosting an AKMA anchor function, and the method comprising: determining configuration information for securely pushing a message from a second network element hosting an application function to a wireless device under an AKMA framework, wherein the second network element is outside of a core network of the wireless network and the configuration information comprises at least one of: a first set of parameters comprising at least one of: an AKMA key ID identifying an AKMA anchor key of the wireless device;an AF key of the wireless device, the AF key being associated with the second network element; ora valid duration of the configuration information; ora second set of parameters comprising at least one of: a random number and an authentication token from an authentication vector (AV), the AV being corresponding to an authentication method; oran authentication method indicator indicating the authentication method, the authentication method comprising one of: a 5G-AKA method; oran EAP-AKA′ method.

15. The method of claim 14, further comprising: transmitting a first message comprising the configuration information to the second network element.

16. The method of claim 15, further comprising, prior to transmitting the first message to the second network element: receiving, from the second network element, a second message requesting the configuration information, wherein the second message comprises one of: a GPSI of the wireless device; ora SUPI of the wireless device.

17. The method of claim 16, further comprising: in response to the second message comprising the GPSI of the wireless device: transmitting, to a third network element, a third message requesting the SUPI of the wireless device; andreceiving the SUPI of the wireless device from the third network element.

18. The method of claim 16, further comprising: in response to an AKMA context of the wireless device being unavailable, transmitting, to a fourth network element in the wireless network, a fourth message to request the AKMA context of the wireless device, the fourth network element hosting an Authentication Server function, wherein the AKMA context comprises at least one of: the SUPI of the wireless device;the AKMA anchor key of the wireless device; orthe AKMA key ID identifying the AKMA anchor key of the wireless device.

19. The method of claim 18, wherein the fourth network element comprises one of: a Unified Data Management (UDM); oran Authentication Server Function (AUSF).

20. The method of claim 18, further comprising receiving a fifth message, the fifth message comprising at least one of: the AKMA context of the wireless device; ora set of authentication method parameters comprises at least one of: a random number and an authentication token from an authentication vector (AV), the AV being corresponding to an authentication method; oran authentication method indicator indicating the authentication method, the authentication method comprises one of: a 5G-AKA method; oran EAP-AKA′ method.

21. The method of claim 20, further comprising: deriving the AF key of the wireless device based on the AKMA anchor key of the wireless device and an ID of the second network element.

22. The method of claim 14, further comprising: in response to an AKMA context of the wireless device being available, deriving the AF key of the wireless device based on the AKMA anchor key of the wireless device and an ID of the second network element.

23-31. (canceled)

32. A device comprising a memory for storing computer instructions and a processor in communication with the memory, wherein, when the processor executes the computer instructions, the processor is configured to cause the device to: receive, from a first network element hosting an Application Function (AF), a message comprising one of: an AKMA (Authentication and Key Management for Applications) key identifier (ID) identifying an AKMA anchor key of the device; ora set of parameters indicative of the AKMA key ID; andstore the AKMA key ID and an AF key associated with the first network element in a security context,wherein the first network element outside of a core network.

33. A device comprising a memory for storing computer instructions and a processor in communication with the memory, wherein the processor, when executing the computer instructions, is configured to implement a method of claim 14.

34. A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement a method of claim 1.

35. A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement a method of claim 14.