System and Method for Determining Trust for SIP Messages

• US 20100262704A1
• Filed: 03/19/2010
• Published: 10/14/2010
• Est. Priority Date: 04/13/2009
• Status: Active Grant

• Current Assignee: Blackberry Limited
• Original Assignee: Research In Motion Limited (Blackberry Limited)
• Inventors: Allen, Andrew, Buckley, Adrian, Bakker, Jan Hendrik Lucas
• Granted Patent: US 8,407,354 B2
• Time in Patent Office: Days
• US Class Current: 709/229
• CPC Class Codes: G06F 11/2007 using redundant communication media
• CPC Class Codes: G06F 3/1203 Improving or facilitating administration, e.g. print management
• CPC Class Codes: H04L 2101/385 Uniform resource identifier for session initiation protocol [SIP URI]
• CPC Class Codes: H04L 51/212 using filtering or selective blocking
• CPC Class Codes: H04L 63/126 the source of the received data
• CPC Class Codes: H04L 65/1016 IP multimedia subsystem [IMS]
• CPC Class Codes: H04L 65/1073 Registration or de-registration
• CPC Class Codes: H04L 65/1101 Session protocols
• CPC Class Codes: H04L 65/1104 Session initiation protocol [SIP]
• CPC Class Codes: H04L 65/403 Arrangements for multi-party communication, e.g. for conferences data switching systems for conference H04L12/18; arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities H04M3/56; television conferencing systems H04N7/15
• CPC Class Codes: H04L 65/611 for multicast or broadcast systems for broadcast or conference H04L12/18; arrangements for broadcast or distribution combined with broadcast H04H20/00; arrangements for broadcast applications with a direct linkage to broadcast information or to broadcast space-time H04H60/00; selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS], H04W4/06
• CPC Class Codes: H04L 67/1095 Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: H04L 69/22 Parsing or analysis of headers
• CPC Class Codes: H04L 69/40 for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection management of faults, events, alarms or notifications in data switching networks H04L41/06
• CPC Class Codes: H04L 9/083 involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
• CPC Class Codes: H04W 12/10 Integrity

Abstract

A method for performing registration is provided. The method includes receiving a server timeout message, the server timeout message including at least a field set to a value equal to a value received during a first registration. The method further includes initiating restoration procedures by performing a second registration in response to receiving the server timeout message.

Claims

1. A method for determining if a message received from a node in an IP (Internet Protocol) Multimedia Subsystem (IMS) network can cause one or more actions to be performed, comprising:

a user agent (UA) receiving from the network node a message containing a trust indicator;

the UA determining whether the trust indicator matches trust information stored in the UA;

when the trust indicator matches trust information stored in the UA, the UA performing all actions typically associated with receipt of the message; and

when the trust indicator does not match trust information stored in the UA, the UA refraining from performing at least one action typically associated with receipt of the message.

2. The method of claim 1, wherein the trust indicator is a Uniform Resource Identifier (URI) of the network node that sent the message.

3. The method of claim 2, wherein the trust information is a plurality of URIs of trusted network nodes that are provided to and stored in the UA.

4. The method of claim 3, wherein the plurality of URIs are associated with the trusted network nodes by a URI parameter in a Session Initiation Protocol (SIP) message.

5. The method of claim 3, wherein the UA associates the plurality of URIs with the trusted network nodes by querying a data repository containing a plurality of URIs of trusted network nodes.

6. The method of claim 1, wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

7. The method of claim 1, wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

8. The method of claim 1, wherein the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA.

9. The method of claim 1, wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA, and wherein the UA retrieves the trust information from the location.

10. The method of claim 1, wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a subscription request made by the UA, and wherein the UA retrieves the trust information from the location.

11. The method of claim 1, wherein the trust information is provided to the UA as information related to a route over which a registration request made by the UA was routed.

12. The method of claim 11, wherein the information related to the route is included in at least one field in at least one of:

a SIP Path header;

a SIP Service-Route header; and

a new SIP header defined for including the information.

13. The method of claim 1, wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

14. A user agent (UA), comprising:

a processor configured to receive, from a node outside a trust domain in an IP (Internet Protocol) Multimedia Subsystem (IMS) network, a message containing a trust indicator, further configured to determine whether the trust indicator matches trust information stored in the UA, further configured, further configured, when the trust indicator matches trust information stored in the UA, to perform all actions typically associated with receipt of the message, and further configured, when the trust indicator does not match trust information stored in the UA, to refrain from performing at least one action typically associated with receipt of the message.

15. The UA of claim 14, wherein the trust indicator is a Uniform Resource Identifier (URI) of the network node that sent the message.

16. The UA of claim 15, wherein the trust information is a plurality of URIs of trusted network nodes that are provided to and stored in the UA.

17. The UA of claim 16, wherein the plurality of URIs are associated with the trusted network nodes by a URI parameter in a Session Initiation Protocol (SIP) message.

18. The UA of claim 16, wherein the UA associates the plurality of URIs with the trusted network nodes by querying a data repository containing a plurality of URIs of trusted network nodes.

19. The UA of claim 14, wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

20. The UA of claim 14, wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

21. The UA of claim 14, wherein the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA.

22. The UA of claim 14, wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA, and wherein the UA retrieves the trust information from the location.

23. The UA of claim 14, wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a subscription request made by the UA, and wherein the UA retrieves the trust information from the location.

24. The UA of claim 14, wherein the trust information is provided to the UA as information related to a route over which a registration request made by the UA was routed.

25. The UA of claim 24, wherein the information related to the route is included in at least one field in at least one of:

a SIP Path header; and

a SIP Service-Route header; and

a new SIP header defined for including the information.

26. The UA of claim 14, wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

27. A method for determining if a node outside a trust domain in an IP (Internet Protocol) Multimedia Subsystem (IMS) network can be trusted, comprising:

a user agent (UA) receiving a message from the network node;

the UA determining whether a trust indicator is present in the message;

when the trust indicator is present in the message, the UA performing all actions typically associated with receipt of the message; and

when the trust indicator is not present in the message, the UA refraining from performing at least one action typically associated with receipt of the message.

28. The method of claim 27, wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

29. The method of claim 27, wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

30. The method of claim 27, wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

31. A user agent (UA), comprising:

a processor configured to receive a message from a node outside a trust domain in an IP (Internet Protocol) Multimedia Subsystem (IMS) network, further configured to determine whether a trust indicator is present in the message, further configured, when the trust indicator is present in the message, to perform all actions typically associated with receipt of the message, and further configured, when the trust indicator is not present in the message, to refrain from performing at least one action typically associated with receipt of the message.

32. The UA of claim 31, wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

33. The UA of claim 31, wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

34. The UA of claim 31, wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.