[VOIPSEC] An issue of trust?

[Zmolek, Andrew (Andy)]

Perhaps this is not obvious, being able to answer the trust question is
a necessary precondition to implementation of encryption (else how can I
be sure the encryption is truly secure) and my point there is that you
can only do so much with the existing standards unless you add a global
PKI to the mix. Splitting hairs about authentication vs. encryption
doesn't matter much if we're talking about fundamental mechanisms that
support both. And yes, it makes a big difference whether the trust is
transitive (hop-by-hop) or direct (end-to-end). For ZRTP specifically,
there is an authentication mechanism but it's authenticating the packet
encryption completely independent of signaling and generally won't
prevent you from speaking with a SPITter in the first place.

Even if I were convinced that the suite of H.235.x standards had solved
all of these security problems (which I'm not, though I do concede that
the ITU is significantly ahead of the IETF right now overall when it
comes to implementable VoIP security standards), From where I sit,
there's so more demand for SIP going forward within the enterprise
(because of the value of MS LCS and Lotus Sametime integration for IM
and presence) that I am much more concerned about seeing the issue
tackled for SIP in the IETF and SIP community. But if there's value in
reworking a particular H.235.x security concept to work with SIP, I'd
welcome that discussion. 

Along those lines, what would be great to see from VOIPSA in the near
term would be a comprehensive, unbiased comparison of security
feature-functionality between SIP and H.323 (and maybe a few others like
H.248 and Skinny). Everything I've seen so far in that realm has been
fairly superficial or focused entirely on promotion of a specific
protocol. 

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


-----Original Message-----
From: Simon Horne [mailto:s.horne at packetizer.com] 
Sent: Saturday, June 17, 2006 5:55 AM
To: Zmolek, Andrew (Andy)
Cc: voipsec at voipsa.org
Subject: RE: [VOIPSEC] An issue of trust?

At 06:30 AM 17/06/2006, you wrote:
>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,

Again I think you are confusing Authentication with encryption. All I
want to know is that I can "trust" the person I am talking to. I may not
want to secure the media or signalling at all. I just want to make sure
the person I am talking is a "trusted" party. (note: Not necessarily
their true identity, just that a 3rd party can vouch for the person) so
I'm confident its not going to be a SPITer or an unsolicited cold caller
etc...

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

In this case I don't care about securing the media or signalling. I
think you are confusing hop-by-hop with end-to-end. You are using
hop-by-hop to achieve end-to-end which is very different to true
end-to-end. (which means party A put a message on the wire and it
arrives at party B unaltered by any intermediaries it may pass through)
ZRTP is truly an end-to-end encryption solution (since it is not affect
by any intermediaries) but it has little to do with Authentication.


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

Agreed.


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

Firstly, I am not talking here about Encryption, I am not talking about
securing the signalling hop-by-hop, I am talking about end-to-end
authentication. I really do suggest you read H235.2 because there is no
need to secure the signalling channel at all because you not just send a
certificate  (and a time stamp) you also sign it with your secret
private key and you can send the certificate + timestamp + signature in
the clear. 
Since the certificate is a "public certificate" you don't care if anyone
sees it, you only care that you are the only one who can reproduce that
signature. Now if you were to call me with a certificate issued by your
organization then before I have even finished process the INVITE message
I would know that you are who you say you are. Then we can worry about
securing the media.

Although off topic, securing the signalling is not required, Agreed
using sdescriptions will definitely require a secure signalling channel
and you must secure every single hop in the path (which honestly you
have no real way of doing except in a trusted closed network) however in
true end-to-end security Party A can use Party B's public key (embedded
in the Party B's
certificate) to encrypt the Diffie-Hellman exchange component and only
Party B is able to decrypt it. So it is quite safe to send the messages
in the clear straight point to point or though pre-existing  H.323
proxies etc without requiring the channel to be secure.


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

Agrred. Inside a closed solution like SKYPE or closed interconnected
VoIP islands then PKI and authentication is less of a concern as it is a
closed system however once you adopt ENUM and DNS SRV and open your
network up to the wilds of the Internet then you definitely need some
form of "trust" to prevent SPIT and the disaster that email has become.


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

Absolutely true, H323 is very daunting to the uninitiated (but I have to
say SIP is getting that way too). There are a couple of open source MPL
licensed implementations such as openH323 (which Craig Southeren and I
help
maintain) http://sourceforge.net/projects/openh323 and web sites such as
www.packetizer.com which posts all the latest standard documents.

The real BIG issue here is interoperability, you can use H.235.x (or any
flavor you want to create of it) on any pre-existing H.323 network to
achieve true E2E security. There is no need for expensive upgrades
because the relaying support is already built into in these devices, so
any already deployed Cisco , Asterisk or FreeSwitch PBX  will support
the routing of H.235.x messages and if you call or receive a call from
an end device that does not support H235.x then at least that device
will not crash and the call will not fail.


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

IMHO Skype exists because the standards based protocols have failed to
deliver on their promises.


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

If standard based protocols are going to survive then this definitely
has 
to change. For years we have been promising something grand but as yet
has 
not delivered . Don't let ourselves settle for "good enough" because as
we 
have seen over the last few years, programs like SKYPE just take over
and 
deliver the promises standard based protocols can't.


Simon