[Sip] Re: REFER security

[William Marshall <[e-mail]>]

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.

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