Authentication and key management of a ue

Abstract

There is provided techniques for authentication and key management of a UE. A method is performed by a broker node. The broker node has an agreement with a set of ASP nodes and a set of MNO nodes. The method comprises receiving a request from an ASP node in the set of ASP nodes for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. The method comprises forwarding the request, and an identifier of the ASP node, and protection parameters of the ASP node to an MNO node in the set of MNO nodes. The MNO node is selected based on the key identifier. The method comprises receiving an ASP key and an ASP specific identifier of the UE from the MNO node. The method comprises forwarding the ASP key and the ASP specific identifier of the UE to the ASP node.

Description

[0001] AUTHENTICATION AND KEY MANAGEMENT OF A UE

[0002] TECHNICAL FIELD

[0003] Embodiments presented herein relate to methods, a broker node, an Application Service Provider node, a Mobile Network Operator node, computer programs, and a computer program product for authentication and key management of a User Equipment.

[0004] BACKGROUND

[0005] In general terms, Generic Bootstrapping Architecture (GBA) provides a mechanism for sharing a secret key between a User Equipment (UE) and a Network Application Function (NAF), where the secret key is to be used for security purposes such as authentication and session key generations. The network and the UE derive the Ks key and the Bootstrapping Transaction Identifier (B-TID). When the UE wants to start a communication with the NAF, the UE generates a Ks_NAF key from the Ks key and sends the B-TID to the NAF. The NAF sends the B-TID to the Bootstrapping Server Function (BSF) of the network to learn the Ks_NAF key, which is also generated by the BSF. Then, the Ks_NAF key is utilized for establishment of secure communication between the UE and the NAF.

[0006] In general terms, the Authentication and Key Agreement for Applications using 3GPP credentials in 5G (AKMA) provides a key sharing mechanism between the UE and an Application Function (AF) to support authentication and key management aspects for applications based on subscription credential(s) in a fifth generation (5G) telecommunication system. The network and the UE derive a KAKMA key and an AKMA Key (KAKMA) identifier (A-KID). When the UE wants to start a communication with the AF, the UE derives the Application Function (KAF) key from the KAKMA key and sends the A-KID to the AF. The AF learns the KAF key for the A- KID from the AKMA Anchor Function (AAnF) of the network by sending the A-KID to the AAnF via a Network exposure Function (NEF) if the AF is located outside the mobile operator network domain or directly to the AAnF when the AF is located inside the mobile operator network domain. Then KAF key could be used for communication security authentication or communication security bootstrapping between the UE and the AF. In Clause 4.2.2a and Annex K of 3GPP TS 33.120 “Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)”, version 17.4.0, is explained how a GBA Zn-Proxy can be used for the case that the UE has contacted a NAF that is operated outside the network of the Mobile Network Operator (MNO) of the UE. In that case, the visited NAF can use a use a Zn-Proxy of the NAF’s network to communicate with the BSF of the UE.

[0007] Existing identity federation technologies can be used to decrease the number of security credentials (such as passwords) to be used for different services, but the user still needs to have at least one password.

[0008] In view of the above, with the help of usage of 3GPP credentials stored in the Universal Integrated Circuit Card (UICC) of the UE, GBA or AKMA could be used to relieve the user from remembering any password. However, since both GBA and AKMA are services provided by MNOs, a global use of GBA and / or AKMA by Application Service Providers (ASPs) for this purpose requires pairwise agreements between each ASPS and many, possibly hundreds of, MNOs. This is not scalable.

[0009] According to solution #7 in 3GPP TS 33.535 “Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)”, version 17.7.0 proxy is proposed to be used. However, the solution does not address the case of having multiple MNOs. Further, the proxy is considered a trusted with the application key (K_NAF), which is used to secure the communication between the UE and the NAF.

[0010] Pairwise agreements are also required for using a GBA Zn-Proxy. Consequently, when there are N number of MNOs participating in a Generic Authentication Architecture (GAA), the total number of agreements becomes N (N -1) / 2, with each MNO needing N -1 agreements. Also, the Zn-Proxy can access the GBA key, which may not be desirable from a security perspective.

[0011] Hence, there is still a need for improved authentication and key management.

[0012] SUMMARY

[0013] An object of embodiments herein is to address the above issues. A particular object is to provide authentication and key management procedures that do not suffer from the above issues, or where the above issues at least are mitigated or reduced.

[0014] A particular object is to provide authentication and key management procedures that do not require pairwise agreements between MNOs (or ASPs).

[0015] According to a first aspect there is presented a method for authentication and key management of a UE. The method is performed by a broker node. The broker node has an agreement with a set of ASP nodes and a set of MNO nodes. The method comprises receiving a request from an ASP node in the set of ASP nodes for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. The method comprises forwarding the request, and an identifier of the ASP node, and protection parameters of the ASP node to an MNO node in the set of MNO nodes. The MNO node is selected based on the key identifier. The method comprises receiving an ASP key and an ASP specific identifier of the UE from the MNO node. The method comprises forwarding the ASP key and the ASP specific identifier of the UE to the ASP node.

[0016] According to a second aspect there is presented a broker node for authentication and key management of a UE. The broker node is configured to have an agreement with a set of ASP nodes and a set of MNO nodes. The broker node comprises processing circuitry. The processing circuitry is configured to cause the broker node to receive a request from an ASP node in the set of ASP nodes for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. The processing circuitry is configured to cause the broker node to forward the request, and an identifier of the ASP node, and protection parameters of the ASP node to an MNO node in the set of MNO nodes. The MNO node is selected based on the key identifier. The processing circuitry is configured to cause the broker node to receive an ASP key and an ASP specific identifier of the UE from the MNO node. The processing circuitry is configured to cause the broker node to forward the ASP key and the ASP specific identifier of the UE to the ASP node.

[0017] According to a third aspect there is presented a computer program for authentication and key management of a UE, the computer program comprising computer program code which, when run on processing circuitry of a broker node configured to have an agreement with a set of ASP nodes and a set of MNO nodes, causes the broker node to perform actions. One action comprises the broker node to receive a request from an ASP node in the set of ASP nodes for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. One action comprises the broker node to forward the request, and an identifier of the ASP node, and protection parameters of the ASP node to an MNO node in the set of MNO nodes. The MNO node is selected based on the key identifier. One action comprises the broker node to receive an ASP key and an ASP specific identifier of the UE from the MNO node. One action comprises the broker node to forward the ASP key and the ASP specific identifier of the UE to the ASP node.

