study of security aspects for sip

8/13/2019 Study of security aspects for SIP

1/127

Study of security aspectsfor

Session Initiation Protocol

Jonas Kullenwall

LiTH-ISY-EX-3234-20022002-04-19


2/127


3/127

Study of security aspectsfor

Session Initiation Protocol

Master thesis

Division of Information TheoryDepartment of Electrical Engineering

Linkping University

Jonas Kullenwall

Reg nr:LiTH-ISY-EX-3234-2002

Supervisors: Anders Hellstrm Ericsson Infotech ABHans Hedbom Ericsson Infotech AB

Examiner: Viivke Fk LiTH

Linkping, 19 April 2002


4/127


5/127

Avdelning, InstitutionDivision, Department

Institutionen fr Systemteknik581 83 LINKPING

DatumDate2002-04-19

Sprk

Language

Rapporttyp

Report category

ISBN

Svenska/SwedishX Engelska/English

LicentiatavhandlingX Examensarbete ISRN LITH-ISY-EX-3234-2002C-uppsatsD-uppsats Serietitel och serienummer

Title of series, numberingISSN

vrig rapport____

URL fr elektronisk versionhttp://www.ep.liu.se/exjobb/isy/2002/3234/

TitelTitle

Analys av skerheten kring Session Initiation Protocol

Study of security aspects for Session Initiation Protocol

Frfattare Author

Jonas Kullenwall

Sammanfattning

AbstractThe objective with this thesis is to describe security mechanisms that are integrated or are proposedto be integrated with the Session Initiation Protocol (SIP). SIP is used for establishing, modifying,and terminating multimedia sessions over the IP network. This thesis is divided into two mainparts, where the rst part describes the implemented security mechanisms in SIP and the secondpart describes a number of proposed security mechanisms that may be implemented in SIP. At theend of the report there is a section that presents the scripts and results from different security teststhat were performed on two implementations of SIP. Apart from describing different security mech-anisms in the rst part of this thesis, this section also contains an analysis on how possible securitythreats against SIP may be used to launch different attacks. The analysis also describes how theseattacks may be prevented, if possible, by using the security mechanisms provided by SIP. The sec-ond part also contains an analysis section, which is focusing on nding the advantages and disad-vantages of using a specic security mechanism compared to a similar security mechanism that iscurrently used or has been used in SIP. In the last section of this thesis I present my conclusions anda summary of the results.

NyckelordKeywordSIP, security, signalling


6/127


7/127

Abstract

vii

AbstractThe objective with this thesis is to describe security mechanisms that are inte-grated or are proposed to be integrated with the Session Initiation Protocol(SIP). SIP is used for establishing, modifying, and terminating multimedia ses-sions over the IP network.This thesis is divided into two main parts, where the rst part describes theimplemented security mechanisms in SIP and the second part describes anumber of proposed security mechanisms that may be implemented in SIP. Atthe end of the report there is a section that presents the scripts and results fromdifferent security tests that were performed on two implementations of SIP.Apart from describing different security mechanisms in the rst part of thisthesis, this section also contains an analysis on how possible security threatsagainst SIP may be used to launch different attacks. The analysis alsodescribes how these attacks may be prevented, if possible, by using the secu-rity mechanisms provided by SIP.

The second part also contains an analysis section, which is focusing on ndingthe advantages and disadvantages of using a specic security mechanismcompared to a similar security mechanism that is currently used or has beenused in SIP.In the last section of this thesis I present my conclusions and a summary of theresults.


8/127

Abstract

viii


9/127

About the thesis

ix

About the thesisThis thesis was written at Ericsson Infotech AB in Karlstad during the lastmonth of 2001 and the beginning of 2002. It was supervised by Viiveke Fk atthe Department of Electrical Engineering at Linkping University.

About the authorMy name is Jonas Kullenwall and I am the author of this thesis. I have studiedthe Computer Science and Engineering programme during the last four and ahalf years. This project is the last step before I get my degree in Master of Sci-ence in Engineering. My prole during my studies has been Telematic, whichincludes telecommunication theory, cryptography and network security,image coding and computer networks. This thesis covers almost every one of these areas, so this thesis has been a great pleasure to write.I also hope that the knowledge I have gained during this project may be usefulin my future work.

Acknowledgements

I will like to thank my two tutors at Ericsson Infotech AB: Anders Ellstrmand Hans Hedbom. Hans, with his knowledge in security, has been a greathelp in structuring this thesis and answering my questions regarding security.Anders, with his knowledge in SIP and experience from his own thesis, has been a great help in answering general question and pushing me forward tothe goal. Without them, this thesis would not have been possible.I will also thank my supervisor Viiveke Fk for answering my questions andgiving me proposals how to improve the quality of this thesis.

Karlstad, March 2002


10/127

About the thesis

x


11/127

Table of Contents

xi

Table of Contents

1 Introduction_________________________________________________ 11.1 Background ________________________________________________ 11.2 Purpose ___________________________________________________ 11.3 Reading instructions _________________________________________ 11.4 Glossary___________________________________________________ 2

1.4.1 Acronyms _______________________________________________ 72 Background theory __________________________________________ 11

2.1 Cryptographic goals ________________________________________ 112.2 Conventional encryption _____________________________________ 112.3 Public key cryptography _____________________________________ 12

2.3.1 Encryption/decryption_____________________________________ 122.3.2 Digital signature _________________________________________ 132.3.3 Key exchange ___________________________________________ 14

2.4 Hash functions_____________________________________________ 142.5 Network security___________________________________________ 15

2.5.1 Replay attacks ___________________________________________ 16

2.6 Signaling _________________________________________________ 172.7 SIP______________________________________________________ 17

3 Security mechanisms in SIP___________________________________ 213.1 Authentication_____________________________________________ 21

3.1.1 HTTP Authentication _____________________________________ 213.2 Integrity__________________________________________________ 273.3 Confidentiality_____________________________________________ 283.4 Analysis__________________________________________________ 29

3.4.1 Threats_________________________________________________ 293.4.2 Potential attacks on SIP____________________________________ 303.4.3 Description of potential attacks on SIP ________________________ 333.4.4 Protection_______________________________________________ 363.4.5 Published attacks_________________________________________ 38

4 Proposed security mechanisms in SIP___________________________ 394.1 S/MIME__________________________________________________ 39

4.1.1 MIME _________________________________________________ 394.1.2 S/MIME Functionality ____________________________________ 404.1.3 S/MIME in SIP __________________________________________ 45

4.2 Authentication with EAP ____________________________________ 524.2.1 EAP in SIP______________________________________________ 544.2.2 UMTS AKA ____________________________________________ 55

4.2.3 SIP/EAP/IMS AKA_______________________________________ 594.3 Transport and network layer security ___________________________ 624.3.1 TLS ___________________________________________________ 624.3.2 IPSec __________________________________________________ 74

4.4 3GPP security model for SIP _________________________________ 754.5 Analysis__________________________________________________ 77

4.5.1 S/MIME vs. PGP_________________________________________ 774.5.2 IMS AKA vs. HTTP Digest Authentication ____________________ 80

5 Security tests _______________________________________________ 855.1 Test equipment ____________________________________________ 85

5.1.1 Common equipment ______________________________________ 85


12/127

Table of Contents

xii

5.1.2 General network _________________________________________ 855.1.3 Vovida SIP stack _________________________________________ 855.1.4 oSIP stack ______________________________________________ 85

5.2 General Network security tests ________________________________ 865.2.1 ARP spoofing ___________________________________________ 865.2.2 Comments on the results ___________________________________ 89

5.3 Security tests on the Vovida SIP stack __________________________ 89

5.3.1 Test cases_______________________________________________ 895.3.2 Comments on the results ___________________________________ 95

5.4 Security tests on the oSIP stack _______________________________ 965.4.1 Test cases_______________________________________________ 965.4.2 Comments on the results __________________________________ 100

5.5 oSIP stack vs. Vovida SIP stack ______________________________ 1016 Conclusions _______________________________________________ 103

6.1 Summary ________________________________________________ 1036.2 Summary of the results _____________________________________ 103

7 References ________________________________________________ 105


13/127

Introduction

1

1 IntroductionThis chapter serves as an introduction to the rest of the thesis. First, the back-ground of the project is presented. Following this is a section on the structureof the thesis, giving the reader an overview of the contents as well as a refer-ence for the specialized terms.

1.1 Background

