WO2009068115A1 - Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga) - Google Patents

Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga) Download PDF

Info

Publication number
WO2009068115A1
WO2009068115A1 PCT/EP2007/063103 EP2007063103W WO2009068115A1 WO 2009068115 A1 WO2009068115 A1 WO 2009068115A1 EP 2007063103 W EP2007063103 W EP 2007063103W WO 2009068115 A1 WO2009068115 A1 WO 2009068115A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
certificate
request
initiation protocol
session initiation
Prior art date
Application number
PCT/EP2007/063103
Other languages
English (en)
Inventor
Gonzalo Camarillo
Pekka Nikander
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/EP2007/063103 priority Critical patent/WO2009068115A1/fr
Publication of WO2009068115A1 publication Critical patent/WO2009068115A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/604—Address structures or formats
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • 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.
  • IP Multimedia Subsystem IP Multimedia Subsystem
  • 3GPP Third Generation Project Partnership
  • FIG. 1 illustrates schematically how the IMS 3 fits into the mobile network architecture.
  • GPRS General Packet Radio Service
  • PS packet switched
  • GSNs General Packet Radio Service
  • 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.
  • MSC Mobile Switching Centre
  • 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.
  • MGW Mobile Switching Centre
  • 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.
  • peer-to-peer applications include Multimedia Telephony (MMTeI), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc.
  • MMTeI Multimedia Telephony
  • PoC Push to Talk over Cellular
  • 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.
  • 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.
  • traffic e.g. SIP messages or media data
  • 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).
  • CGA cryptographically generated IP address
  • 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.
  • traffic e.g. SIP messages, or media signals
  • UA User Agent
  • a contact header field which binds an Address of Records (AoR) with a contact address.
  • AoR Address of Records
  • the network will relay all SIP traffic addressed to the AoR to the contact address instead.
  • a malicious third party attacker 20 could register the IP address of a victim 22 as the contact address.
  • 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.
  • S-CSCF Serving-Call Session Control Function
  • 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.
  • 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.
  • 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.
  • a method of requesting delivery of IP traffic to a destination IP address using the Session Initiation Protocol 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.
  • 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.
  • 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.
  • 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.
  • a method of enabling a requesting node to request delivery of IP traffic to a destination IP address using the Session Initiation Protocol 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.
  • Figure 1 is a schematic representation of a telecommunications network that includes an
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • the Receiver retrieves its public-private key pair, and creates an IPv6 address (CGA) using its public key.
  • CGA IPv6 address
  • 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.
  • 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.
  • URI Uniform Resource Indicator
  • 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.
  • 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.
  • 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.
  • the signed certificate is provided to the Requester.
  • 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.
  • 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.
  • FIG 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.
  • 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.
  • a network entity 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte sur une méthode sécurisée de signalisation consistant à demander la délivrance d'un trafic IP à une adresse de destination IP en utilisant un protocole d'initiation de session (SIP), ladite adresse de destination étant produite cryptographiquement. La méthode consiste à obtenir d'un noeud demandeur un certificat confirmant qu'il a l'autorisation du propriétaire de l'adresse de destination IP de demander la délivrance à cette adresse, ledit certificat étant inclus dans un message SIP demandant la délivrance du trafic IP. La demande de SIP est transmise à un noeud de réseau qui est soit une source de trafic IP, soit un élément de commande d'une telle source.
PCT/EP2007/063103 2007-11-30 2007-11-30 Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga) WO2009068115A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2007/063103 WO2009068115A1 (fr) 2007-11-30 2007-11-30 Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2007/063103 WO2009068115A1 (fr) 2007-11-30 2007-11-30 Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga)

Publications (1)

Publication Number Publication Date
WO2009068115A1 true WO2009068115A1 (fr) 2009-06-04

Family

ID=40019060

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/063103 WO2009068115A1 (fr) 2007-11-30 2007-11-30 Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga)

Country Status (1)

Country Link
WO (1) WO2009068115A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030084293A1 (en) * 2001-10-26 2003-05-01 Jari Arkko Addressing mechanisms in mobile IP
US20050071627A1 (en) * 2003-09-29 2005-03-31 Montenegro Gabriel E. Method and apparatus for facilitating cryptographic layering enforcement
US20050220095A1 (en) * 2004-03-31 2005-10-06 Sankaran Narayanan Signing and validating Session Initiation Protocol routing headers
US20060253704A1 (en) * 2005-05-03 2006-11-09 James Kempf Multi-key cryptographically generated address

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030084293A1 (en) * 2001-10-26 2003-05-01 Jari Arkko Addressing mechanisms in mobile IP
US20050071627A1 (en) * 2003-09-29 2005-03-31 Montenegro Gabriel E. Method and apparatus for facilitating cryptographic layering enforcement
US20050220095A1 (en) * 2004-03-31 2005-10-06 Sankaran Narayanan Signing and validating Session Initiation Protocol routing headers
US20060253704A1 (en) * 2005-05-03 2006-11-09 James Kempf Multi-key cryptographically generated address

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
AURA MICROSOFT RESEARCH T: "Cryptographically Generated Addresses (CGA); rfc3972.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 March 2005 (2005-03-01), pages 1 - 22, XP015009744, ISSN: 0000-0003 *
SEEDORF J: "Using Cryptographically Generated SIP-URIs to protect the Integrity of Content in P2P-SIP", June 2006 (2006-06-01), pages 1 - 9, XP002505819, Retrieved from the Internet <URL:http://www.informatik.uni-hamburg.de/SVS/archiv/papers/2006_Using_Cryptographically_generated_SIP-URIs.pdf> [retrieved on 20081127] *

Similar Documents

Publication Publication Date Title
US7574735B2 (en) Method and network element for providing secure access to a packet data network
TWI358930B (en) System and method for originating a sip call via a
US20040085949A1 (en) User equipment device enabled for sip signalling to provide multimedia services with qos
CA2605475C (fr) Ouverture de session a partir de serveurs d&#39;applications dans un sous-systeme multimedia ip
KR100940548B1 (ko) Ｓｉｐ 메세징을 이용하여 ｉｍｓ 네트워크 환경에서의 콜 연속성을 관리하는 시스템 및 방법
WO2003081431A1 (fr) Identite provisoire pour l&#39;authentification avec un protocole de lancement de session
JP2011511511A (ja) Ｉｐマルチメディアサブシステムにおけるメッセージハンドリング
KR100928247B1 (ko) 통신 네트워크들 간의 보안 통신을 제공하기 위한 방법 및시스템
US9420018B2 (en) End-to-end address transfer
JP2018503886A (ja) オペレータネットワークを介したブラウザベースのサービスの認証
US8345596B2 (en) Call control method for seamless mobility service
US9692835B2 (en) Method and apparatuses for the provision of network services offered through a set of servers in an IMS network
EP2011299B1 (fr) Methode et appareils de securisation des communications entre un terminal utilisateur et un proxy sip utilisant une association de securite ipsec
US20040203432A1 (en) Communication system
WO2009068115A1 (fr) Méthode sécurisée de signalisation sip à une adresse de destination ip produite cryptographiquement (cga)
KR20130041665A (ko) Ｇｒｕｕ 사용 가입자 간의 ｉｍｓ망에서의 ｓｉｐ 메시지 전송 방법 및 그 장치
Rajini VOIP in Peer-to-Peer using Session Initiation Protocol

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07847619

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07847619

Country of ref document: EP

Kind code of ref document: A1