OSP as an Authentication Mechanism

BlueBox Podcast #53 has some further commentary by Dan York and Jonathan Zar in relation to the openID debate and how that fits into the SIP realm.

Jonathan also asked for some more detail on how OSP fits into a security discussion. I also wanted to create some further discussion on OSP, something I started when I posted my thoughts on the openID in SIP debate here. I didn't mean to steer the openID debate into an OSP debate. They are separate animals. I therefore want to start an OSP specific thread afresh in order to explain some of the fundamental misunderstandings about the security aspects within OSP.

It's not about what it says on the Tin

Because OSP is a settlement system ("Open Settlement Protocol"), as such, most people in the VoIP space that have heard of it, and even some that may have looked at it, will think purely in terms of settlement (two networks agreeing to exchange traffic (peering) where "settlement" is the price agreed for that exchange).

However, to my mind the most exciting element of OSP is actually the way it resolves a particular security problem : Identity Misrepresentation.

What's the Problem?

Let's take as a starting point the definition of "identity misrepresentation" from the VoIP Threat Taxonomy.

Here it is in short:-

Quote:

....identity misrepresentation includes: * presentation of a false caller ID name or number with the intent to mislead * presentation of a false voice, name, or organization in a voicemail with the intent to mislead * presentation of a false email with the intent to mislead * presentation of false presence information with the intent to mislead

You can read the full version here.

The "threat" is that someone can spoof/fake a SIP header such that the call looks like it's coming from someone else. In the PSTN world, this is akin to tampering with or changing your callerID so as to represent that you're someone else.

This issue is fundamentally engrained in the SIP protocol which, unfortunately, did not have the foresight to envisage SPAM/SPIT and other security topics, much in the same way that e-mail failed to address identity misrepresentation by design. You can put any "FROM" header you like in an email message. SIP suffers the same.

Single Server Safety

What a SIP proxy does do is validate its own clients. The effect of this is that identity misrepresentation in SIP is not really a concern in a single proxy environment.

Let's say I want to call Martyn. Only one proxy is involved in this example because the party I'm calling happens to be on the same proxy as me. I pickup my dean@ voipuser.org connected phone and dial martyndavies@ voipuser.org. I have already validated with voipuser.org when I first logged on with my SIP phone, I presented my username and password combination to the proxy which was then validated. Martyn did the same.

Result? The proxy at voipuser.org knows that it's really me, and it also know's that it's really Martyn. Martyn's phone "knows" that the incoming call stated to be routed by the proxy voipuser.org really is from the proxy voipuser.org as he's connected to it (although that connection is stateless, most phones I know of will validate this client-side by IP address. It's not impossible to spoof, but it's pretty difficult as you have to match incrementing SIP header ID's, which really means you need a "man in the middle").

So with single proxy configuration, no real problem. It's spoofable, and therefore not perfect, but it's really good enough*.

No Safety In Numbers

Things start to get messy when you bring a second proxy into the equation. Let's have a look at another example:-

I want to call Martyn, but this time we'll say that Martyn's SIP account is with sipphone.

1. I pickup and dial martyndavies@ sipphone.com
2. My SIP phone communicates with my proxy (voipuser.org)
3. voipuser.org says "not one of mine, but we're peered with them" and hands the call to....
4. .... the proxy at sipphone.com
5. sipphone.com routes the call setup message through to Martyn and we speak.

The problem area here is at stage 3 and 4. Whilst the voipuser.org proxy knows that I'm Dean, and the sipphone.com proxy knows that Martyn is Martyn (we both validated by logging on), neither proxy can really be sure of the other proxys' identity. There has been no formal authentication between them. In practice, in a small bi-lateral peering setup with two proxies like this, authentication can of course be done by IP address. However, bi-lateral peering simply doesn't scale. Well, OK, that's a subject for another discussion but for now, imagine peering with 500 different proxies and having to maintain and keep up to date a list of 500 IP addresses and whatever other associated data you might need to authenticate. It's not practical.

A Standards-based Solution

Enter OSP, which sits in the middle of a multi-lateral peering configuration and has the primary job of collecting call data records for calls which pass through it for the purpose of billing and settlement.

As I stated earlier, this point, in my experience, is where most people who have looked at OSP stop looking at OSP. I want to take it a step further, where some interesting security features start to unfold.

Take a multi-lateral peering system, where settlement is involved. It's critical that the data you collect is absolutely accurate. Both parties are relying on that data in order to calculate how much money needs to change hands in accordance with the peering arrangement.

Let's say that VoIP User peers with Sipgate, and the settlement deal is that we'll pay Sipgate 1p/min for calls we route into their network. If someone manages to spoof a packet header such that Sipgate identify the call is coming from VoIP User, Sipgate are going to send a bill to VoIP User for the traffic at 1p/min as agreed. VoIP User, as recipient of that bill, is going to be confused because the VoIP User server call data records are going to state that actually the call Sipgate are trying to bill for wasn't one of theirs.

Not a happy state of affairs, and one that should not be allowed to happen.

The Nitty Gritty

Within an OSP handled peering transaction, each proxy is individually authenticated and given a token to hand to the other proxy. This exchange of tokens ensures the identity of each proxy, and guarantees to each proxy that there are no identification problems. If there are problems, the call can be rejected and the OSP server will not register any required settlements.

So far the focus is on money - making sure that settlements between providers are fair and accurate. But here's the rub; OSP is just an authentication and CDR collection protocol. There's nothing to stop it's use within zero-rated settlement peering. Collecting accurate call records is still useful, it's simply a case of no money exchanging hands.

So forget settlements. The real benefit of OSP, to my mind, is the token exchange and identity authentication that takes place between the two peered proxys. That, coupled to client authentication by the proxys themselves, gives end-to-end authentication and identification that would be very difficult to spoof. What's more, OSP is an ETSI adopted specification, an open standards based protocol and it's already featured within SER, openSER, Asterisk and the SIPfoundry suite. It also comes with pedigree - Cisco, 3COM and TransNexus jointly developed it. What more could you ask for?

Going back to where we started, this is the reason I don't see openID as a potential candidate for securing SIP transactions. It's a client->server system and SIP already has authentication procedures in place to do that. What we lack is server->server - it's the future peering of all these little VoIP Islands that really creates the problem. At the moment, we don't have to worry about it too much. When things start to scale, the implications of SPIT and Identity Misrepresentation become really problematic.

The means of addressing it are available now and for the most part only require VoSP's to hit the OSP module "button" on their servers. The capability is already built right in.

Dean

* - security between client and proxy could be greatly improved using TLS, but that's a subject for another day.

Voip User Forum Index » The World of VoIP » VoIP Security