WO2009068115A1

WO2009068115A1 - Methods for secure sip signalling to a destination ip address being a cryptographi cally generated address (cga)

Info

Publication number: WO2009068115A1
Application number: PCT/EP2007/063103
Authority: WO
Inventors: Gonzalo Camarillo; Pekka Nikander
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-11-30
Filing date: 2007-11-30
Publication date: 2009-06-04

Abstract

The present invention relates to a method of secure signalling that includes requesting delivery of IP traffic to a destination IP address using the Session Initiation Protocol. The destination address is a Cryptographically Generated Address. The method includes obtaining a certificate at a requesting node, the certificate confirming that the requesting node is authorised by an owner of the destination IP address to request delivery to that address. The certificate is included in a Session Initiation Protocol message requesting the delivery of the IP traffic. The Session Initiation Protocol request is sent to a network node that is either a source for the IP traffic or controls such a source.

Description

METHODS FOR SECURE SIP SIGNALLING TO A DESTINATION IP ADDRESS BEING A CRYPTOGRAPHI CALLY GENERATED ADDRESS (CGA)

Technical Field

The present invention relates to a method of secure signalling in SIP messages, and more particularly to methods for enabling a network entity to know that a user is entitled to request the delivery of IP traffic to an IP address contained within a SIP message.

Background

The use of Session Initiation Protocol (SIP) signaling is widespread in a variety of communications systems and architectures. One example is the IP Multimedia Subsystem (IMS) architecture developed under the Third Generation Project Partnership (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.

Figure 1 illustrates schematically how the IMS 3 fits into the mobile network architecture. In the case of a General Packet Radio Service (GPRS) packet switched (PS) domain 1, user terminals access the network via GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio networks and the IMS 3). Users can also access the IMS 3 via a circuit switched (CS) access network through the CS domain 4, where the signal flows are controlled by a network of Mobile Switching Centre (MSC) servers 6. A media gateway (MG or MGW) 8b, controlled by a Media Gateway Control Function (MGC or MGCF) 8a, acts as the interface between the CS domain 4 and PS networks such as the PS domain 1, as well as the IMS 3.

The IMS 3 includes a core network 3a and a Service Network 3b. The IMS core network 3 a includes nodes that send/receive signals to/from the GGSN 2 and network nodes that include Call/Session Control Functions (CSCFs) 5. The IMS service network 3b includes Application Servers (ASs) 7 for implementing IMS service functionality. Application Servers 7 provide services to end-users, and may be connected either as end-points, or "linked in" between the session peers.

The IMS architecture makes it possible to deploy peer-to-peer applications where two or more users exchange data during a SIP session. Examples of such peer-to-peer applications include Multimedia Telephony (MMTeI), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc. The transport connection(s) is (are) negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points (user terminals).

SIP messages carry IP addresses which are used by IMS network entities for a variety of purposes. In particular, a SIP message may contain within its header fϊleds or its SDP part an IP address to which traffic (e.g. SIP messages or media data) is sent, this IP address not necessarily being the source address of the request message. However, the use of IP addresses in SIP messages can give rise to potential security problems resulting from abuse by a malicious third party (referred to below as an attacker). WO02/076060 describes how some of the problems associated with the use of IP addresses can be overcome by using a private key of a public-private key pair to create a cryptographically generated IP address (CGA).

The CGA created in this way overcomes some of the more fundamental problems associated with IP addresses, such as a denial of service attack or a falsification of registration bindings. However, the present invention is concerned with circumstances in which a further level of security is required. A SIP message may instruct the receiver of the message to send traffic (e.g. SIP messages, or media signals) to a particular IP address which may be a different address than the one from which the SIP message originates. This means that a first User Agent (UA) registered with an IMS network may send a SIP message to another UA instructing it to respond to a different address, which may or may not be an address of the first UA.

For example, in a SIP REGISTER message there is a contact header field, which binds an Address of Records (AoR) with a contact address. This means that the network will relay all SIP traffic addressed to the AoR to the contact address instead. However, as shown in the signal flows in Figure 2a, at step 201 a malicious third party attacker 20 could register the IP address of a victim 22 as the contact address. At step 202, a network registrar, such as a Serving-Call Session Control Function (S-CSCF) 24 in an IMS network, verifies the registration by sending a SIP 200OK message. Thereafter, as indicated at steps 203 and 205, whenever the S-CSCF 24 receives a SIP message addressed to the attacker 20, this will now be sent to the victim 22. If the attacker 20 were to subscribe to a service that sends a high volume of SIP messages, this could result in the victim 22 becoming flooded with these messages.

