Authentication and authorization on x2 and x3 interfaces

Abstract

The present disclosure provides not just a method for authenticating and authorizing the entities and microservices allowed to send X2 / X3 traffic, but also a mechanism to control the permissions of the same entities and microservices for establishing a session in which they are allowed to send X2 / X3 traffic The disclosure introduces a Lawful Interception (LI) Identity and Access Manager (LI-IAM) function device with the architecture of the LI Interception Management System (LI-IMS) that manage and verify the identities of entities requesting access to X2 / X3 interface traffic, thereby ensuring that only authorized requests are processed. The LI-IAM function device grants secure processing of identity data and provides authorization for X2 / X3 transmission, so representing a new method to fortify the security posture of LI operations by mitigating risk of unauthorized access to X2 / X3 interfaces.

Description

[0001] AUTHENTIC A TION AND AUTHORIZA TION ON X2 AND X3 INTERFA CES

[0002] Technical Field

[0003] The present disclosure relates to authentication and authorization of X2 and X3 interfaces of a Point of Interception (POI) on a network element. The present disclosure also relates to a network node, a computer program, and a carrier to do the same.

[0004] Background

[0005] Lawful Interception is a security process by which a telecommunications company or network operator is mandated by law to design their network in such a way that it can intercept and deliver communications of individuals or groups to Law Enforcement Agencies (LEAs).

[0006] In the context of Lawful Interception (LI) architecture, X2 and X3 interfaces play crucial roles in the delivery and management of intercepted data to law enforcement agencies:

[0007] X2 Interface: This interface handles the delivery of LI_X2 Intercept Related Information (xIRI) from the service provider's network to the LI Mediation and Delivery Function (MDF), that after the mediation delivers on HI2 interface the Intercept Related Information (IRI) to the Law Enforcement Monitoring Facility (LEMF). IRI includes metadata about the communications being intercepted, such as call duration, the parties involved, time stamps, and service types.

[0008] X3 Interface: This interface handles the delivery of LI_X3 Content of Communication (xCC) from the service provider's network to the LI Mediation and Delivery Function (MDF), that after the mediation delivers on HI2 interface the Content of Communication (CC) to the Law Enforcement Monitoring Facility (LEMF).

[0009] The X2 and X3 interfaces connect Point of Interception (POI) functions of network elements in the general network domain with the MDF. Since the X2 and X3 interfaces operate between domains in the Communication Service Provider (CSP) network with different trust levels, the X2 and X3 interfaces should be authenticated.

[0010] Figure 1 illustrates a reference model for X2 and X3 interfaces between a POI and an MDF according to some embodiments of the present disclosure. On X2 / X3 interfaces 124 and 126, implementations shall perform mutual authentication between the POI function device 118 and the MDF device 120 using client and server X.509 certificates following Internet Engineering Task Force (IETF) Request for Comments (RFC) 6125 but a further check that the incoming requester is allowed for X2 / X3 traffic is missing.

[0011] X2 and X3 Security requirements as described in European Telecommunications Standards Institute (ETSI) Technical Specification (TS) 103 221-2 VI.6.1 (2022-03) Annex A.2.1 and A.4.1 are:

[0012] The X2 / X3 architecture and message exchange technique shall provide authentication and authorization of end points.

[0013] However, in the ETSI TS 103 221-2 there is no indication on how to implement these requirements.

[0014] Summary

[0015] The object of the invention is to enable an improvement in the security of Lawful Interception (LI) data traffic.

[0016] The present disclosure provides a method for authenticating and authorizing not just the entities and microservices allowed to send X2 / X3 traffic, but also a mechanism to control the permissions of the same entities and microservices for establishing a session in which they are allowed to send X2 / X3 traffic. The disclosure introduces a LI Identity and Access Manager (LI-IAM) function device with the architecture of the LI Interception Management System (LI-IMS) that manage and verify the identities of entities requesting access to X2 / X3 interface traffic, thereby ensuring that only authorized requests are processed. IAM is used to create, maintain, and manage identity information of POIs and provide authentication and authorization service to LI- IMS using a JavaScript Object Notation (JSON) Web Tokens (JWTs). So that, when a Point of Interception (POI) function device sends X2 / X3 traffic to the LI-IMS, the LI-IMS requests the LI-IAM function device to verify the POI device identity and to control if it is enabled to send X2 / X3 traffic. This solution fully supports zero-trust principles.

[0017] In an embodiment, a method for authenticating a POI device of a network element is performed by a MDF device and the method includes receiving, from the POI device a login request comprising an access token associated with a registration of the POI device with a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device, and an identity token identifying the POI device wherein the access token comprises a certificate hash associated with the POI device. The method also includes verifying identity token and access token, wherein the verifying the access token comprises matching the certificate hash associated with the POI device with a hash from a transport layer security channel. The method also includes generating a session token and a refresh token, wherein the session token facilitates authentication of a communication session, and the refresh token is based on the access token, providing, to the POI device, the session token and the refresh token, receiving one or more of an X2 or X3 packet from the POI device, wherein the X2 or X3 packet comprises the session token, verifying that the session token in the X2 or X3 packet matches the session token provided to the POI device and is not expired, and processing the X2 or X3 packet in response to the verifying.

[0018] In an embodiment, the method includes receiving, from the POI device, a refresh request comprising the refresh token and determining whether the refresh token has expired.

[0019] In an embodiment, in response to the refresh token being expired, the method further comprises inactivating the session token resulting in a logout of the POI device.