During recent years the telecommunication industry has made tremendousprogress in their development of systems that offer more bandwidth to theend user. Today, the performance of the systems is high enough to offer multi-media sessions, which are very bandwidth demanding. A session is divided intwo phases. The signaling phase, which controls the session, and the mediaphase, which handles the transportation of the data stream.If the participants in the session should be able to understand each other, a setof rules is required. These rules are specied in a protocol. The most likely pro-tocol to be used in an IP based multimedia session for the signaling phase isthe Session Initiation Protocol (SIP), which is designed by the Internet Engine-ering Task Force (IETF). Several protocols with similar functionality exist andthe H.323 protocol is the second most used protocol.During the signaling phase, several parameters are exchanged between theend users. Some of these parameters may be sensitive to the users and should be kept secret, e.g. the location of the user and the users name. It is alsoimportant that each user identies himself to the other users and that unau-thorized users are incapable of modifying, inserting or removing messagessent during the signaling phase. Different security mechanisms as encryption,authentication, secure hash functions and digital signatures may be imple-mented in the protocol to provide a secure session between the end users.

1.2 Purpose Identify the security mechanisms that are implemented in SIP and what

type of protection they provide. Identify possible security threats against SIP. Evaluate which security mechanisms that may be added to SIP to increase

the protection against possible security threats. Present a test specication for security tests performed on different SIPimplementations.

1.3 Reading instructions

The chapter Background theory on page 11gives some background the-ory on cryptography, network security and signaling.

The chapter Security mechanisms in SIP on page 21presents the securitymechanisms in SIP and identies possible security threats against SIP.


14/127

Introduction

2

The chapter Proposed security mechanisms in SIP on page 39 lists sev-eral security mechanisms that have been proposed to be integrated in SIPor used in conjunction with SIP.

The chapter Security tests on page 85presents several security tests thatwere performed on two different implementations of SIP.

The chapter Conclusions on page 103gives the conclusions from the the-

sis.

1.4 Glossary

Active Attack An attack which results in an unauthorized statechange, such as the manipulation of les, or theadding of unauthorized les. [65]

AIS Automated Information System - any equipment of an interconnected system or subsystems of equip-ment that is used in the automatic acquisition, stor-age, manipulation, control, display, transmission,or reception of data and includes software, rm-ware, and hardware. [65]

Authenticate To establish the validity of a claimed user or object.[65]

Authentication To positively verify the identity of a user, device, orother entity in a computer system, often as a pre-requisite to allowing access to resources in a sys-tem. [65]

Buffer Overow This happens when more data is put into a bufferor holding area than the buffer can handle. This isdue to a mismatch in processing rates between theproducing and consuming processes. This canresult in system crashes or the creation of a backdoor leading to system access. [65]

Block Chaining A procedure used during symmetric block encryp-tion that makes an output block dependent notonly on the current plaintext input and key, butalso on earlier input and/or output. The effect of block chaining is that two instances of the sameplaintext input block will produce different cipher-text blocks, making cryptoanalysis more difcult.[1]

Block Cipher A symmetric encryption algorithm in which a large block of plaintext bits (typical 64) is transformed asa whole into a ciphertext block of the same length.[1]


15/127

Introduction

3

Client A client is any network element that sends (SIP)requests and receives (SIP) responses. Clients mayor may not interact directly with a human user.User agent clients and proxies are clients. [59]

Codec Refers to audio or video compression/decompres-sion (codec) algorithms used by an application.

Condentiality Assuring information will be kept secret, withaccess limited to appropriate persons. [65]

Cracker One who breaks security on an AIS. [65]Cryptanalysis Denition 1) The analysis of a cryptographic sys-

tem and/or its inputs and outputs to derive con-dential variables and/or sensitive data includingcleartext.Denition 2) Operations performed in convertingencrypted messages to plain text without initialknowledge of the crypto-algorithm and/or keyemployed in the encryption. [65]

Cryptographic Check-sum

An authenticator that is a cryptographic function of both the data to be authenticated and a secret key.Also referred to as a message authentication code(MAC).[1]

Cryptography The art of science concerning the principles, means,and methods for rendering plain text unintelligibleand for converting encrypted messages into intelli-

gible form.[65]Cryptology The science which deals with hidden, disguised, or

encrypted communications. [65]Data Encryption Stan-dard

Denition 1) (DES) An unclassied crypto algo-rithm adopted by the National Bureau of Standardsfor public use.Denition 2) A cryptographic algorithm for theprotection of unclassied data, published in Fed-eral Information Processing Standard (FIPS) 46.The DES, which was approved by the NationalInstitute of Standards and Technology (NIST), isintended for public and government use. [65]

Decryption The translation of encrypted text or data (calledciphertext) into original text or data (called plain-text). Also called deciphering. [1]

Denial of Service Action(s) which prevent any part of an AIS fromfunctioning in accordance with its intended pur-pose. [65]


16/127

Introduction

4

Dialog A dialog is a peer-to-peer SIP relationship betweentwo UAs that persists for some time. A dialog isestablished by SIP messages, such as a 2xxresponse to an INVITE request. A dialog is identi-ed by a call identier, local tag, and a remote tag.A dialog was formerly known as a call leg in RFC2543.[59]

Digital Signature An authentication mechanism that enables the cre-ator of a message to attach a code that acts as a sig-nature. The signature guarantees the source andthe integrity of the message. [1]

Encryption The conversion of plaintext or data into unintelligi- ble form by means of a reversible translation, basedon a translation table or algorithm. Also calledenciphering. [1]

Firewall A system or combination of systems that enforces a boundary between two or more networks. Gate-way that limits access between networks in accor-dance with local security policy. The typicalrewall is an inexpensive micro-based Unix boxkept clean of critical data, with many modems andpublic network ports on it, but just one carefullywatched connection back to the rest of the cluster.[65]

Hacker A person who enjoys exploring the details of com-puters and how to stretch their capabilities. A mali-cious or inquisitive meddler who tries to discoverinformation by poking around. A person whoenjoys learning the details of programming sys-tems and how to stretch their capabilities, asopposed to most users who prefer to learn on theminimum necessary. [65]

Hash Function A function that maps a variable-length data blockor message into a xed-length value called hashcode. The function is designed in such way that,when protected, it provides an authenticator to thedata or message. Also referred to as a messagedigest. [1]

Header Field A header eld is a component of the SIP messageheader. It consists of one or more header eld val-ues separated by comma or having the sameheader eld name. [59]

Integrity Assuring information will not be accidentally ormaliciously altered or destroyed. [65]


17/127

Introduction

5

IP Spoong An attack whereby a system attempts to illicitlyimpersonate another system by using IP networkaddress. [65]

Key A symbol or sequence of symbols (or electrical ormechanical correlates of symbols) applied to text inorder to encrypt or decrypt.[65]

Network Security Protection of networks and their services fromunauthorized modication, destruction, or disclo-sure, and provision of assurance that the networkperforms its critical functions correctly and thereare no harmful side-effects. Network securityincludes providing for data integrity. [65]

Non-Repudiation Method by which the sender of data is providedwith proof of delivery and the recipient is assuredof the senders identity, so that neither can laterdeny having processed the data. [65]

Nonce An identier or number that is only used once. [1]Packet A block of data sent over the network transmitting

the identities of the sending and receiving stations,error-control information, and message. [65]

Passive Attack Attack which does not result in an unauthorizedstate change, such as an attack that only monitorsand/or records data. [65]

Plaintext Unencrypted data.[65]Private Key One of the two keys used in a asymmetric encryp-

tion system. For secure communication, the privatekey should only be known to its creator. [1]

Promiscuous Mode Normally an Ethernet interface reads all addressinformation and accepts follow-on packets onlydestined for itself, but when the interface is in pro-miscuous mode, it reads all information (sniffer),regardless of its destination. [65]

Proxy, Proxy Server An intermediary program that acts as both a serverand a client for the purpose of making requests on behalf of other clients. Requests are serviced inter-nally or by passing them on, possibly after transla-tion, to other servers. A proxy interprets, and, if necessary, rewrites a request message before for-warding it. [3]

Pseudorandom Num- ber Generator

A function that deterministically produces asequence of numbers that are apparently statisti-cally random. [1]


18/127

Introduction

6

Public Key One of the two keys used in a asymmetric encryp-tion system. The public key is made public, to beused in conjunction with a corresponding privatekey. [1]

Redirect Server A redirect server is a user agent server that gener-ates 3xx responses to requests it receives, directingthe client to contact an alternate set of URIs. [59]

