Institutionen för datavetenskap

Transcription

1 Institutionen för datavetenskap Department of Computer and Information Science Final thesis Threat Analysis of Video on Demand Services in Next Generation Networks by Rickard von Essen LIU-IDA/LITH-EX-A 09/052 SE 9 december 2010 Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping

2

3 Linköping University Department of Computer and Information Science Final thesis Threat Analysis of Video on Demand Services in Next Generation Networks by Rickard von Essen LIU-IDA/LITH-EX-A 09/052 9 december 2010 Supervisor: Examiner: Anders Weiland Attentec AB Nahid Shahmehri Dept. of Computer and Information Science at Linköping University

4

5 LINKÖPING UNIVERSITY ELECTRONIC PRESS På svenska Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida In English The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: c Rickard von Essen

6

7 Abstract IP Multimedia Subsystem (IMS) is the next generation of telecommunication systems. The system is based on an IP network and uses technologies from the Internet. The IMS system is designed to evolve from a telephone system into a general information and communication system. It is meant to include television, Video on Demand (VoD), interactive services etc, etc. It is designed to simplify the implementation of new services in telecom networks. This report investigates security aspects of VoD services when merging an IP Television (IPTV) system with IMS. The investigation covers security functions in IMS, transition solutions for authentication of the Set-Top-Box (STB) in IMS, and identifies problems in the integration of IPTV and IMS. The report concludes that IMS has good solid Authentication, Authorization, and Accounting (AAA) functions that will provide security and billing functionality. One problem is found in the media control between the STB and the streaming server. This interface lacked specification at the time of investigation, and some problems have been identified. These problems have to be solved before a system can be brought into service and be regarded as secure. Keywords: Threat analysis, Security, NGN, IMS, SIP, UE, IPTV, STB, VoD, AAA, RTSP, Threat tree, Authentication, IPsec

8

9 Acknowledgements This thesis would not have been what it is without the contributions of a number of people who deserve to be acknowledged. There are a few people that have directly affected the content of this thesis report, most of all my supervisors Anders Weiland and Åsa Detterfelt who gave me the opportunity to do this thesis work and guided me into the world of consulting. Both of them deserve many thanks. And of course my first examiner Claudiu Duma, previously at LiU and my final examiner Nahid Shahmehri, ADIT, LiU both for their valuable knowledge and their guidance through out the completion of my work. Without their help and effort this report would never have been possible. I also want to thank Henrik Carlsson at Motorola for introducing the topic of the thesis and for his valuable insights in real-world IPTV systems. He also deserves gratitude for helping out with the sometimes complicated jungle of embedded systems. Among my colleagues Stefan Östergaard deserve a special acknowledgment for his help with getting into the world of IMS, and for always providing fast and accurate answers to my questions. He also provided valuable input on how to complete a thesis in general, with his own fresh experience. And finally I am forever grateful to my grandmother for giving me my first home computer, a Sinclair XZ Spectrum 1 in the Christmas of This gift made me discover the world of computer science. 1

10

11 Innehåll Figurer Tabeller xiii xv 1 Introduction Background Purpose Scenario Use Case Constraints IMS STB Billing and Security Goal Problem Description Method Limits Target Audience Outline of the Report I Theoretical Background 7 2 IPTV IP Television Common configuration Multicasting MPEG-TS RTSP Future SIP Session Initiation Protocol User Agents Servers Location Servers SIP Methods SIP Response Codes SDP Authentication ix

12 x INNEHÅLL 3.8 Register Invite Basic Network Media Service RTP/RTCP IMS IP Multimedia Subsystem Overview CSCF Call Session Control Function HSS Home Subscriber Server AS Application Server PEP/PDF CCF/OCS ISIM Reference Points Gm Mw Cx ICS Sh Ro Security Introduction Attacks on Communication Man-in-the-middle Replay DoS Denial of Service Basic cryptography Symmetric cryptography Asymmetric cryptography Cryptographic Signatures SSL/TLS IPsec Transport and Tunnel Mode ESP Encapsulating Security Payload SIP Security IMS Security NDS/IP Network Domain Security IP AKA Authentication and Key Agreement Diameter Risk Analysis Secure Vocabulary Overview Asset Vulnerability Threat Attack Countermeasure

