[VOIPSEC] Truths on "Truth in Caller ID Act"

[Simon Horne]

Dustin

I have copied the "as reported" news article from your presentation, very 
informative.
http://www.dailypayload.com/2396

Although I prefer this story in CIO (although it is a little alarming)
http://www.dailypayload.com/2380

It time the kit gloves are thrown off and the community starts to deal with 
(or lack there of) the extremely important issue of call party (peer 
entity) authentication. I remember it was not that long ago, I had a tough 
time convincing people on this list from some of the largest VoIP 
manufacturers that there was not a "splitting hairs" difference between 
call party authentication and encryption. Now this does not necessarily 
mean I'm suggesting embedding certificates in the invite messages (which we 
have discussed is impossible to do anyway in SIP) but very simple things 
that could (or can't) be done to verify the caller is who they say they are.

Looking at the topic "Truth in Caller ID", heck we can't even come close to 
do that right now in VoIP (TLS, SRTP do absolutely nothing to deal with the 
problem) but with the push to integrate SIP with the PSTN and open source 
code like Asterisk it could get a whole lot worse.

Let me explain in technical terms. On the digital PSTN, Caller IDs are 
contained in the CallPartyIE and the DisplayIE fields. The CallPartyIE is 
used by the provider to verify the caller and the DisplayIE is the number 
to display to the caller. Now in protocols like H.323 the Q.931 is carried 
end-to-end from the originating caller to the terminating called party 
PSTN->VoIP->PSTN so that if a spammer places a call from a payphone in 
Nigeria then it is possible (although not regularly done) to force the 
DisplayIE not to be altered (maybe made fully qualified E.164) from the 
originating PSTN to the terminating phone so the caller ID on the receiving 
party will be a Nigerian phone number.

Now today, most of the international VoIP clearinghouses are still H.323 
and most of the originating parties are calling card providers originating 
calls from the PSTN and the terminating parties are large vendors with some 
degree of control over the gateways, so the impact from VoIP originating 
spammers is marginal and enforcing "Truth in Caller ID" is still possible 
to do in VoIP.

Now SIP does not support Q.931 so it's impossible to carry the callerID 
unaltered end-to-end. With the "migration" of these clearinghouses to SIP 
things could start to get a little ugly. With the explosion of open source 
software like Asterisk it's now possible for anyone to buy a 4 line E1/T1 
card and using SIP to start earning money terminating calls to the PSTN so 
effective control of the terminating gateways previously exercised is lost. 
The software is open source and free, the protocol is relatively simple, so 
anyone with a half a programming brain can build a VoIP Spam bot in Nigeria 
and buy minutes and start flooding the clearinghouse with pre-recorded VoIP 
spam. Now this SPAM is not going to come out of one particular gateway 
anymore in your neighborhood but could be from anywhere someone is trying 
to earn a few dollars. To complicate things more, from the PSTN provider 
point of view it will be almost impossible to distinguish which calls are 
SPAM. The "safety" of the SIP walled gardens is smashed because now the 
spam is not coming over the walls but walking in the front door.

Now the phishing issue can be just as bad. Nigerians can place a SIP call 
through the clearinghouse with a spoofed displayname and pretend to be your 
local bank. How would you ever know? There caller Id appears to be the bank.

Pandora's box springs to mind.

Simon



At 03:47 AM 6/10/2006, you wrote:
> > When is a group like this going to admit that there is a problem that 
> needs
> > to be solved and then try to solve it?
>
>I'll readily admit that there are a number of problems that needs to be
>solved.  I even outlined this exact problem in a presentation I gave at
>ToorCon 8 in San Diego last weekend.  I just don't believe that it can
>be solved with the technologies that we have available today without
>first building an interoperable, trusted user identity system.