[0018] According to a fourth aspect there is presented a method for authentication and key management of a UE. The method is performed by an ASP node. The ASP node has an agreement with a broker node. The method comprises receiving a request from the UE for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. The method comprises forwarding the request to the broker node. The method comprises receiving an ASP key and an ASP specific identifier of the UE from the broker node.

[0019] According to a fifth aspect there is presented an ASP node for authentication and key management of a UE. The ASP node is configured to have an agreement with a broker node. The ASP node comprises processing circuitry. The processing circuitry is configured to cause the ASP node to receive a request from the UE for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. The processing circuitry is configured to cause the ASP node to forward the request to the broker node. The processing circuitry is configured to cause the ASP node to receive an ASP key and an ASP specific identifier of the UE from the broker node.

[0020] According to a sixth aspect there is presented a computer program for authentication and key management of a UE, the computer program comprising computer program code which, when run on processing circuitry of an ASP node being configured to have an agreement with a broker node, causes the ASP node to perform actions. One action comprises the ASP node to receive a request from the UE for the UE to access a service provided by the ASP node. The request comprises a key identifier of a key shared between the ASP node and the UE. One action comprises the ASP node to forward the request to the broker node. One action comprises the ASP node to receive an ASP key and an ASP specific identifier of the UE from the broker node.

[0021] According to a seventh aspect there is presented a method for authentication and key management of a UE. The method is performed by an MNO node. The MNO node has an agreement with a broker node. The method comprises receiving a request from the broker node for the UE to access a service provided by the ASP node. The request comprises a key identifier, an identifier of the ASP node, and protection parameters of an ASP node. The method comprises generating an ASP key based on the received request and obtaining an ASP specific identifier of the UE. The method comprises sending the ASP key and the ASP specific identifier of the UE to the broker node.

[0022] According to an eighth aspect there is presented an MNO node for authentication and key management of a UE. The MNO node is configured to have an agreement with a broker node. The MNO node comprises processing circuitry. The processing circuitry is configured to cause the MNO node to receive a request from the broker node for the UE to access a service provided by the ASP node. The request comprises a key identifier, an identifier of the ASP node, and protection parameters of an ASP node. The processing circuitry is configured to cause the MNO node to generate an ASP key based on the received request and obtaining an ASP specific identifier of the UE. The processing circuitry is configured to cause the MNO node to send the ASP key and the ASP specific identifier of the UE to the broker node.

[0023] According to a ninth aspect there is presented a computer program for authentication and key management of a UE, the computer program comprising computer program code which, when run on processing circuitry of an MNO node being configured to have an agreement with a broker node, causes the MNO node to perform actions. One action comprises the MNO node to receive a request from the broker node for the UE to access a service provided by the ASP node. The request comprises a key identifier, an identifier of the ASP node, and protection parameters of an ASP node. One action comprises the MNO node to generate an ASP key based on the received request and obtaining an ASP specific identifier of the UE. One action comprises the MNO node to send the ASP key and the ASP specific identifier of the UE to the broker node. According to a tenth aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect, the sixth aspect, and the ninth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium can be a non- transitory computer readable storage medium.

[0024] Advantageously, these aspects provide authentication and key management procedures that do not suffer from the above issues.

[0025] Advantageously, these aspects provide authentication and key management procedures that do not require pairwise agreements between MNOs (or ASPs).

[0026] Advantageously, according to these aspects only the broker node needs to have an agreement with each MNO. Therefore, for N number of MNOs, only N agreements will be sufficient, with each MNO needing only one single agreement.

[0027] Advantageously, using these aspects, user will not have to remember any passwords for access to many services.

[0028] Advantageously, these aspects can be utilized by UEs, such as Internet of Things (loT) devices or the like, which are without user interface, for authentication and key management purposes.

[0029] Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

[0030] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

[0032] Fig. 1 is a schematic diagram illustrating a system according to embodiments;

[0033] Figs. 2, 3, and 4 are flowcharts of methods according to embodiments;

[0034] Figs. 5 and 6 are signaling diagrams of methods according to embodiments:

[0035] Fig. 7 is a schematic diagram showing functional units of a broker node according to an embodiment;

[0036] Fig. 8 is a schematic diagram showing functional modules of a broker node according to an embodiment;

[0037] Fig. 9 is a schematic diagram showing functional units of an ASP node according to an embodiment;

[0038] Fig. 10 is a schematic diagram showing functional modules of an ASP node according to an embodiment;

[0039] Fig. 11 is a schematic diagram showing functional units of an MNO node according to an embodiment;

[0040] Fig. 12 is a schematic diagram showing functional modules of an MNO node according to an embodiment; and

[0041] Fig. 13 shows one example of a computer program product comprising computer readable means according to an embodiment.

[0042] DETAILED DESCRIPTION

[0043] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

[0044] Fig. i shows a system io comprising a broker node 100 sitting between service providers (as represented by ASP nodes 200a, ..., 2oon, ..., 200N) and operators (as represented by MNO nodes 300a, ..., 300m, ..., 300M). Although the ASP nodes 200a:200N will be referred to as a set of ASP nodes 200a:200N and the MNO nodes 300a:300M will be referred to as a set of MNO nodes 300a:300M, it could be that at least one of these sets contains just a single member, i.e., that there is only one single ASP node 2oon and / or one single MNO node 300m. Each ASP node 2oon has an agreement with the broker node 100, as indicated by double-directional arrows. Further, each MNO node 300m also has an agreement with the broker node 100, as indicated by double-directional arrows. In this respect, the agreement might pertain to consumption of services, provision or credentials, etc. Further in this respect, it might thus be assumed that the broker node 100 thus has established a respective (first) security trusted relation with each of the ASP nodes 200a: 200N on the one hand and a respective (second) security trusted relation with each of the MNO nodes 300a:300M on the other hand. Such security trusted relations could be established using cryptographic techniques and / or protocols. The (first and second) security trusted relations could then define that each of the ASP nodes 200a: 200N and each of the MNO nodes 300a:300M has an agreement with the broker node 100.

