Ofir Arkin

1
E.T. Cant Phone Home Security Issues with VoIP

• Ofir Arkin
• Managing Security Architect

2
Agenda

• VoIP Overview
• The VoIP Threat Module
• The Session Initiation Protocol
• The Session Initiation Protocol Threat Module
• The RTP Protocol
• The RTP Threat Module

3

• Overview
• IP Telephony, VoIP and VON

4
Overview

• IP Telephony is defined as the use of IP networks
  to transmit both voice and data packets
• VON (or Internet Telephony) is used to describe
  the usage of the Internet to transmit both voice
  and data packets
• VoIP is used to describe the usage of managed IP
  networks to transmit both voice and data packets
  (usually associated with Carrier-Class networks)
• In the course of History VON was the predecessor
  of VoIP, and its success led to the interest and
  development of IP Telephony and VoIP
• Do you remember VocalTECs Internet Phone?

5
Overview

• The IETF has defined many standard track IP
  Telephony protocols
• Many IP Telephony protocols are still under a
  development / draft stage at the IETF
• The IP Telephony protocols defined by the IETF
  can be used with different IP Telephony
  architectures
• Internet Telephony
• Internet Telephony Service Providers (ITSPs)
• Corporate LANs
• Converged Network Architecture

6
Overview

• The protocols combining any IP Telephony
  architecture are divided into the following
  roles
• Signaling Protocols
• Media Transport Protocols
• Supporting Protocols

7
Overview Signaling Protocols

• The VoIP Signaling Protocols perform the
  following services
• Locate a User The ability to locate another
  user which whom a user wish to communicate with
• Session Establishment The ability of the called
  party to accept a call, reject a call, or
  redirect the call to another location or service
• Session Setup Negotiation The ability of the
  communicating parties to negotiate the set of
  parameters to use during the session, this
  includes, but not limited to, Audio encoding
• Modify a Session The ability to change a
  sessions parameters such as using a different
  Audio encoding, adding/removing a session
  participant, etc.
• Teardown a Sessions The ability to end a
  session

8
Overview Media Transport Protocols

• The Media Transport Protocols are used to carry
  voice samples (such as the Real Time Transport
  Protocol RTP)
• The media transport protocols are able to use a
  codec to digitize voice and to compress it into
  small samples that will be encapsulated within an
  IP transport protocol (usually UDP) and
  transported using an IP network

9
Overview Supporting Protocols

• These are the protocols which supports the
  various IP Telephony architectures
• For example
• Quality of Service (QoS) protocols (DiffServ,
  IntServ, RSVP, MPLS, 802.1q)
• DNS (with or without extensions)
• Routing TRIP (Telephony Routing over IP)
• Etc.

10
OverviewIETFs VoIP Architecture

• The IETFs VoIP architecture is based on a number
  of protocols, each of which is only a small part
  of the complete solution
• Therefore the IETFs VoIP architecture is a very
  flexible one
• A Telephony Architecture which connects the PSTN
  with VoIPbased Network(s) has to have elements
  which will translate signaling and voice samples
  between the PSTN and the VoIP IP Network and vice
  versa. Therefore some gateways are introduced
  with the infrastructure

11
Overview VoIP Signaling Protocols, Definitions
IETFs VoIP Architecture

• Media Gateway (MG) A network element which
  converts audio signals carried on telephone
  circuits into data packets carried in packet
  switched networks, and vice versa
• Media Gateway Controller (MGC) Used to control
  a Media Gateway
• Signaling Gateway (SG) A network element which
  converts SS7 signaling information from the PSTN
  into formats understood by the network elements
  in the IP network, and presents an accurate view
  of the elements of the IP network to the SS7
  network (and vice versa)

12
Overview VoIP Signaling ProtocolsIETFs VoIP
Architecture

• The VoIP signaling protocols with the IETFs VoIP
  Architecture can be divided into the following
  categories
• Protocols used between the Media Gateway and the
  Media Gateways Controllers (such as MGCP and the
  Megaco protocols), known as Gateway Control
  Protocols (GCP)
• Protocols used between the Media Gateway and the
  Signaling Gateway (such as SCTP, M2UA, M3UA)
• Protocols used between Media Gateway Controllers
  (MGCs) to initiate a session between users (such
  as SIP)
• Protocols used within the IP Network (SIP)

13
The IETFs VoIP Architecture
14
Internet Telephony Architecture Using SIP
15
Overview Security

• ...It is no longer necessary to have a separate
  network for voice...
• With VoIP the Internet Protocol (IP) is the
  vessel for voice transmission, therefore we
  inherit the security problems associated with the
  IP protocol
• The security issues are more complex because of
  the nature of speech (voice quality), and other
  conditions VoIP needs to meet in order to fulfill
  its promise as the next generation in
  Telecommunication
• Other security issues arise from the VoIP
  protocols themselves and from the different
  architectures in which IP Telephony can be
  deployed

16
Mr. Zerga and the IP PhoneOceans Eleven (The
Coca-Cola vs. Pepsi wars of the 80s is back with
VoIP Phones?)
17

• The VoIP Threat Module

18
The VoIP Threat ModuleOverview 1

• The VoIP (and IP Telephony) threat module is
  combined from different number of issues
• The Usage of IP The IP protocols security
  weaknesses are inherited (sniffing, spoofing,
  reply attacks and all the rest of the family)
• There is no separation of networks The signaling
  and media share the same network (they are not
  separated as with the PSTN). It lowers the bar
  regarding potentially misuse of IP Telephony
• The nature of speech Issues such as Delay,
  Latency, Jitter, Packet Loss, Speech Coding
  Techniques, Network Availability, Managing Access
  Priority, etc. There is a burden on maintaining
  adequate speech quality

19
The VoIP Threat ModuleOverview 2

• Continued
• The VoIP Protocols themselves
• Supporting Protocols (DNS)
• VoIP Infrastructure (Phones, Servers, Special
  Servers)
• Supporting Infrastructure (Switches, Routers)
• Different IP Telephony Architectures (leads to
  different security risks)
• Physical Security
• and Supporting Technologies

20
VoIP-based Protocols

• We wish to maintain
• Integrity
• Confidentiality
• Authentication
• NonRepudiation
• We face issues like
• Call Tracking
• Call Hijacking
• Eavesdropping
• Active modifications
• Denial of Service

21
VoIP-based Protocols ( Architecture)

• The placement of the intelligence
• With the PSTN today the signaling intelligence is
  with the Switches
