Patent Description:
The generic bootstrapping architecture (GBA)/generic authentication architecture (GAA) features specified in 3GPP TS <NUM> version <NUM>. <NUM> leverage the Evolved Packet System (EPS)/Universal Mobile Telecommunications Service (UMTS) authentication infrastructure (especially the home subscriber server (HSS)) to provide the security between the user equipment (UE) and an application function in the network with which the UE interacts on the User Plane. It should be noted that GBA uses UMTS Authentication and Key Agreement (AKA) and that the HSS provides the ciphering key (CK)/integrity key (IK) to the bootstrapping server function (BSF) instead of a key for access security management entries (KASME) like it is done in the Evolved Packet System Authentication and Key Agreement (EPS AKA) procedure.

<FIG> shows the architecture of the features in GBA. GBA allows mutual authentication and the establishment of shared keys between a UE and BSF over a bootstrapping interface (Ub) interface. GAA, on the other hand, enables using such shared keys for protecting the access to a network application function (NAF) where the NAF could be any application server accessible for example through the internet, the difference being that NAF supports the required interfaces and procedure to obtain and use such keys. Thus, in principle GBA keys can be used to secure any protocol between a UE and a NAF over the network application function interface (Ua interface), over the User Plane.

3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) TS <NUM>,<NUM> V15. <NUM>) discloses a bootstrapping procedure and a bootstrapping usage procedure executed by a UE when the UE wants to interact with a NAF (Network Application Function).

3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on authentication and key management for applications; based on 3GPP credential in <NUM>. TR <NUM>, V0. <NUM>) discloses a bootstrapping authentication procedure for <NUM> AKA and a bootstrapping authentication procedure for EAP-AKA'.

3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Battery efficient security for very low throughput machine type communication (MTC) devices (BEST) (TS <NUM> V16. <NUM>) discloses communication security and key agreement processes that are optimized for battery constrained, very low throughput Machine Type Communication (MTC) devices.

An object of the present disclosure is to improve efficiency and signaling overhead for authentication and key management for a terminal device in a wireless communication network. An aspect of the present disclosure is directed to a method performed by a terminal device for authentication and key management for the terminal device in a wireless communication network. The method is defined in the attached claims.

Another aspect of the present disclosure is directed to a terminal device for authentication and key management for the terminal device in a wireless communication network. The terminal device is defined in the attached claims.

Another aspect of the present disclosure is directed to a computer program product that includes a non-transitory computer readable medium storing program code configured for execution by processing circuitry of a terminal device to cause the processing circuitry to perform operations for authentication and key management for the terminal device <NUM> in a wireless communication network. The computer program product is defined in the claims.

The following explanation of potential problems is a present realization as part of the present disclosure and is not to be construed as previously known by others. Some approaches for authentication and key management for a UE may perform an authentication procedure over the User Plane. Some solutions explore the possibility of performing such an authentication over the Control Plane in a similar manner to how primary authentication is performed. However, these solutions may incur a signaling overhead because, e.g., a UE performs more than one authentication. For <NUM>, when the UE has IP connectivity, the UE is already registered and authenticated. In the context of cellular internet of things (CloT) devices with limited hardware capabilities, e.g. battery, such signaling overhead, e.g., consumes resources. An authentication and key management method that improves efficiency and signaling overhead may be desirable.

Various embodiments described herein can operate to perform authentication and key management for a terminal device in a wireless communication network during a primary authentication session for the terminal device. Responsive to a successful authentication of the terminal device a first key may be obtained. Bootstrapping security parameters may be generated that include a second key derived from the first key and a temporary identifier. The temporary identifier may identify the terminal device and the bootstrapping security parameters. As a consequence, efficiency and signaling for authentication and key management may be provided because, e.g., the authentication and key management may be access independent, User Plane independent, independent of an authentication procedure, and may not require additional credentials or additional signaling.

The term "terminal" is used in a non-limiting manner and, as explained below, can refer to any type of radio communication terminal. The term "terminal" herein may be interchangeable replaced with the term "radio terminal," "radio communication terminal," "radio device," or "user equipment (UE). " Examples of terminal devices include, but are not limited to, user equipment (UE), mobiles stations, mobile phones, handsets, wireless local loop phones, smartphones, laptop computers, tablet computers, sensors, actuators, modems, repeaters, network-equipped Internet of Things devices, and network equipped vehicles.

