WO2021198552A1 - Autorisation améliorée dans des réseaux de communication - Google Patents

Autorisation améliorée dans des réseaux de communication Download PDF

Info

Publication number
WO2021198552A1
WO2021198552A1 PCT/FI2021/050178 FI2021050178W WO2021198552A1 WO 2021198552 A1 WO2021198552 A1 WO 2021198552A1 FI 2021050178 W FI2021050178 W FI 2021050178W WO 2021198552 A1 WO2021198552 A1 WO 2021198552A1
Authority
WO
WIPO (PCT)
Prior art keywords
network function
access token
function
information
subscribing
Prior art date
Application number
PCT/FI2021/050178
Other languages
English (en)
Inventor
Nagendra S BYKAMPADI
Narasimha Rao PULIPATI
Bruno Landais
Saurabh Khare
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of WO2021198552A1 publication Critical patent/WO2021198552A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices

Definitions

  • Various example embodiments relate in general to communication networks, such as core networks of cellular communication systems, and more specifically, to improving authorization in such networks.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform transmit, by a first network function, an access token request on behalf of a second network function to an authorization server, the access token request concerning accessing services of a third network function and comprising information related to the second network function or an application function, receive, by the first network function, an access token from the authorization server, the access token comprising information about a subscribing network function and transmit, by the first network function, a subscription request to the third network function on behalf of the second network function, the subscription request comprising said information related to the second network function or the application function and the access token comprising said information about the subscribing network function.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, further cause the apparatus to perform, receive a subscription response indicating that the subscription request has not been accepted when said information related to the second network function or the application function does not correspond to said information about the subscribing network function in the access token.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, further cause the apparatus to perform, receive a subscription response indicating that the subscription request has been accepted when said information related to the second network function or the application function corresponds to said information about the subscribing network function in the access token.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform receive, by an authorization server, an access token request from a first network function, the access token request comprising information related to a second network function or an application function and concerning accessing services of a third network function, and upon determining that the second network function is authorized to access the services of the third network function, transmit by the authorization server an access token to the first network function, the access token comprising information about a subscribing network function.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, further cause the apparatus to perform, transmit the access token response upon determining that the second network function or the application function is authorized to access the services of the third network function.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, further cause the apparatus to perform, sign, by the authorization server, the access token using a private key of the authorization server.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform receive, by a third network function, a subscription request from a first network function, the subscription request comprising information related to a second network function or an application function and an access token signed by an authorization server, the access token comprising information about a subscribing network function and depending on whether the access token is valid, transmit by the third network function a subscription response to the first network function to indicate whether the second network function or the application function is authorized to access services of the third network function or not.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, further cause the apparatus to perform, decide that the access token is not valid when said information related to the second network function or the application function does not correspond to said information about the subscribing network function and transmit the subscription response to the first network function to indicate that the subscription request has not been accepted.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, further cause the apparatus to perform, decide that the access token is valid when said information related to the second network function or the application function corresponds to said information about the subscribing network function and transmit the subscription response to the first network function to indicate that the subscription request has been accepted.
  • Example embodiments of the first, the second or the third aspect may comprise at least one feature from the following bulleted list:
  • said information related to the second network function comprises information about an identity of the second network function
  • said information about the identity of the second network function comprises an instance identity and/or a set identity of the second network function
  • the second network function is the subscribing network function originally requesting a subscription to the services of the third network function
  • said information related to the application function comprises information about an identity of the application function
  • the application function is the subscribing network function originally requesting a subscription to the services of the third network function via the second network function;
  • the second network function and the authorization server operate according to at least one standard specification defined by a 3 rd Generation Partnership Project, 3GPP;
  • the at least one standard specification is a 5G standard.
  • a method comprising transmitting, by a first network function, an access token request on behalf of a second network function to an authorization server, the access token request concerning accessing services of a third network function and comprising information related to the second network function or an application function, receiving, by the first network function, an access token from the authorization server, the access token comprising information about a subscribing network function and transmitting, by the first network function, a subscription request to the third network function on behalf of the second network function, the subscription request comprising said information related to the second network function or the application function and the access token comprising said information about the subscribing network function.
  • a method comprising, receiving, by an authorization server, an access token request from a first network function, the access token request comprising information related to a second network function or an application function and concerning accessing services of a third network function and upon determining that the second network function is authorized to access the services of the third network function, transmitting by the authorization server an access token to the first network function, the access token comprising information about a subscribing network function.
  • a method comprising receiving, by a third network function, a subscription request from a first network function, the subscription request comprising information related to a second network function or an application function and an access token signed by an authorization server, the access token comprising information about a subscribing network function and depending on whether the access token is valid, transmitting by the third network function a subscription response to the first network function to indicate whether the second network function or the application function is authorized to access services of the third network function or not.
  • an apparatus comprising means for transmitting, by a first network function, an access token request on behalf of a second network function to an authorization server, the access token request concerning accessing services of a third network function and comprising information related to the second network function or an application function, means for receiving, by the first network function, an access token from the authorization server, the access token comprising information about a subscribing network function and means for transmitting, by the first network function, a subscription request to the third network function on behalf of the second network function, the subscription request comprising said information related to the second network function or the application function and the access token comprising said information about the subscribing network function.
  • an apparatus comprising means for receiving, by an authorization server, an access token request from a first network function, the access token request comprising information related to a second network function or an application function and concerning accessing services of a third network function and means for transmitting by the authorization server, upon determining that the second network function is authorized to access the services of the third network function, an access token to the first network function, the access token comprising information about a subscribing network function.
  • an apparatus comprising means for receiving, by a third network function, a subscription request from a first network function, the subscription request comprising information related to a second network function or an application function and an access token signed by an authorization server, the access token comprising information about a subscribing network function and means for transmitting by the third network function, depending on whether the access token is valid, a subscription response to the first network function to indicate whether the second network function or the application function is authorized to access services of the third network function or not.
  • non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the fourth aspect.
  • non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the fifth aspect.
  • non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the sixth aspect.
  • a computer program configured to perform the method of the fourth aspect.
  • a computer program configured to perform the method of the fifth aspect.
  • a computer program configured to perform the method of the sixth aspect.
  • FIGURE 1 illustrates an exemplary system in accordance with at least some example embodiments
  • FIGURE 2 illustrates a first signalling example in accordance with at least some example embodiments
  • FIGURE 3 illustrates a second signalling example in accordance with at least some example embodiments
  • FIGURE 4 illustrates an example apparatus capable of supporting at least some example embodiments
  • FIGURE 5 illustrates a flow graph of a first method in accordance with at least some example embodiments
  • FIGURE 6 illustrates a flow graph of a second method in accordance with at least some example embodiments
  • FIGURE 7 illustrates a flow graph of a third method in accordance with at least some example embodiments.
  • a first Network Function, NF may transmit an access token request on behalf of a second NF to an authorization server, to request access to services of a third NF.
  • the access token request may comprise information related to the second NF or an Application Function, AF, such as information about an identity of the second NF or the AF.
  • the authorization server may check whether the second NF or the AF is authorized to access the services of the third NF and if so, respond to the first NF by transmitting an access token comprising information about a subscribing NF, such as the second NF or the AF.
  • the first NF may then transmit a subscription request to the third NF on behalf of the second NF, the subscription request also comprising said information related to the second NF or the AF and the access token, wherein the access token comprises said information about the subscribing NF.
  • the third NF may validate the access token received from the first NF in the subscription request when said information related to the second NF or the AF corresponds to said information about the subscribing NF, and respond by transmitting a subscription response, the subscription response indicating that the second NF or the AF is authorized to access the services of the third NF.
  • authorization of delegated subscription requests is enabled.
  • FIGURE 1 illustrates an exemplary system in accordance with at least some example embodiments of the present invention.
  • the exemplary system of FIGURE 1 comprises two Public Land Mobile Networks, PLMNs, 110 and 112, each equipped with at least one NF, 120 and 122, respectively.
  • AnNF may refer to an operational and/or a physical entity.
  • An NF may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as Virtual Network Elements, VNFs.
  • At least some example embodiments of the present invention may be applied in containerized deployments as well.
  • One physical node may be configured to perform plural NFs. Examples of such NFs include a (radio) access or resource control or management function, session management or control function, interworking, data management or storage function, authentication function or a combination of one or more of these functions.
  • NFs may comprise at least some of an Access and Mobility Function, AMF, a Session Management Function, SMF, a Network Slice Selection Function, NSSF, a Network Exposure Function, NEF, a Network Repository Function, NRF, an Unified Data Management, UDM, an User Data Repository, UDR, an Unstructured Data Storage Function, UDSF, an Authentication Server Function, AUSF, a Policy Control Function, PCF, an AF, Operations Administration and Maintenance, OAM, and Network Data Analysis Function, NWDAF.
  • the PLMNs 110 and 112 may further comprise a Security Edge Protection Proxy, SEPP, 130 and 132, respectively.
  • SEPPs 130 and 132 may be configured to operate as a security edge node or gateway.
  • the NFs may communicate with each other using representational state transfer Application Programming Interfaces, APIs. These may be known as Restful APIs.
  • An inter-PLMN interconnection allows secure communication between a service-consuming NF and a service-producing NF, referred to as a NFc 120 and a NFp 122 in FIGURE 1, respectively.
  • a Service Communication Proxy, SCP, 150 may be deployed for indirect communication between network functions.
  • the SCP 150 may be an intermediate function/element for assisting in routing of messages, such as control plane messages like Diameter Routing Agent, DRA, messages between NFs.
  • NF discovery and NF service discovery enable core network entities, such as the NFc 140 or the SCP 150, to discover a set of NF instance(s) andNF service instance(s) for a specific NF service or an NF type.
  • the NRF is a function that is used to support the functionality of NFs and NF service discovery and status notification.
  • the NRF may maintain an NF profile of available NF instances and their supported services.
  • the NRF may notify about newly registered, updated, or deregistered NF instances along with its NF services to a subscribed NFc 120 or SCPc 150.
  • the NF and NF service discovery may be implemented via the NRF.
  • the NRF may be a logical function.
  • the NRF may also support status notification.
  • An NRF may be co-located together with an SCP.
  • the NFc 120 or the SCPc 150 may initiate, based on local configuration, a discovery procedure with the NRF 140c.
  • the discovery procedure may be initiated by providing the type of the NF and optionally a list of the specific service(s) it is attempting to discover.
  • the NFc 120 or the SCPc 150 may also provide other service parameters, such as slicing related information.
  • the entities or nodes 120, 122, 130, 132, 140, 142, 150, 152 may act in both service-consuming and service-providing roles and that their structure may also be similar or identical, even though their role in the example of FIGURE 1 in delivery of a particular message is identified by use of the prefix “c” or “p” indicating whether they are acting for the service-consuming or service-producing NF. It is to be noted that instead of “c” and “p”, “v” for visited and “h” for home may be used to refer to at least some respective entities in the visited and home PLMNs.
  • OAuth based authorization and token exchange may be applied between the mobile networks.
  • the NFc 120 may be an OAuth client and the NRFp 142 may operate as OAuth resource server, and both may be configured to support OAuth authorization framework as defined in RFC 6749.
  • a first NF such as NFc 120 in FIGURE 1
  • a subscription request (e.g., an UDM subscription request) on behalf of a second NF
  • the subscription request concerning accessing services of a third NF, such as NFp 122 in FIGURE 1.
  • an authorization server such as an NRF
  • the authorization server is aware that the first NF wants to subscribe on behalf of the second NF and if the authorization server authorizes the subscription request, it also authorizes access to services of the third NF by the second NF, e.g., notifications from the third NF to the second NF.
  • Embodiments of the present invention therefore enable authorization of delegated subscriptions by making it possible for the authorization server to decide whether to authorize the subscription request, or not, for the second NF, i.e., the original subscribing NF. Without authorization of the authorization server the second NF will not be able to access the services of the third NF. Consequently, security gaps for subscribe/notify scenarios with delegated discovery may be avoided.
  • the original subscribing NF may be authorized properly and given access rights to the requested services. Security gaps may be avoided similarly if the subscribing NF is the AF.
  • an access token API and access token claims may be enhanced for delegated subscriptions, wherein for example the first NF may create a subscription at a third NF on behalf of the second NF or the AF, i.e., the NF originally requesting the subscription, if authorized by the authorization server.
  • the authorization server may control authorization of the second NF or the AF such that the second NF or the AF can access the services of the third NF, e.g., obtain notifications from the third NF, only if the second NF or the AF has been authorized.
  • the first NF which needs to issue a subscription request to the third NF on behalf of the second NF, may add information related to the second NF or the AF to an access token request concerning accessing services of the third NF.
  • the first NF may transmit the access token request to the authorization server, such as the NRF.
  • the first NF may therefore indicate the original subscribing NF, i.e., the second NF or the AF, in the access token request.
  • the authorization server may then determine whether the second NF or the AF is authorized to access the services of the third NF, for example to obtain notifications from the third NF.
  • the authorization server may respond to the first NF by transmitting an access token signed by the authorization server, the access token comprising information about the subscribing NF.
  • the first NF may then transmit a subscription request to the third NF on behalf of the second NF, the subscription request comprising said information related to the second NF or the AF and the access token comprising said information about the subscribing NF.
  • the third NF may validate the access token and transmit a subscription response to the first NF, the subscription response indicating that the second NF or the AF is authorized to access services of the third NF.
  • FIGURE 2 illustrates a first signalling example in accordance with at least some example embodiments.
  • first NF 202 On the vertical axes are disposed, from the left to the right, first NF 202, second NF 204, third NF 206 and authentication server 208. Time advances from the top towards the bottom.
  • FIGURE 2 illustrates an example, wherein first NF 202 may perform delegated subscription on behalf of second NF 204 for services of third NF 206.
  • first NF 202 may be an UDM
  • second NF 204 may be an NEF
  • third NF 206 may be an AMF
  • authorization server 208 may be an NRF.
  • second NF 204 may determine that it would like to transmit a subscription request to first NF 202. Therefore, at step 210, second NF 204 may transmit an access token request concerning accessing services of first NF 202 to authorization server 208. Authorization server 208 may then authorize second NF 204 to send a subscription request towards first NF 202, to access the services of first NF 202, by transmitting an access token response to second NF 204.
  • the access token response may comprise an access token signed by authorization server 208.
  • second NF 204 may transmit at step 220 a subscription request concerning accessing services of first NF 202 towards first NF 202, e.g., with an authorization header carrying the access token.
  • First NF 202 may then create a subscription for second NF 204 and respond to second NF 204 accordingly.
  • the subscription request transmitted by second NF 204 may comprise information related to second NF 204, such as information about an identity of second NF 204.
  • Said information related to the identity of second NF 204 may be an instance identity (instancelD) and/or a set identity (setID) of second NF 204.
  • first NF 202 may derive said information related to second NF 204 during a Transport Layer Security, TLS, handshake (TLS authentication).
  • First NF 202 may also determine that it needs, or wants, to create a subscription at a new NFp, such as third NF 206, on behalf of second NF 204. That is to say, first NF 202 may determine that there is a need to perform delegated subscription on behalf of second NF 204. Upon determining that there is a need to create a subscription at third NF 206 on behalf of second NF 204, first NF 202 should forward the subscription request received from second NF 204 to third NF 206, e.g., with the notification callback URI that points to second NF 204. First NF 202 would also need to add an access token to the subscription request, which is to be transmitted to third NF 206.
  • a new NFp such as third NF 206
  • first NF 202 may transmit an access token request to authorization server 208, to request the access token for accessing services of third NF 206.
  • First NF 202 may add information related to second NF 204, such as information about the identity of second NF 204, to the access token request.
  • Said information related to second NF 204 may thus indicate the original subscribing NF, i.e., second NF 204, towards which third NF 206 would be authorized to provide services, for example to send notifications.
  • Rest of the parameters used in the access token request may be defined in 3 GPP standard specification TS 29.510, section 6.3.5.2.4.
  • the access token request such as Nnrf AccessToken API
  • grant type client credentials
  • SubscribingNFInfo NF2 (instance Id/Setld.. received in subscription request or derived by other means)
  • targetNfType NF3
  • targetNfhistanceId NF3.
  • Other parameters may be added depending on a use case.
  • authorization server 208 may authorize first NF 202 to transmit a subscription request to third NF 206 and third NF 206 to provide services to first NF 202, .e.g., third NF 206 may be allowed to send notifications towards first NF 202.
  • authorization server 208 may authorize first NF 202 to transmit a subscription request to third NF 206 on behalf of second NF 204, e.g., second NF 204 may be allowed to receive notifications from third NF 206 and third NF 206 to provide services to second NF 204, .e.g., third NF 206 may be allowed to send notifications towards second NF 202.
  • Authorization server 208 may, upon determining that first NF 202 and second NF 204 are authorized to access the services of third NF 206, generate a digitally signed access token. Authorization server 208 may also include information about a subscribing NF, such as second NF 204 if it is the original NF requesting the subscription to services of third NF 206, as a new claim in the access token. Authorization server 208 may then transmit the signed access token comprising said information about the subscribing NF to first NF 202. However, if first NF 202 or second NF 204 is not allowed to subscribe to services provided by third NF 206, authorization server 208 may reject the access token request.
  • a subscribing NF such as second NF 204 if it is the original NF requesting the subscription to services of third NF 206, as a new claim in the access token.
  • Authorization server 208 may then transmit the signed access token comprising said information about the subscribing NF to first
  • first NF 202 may transmit a subscription request to third NF 206 on behalf of second NF 204.
  • the subscription request may comprise the access token signed by authorization server 208, wherein the access token may comprise said information about the subscribing NF, and the subscription request may comprise said information related to second NF 204, such as information about an identity of second NF 204 (e.g., instance identity or set identity of second NF 204, possibly received from second NF 204).
  • Third NF 206 such as NFp, may then check whether said information related to second NF 204 corresponds to said information about the subscribing NF in the access token. That is to say, third NF 206 may determine whether the access token is valid and transmit a subscription response to first NF 202 to indicate whether second NF 204 is authorized to access services of third NF 206, or not.
  • third NF 206 may decide that the access token is valid and accept the subscription request, and transmit a subscription response to first NF 202 to indicate that second NF 204 is authorized to access services of third NF 206, i.e., the subscription has been accepted.
  • Third NF 206 may also store the callback URI information of second NF 204, which can be used later for transmitting notifications to second NF 204.
  • third NF 206 may decide that the access token is not valid and reject the subscription request, and transmit a subscription response to first NF 202 to indicate that second NF 204 is not authorized to access services of third NF 206, i.e., the subscription request has not been accepted.
  • FIGURE 3 illustrates a second signalling example in accordance with at least some example embodiments.
  • FIGURE 3 also illustrates an example, wherein first NF 302 may perform delegated subscription on behalf of second NF 304.
  • first NF 302 may be a first NFc
  • second NF 304 may be a second NFc
  • third NF 306 may be an NFp
  • authorization server 308 may be an hNRF.
  • first NF 302 may receive a subscription request from second NF 304.
  • the subscription request may comprise at least information related to second NF 304, such as information about an identity of second NF 304, and an access token.
  • first NF 302 may authorize the subscription request by validating the access token and decide to forward the subscription request to third NF 306.
  • the subscription request received from second NF 304 may comprise for example at least the following information: NF2 instance/set ID, NF2 callbackURI, access token 1.
  • first NF 302 may transmit an access token request to authorization server 308, such as an OAuth server like an NRF, to obtain a new access token to access services of third NF 306. That is to say, the access token request may be related to accessing services of third NF 306.
  • the access token request may comprise said information related to second NF 304, such as information about an identity of second NF 304 (e.g., a new parameter called Subscribing NF Info may comprise NF Instance ID or NF Set ID of second NF 304 (obtained at step 310)). That is to say, said information related to second NF 304 may be information about a subscribing NF.
  • authorization server 308 may check if first NF 302 can be authorized to delegate a subscription request to third NF 306 and second NF 304 can be authorized to access services of third NF 306, e.g., to obtain notifications from third NF 306. If said authorization checks are successful, authorization server 308 may create a digitally signed access token with said information about the subscribing NF, such as said information related to second NF 304 (e.g., with one additional claim called SubscribingNFInfo that identifies second NF 304).
  • authorization server 308 may check if first NF 302 can be authorized to delegate a subscription request to third NF 306 and second NF 304 can be authorized to access services of third NF 306 by configurations in NF profiles, which may be maintained by authorization server 308, such as an NRF. For instance, if the requested service is related to obtaining notifications, third NF 306 may maintain, at authorization server 308, its profile information of NF types that can receive notifications from it. Similarly, information about delegated subscription may be configured in the NF profile of second NF 304 or in the profile of first NF 302.
  • authorization server 308 may, at step 330, transmit the access token comprising said information about the subscribing NF to first NF 302.
  • first NF 302 may forward the subscription request comprising said information related to second NF 304 and the access token received at step 330 to third NF 306, wherein the access token is signed by authorization server 308 and comprises said information about the subscribing NF.
  • Said information related to second NF 304 may comprise information about an identity of second NF 304, such as a NF instance ID or NF set ID of second NF 304.
  • the subscription request may comprise a callback URI as well.
  • the NF Set ID may be defined as in clause
  • the NF instance ID may uniquely identify an NF instance.
  • the format of the NF instance ID may be a Universally Unique Identifier, UUID, version 4, as described in IETF RFC 4122.
  • Third NF 306 may then validate the received access token, e.g., by checking that second NF 304 is authorized to access services of third NF 306, for example to receive notifications from third NF 306. Third NF may check that second NF 304 is authorized to access services of third NF 306 by comparing said information related to second NF 304 received in the subscription request to said information about the subscribing NF in the access token. [0067] If said information related to second NF 304 received in the subscription request corresponds to said information about the subscribing NF in the access token, third NF 306 may determine that second NF 304 is authorized to access services of third NF 306 and decide that the access token is valid.
  • Third NF 306 may also transmit at step 350 a subscription response to first NF 302, the subscription response indicating that the subscription request has been accepted when said information related to the second NF 304 corresponds to said information about the subscribing NF.
  • third NF 306 may store the callback URI needed later, e.g., for transmitting a notification message to second NF 304.
  • third NF 306 may for example transmit a notification to second NF 304 upon detecting that a required event has happened, if second NF 304 was authorized to access services of third NF 306. Said notification may be transmitted using the stored callback URI of second NF 304 for example.
  • Some example embodiments of the present invention may be applied for example in 3GPP standard specification TS 29.510, Section 6.3.5.2.4 “Type: AccessTokenClaims”, Table 6.3.5.2.4-1: “Definition of type AccessTokenClaims” by adding at least some of the following information:
  • This IE may be included if the NF requesting the access token, is delegating the subscribe request to the NF identified by the “aud” claim on behalf of another NF identified by this claim; and/or
  • This IE may be included if the NF requesting the access token, is delegating the subscribe request to the NF identified by the “aud” claim, on behalf of a set of NFs identified by this claim.
  • This IE may be included if the NF requesting the access token, is delegating the subscribe request to the NF identified by the “aud” claim, on behalf of another NF of NF type identified by this claim.
  • This IE may be included if the NF requesting the access token, is delegating the subscribe request to the NF identified by the “aud” claim, on behalf of another NF for a request issued by an AF (Application Function) identified by this claim.
  • an access token may be requested by first NF
  • the NF type of second NF 304 may be signalled from second NF 304 to first NF 302 in the subscription request.
  • an access token may be requested by first NF 302 for a delegated subscription on behalf of another NF based upon an identity of an AF.
  • the identity of the AF may be signalled from second NF 304 to first NF 302 in the subscription request.
  • the AF may be the subscribing NF and embodiments of the present disclosure may be applied similarly as if second NF 304 would be the subscribing NF.
  • the AF may issue a subscription request to second NF 304, such as an NEF.
  • Second NF 304 may then issue a subscription request to first NF 302, such as an UDM and first NF 302 may transmit an access token request on behalf of second NF 304 to authorization server 308, the access token request comprising information related to the AF, such as an identity of the AF.
  • First NF 302 may then delegate the subscription request to third NF, such as an AMF, upon receiving the access token comprising said information about the subscribing NF from authorization server 308, when the subscribing NF is the AF.
  • Authorization server 308 can thus also grant authorization based on the identity of the AF.
  • FIGURE 4 illustrates an example apparatus capable of supporting at least some example embodiments.
  • device 400 which may comprise, for example, an NFc, NFp or authorization server, or a device controlling functioning thereof.
  • processor 410 which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core.
  • Processor 410 may comprise, in general, a control device.
  • Processor 410 may comprise more than one processor.
  • Processor 410 may be a control device.
  • Processor 410 may comprise at least one Application-Specific Integrated Circuit, ASIC.
  • Processor 410 may comprise at least one Field-Programmable Gate Array, FPGA.
  • Processor 410 may comprise an Intel Xeon processor for example. Processor 410 may be means for performing method steps in device 400, such as determining, causing transmitting and causing receiving. Processor 410 may be configured, at least in part by computer instructions, to perform actions.
  • a processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein.
  • circuitry may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a network function, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • firmware firmware
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • Device 400 may comprise memory 420.
  • Memory 420 may comprise random- access memory and/or permanent memory.
  • Memory 420 may comprise at least one RAM chip.
  • Memory 420 may comprise solid-state, magnetic, optical and/or holographic memory, for example.
  • Memory 420 may be at least in part accessible to processor 410.
  • Memory 420 may be at least in part comprised in processor 410.
  • Memory 420 may be means for storing information.
  • Memory 420 may comprise computer instructions that processor 410 is configured to execute. When computer instructions configured to cause processor 410 to perform certain actions are stored in memory 420, and device 400 overall is configured to run under the direction of processor 410 using computer instructions from memory 420, processor 410 and/or its at least one processing core may be considered to be configured to perform said certain actions.
  • Memory 420 may be at least in part comprised in processor 410.
  • Memory 420 may be at least in part external to device 400 but accessible to device 400.
  • Device 400 may comprise a transmitter 430.
  • Device 400 may comprise a receiver 440.
  • Transmitter 430 and receiver 440 may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP.
  • Transmitter 430 may comprise more than one transmitter.
  • Receiver 440 may comprise more than one receiver.
  • Transmitter 430 and/or receiver 440 may be configured to operate in accordance with a suitable communication standard.
  • Device 400 may comprise User Interface, UI, 450.
  • UI 450 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 400 to vibrate, a speaker and a microphone.
  • a user may be able to operate device 400 via UI 450, for example to configure device 400 and/or functions it runs.
  • Processor 410 may be furnished with a transmitter arranged to output information from processor 410, via electrical leads internal to device 400, to other devices comprised in device 400.
  • a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 420 for storage therein.
  • the transmitter may comprise a parallel bus transmitter.
  • processor 410 may comprise a receiver arranged to receive information in processor 410, via electrical leads internal to device 400, from other devices comprised in device 400.
  • Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 440 for processing in processor 410.
  • the receiver may comprise a parallel bus receiver.
  • Device 400 may comprise further devices not illustrated in FIGURE 4. In some example embodiments, device 400 lacks at least one device described above. For example, device 400 may not have UI 450.
  • Processor 410, memory 420, transmitter 430, receiver 440 and/or UI 450 may be interconnected by electrical leads internal to device 400 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to device 400, to allow for the devices to exchange information.
  • this is only one example and depending on the example embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.
  • FIGURE 5 is a flow graph of a first method in accordance with at least some example embodiments.
  • the phases of the illustrated first method may be performed by a first NF, such as a NFc, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • a first NF such as a NFc
  • a control device configured to control the functioning thereof, possibly when installed therein.
  • the first method may comprise, at step 510, transmitting, by a first NF, an access token request on behalf of a second NF to an authorization server, the access token request concerning accessing services of a third NF and comprising information related to the second NF or an AF. Also, the first method may comprise, at step 520, receiving, by the first NF, an access token from the authorization server, the access token comprising information about a subscribing NF. Finally, the first method may comprise, at step 530, transmitting, by the first NF, a subscription request to the third NF on behalf of the second NF, the subscription request comprising said information related to the second NF or the AF and the access token comprising said information about the subscribing NF.
  • FIGURE 6 is a flow graph of a second method in accordance with at least some example embodiments.
  • the phases of the illustrated second method may be performed by an authorization server, such as an NRF, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the second method may comprise, at step 610, receiving, by an authorization server, an access token request from a first NF, the access token request comprising information related to a second NF or an AF and concerning accessing services of a third NF.
  • the second method may also comprise, at step 620, transmitting by the authorization server an access token comprising information about a subscribing NF upon determining that the second NF is authorized to access the services of the third NF.
  • FIGURE 7 is a flow graph of a third method in accordance with at least some example embodiments.
  • the phases of the illustrated third method may be performed by a third NF, such as a NFp or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the third method may comprise, at step 710, receiving, by a third NF, a subscription request from a first NF, the subscription request comprising information related to a second NF or an AF and an access token signed by an authorization server, the access token comprising information about a subscribing NF.
  • the third method may also comprise, at step 720, depending on whether the access token is valid, transmitting by the third NF a subscription response to the first NF to indicate whether the second NF or the AF is authorized to access services of the third NF or not.
  • an apparatus such as, for example, an NFc, NFp or authorization server, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.
  • a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof.
  • a computer program product embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.
  • an apparatus such as, for example, an NFc, NFp or authorization server, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.
  • At least some example embodiments find industrial application at least in 5G core networks, wherein it is desirable to authorize subscription requests, and possibly in other core networks in the future as well.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Selon un aspect donné à titre d'exemple, la présente invention concerne un procédé comprenant la transmission, par une première fonction de réseau, d'une demande de jeton d'accès pour le compte d'une deuxième fonction de réseau à un serveur d'autorisation, la demande de jeton d'accès concernant des services d'accès d'une troisième fonction de réseau et comprenant des informations relatives à la deuxième fonction de réseau ou à une fonction d'application, la réception, par la première fonction de réseau, d'un jeton d'accès provenant du serveur d'autorisation, le jeton d'accès comprenant des informations concernant une fonction de réseau d'abonnement, et la transmission, par la première fonction de réseau, d'une demande d'abonnement à la troisième fonction de réseau pour le compte de la deuxième fonction de réseau, la demande d'abonnement comprenant lesdites informations relatives à la deuxième fonction de réseau ou à la fonction d'application et le jeton d'accès comprenant lesdites informations concernant la fonction de réseau d'abonnement.