Registrar A registrar is a server that accepts REGISTERrequests. A registrar is typically co-located with aproxy or redirect server and may offer location ser-vices.[3]

RSA Algorithm RSA stands for Rivest-Shamir-Aldeman. A publickey cryptographic algorithm that hinges on theassumption that the factoring of the product of twolarge primes is difcult. [65]

Security Service A service, provided by a layer of communicatingopen systems, which ensures adequate security of the systems or of data transfers. [65]

Secret Key The key used in a symmetric encryption system.Both participants must share the same key, and thiskey must remain secret to protect the communica-tion. [1]

Server A server is a network element that receivesrequests in order to service them and sends back

responses to those requests. Examples of serversare proxies, user agent servers, redirect servers,and registrars.[59]

Session Key A temporary encryption key used between twoparticipants.[1]

Signaling System 7(SS-7)

A protocol used by phone companies. Has three basic functions: Supervising, Alerting andAddressing. Supervising monitors the status of aline or circuit to see if it is busy, idle, or requestingservice. Alerting indicates the arrival of an incom-ing call. Addressing is the transmission of routingand destination signals over the network in theform of dial tone or data pulses. [65]

Spoong Pretending to be someone else. The deliberateinducement of a user or a resource to take an incor-rect action. Attempt to gain access to an AIS by pre-tending to be an authorized user. Impersonating,masquerading, and mimicking are forms of spoof-ing. [65]


19/127

Introduction

7

1.4.1 Acronyms

3GPP 3rd Generation Partnership ProjectAH Authentication HeaderAKA Authentication and Key AgreementARP Address Resolution ProtocolAV Authentication Vector

CA Certicate AuthorityCBC Cipher Block ChainingCK Condentiality KeyCMS Cryptographic Message SyntaxDES Data Encryption StandardDoS Denial of ServiceDSA Digital Signature StandardEAP Extensible Authentication Protocol

Symmetric Encryption A form of cryptosystem in which encryption anddecryption are performed using the same key. Alsoknown as conventional encryption. [1]

Threat The means through which the ability or intent of athreat agent to adversely affect an automated sys-tem, facility, or operation can be manifest. A poten-tial violation of security. [65]

Trojan Horse An apparently useful and innocent program con-taining additional hidden code which allows theunauthorized collection, exploitation, falsication,or destruction of data. [65]

User Agent Client(UAC)

A user agent client is a client application that ini-tiates the SIP request. [3]

User Agent Server(UAS)

A user agent server is a server application that con-tacts the user when a SIP request is received andthat returns a response on behalf of the user. Theresponse accepts, rejects or redirects the request. [3]

Vulnerability Hardware, rmware, or software ow that leavesan AIS open for potential exploitation. A weaknessin automated system security procedures, adminis-trative controls, physical layout, internal controls,and so forth, that could be exploited by a threat togain unauthorized access to information or disruptcritical processing. [65]


20/127

Introduction

8

ESP Encapsulating Security PayloadHE Home EnvironmentHTTP HyperText Transfer ProtocolIK Integrity KeyIM CN SS IP Multimedia Core Network SubSystem

IMSI International Mobile Subscriber IdentityICMP Internet Control Message ProtocolIETF Internet Engineering Task ForceIKE Internet Key ExchangeIP Internet ProtocolIPSec IP SecurityMAC Message Authentication CodeMD5 Message Digest version 5MIME Multipurpose Internet Mail ExtensionOS Operating SystemPGP Pretty Good PrivacyPKIX Public Key InfrastructurePPP Point to Point ProtocolPRF PseudoRandom functionQOP Quality Of Protection

RFC Request For CommentsRSA Rivest-Shamir-AdlemanS/MIME Secure/Multipurpose Internet Mail ExtensionSA Security AssociationSDP Session Description ProtocolSHA-1 Secure Hash Algorithm version 1SIP Session Initiation Protocol

SMTP Simple Mail Transport ProtocolSN Serving NetworkSS7 Signaling System No. 7SSL Secure Socket LayerTCP Transmission Control ProtocolTLS Transport Layer SecurityTMSI Temporary Mobile Subscriber IdentityUA User Agent


21/127

Introduction

9

UDP User Datagram ProtocolUE User EquipmentUMTS Universal Mobile Telecommunication SystemURI Uniform Resource IdentierUSIM UMTS Subscriber Identity Module


22/127

Introduction

10


23/127

Background theory

11

2 Background theoryThis chapter introduces the reader to some background information regardingcryptography and signaling which may be needed in order to understand therest of the chapters. Readers that are familiar with cryptography can probablyskip the rst ve sections and continue to read about signaling and the SessionInitiation Protocol (SIP [2]).

2.1 Cryptographic goals

The main goal of cryptography is to provide the following services:1. Condentiality

2. Authentication

3. Data integrity

4. Non-repudiation

Condentiality is a service used to keep the information secret to everyone thatis unauthorized to access it. Encryption is one method to provide condential-ity, seeConventional encryption on page 11 and Encryption/decryptionon page 12. Authentication is a service used for identication of information or entities. Theidentication of the information is often calleddata origin authentication or mes-sage authenticationand identication of the enities is often calledentity authenti-cation.

Data integrity is a service to detect unauthorized manipulation of information.Manipulation includes insertion, deletion and substitution. Secure hash func-tions may be used to provide data integrity, seeHash functions on page 14.

Non-repudiation is a service which prevents an entity from denying previouscommitments or actions. Digital signatures is one method of providing Non-repudiation, see Digital signature on page 13.

2.2 Conventional encryption

Conventional encryption, also referred to as symmetric encryption or single-key encryption, is the most used encryption technique today. Conventionalencryption uses a secret key that only the sender and receiver share. The keyand the plaintext are the parameters for the encryption algorithm that produce

Message authentication ensures the receiver that only an authorized partycan have created the specic information. An encrypted checksum of theinformation is often attached to the information which proves that only anauthorized entity can have created the information.Entity authentication enables an entity to verify the identity of another entity.A common way to accomplish entity authentication is to challenge theother entity by giving it some type of information that only an authorizedentity responds correctly to.


24/127

Background theory

12

the ciphertext. And the key and the ciphertext are the parameters for thedecryption algorithm.There exist several classical encryption algorithms that are easy to cryptoana-lyze, i.e. a third party nds the secret key or the plaintext. One of these is theCaesar Chiper[1] which is based on a substitution technique, i.e. each charac-ter in the plaintext is mapped to another character by using tables or somemathematical function. The algorithm assigns a number to every characterand produces the chiphertext by adding the numerical key to every character.The result is always modulo the number of characters in the alphabet. Thenumber of possible keys is equal to the number of characters in the alphabetand therefore easy to cryptoanalyze with brute-force.Fortunately there exist modern encryption techniques that are very difcult tocryptoanalyze due to their complex structure. The most famous and mostused algorithms are different variants of the Data Encryption Standard (DES[7]). DES and other modern encryption algorithms are based on the FeistelCipher [8]which is characteristic by its rounds. The rst round takes the plain-text and a subkey as parameters and the output is passed to the next round.The result from the last round is the actual ciphertext. This mean that eachround can be seen as a independent cipher. The major differences between dif-ferent modern symmetric encryption techniques is the structure of these inde-pendent chipers, i.e. they use different key lengths and bit operations. Theyalso differ in how many rounds they use.For more information about modern encryption techniques, see [1].

2.3 Public key cryptography

The discovery of public key cryptography has been a revolution in cryptogra-phy. Public key algorithms are based on mathematical functions rather thanon different types of bit transformations. Another big difference is that publickey cryptography is asymmetric, i.e. uses two separate keys instead of one.The keys are referred to as the public key and the private key. The private keyis kept secret while the public key is distributed to different individuals thatwill communicate with the owner of the private key. Encryption/decryption is just one of three different categories that can be used with public key cryptog-raphy, these are: Encryption/decryption

Digital signature Key exchange

2.3.1 Encryption/decryption

There exist several public key encryption algorithms but the most known isthe Rivest-Shamir-Adleman (RSA [9])algorithm. Another algorithm is EllipticCurves encryption/decryption which is more complicated but can offer equalsecurity with smaller keys than RSA.


25/127

Background theory

13

Bellow is the mathematical description of the RSA algorithm:

Figure 1 The RSA algorithm [1].

One way cryptoanalyze the algorithm is to factorn into its two prime factors.That can easily be done with smalln but for largen the degree of success willfall dramatically.

