[VOIPSEC] Actual Attacks

[Brian Rosen]

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
>