PCT/FI2021/050178 2020-04-02 2021-03-11 Autorisation améliorée dans des réseaux de communication WO2021198552A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041014737 2020-04-02
IN202041014737 2020-04-02

Publications (1)

Publication Number Publication Date
WO2021198552A1 true WO2021198552A1 (fr) 2021-10-07

Family

ID=77926994

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2021/050178 WO2021198552A1 (fr) 2020-04-02 2021-03-11 Autorisation améliorée dans des réseaux de communication

Country Status (1)

Country Link
WO (1) WO2021198552A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024145948A1 (fr) * 2023-01-06 2024-07-11 北京小米移动软件有限公司 Procédés et appareils d'autorisation, dispositif de communication et support de stockage

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019198054A1 (fr) * 2018-04-14 2019-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Points d'extrémité d'authentification de réseau central 5g sur la base de service
WO2019196813A1 (fr) * 2018-04-09 2019-10-17 华为技术有限公司 Procédé et dispositif d'abonnement à un service

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019196813A1 (fr) * 2018-04-09 2019-10-17 华为技术有限公司 Procédé et dispositif d'abonnement à un service
WO2019198054A1 (fr) * 2018-04-14 2019-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Points d'extrémité d'authentification de réseau central 5g sur la base de service

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 16)", 3GPP DRAFT; 33501-G20, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. 20200301, 26 March 2020 (2020-03-26), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051867685 *
3GPP: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Aspects; Study on security aspects of the 5G Service Based Architecture (SBA) (Release 16)", 3GPP TR 33.855 V1.9.0 (2019-11), 1 November 2019 (2019-11-01), pages 1 - 108, XP055926237, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/33_series/33.855/33855-190.zip> [retrieved on 20220531] *
HUAWEI, HISILICON: "Update on solution#15 in TR 33.855", 3GPP DRAFT; S3-194509, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Reno (US); 20191118 - 20191122, 22 November 2019 (2019-11-22), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051828661 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024145948A1 (fr) * 2023-01-06 2024-07-11 北京小米移动软件有限公司 Procédés et appareils d'autorisation, dispositif de communication et support de stockage

