Author Archives: Andy Zmolek

About Andy Zmolek

Andy has been involved with product development and network security for over a decade, and is a co-author and technical editor for the book, "Practical VoIP Security," published in April 2006 by Syngress. Andy was most recently a senior manager in Avaya's Unified Communications Division, driving security and identity planning and strategy for across the Avaya product line, focusing primarily on on applications and next-generation platforms. Previously at Avaya, he led teams within Information Technology, Services, and Strategy & Technology Business Units. Andy was an early advocate for Avaya initiatives in Security, SIP, Presence, and VoiceXML; he has two patents granted and at least nine others pending from his work in Unified Communications. Prior to joining Avaya, Andy directed network architecture and operations at New Era of Networks (now Sybase), a pioneer of enterprise application integration (EAI) technology. Andy got his start in the industry building real-time simulation networks for missile and satellite programs at Raytheon, most notably Sidewinder and Tomahawk. Andy holds a degree in Mathematics from Brigham Young University and lives in Highlands Ranch, Colorado.

FBI Warns of New TDoS Attacks

Earlier this week, several news outlets including reported on a new Telephony Denial-of-Service attack that’s becoming more widespread. In this attack scenario, hundreds or thousands of PSTN calls are launched to the victim’s phone in order to prevent financial institution notifications from arriving while the attacker drains accounts. It’s less clear that attackers can do anything about email or SMS alerts, but based on sheer volumes alone one has to assume the attackers are using VoIP technology to originate the calls. Certainly there are many implications to consider, particularly if TDoS attacks become more common within the PSTN going forward.

PKI Challenges and Gaps for Federation

I recently interviewed XMPP co-chair Joe Hildebrand for regarding XMPP Domain Name Assertions (DNA) used to enable certain instant messaging federation use cases where an XMPP server might host multiple domains. Without DNA, it’s effectively impossible to use TLS for these multiple-domain scenarios, but that’s not the main point of this post. During the course of our conversation, we touched on the general problem of how you leverage PKI and digital certificates to establish trust between two domains for a given application protocol (itself a well-understood concept in theory) and the practical challenges that still remain on a protocol-by-protocol basis for ensuring integrity when binding a certificate to a domain for a given protocol.

Take SIP-TLS for example. We’ve run into more than a few implementations that check for a valid certificate but do absolutely no validation of the domain itself, such that if I send a message purporting to be from after presenting a valid certificate from, not even so much as an error message is logged. Moreover, SIP doesn’t actually specify how such validation should take place, leading to vendor-proprietary implementations that utilize different certificate subject mechanisms and complicate SIP federation.

I noticed a few comments on my prior post claim that UC federation is effectively a solved problem. That’s only true if you narrow the meaning of UC federation to an absurdly small subset of the communications and collaboration space. Yes, XMPP federation for simple domain pairs for instant messaging is well defined with many interoperable vendor implementations today. Frankly, XMPP federation is the best story we’ve got for federation in the UC space, as the story degrades quickly from there. The next-best stories are effectively vendor-specific with Microsoft OCS Federation and Cisco’s Intercompany Media Engine (currently the only product using ViPR – (Verification involving PSTN Reachability – an IETF draft standard proposed by Cisco). There’s a lot of work left to do before all communications and collaboration services are federateable between enterprises, and it turns out that these certificate binding problems are one of the big gaps. To date, XMPP is the closest to solving them and the IETF is considering adopting general standards for protocol certificate binding based on related work – see: draft-saintandre-tls-server-id-check-02 for example]

There’s more to come on this topic in the near future, but for now I just want to leave you with this: it doesn’t matter how secure an established TLS connection is for a given protocol if you can’t bind application-layer domain claims with the certificate used for TLS session establishment. It’s a common fallacy that TLS “makes you secure” all by itself – that’s akin to saying that seat belts and airbags will prevent you from crashing. Federation can only succeed when all associated protocols have well-understood certificate and domain bindings that are properly validated by vendor products used by the federation participants. Anyone who tells you that’s a solved problem today for UC is delusional.

UC Federation and VoIP/UC Security

An emerging trend among Unified Communications vendors these days is support for federation between UC systems in different organizations. Perhaps the first to market was Microsoft OCS Federation which allows two enterprises with Office Communications Servers to share presence, instant messaging, voice, and video.  Google Wave launched last June with support for Wave Federation Protocol which allows wavelets in a wave to be hosted across different organizations.  In November, Cisco launched their Intercompany Media Exchange product which uses a protocol called VIPR (Verification Involving PSTN Reachability) for opportunistic federation between participating organizations.  Avaya, Cisco/Jabber, Reuters Messaging, Google, and others also support XMPP federation which enables presence and instant messaging to be directly shared between organizations.

What VoIP/ UC Security issues come into play with UC Federation schemes like these?  For starters, trust needs to be established between federation partners – this is typically done via digital certificates. But from there we have many policy and identity questions to address, such as:

  • Who in my federation partner organization gets to know about my CEO’s presence and availability?
  • What thresholds can be set to prevent a federation from becoming the conduit for a Denial of Service attack?
  • How does a given E.164 (telephone) number get mapped to the right user@domain handle?
  • Is there any way for a federation partner to use my VoIP system for their toll calls (toll fraud)?

During the next few weeks, I’m going to be exploring some of these UC Federation security questions here on the VOIPSA blog along with others raised by you, our loyal readers. Has your organization implemented any UC federation yet? What are the security issues around federation that concern you the most?