[VOIPSEC] An issue of trust?

[Zmolek, Andrew (Andy)]

Yes, CALEA solutions for SIP exist today and are presumably implemented
by all the major carriers (often via SBCs). That wasn't the point of my
post, but from a CALEA point-of-view, it doesn't matter if the SIP
protocol itself isn't friendly to its aims so long as there's a point at
which the desired information can be accessed. 


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


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

Andrew,

I thought that CALEA could already be achieved in SIP environments using
all the major SBCs and Carrier Class VoIP switches. Am I wrong?

Respectfully,

--
Andre Fucs
http://www.fucs.org/portugues/


---- Mensagem Original ----
From: "Zmolek, Andrew \(Andy\)"
To: "Tyler Johnson" , Ron_Cramer at cargill.com, Voipsec at voipsa.org
Sent: Sex, Junho 16, 2006 3:40 pm
Subject: Re: [VOIPSEC] An issue of trust?
> 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:
> To:
> 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
>
>
> _______________________________________________
> 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