• The phones are just dumb devices
• In the future everything we know today will be
  changed (we see the signs today with the VoIP
  technology)
• With some of the VoIP signaling protocols (like
  SIP) the intelligence is placed at the edges
  the IP phones themselves
• This opens up a wider window opportunity for
  problems initiated by an end user
• As we know, not all clients are born equal
  a.k.a. some will be malicious

22
VoIP-based Protocols

• Authentication
• An IBM Executive Quote from the early days of the
  PCs
• Our goal is to make the computer as easy to
  use as the telephone
• Authenticationof what exactly? Importance of
  Device authentication vs. the failure of user
  authentication
• Or Who the hack wants to authenticate each time
  he needs to use the IP phone?
• Especially not good if you wish to call 911
  services
• When you have a heart attack you do not wish to
  authenticate to call the Ambulance services
• Re-Authentication at predetermined intervals

23
VoIP-based Infrastructure

• The devices
• Phones (usually are not that powerful devices)
• Servers (SIP Proxy, SIP Registrar, SIP Redirect,
  Gatekeepers, Media GWs, Media GW Controllers,
  Signaling GWs, etc)
• Gaining Unauthorized Access
• Remote Access (not on the same local LAN)
• Management interfaces
• Abusing Authentication issues
• Manipulation of settings
• Perform Call tracking
• Etc.

24
VoIP-based Infrastructure

• Physical Access
• To the Phone
• Hard resets (using a button)
• Soft resets (using the phones software)
• Device configuration and manipulation of settings
• Call tracking
• Uploading firmware, adding changing functionality
  and/or adding a permanent backdoor
• etc.

25
VoIP-based Infrastructure

• Physical Access (continued)
• To the Network (more later)
• Free Phone Calls
• Eavesdropping
• Bypassing Filtering
• Bypassing QoS restrictions
• Etc.
• To other VoIP-based devices (you get the
  picture)

26
VoIP-based InfrastructureAvailability

• Shared infrastructure is bad!
• Do you really wish to put the tag of critical
  infrastructure on a shared infrastructure?
• Knock the Switches Off (from the regular data
  network) and you knocked the Voice network as
  well
• Do you trust VLANs?
• No Electricity No Service
• No ability to call emergency services (Violates
  E911 regulations)
• G, here goes our Carrier Grade availability
• Connectivity to different offices in a corporate
  scenario

27
VoIP-based InfrastructureAvailability

• Costs of redundancy, and UPSs for every switch
  and router at the last mile (for a carrier) or in
  a corporate
• Denial of Service
• Even more easy with VoIP, since you really do
  not need to be that smart and use too much
  traffic, but still you can cause outage in the
  whole network, a neighborhood, or a building, or
  on a single end-user (depends on your point of
  presence in the network) a corporate, etc.
• Last Mile Availability problems (in a
  carrier-grade network)

28
The VoIP Threat ModulePhysical Security

• Who said Physical Security?
• The Last Mile is our main concern
• Access to the Physical Wire (and to equipment)
  If achieved all is downhill from there (this
  holds true for any architecture using VoIP as
  well)
• Equipment is likely to be stolen Routers and
  switches are nice decorations for a room
• Physical Tempering Cut the cord Luke

29
The VoIP Threat ModulePhysical Security

• Bypassing simple packet shaping mechanisms
• Getting into the VoIP VLAN An end-of-game

30
The VoIP Threat ModulePhysical Security

• Eavesdropping can be achieved easily if there is
  access to the wire, with no specialized equipment
  other than a hub, a knife, and a clipper.
• Between the IP Phone (or Customer Premises
  Gateway) and the Switch
• Between two switches
• With both scenarios we bypassed any QoS mechanism
  used.

31
The VoIP Threat ModulePhysical Security Free
Phone Calls

• An Advantage Over Phreaking of this sort
  because the eavesdropper can also have free calls
  without the knowledge of the subscriber
• For example, using a different Call-ID to
  differentiate between calls destined to the
  phreaker to the calls destined to the owner of
  the line

32
The VoIP Threat ModuleAccess Technologies

• The Security issues are not limited to
  traditional technologies only
• Various Access Technologies with a Converged
  Network Architecture are susceptible to attacks
• One notable example is Broadband Wireless Access
  Networks using LMDS (Local Multipoint
  Distribution Service). When encryption is used
  between the Base Station to a residential
  transceiver cripples the connection so badly some
  manufactures of LMDS equipment admit it is
  useless
• All you need to have is the right equipment

33
The VoIP Threat ModuleAccess Technologies
34
The VoIP Threat ModuleExample

• Cisco Call Manager Servers where affected by the
  Nimda worm since they where install on a Windows
  2000 Servers with IIS5 (default install)

35
The VoIP Threat ModuleExample

• _at_stake advisory Multiple Vulnerabilities with
  Pingtel xpressa SIP Phones (July 12th, 2002),
  http//www.atstake.com/research/advisories/2002/a0
  71202.txt
• Pingtel xpressa SIP VoIP phones model PX-1
• The Pingtel xpressa SIP-based phone contains
  multiple vulnerabilities affecting all aspects of
  the phones operation. These vulnerabilities
  include remote access to the phone remote
  administrative access to the phone manipulation
  of SIP signaling multiple denials of service
  remote telnet access (complete control of the
  VxWorks operating system) local physical
  administrative access, and more.
• Using the vulnerabilities enumerated within this
  advisory it is possible to jeopardize critical
  telephony infrastructure based on Pingtels
  xpressa SIP phones. Additionally, certain
  vulnerabilities present a severe risk to an
  organizations entire network infrastructure.

36
Other Rants

• Regulations It is the IETF policy not to worry
  about the hooks for wiretapping, but without this
  ability no service provider will be able to
  deploy VoIP (at least in the USA, UK and other
  countries)
• Fraud
• and more

37

• The Session Initiation Protocol

38
SIP History

• SIP was developed within the mmusic working group
  in the IETF
• The work on SIP began in 1995
• Proposed Standard RFC 2543 in February 1999
• Authors Handley (ACIRI), Schulzrinne (Columbia
  University), Schooler (Cal Tech), Rosenberg
  (Bell Labs)
• SIP is part of the Internet Multimedia
  Conferencing Suite
• New SIP RFC 3261, July 2002
• Authors Rosenberg (dynamicsoft), Schulzrinne
  (Columbia University), Camarillo (Ericsson),
  Johnston (Worldcom), Peterson (Neustar) , Sparks
  (dynamicsoft), Handley (ACIRI), Schooler (ATT)

