Subject: [Sip] Re: REFER security

From: William Marshall <[email-masked]>
Date: Thu, 14 Mar 2002 13:13:29 -0500 (EST)

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
[email-masked]

-----original message-----
Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time)
From: Rohan Mahy <[email-masked]>
To: [email-masked]
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'" <[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: Rohan Mahy <[email-masked]>
Date: Thu, 14 Mar 2002 17:54:54 -0800 (Pacific Standard Time)

> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2002 18:10:45 -0800 (PST)

?? 

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

		Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Mar 2002 20:00:35 -0500

> document that defines REFER.

Certainly, more things than cc-transfer would benefit from a capability
like this. I think the general problem is a mechanism for A to indicate
to B a piece of information (a sip fragment or full sip mesage) which is
signed by a third party. Such a mechanism is arguably orthogonal to both
REFER and cc-transfer. If it existed as a standalone specification, it
would probably be handled as a MAY kind of reference in REFER, with more
details provided in the cc-transfer spec.

One way to accomplish it is with S/MIME. A request can contain fragments
with third party signatures. In fact, S/MIME with self-signed certs
works REALLY well for cc-transfer. Consider the scenario where A calls
B. A provides a self-signed cert in the INVITE, as does B in the 200 OK.
Now, they are in a call. A sends a REFER to C. This REFER has a BIG
Refer-To URI for B that contains, as a URI parameter, an SMIME body that
is a signature over the To, From, Call-ID of the dialog between A and B.
In the triggered INVITE from C, this signed body is included. When B
receives the triggetred INVITE, it accepts it (remember, it has a
Replaces header) only if its signed with the same key provided by A for
that dialog. 

The benefit of this approach is that it doesn't require any pre-shared
secrets, no PKI, and allows for excellent assurance that the dialog is
being replaced by a triggered REFER from the peer in the dialog.

More details needed, but thats the general idea.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Mon, 18 Mar 2002 10:18:18 -0600

Is it possible for a sniffer to use the INVITE/200 exchange between A & B to
construct such a INVITE to B that replaces the call from A to B? Since there
are no pre-shared secrets, this appears to be a possibility.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: Sunday, March 17, 2002 7:01 PM
To: Rohan Mahy
Cc: William Marshall; [email-masked]
Subject: Re: [Sip] Re: REFER security

-Jonathan R.