Subject: [Sip] REFER security

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Nov 2001 16:32:10 -0500

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.

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

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: Michael Thomas <[email-masked]>
Date: Tue, 20 Nov 2001 14:32:25 -0800 (PST)

Wandering into the REFER minefield... I should
probably know better. Hopefully this isn't
a complete waste of bandwidth.

 > does indeed come from the same party. As in

   I assume this is REFER (C) B->A?

 >                         R-By: A

   So the basic thing I don't understand here is who
   "owns" admission to the session. Ie, who is the
   ultimate arbiter (if any) of who can join a particular
   session? If anybody can invite anybody else,
   does that mean that each participant needs to
   know the identities of each other participant
   so that we know that newly arriving invitees
   aren't, in fact, crashing the party, as it
   were? 
   
   If instead it's up to the session's initiator
   to do admission checking, I'd think you'd end
   up with a star topology where the initiator
   arbitrates how it wants to control admission,
   as well as presumably what it's willing to
   be charged if that's applicable. This seems
   like a simpler model to me, but I wonder
   whether it scales well for, say, multicast,
   etc.
    
 > to authenticate itself to A.

   Right, and in this case, A seems to control
   admission to the session. But how does A
   differentiate C blindly barging into a call,
   vs being refered by B? Is C's knowledge of
   the Callid sufficient proof? Otherwise, this 
   seems to imply that A would need to know that
   it was somebody on his initial invite list.
   It gets even worse if you have yet another
   level of indirection (ie, A->B->C->D, D->A)
   since A never even admitted C, and the only
   thing it knows for sure is that it invited
   B which is probably not carried across C->D.

	   Mike

---

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

Michael Thomas wrote:

>    I assume this is REFER (C) B->A?

No, A to B, since B ends up sending the INVITE.

>    aren't, in fact, crashing the party, as it

Even if you take existing practice, there's currently nothing that
prevents me from inviting the whole family to listen in on our phone
calls. Note that just because B invites C does not mean that A's audio
will go to C.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Michael Thomas <[email-masked]>
Date: Sun, 25 Nov 2001 12:35:28 -0800 (PST)

> calls. Note that just because B invites C does not mean that A's audio

As I'm sure you're well aware, party lines are not
something trivially reproducible with IP, unlike
analog pots (eg, with SIP phones, not SIP/FXS POTS
gateways). I'll certainly agree that there's
nothing A can do if B is a b2bua acting like a
mixer/bridge, but if B wants to have A or C incur
the cost and/or set up a multicast conference,
they're going to have to participate, right?

In this particular case (and I'm sorry if I'm
being dense here because I don't have a clear
picture in my mind), I assume that there's already
a session between A and C, and that A wants B to
participate?  (and possibly drop out of the call?)
In that case, how does C know whether B is just
barging in, or whether it was legitimately refered
by A? For example, say that the session wasn't
encrypted and I could snoop the session
information to join a call and set up a media
stream to listen in?

If I'm way off base here, maybe you could say what
the two use scenarios were that you outlined?

	Mike

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 26 Nov 2001 12:30:07 -0500

I agree with Robert and Henning.  This is
all solvable with a policy mechanism on the
UA.  The difficulty is coming up with a policy
rules mechanism that mortals can comprehend
enough to allow the desired functionality and
disallow the undesired functionality.  I would
hope that we could come up with a standard
way to represent the rules.

Too bad we don't have a sanctioned effort
on standardizing UA configuration. ;-)