[VOIPSEC] VoIP and Banking Security

[Geoff Devine]

I guess it's all about what you mean by "dumb".  Cellular providers
naturally want to do things in a network-centric/master-slave way.  In
the PacketCable flavor of VoIP over Cable, we have taken the same
approach.  What the end user cares about is features, not whether
intelligence and control are at the user device or centralized at the
core.

For example, you could implement Push-to-Talk by having a cell phone
send SIP messages directly to all the other cell phones in their group.
That's a pure peer-to-peer topology.  What 3GPP/IMS does is have the
cell phone signal the Push-to-Talk feature to the core and the core
implements the feature.

Of course, the point I'm trying to make in all of this is that
master-slave architectures are much easier to engineer, make stable, and
secure than peer-to-peer architectures.  In a master-slave architecture,
the core is trusted.  You have a contract with the service provider.  In
a peer-to-peer topology with a very thin core that merely routes
messages, you really can't trust anything.  In peer-to-peer, people rely
on implementation agreements to make their environment stable. When you
allow hackers to send arbitrary mal-formed SIP messages into the
environment and don't have a heavyweight core service to police the
protocol, every element in the network that can receive SIP messages is
vulnerable to attack.

Geoff

-----Original Message-----
From: Pankaj Shroff [mailto:shroffg at gmail.com] 
Sent: Thursday, June 30, 2005 11:20 AM
To: Geoff Devine
Subject: Re: [VOIPSEC] VoIP and Banking Security

Thats an excellent observation - doesn't apply to non-GSM though -
i.e. CDMA which is prevalent in the US market. Also, the flip side is
its relatively easy to impersonate someone else by simply acquiring a
SIM chip :) I mean i have bought these on the streets of Bombay for US
$25 with no need for authentication. But your point is well taken,
compressed and encoded SIP signalling as defined by 3GPP/IMS is a big
step towards wireless security. What about home wireline, and Wifi and
fixed wireless, and wifi with mobile wireless (wimax, others) though?
Does the GSM concept apply to all CPE devices? Are consumers going to
be happy with "dumb" terminals? With more and more applications,
ringtones, content being pushed to these terminals how "dumb" can they
really be?

Pankaj Shroff
UCN Inc.


On 6/30/05, Geoff Devine <gdevine at cedarpointcom.com> wrote:
> I'd point out that GSM phones in 3GPP/IMS use SIM chip technology.  To
get a SIM chip for your GSM phone, you have to sign a contract with a
GSM service provider.  It's extremely difficult to clone a SIM chip so
the service provider has high confidence that the digital certificate
the handset is presenting is genuine unless the SIM chip is physically
stolen.  SIP signaling happens over transport mode ESP IPSec with IKE as
the key exchange mechanism.  The SIP variant spoken by 3G handsets is
very compressed and limited.  The handset is kept "dumb" and the
intelligence is all in the core.  The P-CSCF core device the handset
talks to polices this signaling and expands it into a more vanilla SIP.
This isn't vanilla SIP on a personal computer.  It's quite secure and
very paranoid with respect to the SIP signalling that emits from the
handset.
> 
> If you open up your 3G wireless network to vanilla SIP and don't
require SIM chips to create digital certificates, you open yourself up
to all kinds of security risks.  I think the biggest risk is that
intentially malformed SIP messages can damage the network.  You can
mitigate many of the risks by profiling SIP and rejecting SIP messages
that don't meet the profile but it's mathematically impossible to write
a program that guarantees that a SIP message or message sequence won't
damage any elements of the core network and won't start crashing
endpoints which can't handle those SIP messages.  The best you can do is
select a very tight profile for SIP behavior and build a tunable
protocol policing mechanism so you can prevent new types of attacks as
they occur.  This creates a conflict between the objective of enabling
rapid service creation (new features at the endpoint) and the objective
of hardening the network.  From a security standpoint, it's much easier
to cope with dumb endpoints and a smart core and that's the approach IMS
has taken.
> 
> Geoff
> 
> 
> 
> DePietro, John wrote on 6/28/05, 7:35 AM:
> 
>  > Hi Brian et. All,
>  >
>  > I just wanted to voice my opinion regarding the importance of
address
>  > SIP/VoIP security.  I have spoken to many European, Asian and US
>  > Wireless carriers and this topic always runs at the top of list.
>  >
>  > Many Wireless carrier will be rolling out IMS/MMD (3GPP/3GPP2
>  > standards based on SIP/VoIP IETF standards) over the next 5 years.
>  > They are also working through business models to converge 3G, Fixed
>  > and Fixed Mobile networks.  IMS/MMD is opening up an opportunity
for
>  > Wireless carriers to expand new business models to hosted
Enterprise
>  > multimedia services.  This means that in the next 2 years 10s of
>  > millions of IMS/MMD SIP/VoIP clients will be roaming the planet on
>  > smart phones, which have widely open OSes with ample processing
power
>  > to entice any hackers and deviants.  This puts SIP/VoIP security
front
>  > and center.
>  >
>  > The reality is that Security was never intended to make anyone
money,
>  > but to prevent from loosing money (e.g. free VoIP call over EVDO),
>  > protecting privacy (e.g. Mobile financial transactions) or limiting
a
>  > market opportunity (e.g. offer VPN hosted to Enterprise customers).
I
>  > view Security as a key enabler for SIP/VoIP and part of doing
business
>  > in IP telephony.
>  >
>  > These discussion and this forum are a good thing.  I would like to
see
>  > some more dialogue with regards to Wireless related (3G and WLAN)
>  > security concerns and general comments of proposed security
>  > architecture for IMS/MMD.  Interestingly enough, ETSI TISPAN has
>  > embraced IMS so now we have Wireless/Wireline standards body
convergence.
>  >
>  > John
>