Another example is shown in the signal flows of Figure 2b. Here, at step 211, the attacker 20 sends a SIP INVITE message, used to establish a session, to another User Agent 26. The SIP INVITE includes a session description that specifies the IP addresses where media traffic is to be sent. In this case, the attacker 20 has placed an instruction into the session description in the SIP INVITE to send media traffic to the IP address of the victim 22. Once the User Agent 26 has replied to the SIP INVITE with a SIP 200OK message at step 212, and the attacker 20 has acknowledged this at step 213, then as the session progresses all the media traffic is sent to the victim 22.

It is an aim of the present invention to alleviate these problems.

Summary

According to a first aspect of the present invention there is provided a method of requesting delivery of IP traffic to a destination IP address using the Session Initiation Protocol. The destination address is a Cryptographically Generated Address. The method includes obtaining a certificate at a requesting node, the certificate confirming that the requesting node is authorised by an owner of the destination IP address to request delivery to that address. The certificate is included in a Session Initiation Protocol message requesting the delivery of the IP traffic. The Session Initiation Protocol request is sent to a network node that is either a source for the IP traffic or controls such a source.

In embodiments of the invention, the Cryptographically Generated Address has been generated using a public key of a public-private key pair of said owner, and the certificate contains the public key of the key pair and is signed with the private key. The certificate may include an identity of the requesting node, the Session Initiation Protocol request being integrity protected. The certificate may contain a public key of a public-private key pair owned by the requesting node, the method comprising signing the Session Initiation Protocol request with the private key of that key pair. Alternatively, the identity of the requesting node may be a Uniform Resource Indicator and the Session Initiation Protocol request further comprises a network-asserted identity. A timestamp may also be included in the Session Initiation Protocol request.

According to a second aspect of the present invention there is provided a method of authorising a Session Initiation Protocol request for the delivery of IP traffic to a destination IP address, received at a network node that is either a source for the IP traffic or controls such a source. The method includes confirming that the destination address is a Cryptographically Generated Address generated using a public key of a public-private key pair to which a certificate contained within the request pertains. The certificate is used to confirm that responsibility for the Cryptographically Generated Address has been delegated to the node at which the request originated by the owner of the address.

The confirming step may comprise verifying that a public key contained in the certificate corresponds to a private key used to sign the certificate. The using step may comprise verifying that the request has originated from the node identified in the certificate.

According to a third aspect of the present invention there is provided a method of enabling a requesting node to request delivery of IP traffic to a destination IP address using the Session Initiation Protocol. The destination IP address is a Cryptographically Generated Address. The method comprises generating a certificate to confirm that responsibility for the Cryptographically Generated Address has been delegated to the requesting node by an owner of the IP address. The certificate is provided to the requesting node for use with a Session Initiation Protocol message that includes a request for IP traffic to be delivered to the Cryptographically Generated Address. The method may include creating the Cryptographically Generated Address using a public key of a public-private key pair of the owner, including the public key of the key pair in the certificate, and signing the certificate with the private key prior to providing it to the requesting node.

Generating the certificate may include inserting an identity of the requesting node into the certificate. The identity of the requesting node may comprise a public key of a public-private key pair of the requesting node. The identity of the requesting node may comprise a Session Initiation Protocol Uniform Resource Indicator of the requesting node. Generating the certificate may further comprise including CGA Parameters data used to create the Cryptographically Generated Address.

Brief Description of the Drawings

Figure 1 is a schematic representation of a telecommunications network that includes an

IMS network;

Figures 2a and 2b are signal flow diagrams illustrating security problems that can arise in SIP signalling; and Figure 3 is a flow diagram of part of a method in accordance with an embodiment of the invention.

Figure 4 is a signal flow diagram illustrating a use of the invention.

Detailed Description

A SIP message may include instructions to send traffic to certain addresses such as the contact address described above in relation to Figure 2a or the IP address of a media gateway controlled by the entity generating the SIP message. To avoid the attacks described above, the recipient of a SIP message needs to be sure that the sender of the SIP message owns, or at least is allowed to use, the IP addresses to which traffic data, such as other SIP messages or media traffic, is to be delivered. In embodiments of the invention this is done by sending a certificate with the SIP message. The certificate enables a network node that receives the SIP message to validate the IP address. The certificate is generated using a public-private key pair, as will be explained further below.