13 INNEHÅLL xi Risk Peltier s Ten Step Method Step 1: Develop a Scope Statement Step 2: Assemble a Quality Team Step 3: Identify Threats Step 4: Prioritize Threats Step 5: Threat Impact Step 6: Risk Factor Determination Step 7: Identify Safeguards and Controls Step 8: Cost-Benefit Analysis Step 9: Rank Safeguards in Recommended Order Step 10: Risk Assessment Report Threat Tree Threat Analysis of NGN IMS II Investigation 39 7 Adapted Risk Analysis Method Goal What is a Risk Analysis Foundation Overview Adapted Risk Analysis Method Step 1: Define the Scope of the Analysis Step 2: Assemble the Quality Team Step 3: Identify Assets Step 4: Identify Threats Step 5: Refine Threats Using Threat Trees Step 6: Assign Probabilities and Impact to Leaves Step 7: Calculate Risk Factors Step 8: Identify Safeguards and Controls Step 9: Cost-Benefit Analysis Step 10: Rank Proposed Safeguards Step 11: Risk Assessment Report Purpose Discussion Threat Analysis Method Description of System Boundaries of the Analysis Threat Analysis Step 1: Scope Statement Step 2: Assemble a Quality Team Step 3: Identify Assets Step 4: Threats Step 5-8: Refine Threats Using Threat Trees False Authorization

14 xii INNEHÅLL Unauthorized Media Access Traffic Snooping Free Service Access Incorrect Billing Step 9: Cost-Benefit Analysis Step 10: Rank Proposed Safeguards Step 11: Risk Assessment Report Different Authorization Methods Hardware ISIM Software ISIM Bluetooth Pass-through Billing Through Another UE IRG IMS Residential Gateway Secure Processor Step 10: Rank Proposed Safeguards Hardware ISIM Secure Processor Software ISIM Gaps in IMS IPTV Integration SIP RTSP Handover III Conclusions Conclusions Recommendations General IMS Security STB/UE Core Network Gaps in IMS IPTV Integration RTSP Security Discussion Validity Further Studies Security Litteraturförteckning 75

15 Figurer 1.1 Activity diagram for the default use case A schematic view of an IPTV network A basic use case for SIP A setup of a session RTP and RTCP An RTP package is encapsulated in a UDP datagram Overview of IMS entities Reference points in IMS IPsec Transport and Tunnel Modes IPsec Transport Mode[16] IPsec Tunnel Mode[16] IPsec ESP[16] Registration with Authentication and Key Agreement (AKA) UML diagram for the vocabulary of risk analysis.[5] A common notation for threat trees Threat tree showing the notation used in this thesis The model of the system used for the risk analysis Activity diagram for the default use case Sequence diagram for the default use case. The IMS core network is simplified to the nodes CSCF and OCS Threat tree for a false authorization Threat tree for unauthorized media access Threat tree for traffic snooping Threat tree for free access to services Threat tree for incorrect billing Hardware ISIM card in the STB Software emulation of an ISIM card Bluetooth pass-through from mobile phone to STB Billing trough another UE IMS Residential Gateway IRG xiii

16 xiv FIGURER 9.6 Secure Processor IMS/IPTV control channels for VoD

17 Tabeller 2.1 An RTSP SETUP example SIP Methods SIP Response Code Classes[44] An SDP offer example[44] An SDP answer example[44] Basic threats in the IPTV system Example of SIP and RTSP setup of video session xv

18 xvi TABELLER

19 Kapitel 1 Introduction This chapter gives an introduction to the thesis work with a short background and problem description. It also defines the goal, limitations and method of the thesis work. 1.1 Background Traditionally, communication networks have been built to support one type of service. During the evolution of communication services the demand for better services has increased, and this increases the cost of the network. At the same time, competition has decreased the price of these services. This has lowered the Average Return Per User (ARPU) and has increased the network to service cost ratio. To cope with the demand for better services and to lower the cost for the network, service providers have begun to investigate converging networks into a common infrastructure delivering multiple services. This will increase the revenues from the services and offer new possibilities of combined and complex services. One fast growing service is IP Television (IPTV), this is television sent over an IPconnection which provides many advantages over normal air broadcasted, cable or satellite TV. The most important advantages are the availability of an unlimited channel space, two way communication, and support for personalized content based on the preferences of the viewer. One of the most important IPTV services will be Video on Demand (VoD), i.e. the ability to buy content directly by using a remote control. This could change the role of television from a passive medium to an interactive medium. The prime candidate for a standard for a converged communication network is the IP Multimedia Subsystem (IMS)[43]. IMS is standardized by the 3rd Generation Partnership Project[1] (3GPP) which is also behind the current Third Generation (3G) mobile system; Universal Mobile Telecommunication System (UMTS). The IMS system is a part of UMTS and it reuses most of its protocols from the Internet standard organization Internet Engineering Task Force[19] (IETF). The main function of IMS is to route calls but it is also a profound base for different services. Because of this, the system receives attention from more than just telephone service actors. 1

