Subject: RE: [Sip] REFER security

From: Robert Sparks <[email-masked]>
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: [email-masked]
Date: Tue, 20 Nov 2001 19:51:03 +0200

Hi,

> Fortunately, the current refer draft does not allow a "method="
> parameter on the Refer-To header.  Hopefully that stays that way.

I have found an example in 3.1.1 showing that
Refer-To: sip:[email-masked];method=SUBSCRIBE

Regards,
Krisztian

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Nov 2001 14:09:24 -0500

> 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.

Well - it does allow a method to be specified, though it's policy
on the reciever's point whether or not it will use it. The DoS you 
suggest is not as easy you imply though - the REFER would have to
contain
the appropriate dialog identifiers and the endpoint processing
the refer would have to agree to reuse them - not likely. I suspect
others are thinking about an _in-dialog_ REFER that would just reuse
the existing dialog identifiers in the resulting requests - that just
moves the problem - the attacker still needs to know the dialog
identifiers to inject a REFER that would work - if they can do that,
they can just introduce the BYE directly.

<snip>

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

Agreed. That would be an unwise default policy.