WO2021099675A1 - Gestion de sécurité de service de réseau mobile - Google Patents

Gestion de sécurité de service de réseau mobile Download PDF

Info

Publication number
WO2021099675A1
WO2021099675A1 PCT/FI2020/050687 FI2020050687W WO2021099675A1 WO 2021099675 A1 WO2021099675 A1 WO 2021099675A1 FI 2020050687 W FI2020050687 W FI 2020050687W WO 2021099675 A1 WO2021099675 A1 WO 2021099675A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
network
proxy
token
network entity
Prior art date
Application number
PCT/FI2020/050687
Other languages
English (en)
Inventor
Nagendra Shridhar BYKAMPADI
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 WO2021099675A1 publication Critical patent/WO2021099675A1/fr

Links

Classifications

    • 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/44—Program or device authentication
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • 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

Definitions

  • the present invention relates to mobile network communications security, and in particular authorization for mobile network service access.
  • Network elements or functions located in Public Land Mobile Networks communicate to provide services for roaming and non-roaming mobile devices.
  • Security management is an important consideration in any mobile network. For example, authorization of access to services is one example of security management. Security of the messages needs to be ensured for various service scenarios.
  • Network function service logic may need to perform authorization of a service request from a network function which may be in another PLMN. There may be various actors in interconnection network trying to track users, listen to traffic, etc.
  • Specific edge security network entities such as security proxies, may be arranged at the perimeter of a PLMN network to protect the PLMN from outside messages (inbound) and provide additional security services for the inter-PLMN communication between the network elements or functions at the different PLMNs.
  • Web- based communication such as Hypertext Transfer Protocol Secure (HTTP(S)), may be applied between network entities.
  • HTTP(S) Hypertext Transfer Protocol Secure
  • Next generation or fifth generation (5G) systems are structured to support IoT usage scenarios.
  • 5G networks apply a service-based architecture and introduce new types of intermediate nodes, presenting further challenges for security management.
  • a method comprising: receiving, from a proxy entity configured to operate on behalf of a service-consuming first network entity, an access request for a service-providing second network entity, the access request comprising a security token comprising information for controlling access for the first network entity for a service-providing second network entity and indicating at least one proxy entity allowed to act on behalf of the first network entity, authorizing access for the first network entity to the second network entity on the basis of the security token, verifying authority of the proxy entity to act on behalf of the first network entity on the basis of the security token, and on the basis of the authorizing the first network entity and the verifying the authority of the proxy entity, transmitting a response message to the proxy entity.
  • a method comprising: receiving a registration request from a service-consuming first network entity, the registration request being indicative of at least one proxy entity allowed to act on behalf of the first network entity, generating, in response to the registration request and authentication of the first network entity, a security token comprising information for controlling access for the first network entity for a service-providing second network entity and indicating the at least one proxy entity allowed to act on behalf of the first network entity, and transmitting, to the first network entity, the security token for requesting access to the second network entity via the proxy entity.
  • a method comprising: transmitting a registration request to an authorization entity, the registration request being indicative of at least one proxy entity allowed to act on behalf of the first network entity, receiving a security token comprising information for controlling access for the first network entity for a service-providing second network entity and indicating the at least one proxy entity allowed to act on behalf of the first network entity, and transmitting the security token to the proxy entity for accessing the service-providing second network entity via the at least one proxy entity.
  • an apparatus comprising at least one processor, 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 processor, cause the apparatus at least to perform the method of the first aspect, the second aspect, or the third aspect, or an embodiment thereof.
  • a computer program product a computer readable medium, or a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method according to any one of the above aspects or an embodiment thereof.
  • FIGURE 1 illustrates an example system capable of supporting at least some embodiments
  • FIGURE 2 illustrates an intra-PFMN example capable of supporting at least some embodiments
  • FIGURES 3 to 5 illustrate methods in accordance with at least some embodiments
  • FIGURE 6 is a signalling example in accordance with some embodiments.
  • FIGURE 7 illustrates an apparatus in accordance with at least some embodiments.
  • FIGURE 1 illustrates a system 100 of an example embodiment, with references .
  • the system comprises two PLMNs 110, 112 equipped with a Network Function (NF) 120, 122.
  • a network function may refer to an operational and/or physical entity.
  • the network function 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. Examples of such network functions 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.
  • 3GPP Third Generation Partnership Project
  • core network 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), Unified Data Management (UDM), Authentication Server Function (AUSF), Policy Control Function (PCF), and Application Function (AF).
  • AMF Access and Mobility Function
  • SMF Session Management Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NRF Network Repository Function
  • UDM Unified Data Management
  • AUSF Authentication Server Function
  • PCF Policy Control Function
  • AF Application Function
  • SEPP Security Edge Protection Proxy
  • the NFs communicate with each other using representational state transfer application programming interfaces (Restful APIs).
  • the SEPP 130, 132 is a network node at the boundary of an operator's network that receives a message, such as an HTTP request or HTTP response from the NF, applies protection for sending, and forwards the reformatted message through a chain of intermediate nodes, such as IP exchanges (IPX) towards a receiving SEPP.
  • IPX IP exchanges
  • the receiving SEPP receives a message sent by the sending SEPP and forwards the message towards an NF within its operator’s network, e.g. the AUSF.
  • the message can alternatively be sent towards another network function of the second network.
  • the two SEPPs 130, 132 may also communicate with each other, e.g., regarding their mutual connections.
  • the SEPP 130, 132 may be configured to act as a non-transparent proxy node.
  • the SEPP may be configured to protect application layer control plane messages between the NFs 120, 122 belonging to the different PLMNs and use the N32 interface to communicate with each other.
  • An inter-PLMN interconnect allows secure communication between a service-consuming NF e.g. in a visited PLMN (VPLMN) and a service-producing NF e.g. in a home PLMN (HPLMN), henceforth referred to as NFc 120 and NFp 122 (may also be referred to as NF service consumer and NF service producer, respectively).
  • Security is enabled by the SEPPs 130, 132 of both networks, which may be referred to as SEPP consumer SEPPc and SEPP producer SEPPp, respectively.
  • transport layer security may be used between the SEPPs.
  • application layer security on the N32 interface between SEPPs may be applied for protection between the SEPPp and the SEPPc, referred also to as PRotocol for N32 INterconnect Security (PRINS).
  • PRINS N32 INterconnect Security
  • An N32-c connection is a TLS based connection for N32 interface management and may be established between the SEPPp and the SEPPc for security capability negotiation by N32 handshake procedure and exchange of protected HTTP messages.
  • a Service Communication Proxy SCP may be deployed for indirect communication between network functions.
  • An SCP is an intermediate function/element to assist in routing messages (e.g., control plane messages such as Diameter Routing Agent (DRA) messages) between NFs.
  • An SCP 150, 152 may be deployed in VPLMN and/or in home HPLMN. The SCP does not expose services itself.
  • An SCP acting on behalf of an NFc may be referred to as SCPc 150 and an SCP acting on behalf of an NFp may be referred to as SCPp 152.
  • Direct communication may be applied between NFc 120 and NFp 122 for an NF service, or NF service communication may be performed indirectly via SCP(s) 150, 152.
  • the NFc 120 performs discovery of the target NFp 122 by local configuration or via local NRF, NRFc 140.
  • the NFc 120 may delegate the discovery of the target NFp 122 to the SCPp 150 used for indirect communication.
  • the SCPp uses the parameters provided by NFc 120 to perform discovery and/or selection of the target NF Service producer.
  • the SCPp address may be locally configured in NFc 120.
  • NF discovery and NF service discovery enable core network entities (NFc or SCP) to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type.
  • Network Repository Function is a function that is used to support the functionality of NF and NF service discovery and status notification.
  • the NRF maintains 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 or SCPc.
  • the NFc 120 or SCPc 150 may initiate, based on local configuration, a discovery procedure with the NRFc 140.
  • 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 SCPc 150 may also provide other service parameters, such as slicing related information.
  • the SCPc 150 may request service discovery from a NRF in its PLMN 110, i.e. the NRFc 140.
  • the NRFc may send a discovery request to an NRF, referred herein as NRFp 142, in another PLMN 112, e.g. the home PLMN.
  • the NRFp 142 in the other network 112 may respond with a discovery response which may be forwarded to the SCPc via the NRFc 140 in the PLMN 110 of the NFc.
  • the SCPc may trigger service requests for the NFp via the SEPPc 130 and the SEPPp 132.
  • At least some of the entities such as the NFs 120, 122 and NRFs 140, 142 may be configured to support TLS, both server-side and client-side certificates.
  • the NFc 120 communicates via the SCPc 150, which may act like a HTTPS proxy and does not break the tunnel.
  • 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, while their role in the present examples 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 can be used to refer to at least some respective entities in the visited and home PLMNs.
  • an NRF in the PLMN may be operatively coupled to SCPc acting as a proxy for one or more NF service consumers NFcs and to a SCPp acting as a proxy for one or more NFps.
  • OAuth based authorization and token exchange is applied between the mobile networks.
  • the second network entity such as the NRFp
  • the NFc may be an OAuth client and the NFp may operate as OAuth resource server, and they may be configured to support OAuth authorization framework as defined in RFC 6749.
  • FIGURE 2 illustrates a hierarchy with OAuth protocol roles for Release 16 (Rel-16) of 3GPP specification TS 23.501 (Option or Model D) as an example, alternative embodiments apply to other forms of service authorization.
  • the OAuth protocol roles may be performed as follows: NRF is the OAuth authorization server (Auth Server).
  • SCPc SCP on the consumer side
  • SCPp SCP on the producer side
  • One or more NFcs may communicate with SCPc, while one or more NFps communicate with SCPp.
  • Rel-16 allows the NRF to be co-located or combined with an SCP. In such scenarios, the SCP could also include the functionality of an OAuth authorization server.
  • SCPc may perform the role of the OAuth client. It therefore has a unique OAuth client identifier (ID) and registers with the OAuth authorization server, see, e.g., the above-referenced IETF RFC 6749.
  • ID OAuth client identifier
  • NFs communicate to each other via an SCP in the indirect communication model D introduced in Rel-16. There is no direct connectivity between NFs. In addition, the NFs only implement application logic whereas all the non-application logic, including e.g. discovery of the target NF and selecting target NF from a list of available NFs, are delegated to the SCP.
  • OAuth client authentication is based on underlying TFS between the OAuth client (NF consumer - NFc) and OAuth server (NRF). This is no longer possible with Option D.
  • FIGURE 3 illustrates a method according to some embodiments.
  • the method may be implemented by an apparatus performing a service-consuming first network entity, such as the NFc 120.
  • the method comprises transmitting 300 a registration request to an authorization entity, the registration request being indicative of at least one proxy entity allowed to act on behalf of the first network entity.
  • a security token comprising information for controlling access for the first network entity for a service-providing second network entity is received 310.
  • the security token also indicates the at least one proxy entity allowed to act on behalf of the first network entity in the first mobile network.
  • the security token may refer to an information element comprising information for authorizing access for the first network entity, represented by the proxy entity, to a service-providing second network entity, such as the NFp 122.
  • the security token could alternatively be referred to as an authentication token or ID token, for example.
  • the security token is transmitted 320 to the proxy entity for accessing the service-providing second network entity via the at least one proxy entity the service request.
  • the security token may be transmitted in a service request for accessing the service providing second network entity in accordance with the applied interface between the first network entity.
  • the proxy entity may initiate service discovery procedure with an authorization entity (e.g. 5G SBA NF and NF service discovery procedure) or transmit an access request comprising the security token to an authorization entity, on behalf of the first network entity.
  • an authorization entity e.g. 5G SBA NF and NF service discovery procedure
  • FIGURE 4 illustrates a method according to some embodiments.
  • the method may be implemented by an apparatus performing a (first) authorization entity, such as the NRFc of the PLMN 110.
  • the authorization entity may refer to a network entity configured at least to facilitate authorization of network services, such as 5G SBA NF services.
  • the authorization entity may also be configured to perform other operations, such as discovery of network services.
  • the method comprises receiving 400 a registration request from a service consuming first network entity, such as the NFc 120 performing the method of FIGURE 2.
  • the registration request is indicative of at least one proxy entity allowed to act on behalf of the first network entity.
  • a security token is generated 410.
  • the security token comprises information for controlling access for the first network entity for a service-providing second network entity and indicating the at least one proxy entity allowed to act on behalf of the first network entity.
  • the security token is transmitted 420 to the first network entity, for requesting access to the second network entity via the proxy entity.
  • FIGURE 5 illustrates a method according to some embodiments.
  • the method may be implemented by an apparatus performing a (second) authorization entity, such as the NRFp of the PLMN 112.
  • the method comprises receiving 500, from a proxy entity configured to operate on behalf of a service-consuming first network entity, an access request for a service providing second network entity.
  • the access request comprises security token comprising information for controlling access for the first network entity for a service-providing second network entity and indicating at least one proxy entity allowed to act on behalf of the first network entity.
  • Access for the first network entity to the second network entity is authorized 510 on the basis of the security token.
  • the first network entity may be authenticated on the basis of the security token.
  • the proxy entity may be authenticated on the basis of the security token.
  • the authorization entity may be able to (separately) authenticate the proxy entity, e.g. by TLS authentication procedure between the SCPc and NRFc in the same PLMN 110.
  • a proxy entity identifier obtained on the basis of such authentication procedure may be compared to the proxy entity identification in the received security token. If they match, the authority of the proxy entity sending the access request may be successfully verified (and access to the second network entity authorized or allowed upon also successfully authorizing access for the first network entity).
  • TLS authentication procedure between the SCPc and NRFc in the same PLMN 110.
  • a response message is transmitted 530 to the proxy entity on the basis of the authorizing the first network entity and the verifying the authority of the proxy entity.
  • access to the second network entity may be authorized or allowed for the first network entity represented by the proxy entity.
  • the response message indicates approval of the access request.
  • the response message may indicate rejection of the access request.
  • the response message may comprise an access token or other type of authorization information element for accessing the second network entity and some or all NF services thereof.
  • An authorization procedure may be performed by the authorization entity 140, 142 in response to receiving 400 the request.
  • the authorization procedure may comprise operations to validate the request and confirming authority of the first network entity to obtain requested service indicated in the first request.
  • the authorization may be based on an authorization policy and/or profile of requested NF/NF service.
  • the policy/profile may identify available resources, allowed actions, and further scope of access restrictions or permissions, for example.
  • the security token may be generated 410 for the first network entity in response to the authorization procedure being successfully performed.
  • the authorization procedure may comprise performing or detecting authentication of the first network entity based on authentication credentials from the first network entity.
  • the authentication may be based on lower-layer security procedures, such as transport layer authentication.
  • transport layer authentication For example, in the example of Figure 1, the NRFc 140 may authenticate the NFc 120 based on TLS procedure and a TLS certificate from the NFc, i.e. during TLS setup. If transport layer protection is not applied in the PLMN 110, the authentication may be implicit by Network Domain Security/IP (NDS/IP) or physical security procedure.
  • NDS/IP Network Domain Security/IP
  • a specific, independent authentication may be arranged between the NFc 120 and the NRFc 140.
  • the security token is generated by a first authorization entity in a first mobile network and the access to the second network entity in a second mobile network is authorized by a second authorization entity in the second mobile network.
  • NRFp or home NRF
  • a single authorization entity such as the NRF in the configuration illustrated in FIGURE 2 may perform the methods of FIGURES 4 and 5.
  • the security token may be transmitted in a message comprising information on target NF producer(s), such as identification information regarding the second network entity and/or the second authorization entity, e.g. the NRFp 142.
  • the security token may be cryptographically protected before the transmission. It is preferable that the security token is at least integrity protected to prevent other parties from changing the contents. Further security level improvement can be achieved by encryption.
  • the access request of block 500 is an access token request and the response message of block 530 is an access token response message.
  • An access token for accessing a resource of the second network entity may be generated after block 520, in response to verifying the security token and the authority of the proxy entity.
  • the access token may be included in the access token response message in block 530.
  • the proxy entity receives the access token response comprising the access token.
  • the proxy entity may then, for accessing the second network entity and the service thereof on behalf of the first network entity, include the access token in a service request to the second network entity, or to a second proxy entity acting on behalf of the second network entity.
  • the first network entity may be authenticated in block 510 on the basis of the security token.
  • the authentication may be preceded by one or more cryptographic validation or verification operations, in some embodiments integrity check, signature verification, and/or decryption.
  • the first network entity may be authenticated on the basis of validating or verifying one or more information elements of the security token.
  • the authentication of the first network entity may comprise one or more security checks, which may include identifying the requesting first network entity, verifying one or more identification information elements in the security token and/or performing verification of an authentication code in the security token, for example.
  • the security token may comprise one or more of a network function instance identifier of the first network entity, a node identifier of the first network entity, timing information indicative of issuance and/or expiry of security token, at least one proxy element identifier, and a digital signature of an issuing authorization entity.
  • the security token comprises audience identification information indicative of at least some of: the authorization entity, the second network entity, one or more associated services of the second network entity, and associated network slice.
  • the security token may comprise a network function instance identifier of the first network entity and/or a node identifier, such as a fully qualified domain name (FQDN), of the first network entity.
  • the audience may be thus an entity generating the access token, such as the NRFp 142 or an OAuth server.
  • the authorization in block 510 may thus comprise verifying that the security token is associated with the first network entity and/or verifying that the security token is addressed to the second authorization entity and/or the second network entity.
  • the security token may comprise at least some of the fields or claims illustrated in the example token below:
  • the security token may be included as a "subject token" in the access token request “exp” refers to information indicative of expiry of the token, “sub” to subject.
  • JSON Web Encryption is applied within and/or between the mobile networks 110, 112.
  • the JWE may be applied (at least) between SEPPc 130 and SEPPp 132 for protecting messages on the N32 interface.
  • a JSON Object Signing and Encryption (JOSE) header may thus comprise parameters describing cryptographic operations and parameters applied.
  • the security token is a JSON web token (JWT).
  • JWT token may comprise at least some of the parameters disclosed in Ch. 4 of the OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-19, M. Jones et al, July 20, 2019.
  • the security token may be a JWT and decoded JWT claims set may comprise at least some of the above illustrated information.
  • the JWT may be intended for consumption by the NRF (authorization server) before a specific expiration time.
  • the subject of the JWT (“NF consumer Instance Id") is the party on behalf of whom the new token is being requested.
  • the "may act" claim indicates that the SCP identified by SCP Id is authorized to act on behalf of the NF consumer instance Id.
  • various other token formats may be applied.
  • the access authorization in block 510 may comprise verifying the security token by at least one of: verifying that the security token is not expired, verifying that the security token is associated with the first network entity, verifying that the security token is addressed to the second discovery entity and/or the second network entity, and verifying a digital signature of an issuing authorization entity in the security token.
  • the authority of the proxy entity may be verified in block 520 based on an information element indicating the at least one proxy entity in the security token and an identifier in an authentication certificate received from the proxy entity, such as a TLS certificate received during TLS procedure between the SPCc and the NRF.
  • an authorization entity such as the NRFc 140 performing the method of FIGURE 4 is further configured to generate an actor token for the proxy entity (configured to represent the service-consuming first network entity) upon authenticating the proxy entity.
  • the actor token may comprise information for authenticating the proxy entity for verifying the authority of the proxy entity to act on behalf of the first network entity.
  • the access request 500 from the proxy entity may further comprise the actor token comprising information for authenticating the proxy entity for verifying the authority of the proxy entity to act on behalf of the first network entity.
  • a discovery or a registration request is received from the proxy entity, such as the SCPc 150.
  • an actor token is generated for the proxy entity.
  • the actor token comprises information for authenticating the proxy entity for accessing the service-providing second network entity on behalf of the first network entity.
  • the security token is transmitted to the proxy entity in a discovery or registration response from the first authorization entity to the first proxy entity.
  • the proxy entity may include the received actor token in a subsequent access request 500 sent, on behalf of the first network entity, to an authorization entity performing the method of FIGURE 5.
  • the authority of the proxy entity may be verified in block 520 on the basis of the received actor token.
  • the authority of the proxy entity is verified in block 520 on the basis of an information element indicating the at least one proxy entity in the security token and an identifier of the proxy entity in the actor token.
  • the authority of the proxy entity is successfully verified. If not, verification fails and access to the second network entity is rejected.
  • actor token may comprise at least some of the fields or claims illustrated in the example token below, some of which may be similar as for the security token:
  • the actor token may be included as "actor token" in the access token request.
  • the actor token may be a JWT and decoded JWT claims set may comprise at least some of the above illustrated information.
  • the JWT may be intended for consumption by the NRF (authorization server) before a specific expiration time.
  • the actor token may be verified by at least one of: verifying that the actor token is not expired, verifying that the actor token is associated with the proxy entity, verifying that the actor token is addressed to the authorization entity and/or the second network entity, and verifying a digital signature of an issuing authorization entity in the security token.
  • the security token, the actor token, and/or the messages comprising the token may comprise further information in addition to some or all of the information elements indicated above.
  • the token or the message carrying the token may indicate requested or issued token type.
  • the security token and/or actor token may be cryptographically protected (by the token-issuing authorization entity) by one or more cryptographic methods.
  • the token receiving authorization entity such as NRFp 142, is configured to access and remove the protection to ensure validity of the security token and/or actor token.
  • the actor token and/or the security token may be integrity-protected by the respective issuing authorization entity, and authorizing access to the second network entity comprises verifying integrity of the actor token and/or the security token.
  • the actor token and/or the security token is encrypted, e.g. by a secret key of the NRFc (or a key shared by NRFc and NRFp).
  • NRFc secret key of the NRFc
  • NRFp key shared by NRFc and NRFp
  • the actor token and/or security token transmitted between the mobile networks 110, 120 may be secured by applying at least some features applied for protecting access token via N32 interface when PRINS is applied or when IPX nodes are applied between SEPPs.
  • the token may be further encrypted in the inter-mobile network interface, in the embodiment of Figure 1 by encryption applied over the N32 interface between the SEPPs 130, 132.
  • the actor token and/or the security token comprises or is transmitted with a digital signature of the token-issuing first authorization entity.
  • the authorization in block 510 and/or the verification in block 520 may thus comprise verifying a digital signature of the first discovery entity in the security token.
  • token introspection procedure may be applied for the actor token and/or security token.
  • the second access node may be configured to use token introspection to verify and/or check validity of the token.
  • the actor token and/or the security token may comprise timing information indicative of issuance and/or expiry of security token.
  • the token may be short-lived, i.e. have a pre-configured validity period, after which it is rejected.
  • validity of the security token may be bound to the lifetime of a TLS tunnel between the mobile networks.
  • lifetime of the security token is dependent on lifetime of N32 interface handshake on security capability negotiation.
  • the verification in block 510 and/or 520 may comprise verifying that the actor token and/or security token is not expired.
  • the security token and/or the actor token may be specific to, or applicable only for a single request for discovering or accessing the service-providing second network entity.
  • the token may be used for multiple requests for accessing the second network entity, such as requests to the second discovery entity in the second mobile network.
  • FIGURE 6 Reference is now made to the signaling example of FIGURE 6, with references to 3GPP 5G SBA system, such as a system comprising the entities of FIGURE 1.
  • the example procedure comprises multiple stages which may be separately performed.
  • the NFc obtains a security token from the local NRFc (e.g. NRFc 140). In the present example, this is carried out by a registration procedure and initiated by a register request 600 to the NRFc, such as an Nnrf NFRegister Request.
  • the NFc includes identifier(s) of one or more authorized or accepted SCPs in the register request.
  • the NRFc may authenticate the NFc (and perform other registration related features) and generate 602 the security token, by applying at least some of the features illustrated above.
  • Block 602 may comprise authentication of the NFc, which may comprise checking that the NFc has been validly authenticated e.g. by lower-layer security procedure, as indicated earlier.
  • the NRFc 140 may perform NFc authentication at (or before) block 602, as a precondition for generating the security token.
  • the security token comprises identifier(s) of one or more authorized or accepted SCPs, e.g. the SCPc 150.
  • the security token indicates: NF Instance Id (of NFc), issued at (time), issuer (NRF), issuing NRF’s signature, and identity of the next hop SCP (SCPc in the present example).
  • the security token is transmitted to the NFc in a register response 604, such as an Nnrf NFRegister Request.
  • the NFc transmits the security token 606 to the authorized SCPc.
  • the security token may be transmitted in a service request for accessing the service providing second network entity.
  • the NFc may thus invoke an API requesting specific service towards the SPCc, such as NF discovery upon requiring a specific NF service.
  • the NFc obtains an actor token, in the present example by a discovery procedure.
  • the NFp transmits a discovery request 608 to the NRFc, such as Nnrf NFDiscovery Request.
  • the request 608 may be transmitted upon a trigger from the NFc, such as the message 606 or another request.
  • the discovery may be triggered upon an incoming trigger, such as a request from another network node or function regarding a roaming UE.
  • the NRFc may perform an authorization procedure for the requested NF (service) discovery.
  • the NRFc may thus further define a set of NF instance(s) matching the discovery request 608. Based on a profile of the expected NF/NF service and the type of the NFc, the NRFc may thus determine whether the NFc is allowed to discover the expected NF instance(s).
  • Block 610 may comprise authentication of the SCPc, which may comprise checking that the SCPc has been validly authenticated e.g. by lower-layer security procedure.
  • the NRFc If the service discovery is authorized/allowed, the NRFc generates 612 the actor token, by applying at least some of the presently illustrated features.
  • the actor token may thus be unique for a (NF discovery) request of the NFc.
  • the NRFc transmits an NF discovery response 614, such as Nnrf NFDiscovery Response, comprising the actor token and discovered NF information to the SCPc.
  • the discovery response 614 may comprise further information regarding the NF discovery, such as an IP address or FQDN of the NRFp.
  • the discovery response may comprise NF profiles of the NRFp. It is to be noted that in some embodiments the NRFc may need to communicate (not shown) with the other PLMN 120 and the NRFp thereof to obtain the required NF information. Thus, the NRFc may request NF discovery from the NRFp.
  • the SCPc requests access token from the remote NRF NRFp by an NF access token request 616, such as an Nnrf_NFAccessToken_Get_Request.
  • the security token may be included in a subject-token information element of the request 616, for example.
  • the actor token is also included in the request 616.
  • the request may comprise further related NF information, such as the NF Instance Id(s) of the NFc, expected NF service name(s), NF type of the expected NF producer instance and NF consumer.
  • the NRFp performs the access authorization 618 for the NFc based on the security token, which may comprise authenticating the NFc by validating the security token, by applying at least some of the features illustrated above.
  • the NRFp may verify the security token and obtain an NF Instance Id for which the access token to be generated.
  • the NRFp also verifies 620 authority of the proxy entity based on the security token and in the present example the actor token, to ensure that the entity through which the access token is being sent is indeed a trustworthy.
  • the NRFp Upon successful access authorization and authority verification, the NRFp generates 622 an access token for the NFc to access the NFp service.
  • the access token may be issued for the NFc (subject identified by the security token) specifically for the requested NF service and scope.
  • the access token is transmitted to the SPCc in an access token response 624, such as Nnrf_NFAccessToken_Get_Response. Otherwise, it may respond by an error response, such as OAuth error response.
  • the response may comprise further parameters, such as expiration time and allowed scope.
  • the SCPc may store the access token received in the response 624 and transmit an NF service request to the NFp (or the SCPp) to initiate inter-PLMN NF communication and service (not shown).
  • the service request may comprise the access token.
  • Stored access tokens may be re-used for accessing service(s) from producer NF type listed in claims (scope, audience) during their validity time.
  • notifications are applied between NFs. At least some of the above disclosed features may be applied similarly in connection with other types of communications, in some embodiments inter-mobile network notifications.
  • At least some of the presently disclosed token exchange related operations may be based on OAuth token exchange, e.g. as defined in version 2.0 as disclosed in Ch. 2 of IETF Internet Draft, OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-19, M. Jones et al, July 20, 2019.
  • the access token may be an OAuth 2.0 access token.
  • the NRFc may provide information on how to access the remote OAuth server, such as FQDN of the OAuth server, in the discovery response 614.
  • the actor token may be obtained during mutual authentication between the SCPc and the NRFc or by a registration procedure between the SCPc and the NRFc.
  • a method for a first authorization entity and apparatus configured to perform the method, comprising:
  • an actor token comprising information for authenticating the first proxy entity for authorizing access for the first network entity to a service-providing second network entity
  • the method may further comprise
  • a security token comprising information for authenticating the first network entity for accessing the service-providing second network entity
  • the method further comprises: - performing, by the first authorization entity, an authorization procedure comprising verification of authority of the first network entity to obtain requested service indicated in the first request, and
  • a method for first proxy entity configured to act on behalf of a service-consuming first network entity, and apparatus configured to perform the method, comprising:
  • the actor token may be transmitted to the first authorization entity (in case the first network entity and the second network entity are in the same PLMN), or to a second authorization entity in another PLMN.
  • the access request may be an access token request and the method may further comprise:
  • the first request is a discovery request for discovering the service-providing second network entity in the second mobile network for the first network entity, and at least the actor token is included in a discovery response from the first authorization entity to the first proxy entity.
  • the first request may be a registration request for registering the first network entity to the first authorization entity, and the actor token is included in a registration response from the first authorization entity.
  • a method for a second authorization entity comprising:
  • the actor token may comprise information for authenticating the first proxy entity in the second mobile network for authorizing access to the second network entity.
  • the access request is an access token request and the response message is an access token response message
  • the means are further configured for: generating an access token for accessing a resource of the second network entity in response to at least verifying the actor token, and including the access token in the access token response message.
  • the authenticating may comprise verifying the actor token by at least one of: verifying that the actor token is not expired, verifying that the actor token is associated with the first proxy entity, verifying that the actor token is addressed to the second authorization entity and/or the second network entity, and verifying a digital signature of the first authorization entity in the security token.
  • the access request may further comprise a security token comprising information for authenticating the first network entity in the second mobile network for accessing the service-providing second network entity in the second mobile network, and the means are further configured for authenticating the first network entity on the basis of the verifying the security token, and authorizing the access to the second network entity for the first network entity via the firth proxy entity in response to successful verification of the and the security token.
  • the security token may comprise an information element indicative of at least one proxy entity entitled to act on behalf of the first network entity.
  • the second authorization entity may be configured to verify the actor token on the basis of the information element in the security token and an identifier of the first proxy entity in the actor token.
  • the actor token and/or the security token may be integrity-protected by the first authorization entity and the authentication comprises verifying integrity of the actor token and/or the security token.
  • the actor token comprises one or more of an identifier of the first proxy entity, timing information indicative of issuance and/or expiry of actor token, an issuer identifier, and a digital signature of the first authorization entity.
  • the actor token may comprise audience identification information indicative of one or more of: the second authorization entity, the second network entity, one or more associated services of the second network entity, and associated network slice.
  • the first network entity is or comprises a network function service consumer function
  • the second network entity is or comprises a network function service producer function
  • the first authorization entity and the second authorization entity is or comprises a network resource function
  • the proxy entity is or comprises a service communication proxy, such as one or more of the entities illustrated in connection with FIGURES 1 and 2.
  • network functions or nodes illustrated above may be shared between two physically separate devices forming one operational entity.
  • virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network.
  • Network virtualization may involve platform virtualization, often combined with resource virtualization.
  • Network virtualization may be categorized as external virtual networking which combines many networks, or parts of networks, into the server computer or the host computer. External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to software containers on a single system.
  • instances of the 5G network functions can be instantiated as virtual network functions (VNFs) in network function virtualization (NFV) architecture.
  • VNFs virtual network functions
  • NFV network function virtualization
  • NFs are instantiated and when no longer needed ramped down.
  • Each NF instance has an instance ID.
  • At least some of the above-illustrated NFs may be applied as cloud-native VNFs with containers.
  • An electronic device comprising electronic circuitries may be an apparatus for realizing at least some embodiments of the present invention.
  • the apparatus may be or may be comprised in a computer, a server, a proxy device, a network function hosting device, a network access device, network management device or another appropriately configured communications apparatus.
  • the apparatus carrying out the above- described functionalities is comprised in such a device, e.g. the apparatus may comprise a circuitry, such as a chip, a chipset, a microcontroller, or a combination of such circuitries configured to perform at least some of the above illustrated features.
  • circuitry may refer to one or more or all of the following:
  • 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.
  • FIGURE 7 illustrates an example apparatus capable of supporting at least some embodiments of the present invention. Illustrated is a device 700, which may be arranged to carry out at least some of the embodiments related to arranging service access authorization as illustrated above.
  • the device may include one or more controllers configured to carry out operations in accordance with at least some of the embodiments illustrated above, such as some or more of the features illustrated above in connection with Figures 1 to 6.
  • the device may operate as the apparatus performing the authorization entity and the method of Figure 4 and/or 5, the service-consuming first network entity performing the method of Figure 3, or the or the proxy entity acting on behalf of the service-consuming first network entity, such as the NRFc 140/NRFp 142, the NFc 120 or SCPc 150, respectively.
  • the device may operate as the apparatus performing at least one of the above- illustrated methods applying the actor token.
  • a processor 702 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.
  • the processor 702 may comprise more than one processor.
  • the processor may comprise at least one application-specific integrated circuit, ASIC.
  • the processor may comprise at least one field-programmable gate array, FPGA.
  • the processor may be means for performing method steps in the device.
  • the processor may be configured, at least in part by computer instructions, to perform actions.
  • the device 700 may comprise memory 704.
  • the memory may comprise random-access memory and/or permanent memory.
  • the memory may comprise at least one RAM chip.
  • the memory may comprise solid-state, magnetic, optical and/or holographic memory, for example.
  • the memory may be at least in part accessible to the processor 702.
  • the memory may be at least in part comprised in the processor 702.
  • the memory 704 may be means for storing information.
  • the memory may comprise computer instructions that the processor is configured to execute. When computer instructions configured to cause the processor to perform certain actions are stored in the memory, and the device in overall is configured to run under the direction of the processor using computer instructions from the memory, the processor and/or its at least one processing core may be considered to be configured to perform said certain actions.
  • the memory may be at least in part comprised in the processor.
  • the memory may be at least in part external to the device 700 but accessible to the device. For example, control parameters affecting operations related to service access authorization and token generation, as well as associated information may be stored in one or more portions of the memory and used to control operation of the apparatus. Further, the memory may comprise device-specific cryptographic information, such as secret and public key of the device 700.
  • the device 700 may comprise a transmitter 706.
  • the device may comprise a receiver 708.
  • the transmitter and the receiver may be configured to transmit and receive, respectively, information in accordance with at least one wired or wireless, cellular or non- cellular standard.
  • the transmitter may comprise more than one transmitter.
  • the receiver may comprise more than one receiver.
  • the transmitter and/or receiver may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, LTE, 5G, wireless local area network, WLAN, and/or Ethernet, for example.
  • the device 700 may comprise a near-field communication, NFC, transceiver 710.
  • the device 700 may comprise user interface, UI, 712.
  • the UI may comprise at least one of a display, a keyboard, a touchscreen, a speaker and a microphone.
  • a user may be able to operate the device via the UI, for example to cause the device to perform at least some functions illustrated above, configure the operation of the device, and/or to manage digital files stored in the memory 704 or on a cloud accessible via the transmitter 706 and the receiver 708, or via the NFC transceiver 710.
  • the device 700 may comprise or be arranged to accept a memory module 714, such as a user identity module or other type of memory module.
  • the user identity module may comprise, for example, a personal identification IC card installable in the device 700.
  • the processor 702 may be furnished with a transmitter arranged to output information from the processor, via electrical leads internal to the device 700, to other devices comprised in the device.
  • a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 704 for storage therein.
  • the transmitter may comprise a parallel bus transmitter.
  • the processor may comprise a receiver arranged to receive information in the processor, via electrical leads internal to the device 700, from other devices comprised in the device 700.
  • Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from the receiver 708 for processing in the processor.
  • the receiver may comprise a parallel bus receiver.
  • the device 700 may comprise further devices not illustrated in Figure 7.
  • some devices may lack the NFC transceiver 710 and/or the user identity module 714.
  • the processor 702, the memory 704, the transmitter 706, the receiver 708, the NFC transceiver 710, the UI 712 and/or the user identity module 714 may be interconnected by electrical leads internal to the device 700 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to the device, to allow for the devices to exchange information.
  • this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.
  • references throughout this specification to one embodiment or an embodiment means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention.
  • appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.
  • the skilled person will appreciate that above-illustrated embodiments may be combined in various ways. Embodiments illustrated in connection with Figures 2 to 6 may be taken in isolation or further combined together.
  • Various embodiments and examples of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.

Abstract

Dans un aspect donné à titre d'exemple, l'invention concerne un procédé consistant : à recevoir d'une entité mandataire configurée pour fonctionner au nom d'une première entité de réseau consommant un service, une demande d'accès pour une deuxième entité de réseau fournissant un service, la demande d'accès comprenant un jeton de sécurité contenant des informations servant à commander l'accès à la première entité de réseau par une deuxième entité de réseau fournissant un service, et indiquant au moins une entité mandataire autorisée à agir au nom de la première entité de réseau. L'accès de la première entité de réseau à la deuxième entité de réseau est autorisé en fonction du jeton de sécurité. L'autorité de l'entité mandataire pour agir au nom de la première entité de réseau est vérifiée en fonction du jeton de sécurité, et un message de réponse est transmis à l'entité mandataire.
PCT/FI2020/050687 2019-11-18 2020-10-21 Gestion de sécurité de service de réseau mobile WO2021099675A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN201911046948 2019-11-18
IN201911046948 2019-11-18

Publications (1)

Publication Number Publication Date
WO2021099675A1 true WO2021099675A1 (fr) 2021-05-27

Family

ID=75980458

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2020/050687 WO2021099675A1 (fr) 2019-11-18 2020-10-21 Gestion de sécurité de service de réseau mobile

Country Status (1)

Country Link
WO (1) WO2021099675A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023031037A1 (fr) * 2021-09-03 2023-03-09 Telefonaktiebolaget Lm Ericsson (Publ) Autorisation de service de fonction réseau dans un réseau de communication sans fil
WO2023102861A1 (fr) * 2021-12-09 2023-06-15 Nokia Shanghai Bell Co., Ltd. Procédé, appareil et programme informatique

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16", 3GPP TS 29.510, 29 November 2019 (2019-11-29), XP051831859, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/29_series/29.510/29510-g11,zip> [retrieved on 20210111] *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 16", 3GPP TS 33.501, 25 September 2019 (2019-09-25), XP051839350, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/33_series/33.501/33501-g00.zip> [retrieved on 20210111] *
"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, 30 October 2019 (2019-10-30), XP051813043, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/33_series/33.855/33855-180.zip> [retrieved on 20210112] *
NOKIA; NOKIA SHANGHAI BELL: "Discussion paper on Service access authorization for Indirect communication with delegated discovery (Model D)", 3GPP DRAFT S 3-191484, 29 April 2019 (2019-04-29), XP051721647, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_95_Reno/Docs/S3-191484.zip> [retrieved on 20210112] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023031037A1 (fr) * 2021-09-03 2023-03-09 Telefonaktiebolaget Lm Ericsson (Publ) Autorisation de service de fonction réseau dans un réseau de communication sans fil
WO2023102861A1 (fr) * 2021-12-09 2023-06-15 Nokia Shanghai Bell Co., Ltd. Procédé, appareil et programme informatique

Similar Documents

Publication Publication Date Title
US11844014B2 (en) Service authorization for indirect communication in a communication system
WO2020220865A1 (fr) Procédé de vérification d&#39;identité pour service de fonction de réseau, et dispositif associé
US20210234706A1 (en) Network function authentication based on public key binding in access token in a communication system
US10856135B2 (en) Method and apparatus for network access
TWI514896B (zh) 可信賴聯合身份方法及裝置
WO2020174121A1 (fr) Autorisation de communication de réseau inter-mobile
EP3668042B1 (fr) Procédé et appareil d&#39;enregistrement basés sur une architecture orientée service
WO2020053481A1 (fr) Authentification de fonction réseau au moyen d&#39;une demande de service signée numériquement dans un système de communication
US20210120416A1 (en) Secure inter-mobile network communication
US11070355B2 (en) Profile installation based on privilege level
US11425636B1 (en) Network function service subscription control
US20210112411A1 (en) Multi-factor authentication in private mobile networks
US20220191028A1 (en) Authorization of network request
WO2019196766A1 (fr) Procédé et appareil de communication
US20220182829A1 (en) Systems and methods for subscriber certificate provisioning
WO2021099675A1 (fr) Gestion de sécurité de service de réseau mobile
WO2021224545A1 (fr) Enregistrement amélioré dans des réseaux de communication
WO2021165925A1 (fr) Gestion de clé
US20230030315A1 (en) Network Security
WO2021079023A1 (fr) Sécurité de communication de réseau inter-mobile
TWI820696B (zh) 通訊方法、裝置及電腦可讀儲存介質
US20230155832A1 (en) Network security
US20240121111A1 (en) Enhanced security in communication networks
WO2024032226A1 (fr) Procédé de communication et appareil de communication
CN117997541A (zh) 通信方法和通信装置

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: 20890741

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: 20890741

Country of ref document: EP

Kind code of ref document: A1