[0045] It is not needed for any ASP node 2oon to have an agreement with any MNO node 300m. As will be further disclosed below, the broker node 100 is utilized during authentication and key management of a UE. The broker node 100 can in this respect be used for enabling GBA and AKMA for identity federation, addressing the above challenges in terms of security and trust as well as scalability. It is here noted that there can be more than one broker node 100, and different broker node 100 can have agreements with different sets of ASP node 2oon and / or sets of MNO node 300m. In this case the broker node 100 can have agreements with each other, and they can create a cluster to extend the total coverage to be able to reach all ASP node 2oon and MNO node 300m. For ease of description, but without loss of generality, it will hereinafter be assumed that there is only one single broker node 100. Reference is now made to Fig. 2 illustrating a method for authentication and key management of a UE as performed by the broker node 100 according to an embodiment. The broker node 100 has an agreement with a set of ASP nodes 200a:200N and a set of MNO nodes 300a:300M.

[0046] S102: The broker node 100 receives a request from an ASP node 2oon in the set of ASP nodes 200a:200N for the UE to access a service provided by the ASP node 2oon. The request comprises a key identifier of a key shared between the ASP node 2oon and the UE.

[0047] S104: The broker node 100 forwards the request, and an identifier of the ASP node 2oon, and protection parameters of the ASP node 2oon to an MNO node 300m in the set of MNO nodes 300a:300M. The MNO node 300m is selected based on the key identifier.

[0048] S106: The broker node 100 receives an ASP key and an ASP specific identifier of the UE from the MNO node 300m.

[0049] S108: The broker node 100 forwards the ASP key and the ASP specific identifier of the UE to the ASP node 2oon.

[0050] Embodiments relating to further details of authentication and key management of a UE as performed by the broker node 100 will now be disclosed with continued reference to Fig. 2.

[0051] There maybe different types of key identifiers. In some embodiments, the key identifier is an AKMA key identifier or a GBA key identifier. One non-limiting example of an AKMA key identifier is an A- KID. One non-limiting example of a GBA key identifier is a B-TID.

[0052] There may be different types of protection parameters. In some embodiments, the protection parameters are defined by a certificate of the ASP node 2oon. One nonlimiting example of a protection parameters defined by a certificate of the ASP node 2oon is an AF certificate.

[0053] There may be different ways in which the broker node 100 obtains identifier of the ASP node 2oon (as forwarded to the MNO node 300m in S104). In some embodiments, the identifier of the ASP node 2oon is obtained either from the protection parameters or from local configuration in the broker node 100. For example, the identifier of the ASP node 2oon could be obtained from the protection parameters of the ASP node 2oon, such as from the AF certificate. For example, the local configuration could be obtained as part of establishing the security trusted relation with the ASP nodes 2oon.

[0054] Reference is now made to Fig. 3 illustrating a method for authentication and key management of a UE as performed by the ASP node 2oon according to an embodiment. The ASP node 2oon has an agreement with a broker node 100.

[0055] S202: The ASP node 2oon receives a request from the UE for the UE to access a service provided by the ASP node 2oon. The request comprises a key identifier of a key shared between the ASP node 2oon and the UE.

[0056] S204: The ASP node 2oon forwards the request to the broker node 100.

[0057] S206: The ASP node 2oon receives an ASP key and an ASP specific identifier of the UE from the broker node 100. It is here understood that in case the ASP key and the ASP specific identifier are security protected, then the ASP node 2oon needs to perform security related operations (e.g., decryption) using the protection parameters of the ASP node 2oon to retrieve the ASP key and the ASP specific identifier in clear text.

[0058] Embodiments relating to further details of authentication and key management of a UE as performed by the ASP node 2oon will now be disclosed with continued reference to Fig. 3.

[0059] The request received from the UE might comprise more information than the key identifier of the key shared between the ASP node 2oon and the UE.

[0060] For example, in case the access of the service is associated with an application layer username, also this information might be provided in the request. Thus, in some embodiments, the request further comprises an application layer username of the UE for the service. For example, the request received from the UE might comprise an indication of which authentication procedure needs to be executed. Hence, in some embodiments, the request further comprises an indication of an authentication procedure for the UE. As will be further disclosed below, this could enable the ASP node 2oon to distinguish whether the authentication procedure for the UE will be via a user agent or via a terminal.

[0061] There might be different actions taken by the ASP node 2oon upon having received the ASP key and an ASP specific identifier of the UE from the broker node 100 in S206.

[0062] In some aspects, the ASP node 2oon authenticates the UE. Therefore, in some embodiments, the ASP node 2oon is configured to perform (optional) step S208.

[0063] S208: The ASP node 2oon authenticates the UE at least based on the ASP key.

[0064] In some aspects, authenticating the UE involves establishing a secure communication channel with the UE.

[0065] There might be different actions taken by the ASP node 2oon upon having authenticating the UE.

[0066] In some aspects, the ASP node 2oon stores the ASP specific identifier of the UE together with an association to a user account of the UE. Therefore, in some embodiments, the ASP node 2oon is configured to perform (optional) step S218.

[0067] S218: The ASP node 2oon stores the ASP specific identifier of the UE with an association to a user account of the UE.

[0068] In some aspects, and as will be disclosed next, the ASP node 2oon performs further actions before authenticating the UE. One purpose of this is to enable an alternative authentication of the UE to be performed.

[0069] To start, the ASP node 2oon might select, or generate, a freshness parameter and provide this freshness parameter to the UE. In this respect, and as will be further disclosed below, there might be different types of freshness parameters. In some nonlimiting examples, the freshness parameter is a one-time password (OTP) or a quick response (QR) code. Therefore, in some embodiments, the ASP node 2oon is configured to perform (optional) steps S210 and S212.

[0070] S210: The ASP node 2oon generates a freshness parameter.

[0071] S212: The ASP node 2oon sends a response message to the UE. The response message comprises the freshness parameter.

[0072] The response message might be a GBA / AKMA Ua / Ua* protocol session response. It is here noted that S212 does not need to be executed directly after S210. It is here further noted that at least S210 can be performed even before the ASP node 2oon receives the request from the UE in S202.

[0073] Further, the UE might then return with authentication credentials to the ASP node 2oon and the ASP node 2oon might use these authentication credentials to authenticate the UE. Therefore, in some embodiments, the ASP node 2oon is configured to perform (optional) steps S214 and S216.

