[go: up one dir, main page]

WO2025175539A1 - Akma authentication with device information - Google Patents

Akma authentication with device information

Info

Publication number
WO2025175539A1
WO2025175539A1 PCT/CN2024/078199 CN2024078199W WO2025175539A1 WO 2025175539 A1 WO2025175539 A1 WO 2025175539A1 CN 2024078199 W CN2024078199 W CN 2024078199W WO 2025175539 A1 WO2025175539 A1 WO 2025175539A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
application
key
terminal device
akma
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/078199
Other languages
French (fr)
Inventor
Heng Zhang
Saurabh Khare
Xin Wang
Wei Zhao
Xin Xin Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Investment China Co Ltd
Nokia Technologies Oy
Original Assignee
Nokia Solutions and Networks Investment China Co Ltd
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Solutions and Networks Investment China Co Ltd, Nokia Technologies Oy filed Critical Nokia Solutions and Networks Investment China Co Ltd
Priority to PCT/CN2024/078199 priority Critical patent/WO2025175539A1/en
Publication of WO2025175539A1 publication Critical patent/WO2025175539A1/en
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041Key generation or derivation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/69Identity-dependent
    • H04W12/71Hardware identity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/69Identity-dependent
    • H04W12/72Subscriber identity

Definitions

  • an apparatus comprising means for receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device; means for determining a first device identifier of the terminal device based on the device information; means for validating the terminal device based on the first device identifier and the AKMA key identifier; and means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device.
  • FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented
  • FIG. 5 illustrates a signaling chart of an example process for AKMA authentication according to some example embodiments of the present disclosure
  • FIG. 6 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure
  • FIG. 8 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure
  • FIG. 9 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure.
  • FIG. 11 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure.
  • FIG. 12 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
  • performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on.
  • NR New Radio
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • WCDMA Wideband Code Division Multiple Access
  • HSPA High-Speed Packet Access
  • NB-IoT Narrow Band Internet of Things
  • the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.
  • the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom.
  • the network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology
  • radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node.
  • An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.
  • IAB-MT Mobile Terminal
  • terminal device refers to any end device that may be capable of wireless communication.
  • a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) .
  • UE user equipment
  • SS Subscriber Station
  • MS Mobile Station
  • AT Access Terminal
  • the terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/
  • the terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) .
  • MT Mobile Termination
  • IAB node e.g., a relay node
  • the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
  • the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and/or code domain resource enabling a communication, and the like.
  • a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.
  • FIG. 1 shows an example environment 100 according to some example embodiments of the present disclosure.
  • AKMA may be employed.
  • the environment 100 may include at least a terminal device 110 (for example, user equipment, UE) , a home network (HN) 120 and an Application Function (AF) 130.
  • UE user equipment
  • HN home network
  • AF Application Function
  • the HN 120 may represent the mobile network provider, which plays the role of authenticating users and helps application providers to reach an agreement with the users on session keys in the AKMA service.
  • the UDM 121 stores information about all subscribers of the HN 120.
  • the AAnF 122 manages temporary information about subscribers and generates temporary session keys K AF for the application functions.
  • the AUSF 123 establishes a connection between UDM 121 and AAnF 122 and obtains the 5G authentication vector from UDM 121 and generates relative AKMA materials.
  • the NEF 124 establishes connection between AAnF 122 and AF 130 when the target AF is located outside the HN 120.
  • the AF 130 may be considered as an application provider or a service provider, which represents the online services that the user may wish to use.
  • the goal of AKMA is to help to establish a secure channel (exchange a secret key) between the AF 130 and the terminal device 110, with authentication of terminal device delegated to its corresponding HN 120.
  • the environment 100 may include a further network function, for example, EIR 125 as shown in FIG. 1.
  • the EIR 125 may be included in a serving network of the terminal device 110. If the terminal device 110 is located in a Home Public Land Mobile Network (HPLMN) , the EIR 125 is included in the HN 120. If the terminal device 110 is located in a Visited Public Land Mobile Network (VPLMN) , the EIR 125 is outside of the HN 120.
  • HPLMN Home Public Land Mobile Network
  • VPLMN Visited Public Land Mobile Network
  • Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , the sixth generation (6G) , and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future.
  • s cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , the sixth generation (6G) , and the like
  • wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future.
  • the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.
  • CDMA Code Division Multiple Access
  • FDMA Frequency Division Multiple Access
  • TDMA Time Division Multiple Access
  • FDD Frequency Division Duplex
  • TDD Time Division Duplex
  • MIMO Multiple-Input Multiple-Output
  • OFDM Orthogonal Frequency Division Multiple
  • DFT-s-OFDM Discrete Fourier Transform spread OFDM
  • AKMA authentication is intended to leverage the 5G authentication mechanism to provide applications with session keys that are afterwards used to secure the communication between the UE and the application server.
  • the AAnF has been introduced in the 5G system to obtain the intermediate AKMA key (K AKMA ) from the AUSF 123, as well as to provide application key (K AF , also referred to as session key) to application providers.
  • K AKMA can use received session key K AF or further derive the keys based on the session key K AF to secure the communication between UE and the application server.
  • K AF also referred to as session key
  • A-KID is generated as a unique identifier in UE and AUSF to identify the K AKMA key of the UE.
  • AKMA AKMA
  • 3GPP credentials used for 5GS access which allows the UE to securely exchange data with an AKMA application function.
  • the UE supporting AKMA Upon receiving a request from the upper layers to obtain the AKMA Key (K AKMA ) and AKMA Key Identifier (A-KID) , the UE supporting AKMA shall derive the K AKMA and the AKMA Temporary Identifier (A-TID) from the valid K AUSF if available, shall further derive the A-KID from the A-TID and shall provide K AKMA and A-KID to the upper layers.
  • K AKMA AKMA Key
  • A-KID AKMA Key Identifier
  • the UE supporting AKMA shall notify the upper layers whenever there is a change of the K AUSF upon reception of an extensible authentication protocol (EAP) -success message or upon reception of SECURITY MODE COMMAND message.
  • EAP extensible authentication protocol
  • the upper layers derive the AKMA Application Key (K AF ) from K AKMA .
  • K AF AKMA Application Key
  • the knowledge of whether a certain application needs to use AKMA or not is application specific.
  • the exact method of securing the data exchange at the upper layers using K AF is application specific.
  • the upper layers request the UE NAS layer to provide K AKMA and A-KID before the upper layers initiate communication with an AKMA application function.
  • the UE NAS layer Upon receiving a request from the upper layers to obtain K AKMA and A-KID, if there is no K AUSF available, the UE NAS layer cannot derive the K AKMA and A-KID and provides an indication to the upper layers that K AKMA and A-KID cannot be generated.
  • AKMA will work because UE would have provided the key material to the application layer.
  • AKMA provides a reliable framework for applications to authenticate the UE and secure the communication between the UE and the application server, leveraging the highly secure HPLMN based primary authentication. However, only credentials in the SIM-cards are checked, and device information is not checked in primary authentication. In some cases, only authorized devices should be able to gain access to services that they provided. With AKMA authentication, unauthorized devices might be passed. For example, if user A is owning the UE-A and having AKMA based authentication at a banking server. Then, user B takes user A’s SIM card and inserts into the UE-B, then AKMA authentication would be successful.
  • AKMA does not requires EIR check. Another case may be envisaged.
  • a UE generates A-KID and K AKMA and send the generated A-KID and K AF to the application layer immediately.
  • the application layer stores the A-KID and K AF . If UE registration is rejected (not accepted) by Access and Mobility Management Function (AMF) due to EIR check fails, the application layer still holds the AKMA keys.
  • AMF Access and Mobility Management Function
  • the UE During an ongoing primary authentication and key agreement procedure, if the UE receives a request from upper layers to obtain K AKMA and A-KID, the UE shall derive the K AKMA and A-TID after the completion of the ongoing primary authentication and key agreement procedure, shall further derive the A-KID from the A-TID and shall provide K AKMA and A-KID to the upper layers.
  • the application in UE can connect to the AF to start application session establishment via A-KID.
  • Wi-Fi Wireless Fidelity
  • the application in UE can connect to the AF to start application session establishment via A-KID.
  • AKMA authentication still can pass even if UE registration is rejected by the AMF due to EIR blocking.
  • a PLMN is providing the AKMA service (operator service) then EIR check must be performed which is missed in the above scenarios. So, it is a gap in the existing AKMA service.
  • a terminal device which is about to establish an application session with an application server, may request establishment of the application session by including device information indicating the terminal device.
  • FIG. 2 illustrates a signaling chart of an example procedure for AKMA authentication according to some example embodiments of the present disclosure.
  • FIG. 1 illustrates a signaling chart of an example procedure for AKMA authentication according to some example embodiments of the present disclosure.
  • FIG. 1 illustrates a signaling chart of an example procedure for AKMA authentication according to some example embodiments of the present disclosure.
  • FIG. 1 illustrates a signaling chart 200.
  • key derivation 202 may be performed.
  • the AUSF 123 and the terminal device 110 both stores K AUSF .
  • the AUSF 123 may derive (220) the K AKMA from K AUSF and generate (222) the AKMA key identifier (A-KID) of the K AKMA .
  • the terminal device 110 may derive (216) the K AKMA from K AUSF.
  • the terminal device 110 may generate the (A-KID) of the K AKMA and device information indicating the terminal device 110.
  • the device information may be generated using any suitable manner to uniquely identify the terminal device 110.
  • the device information may be generated by encrypting a device identifier (also referred to as first device identifier) of the terminal device 110.
  • a device identifier also referred to as first device identifier
  • the device identifier may be a permeant equipment identifier (PEI) of the terminal device 110 and thus the device information may be referred to as “PEI extension” or “PEI information” .
  • PEI permeant equipment identifier
  • the device information may be included in the A-KID of the K AKMA .
  • the terminal device 110 may generate (218) the A-KID including the device information.
  • the device information may be an attribute of the A-KID.
  • an A-KID with the format of “username@realm” may include two parts.
  • the username part 301 may include the RID and an AKMA Temporary UE Identifier (A-TID)
  • the realm part 303 may include a Home Network Identifier.
  • the PEI extension may include the PEI of the terminal device 110 which is encrypted with K AKMA as the shared key.
  • K AKMA a symmetric encryption algorithm
  • DES Data Encryption Standard
  • a prefix for example “ext_pei” and the encrypted string be concatenated together as the extension part.
  • SYNMETRIC_ENCRYPTION (Key, PEI) Key K AKMA
  • the PEI extension 302 may be added into the A-KID. As shown, the PEI extension 302 is inserted between the username part 301 and the realm part 302. Below is a possible example of A-KID with PEI extension:
  • the username part and the realm part are both related to the SIM card. As such, by introducing the device information, SIM-cards can be bound to authorized mobile devices that use 5G AKMA authentication.
  • the device information may be another attribute rather than the A-KID. Such example embodiments will be described with reference to FIG. 5 below.
  • the terminal device 110 may transmit (228) an establishment request for an application session to the AF 130.
  • the establishment request may include the A-KID and the device information.
  • the device information is a part of the A-KID.
  • the terminal device 110 may transmit, to the AF 130, an application session establishment request carrying the A-KID with the PEI extension.
  • the AF130 may request an application key (K AF , which is derived from K AKMA ) from the AAnF 122.
  • K AF an application key
  • the AF 130 may transmit (230) an application key request (for example, Naanf_AKMA_ApplicationKey_Get request) to the AAnF 122.
  • the application key request may be used to obtain the application key K AF from the AAnF 122 and may include the A-KID and the device information indicating the terminal device 110.
  • the application key request includes the A-KID added with the device information.
  • the application key request may further include an AF identifier (AF_ID) of the AF 130.
  • AF_ID an AF identifier
  • the application key request may further include an indication of whether to feedback a device identifier of the terminal device 110 in an application key response.
  • the application key request may include an indicator “PEI_Required_Ind” . If the value of the indicator is set as TRUE, PEI is required to feedback to the AF 130. This indication is needed if the AF 130 need to perform PEI check based on a local policy.
  • the AF 130 may request the K AF from the AAnF 122 by using the Naanf_AKMA_ApplicationKey_Get request, which includes the A-KID with the PEI extension, the AF_ID and optionally the indicator “PEI_Required_Ind” .
  • the AAnF 122 may receive the application key request from the AF 130. In some example embodiments, if the AAnF 122 determines that this AF needs a Generic Public Subscription Identifier (GPSI) , the AAnF 122 may transmit (232) a subscriber data management (SDM) request (for example, Nudm_SDM_Get Request) to the UDM 121 to fetch the GPSI of the terminal device 110. The UDM 121 may respond (234) the AAnF 122 with the SDM response (for example, Nudm_SDM_Get Response) including the GPSI of the terminal device 110. The AAnF 122 may store the received GPSI as part of the AKMA context of the terminal device 110. If the specific AF does not need GPSI, the acts 232 and 234 may be skipped and the AAnF 122 may continue with the following procedure.
  • SDM subscriber data management
  • Nudm_SDM_Get Request for example, Nudm_SDM_Get Request
  • the AAnF 122 may derive (236) the AKMA Application Key (that is, K AF ) from K AKMA if it does not already have K AF .
  • the AAnF 122 may determine (238) a device identifier (which is also referred to as first device identifier) of the terminal device 110 based on the device information in the application key request. For example, the AAnF 122 may extract the device information from the A-KID and derive the first device identifier from the extracted device information.
  • the first device identifier may be stored in the AKMA context of the terminal device 110.
  • the AAnF 122 may determine the K AKMA corresponding to the received A-KID, for example, based on the AKMA register request received at 224. Accordingly, the AAnF 122 may derive the first device identifier by decrypting the device information with the determined K AKMA . In an example, if the PEI extension exists in the A-KID, the AAnF 122 may decrypt the PEI extension with K AKMA to get the PEI of the terminal device 110 and store the PEI in the AKMA context of the terminal device 110.
  • validation of the terminal device 110 may be performed (240) based on the first device identifier and the A-KID.
  • the AAnF 122 may validate the terminal device 110 based on the derived PEI and the A-KID.
  • the terminal device 110 may be validated based on EIR check of the terminal device 110.
  • the validation of the terminal device 110 may be based on information exchange between the AAnF 122 and the UDM 121.
  • the validation of the terminal device 110 may be based on information exchange between the AAnF 122 and the EIR 125.
  • the AAnF 122 may transmit (242) an application key response (for example, Naanf_AKMA_ApplicationKey_Get response) to the AF 130 based on the validation result.
  • an application key response for example, Naanf_AKMA_ApplicationKey_Get response
  • the application key response is a failure response indicating a failure in validation of the terminal device 110.
  • the application key response does not include the K AF .
  • the application key response may further indicate the cause of the failure, for example, an unauthorized termina device.
  • the application key response is a successful response.
  • the application key response may include the K AF .
  • the application key response may further include the first device identifier of the terminal device 110.
  • the AAnF 122 may response the AF 130 with the Naanf_AKMA_ApplicationKey_Get response including the SUPI, K AF , an expiration time of the K AF and the PEI of the terminal device 110.
  • the AF 130 may receive the application key response indicating the validation result for the terminal device 110 from the AAnF 122, and may transmit (246) an establishment response for the application session based on the application key response. For example, if the application key response indicates a successful validation of the terminal device 110, the AF 130 may transmit an acceptation response for the application session. Based on the acceptation response, the terminal device 110 may derive the K AF accordingly. As such, both the terminal device 110 and the AF 130 are in possession of the K AF for further use. If the application key response indicates a failed validation of the terminal device 110, the AF 130 may transmit a rejection response for the application session.
  • the rejection response may include an indication of the failure cause, for example “PEI blocked” .
  • the AF 130 may check (244) the device identifier of the terminal device 110 based on one or more local policies. Based on the first device identifier in the application key response, the AF 130 may determine whether the application session is allowed to be established at the terminal device 110 for example, according to local policies or according to whether the first device identifier is bound to a user account. If the application session is allowed to be established at the terminal device 110, the AF 130 may transmit the acceptation response to the terminal device 110. If the application session is not allowed to be established at the terminal device 110, the AF 130 may transmit the rejection response to the terminal device 110.
  • the AF 130 may check if the PEI of the terminal device 110 is allowed based on an AF local policy. If the PEI is allowed, the AF 130 may accept the terminal device 110’s application session establishment request. Afterwards, the terminal device 110 derives K AF accordingly and both the terminal device 110 and AF 130 are in possession of the K AF for further use. If the PEI is not allowed, the AF 130 may reject the application session establishment with a failure cause “PEI blocked” .
  • AKMA authentication with device validation An example general procedure for AKMA authentication with device validation is described above.
  • the A-KID and PEI extension (as part of the A-KID or as an individual attribute) may be provided to the AF.
  • the AF may send Naanf_AKMA_ApplicationKey_Get request with the A-KID, PEI extension and AF_ID to an AAnF to get K AF , the K AF expiration time and PEI of the UE.
  • the AAnF may check if the PEI is blocked by EIR based on local policy.
  • the AF may perform additional check of the PEI based on an AF local policy. If the PEI is not allowed (for example, not bound with the user account, not an authorized device) , the AF may reject application session establishment request.
  • FIG. 4 illustrates a signaling chart 400 of an example procedure for EIR check according to some example embodiments of the present disclosure.
  • the signaling chart 400 may be considered as an example of a portion of the signaling chart 200.
  • the acts with the same reference number as FIG. 2 are similar to those described above with reference to FIG. 2 and thus description thereof will not be repeated here.
  • the acts 410, 415, 425, 430, 435 may be considered as example implementations of the act 240, and each of the acts 420 and 440 may be considered as an example implementation of the act 242.
  • the AAnF 122 may transmit (410) , to the UDM 121, a device identifier request comprising a subscriber identifier corresponding to the A-KID.
  • the device identifier may be used to request the UDM to check whether the subscriber identifier corresponds to a registered device identifier.
  • the device identifier may be Nudm_UECM_Get request, and the subscriber identifier may be SUPI.
  • the AAnF 130 may determine the SUPI corresponding to the A-KID based on the AKMA register request received at 224.
  • the device identifier may further include an indication to feedback a registered device identifier corresponding to the subscriber identifier if the registered device identifier is present.
  • the indication may further indicate to feedback a serving network name corresponding to the subscriber identifier if the registered device identifier is absent.
  • the AAnF 122 may transmit a Nudm_UECM_Get request to the UDM 121 with SUPI and the indicator “PEI_Required_Ind” .
  • the indicator “PEI_Required_Ind” indicates the UDM 121 to feedback a registered PEI corresponding to the SUPI or a serving network name based on whether the terminal device 110 is registered.
  • the UDM 121 may determine whether the subscriber identifier corresponds to a registered device identifier, or in other words, whether the subscriber identifier has been registered with a terminal device. Based on a result of the determination, the UDM 121 may transmit (415) a device identifier response to the AAnF 122. If the subscriber identifier corresponds to a second device identifier in register data, the device identifier response may include the second device identifier. If no device identifier corresponding to the subscriber identifier is determined in the register data, the device identifier response may include a serving network name corresponding to the subscriber identifier without a device identifier.
  • the UDM 121 may check whether the terminal device 110 is registered in AMF 3GPP and whether a PEI corresponding to the SUPI exists in amf3gppRegistration data. If the above checking result is positive, the UDM 121 may respond the AAnF 122 with the PEI existing in amf3gppRegistration data. If the above checking result is negative, the UDM 121 may respond the AAnF 122 with the serving network name. The serving network name may be used by the AAnF 122 to discover EIR services of a serving network corresponding to the SUPI.
  • the AAnF 122 may validate the terminal device 110 based on the device identifier response and optionally the first device identifier derived previously, and transmit (420) the application key response to the AF 130 accordingly.
  • the AAnF 122 may compare the first device identifier to the second device identifier. If the first device identifier is consistent with the second device identifier, for example, these two device identifiers are the same, it means that the terminal device 110 is not blocked. Accordingly, the application key response is a positive response.
  • the application key response may include the subscriber identifier, K AF , the K AF expiration time and the first device identifier. In this case, the acts 425, 430, 435, 440 may be skipped.
  • the AAnF 122 may check if the PEI from the UDM 121 is same as the PEI received from the terminal device 110. If these two PEIs are the same, it implies that the PEI is not blocked by the EIR, and thus the AAnF 122 may transmit Naanf_AKMA_ApplicationKey_Get response to the AF 130 with the SUPI, K AF , the K AF expiration time and the PEI of the terminal device 110.
  • the AAnF 122 may discover (425) the EIR 125 based on the serving network name.
  • the EIR 125 provides EIR services for the serving network of the terminal device 110.
  • the AAnF 122 may extract a Mobile Country Code (MCC) and a Mobile Network Code (MNC) from the received serving network name and use them to discover EIR services of the visited network, for example, VPLMN or HPLMN.
  • MCC Mobile Country Code
  • MNC Mobile Network Code
  • the AAnF 122 may transmit (430) , to the EIR 125, a device identity check request comprising the first device identifier of the terminal device 110.
  • the device check request may be used to request the EIR 125 to check whether the terminal device 110 is a validated device.
  • the EIR 125 may check whether the terminal device 110 is blocked for network access based on the first device identifier.
  • the EIR 125 may transmit (435) a device identity response based on a result of the checking.
  • the AAnF 122 may transmit N5g_eirEquipmentIdentitiyCheckGet request with SUPI and the PEI (that is the one derived from the PEI extension) of the terminal device 110 to the EIR 125.
  • the EIR 125 may check if the combination of the received SUPI and PEI is blocked and send back a success or failure response based on the check result.
  • the AAnF 122 may transmit (440) the application key response to the AF 130 based on the device identity check response. If the device identity check response indicates that the terminal device 110 is allowed for network access, the application key response is positive.
  • the application key response may include the subscriber identifier, K AF , the K AF expiration time and the first device identifier. If the device identity check response indicates that the terminal device is blocked for network access, the application key response is negative.
  • the application key response may include an indication of a failed validation of the terminal device 110. In this case, K AF may not be returned to the AF 130.
  • the AAnF 122 may receive from the EIR 125 the N5g_eirEquipmentIdentitiyCheckGet response including the EIR check result. If the PEI is not blocked, the AAnF 122 may send a Naanf_AKMA_ApplicationKey_Get success response to the AF 130 with the SUPI, K AF , the K AF expiration time and the PEI of the terminal device 110. If the PEI is blocked, the AAnF 122 may send a failure response to the AF 130.
  • the device information may be another attribute separate from the A-KID. Generation of the device information may be similar as described above with reference to FIG. 2 and FIG. 3, but the device information would not be added to the A-KID.
  • the PEI extension may be an individual optional attribute and generated after A-KID generation.
  • FIG. 5 illustrates a signaling chart 500 of an example process for AKMA authentication according to some example embodiments of the present disclosure.
  • the acts with the same reference number as FIG. 2 are similar to those described above with reference to FIG. 2 and thus description thereof will not be repeated here. Only the differences between the signaling chart 200 and the signaling chart 500 are described.
  • the terminal device 110 may generate (510) an A-KID.
  • This A-KID may include the username part and the realm part.
  • the terminal device 110 may further generate (515) the device information.
  • the PEI information may be generated by encrypting the PEI of the terminal device 110 with K AKMA .
  • the terminal device 110 may add the device information into the establishment request as a part different from the A-KID and transmit (520) the establishment request to the AF 130.
  • the terminal device 110 may insert the PEI information and the A-KID to the application session establishment request, and transmit the application session establishment request to the AF 130.
  • the device information is incorporated in AKMA authentication, either by extending the A-KID with the device information or by using the device information as an individual attribute.
  • the device information is encrypted with a shared key K AKMA.
  • Device information will not be used to uniquely identify K AKMA.
  • the AF receiving A-KID it may acquire K AF and ask the AAnF to decrypt the device information.
  • the AF may check if the device identifier is bound to the user account or check if the device identifier is allowed based a local policy and decide whether to accept or reject this application session establishment request.
  • the validation of the terminal device is performed by the AAnF but this is for purpose of illustration.
  • the validation of the terminal device may be performed by another network function, for example, the NEF 124.
  • the application key request may be transmitted to the AAnF 122 via the NEF 124.
  • the NEF 124 may extract the device information from the application key request, and validate the termina device 110 based on the device information.
  • Validation for example EIR check
  • the validation result may be returned to the AAnF 122, which forwards the validation result to the AF 130 in the application key response.
  • the AAnF or NEF can perform the EIR check before providing the application key to the AF. That is, the AAnF or NEF can check the UDM if the UE is registered or not. If the UE is registered, the AAnF can retrieve the PEI from the UDM and match it with the PEI provided by the UE. This ensures additional checking where PEI provided by the UE over AKMA is same as registered by the UE in 5GC. Please be noted that if the UE is registered in the UDM, then EIR check must have been performed.
  • the AAnF may determine the AMF details based on authentication data in the UDM. If the AMF belongs to the HPLMN, then the AAnF may contact the EIR to perform the PEI check. If the PEI check if failed, then the AAnF amy not provide the service to the AF. IF the AMF belongs to the VPLMN, then the AAnF may contact the EIR of the VPLMN to perform the PEI check. If the PEI check if failed, then the AAnF may not provide the service to the AF. Alternatively, based on operator policy, only the EIR of the HPLMN may be contacted as UE is not registered in the VPLMN.
  • FIG. 6 shows a flowchart of an example method 600 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of a network function.
  • the network function receives, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device.
  • the network function determines a first device identifier of the terminal device based on the device information.
  • the network function validates the terminal device based on the first device identifier and the AKMA key identifier.
  • the network function transmits, to the application function, an application key response based on a result of the validation of the terminal device.
  • determining a first device identifier of the terminal device based on the device information comprises: deriving the first device identifier by decrypting the device information with an AKMA key corresponding to the AKMA key identifier.
  • validating the terminal device based on the first device identifier and the AKMA key identifier comprises: transmitting, to a unified data management, a device identifier request comprising a subscriber identifier corresponding to the AKMA key identifier; receiving, from the unified data management, a device identifier response indicating whether the subscriber identifier corresponds to a registered device identifier; and validating the terminal device based on the device identifier response and the first device identifier.
  • transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: in accordance with a determination that the device identifier response comprises a second device identifier, comparing the first device identifier to the second device identifier; and in accordance with a determination that the first device identifier is consistent with the second device identifier, transmitting, to the application function, the application key response comprising the first device identifier.
  • validating the terminal device based on the first device identifier and the AKMA key identifier comprises: transmitting, to an equipment identity register, a device identity check request comprising the first device identifier of the terminal device; and receiving, from the equipment identity register, a device identity check response indicating whether the terminal device is blocked for network access; and transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: transmitting the application key response to the application function based on the device identity check response.
  • transmitting the application key response to the application function based on the device identity check response comprises: in accordance with a determination that the device identity check response indicates that the terminal device is allowed for network access, transmitting, to the application function, the application key response comprising the first device identifier; and in accordance with a determination that the device identity check response indicates that the terminal device is blocked for network access, transmitting, to the application function, the application key response indicating a failure in the validation of the terminal device.
  • the network function may further receive, from a unified data management, a device identifier response indicating whether a subscriber identifier corresponding to the AKMA key identifier corresponds to a registered device identifier; and in accordance with a determination that the device identifier response comprises a serving network name and lacks a device identifier, determine the equipment identity register based on the serving network name.
  • the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the application key request as a part different from the AKMA key identifier.
  • the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
  • the device identifier request further comprises an indication to feedback the registered device identifier in the device identifier response in presence of the registered device identifier.
  • the network function is comprised in a network exposure function, and the application key response is transmitted via an AKMA anchor function to the application function.
  • the network function is comprised in an AKMA anchor function.
  • FIG. 7 shows a flowchart of an example method 700 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the AF 130 in FIG. 1.
  • the AF 130 receives, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device.
  • the AF 130 transmits, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information.
  • the AF 130 receives, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device.
  • the AF 130 transmits, to the terminal device, an establishment response for the application session based on the application key response.
  • the application key response comprises a first device identifier of the terminal device and transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: determining, based on the first device identifier, whether the application session is allowed to be established at the terminal device; in accordance with a determination that the application session is allowed to be established at the terminal device, transmitting, to the terminal device, an acceptation response for the application session; and in accordance with a determination that the application session is not allowed to be established at the terminal device, transmitting, to the terminal device, a rejection response for the application session.
  • transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: in accordance with a determination that the application key response indicates a failure in the validation of the terminal device, transmitting, to the terminal device, a rejection response for the application session.
  • the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
  • FIG. 8 shows a flowchart of an example method 800 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the terminal device 110 in FIG. 1.
  • the terminal device 110 transmits, to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device 110.
  • the terminal device 110 receives, from the application function, an establishment response for the application session.
  • the method 800 further comprises: generating the device information by encrypting a first device identifier of the apparatus with an AKMA key corresponding to the AKMA key identifier.
  • FIG. 9 shows a flowchart of an example method 900 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 900 will be described from the perspective of the UDM 121 in FIG. 1.
  • the UDM 121 receive, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function.
  • the UDM 121 transmits, to the network function, a device identifier response based on a result of the determination.
  • FIG. 10 shows a flowchart of an example method 1000 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 1000 will be described from the perspective of the EIR 125 in FIG. 1.
  • the EIR 125 receives, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function.
  • the EIR 125 checks whether the terminal device is blocked for network access based on the first device identifier.
  • the EIR 125 transmits, to the network function, a device identity check response based on a result of the checking.
  • an apparatus capable of performing any of the method 600 may comprise means for performing the respective operations of the method 600.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus may be implemented as or included in the AAnF 122 or NEF 124 in FIG. 1.
  • the apparatus comprises means for receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device; means for determining a first device identifier of the terminal device based on the device information; means for validating the terminal device based on the first device identifier and the AKMA key identifier; and means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device.
  • the means for determining a first device identifier of the terminal device based on the device information comprises: means for deriving the first device identifier by decrypting the device information with an AKMA key corresponding to the AKMA key identifier.
  • the means for validating the terminal device based on the first device identifier and the AKMA key identifier comprises: means for transmitting, to a unified data management, a device identifier request comprising a subscriber identifier corresponding to the AKMA key identifier; means for receiving, from the unified data management, a device identifier response indicating whether the subscriber identifier corresponds to a registered device identifier; and means for validating the terminal device based on the device identifier response and the first device identifier.
  • the means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: means for in accordance with a determination that the device identifier response comprises a second device identifier, comparing the first device identifier to the second device identifier; and means for in accordance with a determination that the first device identifier is consistent with the second device identifier, transmitting, to the application function, the application key response comprising the first device identifier.
  • the means for validating the terminal device based on the first device identifier and the AKMA key identifier comprises: means for transmitting, to an equipment identity register, a device identity check request comprising the first device identifier of the terminal device; and means for receiving, from the equipment identity register, a device identity check response indicating whether the terminal device is blocked for network access; and means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: means for transmitting the application key response to the application function based on the device identity check response.
  • the means for transmitting the application key response to the application function based on the device identity check response comprises: means for in accordance with a determination that the device identity check response indicates that the terminal device is allowed for network access, transmitting, to the application function, the application key response comprising the first device identifier; and means for in accordance with a determination that the device identity check response indicates that the terminal device is blocked for network access, transmitting, to the application function, the application key response indicating a failure in the validation of the terminal device.
  • the apparatus further comprises means for receiving, from a unified data management, a device identifier response indicating whether a subscriber identifier corresponding to the AKMA key identifier corresponds to a registered device identifier; and means for in accordance with a determination that the device identifier response comprises a serving network name and lacks a device identifier, determining the equipment identity register based on the serving network name.
  • the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the application key request as a part different from the AKMA key identifier.
  • the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
  • the device identifier request further comprises an indication to feedback the registered device identifier in the device identifier response in presence of the registered device identifier.
  • the network function is comprised in a network exposure function, and the application key response is transmitted via an AKMA anchor function to the application function.
  • the network function is comprised in an AKMA anchor function.
  • the apparatus further comprises means for performing other operations in some example embodiments of the method 600.
  • the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
  • an apparatus capable of performing any of the method 700 may comprise means for performing the respective operations of the method 700.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus may be implemented as or included in the AF 130 in FIG. 1.
  • means for transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: means for in accordance with a determination that the application key response indicates a failure in the validation of the terminal device, transmitting, to the terminal device, a rejection response for the application session.
  • the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the establishment request and the application key request as a part different from the AKMA key identifier.
  • the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
  • the apparatus further comprises means for performing other operations in some example embodiments of the method 700.
  • the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
  • an apparatus capable of performing any of the method 800 may comprise means for performing the respective operations of the method 800.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus may be implemented as or included in the terminal device 110 in FIG. 1.
  • the apparatus comprises means for transmitting, at a terminal device to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; and means for receiving, from the application function, an establishment response for the application session.
  • the apparatus further comprises: mean for generating the device information by encrypting a first device identifier of the apparatus with an AKMA key corresponding to the AKMA key identifier.
  • the apparatus further comprises means for performing other operations in some example embodiments of the method 800.
  • the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
  • an apparatus capable of performing any of the method 900 may comprise means for performing the respective operations of the method 900.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus may be implemented as or included in the UDM 121 in FIG. 1.
  • a computer program 1130 includes computer executable instructions that are executed by the associated processor 1110.
  • the instructions of the program 1130 may include instructions for performing operations/acts of some example embodiments of the present disclosure.
  • the program 1130 may be stored in the memory, e.g., the ROM 1124.
  • the processor 1110 may perform any suitable actions and processing by loading the program 1130 into the RAM 1122.
  • the example embodiments of the present disclosure may be implemented by means of the program 1130 so that the device 1100 may perform any process of the disclosure as discussed with reference to FIG. 2 to FIG. 10.
  • the example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
  • the program 1130 may be tangibly contained in a computer readable medium which may be included in the device 1100 (such as in the memory 1120) or other storage devices that are accessible by the device 1100.
  • the device 1100 may load the program 1130 from the computer readable medium to the RAM 1122 for execution.
  • the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.
  • the term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .
  • FIG. 12 shows an example of the computer readable medium 1200 which may be in form of CD, DVD or other optical storage disk.
  • the computer readable medium 1200 has the program 1130 stored thereon.
  • Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages.
  • the program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented.
  • the program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
  • the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above.
  • Examples of the carrier include a signal, computer readable medium, and the like.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method comprising: receiving, from an application function, an application key request comprising an authentication and key management for application (AKMA) key identifier and device information indicating a terminal device; determining a first device identifier of the terminal device based on the device information; validating the terminal device based on the first device identifier and the AKMA key identifier; and transmitting, to the application function, an application key response based on a result of the validation of the terminal device.

