[VOIPSEC] Actual Attacks

[Brian Rosen]

> 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?
Nope.  You send the sRTP keying info in the SIP message, which is protected
by S/MIME and/or TLS. 
 
In all cases, there is no dead spot.  If TLS is used, the TLS connection is
established before the signaling is processed.  If S/MIME is used, the SDP
is encrypted at all times.

You upgrade existing systems with a firmware upgrade.

> How do you provide incoming Caller Authentication. sRTP only covers call
> encryption.
> What you do with the legacy intermediary non "sips" equipment?
You protect the SIP signaling with S/MIME and/or TLS (sips: is TLS).
If you need end to end authentication, you use S/MIME.  Often, TLS is
enough, with each intermediary authenticating the next (transitive trust).

> 
> 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.
To me, that's weird, but YMMV.  sRTP is much more flexible than RTP in a
tunnel; that's why it was developed.

> 
> >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.
Confusion - I thought H.323 media protection was RTP in a tunnel, not
encrypted payload in a real RTP header.  Never implemented it so I'm
probably wrong.

> 
> >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
As long as hop-by-hop security is acceptable, we have this.
S/MIME for end-to-end also works, but as with most cert based systems, is
highly questionable usefulness because of the lack of a global PKI

>          2. Negotiate Security Association (TLS Handshaking) upon
> authentication (before call proceeding)
This is the way it works for TLS
S/MIME doesn't quite work this way, because you get an (encrypted) message
before the "SA" is established, but it is secure.

>          3. then use that SA to secure voice\video traffic.
Do not agree.  The SA for signaling is not necessarily the same SA for
media.  Specifically, the hop by hop SA is practical - adjacent entities
usually CAN authenticate each other, even if the endpoints cannot.  Media is
always end to end.  You also have cases where the signaling entity is a
separate device from one or more media entities (large gateways often work
this way).

SIP negotiates the SA for media in a secure manner, before use.

>          4. and do it so it's interoperable with all your legacy sip
> devices.
Sure, that's the way it works. 

Brian