20 PURPOSE 1.2 Purpose There is a growing interest among Triple Play 1 actors for the IMS Next Generation Network (IMS NGN) which is a variant of IMS that focuses on a wider use of IMS. It focuses on providing a service platform in fixed access networks, such as Digital Subscriber Line (xdsl) and Fiber To The Premises (FTTP), to give fixed broadband access to an IMS network. These will deliver a multitude of services including telephony, TV, and Internet. [45] IPTV is one of the major services in an IMS NGN network, without it the deployment of such a network is of much less value. To be able to use on-demand services in an IPTV/IMS network it has to be reasonably secure to allow the service provider to charge for the services. The purpose of this thesis work is to investigate the security of such a network and to provide useful input for developers of a Set-Top-Box (STB) on which technologies to use and what threats there are that have to be addressed to build a secure IPTV/IMS system. 1.3 Scenario The system I investigated consists of an IMS (home-) network, an STB and a streaming server. The complete network is under the control of the IPTV/IMS service provider Use Case The basic scenario to investigate is when a user powers up the STB that is connected to an IMS system and selects a video to watch. The user is charged for the service on his account. The activity diagram for this use case is shown in figure 1.1. The system requires that the subscriber has the correct credentials present in the STB as described in 1.6. The scenario does not specify any certain business model for billing or any restriction on the contents the user can access. 1.4 Constraints There are some constraints on the system investigated. These are given by Motorola to constrain the investigation to a setup that is interesting to them to develop IMS IMS should be used for Authentication, Authorization, and Accounting (AAA). The IMS system has a security architecture that should be used to the greatest possible extent. This leads to easier administration and has the advantage of a well known security architecture. 1 Triple Play Using a single connection to provide phone, TV and Internet

21 KAPITEL 1. INTRODUCTION ActivityDiagram DefaultUseCase OrderMovie 3 Authorization? Register OrderMovie Suceded Failed FailedSuceded ChargingforService P ermisioncontrol? Checkfunds? Notenough MovieStreamStarts Enough WatchMovie Figur 1.1: Activity diagram for the default use case STB The STB should be able to send requests for VoD services to IMS using SIP signaling through a common API. UE s have a single way of communicating with IMS, they only differ in their capabilities, such as connection speed, screen resolution, input methods, etc (see 4) Billing and Security The most important aspect of this thesis is to investigate a secure technology for billing. This should be done by evaluating the existing security methods in IMS and by considering

22 GOAL each modification required to add the STB into the IMS system. 1.5 Goal This thesis should present a well investigated solution to incorporating an STB in an IMS network with functions for handling VoD services in a secure way. A threat analysis will show what threats the system has to be protected from. The conclusion should present an evaluation of different technologies for authentication and weaknesses in the current specification.

23 KAPITEL 1. INTRODUCTION Problem Description The problem can be specified as follows: Is it possible to, in a secure way, use an STB to connect to an IMS system and order VoD services? This requires a definition of the word secure. I choose to use the following definition: Using the same security features as IMS does to achieve security. This does not explain what is secure, it just declares that if 3GPP uses the same security features in an equivalent scenario it will be regarded as secure. To answer the question it is refined into two smaller questions: Which technologies can be used for authentication? Are there any security gaps in merging IPTV and IMS? 1.7 Method To solve the problem, a structured method will be used. First I will investigate how an IMS and IPTV system works. Then a threat analysis method will be chosen and adapted to suit the specific needs of the task. With the help of the threat analysis, countermeasures can be evaluated and weak points in the system can be identified. Different technologies for authentication will be evaluated to answer these question for each of the technologies: 1. Is the technology acceptably secure? 2. What are the advantages and drawbacks of the technology? These two questions go hand-in-hand, since what is acceptable in one system or stage of deployment may not be acceptable in a later stage or in another system. This information will help guide a system designer to choose the correct solution depending on different demands on the architecture, usability, business model and legal demands. 1.8 Limits This thesis focuses on using IMS for billing of VoD services in an IPTV network. Other types of Pay-Per-View (PPV) will not be considered. Furthermore the confidentiality of the media stream will neither be taken into account. Since a VoD media stream is singelcast it can be solved with encryption without much difficulties on the client side. 1.9 Target Audience This report is intended to be read by developers with a basic knowledge of SIP/IMS, IPTV and a good understanding of modern security technologies. The thesis will present a basic overview of IPTV, IMS and security techniques. To fully understand the topic the reader should have more knowledge especially in the areas of IMS and security.

