Subject: Re: [Sip] REFER security

From: William Marshall <[email-masked]>
Date: Tue, 20 Nov 2001 07:54:03 -0500 (EST)

Robert Sparks wrote:
> It suprises me, but this is the case [where the REFER comes
> "out of the blue"                    that seems to be scaring 
> people the most. There is FUD circulating that anybody 
> implementing REFER opens themselves to automatically
> accepting REFERences to place calls to numbers that will 
> incur charges. The thing the FUDsters are choosing to
> ignore is that any _sane_ implementation of C is going to
> allow a policy decision to be made before issuing that INVITE
> (and that policy may or may not involve authenticating B).

One piece of the dis-information (D in FUD) seems to derive
from the example posted frequently about 
   Refer-To: ....url....&method=BYE
If this were true and valid, it would enable a hacker "out of the blue"
to cause an existing session to terminate.  What a great denial
of service attack!  And nothing a carrier can do to prevent it.
Fortunately, the current refer draft does not allow a "method="
parameter on the Refer-To header.  Hopefully that stays that way.

One piece of the fear (F in FUD) is the problem of charging.  This
is not a new problem, as it also exists with the 3xx redirect response
to an INVITE.  The DCS draft (still available on Dean's web site)
deals with this by having the proxy generate a private-url out of
the new destination, and include the proper charging information of
the entity that requested the redirect.  The same design works for
REFER (and is shown that way in the informational annex of 3GPP 24.228).

It is clear, though, that a UA that accepts a REFER from an untrusted
source, without authentication, gets exactly what it pays for.

What can be said in the draft about a minimum set of recommended
checks before accepting the refer?  I believe this is the major
uncertainty (U in FUD).

As an example of a current use of "REFER" -- how often do you get those
postcards in the mail saying "you've just won a free vacation, call to
claim your prize".  The phone number looks like a normal one (e.g. not
a 900 number), but Carribean Islands are part of the NANP, and charge
not pennies/minute, but $$$/minute.  While you are waiting on hold "due
to overwhelming response to our great offer..." you will pay more for
the phone call than the vacation is worth.  It is a well-known scam.
The problem is not solved by authentication of the source of the request.

Bill Marshall
[email-masked]

-----original message-----
From: Robert Sparks <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>, [email-masked]
Subject: RE: [Sip] REFER security
Date: Mon, 19 Nov 2001 13:56:52 -0500

This is close, but there's a peice missing - comments inline.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, November 17, 2001 3:32 PM
> To: [email-masked]
> Subject: [Sip] REFER security
> 
> 
> I'm trying to better understand the REFER security issues. It 
> seems like
> there are two approaches:
> 
> (1) If the issuer of the REFER is the same as the caller or callee. In
> that case, the main problem is presumably making sure that the REFER
> does indeed come from the same party. As in
> 
> A -- INVITE --> B
> A -- REFER (C) -- B
>                   B --- INVITE --> C
>                         R-By: A
> 
> It's not clear that C would care about A's authenticated 
> identity, as B
> is in any event responsible for requests it issues, and shouldn't be
> able to "blame" A for waking C at 3 am.

There have been requests to not just be able to authenticate A, but
to allow B to prove to C that A asked _this_ request be sent (so that
C can put the appropriate acceptance policies in place and B can't
put the blame on A unless it really belongs there).

> 
> (2) The REFER comes "out of the blue", e.g., 
> 
> A -- INVITE --> B
>                 B --- REFER (A) --> C
> 
> A <------------ INVITE ------------ C
> 
> This case is no different than standard request 
> authentication. C would
> want to be sure that it is indeed B that it is talking to. C 
> also needs
> to authenticate itself to A.

It suprises me, but this is the case that seems to be scaring 
people the most. There is FUD circulating that anybody 
implementing REFER opens themselves to automatically
accepting REFERences to place calls to numbers that will 
incur charges. The thing the FUDsters are choosing to
ignore is that any _sane_ implementation of C is going to
allow a policy decision to be made before issuing that INVITE
(and that policy may or may not involve authenticating B).

> Is this a fair summary?

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 25 Nov 2001 14:44:18 -0500

> parameter on the Refer-To header.  Hopefully that stays that way.

I don't see why this has to be anything but a policy decision. For
example, asking somebody within an existing signaling relationship to
SUBSCRIBE seems both useful and, given appropriate safeguards, harmless.

> REFER (and is shown that way in the informational annex of 3GPP 24.228).

This matters only for certain models of charging and might be taking as
illustrating that that charging model is broken...

> The problem is not solved by authentication of the source of the request.

The problem is solved by a resource management protocol that indicates
the charges to be incurred ahead of time. In an IP-based environment,
there is no reason not to include this information before committing.
Indeed, I would consider it similar to the requirement that goods for
sale are labeled with their price. From my limited understanding of
consumer protection laws in most developed countries, not doing this
would incur the wrath of the local equivalent of the FTC. 

This seems to be a primarily a legal problem, rather than a technical
one. We can't, via technology, prevent people from filling in their
credit card number on a web site that promises untold riches or
spiritual salvation by reading science fiction. We should, however, make
it easy for protocols that have connection to charging to provide this
information. Do 3G protocols have this type of information?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs