Re: [Sip] Re: REFER security

[Michael Thomas <[e-mail]>]

?? 

I thought that cc-transfer was on an
informational track?

		Mike

Rohan Mahy writes:
 > 
 > 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

_______________________________________________
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