The 3GPP security working group SA3 has started a new study called authentication and key management for applications (AKMA) captured in 3GPP TR <NUM>. The goal of the study is to develop features similar to GBA but that could fit in the <NUM> System.

Since the AKMA features are intended to leverage the 5GS authentication infrastructure to provide similar services, GBA/GAA may be one of the starting points for the architectural design of AKMA. However, due to differences between the 5GS and EPS/UMTS, there is no direct equivalent of the BSF and HSS in the <NUM> core network (5GC). These differences include, but are not limited to, the following:.

<FIG> shows the role of the anchor function in the AKMA architecture. It is expected that the AKMA architecture will include an AKMA Application Function (AKMA AF) with which the UE communicates over the User Plane. The AKMA AF interacts with an anchor function, the BSF-equivalent, in the <NUM> Core.

The final architecture for the AKMA features will have to address the following:.

Further Discussion of Potential Problems with Existing Solutions.

The GBA feature developed for an earlier generation does not require that the UE is registered to any PLMN. In fact, the only requirement is that the UE has IP connectivity to communicate with the BSF and run the authentication procedure. This was a good property because, in an earlier generation, a UE can only register to the network over non-3GPP access. The <NUM>th generation differs in this aspect since it integrates both 3GPP and non-3GPP access as described in 3GPP TS <NUM> version <NUM>. More specifically, the UE can run the same procedure towards the <NUM> Core Network (CN) over non-3GPP access as long as the UE can establish IP connectivity. In the <NUM> System this is realized by a new function called the Non-3GPP Inter-Working Function (N3IWF) which may be reachable via IP connectivity, for example through the internet. Therefore, it may not be necessary that the AKMA feature supports an independent authentication over the User Plane. As long as the UE has an IP connectivity, it may be able to register and authenticate with the Home PLMN (HPLMN) using the 3GPP credentials.

3GPP TR <NUM> includes solutions where the authentication procedure for AKMA is performed over the User Plane. Some solutions explore the possibility of performing such an authentication over the CP in a similar manner to how primary authentication is performed. However, these solutions incur a signaling overhead because, e.g., a UE performs more than one authentication. For <NUM>, when the UE has IP connectivity, the UE is already registered and authenticated. In the context of cellular internet of things (CloT) devices with limited hardware capabilities, e.g. battery, such signaling overhead, e.g., consumes resources.

In various embodiments, an anchor function may be used to authenticate the UE and provide authentication and key management services for a terminal device.

In some embodiments, authentication and key management for a terminal device in a wireless communication network is performed by a network server. The network server performs a method for authenticating the terminal device during a primary authentication session for the terminal device. Responsive to a successful authentication of the terminal device, the network server obtains a first key. The first key may be a root key. The network server generates bootstrapping security parameters. The parameters include a second key derived from the first key and a temporary identifier. The temporary identifier identifies the terminal device and the bootstrapping security parameters. The network server may communicate an authentication response message to the terminal device. The authentication response message includes at least one of the bootstrapping security parameters.

Presently disclosed embodiments may operate to allow for:.

In one embodiment, the bootstrapping security parameters are generated at the time of the Primary Authentication and pushed to the AAuF as illustrated in <FIG>. A primary authentication procedure is described in detail in 3GPP TS <NUM> version <NUM>. <FIG> illustrates an AKMA bootstrapping procedure via primary authentication according to some embodiments of the present disclosure.

Referring to <FIG>, at <NUM> the terminal device <NUM> sends an initial procedure including its subscription identifier (SUCI). The primary authentication procedure may be initiated upon an Initial Registration message from a terminal device <NUM> as shown in <FIG> or any initial NAS message, e.g. a Service Request, from the terminal device <NUM>.

At <NUM>, AMF <NUM> triggers a primary authentication procedure by sending an authentication request to the AUSF <NUM>. The request may include a subscription identifier (SUPI or SUCI).

At <NUM>, the AUSF <NUM> retrieves the terminal device <NUM> identifier and engages in an authentication exchange with the terminal device <NUM>.

At <NUM>, upon a successful authentication of the terminal device <NUM>, the AUSF <NUM> generates bootstrapping security parameters. This may include at least a bootstrapping key denoted by KAKMA and a temporary identifier. The temporary identifier identifies the terminal device <NUM> and the bootstrapping security parameters (also referred to herein as AKMA parameters). This set of AKMA parameters also is referred to herein as the terminal device AKMA context.

At <NUM>, optionally the AUSF <NUM> may provision the AKMA security context to the AAuF <NUM>. In another embodiment, the AAuF function is performed by the AUSF function <NUM>. In that case, the AUSF <NUM> stores the AKMA context of the terminal device <NUM>.

At <NUM>, the authentication procedure is terminated by an authentication response message carrying a security anchor key KSEAF. The authentication response message also may carry the SUPI if the procedure was run following an Initial Registration from the terminal device <NUM> as described in 3GPP TS <NUM> version <NUM>. In one embodiment, optionally this authentication carries information to the terminal device <NUM> related to the established AKMA context, for example, the temporary identifier from the generated AKMA context or any hint or indication of successful AKMA context generation. In another embodiment, when <NUM>-AKA is performed, the AKMA context could be generated by the UDM <NUM> instead of the AUSF <NUM> and pushed to the AAuF <NUM> function directly or through the AUSF <NUM>.

At <NUM>, the AMF <NUM> continues with the security setup as described in 3GPP TS <NUM> version <NUM>. The setup may be performed via a run of the NAS Security Mode Command Procedure. Optionally, the AMF <NUM> relays information related to the established AKMA context received from the AMF <NUM> in a downlink NAS message to the terminal device <NUM>. For example, this information may be included in the NAS SMC Command message or in a Registration Accept message or via the terminal device configuration update procedure described in 3GPP TS <NUM> version <NUM>.

Some embodiments of the present disclosure include deriving the AKMA anchor key KAKMA. In one embodiment, the AKMA anchor key KAKMA is derived as a sibling to KAUSF. <FIG> illustrates operations to derive a KAKMA sibling key to KAUSF. In another embodiment, the AKMA anchor key KAKMA is derived as a child to KAUSF. <FIG> illustrates operations to derive a KAKMA child to KAUSF.

Referring to <FIG>, when authenticating the terminal device <NUM> uses <NUM> authentication and key agreement (<NUM> AKA) protocol signaling during a primary authentication session for the terminal device, and responsive to a successful authentication of the terminal device <NUM>, the network server obtains a first key, K <NUM>. K <NUM> may be a root key. The network server generates bootstrapping parameters, including a second key (KAKMA <NUM>) that is derived based on a third key (CK, IK <NUM>) as a sibling key to a fourth key (KAUSF <NUM>).

Continuing with reference to <FIG>, when authenticating the terminal device <NUM> uses Extensible Authentication Protocol-Authentication and Key Agreement Prime, EAP-AKA', protocol signaling during a primary authentication session for the terminal device <NUM>, the network server obtains a first key, K <NUM>. K <NUM> may be a root key. The network server generates bootstrapping parameters, including a second key (KAKMA <NUM>') is derived based on a third key (CK, IK <NUM>) and a fourth key (CK', IK' <NUM>) as a sibling key to a fifth key (KAUSF <NUM>').

Referring to <FIG>, when authenticating the terminal device <NUM> uses <NUM> AKA protocol signaling during a primary authentication session for the terminal device, and responsive to a successful authentication of the terminal device <NUM>, the network server obtains a first key, K <NUM>. K <NUM> may be a root key. The network server generates bootstrapping parameters, a second key (KAKMA <NUM>) is derived as a child key from a third key (KAUSF <NUM>).

Continuing with reference to <FIG>, when authenticating the terminal device <NUM> uses EAP-AKA' protocol signaling during a primary authentication session for the terminal device <NUM>, the network server obtains a first key, K <NUM>. K <NUM> may be a root key. The network server generates bootstrapping parameters, including a second key (KAKMA <NUM>) is derived as a child key to a third key (KAUSF <NUM>') based on a fourth key (CK, IK <NUM>) and a fifth key (CK', IK' <NUM>).