[0074] S214: The ASP node 2oon receives authentication credentials for a user of the UE. As will be further disclosed below, the authentication credentials might be received from the UE or from another entity, such as a terminal.

[0075] The authentication credentials as received from the UE are based on the freshness parameter sent to the UE in S212. In some examples, the authentication credentials are the OTP or QR code sent to the UE.

[0076] S216: The ASP node 2oon authenticates the user of the UE based on comparing the received authentication credentials to authentication credentials as computed by the ASP node 2oon at least based on the freshness parameter. In this way it can be ensured that the user is in possession of the UE.

[0077] In some examples, the authentication on S216 is further based at least on the ASP key.

[0078] Upon having authenticated the UE (or at least the user of the UE) in either S208 or S216, the ASP node 2oon might notify the user of a result of the authentication. Therefore, in some embodiments, the ASP node 2oon is configured to perform (optional) step S220. S220: The ASP node 2oon sends a result of the authentication (as performed either in S208 or in S216) towards the user of the UE. The result might, for example, be sent either to the UE or to the aforementioned terminal

[0079] Reference is now made to Fig. 4 illustrating a method for authentication and key management of a UE as performed by the MNO node 300m according to an embodiment. The MNO node 300m has an agreement with a broker node 100.

[0080] S302: The MNO node 300m receives a request from the broker node 100 for the UE to access a service provided by the ASP node 2oon. The request comprises a key identifier, an identifier of the ASP node 2oon, and protection parameters of an ASP node 2oon.

[0081] S304: The MNO node 300m generates an ASP key based on the received request and obtaining an ASP specific identifier of the UE.

[0082] S306: The MNO node 300m sends the ASP key and the ASP specific identifier of the UE to the broker node 100. It is here understood that the ASP key and the ASP specific identifier can be securely protected before being transmitted to the broker node 100. For example, the ASP key and the ASP specific identifier can be securely protected using the protection parameters of the ASP node 2oon.

[0083] Embodiments relating to further details of authentication and key management of a UE as performed by the MNO node 300m will now be disclosed with continued reference to Fig. 4.

[0084] There may be different types of ASP specific identifiers of the UE. In some embodiments, the ASP specific identifier of the UE is a random number generated by the MNO node 300m. This random number is by the MNO node 300m not used as another ASP specific identifier. Additionally or alternatively, in some embodiments, the ASP specific identifier of the UE is computed as a function of the identifier of the ASP node 2oon and / or an identifier of a subscriber of the UE. For example, the ASP specific identifier of the UE might be generated using a function, such as a hash function, with the inputs International Mobile Subscriber Identifier (IMSI) or subscriber permanent identifier (SUPI), and AF identifier. After generation of the ASP specific identifier, the ASP specific identifier can be stored in the MNO node 300m so that the MNO node 300m can use it later on a per need basis.

[0085] Aspects of using the herein disclosed embodiments for authentication of a user towards an AF or NAF (associated with an ASP node 2oon) via a user agent in the UE will be disclosed next with reference to the signalling diagram of Fig. 5. The notation (N)AF will be used to represent the AF / NAF when no distinction is needed between the AF and the NAF. The user agent can be an application client of the ASP or it can be a generic application client, such as a web browser. The UE can be without a user interface. In this case the procedure can be used for authentication and key management purposes for loT devices, or the like.

[0086] Step 1: The user agent starts communication with the AF and sends a request to the UE for accessing services of the AF. In this request the UE also sends a AKMA or GBA key identifier (A- KID or B-TID). If there is an application layer username known by the AF, this username can also be sent by the UE to the AF.

[0087] According to the GBA specification, the UE first sends a connection request to the AF and then the AF selects to use GBA and then the UE runs the GBA bootstrapping procedure to learn the GBA key and B-TID. This procedure can be integrated to the present procedure as follows. The UE can send the Public Land Mobile Network (PLMN) identifier (ID) to the AF if there is no available B-TID / A-KID. If the AF selects to use GBA, then the AF can request the UE to run bootstrapping. After bootstrapping, the UE learns the B-TID and sends it to the AF. These additional steps can be executed before step 1.

[0088] Step 2: The AF sends the request to the broker node 100.

[0089] Step 3: The broker node 100 sends the request to the corresponding MNO using the information in the B-TID and A- KID to locate the MNO. Also the broker node 100 sends protection parameters of the AF (e.g. the certificate of the AF). As part of the (N)AF key request to the MNO (BSF or AAnF) the broker node 100 supplies the (N)AF ID. The broker node 100 could obtain the AF ID and the public key of the AF from the AF certificate or from other means (such as local configuration). Step 4: The MNO generates a (N)AF key and obtains the AF specific UE ID. For obtaining the AF specific UE ID, the MNO can fetch the AF specific UE ID from the Unified Data Management (UDM) entity (if existing), or the MNO can itself generate an AF specific UE ID. Then the MNO optionally encrypts the AF specific UE ID using the protection parameters of the AF (e.g., the public key in the certificate of the AF).

[0090] The AF specific UE ID can be generated by the MNO and be stored at its UDM entity as a table with the following columns: UE IMSI, (N)AF ID, and AF specific UE ID. The generated AF specific UE ID can be a unique random value assigned by the MNO. Alternatively, the MNO could also compute an AF specific UE ID generation key K_idg and store the key in the UDM entity as a map between the IMSI of the UE and the K_idg. The key K_idg could be computed, for example, as a keyed hash of the associated IMSI (where a fixed random value could be padded with the IMSI) using the primary key K. It could also be computed using a key derivation function (KDF) where the primary key K is used as the input key. Basically, any cryptographically secure keyed hash function can be used to compute K_idg. The key K_idg can be transported to the AanF / BSF or it can be kept at the UDM entity. The AF specific UE ID can be computed as a keyed hash of the (N)AF ID where K_idg is used as the key. In this case also the function KDF or any cryptographically secure keyed hash function can be used.

[0091] Another example for the generation of the AF specific UE ID is as follows. The AF specific UE ID can be generated using a function (e.g., hash algorithm) with the inputs IMSI and / or SUPI, AF identifier and (optionally) a salt value which can be stored in the UDM entity with the subscription data. Since the hash result is a binary string, it can be represented using base64 encoding and can be truncated to shorten the length if it will be used also by the users. Instead of using IMSI / SUPI directly in the AF specific UE ID generation, an AKMA / GBA Generic Public Subscription Identifier (GPSI) can be derived from the IMSI / SUPI or generated by other means, and then this AKMA / GBA GPSI can be used to derive the AF specific GPSI.