24 OUTLINE OF THE REPORT 1.10 Outline of the Report The outline of the thesis is: Part I Theoretical Background 2. IPTV: Describes IPTV systems and the technology used today. This system is one of the base parts in this thesis. 3. SIP: SIP is the signaling protocol in IMS and very important to understand how connections are established in IMS. 4. IMS IP Multimedia Subsystem: IMS is a complex system but an overview of the system is given in this chapter. It describes the parts necessary to understand the problems investigated in this thesis. 5. Security: This chapter mostly serves as a reminder for the user. It is not on its own enough to present all important aspects of information security. 6. Risk Analysis: Describes the basics of risk analysis used in this report. Part II Investigation 7. Adapted Risk Analysis Method: An adapted risk analysis method is used to analyze the risks in the system. This is used to structure and break down the complex problem. 8. Threat Analysis: This sections contains the analysis of threats to the system. These are presented in section 8.3 and are used to evaluate the different authorization methods in the next section. 9 Different Authorization Methods: Presents some authorization methods that could be used in the STB. It uses results of the threat analysis to evaluate different alternatives of authorization. 10 Gaps in IMS IPTV Integration: Describes problems with specifications and integration between an IMS system and IPTV. This section does not cover this topic, but rather pointing out the problems found by the author. Part III Conclusions

25 Del I Theoretical Background 7

26

27 Kapitel 2 IPTV IP Television IPTV is TV broadcasted over an IP network. The main advantage is that instead of building and maintaining a special network for cable TV it can be combined with a normal IP network used for Internet access. This gives opportunities for advanced TV services, such as web browsing, , Electronic Program Guides (EPG), and Video on Demand (VoD). There is no standard for IPTV networks and transmission, but the general setup is common and most protocols for the network are well known standard protocols. The network is always under control of the service provider who has to be able to guarantee Quality of Service (QoS). The transmission starts at the Video Head End (VHE), which is a streaming server receiving video feeds from satellite or cable, and encodes and compresses it into a digital video stream. The transmission could also start in a VoD server streaming video to customers. These video streams are stored in the server. 2.1 Common configuration A common configuration of an IPTV network is shown in figure 2.1. The figure shows the backbone which connects all local networks with a high bandwidth connection. At the backbone there is a live feed server that captures, encodes and streams live video over the network. This server captures the video from some external source such as satellite or a cable-tv connection. It uses multicast to transmit channels to viewers. Commonly there is also an application server that supplies customers with mostly non-video services, such as web browsing, and content information. Finally there is a VoD server storing video for distribution by unicast to customers on demand. The backbone is connected to the local networks through at least one layer of routers. Since the VoD media is unicasted, the VoD server and the network would soon be overloaded if many customers used VoD at the same time. To solve this there are caching servers closer to the customer that cache VoD contents that pass the network. The next time a customer accesses the VoD contents the VoD server can delegate to the caching server to provide it. 9

28 COMMON CONFIGURATION Figur 2.1: A schematic view of an IPTV network Multicasting Multicast is to send one-to-many, this is vital for live transmissions of TV in an IP network. This gives the VHE the ability to send a stream for one channel to every subscriber that watches that particular channel. If normal unicasting where to be used the VHE had to set up a stream to every viewer. This would make up-scaling of the network impossible and in reality make it unprofitable to build IPTV networks. Since VoD does not use multicast, no further information will be given on this topic even though it is vital for live feeds in IPTV networks MPEG-TS The most common way to transport live video media in an IPTV network is to use Motion Pictures Expert Group (MPEG)[40] version 2 or 4. The stream is actually an MPEG Transport Stream (MPEG-TS) that runs on top of UDP and encapsulates the media in small 188 byte datagrams[15] RTSP The Real-time Streaming Protocol (RTSP)[21] is used as a remote control for a video stream. It can be used to setup feeds, play, pause, forward and record. This is mostly used for VoD services where these functions make sense but it could also be used for remote recording of a live feed to a server for later viewing.