2.3.2 Digital signatureTo sign a plaintext the sender encrypts it with its own private key and thereceiver decrypts the ciphertext with the senders public key. If the result fromthe decryption is readable, the receiver can be sure that it originates from thesender because the sender its the only one that knows its private key. This wayof making digital signatures is not effective because the whole message isencrypted which requires a lot of computational resources. A better solution isto map the message to a smaller, xed sized, value and encrypt it with thesenders private key. The function that maps the plaintext to a xed sized valueis called a strong one-way hash function.

Key Generation

Select p, q p and q both primesCalculate

CalculateSelect integer e

Calculate dPublic key

n p q=

n( ) p 1( ) q 1( )=gdc n( ) e,( ) 1 1 e n( )<


26/127

Background theory

14

2.3.3 Key exchange

One of the problems with public key cryptography is the distribution of publickeys in a secure way. The actual distribution is quite easy to accomplish, but itis much harder to convince a user of the identity of the public key owner.There is no logical connection between a public key and the identity of theowner. For example, if a user C is able to deceive another user A to believe thatit has received a public key from user B, then user C may be able to readencrypted messages from user A to user B. User C may also forge user Bs dig-ital signature and user A will believe that the source of signed messages isuser B.There exist several methods that solves the key-exchange problem by usingsome sort of trusted third party that the participants can ask for public keys.Methods that use so-called public key certicates are probably the most popu-lar ones. A user, who requests a public key certicate, sends its public key to aCerticate Authority (CA), which creates a public key certicate for the partic-ular public key and then it signs the public key certicate with its private key.The user may then send its public key certicate to other users and if theytrust the CA, then they know that the public key in the public key certicate isvalid. More detailed descriptions of public key certicates and other methodsfor distributing public keys can be found in [1].Another problem concerning public key encryption/decryption is that it ismuch slower than conventional encryption. Therefore public key encryption iscurrently conned to key management and signature applications. Theencryption is made with conventional encryption using a secret key, alsoreferred to as a session key. The session key is distributed to the participants by some key exchange algorithm. One of the most famous key exchange algo-rithms is the Dife-Hellman algorithm [10].A detailed description of the Dif-e-Hellman algorithm can be found in [1].

2.4 Hash functions

A hash function, , takes a variable-length block, , and produces a xed-length output. There exists many such function, but to be useful in securityapplication it must have special properties: is relative easy to compute.

For any given output , it is computationally infeasible to nd such that.

For any given block , it is computationally infeasible to nd , , with

It is computationally infeasible to nd any pair such that.

Hash functions that have all of these properties are often called strong one-way hash functions. Hash functions that do not have the last property arecalled weak one-way hash functions.

H x

H x( )h x

H x( ) h= x y y x

H x( ) H y( )= x y,( )

H x( ) H y( )=


27/127

Background theory

15

The most used hash functions today are probably Message Digest, version 5,(MD5[11]) and Secure Hash Algorithm, version 1, (SHA-1 [12]).Detaileddescriptions about these can be found in [1].

2.5 Network security

Under recent year there has been a strong focus on information technologyand specially on Internet. Almost every modern company is connected toInternet and it also has its own local network that is used by the employees.Almost every task performed by the employees involves some use of the Inter-net or the local network, e.g. for documentation and e-mail distribution.Therefore the need of stable hardware and security is essential for a moderncompany.Regarding the security topic, the following types of attacks on networks have been identied by [1]:1. Disclosure: Release of message contents to any person or process not pos-

sessing the appropriate cryptographic key.2. Trafc analysis : Discovery of pattern of trafc between parties. For onlinecommunication a person may measure the time it takes to apply a specicalgorithm to the message or nd how frequent the message exchange is.For both the ofine and online case a person can discover how many mes-sages that were sent and the length of the messages.

3. Masquerade: Insertion of messages into the network from a fraudulentsource. A person may send a message that looks like it origins fromanother source or send an acknowledgement for a message that it has notreceived.

4. Content modication: Changes to the contents of a message, includinginsertion, deletion, transposition and modication.

5. Sequence modication: Any modication to a sequence of messages between parties, including insertion, deletion and reordering.

6. Timing modication: Delay or replay of messages. For online communica-tion a person may replay an old message to gain a certain privilege ordelay the messages to decrease the quality of the communication. Forofine communication a person may replay an old special message.

7. Repudiation: Denial of receipt of message by destination or denial of trans-mission of message by source.

Security researchers have developed and designed plenty of algorithms andprotocols, the purpose of which is to provide protection against one or severalof these types of attacks. And there exist several good text books, within thesecurity area, that describe the most popular and useful ones. One of these is[1], that will give the reader enough knowledge how different algorithms andprotocols works.Message authentication may be used as a measure to prevent items 3 through6. Items 1 and 2 may be prevented by using encryption, and digital signatures


28/127

Background theory

16

may protect against item 7. Next section will give a more detailed descriptionabout what measures that has to be made to protect against item 6.

2.5.1 Replay attacks

An attack where valid messages are maliciously or fraudlently repeated, byeither the orginator or an unauthorized entity, is called a replay attack. Replay

attacks may be launched to gain authrozied access to a service or to imperson-ate another entity.Replay attacks are a threat to almost every system where messages are used toaffect the state of the system. For example, if an attacker is able to replay avalid request, in a client-server system, then the attacker may be able to deletea specic le on the server or change a password.It seems very easy to accomplish a successful reply attack, but one has to con-sider that messages may be encrypted. This eliminates the attackers ability toread the content in the replayed messages and he or she will be unable to pre-dict the result of the replay attack. A skilful attacker may use trafc analysis to

predict the content in the message.The following examples of replay attacks are mentioned in [1]: Simple replay: The attacker simply eavesdrop a message and replays it

later. Repetition that can be logged: The attacker can replay a timestamped mes-

sage within a valid time interval. Repetition that cannot be detected: The attacker eavesdrop a message that

does not reach the destination. When the attacker replays the message thereceiver accepts is as valid and it can not detect that another authorized

entity has sent it before. Backward replay without modication: The attacker replays the message

back to the sender. The attack is possible if a symmetric key has been usedto encrypt the message and the sender does not have the ability to distin-guish if a message originates from it self.

To get a protection against replay attacks the following approaches may beused: Timestamps: The entities always attach a timestamp to their messages and

the receiver only accepts messages that has a valid timestamp, i.e. the

timestamp ts a certain time interval. This is sensitive because the entitiesneed to have synchronized clocks with small divergence depending on theaccuracy of the time interval. This denitely applies to ofine communica-tion where the entities can not synchronize their clocks to each other for arelative long period of time.

Sequence number: The entities always include a sequence number in themessage. The receiver then knows which sequence number the next mes-sage should have to be valid and messages with a smaller or a largersequence number will be discarded. The problem with this method is thateach entity has to remember the sequence number for each entity it will


29/127

Background theory

17

communicate with. One less secure solution to this problem is to alwaysstart with a certain sequence number for each new session.

Challenge/response: An entity rst sends a nonce to the other entity. Thenthe entity requires that the subsequent message contains the correct noncevalue. The problem with this method is that it is only suitable for onlinecommunication. However, this method is preferred in a client-server appli-cation where the server responds to an invalid nonce by sending a newgenerated nonce back to the client. The client may then resend the messagewith the new nonce and the server accepts it as valid. It is important tomention that the server should not use a predictable old nonce becausethen we are back were we began.

2.6 SignalingSignaling refers to the exchange of information between call componentsrequired to provide and maintain service. The information is used to establish,route, monitor and terminate a call between one or several calling parties. Thecalling parties are identied by a unique address, that in traditional telephonyis the phone number. Its important to understand that signaling is notinvolved in the actual transportation of data between the calling parties, butinstead makes the transportation viable.Most signaling today is done over circuit switched networks with the Signal-ing System No.71 (SS7) protocol which is a very exible protocol with manyfeatures. But a more exible and more cost-effective way is to make calls overan IP network, i.e. IP Telephony. The IP Telephony makes it possible to estab-lish sessions between several parties that can exchange data adapted to differ-ent media, i.e. data, voice, pictures and video. Its also possible to modify thesessions during the call, i.e. change media type, add a caller, remove a calleretc. To be able to use all of these features the need for exible signaling is obvi-ous. There exist several protocols for signaling over a IP network and the mostknown are Session Initiation Protocol and H.323 [14].

2.7 SIP

