[VOIPSEC] Actual Attacks

[Simon Horne]

At 03:45 AM 24/02/2005, you wrote:
> > 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.

No problem, but I thought sRTP was designed to do key Exchanges (SA) "In 
Band" with the option of "out of band". So really there is little 
difference with encrypting the RTP payload
and using sRTP with 'out of band SA' (ok sRTP has other things but basically).


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

Standard H235v3 Section 11 has a big diagram :)

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

This was my point, end to end. There needs to be an authentication element 
that is sent, which is unaffected by intermediaries, that utilises a PGP 
"web of trust" model or certificate authority chains (not necessarily a 
Global PKI) to authenticate the caller.


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

sure you can use S/MIME call signalling encryption but you are negotiate 
end to end SA.

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

Sorry I wasn't referring to hop by hop signalling but end to end media SA. 
Definitely they are two distinct animals and S/MIME is fine for hop by hop 
call signaling security but IMHO end to end TLS should be deployed which is 
negotiate between the calling parties independent of the intermediaries used.

Simon