[VOIPSEC] Watering down VoIP security expectations.

[Tobias Glemser]

Simon,

let me just pick one point of your quite interesting posting.

 > When I first joined the list back in the early days, there was some
 > discussion on SPIT and the tone was "how do we kill it".
(..)
 > solution was actually quite simple. "Put an authentication component
 > in the first call setup message to identify the caller." If the caller
 > has it and authenticates than accept the call. If it doesn't then
 > reject the call.
Maybe this would "kill" SPIT. But without any doubt this would kill 
VoIP. If someone tries to call me, I want my damn phone to ring. I don't 
want to exchange keys or anything like that before the first call can be 
established. And, by the way, we already have SPAM in our good old POTS, 
my answering machine knows what I'm talking about. POTS did not "evolve" 
either, because this is not a technical problem, but a fundamental one.

We want to be reachable without any barrier. This is why I'm sure there 
will never be a way to avoid SPAM no matter which "we want to be 
reachable" media we're looking at: eMail, VoIP, POTS or your door bell. 
("door bell SPAM": "Hello, we would like to talk with you about god", I 
had this twice last year *scnr*).

Just have a look at eMail-SPAM: There have been services (and maybe 
they're still there) where the ServiceProvider sends an eMail back to 
the initial sender, containing a dynamic link the initial sender has to 
follow, to validate he's a human being. This really did the job, users 
of this service almost never got spam because on the "I am a human, let 
me send this eMail" authentication website you had to enter a dynamic 
code displayed in an image. Bots did not take this challenge.
So there was/is a way to avoid SPAM. But, do you know anyone using such 
a service? I don't, because the user acceptance is somewhere between low 
and bottomless.
So, if such a service is not working with a media like eMail, which is 
normally not that time-critical, I really don't think this would work 
with a media like VoIP. Again: If I want to call, I want to call now, 
and on the other side, if I use a phone, I want to be reachable.

Every service which would work without user interaction but 
authentication would be some kind of CA where every phone worldwide is 
registered and as soon as SPAM is reported over a specific phone, it's 
blacklisted. But to get this szenario really working we would have to 
leave earth and go to alice's wonderland :)

So my conclusion is this:
The SPAM/SPIT problem will never be beaten, we can only try to develop 
better and better solutions to eleminate as many SPAM/SPIT as possible 
before it reaches the user. This is where we can evolve, just have a 
look at Anti-SPAM Boxes today. The race has begun but it will never finish.

Cheers,

Toby

Simon Horne wrote on 10.03.2006 02:42:
> Guys
> 
> This is my little rant about a disturbing trend on VoIP security I am 
> seeing on this list and in the press in general. The language has changed 
> from "how do we fix" to "how do we live with", which, i don't know about 
> other people, just does not cut it. IMHO we should be looking for solutions 
> for VoIP Security and answers like "oh that's only a problem IF..." and "IF 
> you don't..." are not answers but compromises. People want ANSWERS and 
> SOLUTIONS, not compromises. VoIP is suppose to be, according to all the 
> press, the next great thing but if you can't we fix the simple things....
> 
> I was gob smacked to read people pushing the virtues of using a VPN to 
> provide VoIP security. VPN?. That's what cavemen were using in the VoIP 
> dinosaur age. Have we not EVOLVED?. I understand the reasoning for 
> suggesting it because it's probably one of the only solutions that ACTUALLY 
> works with different products from different vendors (as discussed SRTP is 
> not widely deployed and vendors that do offer it, can't talk to eachother). 
> So what the heck have we been doing for the last few years? (ok some work 
> has been done, but these solutions are vendor specific and require 
> infrastructure upgrades and may not be backward compatible etc etc...)
> 
> Recently someone asked "So what's new in dealing with NAT?" and the answer 
> "Get an SBC" and then there was a competition of which vendor had the best 
> SBC. That's not an answer, people have been using SBC's (when they were 
> called proxies) for NAT Traversal for 10 years, we've seen solutions such 
> as STUN (useless for symmetric NAT) and ICE (go get a coffee while we wait 
> for the call to connect) so the only real workable "catch all" solution is 
> still "Get a proxy!". What the heck have we been doing for 10 YEARS?
> 
> When I first joined the list back in the early days, there was some 
> discussion on SPIT and the tone was "how do we kill it". Which, at the 
> time, I discussed at length with a college of mine in the open source 
> community about how we could go about "killing it" and we both agreed the 
> solution was actually quite simple. "Put an authentication component in the 
> first call setup message to identify the caller." If the caller has it and 
> authenticates than accept the call. If it doesn't then reject the call. 
> Fairly simple? In reality, this is extremely difficult to do in SIP, 
> basically because there is no dedicated end-to-end call signalling channel 
> which means the two parties cannot easly identify themselves but have to 
> rely on intermediaries and use ideas like SIP identity which puts some 
> limitation on its usefulness. So the common consensus now is that its too 
> hard to fix so lets "manage" the problem. Like Email and SPAM? OMG! We need 
> a SOLUTION.....!!
> 
> In someways, I think the VoIP (and security especially) industry, aside 
> from the hype, is actually devolving (going backwards) and settling for 
> solutions just years before we would of thought as "not good enough". I 
> think there needs to be a wholesale review on WTF are we doing and where 
> are we going because it seem to me that there is a "kinda maybe" solution 
> for this and a "kinda maybe" solution for that and no wholistic approach to 
> the security issue. Maybe we do need to go "back to school" on VoIP 
> security and reassess the protocols and (re)incorporate new ideas (backward 
> interoperable if possible) and not take an after thought "I got this cool 
> VoIP phone now how do I secure it" approach which we have today.
> 
> I do very much commend Richard Paine's recent post, now that is forward 
> thinking, looking at security as not just about securing media by method A 
> and signalling by method B but a wholistic approach and how each of those 
> security elements fit within an overall security framework. Hey this stuff 
> may not be "sexy" and not the "in" thing and maybe not even the flavor of 
> the month but it is extremely important and when it comes to the crunch and 
> the customer says "Give me secure VoIP" they don't want excuses, they don't 
> care what color or flavor it is, all they want is for something to JUST WORK!
> 
> 
> Simon