29 KAPITEL 2. IPTV IP TELEVISION 11 C S: S C: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port= RTSP/ OK CSeq: 302 Date: 23 Jan :35:06 GMT Session: Transport: RTP/AVP;unicast;client_port= ; server_port= Tabell 2.1: An RTSP SETUP example Since the topic for this thesis is VoD we go into some detail on RTSP. RTSP is mostly used on a reliable transport protocol, normally TCP. It uses commands and responses similar to HTTP to make it possible to use an HTTP parser to build an RTSP server. In contrast to an HTTP server an RTSP server is not stateless, it has to maintain a state for each connected client. The central commands in RTSP are: DESCRIBE is used to get parameters for a stream such as type, bitrates, encoding, and decryption keys. Describe uses SDP to describe the session, see section 3.6 for information on SDP. SETUP is used to order a stream, with a specific set of parameters. PLAY/RECORD can be issued after a successful SETUP has been executed. This orders the server to start the stream or to connect to the stream and start recording it. PAUSE stops the streaming but keeps the current state in the RTSP server. If a PLAY/RECORD command is issued after PAUSE without arguments the playing/recording is continued from the same place as it was paused. TEARDOWN is used to close a connection. This is important since it allows the RTSP server to free the resources reserved for the connection. To show some important properties of RTSP we look a bit closer at the setup and play commands. An example setup and response is shown in table 2.1. RTSP can use the HTTP basic authentication or HTTP digest authentication mechanisms [23]. It can also be used with security from the network layer, e.g. IPsec[35]. 2.2 Future IPTV is quite a new technology for distributing TV. It has been built without standardization or common technology. To successfully continue to develop and deploy these systems they have to be based on an open standard. IPTV is mostly deployed by companies also providing phone and

30 FUTURE Internet services to their customers and the demand for a converged network from the service providers is strong.

31 Kapitel 3 SIP Session Initiation Protocol Session Initiation Protocol (SIP)[27] is a protocol for setting up media streams between two parties. The protocol was originally intended for setting up audio and video calls over an IP network, but since it is so flexible it can be used to setup any type of stream. SIP is a signaling protocol used for Voice-over-IP (VoIP) and general signaling in IMS systems. As such it is one of the basic building blocks of the next generation of IP based telephone systems. There are three types of elements in SIP: User Agents (UA), Servers, and Location servers. A basic use case of SIP is shown in figure 3.1. SIP users are identified by their Figur 3.1: A basic use case for SIP. SIP URI. It is similar to an address but is proceeded by sip:// or sips:// for transport layer encrypted connections, e.g. sip://adam@nosite.com. 3.1 User Agents UA s are the end devices in the SIP network. They communicate with each other through zero or more SIP servers. A UA may be a mobile phone, software phone, or a traditional wired phone in a Public Switched Telephone Network (PSTN) calling through an SIP gateway. It could also be a voice mail server which acts on behalf of an unregistered or busy UA. 13

32 SERVERS 3.2 Servers There are three types of SIP servers: SIP proxies, Redirect servers, and Registrar servers. An SIP proxy is a signaling only server which modifies and/or controls the passing SIP signaling. It is often used to enforce policies, for anonymizer services, or similar. A Redirect server is also a signaling only server. It answers the invite method with a redirection response (3xx). This is used to direct a caller to the correct UA where the callee is currently registered. A Registrar server is used by UA s to register their current status and location into the location server. This information is used by the caller to reach the callee by calling a redirect server. 3.3 Location Servers A location server[27] is a database containing information about users registered IP addresses, features, and other preferences. The UA does not directly communicate with the location server, this is done through a proxy, redirect, or a registrar server. These servers communicate with the location server in an unspecified way and act as an SIP front-end for the location server. 3.4 SIP Methods SIP uses plain text message methods similar to HTTP[22] and Simple Mail Transfer Protocol (SMTP)[26]. The most common SIP methods are shown in table 3.1. The first six are defined in the basic RFC[27], the rest of the methods are extensions to SIP. Method RFC Description INVITE RFC3261[27] Session setup ACK RFC3261 Acknowledgment to INVITE BYE RFC3261 Session termination CANCEL RFC3261 Abort session REGISTER RFC3261 Register a user s URI OPTIONS RFC3261 Query of options and capabilities INFO RFC2976[25] Midcall signaling transport PRACK RFC3262[28] Provisional response acknowledgment REFER RFC3515[31] Redirect user to another URL SUBSCRIBE RFC3265[29] Request notification of an event NOTIFY RFC3265 Notification of an event MESSAGE RFC3428[30] Instant message body Tabell 3.1: SIP Methods