[0020] In an embodiment, in response to the refresh token remaining valid, the method further comprises in response to a certificate associated with the POI device not being revoked, generating a new session token and providing the session token to the POI device and in response to the certificate associated with the POI device being revoked, inactivating the session token and forcing a logout of the POI device.

[0021] In an embodiment, the certificate is determined to be revoked or not revoked based on a comparison with a certificate revocation list.

[0022] In an embodiment, the access token and the identity token of the login request comprise a JWT.

[0023] In an embodiment, the login request further comprises an access token type identifier identifying whether the POI device is X2Only, X3Only, or X2andX3, and an identity token type.

[0024] In an embodiment, the session token expires before the refresh token.

[0025] In an embodiment, a network node is provided that implements an MDF device that is configured for authenticating POI device of a network element. The network node includes a processor that causes the network node to receiving, from the POI device a login request comprising an access token associated with a registration of the POI device with a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device, and an identity token identifying the POI device wherein the access token comprises a certificate hash associated with the POI device. The process also causes the network node to verify the identity token and access token, wherein the verifying the access token comprises matching the certificate hash associated with the POI device with a hash from a transport layer security channel. The process also causes the network node to generate a session token and a refresh token, wherein the session token facilitates authentication of a communication session, and the refresh token is based on the access token, providing, to the POI device, the session token and the refresh token, receiving one or more of an X2 or X3 packet from the POI device, wherein the X2 or X3 packet comprises the session token, verifying that the session token in the X2 or X3 packet matches the session token provided to the POI device and is not expired, and processing the X2 or X3 packet in response to the verifying.

[0026] In an embodiment, a method for authenticating a POI device of a network element performed by a POI device includes providing a Lawful Interception, LI, Identity and Access Manager, LI-IAM, function device with an authentication request comprising a POI device identifier and a secret key and receiving, from the LI-IAM function device, an access token comprising a certificate hash associated with the POI device and an identity token identifying the POI device. The method also includes providing, to a MDF device, a login request comprising the access token and the identity token, receiving, from the MDF device, a session token and a refresh token, wherein the session token facilitates authentication of a communication session and the refresh token is based on the access token, and providing one or more of an X2 or X3 packet to the MDF device, wherein the X2 or X3 packet comprises the session token.

[0027] In an embodiment, the method includes determining that the session token has expired, providing, to the MDF device, a refresh request comprising the refresh token, and receiving a new session token from the MDF device.

[0028] In an embodiment, the method includes providing one or more additional X2 or X3 packets to the MDF device, wherein the one or more additional X2 or X3 packets comprise the new session token.

[0029] In an embodiment, the method includes providing a logout request to the MDF device. In an embodiment, wherein the access token and the identity token of the login request comprise a JWT.

[0030] In an embodiment, the login request further comprises an access token type identifier identifying whether the POI device is X2Only, X3Only, or X2andX3, and an identity token type.

[0031] In an embodiment, the session token expires before the refresh token.

[0032] In an embodiment, a network node is provided that implements a POI device of a network element that is configured for authenticating the POI device. The network node includes a processor that is configured to cause the network node to provide a LI- IAM function device with an authentication request comprising a POI device identifier and a secret key and receive, from the LI-IAM function device, an access token comprising a certificate hash associated with the POI device and an identity token identifying the POI device. The processor also causes the network node to provide, to a MDF device, a login request comprising the access token and the identity token, receive, from the MDF device, a session token and a refresh token, wherein the session token facilitates authentication of a communication session and the refresh token is based on the access token, and provide one or more of an X2 or X3 packet to the MDF device, wherein the X2 or X3 packet comprises the session token.

[0033] In an embodiment, a method for authenticating a POI device of a network element performed by a LI-IAM function device includes receiving, from the POI device, an authentication request comprising a POI device identifier and a secret key, validating the POI device identifier and the secret key, generating, based on the POI device identifier and a secret key, an access token comprising a certificate hash associated with the POI device and an identity token based on the POI device identifier, and providing, to the POI device, the access token and the identity token.

[0034] In an embodiment, a network node that implements a LI-IAM function device is provided that is configured for authenticating a POI device. The network node includes a processor that is configured to cause the network node to receive, from the POI device, an authentication request comprising a POI device identifier and a secret key, validate the POI device identifier and the secret key, generate, based on the POI device identifier and a secret key, an access token comprising a certificate hash associated with the POI device and an identity token based on the POI device identifier, and provide, to the POI device, the access token and the identity token. Brief of the

[0035] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0036] Figure 1 illustrates a reference model for X2 and X3 interfaces between a Point of Interception (POI) and a Mediation and Delivery Function (MDF) according to some embodiments of the present disclosure;

[0037] Figure 2 illustrates an exemplary Lawful Interception (LI) Architecture with a Lawful Interception (LI) Identity and Access Management (LI-IAM) function device according to some embodiments of the present disclosure;

[0038] Figure 3 illustrates a message sequence chart of a method for authenticating a POI device of a network element according to some embodiments of the present disclosure;

[0039] Figure 4 illustrates another message sequence chart of the method for authenticating a POI device of a network element according to some embodiments of the present disclosure;

[0040] Figure 5 is a schematic block diagram of network node according to some embodiments of the present disclosure;

[0041] Figure 6 is a schematic block diagram that illustrates a virtualized embodiment of the network node of Figure 5 according to some embodiments of the present disclosure; and

[0042] Figure 7 is a schematic block diagram of the network node of Figure 5 according to some other embodiments of the present disclosure.

[0043] Detailed