39
What is the Session Initiation Protocol?

• SIP is an application-layer control protocol
  that can establish, modify, and terminate
  multimedia sessions (conferences) such as
  Internet telephony calls. SIP can also invite
  participants to already existing sessions, such
  as multicast conferences. Media can be added to
  (and removed from) an existing session. SIP
  transparently supports name mapping and
  redirection services, which supports personal
  mobility users can maintain a single externally
  visible identifier regardless of their network
  location.
• Text in this section was taken from RFC 3261

40
What is the Session Initiation Protocol?

• SIP supports five facets of establishing and
  terminating multimedia communications
• User location determination of the end system to
  be used for communication
• User availability determination of the
  willingness of the called party to engage in
  communications
• User capabilities determination of the media and
  media parameters to be used
• Session setup ringing, establishment of
  session parameters at both called and calling
  party
• Session management including transfer and
  termination of sessions, modifying session
  parameters, and invoking services.

41
Overview of Operation

• The example shows the basic functions of SIP
  location of an end point, signal of a desire to
  communicate, negotiation of session parameters to
  establish the session, and teardown of the
  session once established.
• This is a typical example of a SIP message
  exchange between two users, Alice and Bob. In
  this example, Alice uses a SIP application on her
  PC (referred to as a softphone) to call Bob on
  his SIP phone over the Internet. Also shown are
  two SIP proxy servers that act on behalf of Alice
  and Bob to facilitate the session establishment.
  This typical arrangement is often referred to as
  the SIP trapezoid as shown by the geometric
  shape of the dashed lines

42
Overview of Operation

• Alice calls Bob using his SIP identity, a type
  of Uniform Resource Identifier (URI) called a SIP
  URI. It has a similar form to an email address,
  typically containing a username and a host name.
  In this case, it is sipbob_at_biloxi.com, where
  biloxi.com is the domain of Bobs SIP service
  provider (which can be an enterprise, retail
  provider, etc). Alice also has a SIP URI of
  sipalice_at_atlanta.com. Alice might have typed in
  Bobs URI or perhaps clicked on a hyperlink or an
  entry in an address book
• SIP is based on an HTTP-like request/response
  transaction model. Each transaction consists of a
  request that invokes a particular method, or
  function, on the server and at least one response

43
Overview of Operation

• In this example, the transaction begins with
  Alices softphone sending an INVITE request
  addressed to Bobs SIP URI.
• INVITE is an example of a SIP method that
  specifies the action that the requestor (Alice)
  wants the server (Bob) to take.
• The INVITE request contains a number of header
  fields. Header fields are named attributes that
  provide additional information about a message.
  The ones present in an INVITE include a unique
  identifier for the call, the destination address,
  Alices address, and information about the type
  of session that Alice wishes to establish with
  Bob.

44
Overview of Operation INVITE
The address which Alice is expecting to receive
responses. This parameter indicates the path the
return message needs to take
The Method name

• INVITE sipbob_at_biloxi.com SIP/2.0
• Via SIP/2.0/UDP pc33.atlanta.combranchz9hG4bK77
  6asdhds
• Max-Forwards 70
• To Bob ltsipbob_at_biloxi.comgt
• From Alice ltsipalice_at_atlanta.comgttag1928301774
  
• Call-ID a84b4c76e66710_at_pc33.atlanta.com
• CSeq 314159 INVITE
• Contact ltsipalice_at_pc33.atlanta.comgt
• Content-Type application/sdp
• Content-Length 142
• (Alices SDP not shown)

A display name and a SIP or SIPS URI towards
which the request was originally directed
Contains a globally unique identifier for this
call
Contains an integer (traditional sequence number)
and a method name
Contains a SIP or SIPS URI that represents a
direct route to Alice
45
Overview of Operation

• The details of the session, type of media, codec,
  sampling rate, etc. are not described using SIP.
  Rather, the body of a SIP message contains a
  description of the session, encoded in some other
  protocol format. One such format is the Session
  Description Protocol (SDP) (RFC 2327). This SDP
  message (not shown in the example) is carried by
  the SIP message in a way that is analogous to a
  document attachment being carried by an email
  message, or a web page being carried in an HTTP
  message

46
Overview of Operation
F2 The atlanta.com proxy server locates the
proxy server at biloxi.com, possibly by
performing a particular type of DNS (Domain Name
Service) lookup to find the SIP server that
serves the biloxi.com domain. As a result, it
obtains the IP address of the biloxi.com proxy
server and forwards, or proxies, the INVITE
request there. Before forwarding the request, the
atlanta.com proxy server adds an additional Via
header field value that contains its own address
(the INVITE already contains Alices address in
the first Via).
F1 Since the softphone does not know the
location of Bob or the SIP server in the
biloxi.com domain, the softphone sends the INVITE
to the SIP server that serves Alices
domain,atlanta.com
F3 the proxy server receives the INVITE request
and sends a 100 (Trying) response back to Alices
softphone. The 100 (Trying) response indicates
that the INVITE has been received and that the
proxy is working on her behalf to route the
INVITE to the destination. This response contains
the same To, From, Call-ID,CSeq and branch
parameter in the Via as the INVITE, which allows
Alices softphone to correlate this response to
the sent INVITE.
F5 The biloxi.com proxy server receives the
INVITE and responds with a 100 (Trying) response
back to the atlanta.com proxy server to indicate
that it has received the INVITE and is processing
the request.
47
Overview of Operation
Each proxy uses the Via header field to determine
where to send the response and removes its own
address from the top. As a result, although DNS
and location service lookups were required to
route the initial INVITE, the 180 (Ringing)
response can be returned to the caller without
lookups or without state being maintained in the
proxies. This also has the desirable property
that each proxy that sees the INVITE will also
see all responses to the INVITE.
F4 The proxy server consults a
database, generically called a location service,
that contains the current IP address of Bob. The
biloxi.com proxy server adds another Via header
field value with its own address to the INVITE
and proxies it to Bobs SIP phone.
F6 Bobs SIP phone receives the INVITE and
alerts Bob ringing. Bobs SIP phone indicates
this in a 180 (Ringing) response, which is routed
back through the two proxies in the reverse
direction.
48
Overview of Operation
If Bob did not wish to answer the call or was
busy on another call, an error response would
have been sent instead of the 200 (OK), which
would have resulted in no media session being
established.
F9 Bob decides to answer the call. When he picks
up the handset, his SIP phone sends a 200 (OK)
response to indicate that the call has been
answered. The 200 (OK) contains a message body
with the SDP media description of the type of
session that Bob is willing to establish with
Alice. As a result, there is a two-phase
exchange of SDP messages Alice sent one to Bob,
and Bob sent one back to Alice. This two-phase
exchange provides basic negotiation capabilities
and is based on a simple offer/answer model of
SDP exchange.
49
Overview of Operation
The first line of the response contains the
response code (200) and the reason phrase (OK)

