[VOIPSEC] An issue of trust?

[Simon Horne]

At 01:12 AM 20/06/2006, you wrote:
>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.

Agreed.. If you are opening up your network then you need some from of 
scalable "trust" mechanism. Whether that be inter domain or E2E or possibly 
both. For instance you might just need to ensure that the domain (voip 
island) the person is calling from is trustworthy,  presently we use 
mechanisms like CALs however they are not really scalable as they need to 
be constantly updated but using a public PKI certainly does go a long way 
to fix that problem. The email community have done pretty much this with 
the adopted the DKIM mechanism for authentication between email providers. 
Note this is different to SIP Identity as you are only vouching for the 
trustworthyness of the providers not the actual sender/caller. There are 
call setup delay issues with DKIM and SIP Identity as the certificates are 
not sent with the call initialization and time is required to fetch them 
from public websites to validate. Of course with H.235.2 this is not 
necessary because the certs are already in the message.

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

Authentication and encryption have 2 very different functions, maybe I 
should provide a valid business case where authentication and encryption 
are not splitting hairs. Say you are offering a subscription based support 
phone service and you offer a "Free" global ENUM number for people to call 
in on to receive service support. Now you may not be interested in the call 
being secure but you definitely want to make sure that the people calling 
are only current paid-up subscribers. You can issue a username/password  to 
the customers which can be used to call in (using H235.1). Now the border 
element can authenticate the caller as valid current customer (using Radius 
or whatever) and pass the call onto to a customer support person who then 
can use the username supplied to bring up the customers client details 
before answering the phone call.


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

I have already tried to port some of the ideas across to SIP however I ran 
into some structural architectural/call flow issues. There is no common 
security framework in SIP so any changes most likely will not be backward 
inter operable and require updates of all the elements already deployed in 
the network and with no dedicated end-to-end call signalling channel, makes 
everything designed end to end a little more difficult. This would probably 
explain why ZRTP is a completely media channel solution. I think Richard 
Paine's post on HIP and need to secure every message may make interesting 
reading too.

Having SIP in the enterprise is fine because current solutions are VoIP 
islands but once you start linking these VoIP islands together known vendor 
interoperability issues arise and perhaps security might be a lessor of a 
concern then just being able to make calls to eachother.

H.235 is not a security solution however a method to create solutions. I 
will correct my previous statement that no equipment will crash using 
H.235. I should of said most or reputable brands with not crash. Like any 
poor implementations, crashes are very possible. I just got a cheap H.323 
IP Phone from china and yeap it crashed when I tried to call it.


Simon


>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