33 KAPITEL 3. SIP SESSION INITIATION PROTOCOL SIP Response Codes SIP uses a set of numeric response codes as response to each method sent. These response codes correspond to and extend the ones used in HTTP. The codes can be followed by a text string, the content of which is insignificant to the client and only used to simplify debugging. The response codes are divided into classes shown in table 3.2. Class 1xx 2xx 3xx 4xx 5xx 6xx Description Provisional or Informational: the request is progressing but not yet complete Success: the request has completed successfully Redirection: the request should be tried at another location Client Error: the request was not completed due to error in the request and can be retried when corrected Server Error: the request was not completed due to error in the recipient and can be retried at another location Global Failure: the request has failed and should not be retried again Tabell 3.2: SIP Response Code Classes[44] 3.6 SDP To negotiate the setup of streams SIP uses another protocol named Session Description Protocol (SDP)[37]. It is a special protocol for describing sessions and their parameters used by a number of different protocols. An SDP offer is shown in table 3.3. v is the version of the protocol, the current version is 0. c is the connection, with the arguments IN for Internet, IP4 for IP version 4, and finally the IP address. m is the media type, in this case there are two: one video and one audio. Each of them are followed by a port and two Real-time Transport Protocol/Audio Video Profile (RTP/AVP). a is the attributes: rtpmap maps an RTP/AVP to a codec e.g. RTP/AVP 14 is MPA with a sampling rate of 90000Hz. The callee answers with an SDP with a subset of the offered media sessions. In this particular example the GSM encoded audio is kept. But video is declined by specifying a zero (0) port number. SDP includes many more descriptors, these are just the basic ones needed for understanding and reasoning in the thesis. For any details the reader is directed to the RFC 4566[37]. SDP is also used by RTSP for session description, see section for more information.

34 AUTHENTICATION v=0 o= s= c=in IP t= m=video 4004 RTP/AVP a=rtpmap:14 MPA/90000 a=rtpmap:26 JBEG/90000 m=audio 4006 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 GSM/8000 Tabell 3.3: An SDP offer example[44] v=0 o= s= c=in IP t= m=video 0 RTP/AVP 14 m=audio 6002 RTP/AVP 4 a=rtpmap:4 GSM/8000 Tabell 3.4: An SDP answer example[44] 3.7 Authentication The specification for SIP[27] requires that it has some authentication mechanisms, these are inherited from HTTP. The most important one for this thesis is the HTTP digest authentication[23] that is used in IMS. See Register To be able to find the correct UA from an SIP URI the UA has to register its current location and status in the location service. By issuing a register method to a registrar server connected to the location server, the UA is registered. Later when a caller calls an SIP URI it starts by looking up the address to the server part of the URI. This lookup is done by Domain Name System Service (DNS SRV)[24]. The DNS SRV response gives a redirect server for the domain. The caller issues an invite to the redirect server. It answers with a redirect response, calling for a redirect to the UA previously registered by the user. Often the DNS SRV response directs the caller to a

35 KAPITEL 3. SIP SESSION INITIATION PROTOCOL 17 proxy server instead of a redirect server. 3.9 Invite The invite method is used to setup communication between two UA s. The caller, A, issues an invite to the callee, B. The invite includes an SDP with the available encodings and options that the caller wants to use. The callee s UA answers with trying and ringing. When the callee answers the call the UA sends an OK message including an SDP with the selected codec s and options. This is answered with an acknowledgment from the callers UA. After this the media streams negotiated by the exchange of SDP messages can begin. See figure 3.2. Figur 3.2: A setup of a session 3.10 Basic Network Media Service The request for media from an SIP media server is done by issuing an invite to the SIP URI with the user annc at the media server and with the parameter: play=[media URL][34]. E.g. sip:annc@ms2.example.net; \ play= This is useful since it limits the usernames needed for the media server and eases the load of the registrar server. If each media file were to be selected just by a username part of the URI, the media server would have to register each of them with the registrar server and renew them before they timed out. This could easily lead to overloading of the registrar,