[0092] Step 5: The MNO sends the (N)AF key and AF specific UE ID in an encrypted format to the broker node 100.

[0093] Step 6: The broker node 100 forwards the (N)AF key and AF specific UE ID to the AF.

[0094] The AF decrypts the (N)AF key and (N)AF specific UE ID. In this way, the AF is able to have the (N)AF key and AF specific UE ID even though the AF does not have any agreement with the MNO (or vice versa). The (N)AF key and AF specific UE ID can then be used by the AF to authenticate the user.

[0095] Step 7: The AF responds to the UE with a GBA or AKMA Ua / Ua* protocol session response.

[0096] Step 8: The UE generates the (N)AF key as per the GBA or AKMA specifications.

[0097] Step 9: The AF authenticates the user agent (i. e. , authenticates the user) using the AF key. Also, the B-TID / A-KID can be used in the authentication procedure if steps 1 and 9 are not executed in the same communication session.

[0098] Since the (N)AF ID is used in the (N)AF key generation and the MNO encrypts the (N)AF keys such that only the entity who has the (N / AF ID can decrypt the key, the broker node 100 cannot execute a man in the middle attack.

[0099] The (N)AF specific UE ID does not need to be known by the user. When the user registers to the (N)AF, during registration the (N)AF learns the (N)AF specific UE ID from the network and stores it as the user identifier. When the user wants to authenticate himself / herself with the (N)AF, the (N)AF again learns the (N)AF specific UE ID from the network and identifies the user using the prestored (N)AF specific UE ID. Thus, there is no need to consider multiple identifiers (3GPP layer identifier, application layer identifiers, etc.)

[0100] If there is already a username in the application layer (i.e., if the user has already an account with the (N)AF, where the user account is associated with a username, and the user wants to associate this user account with an MNO subscription using AKMA or GBA), the following steps can be executed.

[0101] First, the user logs in to her / his account with the (N)AF.

[0102] Then, an association with the MNO subscription is triggered by the user.

[0103] Then, steps 1-6 as disclosed above with reference to Fig. 5 are executed.

[0104] When the (N)AF learns the AF specific UE ID, the (N)AF stores the AF specific UE ID with the user account. This can be done before step 7 or after step 9. Then, the remaining steps (i.e., steps 7-9 as disclosed above with reference to Fig.) are executed.

[0105] Aspects of using the herein disclosed embodiments for user authentication towards the NAF or AF via a terminal will be disclosed next with reference to the signalling diagram of Fig. 6. The notation (N)AF will be used to represent the AF / NAF when no distinction is needed between the AF and the NAF. The terminal can be a personal computer, a ticket machine, an automated teller machine (ATM) machine of a bank, or the like.

[0106] Fig. 6 represents an example of a user-agent initiated procedure where the user wants an OTP or QR code to authenticate himself / herself to a service provided by the AF. The user agent can be an application client of the application service provider (the provider of the AF), a generic application, such as web browser, or an operating system level application. An example scenario can be that the user wants to access his / her bank account via an ATM machine, and where the user starts a web browser on his / her mobile phone, connects to the bank server to request a QR code to be shown to the ATM machine. According to the herein disclosed embodiments, the user does not need to know any password and download any application to achieve this.

[0107] As disclosed above, if there is an application layer username, or account name, then the AF can have a mapping between the username and AF specific UE ID and use this mapping through the procedures.

[0108] Step 1: The user requests an OTP or QR code to access a service of the AF.

[0109] Step 2-7: Same as steps 1-6 of Fig. 5.

[0110] Additionally in step 2, an indication can be sent to the AF so that the AF can know which procedure needs to be executed, i.e., the AF can distinguish whether the authentication will be via the user agent or via the terminal.

[0111] Step 8: The AF selects a freshness parameter. The freshness parameter can be provided as a random value. Also, the AF can set a timer for the freshness parameter. The AF stores the freshness parameter and the (N)AF specific UE ID mapping. Step 9: The AF responds to the UE with a GBA / AKMA Ua / Ua* protocol session response. The AF also sends the freshness parameter to the user agent.

[0112] Instead of generating the freshness parameter and sending it to the UE in step 8 and 9, this parameter can be generated and sent before step 2 as follows. In the GBA procedure, the UE first sends a connection request to the AF and then the AF selects to use the GBA procedure, and then the UE runs the GBA bootstrapping procedure to learn the GBA key and B-TID. This GBA procedure and freshness parameter can be integrated as follows. The UE can send the PLMN ID to the AF if there is no available B-TID / A-KID. If the AF decides to use GBA, then the AF can request the UE to run bootstrapping, generate the freshness parameter and send it to the UE. After bootstrapping, the UE learns the B-TID, generates the NAF key and derive the OTP or QR code.

[0113] Step 10: The user agent generates the (N)AF key as per the GBA or AKMA specifications.

[0114] Step 11: The user agent computes the OTP or QR code from the freshness parameter and the (N)AF key. For the derivation of the OTP or QR code from the freshness parameter and (N)AF key, a key derivation or hash function can be used. Since the OTP should be human-readable, the derivation result can be processed by a transformation function to derive a human-readable text. For example, base64 encoding and truncation can be used, or the result can be represented as decimal digits and can be truncated to make the length short.

[0115] Step 12: The user agent shows the OTP or QR code on a visual user interface (such as on a display screen) of the UE screen.

[0116] Step 13: User input in terms of the OTP, possibly in combination with some other information such as session identifier or username, is received. Alternatively, the QR code is presented to the terminal.

[0117] Step 14: The terminal sends the received OTP or presented QR code to the AF.

[0118] Step 15: The AF computes the OTP or QR code by using the freshness parameter and (N)AF key and compares the computed OTP or QR code to the received OTP or QR code. Also, the AF can check the freshness of the freshness parameter. The computation of the OTP or QR code at the AF can also be performed in advance in step 8 instead of in step 14. The (N)AF can delete the freshness parameter or the OTP or QR code after the freshness of it expires.

[0119] Step 16: The AF returns the authentication result to the terminal. Then the terminal decides to provide service to the user depending on the authentication result.

[0120] To bind the sessions between the user agent and (N)AF, and the user and (N)AF, any of the following two options can be applied.

[0121] According to a first option, the (N)AF generates the OTP or QR code in step 8. It can be considered that the OTP or QR code include both the session information and the password. Thus, when the (N)AF receives the OTP or QR code from the user, the (N)AF can check whether there is such an OTP or QR code stored. If there is no such a stored OTP or QR code, the (N)AF returns an indication of user authentication failure to the terminal.

[0122] According to a second option, in step 8 or before step 8, the (N)AF generates a random session identifier. If a QR code is not used, then the session identifier needs to be a human readable. To identify which alternative is used (i.e., OTP or QR code), an indication can be sent to the (N)AF in step 2. In step 8, the session identifier is also stored with this freshness parameter and (N)AF key. The (N)AF could additionally send this session identifier to the user agent in step 9. The user agent could then additionally show the session identifier to the user in step 12. The session identifier can be embedded to the QR code. The session identifier could be sent to the (N)AF in step 13, in addition to the OTP. The (N)AF could use this session identifier to find the freshness parameter or the OTP or QR code stored in the N(AF). If the OTP or QR code sent by the user matches the OTP or QR code computed and stored by the (N)AF, then the AF can be ensured that the user is the one who is using the UE identified by the (N)AF specific UE ID.

[0123] An alternative procedure to Fig. 6 will be disclosed below, identifying the required changes in the steps.

[0124] In step 8, the AF generates a random OTP or QR code instead of a freshness parameter. In step 9, a freshness parameter is not sent by the AF to the user agent.

[0125] In step io, in addition to generating the (N)AF key, the user agent and the AF runs an authentication protocol using the (N)AF key.

[0126] In step n, if the authentication is successful, then the AF sends a OTP or QR code to the user agent.

[0127] In step 14, the AF compares the received OTP or QR code to its own computed OTP or QR code.

[0128] Aspects of using the herein disclosed embodiments for user authentication towards the AF via a terminal and where the procedure is initiated from the terminal will be disclosed next, identifying the required changes in the steps of Fig. 5.

[0129] The user accesses the terminal and request an OTP or QR code. The OTP or QR code can be considered as defining a session identifier. The terminal can generate the OTP or QR code itself and send it to the AF, or the terminal can receive the OTP or QR code from the AF.

[0130] The steps of Fig. 5 are executed between the user agent in the UE and AF with the following additions.

[0131] In step 1, the user agent additionally sends the OTP or QR code to the AF.

[0132] Additionally in step 1, an indication can be sent to the AF so that the AF would know which procedure needs to be executed, i.e., the AF can distinguish whether the authentication will be via the user agent or via the terminal.

[0133] After step 9, the AF sends the authentication result to the terminal with the OTP or QR code. The information sent to the terminal can also include user-related data such as username, AF specific UE ID, or session identifier related to the user.

[0134] If the authentication result is successful, the terminal allows the user to access services provided via the terminal.

[0135] Fig. 7 schematically illustrates, in terms of a number of functional units, the components of a broker node 100 according to an embodiment. Processing circuitry no is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1310a (as in Fig. 13), e.g. in the form of a storage medium 130. The processing circuitry 110 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0136] Particularly, the processing circuitry 110 is configured to cause the broker node 100 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 130 may store the set of operations, and the processing circuitry 110 may be configured to retrieve the set of operations from the storage medium 130 to cause the broker node 100 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 110 is thereby arranged to execute methods as herein disclosed.