Session Initiation Protocol, SIP, is an application layer protocol that has beendesigned by Internet Engineering Task Force (IETF) Multiparty MultimediaSession Control working group. It denes initiation, modication and termi-nation of interactive, multimedia communication sessions between users.SIP has incorporated elements from other protocols that are widely used onthe Internet. It is a text-based client-server protocol with almost the samestructure as the HyperText Transport Protocol (HTTP [13]) and the text-encod-ing schemes are borrowed from Simple Mail Transport Protocol (SMTP [16]).This makes the structure of the protocol easy to follow and understand.

1. The standard of SS7 contains many different protocols which have their own documentations. But agood overview can be found at http://www.pt.com/tutorials/ss7/index.html.


30/127

Background theory

18

As mentioned above the SIP messages have the same structure as the mes-sages in HTTP and contain a request line or a status line followed by at leastsix header elds. After the header eld there may be an attached message body, the type and size of which is described by some of the header elds. Asfor HTTP and SMTP, SIP supports the popular Multipurpose Internet MailExtension (MIME[18]) for describing the content in the message body. In mostcases the message body consists of a Session Description Protocol (SDP [15])message, which describes the media transfer after the signaling phase. TheSDP message has a MIME subtype of application/sdp. Even if the SIP message body in most cases contains a SDP message it may also contain other MIMEsubtypes, like e.g.text/plain or image/gif .The client-server structure is based on a client that issues a request for a ser-vice and a service server handles the request and responds with a service. ASIP-enabled end-device, SIP User Agent (UA), has both a client and serverapplication. This is natural if you think of a telephone which both makes callsand receives calls.All requests from a client UA contain a method in their request lines. In cur-rent version of SIP [2] there exist six different methods:

Table 1 Dened methods in SIP.

The responses from the UA server have the same structure as in HTTPresponses. All SIP responses have a status line which contains a status codeand a formal description of the response. The status codes are ordered in sixdifferent classes and each class represents a specic type of response. For amore detailed description of these classes, see[2]. Most of the header elds inthe response are copies of the header elds from the request that the responsecorresponds to. But some header elds are specied to only be used in

Method name Description

INVITE Invites UA server to a call and estab-lishes a new connection. It can con-tain media capabilities.

ACK Used to acknowledge a responsegenerated by a received INVITErequest.

BYE Terminates the media session between two users.

REGISTER Used for registering informationabout a UA clients location.

CANCEL Terminates a non-acknowledgedinvitation.

OPTION Used to get information about sup-

ported capabilities.


31/127

Background theory

19

responses. A response may contain a message body and the MIME subtype isin most cases the same as for the corresponding request. The UA server mayinclude a SDP message in the message body for negotiation of the media typesthat should be used during the media transfer.There exist other applications than UA clients and UA servers that are able tohandle SIP messages, namely:

Proxy servers Redirect servers Registration servers GatewaysProxy servers have the task of forwarding requests from the UA client to theaddress specied in the SIP message. Proxy servers have also the ability tomodify some parts of the header in the message, e.g. the Via header eld. Theycan also require authentication to a request before they forward the message.Responses from the UA server are also forwarded down to the client. Theresponses always take the same way back as the request took, i.e. forwardedthrough the same proxies. If the SIP UA has been congured to always send itsrequests through a specic proxy, then this proxy is called the outbound proxyfor the SIP UA.A redirect server does not issue any request of its own. After receiving arequest the server gathers a list of alternative locations and returns a nalresponse.A registration server, also called registrar, has the task of accepting REGISTERrequests from a UA. The request contains information on how to reach the UA.The information is saved so other UA can ask the registrar where the UA islocated. The registrar can require authentication.Gateways are used between different types of networks or when different pro-tocols are used between networks. Gateways between SIP and H.323 is oftenused as an example.For detailed description about the SIP protocol, see [2].


32/127

Background theory

20


33/127

Security mechanisms in SIP

21

3 Security mechanisms in SIPThis chapter covers the security mechanisms that are standard in the currentversion of SIP [5]. Because SIP still is under development, some security mech-anisms that are discussed in this chapter may be excluded in later versions.There may also be new mechanisms added as standard in later versions. Someof these candidates are described in the next chapter.

The last section makes a solid analysis about the protection that these standardmechanisms give.

3.1 Authentication

Authentication ensures that a message has been created by the claimed sourceand that the claimed source has sent it. Authentication includes protectionagainst modication, delay, replay and reordering, see Cryptographic goalson page 11.

SIP provides a stateless challenged-based mechanism for authentication. Theauthentication mechanism is meant to be used only in one direction. But thereis an option to make mutual authentication, i.e. authentication in both direc-tions. There is also support for integrity protection of requests and responses.IETF SIP working group has not developed a new scheme for authentication,and uses almost the same authentication scheme as is used for HTTP [4]. Onedifference is the denition of the protection domain, which in the HTTP case isdened by the realm and canonical root URL. The canonical root URL doesnot exists in SIP, i.e. there are no les to get, put or delete like in HTTP. There-fore is the protection domain dened by the realm, userinfo, host and portpart of the Request-URI, see [2]for a more detailed description of this topic.

3.1.1 HTTP Authentication

Two different authentication schemes are standard in HTTP, namely Basic andDigest authentication. The rst one is very primitive and insecure because itsends the credentials for the client in plain text. The Digest authentication ismuch more secure because the authentication scheme uses checksums for cre-dentials. Although it is not a perfect solution for secure authentication, it pro-tects against most of the security aws in the Basic authentication.Both authentication schemes use four different header elds to accomplish the

authentication. Some of these are specic for proxies and the rest are for UAauthentication. The elds are (case-sensitive): WWW-Authenticate Authorization Proxy-Authenticate Proxy-AuthorizationThe Digest scheme can use one more header eld, namely Authentication-Info


34/127


22

When a UAS receives a request for a protected domain that is not authenti-cated, it responds with a 401 (Unauthorized) response which contains theWWW-Authenticate headereld. The header eld provides information aboutthe challenge that the client should respond to. If the client is able to respondto the challenge, it must use the Authorization header eld containing creden-tials information about the client. If the server accepts the credentials, the cli-ent is allowed to access the protected domain.A server may have multiple protected domains and therefore the challengemust specify which protection domain the challenge is applied to. This isaccomplished by using the realm parameter in the WWW-Authenticate headereld. The realm value can not be excluded for proper authentication becausethe clients credentials are based on it.The Authentication-Info header can be used by the server to re-challenge theclient if Digest authentication is used. It can also be used by the server toauthenticate itself to the client, i.e. mutual authentication.The Proxy-Authentication and Proxy-Authorization header elds are used

when a proxy demands authentication before it forwards a message. Theheader elds are the same as WWW-Authenticate and Authorization, but withdifferent names.

3.1.1.1 Basic Authentication

As mentioned in the previous section, the Basic authentication gives very poorsecurity because it allows the clients credentials to be sent in plain text. If theserver receives a request that needs authentication, it adds the WWW-Authen-ticate header eld in the 401 (Unauthorized) response. The only parameter inthe header eld is the realm value, i.e.

WWW-Authenticate: Basic realm=Administration

When the client receives the challenge, it tries to nd the credential for thespecied realm and send a response to the challenge that contains usernameand password. The response to the challenge is sent in the Authorizationheader eld:Authorization: Basic Radix-64(username:password)

The radix-64 [7] function maps its parameter to printable characters. The fol-lowing example shows the result of user administrator with passwordfoo:

Authorization Basic YWRtaW5pc3RhdG9yOmZvbw==If the credentials are correct the server authorizes the client to perform therequest that caused the authentication. The client may then send the Authori-zation eld in every request, with the same credential, to the same protectiondomain without receiving a challenge by the server. This reduces the numberof 401 (Unauthorized) responses to the client and as a consequence increasesthe performance.


35/127


23

3.1.1.2 Digest Authentication

Digest authentication is more sophisticated than Basic authentication becauseit uses check sums as response to the challenge. The default checksum algo-rithm is MD5, but other algorithms can be used. If the server receives a requestthat needs authentication, it adds the WWW-Authenticate header eld in the401 (Unauthorized) response. The parameters for the WWW-Authenticateheader eld are described in Table 2.

Table 2 WWW-Authenticate header eld parameters.

The nonce value is important because it species the current challenge. The