Similar Documents

Publication Publication Date Title
US12063312B2 (en) Security procedure for cryptographic signature verification based on a trust relationship between edge nodes connecting home and visited networks
US11844014B2 (en) Service authorization for indirect communication in a communication system
US11737011B2 (en) Management of access tokens in communication networks
US20190380030A1 (en) Systems, devices, and techniques for registering user equipment (ue) in wireless networks using a native blockchain platform
US11425636B1 (en) Network function service subscription control
US20220191028A1 (en) Authorization of network request
US20220224589A1 (en) Network function request error handling
US20210120416A1 (en) Secure inter-mobile network communication
EP3886390A1 (fr) Gestion de jeton
US12034733B2 (en) Authorization in communication networks
WO2021140272A1 (fr) Vérification de jetons d&#39;accès avec des fonctions de référentiel de réseau dans des réseaux centraux
CN116113936A (zh) 针对启用区块链的无线系统中的交易管理的方法、架构、装置和系统
WO2021176131A1 (fr) Autorisation améliorée dans des réseaux de communication
WO2021165194A1 (fr) Gestion de clé
WO2021165925A1 (fr) Gestion de clé
WO2021198552A1 (fr) Autorisation améliorée dans des réseaux de communication
US20230030315A1 (en) Network Security
WO2023045472A1 (fr) Procédé, appareil et système de communication
EP3852339B1 (fr) Activation de la qualité de service pour les fonctions de réseau de tiers fiables dans des réseaux principaux
WO2021240055A1 (fr) Autorisation améliorée dans des réseaux de communication
WO2021224544A1 (fr) Enregistrement dans des réseaux de communication
EP4181465A1 (fr) Sécurité de réseau
EP4092982A1 (fr) Authentification d&#39;une demande de réseau
US20220217127A1 (en) Authentication of network request
EP4451715A1 (fr) Procédé et appareil de communication

Legal Events

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

Ref document number: 21782015

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21782015

Country of ref document: EP

Kind code of ref document: A1