[0137] The storage medium 130 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0138] The broker node 100 may further comprise a communications (comm.) interface 120 for communications with any of the above-disclosed entities, functions, nodes, and devices in accordance with the herein disclosed embodiments. As such the communications interface 120 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0139] The processing circuitry 110 controls the general operation of the broker node 100 e.g. by sending data and control signals to the communications interface 120 and the storage medium 130, by receiving data and reports from the communications interface 120, and by retrieving data and instructions from the storage medium 130. Other components, as well as the related functionality, of the broker node 100 are omitted in order not to obscure the concepts presented herein.

[0140] Fig. 8 schematically illustrates, in terms of a number of functional modules, the components of a broker node 100 according to an embodiment. The broker node 100 of Fig. 8 comprises a number of functional modules; a receive module 110a configured to perform step S102, a forward module 110b configured to perform step S102, a receive module lioc configured to perform step Sio6, and a forward module nod configured to perform step Sio8. The broker node 100 of Fig. 8 may further comprise a number of optional functional modules, as represented by functional module lioe. In general terms, each functional module noa:noe maybe implemented in hardware or in software. Preferably, one or more or all functional modules noa:iioe may be implemented by the processing circuitry no, possibly in cooperation with the communications interface 120 and the storage medium 130. The processing circuitry 110 may thus be arranged to from the storage medium 130 fetch instructions as provided by a functional module 110a: 110a and to execute these instructions, thereby performing any steps of the broker node 100 as disclosed herein.

[0141] Fig. 9 schematically illustrates, in terms of a number of functional units, the components of an ASP node 2oon according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1310b (as in Fig. 13), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0142] Particularly, the processing circuitry 210 is configured to cause the ASP node 2oon to perform a set of operations, or steps, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 may be configured to retrieve the set of operations from the storage medium 230 to cause the ASP node 2oon to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

[0143] The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0144] The ASP node 2oon may further comprise a communications interface 220 for communications with any of the above-disclosed entities, functions, nodes, and devices in accordance with the herein disclosed embodiments. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0145] The processing circuitry 210 controls the general operation of the ASP node 2oon e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the ASP node 2oon are omitted in order not to obscure the concepts presented herein.

[0146] Fig. 10 schematically illustrates, in terms of a number of functional modules, the components of an ASP node 2oon according to an embodiment. The ASP node 2oon of Fig. 10 comprises a number of functional modules; a receive module 210a configured to perform step S202, a forward module 210b configured to perform step S204, and a receive module 210c configured to perform step S206. The ASP node 2oon of Fig. 10 may further comprise a number of optional functional modules, such as any of an authenticate (Auth.) module 2iod configured to perform step S208, a store module 2ioe configured to perform step S218, a generate module 2iof configured to perform step S210, a send module 210g configured to perform step S212, a receive module 2ioh configured to perform step S214, an authenticate (Auth.) module 2ioi configured to perform step S216, and a send module 2ioj configured to perform step S220. In general terms, each functional module 2ioa:2ioj maybe implemented in hardware or in software. Preferably, one or more or all functional modules 2ioa:2ioj may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 210a: 2ioj and to execute these instructions, thereby performing any steps of the ASP node 2oon as disclosed herein.