format is implementation dependent with the restriction that it should beunique. It can be used for protection against replay-attacks if it is changed foreach new request,see Replay attacks on page 16. That technique, however,will increase the used bandwidth.The qop-option value is optional depending on backward compatibility witholder versions of Digest authentication. It should be used because it providesmutual authentication and some message integrity protection. The mutualauthentication means that the server also has to verify that it knows the user-name and password for the client. If the qop-options equals auth-int then both authentication and message integrity is used. Is the value auth then

Name of parameter Description

realm String associated with the protectiondomain.

domain (optional) List of URIs that denes the protec-tion domain.

nonce Unique string that is created by theserver for each 401 response.

opaque (optional) A string of data specied by theserver, which should be returned bythe client unchanged.

stale (optional) A ag that species if the previousrequest from the client was rejected because the nonce was stale.

algorithm (optional) Species the algorithm to use for thechecksum calculations.

qop-options (optional) Species the quality of protectionthat the server supports. It can beeither auth-int or auth depend-ing on the servers capabilities.

auth-param (optional) Future extensions.


36/127


24

only authentication is used. It is important to mention that the server to clientauthentication is made with the Authentication-Info header eld, not in theWWW-Authenticate eld.When the client receives the challenge in a 401 response with a WWW-Authenticate header eld inside, it uses its password and some of the parame-ters in the WWW-Authenticate header eld to calculate the checksum. Thechecksum is included in the Authorization header eld inside the new requestfrom the client to server. The parameters for the Authorization header eld aredescribed inTable 3.


username Clients username for specied realm.realm String associated with the protection

domain. Must contain the same valueas the realm value in the 401 responsefrom the server.

nonce Unique string that is created by theserver for each 401 response. Shouldcontain the same value as the noncevalue in the 401 response from theserver

digest-uri The URI from the Request-URI of theRequest-Line.

response The calculated checksum, hexadeci-mal encoded.

algorithm (optional) Species the algorithm to use for thechecksum calculations.

cnonce (optional) If the qop-options in the received 401response is not empty, this value isused by the server to authenticate itself to the client by using the Authen-tication-Info headereld. Thevalue isgenerated by the client and it should be unique. If the qop-options isempty in the received 401 response,then this parameter must not be used.

opaque (optional) A string of data specied by theserver, which should be returned bythe client unchanged.


37/127


25

Table 3 Authorization header eld parameters.

The parts that are included in the checksum depend on the qop-options andalgorithm values. Figure 2a and Figure 2b show the different checksums cal-culations, where denotes the hash function anddenotes a concatenation of strings.

Figure 2a The checksum calculation if the message-qop value is unspeci-ed.

Figure 2b The checksum calculation if message-qop value is either author auth-int.

The values of A1 and A2 depend on the message-qop and the algorithm usedfor the checksum.Figure 3ato Figure 3dshow the calculations of A1 and A2for different parameter values.

Figure 3a The value of the algorithm parameter is MD5.

message-qop (optional) Species the quality ofprotection thatthe client has applied to the message.It must be some of the qop-optionsvalues specied in the 401 responsefrom the server.

nonce-count (optional) Species the number of requests thathave used the nonce specied in thisheader eld

auth-param (optional) Future extensions.


H x( ) concat s 0 sn, ,( )n 1+

checksum = H(concat(H(A1), :, nonce, :, H(A2)))

checksum = H(concat(H(A1), :, nonce,: ,nonce-count, :,message-qop, :, H(A2)))

A1 = concat(username,:, realm, :, password)


38/127


26

Figure 3b The value of the algorithm parameter is MD5-sess.

Figure 3c The message-qop value is auth or unspecied.

Figure 3d The message-qop value is auth-int.

Following explanation about MD5-sess is given in RFC 2617 [4]:The "MD5-sess" algorithm is intended to allow efcient 3rd party authenticationservers; for the difference in usage.

The MD5-sess algorithm can not be specied if the message-qop value is notpresent. The Method used in the calculation of A2 is the SIP request methodname. The entity-body is not the same as the message body and the followingdescription is given in RFC 1945 [13]:

When an Entity-Body is included with a message, the data type of that body isdetermined via the header elds Content-Type and Content-Encoding. These denea two-layer, ordered encoding model:

entity-body := Content-Encoding( Content-Type( data ) )

A Content-Type species the media type of the underlying data. A Content-Encod-ing may be used to indicate any additional content coding applied to the type, usu-ally for the purpose of data compression, that is a property of the resourcerequested. The default for the content encoding is none (i.e., the identity func-tion).

When the server receives the response from the challenge it calculates thechecksum with the same parameters as the client. If the client is authorized toaccess the protection domain and the checksum result is equal to the value inthe received response parameter then the client is allowed to access the protec-tion domain. If the client is authorized, future responses from the server maycontain the Authentication-Info header eld to provide mutual authentication,some message integrity and new nonce generation. The parameters for theAuthentication-Info header eld are described in Ta ble 4.

A1 = concat(H(concat(username, :, realm,:, password)), :,nonce-value, :, cnonce-value)

A2 = concat(Method, :, digest-uri)

A2 = concat(Method, :, digest-uri, :, H(entity-body))


39/127


27

Table 4 Authentication-Info header eld parameters.

If the server changes the nonce on every request from the client then it mustgenerate new challenges for every request, which is inefcient. To avoid thisthe server can include the Authentication-Info header eld in the responses tothe client, so that the client knows the new nonce before the server changes it.The response-auth value is used by the server to prove that it knows the cli-ents secret. The calculation of the checksum is almost the same as in theAuthorization response.Figure 4aand Figure 4bshow the differences for thechecksums calculations.

Figure 4a The message-qop value is auth or unspecied.

Figure 4b The message-qop value is auth-int.

3.2 Integrity

Message integrity assures that only authorized parties are able to modify themessage, i.e. an unauthorized third party can not modify the message withoutdetection by the authorized receiver. In most cases the integrity protection isonly applied to special parts of a message, i.e. parts that are not allowed to bemodied.


nextnonce Nonce that the server whishes theclient to use for a future authentica-tion response.

message-qop (optional) Same as in the Authorization headereld.response-auth (optional) The calculated checksum, hexadeci-

mal encoded.cnonce (optional) Same as in the Authorization header

eld.nonce-count (optional) Same as in the Authorization header

eld.

A2 = concat(:, digest-uri-value)

A2 = concat(:, digest-uri, :, H(entitybody))


40/127


28

The problem with integrity protection in SIP is that the messages are allowedto be changed by network intermediaries. This means that the parts that areallowed to be changed can not be included in the integrity protection.The standard of SIP denes how to use Pretty Good Privacy (PGP [20]) to sup-ply signatures of message parts that are not changed by network intermediar-ies. A signature is one of several ways to supply message integrity by usinghash functions. Even if the standard document for SIP, Request For Comments(RFC) 2543, is a standard track with Draft Standard [17]status it will probably be obsolete and replaced with the draft draft-ietf-sip-rfc2543bis-0x,where x is the version number. In current version, version 5, the use of PGPsignatures has been excluded. Today there only exists a very limited integrityprotection in SIP which is provided by the Digest authentication scheme,described in the previous section. Although it is wrong to say that SIP does notsupport other integrity protection, the protocol does not make any standarddenition how to implement these.The section above stated that there is no integrity protection for the completemessage in SIP. But there exist denitions on how to protect the integrity of themessage bodies by using S/MIME,see Clear signing on page 43.The mes-sage bodies consist of descriptions of the media transfer which may be inter-esting to protect against modication.Even if there is no integrity protections dened for the complete message inSIP, it is always possible to use transport and network layer protocols that pro-vide this feature. In version 5 of the SIP draft from IETF there is a recommen-dation for SIP endpoints to support Transport Layer Security (TLS [5]). IPSecurity (IPSec [6]) is also a hot topic for providing integrity protection.

3.3 CondentialityMessage condentiality assures that only authorized parties are able to readthe content. In SIP, encryption is used to provide message condentiality.In RFC 2543 there exist two header elds, the Encrytion and Response-Key,that may be used for end-to-end encryption. There also exists a denition onhow to use these header elds for PGP encryption. As in the case of messageintegrity this denition has been excluded in the coming draft. The headerelds have also been excluded which indicates that the encryption will be outof the scope in the SIP protocol and probably be moved to lower layer proto-cols.The problem with end-to-end encryption in SIP is that network intermediarieshave a need to view certain parts of the message to be able to accomplish theirtasks. These parts may be sensitive to the users, which means that most of the benets of using encryption is lost. There is also a concern about the key-exchange because end-to-end encryption algorithms are based on keys shared by different users. SIP does not dene any mechanism for key-exchange aslower layer protocols like TLS and IPSec do. The conclusion is that it is notlikely to be any support for end-to-end encryption in the future standard forSIP.