IP addresses defined in IPv6 enable two or more parties to communicate securely over the Internet, as well as providing for mobile Internet access (mobilelP). MobileIP allows users to access the Internet on the move, for example using wireless mobile devices, roaming from one IP access node to another (connected for example to wireless LANs and cellular telephone networks).

IPv6 addresses are 128 bits in length. The first 64 bits of an address form a routing prefix which uniquely identifies the Internet access node (or so-called "local link") used by an IP terminal or host, whilst the last 64 bits form a host suffix which uniquely identifies the mobile terminal to the access node (or within the local link). The host suffix is referred to as an "interface identifier" as it identifies the host uniquely over the access interface. Typically, when a host registers with an access node, the host learns the routing prefix of the access node from an advertisement message sent from the access node. According to RFC3041 (IETF), a host then generates its interface identifier using a random number generated by the host. The host may additionally use a link layer address to generate the interface identifier, the link layer address being for example a MAC layer address used by the access network. WO02/076060 describes how a User can generate a cryptographic version of the interface identifier using a oneway coding function, such as a hash function, and provide this to another peer user, who can then verify that the User is the owner of the interface identifier part of the IP address. This provides a level of security to help prevent, for example, a denial of service attack, in which the attacker claims to be the owner of the IP address that the User wishes to use. However, the method disclosed in WO02/076060 essentially establishes secure use of an IP address in peer-to-peer communications, but would not necessarily prevent the attacker 20 using the victim's IP address in the session description of a SIP message to flood the victim 22 with data, as shown in Figures 2a or 2b. According to this invention it is proposed that, if a Requester sends a SIP message that includes an IP address to which data is to be sent, then this will only be acted upon by the receiver of the message if the Requester also provides a certificate that proves that the Requester owns, or is allowed to use, the IP address.

Referring to Figure 3, there is shown a method by which a Requester is able to obtain a certificate that will enable a network entity receiving a SIP message from the Requester to know that the Requester is permitted to use an IP address to which data is to be delivered. The term Requester is used here to refer to the entity that will be generating SIP messages that include within the session description part (or elsewhere, e.g. in the message header) the IP address to which data is to be delivered.

At step 31, the Receiver retrieves its public-private key pair, and creates an IPv6 address (CGA) using its public key. To do does this, the Receiver uses a modifier parameter. For example, the Receiver may need to generate many CGAs for different purposes, and each time it will use a different modifier parameter.

At step 32, the identity of the Requester to whom the receiving entity is going to delegate responsibility for its IPv6 address, is obtained. For example, this may be contained within a request sent by the Requester to be permitted to establish a session in which data will be sent to the Receiver. The identity is preferably the Requester's public key. However, other identities, such as the Requester's SIP Uniform Resource Indicator (URI), may be provided. At step 33 a certificate is generated by the Receiver and which contains the CGA, the Receiver's public key, and the identity (e.g. public key) of the Requester. In addition, the certificate includes a CGA Parameters data structure, which contains information, about how the CGA has been generated from the public key, including the modifier parameter used to create the CGA.

At step 34 the certificate is signed with the Receiver's private key and the signature appended to the certificate. Mechanisms for signing a certificate using a private key are well known. Finally, at step 35, the signed certificate is provided to the Requester. When the Requester wishes to request delivery of traffic to the delegated IP address, it generates an appropriate SIP message that contains the Receiver's IP address in the session description part of the message (or elsewhere), and then attaches the certificate to the SIP message in order to prove that the Requester is allowed to use the CGA. The SIP message is protected to provide integrity and replay protection. If the identity of the Requester in the certificate is in the form of the Requester's public key, then the Requester also signs the certificate with its private key. Alternatively, if the identity is in the form of the Requester's SIP URI, then if the network is the IMS, the IMS will append a network-asserted identity to the message. The entity receiving the SIP message can then compare the network-asserted identity with the SIP URI of the Requester. The SIP message may be further protected against a replay attack by including a timestamp.

Figure 4 illustrates the signal flows for the situation where a User named Bob 40 sends a SIP INVITE message at step 401 to another User Agent 42. The SIP INVITE message specifies the IP addresses m = CGAl where media traffic is to be sent. Here CGA 1 is the cryptographically generated address of a network entity. Attached to the SIP INVITE message is a certificate indicating that user Bob 40 is permitted to use the IP address CGAl.