[0147] Fig. 11 schematically illustrates, in terms of a number of functional units, the components of an MNO node 300m according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1310c (as in Fig. 13), e.g. in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0148] Particularly, the processing circuitry 310 is configured to cause the MNO node 300m to perform a set of operations, or steps, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 may be configured to retrieve the set of operations from the storage medium 330 to cause the MNO node 300m to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

[0149] The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0150] The MNO node 300m may further comprise a communications interface 320 for communications with any of the above-disclosed entities, functions, nodes, and devices in accordance with the herein disclosed embodiments. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0151] The processing circuitry 310 controls the general operation of the MNO node 300m e.g. by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the MNO node 300m are omitted in order not to obscure the concepts presented herein.

[0152] Fig. 12 schematically illustrates, in terms of a number of functional modules, the components of an MNO node 300m according to an embodiment. The MNO node 300m of Fig. 12 comprises a number of functional modules; a receive module 310a configured to perform step S302, a generate / obtain (Gen.Obt.) module 310b configured to perform step S304, and a send module 310c configured to perform step S306. The MNO node 300m of Fig. 12 may further comprise a number of optional functional modules, as represented by functional module 3iod. In general terms, each functional module 3ioa:3iod may be implemented in hardware or in software. Preferably, one or more or all functional modules 3ioa:3iod maybe implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 3ioa:3iod and to execute these instructions, thereby performing any steps of the MNO node 300m as disclosed herein.

[0153] The broker node 100, ASP node 2oon, and / or MNO node 300m maybe provided as a standalone device or as a part of at least one further device. For example, the broker node 100, ASP node 2oon, and / or MNO node 300m may be provided in a node of the radio access network or in a node of the core network. Alternatively, functionality of the broker node 100, ASP node 2oon, and / or MNO node 300m maybe distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part (such as the radio access network or the core network) or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time. Thus, a first portion of the instructions performed by each of the broker node 100, ASP node 2oon, and / or MNO node 300m may be executed in a respective first device, and a second portion of the of the instructions performed by the broker node 100, ASP node 2oon, and / or MNO node 300m may be executed in a respective second device, and so on; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the broker node 100, ASP node 2oon, and / or MNO node 300m may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a broker node 100, ASP node 2oon, and / or MNO node 300m residing in a cloud computational environment. Therefore, although a single processing circuitry 110, 210, 310 is illustrated in Figs. 7, 9, 11 the processing circuitry 110, 210, 310 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 110a: noe, 2ioa:2ioj, 3ioa:3iod of Figs. 8, 10, 12 and the computer programs 1320a, 1320b, 1320c of Fig. 13.

[0154] Fig. 13 shows one example of a computer program product 1310a, 1310b, 1310c comprising computer readable means 1330. On this computer readable means 1330, a computer program 1320a can be stored, which computer program 1320a can cause the processing circuitry no and thereto operatively coupled entities and devices, such as the communications interface 120 and the storage medium 130, to execute methods according to embodiments described herein. The computer program 1320a and / or computer program product 1310a may thus provide means for performing any steps of the broker node 100 as herein disclosed. On this computer readable means 1330, a computer program 1320b can be stored, which computer program 1320b can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 1320b and / or computer program product 1310b may thus provide means for performing any steps of the ASP node 2oon as herein disclosed. On this computer readable means 1330, a computer program 1320c can be stored, which computer program 1320c can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 1320c and / or computer program product 1310c may thus provide means for performing any steps of the MNO node 300m as herein disclosed.

[0155] In the example of Fig. 13, the computer program product 1310a, 1310b, 1310c is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1310a, 1310b, 1310c could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1320a, 1320b, 1320c is here schematically shown as a track on the depicted optical disk, the computer program 1320a, 1320b, 1320c can be stored in any way which is suitable for the computer program product 1310a, 1310b, 1310c.

[0156] The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

CLAIMS1. A method for authentication and key management of a UE, wherein the method is performed by a broker node (too), wherein the broker node (too) has an agreement with a set of ASP nodes (200a: 200N) and a set of MNO nodes (300a:300M), and wherein the method comprises: receiving (S102) a request from an ASP node (2oon) in the set of ASP nodes (200a: 200N) for the UE to access a service provided by the ASP node (2oon), wherein the request comprises a key identifier of a key shared between the ASP node (2oon) and the UE; forwarding (S104) the request, and an identifier of the ASP node (20cm), and protection parameters of the ASP node (20cm) to an MNO node (300m) in the set of MNO nodes (300a:300M), wherein the MNO node (300m) is selected based on the key identifier; receiving (S106) an ASP key and an ASP specific identifier of the UE from the MNO node (300m); and forwarding (S108) the ASP key and the ASP specific identifier of the UE to the ASP node (20cm).

2. The method according to claim 1, wherein the key identifier is an AKMA key identifier or a GBA key identifier.

3. The method according to claim 1, wherein the protection parameters are defined by a certificate of the ASP node (20cm).

4. The method according to claim 1, wherein the identifier of the ASP node (20cm) is obtained either from the protection parameters or from local configuration in the broker node (100).

5. A method for authentication and key management of a UE, wherein the method is performed by an ASP node (20cm), wherein the ASP node (2oon) has an agreement with a broker node (100), and wherein the method comprises:receiving (S202) a request from the UE for the UE to access a service provided by the ASP node (2oon), wherein the request comprises a key identifier of a key shared between the ASP node (2oon) and the UE; forwarding (S204) the request to the broker node (100); and receiving (S206) an ASP key and an ASP specific identifier of the UE from the broker node (100).

6. The method according to claim 5, wherein the request further comprises an application layer username of the UE for the service.

7. The method according to claim 5, wherein the request further comprises an indication of an authentication procedure for the UE.