41/127


29

Although the complete message will not be encrypted, it is however possibleto encrypt the message body end-to-end by using S/MIME, see Encryptionof a MIME entity on page 41.

3.4 Analysis

The intention with the following section is to give the reader a careful analysisof the security mechanisms in SIP. The analysis is based on the latest draft of the SIP protocol [2] from IETF.Modern cryptology schemes may provide protection against different securitythreats. But there are also other aspects to consider when designing an appli-cation e.g. performance, power consumption, user-friendliness etc.SIP will be implemented on many different platforms with some of them hav-ing long round-trip times and limited power supply, e.g. mobile phones. Com-plex schemes that provide strong protection will probably not be suitable inSIP. Constructing a new scheme based on the requirements and limitations is

always possible but will require lot of time to develop. The history shows thatnew schemes always have serious security aws when they rst are releasedfor public use. Even if the core of the new scheme is kept secret it does not pre-vent users from making reverse engineering to reveal the secrets.IETF have obviously thought about the requirements and limitations whenthey designed the security framework for SIP but there is still much morework left to be done. The framework contains only Basic and Digest authenti-cation today, which is not sufcient to prohibit all security threats. The frame-work must be extended to prevent more security threats as the man-in-the-middle (MITM) attacks and eavesdropping.

3.4.1 Threats

Threats can be split into different areas, shown in Figure 5.

Figure 5 Different areas of threats [21].

Security threats

Natural disasterHuman

Malicious Non-malicious

Outsiders likeCrackers orHackers

Insiders likedisgruntledemployees

Ignorantemployees

Floods, Fires,Earthquake etc.


42/127


30

The most serious threats are those made by insiders who have both the knowl-edge and capabilities to make serious harm to the target. The non-maliciouspersons are often unaware of the threats they cause, i.e. they do not have theintention to harm the target. A unintentional threat could be software bugsand loose security thinking but events like natural disaster also ts this cate-gory. Natural disasters are difcult to be protected against but a good recoveryplan may decrease the damage to minimum.The most famous group of malicious outsiders that makes intentional threatsis hackers and crackers who often use different types of self developed tools toharm the target. They often gain knowledge about weak points on the target before the actual attack occurs. The attack could be either active or passive.The passive attack is used to obtain information and the active attack is usedto modify information.

3.4.1.1 Threat classes

There exists several classications on security threats and I have chosen thefollowing one, which is broader then the average classication: Unauthorized access Modication Disclosure Repudiation Denial of Service (DoS)The Denial of Service is the hardest one to be protected against. The main rea-son for this is that systems that try to protect against a specic DoS threat oftenare exposed to other types of DoS threats.

3.4.2 Potential attacks on SIP

There exist several potential attacks on SIP and some of them are easy toaccomplish with almost no knowledge about security. Fortunately theseattacks are easy to be protected against with supported security mechanismsin SIP. Some potential attacks are more difcult to be protected against because of the limited security mechanisms for encryption and integrity pro-tection in SIP.

3.4.2.1 Spoong

Spoong is an active attack. The malicious person, the attacker, constructs anew message which is sent to the target. The headers and the body in the mes-sage are written so that the receiver believes that the message originates fromanother source. If the attacker is able to do this, it may open up several otherattacks, e.g. eavesdropping and security downgrading.The simple spoong attacks on SIP have properties similar to the spoongattacks on the SMTP protocol. Spoong attacks on the SMTP protocols are inmost cases used for sending spams, i.e. e-mails that the receiver has not askedfor. The receiver is unable to backtrace these e-mails because the source

address is spoofed and in most cases the specied source address does not


43/127


31

exist. A simple spoong attack in SIP would be to spoof the From and/or theSubject header elds. And if the receiver uses a SIP UA that does not makeany reverse address lookup and checks it against the Internet Protocol (IP [22])address, the user is unable to decide if the message really originates from thespecied source. Even if the UA makes a reverse address lookup it does notassure a correct IP address, because even the IP address can be spoofed [25].The following example shows how user Alice wants Bob to believe that theSIP message comes from Charlie by spoong the From and Subject headerelds:

Figure 6 Spoofed SIP message.

It can be seen inFigure 6that Alice has to specify her own IP address in someheader elds to assure that Bob sends the response back to her. She must dothis because her intention is to have a dialog with Bob and he should believethat he is invited by Charlie. A more advanced variant of this attack would beto use a spoofed IP address. Then Alice would receive the responses from Bobeven if she species Charlies IP address.

3.4.2.2 Eavesdropping

Eavesdropping in an IP network is not as easy as it sounds, although it is eas-ier than eavesdropping a telephone call. One exception is the Ethernet net-work, Ethernet is the most common network protocol running on localnetworks and is easily monitored because all messages pass all hosts. Themessages are passed to all hosts because they share a common cable or hub. Ausers network device may then be put in a promiscuous mode that enables itto pass all received messages through the protocol stack even if the messagesare addressed to another host. Fortunately, most local networks use switchesinstead of hubs which prohibit this type of broadcasted messages. A switchuses forwarding tables to decide which of its connected hosts that shouldreceive a particular message. This means that a user only can eavesdrop itsown messages in a switched network if the forwarding tables are static.In an IP network all hosts are addressed by their IP address and not the MediaAccess Control (MAC) address that is used in Ethernet networks. This meansthat all hosts and switches need to have a table that translates an IP address toa MAC address to be able to send messages to a Ethernet network device.These tables are often built dynamically by using the Address Resolution Pro-tocol (ARP [23]). An attacker may spoof ARP messages to be able to receive

INVITE sip:[email protected] SIP/2.0

From: Charlie C. ; tag=1234Call-ID: 1234567CSeq: 1 INVITEContact: Alice Subject: Greeting from Charlie!!...

To: Bob B.Via: SIP/2.0/UDP 10.0.0.3:5060


44/127


32

messages addressed to another host even in a switched network. However,this type of attack may only work inside a local network because routers donot forward ARP messages to an outside network. A router is actually anadvanced switch that interconnects local networks with e.g. internet. For moredetails about ARP spoong, see [24]and ARP spoong on page 86.A similar method to the ARP spoong is the Internet Control Message Proto-col (ICMP[26]) spoong, see[27] for a more detailed description.To be able to eavesdrop messages from an arbitrary IP address you may haveto use more sophticated methods, e.g. implant a trojan horse in the target, letan insider re-congure a specic router or make some cable/hardware modi-cation to the network infrastructure. The most common ways to distribute atrojan horse is to attach it in an e-mail or to merge it with a public software.

3.4.2.3 Buffer Overow

Buffer overow is a witty method for an attacker to gain certain privileges atthe target. All operating systems (OS) have so called system calls that pro-

grammers may use to access different OS resources. These system calls areoften written in some high level language like the C-language. These lan-guages may be delivered with different libraries that contain functions formanipulating strings. Some properties of these functions may be used forlaunching a buffer overow attack because they do not check for strings thatare too long to t in the allocated buffer. If a particular system call uses a vul-nerable string manipulation function, the attacker may be able to execute arbi-trary code with high privileges by passing a string to the system call that is toolong. The arbitrary code is often written for opening a terminal window. For-tunately, there are several simple techniques to eliminate buffer overow vul-nerableties. But developers must be aware of it and always check for stringlengths.A complete description how to launch a buffer overow attack will not begiven because it requires a full understanding how a modern processor man-age function calls. A detailed example is given in [28].It is not only system calls that may be the target for the buffer overow attack but also a SIP stack could be vulnerable to these types of attacks. Of course,this depends on how the stack is implemented. The following example showswhat a vulnerable code for parsing the From header eld could look like:

Figure 7 Example of vulnerable code in a SIP stack.

FromHeader ParseSipFromHeader(char *lpMessageLine) {char temporyStorage[256];FromHeader header;strcpy(temporyStorage, lpMessageLine);...return(header);

}


45/127


33

If a developer uses the code inFigure 7when implementing a SIP proxy serveran attacker may be able to crash the server by sending a From header eld thatcontains more than 256 characters. The source of the vulnerability is the fourthline in Figure 7which overows the allocated buffer on the second line.

3.4.3 Description of potential attacks on SIP

The following tables describe different types of potential attacks on SIP.3.4.3.1 Intercepted messages