36 RTP/RTCP Figur 3.3: RTP and RTCP Figur 3.4: An RTP package is encapsulated in a UDP datagram. e.g. an on-demand repository of music could collect millions of items that need to be re-registered, usually every hour RTP/RTCP Real-time Transport Protocol (RTP)[32] is a transport layer protocol for sending media streams over an IP-network. RTP is typically used on top of User Datagram Protocol (UDP)[20]. UDP lacks information important to a media stream, such as the datagram sequence in the stream and timestamps to keep the playback in real-time and to sync different streams. RTP implements these vital functions on top of UDP. It adds type information, sequencing, time stamping, and mixing information to the UDP datagram. Since RTP is a transport layer protocol it does not have a well defined port number, but an RTP-connection always uses an even port number to send its data. The odd port numbers are used for the Real-time Transport Control Protocol (RTCP)[32] that commonly accompanies an RTP-connection. The associated RTCP-connection uses the succeeding port number of the RTP port number which it is controlling. RTCP is mainly used to return feedback on the reception of the stream to the sending server.

37 Kapitel 4 IMS IP Multimedia Subsystem IP Multimedia Subsystem (IMS) is the service platform for the next generation phone systems, both fixed and mobile. By using this open standard on an IP based network, telecommunication will move towards using cheap and well known IP networks. IMS also adds functions to satisfy the strict QoS and Authentication, Authorization, and Accounting (AAA) (see 5.1) demands on a telecommunication network. The open standard ensures interoperability between operators and system providers. To speed up the development, IMS mostly uses well known protocols used on the Internet, specified by IETF. This will be the next big step for the telecom industry according to Ericsson [43], the world leading telecommunication system provider[13]. 4.1 Overview An IMS system is built in four layers: the Access network plane, the user plane, the control plane, and the application plane. The access network plane consists of a physical network infrastructure supplying IP connectivity. The access network can consist of RAN, WLAN, xdsl, or other types of IP able networks. Some of these access methods are not fully specified in IMS yet, but they are being investigated in Next Generations Network (NGN), and will eventually find their way into a release of IMS. The user plane transports the media between the different users. It consist of the logical connections between users. The control plane contains control signaling and enforces policies and security on lower levels of the network. It is also responsible for the QoS of the network. This is very important since it ensures that a standard best-effort IP network is usable as a telecommunication network with its strict QoS requirements. The two most important functions in the control plane are the Call Session Control Function (CSCF) and the Home Subscriber Server (HSS), see figure 4.1. There are more functions in the control plane but they are not crucial to the scenario in this thesis. At the top is the application plane where the Application Server (AS) and Online Charging System (OCS) reside. AS s implement different services for the users such as voice mail, teleconferencing etc. The IMS specifications do not define how each function works, it rather specifies reference points and how the functions communicate with each other. 19

38 CSCF CALL SESSION CONTROL FUNCTION AS OCS HSS Application Plane UE P-CSCF I-CSCF S-CSCF Control Plane Media Stream IPv6 Backbone User Plane Figur 4.1: Overview of IMS entities 4.2 CSCF Call Session Control Function The Call Session Control Function (CSCF) consists of three different functions, the Proxy CSCF (P-CSCF), the Interrogating CSCF (I-CSCF), and the Serving CSCF (S-CSCF). All UA signaling first passes the edge gateway, the P-CSCF, which directs the traffic to an I-CSCF or an S-CSCF. The P-CSCF is responsible for finding the correct I/S-CSCF and handles the security of the UE. The I-CSCF is the contact point for all SIP signaling from another operator s network destined to a UE in the I-CSCF s network. It is usually also responsible for hiding the topology of the operator s network from other operators by a function called Topology Hiding Inter-network Gateway (THIG). The S-CSCF is the function that actually handles the session. It routes the connection to its correct destination, controls the type of connection set up between UE s, takes care of registration etc.

39 KAPITEL 4. IMS IP MULTIMEDIA SUBSYSTEM HSS Home Subscriber Server The HSS maintains a database of all the subscribers, their setup, and their current registration state. This information is used by the CSCF s to route the signaling to the correct S/I-CSCF. The HSS also produces AAA vectors to be used by the network when authenticating itself and the UE. In an NGN IMS-network the HSS is called User Profile Server Function (UPSF) and has some additional capabilities; it is however functionally equivalent for the purpose of this investigation. 4.4 AS Application Server An Application Server (AS) provides the IMS system with a specialized service. Since they communicate with well defined protocols, the deployment time is short and they can be used in all IMS systems. This is one of the main advantages of IMS; by using an open platform it opens for competitive development of services that do not need to be tailored for each service provider. 4.5 PEP/PDF The Policy Enforcement Point (PEP) is an entity in the network that enforces policies. This is usually done by filtering the traffic. The Policy Decision Function (PDF) controls the network by controlling the PEP s. For example, S-CSCF can reserve QoS in a router for a call. Then the S-CSCF acts as a PDF and the router as a PEP. This is a complicated matter, but it is necessary in order to make the best-effort IP network to a strict QoS network acceptable for telecommunication services. 4.6 CCF/OCS There are two functions for charging (billing) in IMS: the Charging Collection Function (CCF) for offline charging and the Online Charging System (OCS) for online charging. Offline charging is classical charging where service usage is collected on a bill at the end of the month. Online charging is used when the user prepays for services by buying credits. When an OCS is used, the charging entity, e.g. an S-CSCF, reserves a certain amount of credits and deducts them as the service session continues. If the user runs out of credits the OCS notifies the charging entity which will terminate its service. OCS can also be used for traditional billing at the end of the month. 4.7 ISIM All UE in an IMS network will have a Universal Integrated Circuit Card (UICC) with an IMS Subscribers Identity Module (ISIM) function. The ISIM is an advanced version of the old Subscribers Identity Module (SIM) and the UMTS Subscribers Identity Module (USIM). It contains information regarding public and private user identity, home network

