[VOIPSEC] An issue of trust?

[Zmolek, Andrew (Andy)]

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

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.

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. 

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.

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.

/\\//\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 Tyler Johnson
Sent: Thursday, June 15, 2006 6:35 PM
To: Ron_Cramer at cargill.com; Voipsec at voipsa.org
Subject: Re: [VOIPSEC] An issue of trust?

You can't. That's why you have to implement security at the application
layer. That means end to end encryption of media an signaling. However,
US regulations for CALEA break that. If you do hop to hop security you
really don't have any assurance of security beyond the next hop unless
you are in a limited federation, but that doesn't scale to the whole
Internet.

I think the bottom line is to work to get coherent policy implemented at
the federal level in the U.S.

The other possibility is to think about a new protocol that is designed
with security from the ground up, with wiretap in mind. H.325 offers an
opportunity here, I think. I don't think it's going to work to reverse
engineer this into SIP or H.323.


----- Original Message -----
From: <Ron_Cramer at cargill.com>
To: <Voipsec at voipsa.org>
Sent: Thursday, June 15, 2006 6:46 PM
Subject: Re: [VOIPSEC] An issue of trust?


> It appears I should clarify my question in regards to a Telecom
Service 
> Provider
> vs an Internet Service Provider.
>
> Based on my experience, many enterprises would choose to trust telecom

> service providers
> to keep data traffic private on a traditional layer 2 service such as 
> frame relay or voice
> services on POTS.  And, would choose not to trust Internet based 
> communication, but to
> mitigate the Internet based risk with firewalls, encryption tunnels,
etc.
>
> Part of the logic used to differentiate between these two choices was
that 
> the traditional layer 2
> services provided separation between the virtual private networks of
the 
> many customers serviced
> by the Telecom Provider.  Since the packets are being forwarded at
layer 2 
> the Telecom Provider
> had no awareness of anything related to the Internet Protocol.  This
also 
> meant that the
> Telecom Service Providers customers could not use IP based attacks
against 
> the carrier infrastructure.
>
> As Telecom Service Providers move to offer IP-ware services - MPLS,
VoIP 
> or whatever
> the Telecom Service Providers are vulnerable to IP based attacks.  I
know 
> there
> are many papers that state MPLS *can* be deployed with the same level
of 
> security
> as a layer 2 service, but how can I *trust* the Telecom Service
Provider 
> will invest
> the effort to operate a secure MPLS network.  Or, VoIP, or whatever?
>
> Thanks and regards,
>
> Ron
>
>
>
> -----Original Message-----
> From: Cramer, Ron - Ron_Cramer at cargill.com
> Sent: Thursday, June 15, 2006 1:19 PM
> To: 'Voipsec at voipsa.org'
> Subject: An issue of trust?
>
>
> The issue of trust for your Telecom service provider,
> either traditional or VoIP based seems to be a fundamental
> component for secure communications.
>
> Can anyone identify an industry standard that an
> Enterprise can use to establish trust with a Telecom
> vendor?  Something with well established decision
> criteria, not just a high level guide to performing a
> risk assessment.
>
> Thanks in advance,
>
> Ron
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 


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