• SIP/2.0 200 OK
• Via SIP/2.0/UDP server10.biloxi.combranchz9hG4b
  Knashds8 received192.0.2.3
• Via SIP/2.0/UDP bigbox3.site3.atlanta.combranch
  z9hG4bK77ef4c2312983.1 received192.0.2.2
• Via SIP/2.0/UDP pc33.atlanta.combranchz9hG4bK77
  6asdhds received192.0.2.1
• To Bob ltsipbob_at_biloxi.comgttaga6c85cf 465
• From Alice ltsipalice_at_atlanta.comgttag1928301774
  466
• Call-ID a84b4c76e66710
• CSeq 314159 INVITE
• Contact ltsipbob_at_192.0.2.4gt
• Content-Type application/sdp
• Content-Length 131 471
• (Bobs SDP not shown)

Added by biloxy.com SIP Proxy
Added by atlanta.com SIP Proxy
Added by Alices softphone
Contains a URI at which Bob can be directly
reached at his SIP phone.
What method this 200 OK is sent for?
50
Overview of Operation
Finally, Alices softphone sends an
acknowledgement message, ACK to Bobs SIP phone
to confirm the reception of the final response
(200 (OK)). In this example, the ACK is sent
directly from Alices softphone to Bobs SIP
phone, bypassing the two proxies. This occurs
because the endpoints have learned each others
address from the Contact header fields through
the INVITE/200 (OK) exchange, which was not known
when the initial INVITE was sent. The lookups
performed by the two proxies are no longer
needed, so the proxies drop out of the call flow.
This completes the INVITE/200/ACK three-way
handshake used to establish SIP sessions.
In addition to DNS and location service lookups
shown in this example, proxy servers can make
flexiblerouting decisions to decide where to
send a request. For example, if Bobs SIP phone
returned a 486 (Busy Here) response, the
biloxi.com proxy server could proxy the INVITE to
Bobs voicemail server. A proxy server can also
send an INVITE to a number of locations at the
same time. This type of parallel search is known
as forking.
In this case, the 200 (OK) is routed back through
the two proxies and is received by Alices
softphone, which then stops the ringback tone and
indicates that the call has been answered.
51
Overview of Operation

• Alice and Bobs media session has now begun, and
  they send media packets using the format to which
  they agreed in the exchange of SDP. In general,
  the end-to-end media packets take a different
  path from the SIP signaling messages
• During the session, either Alice or Bob may
  decide to change the characteristics of the media
  session. This is accomplished by sending a
  re-INVITE containing a new media description.
• A re-INVITE references the existing dialog so
  that the other party knows that it is to modify
  an existing session instead of establishing a new
  session. The other party sends a 200 (OK) to
  accept the change. The requestor responds to the
  200 (OK) with an ACK.
• If the other party does not accept the change, he
  sends an error response such as 406 (Not
  Acceptable), which also receives an ACK. However,
  the failure of the re-INVITE does not cause the
  existing call to fail the session continues
  using the previously negotiated characteristics

52
Overview of Operation
F13/F14 At the end of the call, Bob disconnects
(hangs up) first and generates a BYE message.
This BYE is routed directly to Alices softphone,
again bypassing the proxies. Alice confirms
receipt of the BYE with a 200 (OK) response,
which terminates the session and the BYE
transaction. No ACK is sent an ACK is only sent
in response to a response to an INVITE request.
53
Overview of Operation Forced Routing
In some cases, it may be useful for proxies in
the SIP signaling path to see all the messaging
between the endpoints for the duration of the
session. For example, if the biloxi.com proxy
server wished to remain in the SIP messaging path
beyond the initial INVITE, it would add to the
INVITE a required routing header field known as
Record-Route that contained a URI resolving to
the hostname or IP address of the proxy. This
information would be received by both Bobs SIP
phone and (due to the Record-Route header field
being passed back in the 200 (OK)) Alices
softphone and stored for the duration of the
dialog. The biloxi.com proxy server would then
receive and proxy the ACK, BYE, and 200 (OK) to
the BYE. Each proxy can independently decide to
receive subsequent messaging, and that messaging
will go through all proxies that elect to receive
it. This capability is frequently used for
proxies that are providing mid-call features.
54
Overview of Operation Registration
Registration is one way that the biloxi.com
server can learn the current location of Bob.
Upon initialization, and at periodic intervals,
Bobs SIP phone sends REGISTER messages to a
server in the biloxi.com domain known as a SIP
Registrar. The REGISTER messages associate Bobs
SIP or SIPS URI (sipbob_at_biloxi.com) with the
machine into which he is currently logged (IP).
The registrar writes this association, also
called a binding, to a database, called the
location service, where it can be used by the
proxy in the biloxi.com domain. Bob is not
limited to registering from a single device. For
example, both his SIP phone at home and the one
in the office could send registrations. This
information is stored together in the location
service and allows a proxy to perform various
types of searches to locate Bob. Similarly, more
than one user can be registered on a single
device at the same time.
The location service is just an abstract concept.
It generally contains information that allows a
proxy to input a URI and receive a set of zero or
more URIs that tell the proxy where to send the
request.
55
Overview of Operation Registration

• F1 REGISTER Bob -gt Registrar
• REGISTER sipregistrar.biloxi.com SIP/2.0
• Via SIP/2.0/UDP bobspc.biloxi.com5060branchz9h
  G4bKnashds7
• Max-Forwards 70
• To Bob ltsipbob_at_biloxi.comgt
• From Bob ltsipbob_at_biloxi.comgttag456248
• Call-ID 843817637684230_at_998sdasdh09
• CSeq 1826 REGISTER
• Contact ltsipbob_at_192.0.2.4gt
• Expires 7200
• Content-Length 0

Associating Bobs URI ltsipbob_at_biloxy.comgt with
the machine he is currently logged (the Contact
information) ltsipbob_at_192.0.2.4gt
The information expires after 2 hours
56
Overview of Operation Registration

• F2 200 OK Registrar -gt Bob
• SIP/2.0 200 OK
• Via SIP/2.0/UDP bobspc.biloxi.com5060branchz9h
  G4bKnashds7 received192.0.2.4
