[VOIPSEC] Actual Attacks

[Simon Horne]

At 10:54 PM 23/02/2005, you wrote:
>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.

Again the TLS handshaking in sRTP is done "in band" which means there is a
dead spot (not encrypted) at the start in which TLS SA is done. Also its a
separate "New" protocol. What do you do with all your legacy RTP equipment?
How do you provide incoming Caller Authentication. sRTP only covers call 
encryption.
What you do with the legacy intermediary non "sips" equipment?

The H323 method can do custom TLS handshaking "out of band" within existing 
call
signalling mechanism (already allocated for in the Standard) to provide 
Caller Authentication
and then use the negotiated SA to encrypt the payload of the existing RTP 
protocol.
If you specify your "security policy" as request authentication, legacy 
equipment calls
which fail authentication are still be permitted and voice/video progresses
are per normal.

>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.

You are right here. H323 has a method for hop to hop encryption of Call 
Signalling
through Intermediaries but alas those intermediaries have to support it and 
a lot
don't so this a valid point. However RTP Traffic passes thro' uneffected as 
only
the payload is encrypted so intermediary proxies still have access to the 
Header
and can treat the traffic as per normal.

>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.

Agree signalling security thro' intermediaries is a major issue whether sip 
or H323
and the issues involved are much the same. In terms or Caller Authentication
and Voice\Video Encryption, H323 secured devices can reside quite comfortably
within existing legacy H323 Networks without any interoperability issues.

I guess that's what this list is about. Vigorous Discussion.

IMHO there needs to be within SIP a common or standard method to:
         1. Use Certificate based Caller Authentication on incoming calls
         2. Negotiate Security Association (TLS Handshaking) upon 
authentication (before call proceeding)
         3. then use that SA to secure voice\video traffic.
         4. and do it so it's interoperable with all your legacy sip devices.

Enough with the H323 stuff already... :)

Simon