[VOIPSEC] Actual Attacks

Wed Feb 23 22:02:59 CST 2005

I would like clarification regarding your comment below: 

"> SBCs and firewalls are very unfriendly to any signaling security, because
> they want to peer into the signaling, and sometimes alter it.  They could
> be
> more visible in the process; for example, a firewall or SBC could be a
> real
> SIP proxy server, in the routing path, and thus be a hop in the TLS path."

The fact that an organization or individual places the trust on SIP
endpoints, in this case, to basically bypass security measures (which you
stated are unfriendly to signaling security) is ludicrous to me. 

Firewalls and border controllers are not merely in place to facilitate VoIP,
:) well at least not the former. They are in place to protect the
infrastructure from unauthorized use of resources at various levels, whether
it is a home user, enterprise application, or carrier service. But they are
not the silver bullet either.

Firewalls are becoming more intelligent as they evolve to meet the needs of
these new protocols and applications and because they have to in order to
provide the protection that they were originally intended for. They are a
fact of life that will not go away. IDS's and IPS's are also going to have
to evolve in this direction too.

SIP and other peer to peer protocols like it pose a very real threat to
these environments. The very fact that we developed the enablement of these
protocols through these security mechanisms means that the dynamic pinholes,
port redirections, and what have you, are now fully authorized conduits of
whatever mischief can be thought up unless the security mechanism can "peer"
into the signaling and/or media to determine authorization and
authentication is not being attacked.

What we have to do is determine how to find the middle ground to an
acceptable risk and develop this so that there can be confidence in using
the applications derived from it.

Signaling security should also be designed with these things in mind, not
just the other way around...infrastructures are built of many components,
some are standards based, and some are for survival. You have to look at the
whole picture.
________________________________

Christopher A. Martin
P.O. Box 1264
Cedar Hill, Texas 75106

Domains.SIP1.com
http://domains.sip1.com 
Low cost domain name registration & other Internet services.

Sign up for your PayPal merchant account today and start selling your
products on line today!
https://www.paypal.com/us/mrb/pal=Q622ZEE3CUWM8

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Brian Rosen
> Sent: Wednesday, February 23, 2005 8:54 AM
> To: 'Simon Horne'; voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> Yep, you are wrong.
> 
> SIP has a complete security mechanism that allows security of both media
> and
> signaling.  It uses TLS for signaling between routing elements (hop by
> hop),
> as well as S/MIME for security of signaling end to end.  It uses sRTP
> with a couple of options for keying for the media.  TLS security is
> visible
> to users and other elements by using the "sips:" URI scheme, similar to
> "https:".  The far end can determine if all intermediate signaling
> entities
> successfully enabled TLS for a "sips:" call, assuring security.
> 
> The only deployment issues for SIP are the same as those for H.323, viz.
> if
> you encrypt the signaling, firewalls and other intermediaries can't see
> what
> is happening and may reject it, and if you have an element such as an SBC
> that wants to rewrite parts of the signaling that it should not be
> rewriting, if you integrity protect the message, security will fail due to
> the tampering.
> 
> There have been some implementation issues that have created some
> interoperability problems, but there is a draft out that supplies guidance
> to implementers that should ameliorate the issues that have been found in
> testing.
> 
> SBCs and firewalls are very unfriendly to any signaling security, because
> they want to peer into the signaling, and sometimes alter it.  They could
> be
> more visible in the process; for example, a firewall or SBC could be a
> real
> SIP proxy server, in the routing path, and thus be a hop in the TLS path.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> > Behalf Of Simon Horne
> > Sent: Tuesday, February 22, 2005 9:47 PM
> > To: voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Actual Attacks
> >
> > At 03:35 AM 23/02/2005, you wrote:
> > >Simon - Why do say security would be less problematic with H323 than
> SIP?
> >
> > Sorry I was speaking from a developers/Implementor point of view not
> from
> > a users prospective. Absolutely, the same issues in equal measure are
> > present on both.
> >
> >  From a developers point of view to secure H323 would be easier than SIP
> > as the H323 has a rich (some say too much) array of call control
> > mechanisms
> > (H225,H245) which already supports credential exchange (but are rarely
> > Implemented)
> > All security features within the messaging are optional which means that
> > there
> > is a high degree of inter operability between secure and non-secure
> > Clients. If the
> > message is present use it if not assume non secure call. The leads to
> the
> > ability
> > for secure H323 devices to exist comfortably with other non secure H323
> > devices
> > and when another secure H323 devices is encountered security
> associations
> > SA
> > can then ensue. If voice/video/data is to be encrypted, SA is done
> > previously out of
> > band so there is no initial "dead' spot for 'handshaking", the traffic
> can
> > utilize
> > existing Firewalls, Proxies, Gatekeepers just as if were unsecured.
> >  From a rolling out point of view secure H323 devices can be deployed
> > within existing networks without having to upgrade infrastructure.
> > Given the pre-existing wide deployment of H323, Network Managers
> > implementing
> > security can still use their existing infrastructure, extending its
> useful
> > life considerably.
> >
> > This is a problem for SIP as it doesn't have the degree of standardized
> > framework.
> > As far as I can tell (correct me if I'm wrong) there is no current
> > comprehensive standard
> > framework or call control mechanism to secure SIP.
> > Security Features available such as external IPSec or SRTP (inband SA)
> can
> > be deployed
> > but there is inter operability issue with other network appliances and
> > Infrastructure.
> > There may have to wholesale infrastructure upgrades to accommodate
> > security. For Network
> > managers this can be a very expensive exercise and adoption could be
> very
> > slow.
> >
> > I hope that clears up what I meant?
> >
> > Simon
> >
> >
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> 
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org