• To Bob ltsipbob_at_biloxi.comgt
• From Bob ltsipbob_at_biloxi.comgttag456248
• Call-ID 843817637684230_at_998sdasdh09
• CSeq 1826 REGISTER
• Contact ltsipbob_at_192.0.2.4gt
• Expires 7200
• Content-Length 0

All Current Binding of ltsipbob_at_biloxy.comgt
57
Overview of Operation CANCEL
The CANCEL request, as the name implies, is used
to cancel a previous request sent by a client
(only INVITEs). Specifically, it asks the UAS to
cease processing the request and to generate an
error response to that request. CANCEL has no
effect on a request to which a UAS has already
given a final response (200 OK). A UAS that
receives a CANCEL request for an INVITE, but has
not yet sent a final response, would stop
ringing, and then respond to the INVITE with a
specific error response (a 487).
58
Overview of Operation CANCEL
If the UAS has already sent a final response for
the original request, the CANCEL request has no
effect on the processing of the original request,
no effect on any session state, and no effect on
the responses generated for the original request.
If the UAS did not find a matching transaction
for the CANCEL according to the procedure above,
it SHOULD respond to the CANCEL with a 481 (Call
Leg/Transaction Does Not Exist).
59
Overview of Operation OPTIONS

• The SIP method OPTIONS allows a UA to query
  another UA or a proxy server as to its
  capabilities. This allows a client to discover
  information about the supported methods, content
  types, extensions, codecs, etc. without ringing
  the other party.

60
Overview of Operation OPTIONS

• OPTIONS sipcarol_at_chicago.com SIP/2.0
• Via SIP/2.0/UDP pc33.atlanta.combranchz9hG4bKhj
  hs8ass877
• Max-Forwards 70
• To ltsipcarol_at_chicago.comgt
• From Alice ltsipalice_at_atlanta.comgttag1928301774
  
• Call-ID a84b4c76e66710
• CSeq 63104 OPTIONS
• Contact ltsipalice_at_pc33.atlanta.comgt
• Accept application/sdp
• Content-Length 0

61
Overview of Operation OPTIONS

• SIP/2.0 200 OK
• Via SIP/2.0/UDP pc33.atlanta.combranchz9hG4bKhj
  hs8ass877 received192.0.2.4
• To ltsipcarol_at_chicago.comgttag93810874
• From Alice ltsipalice_at_atlanta.comgttag1928301774
  
• Call-ID a84b4c76e66710
• CSeq 63104 OPTIONS
• Contact ltsipcarol_at_chicago.comgt
• Contact ltmailtocarol_at_chicago.comgt
• Allow INVITE, ACK, CANCEL, OPTIONS, BYE
• Accept application/sdp
• Accept-Encoding gzip
• Accept-Language en
• Supported foo
• Content-Type application/sdp
• Content-Length 274
• (SDP not shown)

62
Protocol Components

• User Agent Client (UAC)
• End Systems
• Send SIP Requests
• User Agent Server (UAS)
• Listening for Incoming Requests
• Execute an internal logic/program to determine
  the appropriate response
• User Agent
• UAC UAS

63
Protocol Components

• Redirect Server
• Redirect callers (requests) to another Server
• Proxy Server
• Relay Call Signaling (Proxy requests to another
  server)
• Can fork requests to multiple targets
• Able to maintain basic Call-State (or not)
• Registrar
• Receives registrations requests regarding current
  user locations
• Stores the information at a Location Server

64
SIP Methods (Core Methods)

• INVITE
• Initiate Sessions
• Change a Session state via re-INVITEs
• ACK
• Confirms Session Establishment
• BYE
• Terminates Sessions
• CANCEL
• Cancels an INVITE request sent by a client not
  already sent a final response for
• OPTIONS
• Query another UA or a proxy server as to its
  capabilities
• REGISTER
• Binds permanent address to the current location

65
SIP Response Codes

• 1xy Information or Provisional - Request in
  progress but not yet completed
• 100 Trying
• 180 Ringing
• 181 Call is Being Forwarded
• 182 Queued
• 183 Session Progress
• 2xy Success - the request has completed
  successfully
• 200 OK

66
SIP Response Codes

• 3xy Redirection - another location should be
  tried for the request
• 300 Multiple Options
• 301 Moved Permanently
• 302 Moved Temporarily
• 305 Use Proxy
• 380 Alternative Service

67
SIP Response Codes

• 4xy Client Error due to an error in the
  request, the request was not completed . The
  client SHOULD NOT retry the same request without
  modification (for example, adding appropriate
  authorization). However, the same request to a
  different server might be successful.
• 400 Bad Request
• 401 Unauthorized
• 402 Payment Required
• 403 Forbidden
• 404 Not Found
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 408 Request Timeout

68
SIP Response Codes

• 410 Gone
• 413 Request Entity Too Large
• 414 Request URI Too Long
• 415 Unsupported Media Type
• 416 Unsupported Media Scheme
• 420 Bad Extension
• 421 Extension Required
• 423 Interval Too Brief
• 480 Temporarily Unavailable
• 481 Call/Transaction Does Not Exist

• 482 Loop Detected
• 483 Too Many Hops
• 484 Address Incomplete
• 485 Ambiguous
• 486 Busy Here
• 487 Request Terminated
• 488 Not Acceptable Here
• 491 Request Pending
• 493 Undecipherable

69
SIP Response Codes

• 5xy Server Failure the request was not
  completed due to error in recipient. Can be
  retried at another location
• 500 Server Internal Error
• 501 Not Implemented
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Server Time-Out
• 505 Version Not Supported
• 513 Message Too Large

70
SIP Response Codes

• 6xy Global Failure request was failed and
  should not be retried again
• 600 Busy Everywhere
• 603 Decline
• 604 Does Not Exist Anywhere
• 606 Not Acceptable

71
SIP Architecture (I Proxy)
Location Service
DNS Server
sip.biloxy.com
SIP Proxy
2. Store
7. FW INVITE
910. Query Respond
56. DNS Query
16. 200 OK
8. 100 Trying
13. 180 Ringing
11. FW INVITE
15. 200 OK
SIP Registrar
1. Register
SIP Proxy
12. 180 Ringing
sip.atlanta.com
3. INVITE
4. 100 Trying
14. 180 Ringing
20. BYE
17. 200 OK
18. ACK
SIP UA B
sipbob_at_biloxy.com
19. Media Transport is opened
21. 200 OK
SIP UA A
sipalice_at_atlanta.com
72
SIP Architecture (II Proxy Redirect)
sip.new-york.com
SIP Redirect Server
Location Service
DNS Server
sip.biloxy.com
SIP Proxy
7. FW INVITE
8. Redirect sip.biloxy.com
2. Store
9. FW INVITE
1112. Query Respond
56. DNS Query
18. 200 OK
10. 100 Trying
15. 180 Ringing
13. FW INVITE
17. 200 OK
SIP Registrar
1. Register
SIP Proxy
14. 180 Ringing
sip.atlanta.com
3. INVITE
4. 100 Trying
16. 180 Ringing
22. BYE
19. 200 OK
20. ACK
SIP UA B
sipbob_at_biloxy.com
21. Media Transport is opened
23. 200 OK
SIP UA A
sipalice_at_atlanta.com
73
SIP Architecture (III The Principle of Mobility)
Location Service
DNS Server
sip.biloxy.com
SIP Proxy
2. Store
7. FW INVITE
910. Query Respond
56. DNS Query
8. 100 Trying
13. FW Redirect
11. FW INVITE
14. FW INVITE
SIP Registrar
1. Register
17. 200 OK
SIP Proxy
15. 180 Ringing
12. 3xx Redirect
sip.atlanta.com
3. INVITE
4. 100 Trying
16. 180 Ringing
19. ACK
18. 200 OK
SIP UA B
21. Bye
sipbob_at_biloxy.com
SIP UA B
20. Media Transport is Open
bob_at_somewhere.else
22. 200 OK
SIP UA A
sipalice_at_atlanta.com
74
SIP Message Structure

• Some Other Time

75
The Change of Tides

• With RFC 2543 UDP was used as the underlying
  transport protocol for SIP
• The IETF demanded that with the new version of
  SIP, Security will be an integral part of the
  protocol
• Since UDP is hard to secure (IPSec only) the
  authors of the new version of the protocol turned
  to TCP. Up until that point they argued that UDP
  is a better solution for transport of SIP
  signaling (no retransmissions, and other)
• So Dorothy had to buckle up because Kansas gone
  bye bye

76

• The SIP Threat Module

77
SIP Threat Module

• Assumption
• An Attacker Is On the Wire
• This list is only a partial list

78
Threats

• Denial-of-Service
• CANCEL
• BYE
• Using response codes
• ICMP Error Messages for UDP datagrams
• Call Hijacking
• Through the Registrar
• Through the usage of 3xy response code messages
• Mid-Session tricks

79
Threats

• Man in the Middle (MITM) Attacks
• Through the usage of 301 302 Response codes
• Through the usage of 305 (Use Proxy) response
  code
• No intelligence/control of the Media stream
  during a session
• Covert Channels
• Unknown Header fields
• Enumerating
• OPTIONS
• Call Leg does not exists
• Max - Forwards

80
Threats

• Wiretapping
• Whos in my path?
• SIP Proxies are allowed to send messages through
  a set of additional proxies
• Call Tracking
• Clients are Malicious
• Design Issues
• Predictable Values

81
Denial of Service CANCEL
SIPcarol_at_biloxy.com
SIP UA C
Location Service
DNS Server
sip.biloxy.com
SIP Proxy
2. Store
910. Query Respond
7. FW INVITE
56. DNS Query
15. CANCEL
8. 100 Trying
11. FW INVITE
13. 180 Ringing
SIP Registrar
1. Register
SIP Proxy
12. 180 Ringing
sip.atlanta.com
3. INVITE
4. 100 Trying
14. 180 Ringing
SIP UA B
SIPbob_at_biloxy.com
The CANCEL needs to hit Bobs SIP Phone before
it sends the 200 OK. This is a Denial-of-Service
on Bob
SIP UA A
SIPalice_at_atlanta.com
82
Denial of Service CANCEL
The CANCEL needs to hit Bobs SIP Phone before
it sends the 200 OK. This is a Denial-of-Service
on Alice. Whenever Alice sends an INVITE, carol
will CANCEL it.
Location Service
DNS Server
sip.biloxy.com
SIP Proxy
2. Store
910. Query Respond
7. FW INVITE
56. DNS Query
8. 100 Trying
SIPcarol_at_biloxy.com
11. FW INVITE
13. 180 Ringing
SIP UA C
12. 180 Ringing
SIP Proxy
SIP Registrar
1. Register
sip.atlanta.com
3. INVITE
4. 100 Trying
15. CANCEL
14. 180 Ringing
SIP UA B
SIPbob_at_biloxy.com
SIP UA A
SIPalice_at_atlanta.com
83
Denial of Service BYE
SIPcarol_at_biloxy.com
SIP UA C
Location Service
16. BYE
7. Query
2. Store
sip.biloxy.com
SIP Proxy
5. FW INVITE
8. Reply
10. 100 Trying
13. 200 OK
6. 100 Trying
14. FW 200 OK
11. FW 100 Trying
SIP Registrar
SIP Proxy
1. Register
9. FW INVITE
sip.atlanta.com
3. INVITE
SIP UA B
12. FW 100 Trying
SIPbob_at_biloxy.com
4. 100 Trying
15. FW 200 OK
As soon as the 200OK will be sent from Bobs SIP
Phone to Alices SIP Phone, Carol will send a BYE
request to either Bob or Alice or both
SIP UA A
SIPalice_at_atlanta.com
84
Denial of Service BYE (to Alice)
SIPcarol_at_biloxy.com
SIP UA C
Location Service
16. BYE
sip.biloxy.com
26. 481 Call/Transaction Does Not Exist
SIP Proxy
27. 481 Call/Transaction Does Not Exist
20. FW 200 OK
21. FW 200 OK
17. FW BYE
SIP Registrar
SIP Proxy
22. Any SIP Message
23. FW Any SIP Message
19. 200 OK
sip.atlanta.com
25. 481 Call/Transaction Does Not Exist
SIP UA B
24. FW Any SIP Message
SIPbob_at_biloxy.com
18. FW BYE
The session does not exist on the SIP Proxy
anymore, but it will pass the message
The 200OK is sent to acknowledge the BYE request
200 OK received (The transaction is non-existent
on Alices SIP Phone ONLY)
SIP UA A
We got a mismatch
SIPalice_at_atlanta.com
85
Denial of Service BYE (to Bob)
SIPcarol_at_biloxy.com
SIP UA C
Location Service
sip.biloxy.com
16. BYE
SIP Proxy
18. FW 200 OK
SIP Registrar
17. 200 OK
SIP Proxy
sip.atlanta.com
SIP UA B
19. FW 200 OK
SIPbob_at_biloxy.com
SIP UA A
The session does not exist any more on Bobs
SIP Phone
SIPalice_at_atlanta.com
86
Denial of Service BYE (to Both)
When a fake BYE will be sent to one of the
participants in a dialog, that participant will
generate a 200 OK reply. To avoid detection the
BYE will be sent simultaneously to both
participants, and the 200 OK responses, although
generated for a different message will not be
suspected (Sequence of both BYE will be the same)
SIPcarol_at_biloxy.com
SIP UA C
Location Service
16. BYE (B-gtA)
sip.biloxy.com
16. BYE (A-gtB)
SIP Proxy
18. FW 200 OK
19. FW 200 OK
18. FW 200 OK
SIP Registrar
17. 200 OK
SIP Proxy
17. 200 OK
sip.atlanta.com
SIP UA B
19. FW 200 OK
SIPbob_at_biloxy.com
The malicious party will send the BYE request not
through the SIP Proxies but direct to the dialog
participants. This to avoid cases in which a
stateful proxy might take action for the BYE SIP
request.
SIP UA A
SIPalice_at_atlanta.com
87
Denial of Service Using Response Codes

• A malicious party can use several response codes
  in order to introduce a denial of service
  condition
• 4xx responses are definite failure responses
  from a particular server. The client SHOULD NOT
  retry the same request without modification (for
  example, adding appropriate authorization).
  However, the same request to a different server
  might be successful.
• 5xx responses are failure responses given when a
  server itself has erred.
• 6xx responses indicate that a server has
  definitive information about a particular user,
  not just the particular instance indicated in the
  Request-URI.

88
Call HijackUsing Manipulation of the
Registration Records
Associating Bobs URI ltsipbob_at_biloxy.comgt with
the attackers machine ltsipbob_at_192.168.1.10gt
SIPcarol_at_biloxy.com
SIP UA C
Location Service
10. FW INVITE
2. Store
sip.biloxy.com
3. Register
4. Store
SIP Proxy
8. Query
6. FW INVITE
9. Reply
7. 100 Trying
SIP Registrar
SIP Proxy
1. Register
sip.atlanta.com
4. INVITE
SIP UA B
SIPbob_at_biloxy.com
5. 100 Trying
Associating Bobs URI ltsipbob_at_biloxy.comgt with
the machine he is currently logged (the Contact
information) ltsipbob_at_192.168.1.5gt
SIP UA A
SIPalice_at_atlanta.com
89
Call Hijack Using Manipulation of the
Registration Records

• You can query the SIP Registrar for the list of
  addresses of a particular SIP URI
• You will be given the list of addresses
  associated with your SIP URI with each successful
  registration
• But does your UA will show it up? Probably not
  (we tried this NO!)
• You can give your registration higher priority
  than the other record (not deleting other records)

90
Call Hijack Using Manipulation of the
Registration Records

• Or, you can register with a lower priority and
  perform a denial of service on the higher
  priority entry, so the SIP Proxy will not be able
  to deliver-to-it and will turn to the next
  entry with the Registrar
• The Registrar can require the registering party
  (which can be a 3rd party as well) to
  authentication before receiving the registration
  information. But, since the characteristics of
  the registration with SIP requires registration
  each hour for the same SIP URI, by default, it is
  unlikely that a SIP phone user will authenticate
  to the Registrar each hour
• Instead, what most of the SIP-based phones does
  is store the username and password information
  with the phone (other attack venues) and perform
  autentication automatically for the user when
  required (not always works smoothly)

91
Call Hijack Using 301 Moved Permanently Response
Code
The INVITE that was originally sent to
bob_at_biloxy.com, is now being sent to the address
given with the 301 spoofed response code,
bob_at_foobar_IP (carols SIP Phone). Therefore the
query goes to Carols SIP phone rather than to
Bobs
SIPcarol_at_IP_ADDRESS
sip.biloxy.com
SIP UA C
SIP Proxy
4. 301 Moved Permanently
3. FW INVITE
6. FW INVITE
5. INVITE
SIP Proxy
SIP UA B
sip.atlanta.com
1. INVITE
SIPbob_at_biloxy.com
2. 100 Trying
The user can no longer be found at the address
in the Request-URI, and the requesting client
SHOULD retry at the new address given by the
Contact header field. The requestor SHOULD update
any local directories, address books, and user
location caches with this new value and redirect
future requests to the address(es) listed.
SIP UA A
SIPalice_at_atlanta.com
92
Call Hijack Using 30x Messages

• The location of the malicious entity can be
  anywhere (Alices network, Bobs network,
  in-between networks)
• One can also use the 302 Moved Temporarily
  Response Code
• The requesting client SHOULD retry the request
  at the new address(es) given by the Contact
  header field. The Request-URI of the new request
  uses the value of the Contact header field in the
  response.
• The duration of the validity of the Contact
  URI can be indicated through an Expires header
  field or an expires parameter in the Contact
  header field. Both proxies and UAs MAY cache this
  URI for the duration of the expiration time. If
  there is no explicit expiration time, the address
  is only valid once for recursing, and MUST NOT be
  cached for future transactions. If the URI cached
  from the Contact header field fails, the
  Request-URI from the redirected request MAY be
  tried again a single time.

93
Call Hijack Mid Session Tricks / Re-INVITE me
baby one more time!

• this modification can involve changing
  addresses or ports, adding a media stream,
  deleting media stream, and so on, this is
  accomplished by sending a new INVITE request
  within the same dialog that established the
  sessionalso known as Re-INVITE
• Hijack the signaling path you are able to
  introduce new routing into the signaling path of
  a current session
• Deny signaling from any side to your benefit
• Can evolve to introducing other participants to
  the session
• Eavesdropping made easy

94
MITM Attacks

• 301 and 302 Response codes can be spoofed as
  responses coming from any SIP element
• SIP Registrar
• SIP Proxy Server
• SIP Redirect Server
• SIP UA
• More creativity 305 Use Proxy Response Code