[0044] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. Network Node: As used herein, a "network node" is any type of node in a Communication Service Provider network or any node that implements a core network function. Some examples of a core network node include, e.g., a Lawful Interception (LI) Identity and Access Manager (LI-IAM) function device, a Point of Interception (POI) function device, a Mediation and Delivery Function (MDF) device, a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0045] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0046] Fifth Generation (5G) architecture is characterized by freely combinable, highly scalable microservices distributed over a node cluster in the network. This transformation of the Telecom architecture exposes the applications to many more security breaches. In such context, an authentication and authorization mechanism is much more relevant.

[0047] Looking at the 5G Lawful Interception (LI) architecture, the definition of an authentication and authorization mechanism is essential to secure Zero Trust (ZT) communications between the trust domains. Specifically, ZT is implemented through attestation at bootstrap so meaning there is no attestation monitoring at run-time.

[0048] Without an authentication and authorization mechanism on X2 / X3 interfaces, a hacker could take, singularly or together, many attacks, for instance:

[0049] • Code injection in X2 / X3 microservices to send unspurious traffic

[0050] • Denial of service attack to crash the MDF function

[0051] • NE Repudiation attack

[0052] European Telecommunications Standards Institute (ETSI) Technical Specification (TS) 103 221-2 requires authentication and authorization mechanisms but does not indicate how they must be implemented. This implementation discretion could lead to points of weakness as it can be approached with different quality and effectiveness in the different elements constituting the solution. The weakest element (most flawed implementation) negatively affects the entire solution. Even more valuable it is after the introduction of an authorization mechanism which can enable the distribution of stronger and flexible dynamic authorization rules among centralized access management entity and all LI Mediation and Delivery Functions (MDFs)

[0053] The present disclosure provides a method for authenticating and authorizing not just the entities and microservices allowed to send X2 / X3 traffic, but also a mechanism to control the permissions of the same entities and microservices for establishing a session in which they are allowed to send X2 / X3 traffic. The disclosure introduces a LI Identity and Access Manager (LI-IAM) function device with the architecture of the LI Interception Management System (LI-IMS) that manage and verify the identities of entities requesting access to X2 / X3 interface traffic, thereby ensuring that only authorized requests are processed. IAM is used to create, maintain, and manage identity information of POIs and provide authentication and authorization service to LI- IMS using a JavaScript Object Notation (JSON) Web Tokens (JWTs). So that, when a Point of Interception (POI) function device sends X2 / X3 traffic to the LI-IMS, the LI-IMS requests the LI-IAM function device to verify the POI function device identity and to control if it is enabled to send X2 / X3 traffic. This solution fully supports ZT principles. The existing security mechanism to secure a connection (TLS based) can and must be used.

[0054] Some of the advantage provided by the techniques disclosed herein is that not only are rigorous authentication and authorization for entities communicating via X2 / X3 interfaces ensured but there are also updates to the ETSI TS 103 221-2 standard to embed these security measures formally. This alignment reinforces the commitment to enhancing security of LI operations while facilitating standard compliance.

[0055] The techniques disclosed herein also introduce a very flexible authentication and authorization mechanism through the registration of Network Elements (NEs) in the LI- IAM function device and the definition of specific authorization rules for the NEs. Moreover, the Identity and Access Manager is a very secure solution; indeed, modern IAM implements capabilities as step-up authentication, which involves multiple factors authentication, thereby providing additional layers of defense against unauthorized access. Furthermore, the IAM offers attack protection measures to safeguard the integrity of the communication.

[0056] With the implementation of multi-factor authentication, even if an entity or microservice possesses a certificate signed by the root Certificate Authority (CA), it will not gain access unless it is recognized as an authenticated and authorized party. This stringent verification process ensures that a stolen or compromised certificate alone is not sufficient to impersonate authorized POIs, thus significantly reducing the likelihood of security breaches.

[0057] These advancements in authentication and authorization not only meet the current security challenges but also anticipate future requirements connected to LI in cloud, positioning the solution as a forward-looking enhancement to LI communications.

[0058] This form of standardized method offers different advantages:

[0059] The reuse of standardized parameters and protocols would make widely applicable this solution in heterogeneous contexts.

[0060] Multivendor POIs (Points of Interception) are easily integrable.

[0061] Integration of cross-platform elements (best-of-breed technologies in the market).

[0062] Figure 2 illustrates an exemplary Lawful Interception (LI) Architecture with a Lawful Interception (LI) Identity and Access Management (LI-IAM) function device according to some embodiments of the present disclosure.

[0063] Figure 2 shows that in a communication service provider (CSP) 102, there can be different trust domains. Many cloud systems are typically built on the assumption that there is one root administrator who has absolute dominion over all software and resources in a system, but that approach is not compatible with LI, unless they are a member of the LI administration team that controls the rest of the network. The incompatibility is due to the legal requirements of LI and desirability of maintaining privacy. While LI is always under the control of the CSP 102, most general network administration and support personnel will not be authorized to have control, knowledge, or visibility of LI. Therefore, it is necessary to be able to separate the administration of LI from other network functions or processes. Accordingly, general network operations can occur in Trust Domain (TD)-A 106, including the Element of Lawful Interception (ELI) otherwise known as the Point of Interception (118) that intercepts data including LI X2 Intercept Related Information (xIRI) and LI X3 Content of Communication (xCC) from nodes in the TD-A 106, while the bulk of the LI infrastructure has a separate TD-B 108, which includes the Administration Function (ADMF) 110, which includes the LI-IAM function device 112, the LI-IMS Certification Authority (LI-CA) 114 and LI Certificate Management Function (LI-CMF) 116, MDF 120. The law enforcement agency (LEA) 104 can receive data, via the Law Enforcement Monitoring Facility (LEMF) 122 that receives data from the CSP 102 via the MDF 120.

[0064] According to ETSI TS 104 007 V0.0.7, ELI is a generic name that is used for POIs as well as MDFs, and Triggering Functions (TFs). Future versions of the standard may have different naming conventions, but the techniques disclosed herein may apply to future versions of the functions that perform similar operations.

[0065] A Certificate Authority (CA), a Certificate Management Function (CMF) and an Identity and Access Manager (IAM) are entities that can work together to establish a secure authentication system. Within this framework, the LICA issues digital certificates that verify the identity of an entity, such as a NE or LI entities. LI-CMF mediates between LI-CA and ADMF to abstract away from CA vendor specific interfaces. Conversely, the LI-IAM function device 112 authenticates NE or LI entities and issues them with a security token (at application level while TLS certificate operates at a lower transport layer), which can be used to gain access to protected resources, such as X2 / X3 traffic. The trust relationship between a CA and an IAM is predicated on mutual confidence: the LICA must rely on the LI-IAM function device 112 to authenticate NE or LI entities correctly at application level, while the LI-IAM function device 112 must rely on the LICA for issuing valid certificates to assure secure transport. This synergy ensures that NE and LI entities can securely and reliably access, transmit and manage protected resources.

[0066] In an embodiment, LI-IAM function device 112 functionality can be combined in one of the entities that the standard ETSI TS 104 007 V0.0.7 (2024-01) already proposes in TD-B2, LI-CA 114 or LICMF 116; at the same time, it is also acceptable to think of a LI-IAM function device 112 as a standalone entity that can interoperate with a baseline LICA and LI-CMF.

[0067] The LI-IAM function device 112 equips the LI-IMS with the enhanced capabilities to authenticate and authorize Points of Interception (POIs), centralizing identity management and the security token management that control POI's access permissions. This system securely processes identity data and provides guarantees for the validity and authorization for the transmission of X2 / X3 traffic.

[0068] In the present disclosure, LI-IAM function device 112 adheres to open authentication and authorization standards and protocols, such as OAuth 2.0 protocol, OpenlD Connect, and JSON Web Token (JWT).

[0069] Figure 3 illustrates a message sequence chart of a method for authenticating a POI device 118 of a network element according to some embodiments of the present disclosure.

[0070] In Figure 3, at step 302, the POI device 118 sends to the LI-IAM function device 112 the POI devices 118's credentials which include the POI device identifier (e.g., client ID) and a secret key. The credentials are sent along with a request for an access and identity token to send X2 / X3 traffic to the MDF 120. An example of the request is below: curl -request POST \

[0071] — url 'https: / / trustDomainBl / liiam / token' \

[0072] -data grant_type=client_credentials \

[0073] -data client_id=NE_ID \

[0074] -data client_secret=NE_SECRET \

[0075] -data audience= ("X2 Only" or "X3 Only" or "X2 And X3")

[0076] Where clientjd is the network element (NE ID) received in a configuration phase, client_secret is the NE Secret received in the configuration phase, audience defines the intended consumer of the token, that is the MDF 120.

[0077] At step 303, the LI-IAM function device 112 validates the POI device identifier and secret key by checking the NE POI certificate that is obtained by the LI Certificate Management Function (LI-CMF) during the certificate provisioning phase and NE credential to authenticate the NE.

[0078] At step 304, the LI-IAM function device 112 generates, based on the POI device identifier and secret key, an access token comprising a certificate hash associated with the POI device 118 and an identity token based on the POI device identifier and then at step 306, the LI-IAM function device provides the identity token and access token to the POI device 118.

[0079] POI receives an HTTPS 200 response with a payload containing access_token, access_token_type, identity_token and identity_token_type, values: {

[0080] "access_token" : "eyJz93a ... k4laU Ww",

[0081] "access_token_type":("X2 Only" or "X3 Only" or "X2 And X3"), "identity Joken" : "ii Jk67a ...j3lgFBb", "identity_token_type":"NE_POI",

[0082] }

[0083] Identity and access token are JSON web token (JWT), that is JSON object. Because of its relatively small size, a JWT can be sent through a URL, through a POST parameter and it is transmitted quickly. The information contained within the JSON object are digitally signed using public / private key pairs of LI-IAM, as in AuthO SW product that implements OAuth 2.0 protocol.

[0084] Note that in access_token it is included an expiration time for the whole long living authorization session, e.g., 86400 seconds. Furthermore, the access token shall contain a claim related to the NE POI certificate hash as retrieved from the LI-CMF during the certificate provisioning phase. In the registration phase, an NE secret that is pre-shared in both entities, the application (POI device 118) and the LI-IAM function device 112. So that, the application entity (POI device 118) authenticates by including the NE Secret in the authentication request to the LI-IAM.

[0085] LI-IAM function device 112 serves as the authorization server that issues the registered POI device 118 a client identifier (NE ID as a unique string representing the registration information provided by the NE POI), a client password (NE Secret) and the NE POI certificate hash obtained from the NE POI certificate provided by LI-CMF 116 during the certificate provisioning phase. Note that this procedure is described as "Client Secret authentication" method in RFC 6749 sections 2.2, 2.3.

[0086] OAuth 2.0 defines a shared-secret method of client authentication but also allows for defining and using additional client authentication mechanisms when interacting directly with the authorization server. An additional mechanism of client authentication utilizing mutual-TLS certificate-based authentication provides better security characteristics than shared secrets.

[0087] The registration phase is required to determine how to build the tokens before their use in the authentication and authorization workflow. The access token shall contain a claim related to the POI device 118 certificate hash obtained in registration phase. POI device 118 can use the identity token and access token to login with LI-MDF so that X2 / X3 traffic could be managed by LI-MDF.

[0088] The POI device 118 certificate hash in access token ensures that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources. Such a constraint is sometimes referred to as key confirmation, proof-of-possession, or holder-of-key. Binding an access token to the client's certificate prevents the use of stolen access tokens or replay of access tokens by unauthorized parties.

[0089] JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the keyed-hash message authentication code (HMAC) algorithm) or a public / private key pair using RSA or Elliptic Curve Digital Signature Algorithm (ECDSA).

[0090] Although JWTs can be encrypted to also provide secrecy between parties, we focused on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public / private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

[0091] Structurally it is a string encoded in base64 and formed by three blocks separated by a dot (.):

[0092] • Header: Used to identify the type of token and the signing algorithm.

[0093] • Payload: It is the block that contains the claims (key-value) related to an entity (usually the user). There are three types of claims: registered, public, and private claims.

[0094] • Signature: Includes a secret key to validate the token

[0095] Example of JWT payload:

[0096] {

[0097] "sub": "1234567890",

[0098] "name": "<NE POI name>",

[0099] "type": "<NE type>",

[0100] "exp": "<expiration date>" } sub is a registered claim that contains the subject, name is a registered claim that contains the username, type is a private claim that defines the NE type and exp is a registered claim that contains the expiration date.

[0101] Claim validations enable to choose the conditions under which a token received in the policy is rejected. Claim validation is mandatory or non-mandatory. If a claim is defined as mandatory and is not present in the incoming JWT, the policy rejects this token. If a claim is defined as non-mandatory and is not present in the incoming JWT, the policy does not reject the token for that specific validation.

[0102] For both cases, if a claim is present, the policy validates the token value. If the validation fails, the JWT will be rejected.

[0103] In registration phase, on LI-IAM it is possible also to add policies used to validate the tokens. These policies could be customized per NE POI basis.

[0104] Example of such policy could be the check of UID relative distinguished name of the Subject field in the NE POI certificate against a key-value claim in the JWT payload.

[0105] Example of JWT payload with "UID":

[0106] {

[0107] "sub": "1234567890",

[0108] "name": "<NE POI name>",

[0109] "type": "<NE type>",

[0110] "UID": "<UID>",

[0111] "exp": "<expiration date>"

[0112] }

[0113] The check failure will determine the access denied. When access tokens are represented as JSON Web Tokens (JWT), the certificate hash information shall be represented using the x5t#S256 confirmation method member. To represent the hash of a certificate in a JWT, it is used the new JWT Confirmation Method from IETF RFC 7800 member x5t#S256 for the X.509 Certificate SHA-256 Thumbprint. The value of the x5t#S256 member is a base64url-encoded SHA-256 hash (a.k.a., thumbprint, fingerprint, or digest) of the DER encoding of the X.509 certificate. The following is an example of a JWT payload containing an x5t#S256 certificate thumbprint confirmation method. The cnf confirmation method claim at the bottom of the example has the x5t#S256 confirmation method member containing the value that is the hash of the client certificate to which the access token is bound.

[0114] {

[0115] "sub": "1234567890",

[0116] "name": "<NE POI name>",

[0117] "type": "<NE type>",

[0118] "UID": "<UID>",

[0119] "exp": "<expiration date>",

[0120] "cnf":{

[0121] "x5t#S256":nbwcK0esc3ACC3DB2Y5_IESsXE8o9ltc05O89jdN-dg2"

[0122] }

[0123] }

[0124] MDF 120 obtains, from its Transport Security Layer (TLS) implementation layer, the NE POI certificate used for mutual TLS and MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt must be rejected with an error, per IETF RFC 6750, using an HTTP 401 status code and the invalid_token error code.

[0125] Figure 4 illustrates another message sequence chart of the method for authenticating a POI device of a network element according to some embodiments of the present disclosure.

[0126] At 402, the method includes providing, to the MDF device 120 by the POI device 118, a login request that includes the access and identity tokens received from the LI- IAM function device 112 in step 306. The identity token identifies the POI device 118 and the access token comprises a certificate hash associated with the POI device 118. An example of the request is provided below: curl --request POST \

[0127] — url 'https: / / trustDomainB3 / limdf / session' \

[0128] -data access_token="eyJz93a...k4laUWw" \

[0129] -data access_token_type="X2 Only" or "X3 Only" or "X2 And X3" \

[0130] -data identity_token="iiJk67a...j3lgFBb" \

[0131] -data identity_token_type=" NE_POI"

[0132] At step 403, the MDF device 120 verifies the identity token and access token, wherein the verifying the access token comprises matching the certificate hash associated with the POI device with a hash from a transport layer security channel. In an embodiment, the MDF device 120 checks the identity and access token validity to avoid replay attacks. Tokens are parsed and validated to make sure they aren't compromised, and the signature is authentic. Tokens should be verified to decrease security risks if the token has been, for example, tampered with, misused, or has expired. JWT validation checks the structure, claims, and signature to assure the least amount of risk. Note that a successfully validated token only means that the information contained within the token has not been modified by anyone else. This doesn't mean that others weren't able to see the content, which is stored in plain text. Because of this, other steps should be taken to ensure that JWTs are not intercepted, such as by sending JWTs only over HTTPS.

[0133] At step 404, the MDF device 120 generates a session token and a refresh token, wherein the session token facilitates authentication of a communication session, and the refresh token is based on the access token. The MDF device 120 creates a short-lived Session ID token whereas the duration is determined considering the trade-off between performance and security responsiveness, e.g., 1800 seconds.

[0134] The MDF device 120 also creates a long-lived refresh token by setting its expiration time as the one extracted from the access token e.g., 86400 seconds. Moreover, the refresh token will embed also a claim related to the NE POI certificate hash as extracted from the access token. Moreover, the MDF device 120 builds a long- lived refresh token including in a claim the POI device 118 certificate hash as extracted from the access token. Refresh period is decided by MDF device 120 and is a trade-off between performance and security responsiveness since MDF device 120 has under control its performances and this expiration should be settled in order to get a balance between the impact on performances and the provided responsiveness for security counter-action (i.e. the forced logout in presence of a revoked POI TLS certificate).

[0135] At step 406, the MDF device 120 provides the session token and the refresh token to the POI device 118. The POI device 118 may receive an HTTPS 200 response with a payload containing sessionjd and refresh values.

[0136] { sessionjd" : "eyJz93a ... k4 la U Ww", refresh" : "at3j56r...T g8Ip9a", }

[0137] At step 408, the POI device 118 starts sending X2 / X3 Protocol Data Unit (PDU) packets whose header contains the "Session ID" (e.g., the session token) received from MDF device 120.

[0138] At step 410, the MDF device 120, at the reception of X2 / X3 packets, checks the received Session token validity by matching the session token received in the X2 / X3 packets to the session token provided to the POI device 118 and verifies that the session token is not expired. The MDF device 120 accepts the X2 / X3 only in case of correct validation, otherwise the packet is discarded, and the session is logically forced logout. Also, the other embedded authorization rules are validated. If any rule is violated, the packet will be discarded. At step 412, if the validation is successful, the data is processed. If the validation is not successful, or the session token has expired, the MDF device 120 may inactivate the session at step 422, resulting in a logout of the POI device 118.

[0139] At step 413, the POI device 118 can determine that the session token has expired or is about to expire, and at step 414, the POI device 118 can send to the MDF device 120 a refresh token, which can serve as an indicator to the MDF device 120 that the POI device 118 wants a new session token, enabling prolonged re-authentication and re-authorization over the ongoing session.

[0140] The MDF device 120 can decide to not refresh the token, one reason could be for example when it verifies that the extracted claim related to the POI device 118 certificate hash matches with anyone found within the certificate revocation list; in that case MDF device 120 does not refresh the token forcing the teardown of the ongoing TLS session.

[0141] This is a new dynamic mechanism that, in the event of certificate revocation, ensures that connections to functions that have become untrustworthy can be torn down immediately when active, not just merely prevented from re-starting in the future by a revoked / invalid certificate.

[0142] In the case of normal operation, the POI device 118 can perform a logout to interrupt the session towards MDF device 120.

[0143] At step 416, the MDF device 120 verifies the refresh token and that its validity is not expired, otherwise a forced logout is ordered (at step 422). Moreover, MDF device 120 extracts the POI device 118 certificate hash to verify that this certificate is not among the revoked certificates. If this is the case, a new Session ID is generated. In case the POI device 118 certificate has been revoked, MDF device 120 does not refresh the Session ID token forcing the immediate teardown of the session (step 422).

[0144] In an embodiment, the MDF device 120 must obtain, from its TLS implementation layer, the POI device 118 certificate used for establishing the mutual TLS. Then, the MDF device 120 can verify that the hash of that certificate matches with the hash received in the refresh token.

[0145] In a further embodiment, MDF device 120 extracts the serial number of the read certificate and searches the same in the Certificate Revocation List (CRL), so allowing to verify if that a specific certificate has been revoked.

[0146] At step 418, the MDF device 120 provides the new session token to the POI device 118 via an HTTPS 200 response, which may then, at step 419, send additional X2 and / or X3 packets whose header contains the "Session ID" received in step 418.

[0147] When the session is no longer needed, the POI device 118 at step 420 can send a logout request, and in response the MDF device 120 at step 422 can inactivate the session token, thus ending the session.

[0148] The use of standardized JWTs allows for easy integration of different technologies and ensures the secure and reliable functioning of network solutions.

[0149] Integrating JWT (JSON Web Token) with a specialized policy for identifying potentially malicious Network Elements (NEs) can significantly enhance the security of a network. This approach can be particularly effective in scenarios where the behavior of network elements like NE-POI needs to be monitored for unusual or potentially harmful activities.

[0150] JWTs can be enriched with dynamic behavior monitoring policies, which would provide an additional layer of security. This involves tracking the activities of each NE, such as the packet count, to identify any anomalies that might suggest malicious intent.

[0151] By defining a threshold based on normal traffic between two NEs, with the JWT it is possible to consider the implementation of a policy that checks when an NE is sending an unusually high number of packets that overcomes the defined threshold in a short period. After the detection, the NE is flagged as suspicious. This threshold can be encoded into the JWT payload or associated metadata, allowing for real-time monitoring. Upon detecting such an anomaly, the system could trigger an alert, temporarily restrict the NE's access, or initiate a deeper investigation to determine if the activity is indeed malicious.

[0152] It follows an example of JWT payload that combines the authorization fields with some additional information associated to an embedded detection policy:

[0153] {

[0154] "sub": "nel2345",

[0155] "name": "Network Element 1",

[0156] "iat": 1617184000,

[0157] "exp": 1617270400,

[0158] "neType": "NE POI",

[0159] "securityPolicy": {

[0160] "packetCountThreshold": 1000,

[0161] "actionOnThresholdBreach": "flag",

[0162] "additionalMonitoring": true },

[0163] "iss": "Securityprovider"

[0164] }

[0165] This method adopts an adaptive, risk-based approach to network security. By continuously analyzing packet flows and other behavioral metrics, the system can dynamically adjust its security posture. If an NE consistently shows signs of abnormal behavior, its risk profile is updated in the JWT, leading to stricter monitoring or preemptive action.

[0166] The present disclosure proposes to add to the X2 / X3 PDU header a new mandatory field "Session ID" to indicate the identifier of a new Session between the entity / microservice that is sending the X2 / X3 traffic and the LI-MDF.

[0167] Table 1 in clause 5.1 of ETSI TS 103 221-2 is proposed to be changed as below, with the underlined row added:

[0168] Table 1: X2 / X3 PDU Structure

[0169]

[0170] Additionally, New clause 5.2.9 "Session ID" in ETSI TS 103 221-2 should contain something as: Session Identifier uniquely identifies the secure X2 / X3 Session. It is a JSON Web Token (JWT) format:

[0171] Session ID JWT payload shall contain at least the following fields:

[0172] {

[0173] "sub": "<Session Identifier^',

[0174] "name": "<NE POI identifier^',

[0175] "type": "<NE type>",

[0176] "exp": "<timestamp>"

[0177] }

[0178] Where "sub" is a registered claim that defines the Session Identifier as a version 4 UUID as per IETF RFC 4122, name is a registered claim that contains the NE POI identifier, type is a private claim that defines the NE POI type and the exp is a registered claim that defines the claim expiration date.

[0179] Figure 5 is a schematic block diagram of a network node 500 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 500 may be, for example, a network node that implements all or part of the functionality of the LI-IAM function device 112, MDF device 120, and POI device 118 as described herein. As illustrated, the network node 500 includes a control system 502 that includes one or more processors 504 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory / computer readable storage medium (CRSM) 506, and a network interface 508. The one or more processors 504 are also referred to herein as processing circuitry. The one or more processors 504 operate to provide one or more functions of a network node 500 as described herein. In some embodiments, the function(s) are implemented in one or more computer programs 510 that are stored, e.g., in the memory 506 and executed by the one or more processors 504.

[0180] Figure 6 is a schematic block diagram that illustrates a virtualized embodiment of the network node 500 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.

[0181] As used herein, a "virtualized" network node is an implementation of the network node 500 in which at least a portion of the functionality of the network node 500 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). The network node 500 includes one or more processing nodes 600 coupled to or included as part of a network(s) 602. If present, the control system 502 is connected to the processing node(s) 600 via the network 602. Each processing node 600 includes one or more processors 604 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory / computer readable storage medium 606, and a network interface 608.

[0182] In this example, functions 610 of the network node 500 described herein are implemented at the one or more processing nodes 600 or distributed across the one or more processing nodes 600 and the control system 502 in any desired manner. In some particular embodiments, some or all of the functions 610 of the network node 500 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 600. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 600 and the control system 502 is used in order to carry out at least some of the desired functions 610. Notably, in some embodiments, the control system 502 may not be included.

[0183] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of network node 500 or a node (e.g., a processing node 600) implementing one or more of the functions 610 of the network node 500 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0184] Figure 7 is a schematic block diagram of the network node 500 according to some other embodiments of the present disclosure. The network node 500 includes one or more modules of the LI-IAM function device 112, MDF device 120, and POI device 118 which are implemented in software. The modules LI-IAM function device 112, MDF device 120, and POI device 118 provide the functionality of the network node 500 described herein. This discussion is equally applicable to the processing node 600 of Figure 6 where the modules LI-IAM function device 112, MDF device 120, and POI device 118 may be implemented at one of the processing nodes 600 or distributed across multiple processing nodes 600 and / or distributed across the processing node(s) 600 and the control system 502.

[0185] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0186] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0187] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims1. A method for authenticating a point of intercept, POI, device (118) of a network element performed by a Mediation and Delivery Function, MDF, device (120), the method comprising: receiving (402), from the POI device (118), a login request comprising an access token associated with a registration of the POI device (118) with a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device (112), and an identity token identifying the POI device (118) wherein the access token comprises a certificate hash associated with the POI device (118); verifying (403) identity token and access token, wherein the verifying the access token comprises matching the certificate hash associated with the POI device with a hash from a transport layer security channel; generating (404) a session token and a refresh token, wherein the session token facilitates authentication of a communication session, and the refresh token is based on the access token; providing (406), to the POI device (118), the session token and the refresh token; receiving (408) one or more of an X2 or X3 packet from the POI device (118), wherein the X2 or X3 packet comprises the session token; verifying (410) that the session token in the X2 or X3 packet matches the session token provided to the POI device (118) and is not expired; and processing (412) the X2 or X3 packet in response to the verifying.

2. The method of claim 1 , further comprising: receiving (414), from the POI device (118), a refresh request comprising the refresh token; and determining (416) whether the refresh token has expired.

3. The method of claim 2, wherein in response to the refresh token being expired, the method further comprises: inactivating (422) the session token resulting in a logout of the POI device (118).

4. The method of claim 2, wherein in response to the refresh token remaining valid, the method further comprises: in response to a certificate associated with the POI device (118) not being revoked, generating (416) a new session token and providing (418) the session token to the POI device (118); and in response to the certificate associated with the POI device (118) being revoked, inactivating (422) the session token and forcing a logout of the POI device (118).

5. The method of claim 4, wherein the certificate is determined to be revoked or not revoked based on a comparison with a certificate revocation list.

6. The method of any of claims 1 to 5, wherein the access token and the identity token of the login request comprise a JavaScript Object Notation, JSON, Web Token, JWT.

7. The method of claim 6 wherein the login request further comprises an access token type identifier identifying whether the POI device (118) is X2Only, X3Only, or X2andX3, and an identity token type.

8. The method of any of claims 1 to 7, wherein the session token expires before the refresh token.

9. A network node (500) that implements a Mediation and Delivery Function, MDF, device (120) that is configured for authenticating a point of intercept, POI, device (118) of a network element, the network node (500) comprising a processor (504) configured to cause the network node (500) to: receive (402), from the POI device (118), a login request comprising an access token associated with a registration of the POI device (118) with a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device (112), and an identity token identifying the POI device (118), wherein the access token comprises a certificate hash associated with the POI device (118);verifying (403) identity token and access token, wherein the verifying the access token comprises matching the certificate hash associated with the POI device with a hash from a transport layer security channel; generate (404) a session token and a refresh token, wherein the session token facilitates authentication of a communication session, and the refresh token is based on the access token; provide (406), to the POI device (118), the session token and the refresh token; receive (408) one or more of an X2 or X3 packet from the POI device (118), wherein the X2 or X3 packet comprises the session token; verify (410) that the session token in the X2 or X3 packet matches the session token provided to the POI device (118); and process (412) the X2 or X3 packet in response to the verifying.

10. The network node (500) of claim 9, wherein the processor (504) is further configured to cause the network node (500) to perform any of the methods of claims 2 to 8.

11. A method for authenticating a point of intercept, POI, device (118) of a network element performed by the POI device (118), the method comprising: providing (302) a Lawful Interception, LI, Identity and Access Manager, LI-IAM, function device (112) with an authentication request comprising a POI device (118) identifier and a secret key; receiving (306), from the LI-IAM function device (112), an access token comprising a certificate hash associated with the POI device (118) and an identity token identifying the POI device (118); providing (402), to a Mediation and Delivery Function, MDF, device (120), a login request comprising the access token and the identity token; receiving (406), from the MDF device (120), a session token and a refresh token, wherein the session token facilitates authentication of a communication session and the refresh token is based on the access token; and providing (408) one or more of an X2 or X3 packet to the MDF device (120), wherein the X2 or X3 packet comprises the session token.

12. The method of claim 11 , further comprising: determining (413) that the session token has expired; providing (414), to the MDF device (120), a refresh request comprising the refresh token; and receiving (418) a new session token from the MDF device (120).

13. The method of claim 12, further comprising: providing (419) one or more additional X2 or X3 packets to the MDF device (120), wherein the one or more additional X2 or X3 packets comprise the new session token.

14. The method of any of claims 11 to 13, providing (420) a logout request to the MDF device (120).

15. The method of any of claims 11 to 14, wherein the access token and the identity token of the login request comprise a JavaScript Object Notation, JSON, Web Token, JWT.

16. The method of claim 15 wherein the login request further comprises an access token type identifier identifying whether the POI device (118) is X20nly, X30nly, or X2andX3, and an identity token type.

17. The method of any of claims 11 to 16, wherein the session token expires before the refresh token.

18. A network node (500) that implements a point of intercept, POI, device (118) of a network element that is configured for authenticating the POI device (118), the network node (500) comprising a processor (504) configured to cause the network node (500) to: provide (302) a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device (112), with an authentication request comprising a POI device identifier and a secret key;receive (306), from the LI-IAM function device (112), an access token comprising a certificate hash associated with the POI device (118) and an identity token identifying the POI device (118); provide (402), to a Mediation and Delivery Function, MDF, device, (120) a login request comprising the access token and the identity token; receive (406), from the MDF device (120), a session token and a refresh token, wherein the session token facilitates authentication of a communication session and the refresh token is based on the access token; and provide (408) one or more of an X2 or X3 packet to the MDF device (120), wherein the X2 or X3 packet comprises the session token.

19. The network node (500) of claim 18, wherein the processor (504) is further configured to cause the network node to perform any of the methods of claims 12 to 17.

20. A method for authenticating a point of intercept, POI, device (118) of a network element performed by a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device (112), the method comprising: receiving (302), from the POI device (118), an authentication request comprising a POI device identifier and a secret key; validating (303) the POI device identifier and the secret key; generating (304), based on the POI device identifier and a secret key, an access token comprising a certificate hash associated with the POI device (118) and an identity token based on the POI device identifier; and providing (306), to the POI device (118), the access token and the identity token.21 . A network node (500) that implements a Lawful Interception, LI, Identity and Access Manager, LI-IAM function device (112) that is configured for authenticating a point of intercept, POI, device (118) of a network element, the network node (500) comprising a processor (504) configured to cause the network node (500) to: receive (302), from the POI device (118), an authentication request comprising a POI device identifier and a secret key; validating (303) the POI device identifier and the secret key;generate (304), based on the POI device identifier and a secret key an access token comprising a certificate hash associated with the POI device (118) and an identity token based on the POI device identifier; and provide (306) to the POI device (118), the access token and the identity token.

22. A computer program (510) comprising instructions which, when executed on at least one processor (504), cause the processor (504) to carry out the method according to any of claims 1 to 8, 11-17, and 20.

23. A carrier containing the computer program (510) of claim 22, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (506).

Images