Posts categorized "Security"

Can We Create A "Secure Caller ID" For VoIP? (Join Tomorrow's STIR BOF To Learn More)

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

You can also join the Jabber chat room at:

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

If you found this post interesting or useful, please consider either:

At SIPNOC 2013 This Week Talking About VoIP And IPv6, DNSSEC ... and Security, Of Course

Sipnoc 2013 logoOne of the conferences I've found most interesting each year is the SIP Network Operators Conference (SIPNOC) produced by the SIP Forum, a nonprofit industry association. Part of my interest is that it is only an educational conference, i.e. there's no massive exhibit floor or anything... it's all about education. It also brings together pretty much all the major players in the "IP communications" space - certainly within North America but also from around the world.

I'll be there this week in Herndon, Virginia, talking about how VoIP can work over IPv6 and how DNSSEC can make VoIP more secure. The sessions I am directly involved with include:

  • Panel Discussion: Anatomy of a VoIP DMZ
  • VoIP Security BOF
  • Panel Discussion:  IPv6 and SIP - Myth or Reality?
  • Who Are You Really Calling? How DNSSEC Can Help

There are quite a range of other topics on the SIPNOC 2013 agenda, including a number of other talks related to security.  

It should be quite a good show and I'm very much looking forward to it.  I'm particularly looking forward to my "DNSSEC and VoIP" talk on Thursday as that is a topic I've not presented on before... but I think there is some quite valuable potential about using DNSSEC with VoIP.

If you are there at SIPNOC this week, please do say hello!

P.S. While SIPNOC is not being livestreamed, you may find some people tweeting using the hashtag #SIPNOC.

If you found this post interesting or useful, please consider either:

Oracle Buys Acme Packet For $2 Billion To Gain SIP Session Border Controllers (SBCs) And More

AcmepacketFascinating news today out of Oracle that they have purchased Acme Packet in a transaction estimated to be around $2 billion US. For those of you not really tracking the VoIP security space, Acme Packet is probably the world's largest vendor of "session border controllers (SBCs)", devices that are used to securely and reliable interconnect VoIP networks. SBCs also provide a very important role in helping with interoperability of Session Initiation Protocol (SIP) signaling between the SIP products and networks of different vendors.

As Andy Abramson writes, the fascinating aspect of this acquisition is this:

This is an interesting grab by one of the tech world's true giants because it sqaurly puts Oracle into a game where they begin to compete with the giants of telecom, many of whom run Oracle software to drive things including SBC's, media gateways and firewall technology that's sold.

This acquisition does put Oracle VERY firmly into the telecom sector at a carrier / large enterprise level, as Acme Packet's products are widely used within that tier of companies. As the news release notes:

"The company's solutions are deployed by more than 1,900 service providers and enterprises globally, including 89 of world's top 100 communications companies."

Acme Packet has also long been recognized as a leader by analyst firms such as Gartner. People from Acme Packet, in particular Hadriel Kaplan, have also been extremely involved with industry efforts such as the SIP Forum and standards activity in the IETF.

As far as integration, Oracle already has a wide array of "communications" products, including several unified communications (UC) products that could potentially interact with Acme Packet products extremely well. Beyond all of that, though, this acquisition will have Oracle being a strong player in providing telecom infrastructure as we continue to collectively move to basing all our communications on top of IP.

Congratulations to my friends at Acme Packet and Oracle... and I wish them the best as they proceed down the path to completing this acquisition.

More information here:

If you found this post interesting or useful, please consider either:

Today's VUC Call - Philippine Phone Phreaking Funding Terrorists

For those interested in telecommunications security, today's (Dec 2, 2011) VoIP Users Conference (VUC) call at 12 noon US Eastern will cover the recent arrests of 4 Philippine men who defrauded AT&T of close to $2 million and were employed by an alleged terrorist organization who was using the proceeds of the scam to fund their activities.

Eric Klein of Humbug Labs will be the guest on the VUC call discussing this and other fraud issues. It should be an interesting discussion.

You can join the live call via SIP, Skype or the regular old PSTN. There is also an IRC backchannel that gets heavy usage during the call. It will be recorded so you can always listen later.

If you found this post interesting or useful, please consider either:

The Creepy - And Insecure - Side of iOS and Android Apps

Want to see the dark side of mobile apps? Just read this great bit of research from Troy Hunt:
Secret iOS business; what you don’t know about your apps

As people have noted in the comments, "iOS" (Apple's operating system for iPhones and iPads) is purely the platform Troy Hunt did his research on... but he's really talking about issues with mobile applications.

I'm my unfortunately sure that these type of issues will also be there on apps on Android and probably on other mobile operating systems from Microsoft, RIM, WebOS, etc.

These are application design issues.

The article starts off with the incredibly inefficient case of stuffing large images from "regular" websites down the mobile pipe to the phone... and then simply "resizing" them with "width" and "height" attributes. This is just laziness"efficiency" on the app developers part in that they are simply "repurposing their existing content" for a mobile audience, i.e. it's too much work/effort for them to create and track a separate smaller image for a mobile environment so they will just send you the larger one and eat up your data plan bandwidth.

But Troy Hunt goes on to talk about far worse issues... he calls out the analytics sent back to in particular (and there are other similar players out there) that report what the user is doing. I agree with Troy Hunt's comment that where this gets "creepy" for me is not so much reporting data back for one application, but rather that all this data is being aggregated across applications inside of Flurry's databases.

And then the truly scary issue of how little security some applications use to protect login credentials (i.e. NONE!) or to protect confidentiality of the information people are seeing.

As Troy Hunt points out with regard to the Facebook app for iOS:

Unfortunately, the very security that is offered to browser-based Facebook users is not accessible on the iPhone client. You know, the device which is most likely to be carried around to wireless hotspots where insecure communications are most vulnerable.

Mobile devices are being brought to the worst possible WiFi environments... and per this article seem to have some awfully insecure apps running on them.

Every mobile developer needs to read this article - and start looking at how to secure their apps!

P.S. Thanks, Troy Hunt, for writing this piece!

If you found this post interesting or useful, please consider either:

Survey: Only 40% of Canadians Password-Protect Their Cell Phones

GlobeandmailOnly 40% of Canadian cell phone users password-protect their phones or use other privacy options, a survey by Canada's privacy commissioner found. The results of the 2000-person survey were released in August and written up in a Globe And Mail piece entitled "How private is that text message?".

When I saw the headline, I honestly thought it was going to be something about the security of SMS messages... but in fact it was about the security of the cell phones themselves. If the phones aren't secured then someone can go in and look at your text messages. Ergo... the link-bait title of the article. (And yes, it got me to look.)

Still, it had some interesting data points such as the fact that the users from age 18 to 34 were the ones most likely to use privacy tools, which is good to see, since they are probably the ones pumping the most information out online.

Nice to see, too, that 82 percent did not think police should have access to your online usage info without a warrant.

I was surprised, in all honestly, about the 40% number... I actually might have thought of it being lower as I know MANY people who don't password-protect their phones mostly because of the "inconvenience" of having to enter the password to get into the phone.

And in truth the % who password-protect their phones may be lower... the article says that "only four in 10 people password-protect their phones or adjust privacy settings on personal-information sharing via downloaded applications". The number of people who adjust privacy settings - but don't password-protect their phone - may be driving that % up.

I wonder what a survey like this might find in the United States?

Do you password-protect your phone? (I do)

If you found this post interesting or useful, please consider either:

Speaking Next Week on IPv6 and VoIP Security at 7th Real-Time Communications Conference in Chicago

If any of you will be in Chicago next week, October 4-6, 2011, for the 7th Annual Real-Time Communications Conference & Expo, I'll be there on the 5th and 6th as a speaker.

I'll be speaking twice. First on Wednesday the 5th at 4pm on "The Current State of VoIP Security", wearing my VOIPSA hat and leading off a series of talks about security. I'll be providing an overview of the main threats to VoIP and communications security in general, leading the way into the two more specific talks following mine.

I'm rather excited that my second session will be my first public appearance wearing my new Internet Society hat (if you are not aware, I've posted details about my recent move) and will of course be about IPv6... more specifically "How IPv6 Will Impact SIP And Telecom".

Due to ongoing events on the personal front, I wasn't sure that I was going to make it out there... and quite frankly there's still a chance that I won't... but I should be out there.

If you look at the conference schedule, the speakers include outstanding people involved with so many different aspects of real-time communications. It should be truly an excellent event!

P.S. You can still register if you would like to attend!

If you found this post interesting or useful, please consider either:

Skype Issues 2nd Mac 5.1 Hotfix for "Security Issues" - But What Are Those Issues?

skypelogo-shadow.pngToday, Skype issued a new Skype 5.1 for Mac "hotfix" for more "security issues". The problem?
We don't know what those "security issues" are?

We don't know, for instance:

  • Are they related to the remote exploit that was publicly disclosed on Friday? Or to related attacks on the same theme? (as discussed on SecNiche today)

  • What is the severity of these "security issues"? Remote compromise? Denial of service? What?

  • What is the priority that we should place on getting this update in place? Is it a "UPDATE NOW!" kind of priority? or a "Update when you can"?

  • What kind of mitigating circumstances are there for these security fixes?

  • Are there any workarounds that could be put in place at a network layer (or any other layer) to prevent attacks on individual systems? (i.e. as a safety measure until the individual clients are all updated?)

We need to know this kind of information.

Particularly as Skype looks to try to move more into the "business" or "enterprise" market space, this level of NON-disclosure is unacceptable.

In comparison, take a look at any of the recent Microsoft security bulletins, like, oh, this one, and you can see the kind of information that a security professional is looking for. Now, sure, Skype doesn't necessarily need to go to the level of detail that Microsoft has... but something more than just "Security issues" is necessary.

Letting Us Know?

Additionally, why again is Skype issuing a "hotfix for security issues" without telling anyone about it? Just like they did back in April?

Once again the hotfix is mentioned only on Skype's Garage blog. Nothing on Twitter on either @skype or @skypesecurity. Nothing on the Mac blog (although they finally updated that blog about the issue on Friday). Nothing on the Security blog.

And once again, the "Check for Updates..." feature in Skype 5.1 does not show a new update available:


So apparently the only way we can get this hotfix for unknown "security issues" is to go to Skype's main download site and download it!

C'mon Skype! You can do better than this!

Recommendations for Skype

So rather than just rant, let me offer these suggestions to Skype for what they should do when they have a "security hotfix":

1. Provide More Info - Saying it is simply "security issues" doesn't cut it. We need to know things like:

  • what is the severity of the security issue? if an attacker could compromise the Skype client, what could he or she do?
  • how easy is it for an attacker to execute an attack? can the attacker be remote? do they have to be a contact?
  • are there mitigating circumstances that would make an attack less likely?
  • are there workarounds that could be put in place at a larger level than just the client?
  • what is the potential exposure of NOT upgrading?

Skype should look seriously at tools like the Common Vulnerability Scoring System (CVSS) used by many software/hardware providers (see also the CVSS FAQ). And while perhaps the full CVSS process may be too heavy for a smaller organization like Skype, the document at least gives insight into the type of questions security professionals want.

Similarly, the Cisco Security Vulnerability Policy and associated links is worth a read. Again, it may be too heavy a system for a smaller company like Skype... but then again perhaps in all of the new hires Skype is looking to do they could hire some folks specifically to work on this process.

2. Let People Know About The Security Hotfix - Skype has a "security" blog and specific @skypesecurity Twitter account. They should be used to communicate the availability of security hotfixes. Security professionals associated with companies using Skype could then know that they need to subscribe/follow those sites to know when there are new issues needing attention.

3. Make The Security Hotfix EASY To Obtain - Make the "Check for Updates..." process work from the beginning. The blog post or other update should be able to state that Skype users can simply go up to "Check for Update..." to download/install the new version. Perhaps this means that the blog post has to be delayed until the new version is uploaded to whatever update servers Skype has... but so what? Wait a bit - or improve the internal process so that these uploads happen faster. The end result will be that MORE people will update sooner, which, I would think, should be the goal.

Those three steps would help people feel a whole lot better about Skype's concern for security - and would also make sure that Skype users are better protected. It would also help Skype's reputation, brand, etc.

And it would stop people like me from writing blog posts like this. ;-)