When a network entity receives a SIP request to deliver traffic to an IP address, it first checks to see if the message contains a certificate for the requested delivery address. If no certificate is present, the network entity performs a default action, i.e. deliver or don't deliver. If the request does contain a certificate it performs the following steps. Firstly, it verifies that the Receiver's public key, contained in the certificate, corresponds to the private key used to sign the certificate so that it knows that the certificate has been generated by the owner of the CGA.

Next, the entity receiving the request verifies that the request has indeed originated from the delegated Requester, which it can do because the SIP message is integrity protected. For example this may be because the IMS provides the network-asserted identity of the requester corresponding to the SIP URI used in the certificate. Alternatively, where the Requester has signed the certificate with its private key, it can confirm that the Requester is the owner of the second public key contained within the certificate. At this stage, the receiving entity knows if the request is valid or not. If it is valid, it can commence delivering traffic to the requested delivery address, otherwise it can reject the request.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention. For example, in certain embodiments the certificate may be generated by an entity other than the Receiver, for example at the Requester, providing of course that this other entity has access to the private key of the Receiver.

Claims

1. A method of requesting delivery of IP traffic to a destination IP address using the Session Initiation Protocol, wherein said destination address is a Cryptographically Generated Address, the method comprising: at a requesting node, obtaining a certificate confirming that the requesting node is authorised by an owner of the destination IP address to request delivery to that address; including the certificate in a Session Initiation Protocol message requesting said delivery; and sending said Session Initiation Protocol request to a network node that is either a source for said IP traffic or controls such a source.

2. A method according to claim 1, wherein said Cryptographically Generated Address has been generated using a public key of a public-private key pair of said owner, and said certificate contains the public key of the key pair and is signed with the private key.

3. A method according to claim 1 or claim 2 wherein the certificate includes an identity of the requesting node, said Session Initiation Protocol request being integrity protected.

4. A method according to claim 3, said certificate containing a public key of a public-private key pair owned by the requesting node, the method comprising signing said Session Initiation Protocol request with the private key of that key pair.

5. A method according to claim 3 wherein the identity of the requesting node is a Uniform Resource Indicator and said Session Initiation Protocol request further comprises a network-asserted identity.

6. A method according to any of claims 3 to 5, further comprising including a timestamp to said Session Initiation Protocol request

7. A method of authorising a Session Initiation Protocol request for the delivery of IP traffic to a destination IP address, received at a network node that is either a source for said IP traffic or controls such a source, the method comprising: confirming that said destination address is a Cryptographically Generated Address generated using a public key of a public-private key pair to which a certificate contained within the request pertains; and using said certificate to confirm that responsibility for the Cryptographically Generated Address has been delegated to the node at which the request originated by the owner of the address.

8. A method according to claim 7 wherein the confirming step comprises verifying that a public key contained in the certificate corresponds to a private key used to sign the certificate.

9. A method according to claim 7 or claim 8 wherein the using step comprises verifying that the request has originated from the node identified in the certificate.

10. A method of enabling a requesting node to request delivery of IP traffic to a destination IP address using the Session Initiation Protocol, wherein the destination IP address is a Cryptographically Generated Address, the method comprising: generating a certificate to confirm that responsibility for the Cryptographically

Generated Address has been delegated to the requesting node by an owner of the IP address, and providing the certificate to the requesting node for use with a Session Initiation Protocol message that includes a request for IP traffic to be delivered to the Cryptographically Generated Address.

11. A method according to claim 10 and including creating the Cryptographically Generated Address using a public key of a public-private key pair of said owner, including the public key of the key pair in the certificate, and signing the certificate with the private key prior to providing it to the requesting node.

12. The method according to claim 11 or claim 12 wherein generating the certificate includes inserting an identity of the requesting node into the certificate.

13. The method of claim 12 wherein the identity of the requesting node comprises public key of a public-private key pair of the requesting node.

14. The method of claim 13 wherein the identity of the requesting node comprises a Session Initiation Protocol Uniform Resource Indicator of the requesting node.

15. The method according to any of claims 10 to 14 wherein generating said certificate further comprises including CGA Parameters data used to create the

Cryptographically Generated Address.