The Dangers of Push Notification in Mobile SIP Applications
Jul
07
2010
The Dangers of Push Notification in Mobile SIP Applications Comments: 2
Mobile SIP Applications: What You Should Know
Mobile SIP applications are here! While this is great news, it's important to be aware of certain security risks and choose your SIP application and SIP application features wisely.
To make a mobile SIP application truly useful, it must do everything a desk phone does including, and most importantly, it must notify the user of an inbound call. Without that feature, a mobile SIP app is simply a novelty. For the iPhone, inbound call notification is made possible by one of the two options:
- SIP via TCP/IP
- Apple's Push server
Unfortunately for providers who use UDP protocol, like OnSIP, option TCP/IP presents a compatibility issue, and push presents a security concern. Here is an explanation of what you should know.
Some Soft Phone Apps Support Only TCP/IP, a Problem for VoIP Providers using UDP
We've previously written about the reasoning for UDP. If Apple were to use UDP, VoIP providers using UDP would have the ability to route calls as they do to any other user agent: A call would come into a VoIP provider, the VoIP provider - OnSIP in this case - would send the call via UDP directly to the iPhone just as it happens on every inbound call to other call platforms today. Upon receipt of that UDP packet, the phone would wake-up and ring, announcing to the user that a call was coming in.
Because Apple does not support wake-up on UDP packets, the above model will not work. So, now we'll discuss option 2 for Apple (and other softphone applications that only support TCP/IP): Push notification for incoming calls via providers using UDP. For mobile VoIP applications, push notification is essentially a workaround for receiving call notification from a provider using UDP. However, this is where the security issues come in.
Push Notification Presents a Security Issue
Apple's Push notification is an elegant solution to applications that aim to notify the user of external events. (We are not speaking negatively about Push notification as a whole!) However, in regards to using a mobile SIP application with a VoIP provider (like OnSIP), Push presents a major certain security concern:
With Push, the softphone application sitting on your iPhone sends your OnSIP username/password to the third party softphone vendor.
As such, if you are using a push-enabled softphone application with OnSIP, the softphone vendor registers with OnSIP on your behalf. Then, when a call comes in, we send the notification of that call to the third party softphone vendor so that they can send a notification to the Apple Push server. The Apple Push server, in turn, sends a Push notification to your phone, alerting you of the incoming call.
The problem with this particular approach is that we have zero control over how the third party softphone vendor sends the username/password over the Internet from the phone to themselves. They cannot use the same MD5 authentication (one-way hash) that is used when a phone communicates directly with the VoIP provider because MD5 requires that both sides already know the password and you're just confirming it. In this case, with a third party provider in the middle, they don't know your password and are therefore sending new information.
Even if the third party provider does not plan to do anything nefarious with your credentials, they still have to find a secure way to send your username/password over the Internet every single time the phone starts up. If their security is compromised, all of the usernames/passwords going to/from them are compromised. Encryption-wise, confirming something both sides already know is much, much easier than conveying new information from one system to another.
To do SIP via TCP/IP, VoIP providers have to re-tool their servers to support TCP and/or set aside specific servers to support SIP via TCP. The softphone only communicates username/password directly with OnSIP. During that conversation, the password is obscured with MD5 authentication, and again, both sides are just agreeing on the password, not transmitting it. Switching to SIP via TCP is neither quick, easy, nor cheap. However, it is the most secure option and the option that Junction Networks is leaning toward to suport OnSIP for our mobile SIP customers.
Bottom Line: Turn Off Push if You are Using OnSIP or Any Other VoIP Provider Using UDP
In short, mobile SIP is still in its infancy and as such still has some growing pains. Until all the security is sorted out, our strongest recommendation is to use the mobile SIP applications with OnSIP, but do not, at this time, enable Push notifications.
As far as iPhone soft phones go, for overall reliability, sound quality and security, our current top recommendation is the Bria softphone from Counterpath. Just don't enable Push.
I think a preferred solution
I think a preferred solution would be for OnSIP and softphone providers to use oAuth and webhook to authenticate and push information between themselves.
re: I think a preferred solution
The problem that oAuth is meant to solve is certainly a useful way to view the same problem we have here, however it just isn't the right tool for the job. oAuth and webhook are mechanisms for HTTP based applications to authenticate and use a simplistic eventing mechanism. This works well in the WWW (HTTP) world in which there is a simple client/server model where the resource identified in an HTTP URI maps to a single resource on the the internet, for example when I send an HTTP
GETtohttp://www.google.comthere is only one HTTP resource I am attempting to contact (this at a different level than the DNS resolution of www.google.com, that's not an HTTP resource). However, OnSIP is built on the SIP protocol which has very different aims from HTTP. In SIP a single URI likesip:bob@example.commay be (or somehow map to) an address of record (AOR) which is then permitted to correspond to multiple IP based locations. To conquer this challenge the core SIP RFC very clearly defines the SIP registration protocol that allows a SIP service to locate endpoints when it needs to contact a SIP AOR. For something like oAuth to work there would need to be a SIP RFC defined that specifies a token based access granting registration scheme.To conquer the problem here we first need to realize what the problem is, and the idea of oAuth is certainly the right paradigm; that problem is granting permission for another outside service to receive calls without exposing the credentials that give a third party the ability to run up your phone bill. With this view of the problem in mind an equivalent, but SIP centric solution may instead be to register as a different SIP AOR with the push softphones, say
bob@no.risk.com, that has minimal downside if the credentials are stolen. Then setup an OnSIP group to simultaneously ring your OnSIP user addressbob@example.comandbob@no.risk.com. By placing a secondary address in the call group you are granting permission for that address to receive your phone calls, without extending it the ability to initiate phone calls as your trusted AOR.The downside here is when you answer the phone call as
bob@no.risk.if.hacked.comyou won't be able to transfer to your OnSIP extensions trivially (or transfer to the PSTN) unless your "low risk" user happens to somehow be in your OnSIP domain. Unfortunately, it is not currently possible to set up a user in OnSIP that does NOT have the privilege of making paid telephone calls.---
Erick J
Junction Networks Engineer