Seriously, Skype... security matters... and even more, communication about security matters. We all know that with any system there are security issues... no system is perfect and attackers will always try to compromise systems. We get that. It is how you react and communicate about those security issues that is so incredibly critical.

Skype's Security Communication FAIL - Why Issue a HotFix If You Don't Tell Anyone?

skypelogo-shadow.pngWhat is the point in issuing a hotfix that addresses a security vulnerability... if you don't tell anyone that the hotfix is available?

Tonight Skype published a blog post saying that back on April 14th they released a "hotfix" for this problem in Skype for Mac version That's great... it's good that the fix is out there, but...

how were we Mac users supposed to know about it?

Hmmm... let's see... Could we find out about the Skype for Mac hotfix...

  • ... using the "Check for Updates" feature? Nope, doesn't work for me. Maybe it works for others out there, but not for me.

  • ... from the Skype for Mac Release Notes page? Nope, that page STILL hasn't been updated, three weeks later, to indicate that a new version is out. Nothing on there at all about

  • ... from Skype's Twitter account? Nope, no mention of a hotfix back on April 15th, although they did talk about the fact that Skype was mentioned twice on 30 Rock and that there was Skype call on the Rachael Ray show.

  • ... from Skype's skypesecurity Twitter account? Nope, no mention.

  • ... on Skype's Mac blog? Nope. Last post there was April 14th, the day before this hotfix came out.

