Subject: RE: [Sip] REFER security options - removing Referred-By

From: [email-masked]
Date: Fri, 5 Apr 2002 09:21:48 +0200

Whether "traditional" phone systems provide the sort of information that 
is
carried by Referred-By or not, depends on your definition of "traditional
phone system" and the context in which REFER is being used. There are 
several examples of the availability of "Referred-by" type of information
to be found in today's telephone systems:

- ISDN's (Q.931) Redirecting Number Information Element
- QSIG's (ECMA-178) rerouteingNumber element in the Call Transfer Initiate
  operation
- DPNSS' ....

Etc.

Leaving out all the "nice bits" may result in something that will do the
job (i.e. achieve the call transfer), but this also restricts new services
to be implemented, because there simply isn't enough information to infer
what's going on.

Regards,

Frank

Sounds reasonable to me. I think it would be possible to phrase the draft 
in
a way that when we add in a Referred-By that it does not need a Requires 
and
that REFERs without a Referred-By are just treaded as the Referred-By as
unknown or anonymous.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Robert
> Sparks
> Sent: Thursday, April 04, 2002 8:42 AM
> To: [email-masked]
> Subject: [Sip] REFER security options - removing Referred-By
>
>
> I want to explore the option of removing Referred-By a little.
>
> As the refer-sec-options draft points out, traditional phone
> systems don't provide the kind of information Referred-By is
> trying to provide during a transfer. We've set our goals higher
> for SIP transfer, which is a good thing to do, but is it necessary
> for a base version of the application? Would a transfer application
> that didn't tell the transfer target who initiated the transfer be
> sufficient?
>
> Perhaps the Referred-By functionality should be an extension (Requires:)
> to REFER instead of part of its base definition?
>
> This would remove the security issue with base REFER (B's triggered
> request would be indistinguishable from a request that B initiated on
> its own - there is no claim in the request that the request exits
> because A asked for it to happen).
>
> The current work on securing Referred-By would continue in an extension
> draft, but advancement of REFER would not be blocked on its completion.
>
>
> 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
>

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 05 Apr 2002 08:33:46 -0600

> to be implemented, because there simply isn't enough information to

To be clear, I'm not suggesting we abandon the Referred-By idea. I'm
suggesting we start with a version of REFER that doesn't provide it
and bring it back in with a follow-on extension to REFER.

> 
> Regards, 
> 
> Frank 
> 
> 
> 
> 
> 
> 
> Sounds reasonable to me. I think it would be possible to phrase the
> draft in

---

From: Nigel Dewdney <[email-masked]>
Date: Fri, 05 Apr 2002 10:07:05 -0500

Pardon me if I'm being obtuse, but how do I tell whether an INVITE is as
a result
of a REFER or not if Referred-By is dropped? A calls B. B REFERs A to C,
A calls
C. If C can not tell that the call is a result of a referral from A then
the REFER mechanism
has been reduced into one of "hey don't call me call them!", i.e. the
call from A to C is
disassociated from the dialog between A and B.

Dropping Referred-By could preclude many applications. Okay, an
extension to bring
it back in would enable them, but wasn't the idea of REFER that it be a
primitive to
enable such applications? The obvious example is where C wants to only
accept calls
which have been vetted by B. Irrespective of  security requirements,
this requires
that the primitive have a reference to B in A's request to C. How about
applications
where I would want to treat INVITEs differently according to where the
REFER came
from? E.g. accept calls referred from P.A. but fwd those reffered from
Marketing to my
voice-mail service.

On the question of authenticating the referral I prefer the option of C
VERIFYing with
A. Why wouldn't A put a meaningful contact address in Referred-By: and
expect C
to blindly accept the referral without the option of being able to
contact A? Thats not
to say that I don't thing the S/MIME option isn't possible - I'm just
uneasy about
man-in-the-middle.

Regards,

Nigel Dewdney
Laboratory Telecommunication Sciences

[email-masked] wrote:

>
> Whether "traditional" phone systems provide the sort of information
> that is
> a way that when we add in a Referred-By that it does not need a
> Requires and

---

From: Robert Sparks <[email-masked]>
Date: 05 Apr 2002 09:41:25 -0600

On Fri, 2002-04-05 at 09:07, Nigel Dewdney wrote:
> of a REFER or not if Referred-By is dropped?

That's exactly the point - you wouldn't.

> A calls B. B REFERs A to C,
> A calls

No - that's a separate problem. The kind of association you are
looking for here is what's being addressed through the Replaces header.

> enable such applications? 
> The obvious example is where C wants to only
> accept calls
You got your alphabet mixed up there.
> from? E.g. accept calls referred from P.A. but fwd those reffered from

There are _clearly_ good applications waiting for the Referred-By
functionality. I am _NOT_ advocating we abandon providing it. What
I'm asking is whether or not the base level transfer application
really needs it. There are already fielded implementations that don't
use it providing some evidence that you have a useful service without
it.

> to say that I don't thing the S/MIME option isn't possible - I'm just

I don't follow - you're suggesting that if C tried to contact A and
failed, it would just accept the request by default?

The real problem here is that it may be very difficult for A to
provide a contact to C that will  get back to the UA that has the
knowledge about sending the REFER. Its the same problem
we have with getting B's INVITE-Replaces to the same C we had
a consultative-hold conference with.

---

From: Nigel Dewdney <[email-masked]>
Date: Mon, 08 Apr 2002 09:30:55 -0400

Robert,
Inline:

> That's exactly the point - you wouldn't.

I would argue this is a bad thing. A referral and an unsolicited invited are
conceptually two different things. The endpoint should be aware of the
type of process it is involved in. Whether it chooses to do anything
different as a result is another question.
[snip]

