Re: [Sip] Re: REFER security

[Rohan Mahy <[e-mail]>]

On Thu, 14 Mar 2002, William Marshall wrote:
> The issue that I raised with REFER security during its last-call period
> last year was the inability of the transfer-target to authenticate
> the Referred-By header with the transferor.  While there may be
> an authenticated relationship between the transferee and the transferor
> (established by an INVITE, and used by the REFER), and an authenticated
> relationship between the transferee and the transfer-target (established by
> the REFER-initiated INVITE), there is no way for the transfer-target
> (i.e. UAS in the second INVITE) to verify that the transferor really
> did send a REFER to the UAC.

Then you are discussing the security of cc-transfer, not the security of
REFER.  This doesn't mean we don't need a solution, but figuring out how
to trust a header in an INVITE doesn't exactly seem like a job for the
document that defines REFER.

thanks,
-rohan

> The result is that the only reasonable policy of a UAS on receiving
> an INVITE containing a Referred-By header is to ignore it.  It can
> only be utilized and believed within a very limited scope that rivals
> the applicability statement in the privacy draft.
>
> If the basic mechanism is of such limited scope, it seems less than
> useful to discuss security for each separate usage of REFER.
>
> In my last-call review of draft-ietf-sip-refer-02, message dated 13 Nov 2001,
> I proposed one solution.  An additional 4xx error response would be
> sent from transfer-target to transferee, which would contain a challenge.
> The transferee would send this challenge to the transferer in a NOTIFY,
> who would respond with an updated REFER with the proper response. This
> response would then be included in a new INVITE to the transfer-target.
> Lots of details TBD, like what additional headers are included in the
> calculation of the response.
>
> An example of the problem with the current draft:
>   Consider the simple case of a blind transfer (described in Section 6
> of draft-ietf-sip-cc-transfer-05):
>   Person X calls the CEO of a corporation, and the call is intercepted by
> a screener (S).  Screener is the transferor, X is the transferee, and
> CEO is transfer-target.  Screener sends REFER to X, then X sends INVITE
> to CEO's private address with Referred-By: S.  So the next time X wants
> to call CEO, why go through the screener?  X has the magic Referred-By
> value to go direct.  CEO gets unscreened calls, and removes SIP phones
> from company.
>
> Bill Marshall
> [e-mail]
>
> -----original message-----
> Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time)
> From: Rohan Mahy <[e-mail]>
> To: [e-mail]
> Subject: [Sip] Re: REFER security
>
>
> 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'" <[e-mail]>, [e-mail]
> Subject: RE: [Sip] Status of REFER
> From: Alan Johnston <[e-mail]>
> Date: Tue, 12 Mar 2002 12:43:21 -0600
> Importance: Normal
> In-reply-to: <[e-mail]>
> List-Id: Session Initiation Protocol <sip.ietf.org>
> Sender: [e-mail]
>
> --------------------------------------------------------------------------------
>
> 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:[e-mail]
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Robert Sparks
> > Sent: Tuesday, March 12, 2002 9:06 AM
> > To: [e-mail]
> > 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip