JP5069353B2 - Method and apparatus for handling trust in an IP multimedia subsystem communication network - Google Patents

Description

  The present invention relates to the field of handling reliability in IP multimedia subsystem communication networks.

  IP multimedia services provide a dynamic combination of voice, video, messaging, data, etc. in the same session. By increasing the number of basic applications and the number of media that can be combined, the number of services offered to end users will increase and the communication experience between individuals will be enriched. This will lead to a new generation of personalized and rich multimedia communication services.

  IP Multimedia Subsystem (IMS) is a technology defined by the 3rd Generation Partnership Project (3GPP) to provide IP multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328, and TS 29.329 releases 5-8). IMS provides key features that enrich the end-user's person-to-person communication experience through the use of standardized IMS service enablers, which are new rich person-to-person ( Promote not only client-to-client communication services but also personal-to-content (client-to-server) services. IMS uses the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or between user terminals and application servers). The Session Description Protocol (SDP) carried by SIP signaling is used to describe and negotiate the media components of the session. SIP has been created as a user-to-user protocol, while IMS allows operators and service providers to control user access to services and charge users accordingly. The integration of an IP multimedia subsystem into a 3G mobile communication system is schematically illustrated in FIG.

  Using IMS Authentication and Key Agreement (AKA), a shared key is exchanged between a user equipment (UE) 101 such as a mobile phone and a proxy call session control function (P-CSCF) 102 in the IMS network 103, for example. Established. Thereby, a signal transmitted between the UE 101 and the IMS network 103 can be encrypted in a secure manner using a pre-shared key using an IP-sec tunnel. The P-CSCF 102 may be located in the home public land mobile communication network (PLMN) as illustrated in FIG. 2, or may be located in the serving PLMN as illustrated in FIG. The home PLMN 201 is a network in which the UE 202 is registered, and the located PLMN 203 is a network to which the UE 202 may be connected. The serving call session control function (S-CSCF) 204 is located in the home PLMN 201 and controls the authentication and authorization of the UE 202 when the UE joins the network, which is exemplified by TS 33.203. Please refer to.

  IMS will be applied not only to 3GPP IMS networks, but also to networks other than 3GPP IMS, such as Telecoms & Internet converged Services & Protocols for Advanced Networks (ETSI TISPAN) and PacketCable. See, for example, ETSI ES 282007 and PKT-SP-23.228-I02-061013. However, when TISPAN and PacketCable deploy IMS, it not only uses IMS AKA as used by 3GPP IMS networks. Allowing a Universal Subscriber ID Module (USIM) or IP Multimedia Service ID Module (ISIM) in a TISPAN or PacketCable terminal for the purpose of accessing a 3GPP IMS network may be an obstacle to these access technologies in some scenarios It is. TISPAN and PacketCab have already introduced other security solutions such as HTTP Digest for SIP, Authentication by Network Attachment Subsystem (NASS) -IMS Bundle, and Transport Layer Security (TLS). However, these security mechanisms provide a lower level of security than IMS AKA.

  It is desirable for 3GPP IMS networks to be able to interact with TISPAN and PacketCable networks in order to improve the options available to users of the network. To enable this, the S-CSCF in the IMS network must be able to handle and support interactions between different access technologies. Then, terminals will be able to communicate with each other using different access technologies.

  Also, in addition to the IMS network being accessible using various access technologies such as 3GPP, TISPAN, and PacketCable, the IMS network is also e.g. PSTN interconnected (see e.g. 3GPP TS 23.002) , IMS interconnect (see, eg, 3GPP TS 23.228), and interconnect technologies such as Internet Interconnect may be used. It should be noted that Internet Interconnect is not a specific protocol or system, and therefore tends to be based on proprietary implementations. These allow each terminal that accesses the non-IMS network to access the IMS service from the IMS network.

  Different types of networks and access technologies will expose the IMS network to signaling from terminals and network nodes from different networks, and these signaling levels are different from other nodes in the same IMS network. May have. This is a major problem, especially for IMS interconnections, because the interconnection network cannot know about the various levels of trust used by other networks with which it is interconnected. Because. Thus, the interconnect network will treat all incoming traffic equally.

  In current IMS networks, there is only one trust domain given to the signaling, and therefore the message is either trusted or untrusted. If the SIP request used to establish the session is not trusted, the asserted user ID P-Asserted-ID (see RFC 3325) included in the SIP request is forwarded to the untrusted area. Deleted from the SIP request before The IMS network operator can accept any asserted information, for example, by accepting or not accepting the low level security used in early IMS security (see TR 33.978) or HTTP Digest (see RFC 2617). Must be removed from the request.

  IMS provides very strong security, but as interoperability with other access technologies and networks increases, the security applied to IMS communications may decrease. This leads to the risk of increased nuisance communication for each IMS user, which is undesirable. It can also reduce the likelihood that IMS will be adopted for services that require a strong security architecture, such as IPTV, where media streams for individual users or user groups may be encrypted. .

  Applicants have devised a solution to understand the problems associated with trust levels in current IMS networks and to indicate to nodes in the IMS network the level of trust that should be given to signaling. The SIP protocol is extended by including additional information in the SIP message that relates to the level of trustworthiness of the message. This allows flexible processing of trust in IMS sessions between networks. Information elements may be added, verified, and implemented by various entities in the network.

  According to a first aspect of the present invention, a method for handling trust in an IP multimedia subsystem network is provided. A node in the IP multimedia subsystem network receives a session initiation protocol message from a remote node. The message has an indicator that indicates the reliability level of the communication sent from the remote node to the node of the IP multimedia subsystem. Based on the indication, the node applies a security policy to the message.

  This has the advantage that the node can make a decision as to how much confidence to give the message. This is particularly advantageous when the remote node is located in another network that may not be an IMS network.

  SIP messages are typically used to set up a communication session, so in one option, security policies are applied to all signaling (eg, media) associated with session initiation protocol messages.

  The indicator is a numerical value in one option, in which case the numerical value can be directly mapped to a security policy. Alternatively, the indicator is a description, in which case the description is mapped to a security policy.

  The indicator, in one option, includes a plurality of indicator elements, each indicator element relating to the trust level of another node in the signaling path between the remote node and the previous node. This allows a confidence level indicator to be constructed as the SIP message traverses various nodes along the path to its destination, and trust information about each traversed node is trusted. Can be included in gender level indicators. The indicator element may include an indicator of the network from which the SIP message was received.

  The trust level indicator is optionally derived from some information that can affect the trust level to be given to the message. Such information includes the type of user terminal, the type of encryption, the type of network, the end user authentication mechanism, and the intra-region security mechanism.

  One option is to remove the P-Associated Identity header, apply topology concealment, disallow communication, allow unmodified communication, and filter messages according to the database for acceptable message sources The security policy to be applied is selected from either of the following and applying malware detection to incoming signaling for the SIP message.

  The security policy is optionally applied at any node that is relevant to applying such a policy. Such nodes include boundary elements, application servers, user equipment, and call session control functions.

  According to a second aspect of the present invention, a node for use in an IP multimedia subsystem network is provided. The node has a receiver for receiving session initiation protocol messages from the remote node. The message has an indicator that indicates the reliability level of communications sent from the remote node to that node. The node further comprises a processor for applying a security policy to the message. The security policy is determined from information included in the index.

  Such a node is used to apply a security policy to the message based on information contained in the indicator. This has the advantage of allowing security policies to be flexibly applied to the message depending on the level of trust the node gives to the message.

  The node is optionally selected from one of a user equipment, a call session control function, a boundary element, and an application server.

  According to a third aspect of the present invention, a node for use in a communication network is provided. The node comprises means for collecting trust level information and a processor for generating a trust level indicator based on the trust level information. The processor is also for modifying the session initiation protocol message such that the session initiation protocol message has an indication of trustworthiness level. The node further comprises a transmitter for sending a session initiation protocol message.

  Such a node has the advantage of allowing SIP messages that contain an indication of trust level to be sent. As described above, the trust level indicator can be used to determine the security policy applied to the message, and depending on the degree of trust given to the message by the network, various security policies can be used. Can be flexibly applied to messages.

  The processor is preferably configured to modify the existing trust level indicator in the SIP message by adding a trust level indicator element to the existing trust level indicator. Here, the index element of the trust level relates to the trust level of the node or the network in which the node is arranged.

  The node is preferably selected from one of a user equipment, a call session control function, a boundary element, and an application server.

  According to a fourth aspect of the present invention, a method for handling credibility in an IP multimedia subsystem network is provided. Trust level information is collected at the network node and a trust level indicator is created based on the trust level information. A trust level indicator is then added to the session initiation protocol message.

  The advantage of creating or modifying a SIP message to include an indication of trust level is that other nodes can be given to the SIP message or related messages based on the trust level indicator. To provide flexibility in the type of security policy that can be applied to the message.

  The trust level indicator is in one option added to a new session initiation protocol message created by the network node or added to an existing session initiation protocol received by the network node.

  Trust level information is optional, including database information, user terminal type, encryption type, network type, node type, end-user authentication mechanism, and in-region security mechanism. And based on either.

FIG. 3 is a diagram schematically illustrating the integration of an IP multimedia subsystem into a 3G mobile communication system as a block diagram. FIG. 2 schematically illustrates, as a block diagram, a security architecture for an IMS network when a P-CSCF is deployed in a visited network. FIG. 2 schematically illustrates, as a block diagram, a security architecture for an IMS network when a P-CSCF is deployed in a home network. FIG. 6 is a diagram schematically illustrating an example of a message format according to an embodiment of the present invention. FIG. 6 is a diagram schematically illustrating an example of a message format according to an embodiment of the present invention. FIG. 2 schematically illustrates a node used in a communication network as a block diagram in accordance with one embodiment of the present invention. FIG. 3 is a flow diagram illustrating the basic steps of the present invention. FIG. 2 schematically illustrates, as a block diagram, routing of SIP messages between an originating IMS network and an incoming IMS network. FIG. 2 schematically illustrates functional partitioning in an interconnected network according to one embodiment of the invention.

  By introducing an indication of trust level into the signaling, the nodes in the IMS network see what level of trust is given to the signaling from the remote node, eg user equipment (UE) can do. The trust level may depend on various factors, such as security at the UE and security at various nodes in the transmission path from the UE to a node in the IMS network.

  There are several ways in which a credibility indicator can be created. The first way of indicating credibility is by numerical value, for example, the new credibility level exists within a certain range, for example 1-10, in which case it is labeled 10 A trust level is assigned to a fully trusted access technology or security mechanism, and a trust level labeled 1 may be assigned to an access technology that is not trusted by the IMS node receiving the signaling. It will be.

  An IMS network operator can classify various terminals that support various access technologies and security mechanisms using trust levels. Table 1 is an example of the trust levels given for various access technologies and security mechanisms.

  In the numerical example above, the confidence level indicator is simply a numerical value. However, different IMS network operators may have different views on how trustworthy a given access technology or security mechanism is, depending on their own security policy and risk assessment. In this case, the credibility indicator is descriptive rather than numerical. The credibility indicator includes a description of factors that can affect the level of credibility to be given to the message. The description may be standardized and mapped by each network operator to a confidence level that the network operator considers correct. Thus, signaling that accurately has a given descriptive trust level indicator may be given different trust levels by different IMS network operators, but the trust level indicator is different for each network operator. Are standardized so that they can take their own views on the level of trust that will be given.

The following elements may be included in the signaling as part of the descriptive confidence level indicator.
• Applicable end-user network access security mechanism (if available) • End-user IMS authentication mechanism used • Message integrity protection used for access security • Used for access security Message confidentiality protection

In addition, including the following information, if available, may also be advantageous for signaling sent to the IMS network.
The terminal type, ie what type of hardware and software is used and whether it is authorized, or the media security level, ie any specific media security mechanism applied by the network Indicator of whether or not the signaling includes a request from a trusted AS or GW generated by the network. This is useful for “sudden” calls when the network is generating the request on behalf of the user. This includes the ID of the network from which the signaling originated or the ID of the network traversed before the signaling entered the terminating network. This is especially used when the operator has an agreement with a network that is less reliable than its own network, such as a pure Internet phone without strong user authentication, a PSTN network, etc.

  When an IMS session is established using SIP signaling, it is advantageous to include an indication of trust level in the SIP signaling used to establish the session, rather than sending separate signaling that provides trust information. It is. FIG. 4A schematically illustrates an exemplary SIP message 401 having a trust level indicator 402 as part of the message.

The following is an example of a SIP message that includes an indicator of trustworthiness level.

INVITE sip@company.com SIP / 2.0
Via: SIP / 2.0 / UDP pc1.company.com; branch = sdher4ty56df
Max-Forwards: 40
To: Peter <sip: peter@company.com>
From: Monica <sip: monica@company.com>; tag = 123456789
Call-ID: 762947fed38
TrustInfo: Authentication = HTTP Digest: Confidentiality = TLS-AES-CBC-128;
Integrity = TLS-HMAC-SHA1-160;
Contact: <sip: monica@pc1.company.com>
Content-Type: application / sdp
Content-Length: 167
<SDP contect ...>

  The trust level indicator need not be a single indicator for signaling. The trust level indicator may consist of trust level indicator elements, which are determined by the nodes when the SIP message traverses various nodes to the destination in the IMS network. Added to gender level indicator. As shown in FIG. 4B, the trust level indicator 403 is added by the P-CSCF, including a trust level indicator element TL1 404 that describes what type of confidentiality and integrity protection is being used. May be. The S-CSCF may add a trust level indicator element TL2 405 that describes the authentication mechanism that has been applied. The interconnect function may add a trust level indicator element TL3 406 that identifies the network from which the SIP message was received. In this way, a confidence level indicator 403 is constructed as the SIP message 401 traverses various nodes before arriving on the IMS network.

  FIG. 5 of this document schematically illustrates a node used in a communication network according to one embodiment of the present invention. Node 501 comprises a receiver 502 for receiving a SIP message, and a processor 503 for analyzing the received SIP message and modifying the SIP message to include it in a credibility level indicator. The processor may access the database 504 to obtain information to include in the confidence level indicator. This database may be located at a remote location or may be located within a node. Also, information about the confidence level indicator may be received from other collection sources not shown in FIG. The database 504 may also include a mapping database that maps the confidence level indicator to a security policy to be applied when the SIP message includes a given confidence level indicator. . For cases where the message does not terminate at that node, node 501 further includes a transmitter 505 for forwarding the modified SIP message. Node functions may be present on any or all nodes that process messages, including user equipment, application servers, call session control functions, and boundary or interconnect elements.

  The trust level indication in the SIP message may be used by a node in the IMS network to apply a security policy to any signaling associated with the SIP message. For example, a SIP message may be used to set up a media stream between two UEs, and a security policy may be applied to the media stream based on an indication of trust level in the SIP message. Good.

  A flow diagram of the basic steps of one embodiment of the present invention is shown in FIG. For the purpose of creating an indicator of trust level, trust level information is collected at the node (601). The node creates an index of trustworthiness level based on the collected information (602). Before the message is sent to the IMS node (604), a trust level indicator is applied to the new SIP message or added to the existing SIP message (603). The IMS node receives a SIP message from a node that may be in a different network than the node (605). The SIP message contains a trust level indicator, and the IMS node maps the indicator (which may be numeric or descriptive and may consist of multiple trust level indicator elements) to the security policy. (606). A security policy is then applied to the message and associated signaling (607), as determined by the trust level indicator.

  Sometimes IMS network operators have roaming and interconnection contracts with other IMS operators. In this case, the IMS operator may ensure that any traffic received from or via other IMS operators has at most an agreed trust level, or another way of saying Then, agree on trust levels with other IMS operators to have a guarantee that a set of defined security mechanisms has been applied. In the case of a roaming partner, for example, if a P-CSCF is assigned to a user by the other operator, the other operator's network may not support the same security mechanism. In such an environment, when users are roaming, they may be in a network that is given a lower trust level than their home network. Similarly, a user may be roaming in a visited network that gives the user's home network a low level of trustworthiness. In this case, either or both of the visited network and the home network may apply the security policy to signaling passing between the visited network and the home network. Additional information elements that are included in the trust level indicators by various network entities are used in the negotiation and enforcement of the correct trust level and consistent security policy.

There are several situations where a trust level indicator is used and a security policy can be enforced based on the trust level indicator. Examples of these are given below.
・ Indicators of reliability level are used to perform extensive filtering of incoming traffic at boundary elements or interconnection elements that enforce security policies across operators ・ Perform specific service operations on application servers (AS) A credibility level indicator is used to (or do not allow certain service operations). For example, if the application server believes that a message has a low level of trustworthiness, specific content filtering may be applied to see if the message contains any viruses, spam, etc. In addition, special premium services (eg, music downloads of DRM content) may be disabled to ensure that such content is sent only to “trusted” sources. The AS may act on behalf of the user to enforce the user-based policy, either to perform specific processing of incoming traffic at the end user's terminal, or to trust the incoming traffic to the end user A credibility level indicator may be used to either inform about the sex level. For example, an incoming call with a low trust level may be checked against a “spam” list, or may be blocked if the user wants to completely block such traffic.

  As illustrated in FIG. 7, if a SIP message traverses two regions, namely an “outgoing IMS network” 701 and an “incoming IMS network” 702, the routed region will receive all SIPs received from a certain region. Make static decisions about requests. If the trust level is below a certain level that was previously negotiated and defined in roaming and interconnection contracts, appropriate action is required. For SIP messages that do not have a fully trusted confidence level indicator, the appropriate action may be the removal of the P-Asserted-Identity header, topology hiding may be applied, or It may simply mean that SIP messages are not allowed. This requires that the boundary entity is given an agreement between the areas agreed upon, for example, when entering into roaming and / or interconnection agreements between operators.

  If the SIP request is allowed by the originating IMS network 701, the originating IMS network 701 adds a trust level indicator to the SIP request. When a SIP request is sent to another incoming IMS network 702, the incoming IMS network 702 checks the trust level indicator and it determines the minimum trust level agreed between the two networks. Guarantee that it is the same as or higher than. Also, the incoming IMS network boundary element may add additional credibility information, such as from which network it received the message. The user equipment (UE) 703 and other entities (e.g., application server (AS)) are then used to determine whether the information contained in the SIP request (e.g., P-Asserted-Identity header) should be trusted using the trust level indicator. )) The SIP request is routed to 704.

  If the outgoing IMS network 701 does not support the security mechanism indicated by the trust level indicator, the SIP request sent to the incoming IMS network 702 will not contain any trust information. The incoming IMS network 702 then makes a static decision as to which trust level should be given to the SIP request based on a roaming agreement or interconnection agreement with the outgoing IMS network.

  A special interconnect network 801 as shown in FIG. 8 may be used between two or more operators to route traffic to the correct incoming network (this is often all around the world). This is to avoid a one-to-one contract between operators). For example, two operators may be an operator of the home network 802 and another operator of the IMS network 803. In this case, it is advantageous for the different boundary elements 804, 805 to add an indication of the network from which the boundary element has received the message. By doing so, the incoming IMS network boundary element 804, 805 then ensures that the policy is used based on the received credibility information and what network the message has been traversed so far. Can do.

  The application server can also use an index of trustworthiness level. For example, if the user only wants to receive a SIP message given a certain trust level, a special subscription for the service based on the trust level indicator may be applied. Such a service could be implemented in the AS. The AS can retrieve the subscription information from the HSS 205 (or a trust level indicator is sent from the UE through the Ut interface) and the SIP request has a trust level lower than the trust level required by the user. If it has an indicator, the SIP request may be given special handling, for example, ignored, logged, rejected, forwarded to voicemail.

One example where this can be used is in a service that handles unsolicited communications (SPAM / SPIT filters), whereby various policies are subsequently dependent on the credibility level indicator of the received SIP message. May be applied. Examples of such policies are given below.
When a SIP message is received from an internet interconnection, always apply strict filtering, allow only incoming calls from user IDs in the white list configured by the user, and for incoming traffic Apply anti-malware detection-If a SIP message is received from an IMS network using NBA or Digest authentication, apply anti-malware protection to incoming packets and allow only a certain number of calls per minute Yes-No special security rules apply when SIP messages are received from an IMS network at a "trusted terminal" using IMS AKA

The UE may also use another usage of the reliability level indicator. Examples of such applications include:
Present the (derived) confidence level (for a particular IMS communication) to the user. The user can then decide whether to answer the phone (call) or ask the remote user multiple questions (ensures that the remote user is the “right” user. And can be used for outgoing calls)
• If the application allows it, perform additional authentication. • Filter the number of calls for presentation to the user, or transfer the call directly, eg to voicemail.

  If the UE is a gateway that handles multiple devices (such as a home IMS gateway or a residential gateway (RGW), see eg ETSI TS 187 003), which entity in the private network receives incoming requests Can be determined using an indicator of confidence level.

  There is now an awareness that within an IMS network, security and trust are homogeneous and completely reciprocal, and that the minimum security level is the least secure security mechanism allowed within an IMS network. is there. By introducing a trust level indicator into the IMS network, the entity handling the IMS communication can know how reliable the information received in the SIP message is. This limits the risk of nuisance communication and increases the probability of adopting IMS because services that require a security architecture have security. This also ensures that the current symmetric security level (ie that the two communicating parties must trust each other at the same level) can be avoided.

  Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be construed as implying that any particular element, step, range, or function is essential and must be included within the scope of the claims. The scope of patented subject matter is defined only by the claims. The degree of legal protection is defined by the words spoken in the allowed claims and their equivalents.

Claims (17)

A method of handling credibility in an IP multimedia subsystem network comprising:
A session initiation protocol including an index indicating a reliability level of communication transmitted from a remote node registered in a different network to a node of the IP multimedia subsystem at a node in the IP multimedia subsystem network Receiving a message from the remote node;
Applying a security policy determined by the indicator to the message;
A method comprising the steps of: The method of claim 1, further comprising applying the security policy to all signaling associated with the session initiation protocol message. The indicator is a numerical value,
The method according to claim 1 or 2 , further comprising the step of mapping the numerical value to a security policy. The indicator is a description;
The method of claim 1 or 2 , further comprising the step of mapping the description to a security policy. The indicator includes a plurality of indicator elements,
The method of claim 4 , wherein each of the plurality of indicator elements is associated with a trust level of another node in a signaling path between the remote node and the node. 6. The method according to claim 5 , wherein the indicator element includes information indicating a network from which the SIP message is transmitted. The trust level indicator is determined according to information selected from one of a user terminal type, an encryption type, a network type, a node type, an end-user authentication mechanism, and an in-region security mechanism. 7. A method according to any one of claims 1 to 6 , characterized in that The applied security policy includes removing P-Associated Identity headers, applying topology concealment, not allowing the communication, allowing the communication without modification, and a database regarding acceptable message sources. The method according to any one of claims 1 to 7 , characterized in that it is selected from filtering the message according to: and applying malware detection to incoming signaling associated with the SIP message. the method of. The security policy, boundary element, application server, a user device, and a method according to any one of claims 1 to 8, characterized in that it is applied in one of the call session control function. A node for use in an IP multimedia subsystem network comprising:
A receiver that receives from the remote node a session initiation protocol message that includes an indication of a confidence level of communication sent from a remote node registered in a different network to a node of the IP multimedia subsystem;
Applying a security policy determined by the indicator to the message;
A node characterized by comprising: The node is a node according to claim 10, wherein the user equipment, the call session control function, the boundary elements, and be selected from one of the application server. A node for use in a communication network,
A means of collecting confidence level information;
A processor that generates a trust level indicator based on the trust level information and modifies the session start protocol message such that the session start protocol message includes the trust level indicator;
A transmitter for transmitting the session initiation protocol message;
A node characterized by comprising: The processor adds a trust level indicator element associated with the trust level of the node or the network in which the node is located to an existing trust level indicator in a session initiation protocol message. The node of claim 12 , wherein the node is configured to modify the existing confidence level indicator. The node according to claim 12 or 13 , wherein the node is selected from one of a user equipment, a call session control function, a boundary element, and an application server. A method of handling credibility in an IP multimedia subsystem network comprising:
Collecting trust level information at a network node;
Creating a confidence level indicator from the collected confidence level information;
Adding the trust level indicator to a session initiation protocol message;
A method comprising the steps of: The method of claim 15 , wherein the trust level indication is added to a new session initiation protocol created by the network node or an existing session initiation protocol received by the network node. The trust level information is based on any of database information, user terminal type, encryption type, network type, node type, end user authentication mechanism, and in-region security mechanism. The method according to claim 15 or 16 .

Images