[VOIPSEC] VoIP and Fraud

[Brian Rosen]

So the way this will work in VoIP if things go the way I think they are
going is:
1. The PHONE learns its location when it boots using, for example, a new
option to carry location in DHCP
2. When an emergency call is placed, the location is put in the signaling on
the call using, for example, PIDF-LO for SIP.
3. There will be some electronic signature on the location to avoid most of
the opportunities for fraudulent location, although in some circumstances a
replay attack may be possible.

The signaling also includes a "Call Back Number" so that if you are
disconnected, the emergency call center can call you back.  The
"P-Asserted-Identity" or Peterson's Identity work will suffice for this
purpose.

Brian

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Mark Fletcher
> Sent: Tuesday, February 15, 2005 9:53 AM
> To: 'Geoff Devine'; 'Voipsec at voipsa.org'
> Subject: RE: [VOIPSEC] VoIP and Fraud
> 
> I agree with you Geoff, and that is the inherent problem. In an all IP
> environment, point-to-point trust models can be developed. The problem is
> that a user on a standard POTS line has no way of authenticating an IP end
> point at the far end. That authentication would have to come from a higher
> level. I agree, some sort of admission control would have to be developed
> to
> prevent an unauthenticated end point from even coming online. The root of
> the problem, I believe, is that new we have placed control in the users
> hands.
> 
> Take the E911 system for example, no location data is actually 'passed'
> from
> the origination point. The E911 Location screen is populated at the
> dispatcher console based on a ALI database dip using the CLID as the
> index.
> So for example in NJ, I can be in Atlantic City, hit a local PRI trunk
> with
> spoofed CLID, and end up at a PSAP in Newark (practically the other end of
> the State). E911 routing is based on CLID and nothing else, and
> unfortunately that is now easier to spoof.
> 
> In the same respect, the name you get on CLASS Caller ID service at your
> house is also based on a database dip at your local CO. So if I could
> spoof
> my CLID to match the number of your local PD, I could call your house and
> the CLASS name display would read "ANYTOWN POLICE DEPT". Imagine what I
> could do then......
> 
> Yes, this is fixable with a change and/or policing of the technology, but
> that is not coming anytime soon.
> 
> Fletch
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Geoff Devine
> Sent: Monday, February 14, 2005 10:51 PM
> To: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] VoIP and Fraud
> 
> 
> Mark Fletcher fletch at nortel.com writes:
> > There are many potential areas, but one that concerns me is the
> > ability for a user to easily spoof their Caller ID. Typically this has
> > only been available to administrators of a PBX with PRI circuits. Many
> > call this 'security via obscurity'. By spoofing CLID, a caller could
> > raise havoc with Emergency Services and the national E9-1-1 system, or
> > use a spoofed CLID to socially engineer people into giving up personal
> > information.
> 
> 
> 
> The issue here is that endpoints can't be trusted.  Endpoints can only be
> authenticated.  A PBX running Primary Rate ISDN is quite different from a
> mass market subscriber SIP endpoint somewhere out there in the world.  You
> should not _trust_ that device to give you accurate CallerID.  The device
> is
> portable so you should use its routable IP address to obtain physical
> location rather than _trust_ it to tell you where it is.  To create a
> secure
> service, you can't blindly pass SIP messages around as a lightweight SIP
> Proxy.  You have to adopt a more hardened Back2Back User Agent model where
> you understand exactly what the endpoint is signaling and have the abilty
> to
> police the signaling.
> 
> 
> 
> Geoff
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>