[VOIPSEC] An issue of trust?

[Simon Horne]

At 02:40 AM 17/06/2006, you wrote:
>CALEA doesn't break E2E security, so long as you're encrypting with
>technology not under the control of a service provider (or SP
>equivalent) who must comply with it. Federal policy doesn't prevent E2E
>security today, but it's laughable to think it's worthwhile to expect
>changes to US regulations that mandate E2E security unless you're
>willing to extend CALEA to cover all P2P technology as well.
>
>There are plenty of good E2E security solutions that can be put in place
>by end-users or businesses that are carrier-independent, but none of
>them has that critical mass of implementation yet and interoperability
>between most of these solutions are poor candidates for widespread use
>because of two simple problems:
>
>1. Key management: so many different ways to provide keys, but the most
>interoperable of these methods have point-to-point dependencies (like
>sdescriptions over TLS for SIP) or require the prior existence of a
>global PKI solution for all endpoints (and end-users) to leverage (like
>many of the MIKEY variants).

True, but what has global PKI got to do with securing the signalling or 
media.  PKI is only required to authenticate the person you are talking to. 
None of the methods you have stated have anything to do with authenticating 
the actual person you are talking to.. I think you are confusing hop-by-hop 
signalling/media protection with end-to-end Authentication.


>2. Offer management: namely, how do I determine whether my device can
>communicate with yours in a secure and interoperable way? The most
>obvious way to do this in SIP would be with multi-part SDP offers, but
>it doesn't take much testing to determine that a lot of today's clients
>break when presented with a multi-part message. So we end up having to
>look at SDP extensions or headers as a compromise that may or may not
>work properly for backwards compatibility, but don't blow up the client
>at least.

In H.323 this not a problem. There is no offer, no multi-part SDP messages, 
you just insert the damn certificate directly into the setup message (SIP 
INVITE) ,  if the remote party doesn't support authentication then that 
part of the message is just simply ignored (it won't crash the device) and 
the call progresses as normal.


>BTW, ZRTP bypasses some of the key management problems but does so by
>hiding signaling in the media (which creates a host of other interop
>problems to solve which make offer management more complex). And yes,
>the H.235.x family of security protocols does offer a few solutions as
>well for the H.323 family but the applicability of those protocols
>varies a lot and most of the H.235.x protocols are implemented by a few
>vendors in ways that often don't lend them to interoperability.

H.235 support is built into almost every H.323 message,. it is designed to 
be interoperable,  You can throw anything into the crytoToken field in 
existing messages and it will get to the other end regardless of the 
intermediaries it passes through, if the remote party doesn't support the 
feature it just ignores the message and continues on as a standard 
unencrypted call. The call is never going to fail.


>Moreover, the IETF prides itself on a history of not supporting
>wiretapping through its standards, so don't expect the SIP community to
>engineer this kind of support at the protocol level any time soon. And
>just in the key management realm, they've still got 11 candidates in
>play after 5+ years of work in this area, with no clear consensus in
>sight despite general agreement that the problem needs to be solved
>quickly.

Agreed, the IETF still has a long way to go.


>Bottom line: no one entity with leverage in this area has enough
>political might to break up this logjam, so expect the impasse on this
>encryption/wiretapping issue to hang around until the balance of power
>changes in a big way. That may or may not happen in my lifetime. In the
>mean time, one should expect balkanization to be the overall rule with
>multiple peering communities built along each of the major usage
>profiles (large enterprise, small-to-midsize carrier-oriented
>communities, PC-oriented consumers, etc.), each with their own dominant
>solution based on their own priorities.

and while we wait the world is using SKYPE.:)

Simon