Table 5 Potential attacks for a malicious person who is able to interceptmessages.

3.4.3.2 False and spoofed messages

Id Description Achievement Threat class

A1.1 Eavesdroppingmessages.

Gain knowledge about sensi-tive information regardingsignaling information.

Disclosure

A1.2 Rogue proxy thatmodies thereceived message body and forwardsit to the destina-tion.

Able to falsify the informationin the message body, e.g.replace some media codecwith another that presents themedia with lower quality.

Modication,Disclosure

A1.3 Rogue proxy thatmodies the SIPmessage headerand forwards it to

the destination.

Able to change the requestmethod. Able to force furthermessages to be forwardedthrough other proxies.

Modication,Denial of Ser-vice, Unau-thorized

access.


A2.1 Falsied Fromheader eld.

Identity impersonation.In the E-mail case, a user oftenchecks the From value todecide if it originates from anunserious source, i.e. a spam.Same effect might also beachieved in the SIP case,where a user rejects unknownSIP addresses.

Unautho-rized access,Repudiation,Denial of Ser-vice

A2.2 Spoofed BYErequest.

Able to terminate a session. Denial of Ser-vice


46/127


34

Table 6 Potential attacks for a malicious person who is able send false orspoofed messages.

A2.3 Spoofed CANCELrequest.

Able to terminate a pendingINVITE request.

Denial of Ser-vice

A2.4 Spoofed ACK withchanged IP

address in the SDPmessage body.

Able to hijack the media trans-fer.

Unautho-rized access,

Denial of Ser-viceA2.5 Spoofed REGIS-

TER request.Able to remove registrationsfrom a user.

Denial of Ser-vice, Modi-cation

A2.6 Spoofed REGIS-TER request.

Able to overload the registrarwith registrations.


A2.7 Spoofed REGIS-TER request.

Able to initiate a DoS attack byregistrating multiple contactsto same host.


A2.8 Security down-grading.

Able to downgrade authenti-cation scheme to Basic authen-tication.

Unautho-rized access,Disclosure

A2.9 Chosen plaintext. Able to make cryptanalysiseasier for MD5.

Unautho-rized access

A2.10 Sending false 6xxresponses.

Able to fool a user that a calleduser is not willing to acceptcalls.

Denial of Ser-vice



47/127


35

3.4.3.3 Repeated or deliberately erroneous messages

Table 7 Potential attacks for a malicious person who is able repeat ormake deliberately erroneous messages.

3.4.3.4 Intercepted media

Table 8 Potential attacks for a malicious person who is able to spoof theSIP message body.

3.4.3.5 Unwanted and spoofed media

Table 9 Potential attacks for a malicious person who is able to sendspoofed media data.


A3.1 Message ooding. The targets phone never stopsringing and the target isunable to receive non-mali-cious requests.

Denial of Ser-vice

A3.2 Buffer overow. Able to make the target tocrash or to run arbitrary code.

Denial of Ser-vice, Modi-cation,Unautho-rized access

A3.3 Replay messages. Able to make authorizedrequests.



A4.1 Spoofed SIP mes-sage body.

Able to receive sensitivemedia information.

Disclosure


A5.1 Spoofed INVITErequest.

Able to send unwanted mediadata to the target.



48/127


36

3.4.3.6 Password guessing

Table 10 Potential attacks for a malicious person who is able guess pass-words.

3.4.4 Protection

The potential attacks that were mentioned in the sectionPotential attacks onSIP on page 30 are all possible to accomplish on an unprotected system. For-tunately, there are several ways to protect against them. This section will, if possible, propose methods to be protected against them.


A6.1 Online passwordguessing.

Able to guess a small subset of valid passwords to gainauthorized access.


A6.2 Ofine passwordguessing.

Able to guess a large subset of valid password to gain autho-rized access.


Id Protection

A1.1 Because there is no support for encryption between SIP user agentsit is impossible to protect the information that is eavesdropped. SIPhas to rely on the underlying protocols or network protectionagainst eavesdropping.

A1.2 The only way to protect against this kind of attack is by using theintegrity protection that is supported by the Digest authentication,i.e. use auth-int as the qop-value in the Authorization header eld.

A1.3 The Digest authentication detects modication of the requestmethod if the qop-value is specied. Modication of the headerelds are not possible to detect because there is no integrity protec-tion for them.

A2.1 By demanding either Basic or Digest authentication from the source,the receiver can tell from whom the message originates. But thisdoes not guarantee that the From eld is valid because some rogueproxy may have changed the value, see A1.3.

A2.2 Using Digest authentication for Bye requests and with a speciedqop-value. This guarantees that the request originates from a sourcethat knows the secret and that the request method has not beenchanged. Basic authentication can also be used to verify the origin of the message.

A2.3 See protection againstA2.2.


49/127


37

A2.4 First, it should be mentioned that there exist two methods of negoti-ating the media capabilities. In the rst method the negotiationoccurs between the INVITE request from the calling party and the200 OK response from the called party. In the second method thenegotiation occurs between the 200 OK response from the calledparty and the ACK from the calling party. This means that this attackis only possible to accomplish in the second method because in therst method the called party ignores the message body contained inthe ACK.This attack is quite hard to accomplish if the malicious person isunable to eavesdrop the session because he/she has to guess at leastve header values, namely the From, Request-URI, Call-ID, To, Viavalues. Some of these header values are unique and cryptographi-cally random which makes the task harder. If the called party cannot match these header eld values against header eld values from

the INVITE request, then it will discard the ACK.If the malicious person is able to eavesdrop and modify the ACKrequest, then the called party has to force the calling party to useauth-int as the qop-value when it challenges the INVITE request.The need of challenging the INVITE request is necessary because thecalled party is not allowed to challenge the ACK request because noresponse can be sent to an ACK. By challenging the INVITE requestthe called party forces the calling party to use the same credentials inthe Authorization header eld in the ACK.

A2.5 Basic or Digest authentication should be used by the registrar. Digest

authentication is preferred if eavesdropping is possible.A2.6 Basic or Digest authentication should be used by the registrar. Digest

authentication is preferred if eavesdropping is possible.It is also possible to set a limit on the number of registrations a usercan have. But that solution may be used for launching a DoS attack.

A2.7 Basic or Digest authentication should be used by the registrar. Digestauthentication is preferred if eavesdropping is possible.

A2.8 If the client supports Digest authentication it can be congured todemand it. The client can also remember the strongest authentica-

tion scheme used for a particular server. If the server wants a weakerscheme the client should show a warning message before it uses theweaker one.

A2.9 Almost every parameter in the Digest authentication is chosen bythe server which can be used by a rogue server to launch a chosenplaintext attack. But the client can use the cnonce value to make thechecksum stronger. However, there is today no known way to breakthe one-way property of MD5.

Id Protection


50/127


38

Table 11 Proposed protections against potential attacks on SIP.

3.4.5 Published attacks

Because the SIP protocol is relatively young and only a few public SIP serversare up and running, no published attacks have been found. This is will probably not be true in the near future because several new SIP applications willsoon be released.

A2.10 The client should ignore the responses if it requested authentication.The problem is that new requests from the client will reach the samesource as the invalid responses, and the process will repeat. Onesolution is to choose another signaling path by choosing anotherproxy, i.e. change outbound proxy.

A3.1 It is very hard for the client to protect against this type of attack because of its nature. Authentication will prevent the annoyingphone signals but does not protect against the actual attack.

A3.2 The only protection is to use some sort of safe compiler when build-ing the SIP stack because developers may miss some boundarychecks. Dynamically allocated memory may be used instead of localvariables.All header values that specify some type of message length should be considered as unsafe and checked carefully.

Try to avoid usage of environment variables that an arbitrary usercan modify.A3.3 Replays are only a concern when Digest authentication is used. To

get full protection against replays you should change the nonce-value for each challenge. That type of protection requires a lot of resources.Another option is to have strong nonces, i.e. include the clients IP,method, time-stamp and a server key in the nonce generation.

A4.1 The only protection is to use Digest authentication and set the qop-value to auth-int. The server can then verify if the content in themessage body has been changed or not. The responses from theserver can also have modied message bodies and therefore the cli-ent should demand the Authentication-Info header, with the qop-value set to auth-int in the responses.

A5.1 Basic or Digest authentication will protect against this type of attack.A6.1 The used password should be hard to guess, i.e. no default pass-

wo

study of security aspects for sip

Documents