Subject: [Sip] Re: REFER security

From: Rohan Mahy <[email-masked]>
Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time)

Hi,

I'm a little unclear whether it is REFER that needs security, or its
usage.

- A REFER which starts a new dialog should be challenged just like any
other request that starts a new dialog (INVITE, SUBSCRIBE).

- A REFER in the context of an existing dialog should be treated just like
any other request in that context (reINVITE, BYE).  If you are using TLS,
you don't have any reason to challenge these requests, if you aren't using
TLS you should probably challenge these requests.

I think what we are talking about is the security or introduction of the
triggered request.  Can we reasonably discuss this issue in each
"usage" of REFER, the first being cc-transfer?

thanks,
-rohan

------------------
To: "'Robert Sparks'" <[email-masked]>, [email-masked]
Subject: RE: [Sip] Status of REFER
From: Alan Johnston <[email-masked]>
Date: Tue, 12 Mar 2002 12:43:21 -0600
Importance: Normal
In-reply-to: <[email-masked]>
List-Id: Session Initiation Protocol <sip.ietf.org>
Sender: [email-masked]

--------------------------------------------------------------------------------

Robert,

I'm confused about this.  We decided a while back to remove a REFER
specific security scheme in favor of a more general SIP security
approach.

Now that we have the general SIP security scheme in bis, you are
suggesting that we have to add a REFER specific security scheme back in?
This makes no sense.

Also, I feel that this is a specific case of the more general problem of
how to transport and pass around an "authorization token" for want of a
better description in SIP.  It could authorize a transfer, a call back
through a gateway, a one-time use of a special SIP service, etc, as
briefly mentioned in the Multiparty Framework document.

I am in favor of solving this general problem, not inventing a REFER
specific approach (again) which may or may not work for the more general
case.

REFER is already way, way, way behind schedule - lets not delay any
further by wading into another security quagmire - please.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Robert Sparks
> Sent: Tuesday, March 12, 2002 9:06 AM
> To: [email-masked]
> Subject: [Sip] Status of REFER
>
>
> First - many thanks to those people who found the time to
> comment on the current REFER draft during the bis-storm.
>
> The feedback I received indicates that we should alter the
> plan discussed in SLC. Specifically, we should not advance
> the REFER draft without a concrete mechanism for securing
> information passed from the referror through the referree
> to the refer target). I'm working on a couple of mechanisms now.
>
> The draft also needs to be realigned with the new SIP and
> SIP-events RFCs. For instance, the ;cseq= parameter should
> be replaced with the more general ;id= parameter in events.
>
>
> RjS

_______________________________________________
Sip mailing list  https://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: Thu, 14 Mar 2002 11:05:57 -0800 (PST)

> TLS you should probably challenge these requests.

   Let's be careful here. Authentication != authorization.

   For example, a UAC can identify myself to my
   UAS, but that says nothing about whether my
   screener authorized that UAC to get past it for
   the REFER/INVITE I see incoming. I don't see
   the current set of mechanisms as providing the
   necessary functionality.

	  Mike