8. The method according to claim 5, wherein the method further comprises: authenticating (S208) the UE at least based on the ASP key.

9. The method according to claim 5, wherein the method further comprises: storing (S218) the ASP specific identifier of the UE with an association to a user account of the UE.

10. The method according to claim 5, wherein the method further comprises: generating (S210) a freshness parameter; and sending (S212) a response message to the UE, wherein the response message comprises the freshness parameter.

11. The method according to claim 10, wherein the method further comprises: receiving (S214) authentication credentials for a user of the UE; authenticating (S216) the user of the UE based on comparing the received authentication credentials to authentication credentials as computed by the ASP node (2oon) at least based on the freshness parameter; and sending (S220) a result of the authenticating towards the user of the UE.

12. A method for authentication and key management of a UE, wherein the method is performed by an MNO node (300m), wherein the MNO node (300m) has an agreement with a broker node (100), and wherein the method comprises: receiving (S302) a request from the broker node (100) for the UE to access a service provided by the ASP node (2oon), wherein the request comprises a key identifier, an identifier of the ASP node (2oon), and protection parameters of an ASP node (2oon); generating (S304) an ASP key based on the received request and obtaining an ASP specific identifier of the UE; and sending (S306) the ASP key and the ASP specific identifier of the UE to the broker node (100).

13. The method according to claim 12, wherein the ASP specific identifier of the UE is a random number generated by the MNO node (300m) and which by the MNO node (300m) is not used as another ASP specific identifier.

14. The method according to claim 12, wherein the ASP specific identifier of the UE is computed as a function of the identifier of the ASP node (20cm) and / or an identifier of a subscriber of the UE.

15. A broker node (100) for authentication and key management of a UE, the broker node (100) being configured to have an agreement with a set of ASP nodes(200a: 200N) and a set of MNO nodes (300a:300M), the broker node (100) comprising processing circuitry (110), the processing circuitry being configured to cause the broker node (100) to: receive a request from an ASP node (20cm) in the set of ASP nodes (200a: 200N) for the UE to access a service provided by the ASP node (20cm), wherein the request comprises a key identifier of a key shared between the ASP node (2oon) and the UE; forward the request, and an identifier of the ASP node (20cm), and protection parameters of the ASP node (20cm) to an MNO node (300m) in the set of MNOnodes (300a:300M), wherein the MNO node (300m) is selected based on the key identifier; receive an ASP key and an ASP specific identifier of the UE from the MNO node (300m); and forward the ASP key and the ASP specific identifier of the UE to the ASP node (2oon).

16. The broker node (100) according to claim 15, the processing circuitry further being configured to cause the broker node (100) to perform the method according to any of claims 2 to 4.

17. An ASP node (20cm) for authentication and key management of a UE, the ASP node (20cm) being configured to have an agreement with a broker node (100), the ASP node (20cm) comprising processing circuitry (210), the processing circuitry being configured to cause the ASP node (20cm) to: receive a request from the UE for the UE to access a service provided by the ASP node (20cm), wherein the request comprises a key identifier of a key shared between the ASP node (2oon) and the UE; forward the request to the broker node (100); and receive an ASP key and an ASP specific identifier of the UE from the broker node (100).

18. The ASP node (20cm) according to claim 17, the processing circuitry further being configured to cause the ASP node (20cm) to perform the method according to any of claims 2 to 11.

19. An MNO node (300m) for authentication and key management of a UE, the MNO node (300m) being configured to have an agreement with a broker node (100), the MNO node (300m) comprising processing circuitry (310), the processing circuitry being configured to cause the MNO node (300m) to:receive a request from the broker node (too) for the UE to access a service provided by the ASP node (2oon), wherein the request comprises a key identifier, an identifier of the ASP node (2oon), and protection parameters of an ASP node (2oon); generate an ASP key based on the received request and obtaining an ASP specific identifier of the UE; and send the ASP key and the ASP specific identifier of the UE to the broker node (100).

20. The MN0 node (300m) according to claim 19, the processing circuitry further being configured to cause the MN0 node (300m) to perform the method according to any of claims 13 to 14.

21. A computer program (1320a) for authentication and key management of a UE, the computer program comprising computer code which, when run on processing circuitry (110) of a broker node (100) configured to have an agreement with a set of ASP nodes (200a: 200N) and a set of MN0 nodes (300a:300M), causes the broker node (100) to: receive (S102) a request from an ASP node (2oon) in the set of ASP nodes (200a: 200N) for the UE to access a service provided by the ASP node (20cm), wherein the request comprises a key identifier of a key shared between the ASP node (2oon) and the UE; forward (S104) the request, and an identifier of the ASP node (20cm), and protection parameters of the ASP node (20cm) to an MN0 node (300m) in the set of MN0 nodes (300a:300M), wherein the MN0 node (300m) is selected based on the key identifier; receive (S106) an ASP key and an ASP specific identifier of the UE from the MN0 node (300m); and forward (S108) the ASP key and the ASP specific identifier of the UE to the ASP node (2oon).

22. A computer program (1320b) for authentication and key management of a UE, the computer program comprising computer code which, when run on processingcircuitry (210) of an ASP node (2oon) being configured to have an agreement with a broker node (100), causes the ASP node (2oon) to: receive (S202) a request from the UE for the UE to access a service provided by the ASP node (2oon), wherein the request comprises a key identifier of a key shared between the ASP node (2oon) and the UE; forward (S204) the request to the broker node (100); and receive (S206) an ASP key and an ASP specific identifier of the UE from the broker node (100).

23. A computer program (1320c) for authentication and key management of a UE, the computer program comprising computer code which, when run on processing circuitry (310) of an MNO node (300m) being configured to have an agreement with a broker node (100), causes the MNO node (300m) to: receive (S302) a request from the broker node (100) for the UE to access a service provided by the ASP node (20cm), wherein the request comprises a key identifier, an identifier of the ASP node (2oon), and protection parameters of an ASP node (2oon); generate (S304) an ASP key based on the received request and obtaining an ASP specific identifier of the UE; and send (S306) the ASP key and the ASP specific identifier of the UE to the broker node (100).

24. A computer program product (1310a, 1310b, 1310c) comprising a computer program (1320a, 1320b, 1320c) according to at least one of claims 21, 22, and 23, and a computer readable storage medium (1330) on which the computer program is stored.

Images