No mention of a "hotfix" for Skype 5.1 for Mac OS X on any of those communication vehicles.

In The Garage?

Ah, but wait... Skype did mention the hotfix, over on the Skype Garage blog, which is all about "Experiments and pre-releases". Here's a screen capture of the notice:


So they posted news of this important "hotfix" on a blog for "experiments and pre-releases", didn't tweet it out, and didn't update release notes or put it anywhere regular Mac users would find it.

And a curious thing...


Nothing whatsoever.

I am guessing that "Minor bug fixes" must include this security issue. And maybe the fix was simply a "minor bug fix". Maybe someone forgot to do bounds checking on some part of the chat system and as a result a buffer overflow occurred. Maybe it was some simple little fix.

But labeling it in this way gives absolutely no incentive for anyone to upgrade. Even had I seen this notice, I probably wouldn't have bothered to upgrade (unless the Check for Updates had worked). There is no urgency on this.

And... call me crazy, perhaps, but I guess I don't consider a security issue where someone could send me a chat message and gain complete control of my Mac to be a "minor bug"!

Did Skype not think that at some point the security researcher would publish his findings?

And why in the world didn't Skype communicate with this security researcher to tell him that they had fixed the bug he found and would be issuing (in fact had issued a fix)? Now maybe they thought they did... but whatever the situation was, he didn't know and out of frustration published his post today.