> looking for here is what's being addressed through the Replaces header.

Sorry, I meant association at a functional or application level. It comes down
to
a question of granularity. Do you consider the referral process as one that
just
tells the referree where to go, or one that includes the point of referral?
[snip]

> You got your alphabet mixed up there.

Er, no. This is just another reference to Referred-By (no pun intended).
A->B
A<-B "please A, REFER to C"
A->C
C - "hey did A go through B before contacting me?"
[snip]

> use it providing some evidence that you have a useful service without

I didn't think for a moment that you were! :~) You could certainly achieve
some base functionality without Referred-By, but then you could apply
the same argument to other SIP methods. You could strip out some of the
headers in INVITE and still get some base functionality, but I don't think
anyone is arguing for that. You could remove the From header for example,
as has already been alluded to on this thread. Its another point of
granularity -
you support a lot more with it than without. You can ignore the header if
your application doesn't require it (treat it like the From: header).

regards,

Nigel Dewdney

---

From: Nigel Dewdney <[email-masked]>
Date: Mon, 08 Apr 2002 09:59:33 -0400

Robert,

Robert Sparks wrote:
[snip]

> failed, it would just accept the request by default?

That would depend on C's policy. I would expect default to be to decline.

> a consultative-hold conference with.

I'm sorry, I can't see this yet. If B can contact A, in what situation would
C not be able to contact A (except in the case where suddenly A has an
equipment failure)? The only case I can see is if A is still in dialog with B
and only has "one line". Thus A would respond to B with "Busy". For this
case I would argue that if A is capable of using the REFER method it should
be prepared to deal with another request (without SDP) from the
referral point (C), e.g. VERIFY (if that comes to light). C doesn't have to
establish
media with A for verification.

Regards,
Nigel Dewdney

---

From: Robert Sparks <[email-masked]>
Date: 08 Apr 2002 09:23:13 -0500

> different as a result is another question.

So, are you saying
"It will not be useful to have a version of REFER that doesn't
 make the triggered request distinct from an ordinary request."?

That's different from
"It will be useful to have a version of REFER that does make
the triggered request distinct from an ordinary request."

I agree with the second statement. I'm not convinced yet on the first.

> C - "hey did A go through B before contacting me?"

Ah - I was using the model in the refer-sec-options draft that has
a REFER going from A to B. 
> your application doesn't require it (treat it like the From: header).

Well, the same argument _did_ get applied to other SIP methods as they
were being defined. What we're left with is what we could agree on being
the minimal set of required headers. Of course, the bar was in a little
different place before we had an agreed on Supported/Require mechanism.

Your last sentence is nearing the root of the problem though.
Are you claiming that its OK to provide Referred-By and not secure it?
(where secure it means A provides a proof "X" to C through some
mechanism. X is a proof of at least A's identity, the content of the
Refer-To header A sends to B. There may be more stuff in the proof to
help defend against replay).

Are you claiming that it is sufficient to say in the draft that
an implementation receiving any request (other than a REFER) with a
Referred-By header and no such proof SHOULD ignore the header entirely
while processing the request? (This is analogous to saying an 
implementation SHOULD NOT display the contents of the From header
while the phone is alerting unless the UA has some proof of the
contents of that From header).

---

From: Robert Sparks <[email-masked]>
Date: 08 Apr 2002 10:09:19 -0500

> > [From RjS]
> [From Nigel Dewdney]

The problem is not with C's ability to contact A. It's C's ability to
get a SIP message to the _exact same UA_ that A is using to talk to B.
It's no good if C's request went to some other UA for A - that other UA
has no knowledge of the REFER.

We've seen this problem several times already - there have been long
threads on it in the discussions on attended transfer. In the 
cc-transfer draft, we were bringing in "accept-contact" to try to work
around it (see the far-to-sparse section titled "Consultation hold in
the presence of forking proxies in the transfer draft).

Here's a real world instance of the problem rewritten in terms of
a VERIFY.

I have 3 SIP phones active most of the day, all registering to the
same address-of-record: sip:[email-masked]. One's on my
desk, one's on my laptop, and one's in my house.

Suppose I call Kevin using my desk phone and decide I need to transfer
Kevin to you. My desk phone knows itself (at the moment) as
sip:[email-masked]. Say it puts that value in the
Referred-By header and passes it to Kevin. Kevin passes it to you.
You try to send a VERIFY to to that address and it fails.
Our office is set up to allow SIP traffic only through the proxies at
sip:dynamicsoft.com. Not a problem for Kevin since we got those things
on the request path using Record-Route while setting up our dialog. Big
problem for you.

So maybe I could have set my phone up to provide
sip:[email-masked] in the Referred-By instead. Then your
request would make it into our network. Now you roll the dice to see
if my desk phone is still on the list of things that it might get
forked to. If it is, you'll probably get lucky - the 200 my desk phone
returns will beat out the other phone's non-200 final responses. But all
kinds of legitimate things can happen to cause my desk phone to not be
on that list (time-of-day routing and access control lists give you
the tip of the iceberg). Let make it worse - suppose I placed my
original call to Kevin from a phone that didn't register to any
address of record at our outgoing proxies. Your request is guaranteed to
fail. (Reread this paragraph from the perspective of an INVITE that you
really wanted to reach my desk and think about what happens if someone
picks up my house phone).

Now consider environments where the endpoints live in some variant of
a private address space (nats, split-dns, etc). What kind of identifier
can they hand you that you will find useful for contacting that 
particular endpoint?

The current discussions for solving this problem involve things like
my phone including a preloaded route for you to use in the identifier I
hand to Kevin. What's not clear yet is how my phone discovers that
route.

RjS