95
MITM Attacks 302 Moved Temporarily
Carol is now acting as a SIP Proxy
sip.biloxy.com
SIP Proxy
Carols Proxy
6. FW INVITE
4. FW INVITE
5. 100 Trying
SIP Proxy
2. 302 Moved Temporarily
3. INVITE
sip.atlanta.com
SIP UA B
1. INVITE
SIPbob_at_biloxy.com
302 Moved Temporarily - The requesting client
SHOULD retry the request at the new address(es)
given by the Contact header field. The
Request-URI of the new request uses the value of
the Contact header field in the response.
SIP UA A
SIPalice_at_atlanta.com
96
MITM Attacks vs. Registrar
Carol is spoofing a 301 Moved Permanently
response message allegedly coming from the
REGISTRAR
SIPcarol_at_biloxy.com
Location Service
SIP UA C
Carol has bobs credentials Game Over
7. Register request for bobs credentials
4. 401 Unauthorized
8. Store
3. Register
2. 301 Moved Permanently
5. Register request with appropriate credentials
6. Confirm Registration
SIP Registrar
1. Register
SIP UA B
SIPbob_at_biloxy.com
Bobs SIP Phone performs a registration request
97
MITM Attacks 305 Use Proxy, orThe Whos your
Daddy? Attack
Carol is now acting as a SIP Proxy
sip.biloxy.com
SIP Proxy
Carols Proxy
6. FW INVITE
4. FW INVITE
5. 100 Trying
SIP Proxy
2. 305 Use Proxy
3. INVITE
sip.atlanta.com
SIP UA B
1. INVITE
SIPbob_at_biloxy.com
The requested resource MUST be accessed through
the proxy given by the Contact field. The Contact
field gives the URI of the proxy. The recipient
is expected to repeat this single request via the
proxy. 305 (Use Proxy) responses MUST only be
generated by UASs.
SIP UA A
SIPalice_at_atlanta.com
98
No intelligence/control of the Media stream
during a session

• Signaling goes one way, Media goes another way
• Some device needs to control the creation of
  Media streams no media stream without the
  appropriate signaling (who came first the chicken
  or the egg problem)
• If there is a modification to the Media stream
  along the call (through the usage of RTP or
  RTCP, for example) the SIP signaling protocol
  will not be aware of it
• If the codec used will be changed using the media
  transport protocol SIP is simply blind.
• In the case the media stream will be cut the SIP
  elements participating in the session (especially
  the SIP UAs) will not get indication that the
  media is cut They will have to understand that
  the conversation was cut

99
No intelligence/control of the Media stream
during a session

• There is no control of the pipeline for the
  Media stream. Therefore a malicious party can
  change the codec used through the Media protocol
  used, and use a codec which demands more
  bandwidth (and therefore its usage will raise the
  packet loss and we will have a lower quality, or
  even a poor quality of speech)
• No Provisioning what so ever on the Media stream

100
Enumeration

• If the UAS did not find a matching transaction
  for the CANCEL according to the procedure it
  SHOULD respond to the CANCEL with a 481 (Call
  Leg/Transaction Does Not Exist).
• OPTIONS method
• The Max-Forwards header value represents the
  maximum number of SIP devices this request can
  route through. The default value is 70 (a nice
  rounded number)

101
Covert Channels

• If you will introduce a fake SIP header field
  with a SIP message it will be allowed across all
  components of a SIP based solution
• Future header support It Just Rock!

102
Call Tracking

• Defined as Logging of the source and
  destination of all numbers being called
• Capturing DTMFs along with other signaling
  traffic will give an attacker the opportunity to
  capture voice mail passwords (rings a bell?),
  calling card information, credit card
  information, or any other data entered using DTMF
• With SIP all we need is to track INVITE messages
• If the BYE is also recorded the duration of the
  call can also be tracked, and other bits of
  information

103
Call Tracking

• INVITE sipbob_at_biloxi.com SIP/2.0
• Via SIP/2.0/UDP pc33.atlanta.combranchz9hG4bK77
  6asdhds
• Max-Forwards 70
• To Bob ltsipbob_at_biloxi.comgt
• From Alice ltsipalice_at_atlanta.comgttag1928301774
  
• Call-ID a84b4c76e66710_at_pc33.atlanta.com
• CSeq 314159 INVITE
• Contact ltsipalice_at_pc33.atlanta.comgt
• Content-Type application/sdp
• Content-Length 142
• (Alices SDP not shown)

104
Clients are Malicious

• SIPs threat module according to the SIP WG does
  not include malicious clients
• If I am using a malicious client (my stack
  instead of the manufactures stack or a modified
  one) and I am the called party, I can, for
  example, strip any Record-Route headers and not
  bother with those. As a direct response to this,
  not my client, and most importantly the caller
  will send signals beyond the three-way SIP
  handshake through any SIP Proxy as we like
• The official SIP threat module does not take
  into consideration that when two friends use
  the network they will be able to unveil the
  routing path with nearly no hassle (see example
  at the next slide)
• There is also a lot more to this one

105
Clients are Malicious
A conspirator will have all the route taken (at
least the entities that needs to be passed
through) in the VIA headers
Location Service
sip.somewhere.com
SIP Proxy
Encrypted
Encrypted
Might be Encrypted
SIP Proxy
SIP Registrar
Might be Encrypted
SIP Proxy
sip.biloxy.com
sip.atlanta.com
SIP UA B
SIPbob_at_biloxy.com
SIP UA A
SIPalice_at_atlanta.com
106
More Issues

• Predicted Values
• Firewalls NAT
• Bypassing the SIP Proxy Bypassing Billing
  (where is my CDR syndrome)
• No Control on Media streams Bypassing Billing
  using tunneling with the Media streams protocols
• Fraud if you are only looking at CDRs produces
  Well, you are a complete idxxx Most important
  is to look at the network traffic

107

• Security Mechanisms with the SIP Protocol

108
Security Mechanisms with the SIP Protocol

• TLS support
• TLS is only good for TCP
• This means that if you wish to use UDP for the
  transport of your SIP messages you will not have
  security (accept for body encryption)
• It is only RECOMMENDED that a UA will be able to
  initiate a TLS based connection
• Digital Certificated Usage and the missing piece
  it is only for the SIP Servers to use digital
  certificates. Clients are not required to have
  one
• Without certificates at the client side we just
  have at the end of the process an encrypted
  communication channel between two parties without
  authenticating their identity
• 12 messages to establish a session, which
  according to the RFC needs to be kept alive all
  the time

109
Security Mechanisms with the SIP Protocol

• S/MIME for message bodies (key distribution)
• Digest Authentication
• With encryption firewalls will be useless when
  they have the ability to really understand the
  protocol (remember Max-Forwards for example?)

110

• Multimedia Communication (RTP RTCP)

111
Multimedia Communication (RTP RTCP)

• The main concern is the ability to control any
  part of a media stream by manipulating the
  appro