[VOIPSEC] An issue of trust?

[Simon Horne]

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