The procedure for EAP-AKA' is defined in 3GPP TS <NUM> version <NUM>. In that procedure, the AUSF derives EMSK from CK' and IK' as described in RFC <NUM> and Annex F of 3GPP TS <NUM> version <NUM>. The AUSF uses the most significant <NUM> bits of EMSK as the KAUSF.

In one embodiment, when deriving the AKMA key as a sibling key, the AUSF <NUM> uses other <NUM> bits from the EMSK, for example the following or the last ones may be used as the KAKMA. Since the derivation of the AKMA key is based on the EMSK it is EAP-method independent. In other words, the derivation of the AKMA key works for EAP methods such as EAP-TLS or EAP-PSK, etc. in addition EAP-AKA'.

In another embodiment, when generating the AKMA key as a child key, KAKMA will be a sibling key to KSEAF and it may be derived similarly as KSEAF for example using another FC value and possible other parameters from the KAUSF.

The <NUM>-AKA procedure is described in 3GPP TS <NUM> version <NUM>. For <NUM> AKA, the KAUSF is derived by the UDM (not by AUSF as in EAP-AKA'). Thus, the UDM also may be appropriate for derivation of the KAKMA. In one embodiment, when deriving the AKMA key as a sibling key, KAKMA may be derived similar to KAUSF but using another FC value. In another embodiment, when generating the AKMA key as a child key, KAKMA may be a sibling key to KSEAF and KAKMA may be derived similarly as KSEAF for example using another FC value and possible other parameters from the KAUSF. The derivation may be performed either by the AUSF <NUM> or by the UDM <NUM>.

These and other related operations will now be described in the context of the operational flowchart of <FIG> that are performed by a network server. Each of the operations described in <FIG> can be combined and/or omitted in any combination with each other, and it is contemplated that all such combinations fall within the spirit and scope of this disclosure. For example, some operations of <FIG> may be optional or omitted (e.g., operations <NUM>, <NUM>, <NUM>, and <NUM> may be omitted).

<FIG> is a flowchart of operations that may be performed by a network server according to some embodiments of the present disclosure.

Referring to <FIG>, in some embodiments, network server <NUM> authenticates (<NUM>) terminal device <NUM> during a primary authentication session for the terminal device <NUM>.

Responsive to a successful authentication of the terminal device <NUM>, obtains (<NUM>) a first key (K <NUM>, <NUM>). The first key may be a root key.

The network server <NUM> generates (<NUM>) bootstrapping security parameters. This may include at least a bootstrapping key denoted by KAKMA (<NUM>, <NUM>', <NUM>) and a temporary identifier. The temporary identifier identifies the terminal device <NUM> and the bootstrapping security parameters (also referred to herein as AKMA parameters). This set of AKMA parameters also is referred to herein as the terminal device AKMA context.

The network server <NUM> communicates (<NUM>) an authentication response message to the terminal device <NUM>. The authentication message includes at least one of the bootstrapping security parameters.

Optionally, in some embodiments, the network server <NUM> provisions (<NUM>) the AKMA security context to the AAuF <NUM>.

Optionally, in some embodiments, the AAuF function is performed by the AUSF function <NUM>. In that case, the AUSF <NUM> stores (<NUM>) the AKMA context of the terminal device <NUM>.

Optionally, in some embodiments, when <NUM>-AKA is performed, the AKMA context is generated by a Unified Data Management Function server (<NUM>), which provides (<NUM>) the bootstrapping security parameters to a first authentication server (AAuF <NUM>) through a second authentication server (AUSF <NUM>).

In some embodiments, the authentication response (<NUM>, <NUM>) message includes at least one of the bootstrapping security parameters including, but not limited to, the temporary identifier and an indication of successful bootstrapping security parameters generation.

In some embodiments, the network server is an Authentication Server Function, AUSF, server (<NUM>). The authentication server may be an Authentication and Key Management for Applications, AKMA, Authentication Function server (<NUM>).

In some embodiments, the network server is a Unified Data Management Function, UDM, server (<NUM>), and may further provide the bootstrapping security parameters to a first authentication server (<NUM>).

In other embodiments, the network server is a Unified Data Management Function, UDM, server (<NUM>), and may further provide the bootstrapping security parameters to the first authentication server (<NUM>) through a second authentication server (<NUM>).

<FIG> is a block diagram illustrating a terminal device <NUM> that is configured according to some embodiments. The terminal device <NUM> can include, without limitation, a wireless terminal, a wireless communication device, a wireless communication terminal, a terminal node/terminal device/device, etc. The terminal device <NUM> includes a RF front-end <NUM> comprising one or more power amplifiers the transmit and receive through antennas of an antenna array <NUM> to provide uplink and downlink radio communications with a radio network node (e.g., a base station, eNB, gNB, etc.) of a telecommunications network. Instead of or in addition to the RF front-end <NUM>, the terminal device <NUM> may include a light reception front-end configured to receive light signaling such from a Light WiFi AP. Terminal device <NUM> further includes a processor circuit <NUM> (also referred to as a processor) coupled to the RF front end <NUM> and a memory circuit <NUM> (also referred to as memory). The memory <NUM> stores computer readable program code that when executed by the processor <NUM> causes the processor <NUM> to perform operations according to embodiments disclosed herein.

<FIG> is a block diagram illustrating a network server <NUM> (e.g., a network node, an authentication server, a key management server, etc.) of a telecommunications network. The network node <NUM> includes processing circuitry <NUM> (also referred to as a processor), a memory circuit <NUM> (also referred to as memory), and a network interface <NUM> (e.g., wired network interface and/or wireless network interface) configured to communicate with other network nodes. The network node <NUM> may be configured as a radio network node containing a RF front-end and/or a light signaling front-end with one or more power amplifiers <NUM> that transmit and receive through antennas of an antenna array <NUM>. The memory <NUM> stores computer readable program code that when executed by the processor <NUM> causes the processor <NUM> to perform operations according to embodiments disclosed herein.

As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are openended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof.

Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 4160b, and WDs <NUM>, 4110b, and 4110c (also referred to as mobile terminals). In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

As used herein, wireless device (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the WD may be a UE or other terminal implementing the 3GPP narrow band internet of things (NB-loT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

<FIG>: User Equipment in accordance with some embodiments.

UE <NUM> may be any UE identified by the 3rd Generation Partnership Project (3GPP), including a NB-loT UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE. UE <NUM>, as illustrated in <FIG>, is one example of a WD configured for communication in accordance with one or more communication standards promulgated by the 3rd Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and/or <NUM> standards.

Network connection interface <NUM> may be configured to provide a communication interface to network 4243a. Network 4243a may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 4243a may comprise a Wi-Fi network.

In <FIG>, processing circuitry <NUM> may be configured to communicate with network 4243b using communication subsystem <NUM>. Network 4243a and network 4243b may be the same network or networks or different network or networks. Communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with network 4243b.

Network 4243b may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 4243b may be a cellular network, a Wi-Fi network, and/or a near-field network.

<FIG>: Telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments.

Access network <NUM> comprises a plurality of base stations 4412a, 4412b, 4412c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 4413a, 4413b, 4413c. Each base station 4412a, 4412b, 4412c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 4413c is configured to wirelessly connect to, or be paged by, the corresponding base station 4412c. A second UE <NUM> in coverage area 4413a is wirelessly connectable to the corresponding base station 4412a.

<FIG>: Host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments.

It is noted that host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of base stations 4412a, 4412b, 4412c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments may improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the deblock filtering for video processing and thereby provide benefits such as improved video encoding and/or decoding.

<FIG>: Methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

Claim 1:
A method for authentication and key management for applications, AKMA, for a terminal device (<NUM>) in a wireless communication network, the method being performed by the terminal device (<NUM>), the method comprising:
responsive to a successful authentication of the terminal device (<NUM>) with an authentication server function, AuSF (<NUM>), during a primary authentication session for the terminal device, obtaining a first key (<NUM>');
receiving an authentication response message from the AuSF, wherein the authentication response message comprises at least one of a plurality of bootstrapping security parameters, wherein the parameters comprise a second key (<NUM>) derived from the first key (<NUM>'), and a temporary identifier, and wherein the temporary identifier identifies the terminal device and the bootstrapping security parameters; and
communicating with an AKMA Application Function, AKMA AF (<NUM>) using the at least one of the bootstrapping security parameters to be authenticated by an AKMA Authentication Function, AAuF (<NUM>).