40 REFERENCE POINTS information, and administrative data. It also contains security keys used to calculate responses to authentication challenges and session keys. There will be more about this in section 5.7 IMS security. 4.8 Reference Points By tradition, all connections between different functional entities in telecommunications are assigned a name, usually consisting of two letters. The reference point is specified by its protocol and the messages that are sent through it. The reference points important for this thesis in a basic IMS system are shown in figure 4.2. Figur 4.2: Reference points in IMS Gm Gm is the reference point between the UE and the P-CSCF. It is used to send SIP messages to initiate services. This is probably the most important reference point since it is the one between the user owned UE and the service provider s core network. It cannot be physically protected since it should be possible to use in a mobile environment and to roam through other service providers networks. It also requires a high compatibility between P-CSCF s and different UE s in contrast to equipment within the core network which can be fine tuned to inter-operate.

41 KAPITEL 4. IMS IP MULTIMEDIA SUBSYSTEM 23 The Gm interface has three main categories of messages: registration, session control and transactions. Registration handles the authentication of the user and setup of the security on the reference point. The session control messages are used to initiate, setup, and terminate sessions. The transaction messages are standalone messages that carry for example Instant Messages (IM) that do not create a dialog Mw Mw is the reference point between the CSCF s which transmits SIP messages. The Mw reference point has the same classes of messages as the Gm interface Cx Cx is the reference point between I/S-CSCF and the HSS which uses the Diameter protocol ICS The IMS Service Control (ICS) is used between the I/S-CSCF and an AS. When an I/S- CSCF gets a session initiation request it analyzes it and if required routes it to an AS for further processing. Also, initial invites can originate from an AS in response to some external event. This could be an automated wake up call where the AS calls a subscriber on a requested time Sh An AS may need user information or parameters stored in the HSS. this is what the Sh reference point is used for. It uses the Diameter protocol to handle data and for subscription/notification. The HSS has a list of the AS s permissions to read and alter data Ro Online charging is done over the Ro reference point towards the OCS. It communicates over Ro using Diameter with AS s and S-CSCF s. The OCS can reserve, control and charge the user depending on the request from the peer.

42 REFERENCE POINTS

43 Kapitel 5 Security This chapter has a brief introduction to some security concepts and a description of some security technologies used by IPTV or IMS. 5.1 Introduction Security for services and communication is often divided into three properties Confidentiality, Integrity, and Availability (CIA). Confidentiality is the property that only authorized users can access the information. This is often enforced by Access Control (AC) and/or encryption, which only allows the holders of the key to read the information. Integrity is the property that only authorized users can modify and create the information. This is also enforced by AC and cryptographic signatures or sometimes with encryption. Availability is the property that ensures the availability of the service or the information. This requires good design of the services and networks, so that they are not easily exhausted of resources. To ensure the CIA-properties there have to be three systems or functions in a service or communication: Authentication, Authorization, and Accounting (AAA). Authentication it the function which identifies the user. It must exist an authentication system since it is the base of all security. This does not have to be a classic username and password system, it could be implicit, e.g. the holder of the secret key is authenticated by the ability to encrypt a message that the receiver can decrypt producing a meaningful message. Authorization is the system which determines if a user is granted or denied a resource. The authorization system enforces the access policies based on the identified user and the resource requested. Accounting is the system which logs activities. This information can be used in multiple ways, e.g. for billing, for monitoring attempts to breach security, and for monitoring legitimate users use of services and resources. 25