Description

AKMA AUTHENTICATION WITH DEVICE INFORMATION
FIELDS
Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for Authentication and Key Management for Application (AKMA) authentication with device information.
BACKGROUND
AKMA authentication is a novel cellular-network-based delegated authentication service. Using AKMA, a user can log in to an application service based on the 3rd generation partnership project (3GPP) credential which is the permanent key stored in the user’s tamper-resistant sim-cards. The application service provider can also delegate the task of user authentication to the mobile network operator by using AKMA.
SUMMARY
In a first aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device; determine a first device identifier of the terminal device based on the device information; validate the terminal device based on the first device identifier and the AKMA key identifier; and transmit, to the application function, an application key response based on a result of the validation of the terminal device.
In a second aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; transmit, to an AKMA anchor function, an application key request comprising the AKMA key  identifier and the device information; receive, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and transmit, to the terminal device, an establishment response for the application session based on the application key response.
In a third aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: transmit, to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the apparatus; and receive, from the application function, an establishment response for the application session.
In a fourth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; determine whether the subscriber identifier corresponds to a registered device identifier; and transmit, to the network function, a device identifier response based on a result of the determination.
In a fifth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; check whether the terminal device is blocked for network access based on the first device identifier; and transmit, to the network function, a device identity check response based on a result of the checking.
In a sixth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device; determining a first device identifier  of the terminal device based on the device information; validating the terminal device based on the first device identifier and the AKMA key identifier; and transmitting, to the application function, an application key response based on a result of the validation of the terminal device.
In a seventh aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; transmitting, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information; receiving, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and transmitting, to the terminal device, an establishment response for the application session based on the application key response.
In an eighth aspect of the present disclosure, there is provided a method. The method comprises: transmitting, at a terminal device to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; and receiving, from the application function, an establishment response for the application session.
In a ninth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; determining whether the subscriber identifier corresponds to a registered device identifier; and transmitting, to the network function, a device identifier response based on a result of the determination.
In a tenth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; checking whether the terminal device is blocked for network access based on the first device identifier; and transmitting, to the network  function, a device identity check response based on a result of the checking.
In an eleventh aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device; means for determining a first device identifier of the terminal device based on the device information; means for validating the terminal device based on the first device identifier and the AKMA key identifier; and means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device.
In a twelfth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; means for transmitting, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information; means for receiving, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and means for transmitting, to the terminal device, an establishment response for the application session based on the application key response.
In a thirteenth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for transmitting, at a terminal device to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; and means for receiving, from the application function, an establishment response for the application session.
In a fourteenth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; means for determining whether the subscriber identifier corresponds to a registered device identifier; and means for transmitting, to the network function, a device identifier response based on a result of the determination.
In a fifteenth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; means for checking whether the terminal device is blocked for network access based on the first device identifier; and means for transmitting, to the network function, a device identity check response based on a result of the checking.
In a sixteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least one of the method according to the sixth aspect, the method according to the seventh aspect, the method according to the eighth aspect, the method according to the ninth aspect, or the method according to the tenth aspect.
It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.
BRIEF DESCRIPTION OF THE DRAWINGS
Some example embodiments will now be described with reference to the accompanying drawings, where:
FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;
FIG. 2 illustrates a signaling chart of an example procedure for AKMA authentication according to some example embodiments of the present disclosure;
FIG. 3 illustrates a schematic diagram of AKMA key identifier generation according to some example embodiments of the present disclosure;
FIG. 4 illustrates a signaling chart of an example procedure for equipment identity Register (EIR) check according to some example embodiments of the present disclosure;
FIG. 5 illustrates a signaling chart of an example process for AKMA authentication according to some example embodiments of the present disclosure;
FIG. 6 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure;
FIG. 7 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure;
FIG. 8 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure;
FIG. 9 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure;
FIG. 10 illustrates a flowchart of a method implemented at apparatus according to some example embodiments of the present disclosure;
FIG. 11 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and
FIG. 12 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
Throughout the drawings, the same or similar reference numerals represent the same or similar element.
DETAILED DESCRIPTION
Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.
In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.
References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such  phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
It shall be understood that although the terms “first, ” “second, ” …, etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.
As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.
As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.
As used in this application, the term “circuitry” may refer to one or more or all of the following:
(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and
(b) combinations of hardware circuits and software, such as (as applicable) :
(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and
(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and
(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be  embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.
As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.
The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part  of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and/or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.
FIG. 1 shows an example environment 100 according to some example embodiments of the present disclosure. In the environment 100, AKMA may be employed. As shown, the environment 100 may include at least a terminal device 110 (for example, user equipment, UE) , a home network (HN) 120 and an Application Function (AF) 130.
The HN 120 may represent the mobile network provider, which plays the role of authenticating users and helps application providers to reach an agreement with the users on session keys in the AKMA service. There are several network functions located within the HN 120, such a Unified Data Management (UDM) 121, an AKMA Anchor Function (AAnF) 122, an Authentication Server Function (AUSF) 123 and a Network Exposure Function (NEF) 124. The UDM 121 stores information about all subscribers of the HN 120. The AAnF 122 manages temporary information about subscribers and generates temporary session keys KAF for the application functions. The AUSF 123 establishes a connection between UDM 121 and AAnF 122 and obtains the 5G authentication vector from UDM 121 and generates relative AKMA materials. The NEF 124 establishes connection between AAnF 122 and AF 130 when the target AF is located outside the HN 120.
The AF 130 may be considered as an application provider or a service provider, which represents the online services that the user may wish to use. The goal of AKMA is  to help to establish a secure channel (exchange a secret key) between the AF 130 and the terminal device 110, with authentication of terminal device delegated to its corresponding HN 120.
In some example embodiments, the environment 100 may include a further network function, for example, EIR 125 as shown in FIG. 1. The EIR 125 may be included in a serving network of the terminal device 110. If the terminal device 110 is located in a Home Public Land Mobile Network (HPLMN) , the EIR 125 is included in the HN 120. If the terminal device 110 is located in a Visited Public Land Mobile Network (VPLMN) , the EIR 125 is outside of the HN 120.
Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , the sixth generation (6G) , and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.
As briefly mentioned above, AKMA authentication is intended to leverage the 5G authentication mechanism to provide applications with session keys that are afterwards used to secure the communication between the UE and the application server. The AAnF has been introduced in the 5G system to obtain the intermediate AKMA key (KAKMA) from the AUSF 123, as well as to provide application key (KAF, also referred to as session key) to application providers. The AF can use received session key KAF or further derive the keys based on the session key KAF to secure the communication between UE and the application server. Considering the 5G security design of enabling KAUSF storage in the home network and the UE for further services, AKMA is designed to leverage primary authentication and namely KAUSF to simplify the procedures. Specifically, if the UE is  subscribed with AKMA service capability, there will be KAUSF stored in the UE and further KAKMA derived from KAUSF after the successful primary authentication.
In AKMA procedures, A-KID is generated as a unique identifier in UE and AUSF to identify the KAKMA key of the UE.
The purpose of AKMA is to provide authentication and key management to applications based on 3GPP credentials used for 5GS access, which allows the UE to securely exchange data with an AKMA application function.
Upon receiving a request from the upper layers to obtain the AKMA Key (KAKMA) and AKMA Key Identifier (A-KID) , the UE supporting AKMA shall derive the KAKMA and the AKMA Temporary Identifier (A-TID) from the valid KAUSF if available, shall further derive the A-KID from the A-TID and shall provide KAKMA and A-KID to the upper layers.
The UE supporting AKMA shall notify the upper layers whenever there is a change of the KAUSF upon reception of an extensible authentication protocol (EAP) -success message or upon reception of SECURITY MODE COMMAND message.
The upper layers derive the AKMA Application Key (KAF) from KAKMA. The knowledge of whether a certain application needs to use AKMA or not is application specific. The exact method of securing the data exchange at the upper layers using KAF is application specific. The upper layers request the UE NAS layer to provide KAKMA and A-KID before the upper layers initiate communication with an AKMA application function. Upon receiving a request from the upper layers to obtain KAKMA and A-KID, if there is no KAUSF available, the UE NAS layer cannot derive the KAKMA and A-KID and provides an indication to the upper layers that KAKMA and A-KID cannot be generated.
In view of the above, once authentication is passed and registration is rejected, AKMA will work because UE would have provided the key material to the application layer.
AKMA provides a reliable framework for applications to authenticate the UE and secure the communication between the UE and the application server, leveraging the highly secure HPLMN based primary authentication. However, only credentials in the SIM-cards are checked, and device information is not checked in primary authentication. In some cases, only authorized devices should be able to gain access to services that they  provided. With AKMA authentication, unauthorized devices might be passed. For example, if user A is owning the UE-A and having AKMA based authentication at a banking server. Then, user B takes user A’s SIM card and inserts into the UE-B, then AKMA authentication would be successful.
Moreover, AKMA does not requires EIR check. Another case may be envisaged. A UE generates A-KID and KAKMA and send the generated A-KID and KAF to the application layer immediately. The application layer stores the A-KID and KAF. If UE registration is rejected (not accepted) by Access and Mobility Management Function (AMF) due to EIR check fails, the application layer still holds the AKMA keys.
During an ongoing primary authentication and key agreement procedure, if the UE receives a request from upper layers to obtain KAKMA and A-KID, the UE shall derive the KAKMA and A-TID after the completion of the ongoing primary authentication and key agreement procedure, shall further derive the A-KID from the A-TID and shall provide KAKMA and A-KID to the upper layers.
As the application layer has the keys and UE is connected via Wireless Fidelity (Wi-Fi) , the application in UE can connect to the AF to start application session establishment via A-KID. However, in this case, AKMA authentication still can pass even if UE registration is rejected by the AMF due to EIR blocking. In this case, a PLMN is providing the AKMA service (operator service) then EIR check must be performed which is missed in the above scenarios. So, it is a gap in the existing AKMA service.
In view of the above, the present disclosure proposes a solution for AKMA authentication with device information. In this solution, a terminal device, which is about to establish an application session with an application server, may request establishment of the application session by including device information indicating the terminal device.
As such, the network performs additional check on the device information to make sure unauthorized devices not to pass AKMA authentication. The solution can simultaneously enhance security and provide a seamless user experience with AKMA authentication. In this way, the security of user data can be ensured, potential attacks can be mitigated, and service providers can be provided with better device control mechanisms.
Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.
Now reference is made to FIG. 2, which illustrates a signaling chart of an example procedure for AKMA authentication according to some example embodiments of the present disclosure. For the purpose of discussion, reference is made to FIG. 1 to describe the signaling chart 200.
As shown in FIG. 2, in some example embodiments, a primary authentication 201 may be performed first. During the primary authentication 201, the AUSF 123 may interact with the UDM 121 to fetch authentication information. The AUSF 123 may transmit (212) to the UMD 121 an authentication request including a Subscription Permanent Identifier (SUPI) or Subscription Concealed Identifier (SUCI) of the terminal device 110, for example, the Nudm_UEAuthentication_Get Request including SUPI or SUCI.
Depending on whether the terminal device 110 is capable of AKMA service and allowed to use the AKMA service, the UDM 121 may transmit (214) to the AUSF 123 an authentication response to indicate to the AUSF 123 whether KAKMA should be generated. For example, the Nudm_UEAuthentication_Get Response including an AKMA indication and the Routing Indicator (RID) of the terminal device 110 may be used. If the terminal device 110 is capable of AKMA service and allowed to use the AKMA service, the value of the AKMA indication is set as True.
It is noted that the primary authentication 201 shown in FIG. 2 is an example without any limitation to the protection scope.
Then, key derivation 202 may be performed. After receiving the AKMA indication from the UDM 121, the AUSF 123 and the terminal device 110 both stores KAUSF. After the primary authentication procedure is completed, the AUSF 123 may derive (220) the KAKMA from KAUSF and generate (222) the AKMA key identifier (A-KID) of the KAKMA.
After AKMA key material (for example, A-KID and KAKMA) is generated, the AUSF 123 may transmit (224) them together with the SUPI of the terminal device 110 in an AKMA register request to the AAnF 122 for further key derivation. For example, the Naanf_AKMA_AnchorKey_Register Request carrying the A-KID and KAKMA, and the SUPI may be transmitted to the AAnF 122. The AAnF 122 may transmit (226) an AKMA register response to the AUSF 123, for example, using the Naanf_AKMA_AnchorKey_Register response service operation.
Correspondingly, the terminal device 110 may derive (216) the KAKMA from KAUSF. The terminal device 110 may generate the (A-KID) of the KAKMA and device information indicating the terminal device 110. The device information may be generated using any suitable manner to uniquely identify the terminal device 110.
In some example embodiments, the device information may be generated by encrypting a device identifier (also referred to as first device identifier) of the terminal device 110. In this way, security of the device information during transmission can be ensured. The device identifier may be a permeant equipment identifier (PEI) of the terminal device 110 and thus the device information may be referred to as “PEI extension” or “PEI information” .
In some example embodiments, the device information may be included in the A-KID of the KAKMA. As shown in FIG. 2, the terminal device 110 may generate (218) the A-KID including the device information. In other words, the device information may be an attribute of the A-KID.
Reference is now made to FIG. 3 to illustrate generation of the A-KID with the device information. In FIG. 3, PEI extension is shown as an example. With the extension of device information, an A-KID with the format of “username@realm” may include two parts. The username part 301 may include the RID and an AKMA Temporary UE Identifier (A-TID) , and the realm part 303 may include a Home Network Identifier.
The PEI extension may include the PEI of the terminal device 110 which is encrypted with KAKMA as the shared key. For example, a symmetric encryption algorithm (AES) or Data Encryption Standard (DES) may be used to encrypt the PEI. Then, a prefix for example “ext_pei” and the encrypted string be concatenated together as the extension part. As an example without any limitation, the PEI Extension may be constructed as follows:
PEI Extension = “ext_pei” || SYNMETRIC_ENCRYPTION (Key, PEI)
Key = KAKMA
where “SYNMETRIC_ENCRYPTION” represent the encryption algorithm.
The PEI extension 302 may be added into the A-KID. As shown, the PEI extension 302 is inserted between the username part 301 and the realm part 302. Below is a possible example of A-KID with PEI extension:
atid316e0b4e3c5d633db077771c5c77bf14533ce36005c11c7b43146da64736b946. rid123 4. ext_pei12345678910@eps. mnc234. mcc15.3gppnetwork. org
where “atid316e0b4e3c5d633db077771c5c77bf14533ce36005c11c7b43146da64736b946” is an example of the A-TID, “rid1234” is an example of the RID, “. ext_pei12345678910” is an example of the PEI extension, and “eps. mnc234. mcc15.3gppnetwork. org” is an example of the realm part. It is noted that this example A-KID is given for the purpose of illustration without any limitation.
The username part and the realm part are both related to the SIM card. As such, by introducing the device information, SIM-cards can be bound to authorized mobile devices that use 5G AKMA authentication.
In some example embodiments, the device information may be another attribute rather than the A-KID. Such example embodiments will be described with reference to FIG. 5 below.
Reference is now made back to FIG. 2. When the terminal device 110 is about to communicate with the AF 130 (for example, an application server) , the terminal device 110 may transmit (228) an establishment request for an application session to the AF 130. The establishment request may include the A-KID and the device information. In the example of FIG. 2, the device information is a part of the A-KID. For example, the terminal device 110 may transmit, to the AF 130, an application session establishment request carrying the A-KID with the PEI extension.
If the AF 130 does not have the key material associated with the A-KID, then the AF130 may request an application key (KAF, which is derived from KAKMA) from the AAnF 122. To this end, the AF 130 may transmit (230) an application key request (for example, Naanf_AKMA_ApplicationKey_Get request) to the AAnF 122. The application key request may be used to obtain the application key KAF from the AAnF 122 and may include the A-KID and the device information indicating the terminal device 110. In this example of FIG. 2, the application key request includes the A-KID added with the device information. The application key request may further include an AF identifier (AF_ID) of the AF 130.
In some example embodiments, the application key request may further include an indication of whether to feedback a device identifier of the terminal device 110 in an  application key response. For example, the application key request may include an indicator “PEI_Required_Ind” . If the value of the indicator is set as TRUE, PEI is required to feedback to the AF 130. This indication is needed if the AF 130 need to perform PEI check based on a local policy.
As an example, the AF 130 may request the KAFfrom the AAnF 122 by using the Naanf_AKMA_ApplicationKey_Get request, which includes the A-KID with the PEI extension, the AF_ID and optionally the indicator “PEI_Required_Ind” .
The AAnF 122 may receive the application key request from the AF 130. In some example embodiments, if the AAnF 122 determines that this AF needs a Generic Public Subscription Identifier (GPSI) , the AAnF 122 may transmit (232) a subscriber data management (SDM) request (for example, Nudm_SDM_Get Request) to the UDM 121 to fetch the GPSI of the terminal device 110. The UDM 121 may respond (234) the AAnF 122 with the SDM response (for example, Nudm_SDM_Get Response) including the GPSI of the terminal device 110. The AAnF 122 may store the received GPSI as part of the AKMA context of the terminal device 110. If the specific AF does not need GPSI, the acts 232 and 234 may be skipped and the AAnF 122 may continue with the following procedure.
The AAnF 122 may derive (236) the AKMA Application Key (that is, KAF) from KAKMA if it does not already have KAF. The AAnF 122 may determine (238) a device identifier (which is also referred to as first device identifier) of the terminal device 110 based on the device information in the application key request. For example, the AAnF 122 may extract the device information from the A-KID and derive the first device identifier from the extracted device information. The first device identifier may be stored in the AKMA context of the terminal device 110.
In some example embodiments, the AAnF 122 may determine the KAKMA corresponding to the received A-KID, for example, based on the AKMA register request received at 224. Accordingly, the AAnF 122 may derive the first device identifier by decrypting the device information with the determined KAKMA. In an example, if the PEI extension exists in the A-KID, the AAnF 122 may decrypt the PEI extension with KAKMA to get the PEI of the terminal device 110 and store the PEI in the AKMA context of the terminal device 110.
Then, validation of the terminal device 110 may be performed (240) based on the first device identifier and the A-KID. For example, the AAnF 122 may validate the  terminal device 110 based on the derived PEI and the A-KID.
The terminal device 110 may be validated based on EIR check of the terminal device 110. In some example embodiments, the validation of the terminal device 110 may be based on information exchange between the AAnF 122 and the UDM 121. Alternatively, or in addition, in some example embodiments, the validation of the terminal device 110 may be based on information exchange between the AAnF 122 and the EIR 125. Some example embodiments regarding the validation will be described with reference to FIG. 4.
After obtaining a validation result of the validation of the terminal device 110, the AAnF 122 may transmit (242) an application key response (for example, Naanf_AKMA_ApplicationKey_Get response) to the AF 130 based on the validation result. If the validation result indicates that the terminal device 110 is not authorized, for example if the derived PEI is blocked for network access, the application key response is a failure response indicating a failure in validation of the terminal device 110. In this case, the application key response does not include the KAF. In some example embodiments, the application key response may further indicate the cause of the failure, for example, an unauthorized termina device.
If the validation result indicates that the terminal device 110 is authorized, for example if the derived PEI is not blocked for network access, the application key response is a successful response. In this case, the application key response may include the KAF. In some example embodiments, the application key response may further include the first device identifier of the terminal device 110. In an example, the AAnF 122 may response the AF 130 with the Naanf_AKMA_ApplicationKey_Get response including the SUPI, KAF, an expiration time of the KAF and the PEI of the terminal device 110.
The AF 130 may receive the application key response indicating the validation result for the terminal device 110 from the AAnF 122, and may transmit (246) an establishment response for the application session based on the application key response. For example, if the application key response indicates a successful validation of the terminal device 110, the AF 130 may transmit an acceptation response for the application session. Based on the acceptation response, the terminal device 110 may derive the KAF accordingly. As such, both the terminal device 110 and the AF 130 are in possession of the KAF for further use. If the application key response indicates a failed validation of the terminal device 110, the AF 130 may transmit a rejection response for the application  session. The rejection response may include an indication of the failure cause, for example “PEI blocked” .
In addition, in some example embodiments, the AF 130 may check (244) the device identifier of the terminal device 110 based on one or more local policies. Based on the first device identifier in the application key response, the AF 130 may determine whether the application session is allowed to be established at the terminal device 110 for example, according to local policies or according to whether the first device identifier is bound to a user account. If the application session is allowed to be established at the terminal device 110, the AF 130 may transmit the acceptation response to the terminal device 110. If the application session is not allowed to be established at the terminal device 110, the AF 130 may transmit the rejection response to the terminal device 110.
In an example, the AF 130 may check if the PEI of the terminal device 110 is allowed based on an AF local policy. If the PEI is allowed, the AF 130 may accept the terminal device 110’s application session establishment request. Afterwards, the terminal device 110 derives KAF accordingly and both the terminal device 110 and AF 130 are in possession of the KAF for further use. If the PEI is not allowed, the AF 130 may reject the application session establishment with a failure cause “PEI blocked” .
An example general procedure for AKMA authentication with device validation is described above. As a general example, when a UE initiates application session establishment request with an AF in AKMA authentication, the A-KID and PEI extension (as part of the A-KID or as an individual attribute) may be provided to the AF. The AF may send Naanf_AKMA_ApplicationKey_Get request with the A-KID, PEI extension and AF_ID to an AAnF to get KAF, the KAF expiration time and PEI of the UE. The AAnF may check if the PEI is blocked by EIR based on local policy. The AF may perform additional check of the PEI based on an AF local policy. If the PEI is not allowed (for example, not bound with the user account, not an authorized device) , the AF may reject application session establishment request.
Some example embodiments regarding device validation based on EIR check are now described with reference to FIG. 4.
FIG. 4 illustrates a signaling chart 400 of an example procedure for EIR check according to some example embodiments of the present disclosure. The signaling chart 400 may be considered as an example of a portion of the signaling chart 200. The acts with the same  reference number as FIG. 2 are similar to those described above with reference to FIG. 2 and thus description thereof will not be repeated here. The acts 410, 415, 425, 430, 435 may be considered as example implementations of the act 240, and each of the acts 420 and 440 may be considered as an example implementation of the act 242.
As shown in FIG. 4, in some example embodiments, upon determining the first device identifier of the terminal device 110 from the device information in the application key request, the AAnF 122 may transmit (410) , to the UDM 121, a device identifier request comprising a subscriber identifier corresponding to the A-KID. The device identifier may be used to request the UDM to check whether the subscriber identifier corresponds to a registered device identifier. For example, the device identifier may be Nudm_UECM_Get request, and the subscriber identifier may be SUPI. The AAnF 130 may determine the SUPI corresponding to the A-KID based on the AKMA register request received at 224.
In some example embodiments, the device identifier may further include an indication to feedback a registered device identifier corresponding to the subscriber identifier if the registered device identifier is present. The indication may further indicate to feedback a serving network name corresponding to the subscriber identifier if the registered device identifier is absent.
In an example, if PEI EIR check is needed based on the local policy of the AAnF 122, the AAnF 122 may transmit a Nudm_UECM_Get request to the UDM 121 with SUPI and the indicator “PEI_Required_Ind” . The indicator “PEI_Required_Ind” indicates the UDM 121 to feedback a registered PEI corresponding to the SUPI or a serving network name based on whether the terminal device 110 is registered.
After receiving the device identifier request from the AAnF 122, the UDM 121 may determine whether the subscriber identifier corresponds to a registered device identifier, or in other words, whether the subscriber identifier has been registered with a terminal device. Based on a result of the determination, the UDM 121 may transmit (415) a device identifier response to the AAnF 122. If the subscriber identifier corresponds to a second device identifier in register data, the device identifier response may include the second device identifier. If no device identifier corresponding to the subscriber identifier is determined in the register data, the device identifier response may include a serving network name corresponding to the subscriber identifier without a device identifier.
In an example, once receiving the Nudm_UECM_Get request including the SUPI and the indicator “PEI_Required_Ind” from the AAnF 122, the UDM 121 may check whether the terminal device 110 is registered in AMF 3GPP and whether a PEI corresponding to the SUPI exists in amf3gppRegistration data. If the above checking result is positive, the UDM 121 may respond the AAnF 122 with the PEI existing in amf3gppRegistration data. If the above checking result is negative, the UDM 121 may respond the AAnF 122 with the serving network name. The serving network name may be used by the AAnF 122 to discover EIR services of a serving network corresponding to the SUPI.
Upon receiving the device identifier response, the AAnF 122 may validate the terminal device 110 based on the device identifier response and optionally the first device identifier derived previously, and transmit (420) the application key response to the AF 130 accordingly.
In some example embodiments, if the device identifier response includes a second device identifier, the AAnF 122 may compare the first device identifier to the second device identifier. If the first device identifier is consistent with the second device identifier, for example, these two device identifiers are the same, it means that the terminal device 110 is not blocked. Accordingly, the application key response is a positive response. For example, the application key response may include the subscriber identifier, KAF, the KAF expiration time and the first device identifier. In this case, the acts 425, 430, 435, 440 may be skipped.
In an example, once receiving Nudm_UECM_Get response with a PEI from the UDM 121, the AAnF 122 may check if the PEI from the UDM 121 is same as the PEI received from the terminal device 110. If these two PEIs are the same, it implies that the PEI is not blocked by the EIR, and thus the AAnF 122 may transmit Naanf_AKMA_ApplicationKey_Get response to the AF 130 with the SUPI, KAF, the KAF expiration time and the PEI of the terminal device 110.
In some example embodiments, if the device identifier response includes the serving network name but lacks a device identifier, the AAnF 122 may discover (425) the EIR 125 based on the serving network name. The EIR 125 provides EIR services for the serving network of the terminal device 110. For example, if the Nudm_UECM_Get response from the UDM 121 includes the serving network name, the AAnF 122 may  extract a Mobile Country Code (MCC) and a Mobile Network Code (MNC) from the received serving network name and use them to discover EIR services of the visited network, for example, VPLMN or HPLMN.
Then, the AAnF 122 may transmit (430) , to the EIR 125, a device identity check request comprising the first device identifier of the terminal device 110. The device check request may be used to request the EIR 125 to check whether the terminal device 110 is a validated device. Upon receiving the device identity request, the EIR 125 may check whether the terminal device 110 is blocked for network access based on the first device identifier. The EIR 125 may transmit (435) a device identity response based on a result of the checking.
In an example, if the EIR service is found, the AAnF 122 may transmit N5g_eirEquipmentIdentitiyCheckGet request with SUPI and the PEI (that is the one derived from the PEI extension) of the terminal device 110 to the EIR 125. The EIR 125 may check if the combination of the received SUPI and PEI is blocked and send back a success or failure response based on the check result.
Continuing with the chart 400, upon receiving the device identity check response, the AAnF 122 may transmit (440) the application key response to the AF 130 based on the device identity check response. If the device identity check response indicates that the terminal device 110 is allowed for network access, the application key response is positive. For example, the application key response may include the subscriber identifier, KAF, the KAF expiration time and the first device identifier. If the device identity check response indicates that the terminal device is blocked for network access, the application key response is negative. For example, the application key response may include an indication of a failed validation of the terminal device 110. In this case, KAF may not be returned to the AF 130.
In an example, the AAnF 122 may receive from the EIR 125 the N5g_eirEquipmentIdentitiyCheckGet response including the EIR check result. If the PEI is not blocked, the AAnF 122 may send a Naanf_AKMA_ApplicationKey_Get success response to the AF 130 with the SUPI, KAF, the KAF expiration time and the PEI of the terminal device 110. If the PEI is blocked, the AAnF 122 may send a failure response to the AF 130.
The following procedure is similar to FIG. 2 and thus is not repeated here.
As briefly mentioned above, in some example embodiments, the device information may be another attribute separate from the A-KID. Generation of the device information may be similar as described above with reference to FIG. 2 and FIG. 3, but the device information would not be added to the A-KID. For example, the PEI extension may be an individual optional attribute and generated after A-KID generation.
FIG. 5 illustrates a signaling chart 500 of an example process for AKMA authentication according to some example embodiments of the present disclosure. The acts with the same reference number as FIG. 2 are similar to those described above with reference to FIG. 2 and thus description thereof will not be repeated here. Only the differences between the signaling chart 200 and the signaling chart 500 are described.
As shown, the terminal device 110 may generate (510) an A-KID. This A-KID may include the username part and the realm part. The terminal device 110 may further generate (515) the device information. For example, the PEI information may be generated by encrypting the PEI of the terminal device 110 with KAKMA. The terminal device 110 may add the device information into the establishment request as a part different from the A-KID and transmit (520) the establishment request to the AF 130. For example, the terminal device 110 may insert the PEI information and the A-KID to the application session establishment request, and transmit the application session establishment request to the AF 130.
As can be seen from the above, the device information is incorporated in AKMA authentication, either by extending the A-KID with the device information or by using the device information as an individual attribute. To ensure security and make sure that the device identifier is not tampered at application side, the device information is encrypted with a shared key KAKMA. Device information will not be used to uniquely identify KAKMA. When the AF receiving A-KID, it may acquire KAF and ask the AAnF to decrypt the device information. After getting KAF and the device identifier (for example, PEI) , the AF may check if the device identifier is bound to the user account or check if the device identifier is allowed based a local policy and decide whether to accept or reject this application session establishment request.
It is noted that in the above description, the validation of the terminal device (such as EIR check) is performed by the AAnF but this is for purpose of illustration. In some example embodiments, the validation of the terminal device (such as EIR check) may be performed by another network function, for example, the NEF 124. The  application key request may be transmitted to the AAnF 122 via the NEF 124. Thus, the NEF 124 may extract the device information from the application key request, and validate the termina device 110 based on the device information. Validation (for example EIR check) performed by the NEF 124 is similar to that performed by the AAnF 122 as described above and thus is not repeated here. If the validation is performed by the NEF 124, the validation result may be returned to the AAnF 122, which forwards the validation result to the AF 130 in the application key response.
By utilizing the EIR check in the AKMA authentication, the AAnF or NEF can perform the EIR check before providing the application key to the AF. That is, the AAnF or NEF can check the UDM if the UE is registered or not. If the UE is registered, the AAnF can retrieve the PEI from the UDM and match it with the PEI provided by the UE. This ensures additional checking where PEI provided by the UE over AKMA is same as registered by the UE in 5GC. Please be noted that if the UE is registered in the UDM, then EIR check must have been performed.
If the UE is not registered (may be a case where after authentication, registration is rejected due to EIR check) , the AAnF may determine the AMF details based on authentication data in the UDM. If the AMF belongs to the HPLMN, then the AAnF may contact the EIR to perform the PEI check. If the PEI check if failed, then the AAnF amy not provide the service to the AF. IF the AMF belongs to the VPLMN, then the AAnF may contact the EIR of the VPLMN to perform the PEI check. If the PEI check if failed, then the AAnF may not provide the service to the AF. Alternatively, based on operator policy, only the EIR of the HPLMN may be contacted as UE is not registered in the VPLMN.
FIG. 6 shows a flowchart of an example method 600 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of a network function.
At block 610, the network function receives, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device.
At block 620, the network function determines a first device identifier of the terminal device based on the device information.
At block 630, the network function validates the terminal device based on the first device identifier and the AKMA key identifier.
At block 640, the network function transmits, to the application function, an application key response based on a result of the validation of the terminal device.
In some example embodiments, determining a first device identifier of the terminal device based on the device information comprises: deriving the first device identifier by decrypting the device information with an AKMA key corresponding to the AKMA key identifier.
In some example embodiments, validating the terminal device based on the first device identifier and the AKMA key identifier comprises: transmitting, to a unified data management, a device identifier request comprising a subscriber identifier corresponding to the AKMA key identifier; receiving, from the unified data management, a device identifier response indicating whether the subscriber identifier corresponds to a registered device identifier; and validating the terminal device based on the device identifier response and the first device identifier.
In some example embodiments, transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: in accordance with a determination that the device identifier response comprises a second device identifier, comparing the first device identifier to the second device identifier; and in accordance with a determination that the first device identifier is consistent with the second device identifier, transmitting, to the application function, the application key response comprising the first device identifier.
In some example embodiments, validating the terminal device based on the first device identifier and the AKMA key identifier comprises: transmitting, to an equipment identity register, a device identity check request comprising the first device identifier of the terminal device; and receiving, from the equipment identity register, a device identity check response indicating whether the terminal device is blocked for network access; and transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: transmitting the application key response to the application function based on the device identity check response.
In some example embodiments, transmitting the application key response to the  application function based on the device identity check response comprises: in accordance with a determination that the device identity check response indicates that the terminal device is allowed for network access, transmitting, to the application function, the application key response comprising the first device identifier; and in accordance with a determination that the device identity check response indicates that the terminal device is blocked for network access, transmitting, to the application function, the application key response indicating a failure in the validation of the terminal device.
In some example embodiments, the network function may further receive, from a unified data management, a device identifier response indicating whether a subscriber identifier corresponding to the AKMA key identifier corresponds to a registered device identifier; and in accordance with a determination that the device identifier response comprises a serving network name and lacks a device identifier, determine the equipment identity register based on the serving network name.
In some example embodiments, the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the application key request as a part different from the AKMA key identifier.
In some example embodiments, the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
In some example embodiments, the device identifier request further comprises an indication to feedback the registered device identifier in the device identifier response in presence of the registered device identifier.
In some example embodiments, the network function is comprised in a network exposure function, and the application key response is transmitted via an AKMA anchor function to the application function.
In some example embodiments, the network function is comprised in an AKMA anchor function.
FIG. 7 shows a flowchart of an example method 700 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the AF 130 in FIG. 1.
At block 710, the AF 130 receives, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device.
At block 720, the AF 130 transmits, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information.
At block 730, the AF 130 receives, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device.
At block 740, the AF 130 transmits, to the terminal device, an establishment response for the application session based on the application key response.
In some example embodiments, the application key response comprises a first device identifier of the terminal device and transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: determining, based on the first device identifier, whether the application session is allowed to be established at the terminal device; in accordance with a determination that the application session is allowed to be established at the terminal device, transmitting, to the terminal device, an acceptation response for the application session; and in accordance with a determination that the application session is not allowed to be established at the terminal device, transmitting, to the terminal device, a rejection response for the application session.
In some example embodiments, transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: in accordance with a determination that the application key response indicates a failure in the validation of the terminal device, transmitting, to the terminal device, a rejection response for the application session.
In some example embodiments, the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the establishment request and the application key request as a part different from the AKMA key identifier.
In some example embodiments, the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
FIG. 8 shows a flowchart of an example method 800 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the terminal device 110 in FIG. 1.
At block 810, the terminal device 110 transmits, to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device 110.
At block 810, the terminal device 110 receives, from the application function, an establishment response for the application session.
In some example embodiments, the method 800 further comprises: generating the device information by encrypting a first device identifier of the apparatus with an AKMA key corresponding to the AKMA key identifier.
In some example embodiments, the method 800 further comprises: adding the device information into the AKMA key identifier as a part of the AKMA key identifier, or adding the device information into the establishment request as a part different from the AKMA key identifier.
FIG. 9 shows a flowchart of an example method 900 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 900 will be described from the perspective of the UDM 121 in FIG. 1.
At block 910, the UDM 121 receive, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function.
At block 920, the UDM 121 determines whether the subscriber identifier corresponds to a registered device identifier.
At block 930, the UDM 121 transmits, to the network function, a device identifier response based on a result of the determination.
In some example embodiments, transmitting, to the network function, a device  identifier response based on a result of the determination comprises: in accordance with a determination that the subscriber identifier corresponds to a second device identifier in register data, transmitting the device identifier response comprising the second device identifier to the network function; and in accordance with a determination that no device identifier corresponding to the subscriber identifier is determined in the register data, transmitting, to the network function, the device identifier response comprising a serving network name corresponding to the subscriber identifier and lacking a device identifier.
FIG. 10 shows a flowchart of an example method 1000 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 1000 will be described from the perspective of the EIR 125 in FIG. 1.
At block 1010, the EIR 125 receives, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function.
At block 1020, the EIR 125 checks whether the terminal device is blocked for network access based on the first device identifier.
At block 1030, the EIR 125 transmits, to the network function, a device identity check response based on a result of the checking.
In some example embodiments, an apparatus capable of performing any of the method 600 may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the AAnF 122 or NEF 124 in FIG. 1.
In some example embodiments, the apparatus comprises means for receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device; means for determining a first device identifier of the terminal device based on the device information; means for validating the terminal device based on the first device identifier and the AKMA key identifier; and means for transmitting, to the application function, an application key response based on a result of the validation of the  terminal device.
In some example embodiments, the means for determining a first device identifier of the terminal device based on the device information comprises: means for deriving the first device identifier by decrypting the device information with an AKMA key corresponding to the AKMA key identifier.
In some example embodiments, the means for validating the terminal device based on the first device identifier and the AKMA key identifier comprises: means for transmitting, to a unified data management, a device identifier request comprising a subscriber identifier corresponding to the AKMA key identifier; means for receiving, from the unified data management, a device identifier response indicating whether the subscriber identifier corresponds to a registered device identifier; and means for validating the terminal device based on the device identifier response and the first device identifier.
In some example embodiments, the means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: means for in accordance with a determination that the device identifier response comprises a second device identifier, comparing the first device identifier to the second device identifier; and means for in accordance with a determination that the first device identifier is consistent with the second device identifier, transmitting, to the application function, the application key response comprising the first device identifier.
In some example embodiments, the means for validating the terminal device based on the first device identifier and the AKMA key identifier comprises: means for transmitting, to an equipment identity register, a device identity check request comprising the first device identifier of the terminal device; and means for receiving, from the equipment identity register, a device identity check response indicating whether the terminal device is blocked for network access; and means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device comprises: means for transmitting the application key response to the application function based on the device identity check response.
In some example embodiments, the means for transmitting the application key response to the application function based on the device identity check response comprises: means for in accordance with a determination that the device identity check response  indicates that the terminal device is allowed for network access, transmitting, to the application function, the application key response comprising the first device identifier; and means for in accordance with a determination that the device identity check response indicates that the terminal device is blocked for network access, transmitting, to the application function, the application key response indicating a failure in the validation of the terminal device.
In some example embodiments, the apparatus further comprises means for receiving, from a unified data management, a device identifier response indicating whether a subscriber identifier corresponding to the AKMA key identifier corresponds to a registered device identifier; and means for in accordance with a determination that the device identifier response comprises a serving network name and lacks a device identifier, determining the equipment identity register based on the serving network name.
In some example embodiments, the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the application key request as a part different from the AKMA key identifier.
In some example embodiments, the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
In some example embodiments, the device identifier request further comprises an indication to feedback the registered device identifier in the device identifier response in presence of the registered device identifier.
In some example embodiments, the network function is comprised in a network exposure function, and the application key response is transmitted via an AKMA anchor function to the application function.
In some example embodiments, the network function is comprised in an AKMA anchor function.
In some example embodiments, the apparatus further comprises means for performing other operations in some example embodiments of the method 600. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
In some example embodiments, an apparatus capable of performing any of the method 700 may comprise means for performing the respective operations of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the AF 130 in FIG. 1.
In some example embodiments, the apparatus comprises means for receiving, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; means for transmitting, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information; means for receiving, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and means for transmitting, to the terminal device, an establishment response for the application session based on the application key response.
In some example embodiments, the application key response comprises a first device identifier of the terminal device and means for transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: means for determining, based on the first device identifier, whether the application session is allowed to be established at the terminal device; means for in accordance with a determination that the application session is allowed to be established at the terminal device, transmitting, to the terminal device, an acceptation response for the application session; and means for in accordance with a determination that the application session is not allowed to be established at the terminal device, transmitting, to the terminal device, a rejection response for the application session.
In some example embodiments, means for transmitting, to the terminal device, an establishment response for the application session based on the application key response comprises: means for in accordance with a determination that the application key response indicates a failure in the validation of the terminal device, transmitting, to the terminal device, a rejection response for the application session.
In some example embodiments, the device information is comprised as a part of the AKMA key identifier, or the device information is comprised in the establishment request and the application key request as a part different from the AKMA key identifier.
In some example embodiments, the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
In some example embodiments, the apparatus further comprises means for performing other operations in some example embodiments of the method 700. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
In some example embodiments, an apparatus capable of performing any of the method 800 may comprise means for performing the respective operations of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the terminal device 110 in FIG. 1.
In some example embodiments, the apparatus comprises means for transmitting, at a terminal device to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; and means for receiving, from the application function, an establishment response for the application session.
In some example embodiments, the apparatus further comprises: mean for generating the device information by encrypting a first device identifier of the apparatus with an AKMA key corresponding to the AKMA key identifier.
In some example embodiments, the apparatus further comprises: mean for adding the device information into the AKMA key identifier as a part of the AKMA key identifier, or mean for adding the device information into the establishment request as a part different from the AKMA key identifier.
In some example embodiments, the apparatus further comprises means for performing other operations in some example embodiments of the method 800. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
In some example embodiments, an apparatus capable of performing any of the method 900 may comprise means for performing the respective operations of the method 900. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the UDM 121 in FIG. 1.
In some example embodiments, the apparatus comprises means for receiving, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; means for determining whether the subscriber identifier corresponds to a registered device identifier; and means for transmitting, to the network function, a device identifier response based on a result of the determination.
In some example embodiments, means for transmitting, to the network function, a device identifier response based on a result of the determination comprises: means for in accordance with a determination that the subscriber identifier corresponds to a second device identifier in register data, transmitting the device identifier response comprising the second device identifier to the network function; and means for in accordance with a determination that no device identifier corresponding to the subscriber identifier is determined in the register data, transmitting, to the network function, the device identifier response comprising a serving network name corresponding to the subscriber identifier and lacking a device identifier.
In some example embodiments, the apparatus further comprises means for performing other operations in some example embodiments of the method 900. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
In some example embodiments, an apparatus capable of performing any of the method 1000 may comprise means for performing the respective operations of the method 1000. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the EIR 125 in FIG. 1.
In some example embodiments, the apparatus comprises means for receiving,  from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function; means for checking whether the terminal device is blocked for network access based on the first device identifier; and means for transmitting, to the network function, a device identity check response based on a result of the checking.
In some example embodiments, the apparatus further comprises means for performing other operations in some example embodiments of the method 1000. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.
FIG. 11 is a simplified block diagram of a device 1100 that is suitable for implementing example embodiments of the present disclosure. The device 1100 may be provided to implement a communication device, for example, the terminal device 110, the AF 130, the AAnF 122, the UDM 121, the EIR 125, or the AUSF 123 as shown in FIG. 1. As shown, the device 1100 includes one or more processors 1110, one or more memories 1120 coupled to the processor 1110, and one or more communication modules 1140 coupled to the processor 1110.
The communication module 1140 is for bidirectional communications. The communication module 1140 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 1140 may include at least one antenna.
The processor 1110 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1100 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
The memory 1120 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not  limited to, a Read Only Memory (ROM) 1124, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 1122 and other volatile memories that will not last in the power-down duration.
A computer program 1130 includes computer executable instructions that are executed by the associated processor 1110. The instructions of the program 1130 may include instructions for performing operations/acts of some example embodiments of the present disclosure. The program 1130 may be stored in the memory, e.g., the ROM 1124. The processor 1110 may perform any suitable actions and processing by loading the program 1130 into the RAM 1122.
The example embodiments of the present disclosure may be implemented by means of the program 1130 so that the device 1100 may perform any process of the disclosure as discussed with reference to FIG. 2 to FIG. 10. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
In some example embodiments, the program 1130 may be tangibly contained in a computer readable medium which may be included in the device 1100 (such as in the memory 1120) or other storage devices that are accessible by the device 1100. The device 1100 may load the program 1130 from the computer readable medium to the RAM 1122 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .
FIG. 12 shows an example of the computer readable medium 1200 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 1200 has the program 1130 stored thereon.
Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in  firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.
Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.
The computer readable medium may be a computer readable signal medium or  a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.
Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (34)

  1. An apparatus comprising:
    at least one processor; and
    at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
    receive, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device;
    determine a first device identifier of the terminal device based on the device information;
    validate the terminal device based on the first device identifier and the AKMA key identifier; and
    transmit, to the application function, an application key response based on a result of the validation of the terminal device.
  2. The apparatus of claim 1, wherein the apparatus is caused to determine a first device identifier of the terminal device based on the device information by:
    deriving the first device identifier by decrypting the device information with an AKMA key corresponding to the AKMA key identifier.
  3. The apparatus of claim 1, wherein the apparatus is caused to validate the terminal device based on the first device identifier and the AKMA key identifier by:
    transmitting, to a unified data management, a device identifier request comprising a subscriber identifier corresponding to the AKMA key identifier;
    receiving, from the unified data management, a device identifier response indicating whether the subscriber identifier corresponds to a registered device identifier; and
    validating the terminal device based on the device identifier response and the first device identifier.
  4. The apparatus of claim 3, wherein the apparatus is caused to transmit, to the application function, an application key response based on a result of the validation of the terminal device by:
    in accordance with a determination that the device identifier response comprises a  second device identifier, comparing the first device identifier to the second device identifier; and
    in accordance with a determination that the first device identifier is consistent with the second device identifier, transmitting, to the application function, the application key response comprising the first device identifier.
  5. The apparatus of claim 1, wherein the apparatus is caused to validate the terminal device based on the first device identifier and the AKMA key identifier by:
    transmitting, to an equipment identity register, a device identity check request comprising the first device identifier of the terminal device; and
    receiving, from the equipment identity register, a device identity check response indicating whether the terminal device is blocked for network access; and
    the apparatus is caused to transmit, to the application function, an application key response based on a result of the validation of the terminal device by:
    transmitting the application key response to the application function based on the device identity check response.
  6. The apparatus of claim 5, wherein the apparatus is caused to transmit the application key response to the application function based on the device identity check response by:
    in accordance with a determination that the device identity check response indicates that the terminal device is allowed for network access, transmitting, to the application function, the application key response comprising the first device identifier; and
    in accordance with a determination that the device identity check response indicates that the terminal device is blocked for network access, transmitting, to the application function, the application key response indicating a failure in the validation of the terminal device.
  7. The apparatus of claim 5, wherein the apparatus is further caused to:
    receive, from a unified data management, a device identifier response indicating whether a subscriber identifier corresponding to the AKMA key identifier corresponds to a registered device identifier; and
    in accordance with a determination that the device identifier response comprises a serving network name and lacks a device identifier, determine the equipment identity register based on the serving network name.
  8. The apparatus of claim 1, wherein the device information is comprised as a part of the AKMA key identifier, or
    the device information is comprised in the application key request as a part different from the AKMA key identifier.
  9. The apparatus of claim 1, wherein the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
  10. The apparatus of claim 3, wherein the device identifier request further comprises an indication to feedback the registered device identifier in the device identifier response in presence of the registered device identifier.
  11. The apparatus of claim 1, wherein the apparatus is comprised in a network exposure function, and the application key response is transmitted via an AKMA anchor function to the application function.
  12. The apparatus of claim 1, wherein the apparatus is comprised in an AKMA anchor function.
  13. An apparatus comprising:
    at least one processor; and
    at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
    receive, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device;
    transmit, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information;
    receive, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and
    transmit, to the terminal device, an establishment response for the application session based on the application key response.
  14. The apparatus of claim 13, wherein the application key response comprises a first device identifier of the terminal device and the apparatus is caused to transmit, to the terminal device, an establishment response for the application session based on the application key response by:
    determining, based on the first device identifier, whether the application session is allowed to be established at the terminal device;
    in accordance with a determination that the application session is allowed to be established at the terminal device, transmitting, to the terminal device, an acceptation response for the application session; and
    in accordance with a determination that the application session is not allowed to be established at the terminal device, transmitting, to the terminal device, a rejection response for the application session.
  15. The apparatus of claim 13, wherein the apparatus is caused to transmit, to the terminal device, an establishment response for the application session based on the application key response by:
    in accordance with a determination that the application key response indicates a failure in the validation of the terminal device, transmitting, to the terminal device, a rejection response for the application session.
  16. The apparatus of claim 13, wherein the device information is comprised as a part of the AKMA key identifier, or
    the device information is comprised in the establishment request and the application key request as a part different from the AKMA key identifier.
  17. The apparatus of claim 13, wherein the application key request further comprises an indication of whether to feedback the first device identifier of the terminal device in the application key response.
  18. An apparatus comprising:
    at least one processor; and
    at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
    transmit, to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the apparatus; and
    receive, from the application function, an establishment response for the application session.
  19. The apparatus of claim 18, wherein the apparatus is further caused to:
    generate the device information by encrypting a first device identifier of the apparatus with an AKMA key corresponding to the AKMA key identifier.
  20. The apparatus of claim 18, wherein the apparatus is further caused to:
    add the device information into the AKMA key identifier as a part of the AKMA key identifier, or
    add the device information into the establishment request as a part different from the AKMA key identifier.
  21. An apparatus comprising:
    at least one processor; and
    at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
    receive, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function;
    determine whether the subscriber identifier corresponds to a registered device identifier; and
    transmit, to the network function, a device identifier response based on a result of the determination.
  22. The apparatus of claim 21, wherein the apparatus is caused to transmit, to the network function, a device identifier response based on a result of the determination by:
    in accordance with a determination that the subscriber identifier corresponds to a second device identifier in register data, transmitting the device identifier response comprising the  second device identifier to the network function; and
    in accordance with a determination that no device identifier corresponding to the subscriber identifier is determined in the register data, transmitting, to the network function, the device identifier response comprising a serving network name corresponding to the subscriber identifier and lacking a device identifier.
  23. An apparatus comprising:
    at least one processor; and
    at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:
    receive, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function;
    check whether the terminal device is blocked for network access based on the first device identifier; and
    transmit, to the network function, a device identity check response based on a result of the checking.
  24. A method comprising:
    receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device;
    determining a first device identifier of the terminal device based on the device information;
    validating the terminal device based on the first device identifier and the AKMA key identifier; and
    transmitting, to the application function, an application key response based on a result of the validation of the terminal device.
  25. A method comprising:
    receiving, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device;
    transmitting, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information;
    receiving, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and
    transmitting, to the terminal device, an establishment response for the application session based on the application key response.
  26. A method comprising:
    transmitting, at a terminal device to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; and
    receiving, from the application function, an establishment response for the application session.
  27. A method comprising:
    receiving, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function;
    determining whether the subscriber identifier corresponds to a registered device identifier; and
    transmitting, to the network function, a device identifier response based on a result of the determination.
  28. A method comprising:
    receiving, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function;
    checking whether the terminal device is blocked for network access based on the first device identifier; and
    transmitting, to the network function, a device identity check response based on a result of the checking.
  29. An apparatus comprising:
    means for receiving, from an application function, an application key request comprising an authentication and key management for application, AKMA, key identifier and device information indicating a terminal device;
    means for determining a first device identifier of the terminal device based on the device information;
    means for validating the terminal device based on the first device identifier and the AKMA key identifier; and
    means for transmitting, to the application function, an application key response based on a result of the validation of the terminal device.
  30. An apparatus comprising:
    means for receiving, from a terminal device, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device;
    means for transmitting, to an AKMA anchor function, an application key request comprising the AKMA key identifier and the device information;
    means for receiving, from the AKMA anchor function, an application key response indicating a result of validation of the terminal device; and
    means for transmitting, to the terminal device, an establishment response for the application session based on the application key response.
  31. An apparatus comprising:
    means for transmitting, at a terminal device to an application function, an establishment request for an application session, the establishment request comprising an authentication and key management for application, AKMA, key identifier and device information indicating the terminal device; and
    means for receiving, from the application function, an establishment response for the application session.
  32. An apparatus comprising:
    means for receiving, from a network function, a device identifier request comprising a subscriber identifier, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function;
    means for determining whether the subscriber identifier corresponds to a registered device identifier; and
    means for transmitting, to the network function, a device identifier response based on a result of the determination.
  33. An apparatus comprising:
    means for receiving, from a network function, a device identity check request comprising a first device identifier of the terminal device, the network function comprises at least one of an authentication and key management for application, AKMA, anchor function, or a network exposure function;
    means for checking whether the terminal device is blocked for network access based on the first device identifier; and
    means for transmitting, to the network function, a device identity check response based on a result of the checking.
  34. A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of any of claims 25-28.
PCT/CN2024/078199 2024-02-22 2024-02-22 Akma authentication with device information Pending WO2025175539A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2024/078199 WO2025175539A1 (en) 2024-02-22 2024-02-22 Akma authentication with device information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2024/078199 WO2025175539A1 (en) 2024-02-22 2024-02-22 Akma authentication with device information

Publications (1)

Publication Number Publication Date
WO2025175539A1 true WO2025175539A1 (en) 2025-08-28

Family

ID=96846299

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/078199 Pending WO2025175539A1 (en) 2024-02-22 2024-02-22 Akma authentication with device information

Country Status (1)

Country Link
WO (1) WO2025175539A1 (en)

Similar Documents

Publication Publication Date Title
US12401690B2 (en) Mechanism for dynamic authorization
US20240422535A1 (en) Authentication Management Method for Non-3GPP Access of a UE Device to a 5G Network
WO2021219385A1 (en) Securely identifying network function
US20240244429A1 (en) Joint authentication for private network
US12439246B2 (en) Security communication in prose U2N relay
WO2025175539A1 (en) Akma authentication with device information
EP4322039A1 (en) Network function validation
US12477337B2 (en) Access token revocation in security management
WO2024092844A1 (en) Using routing indicator
US20240056302A1 (en) Apparatus, method, and computer program
WO2024036462A1 (en) Registration enhancement for multi-access
US20240340772A1 (en) Steering of roaming enhancement during registration reject
US20250097875A1 (en) Path switch between relays and security procedures
WO2025231876A1 (en) Public land mobile network protection
EP4569839A1 (en) Authentication for device with non-cellular access
US12452657B2 (en) Authentication between wireless devices and edge servers
WO2025168272A1 (en) User authentication behind a user device
US20250133393A1 (en) User plane traffic handling for emergency case
WO2025168278A1 (en) User authentication behind a user device
WO2025168285A1 (en) User authentication behind a user device
US20250175792A1 (en) Determining authentication credentials for a device-to-device service
US20240224032A1 (en) Method and apparatus for providing or revoking resource owner&#39;s authorization information using oauth
WO2024065209A1 (en) Mobile terminated early data transmission for internet of things
US20240244427A1 (en) Method and apparatus for protecting privacy issue for authentication and key management for applications
WO2024098177A1 (en) Authentication procedure for network slice

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24925291

Country of ref document: EP

Kind code of ref document: A1