[VOIPSEC] An issue of trust?

[Zmolek, Andrew (Andy)]

Try implementing any of the 11 proposed methods for SRTP key management
(or for that matter, any S/MIME-based SIP or email solution). You will
quickly discover that most of these solutions are unworkable without
reliance on a global PKI or equivalent system for managing trust
relationships across multiple administrative domains, independent of
what you're doing for user authentication within each domain. And the
few that don't require it directly can't guarantee that signaling (and
thus keys) is protected E2E. The main exception is ZRTP which partially
sidesteps the issue by pushing key management into the media so that it
becomes E2E so long as you don't have anything else that touches the
media along the way.

Regardless, you don't even need PKI to authenticate the person you're
talking to but having a global PKI there certainly helps once you go
beyond a small number of administrative domains. And that's the
underlying issue in all of this. When you're talking to people that
reside in one of an arbitrarily large number of administrative domains,
you either need to leverage a shared secret that can be protected
against MITM or a PKI solution that eliminates the shared secret at the
expense of maintaining a large-scale deployment of digital certificates.

For sdescriptions, the shared secret is protected by the signaling
channel, so it's important that each hop properly protect the signaling
using TLS or the key won't be very secret. Ensuring TLS is used between
administrative domains is a more manageable problem today than rolling
out a global PKI so it's a preferred enterprise solution for
interoperable SRTP today. In the case of Skype and a lot of
semi-proprietary schemes, all key management is done within a single
administrative domain (or limited number of homogeneous domains)--a
simpler problem. What's cool (and frustrating, depending on your POV)
about ZRTP is that it also simplifies the problem by doing key
management of a shared secret in the media itself (which is presumably
E2E). In all three cases, the common thread is that the complex issues
of trust across heterogeneous administrative domains have been
simplified in some way such that PKI is not required.

The "offer problem" in H.323 is different than in SIP, and to some
degree the problem there is that so many "standardized" methods exist to
set up an H.323 call that the question becomes one of vendor support for
all the different flavors of H.323 and H.235 signaling methods since
there are so many to choose from. But at least it's pretty
straightforward once you've picked the combination of flavors you want
to use--as long as the party you call supports the same set. I
completely agree that there is less of a backwards-compatibility issue
in the H.323 world, though there's a lot less R&D money chasing H.323
these days compared to SIP and it's definitely got a steeper learning
curve for the uninitiated.

Skype is definitely being used by consumers and small businesses, but I
don't see any desire by large enterprise to abandon their existing VoIP
implementation models in favor of Skype or even integrate them with
Skype (still, PIKA now claims to have an Asterisk-Skype gateway, which
would be a first). In any case, Skype isn't publishing their security
interfaces so there really isn't a broader secure interop story there
even if Skype as a community were to make inroads in the enterprise
space. 

It's easy to forget that VoIP has consumer, carrier, and enterprise
islands right now and that the dominant players in each have limited
influence on the growth of other islands so long as the PSTN is the
ocean that surrounds them. Enterprises try to block use of the consumer
VoIP and are much more likely to use VoIP phones and trunks within the
enterprise space (or to carriers) than expose VoIP to the Internet and
consumer world. For a given VoIP call, carriers are much more likely to
be using the VoIP for backhaul and TDM trunk replacement than they are
to be passing an enterprise or consumer call into their networks for
access. And it's telling that all the money being made in the consumer
space is happening at the IP/PSTN edge. Even if I called someone on a
Vonage IP phone from my VoIP phone right now, I would be going through a
TDM trunk backhauled over IP to a TDM interface connecting to Vonage,
for a total of 4 IP/TDM digital conversions. If I want E2E encryption
for that, I have to be able to encrypt the digital audio stream from
both sides and be prepared to have a few stuffed, robbed, or lost bits
in between. 


/\\//\Y/\   Andy Zmolek  |  zmolek at avaya.com  |  303-538-6040 
            Senior Manager, Security Planning & Strategy
            GCS Security Technology Development  |  Avaya, Inc. 


-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Simon Horne
Sent: Friday, June 16, 2006 2:32 PM
To: voipsec at voipsa.org
Subject: Re: [VOIPSEC] An issue of trust?

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



_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org