It Didn't Have To Be This Way

In other words...

... everything that happened today was COMPLETELY PREVENTABLE had Skype only communicated more.

Skype would not have had the negative coverage in ZDNet, CNet, ComputerWorld, Mashable, TheNextWeb, my own blog ... and many other sites, let alone all the tweeting and retweeting.

Instead of having all this negative activity, they could have jointly come out with a statement with the security researcher or at least crediting the researcher. It would have shown that Skype was serious about security and protecting us - and also serious about working with the security community.

And even after the story broke early today, Skype could have tweeted out a response... or posted the blog post earlier... they could have cut off all the discussions and concerns simply by being more transparent and providing some information - or even just communicating that they were in the process of getting an answer.

Instead, there is only one word to summarize Skype's communications:


The thing that kills me is that Skype employs a ton of truly brilliant engineers. They have on their payroll a couple of the leading SIP/VoIP security researchers that are out there. And these guys know how the security community works.

Knowing some of those folks personally, I have to think that the process broke down somewhere in the external communications side of the house. Because of the IPO and the "silent period", I know that people at Skype are ultra-cautious about saying anything. And maybe that's part of it, but in this case, it truly failed them.

Too bad... because none of all this communication today had to happen.

If you found this post interesting or useful, please consider either:

Sorry, Skype, But Your Auto-Update Feature Is A Fail!

According to Skype's Security Blog post right now, I'm supposed to just do an "auto-update" that will give me the latest version of the Skype for Mac client. When I check what version I have, it is

Skype 1

So I go up to the Skype menu and choose "Check for Updates..."


And this is what I get...


So if, as Skype indicates, this security issue was fixed a month ago, how was I supposed to get it?

Sure... it now seems that I can go to the main page and download the software directly, but why would I ever think of doing that?

C'mon, Skype... if you are going to send out security updates as optional updates, please make sure your "Check for Updates" feature works!

P.S. When I first heard of the security issue, after checking the Skype blogs and Twitter streams, the first thing I did was to go into my Skype 5.1 client and do this "Check For Updates". The next thing I did was check the Skype for Mac Release Notes, which still do not list this update that was apparently fixed in April. After that I did some more poking around and then wrote the blog post...

If you found this post interesting or useful, please consider either: