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

From: "Sriram Parameswar"<[email-masked]>
Date: Fri, 5 Apr 2002 10:40:44 -0600

Hi All,

To quickly summarize - the Referred-By is undoubtedly a good thing to put
into a request resulting out of a REFER. However to quote the REFER draft 
<<quote>>
If the URL is a SIP URL, the Referred-By header in the REFER request should
be copied into the request sent to the referred-to resource.
<<endquote>>

It seems to me that this of "SHOULD" strength, and anybody not
willing/wanting to send it - need not. I am of the opinion that we use the
appropriate mechanisms (either the SMIME/ or direct transferor to transfer
target verification method) to ensure that this Referred-By is verifiable.
Also if the transferor is wanting to protect itself it could always put in a
URI of the nature:
	sip:[email-masked]

and allow the transfer target the choice to accept or deny the call.

Removal and converting it into Requires does not buy us much. I vote that we
continue down the path as suggested in drafts-sparks-sip-sec-options-00 and
leave the Referred-By header as is.

Thanks,

Sriram

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Friday, April 05, 2002 9:41 AM
To: Nigel Dewdney
Cc: [email-masked]
Subject: Re: [Sip] REFER security options - removing Referred-By

On Fri, 2002-04-05 at 09:07, Nigel Dewdney wrote:
> 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?

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

> 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.

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

> 
> 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
You got your alphabet mixed up there.
> 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.

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.

> 
> 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.

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.
> 
> Regards,
> 
> Nigel Dewdney
> Laboratory Telecommunication Sciences
> 
> 
> [email-masked] wrote:
> 
> >
> > 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
> >
> >
> 
> 
> _______________________________________________
> 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: [email-masked]
Date: Mon, 8 Apr 2002 10:17:09 +0200

-

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

I am not convinced that Replaces by itself will completely address this
issue. Adding a Replaces header still does not explicitely convey that
the reason for the replacement is a transfer. 

The difficulty we're getting into here, is that on the one hand there is 
the REFER method with its mandatory/optional headers and on the other hand
there is the application of the REFER method. Transfer is "just" an 
example
of the latter. Anything that is specific to transfer, should probably not 
be a mandatory thing for the REFER method.

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

I suppose that that is correct. On my POTS telephone, transfer works like
a charm and it (the POTS phone) certainly hasn't a clue about what's going
on. However, this is more a matter of history than anything else: there
simply didn't use to be any means to convey this sort of information. 

The fact that there are applications out there, may or may not be an 
issue. 
First of all, the SIP specification is still fairly new, so how many 
applications do you expect to be adhering to the latest SIP specification 
anyway
and how many of these "fielded applications" do you expect to remain in 
existence? 
I suspect that many of the existing implementations (based on RFC2543 or 
on 
some version of the 2543bis draft) will simply disappear in the near 
future. 
In other words, it is still early days for products based on the final 
version
of RFC2543bis. Secondly, when introducing new elements in the protocol, 
what 
_is_ important is that this does not break existing implementations. 

As long as we do not specify _exactly_ what a service (transfer in this 
case) 
is supposed to deliver, this discussion will continue and go full circle 
at 
some stage.

---

From: [email-masked]
Date: Mon, 8 Apr 2002 10:17:10 +0200

Robert,

>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.

That might be an idea, but I would say that Referred-By is about the
only thing that can be used to convey some information about the "nature"
of the REFER. Furthermore, Referred-By is not specifically tied to any
application of the REFER method. If there is service specific information
to be conveyed with the REFER (e.g. for call transfer), than this is
outside the scope of the definition of the REFER method and its 
constituent headers. 
Regards,

Frank

---

From: [email-masked]
Date: Tue, 09 Apr 2002 18:04:55 +0200 (MEST)

Sirs,

I think there are plainty of cases where C :
-will not need to know that the call was started by A read in Referred-By
-or will trust B (i.e: intranet cases).

Protecting Referred-By also means protecting others headers.

This means that we should avoid all solutions that are not optional regarding C 
policy.

A VERIFYing approach starting at C is better suited; It allows C to decide to 
verify or not A identity.
If C does NOT want to or does NOT support VERIFY the call flows remains 
consistent with current behavior.

PS: Referred-By is a means for carrying some useful Information.

That's my 2 cents.

Best Regards,

Patrick

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Apr 2002 07:50:45 +0100

I agree with what Patrick Mourot says. Let's have a basic refer capability
that provides an unsecured identity of A to C, and then leave it to C to
decide whether and how to verify the identity of A. This will depend on
whether it is attended or unattended transfer - with attended transfer the
call A-C will exist and will be identified by the Replaces header. This may
be sufficient, but if not, verification can be done in the context of that
dialog A-C.

 ---------------------------------------------------------------
 John Elwell ([email-masked])
 Siemens Communications Limited,
 ---------------------------------------------------------------
 Internet communications are not secure and therefore Siemens
 Communications Limited does not accept legal responsibility for the
 contents of this message. Any views or opinions presented are solely
 those of the author and do not necessarily represent those of Siemens
 Communications Limited unless otherwise specifically stated.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 5:05 PM
To: [email-masked]; [email-masked]
Subject: RE: [Sip] REFER security options - removing Referred-By

Sirs,

This means that we should avoid all solutions that are not optional
regarding C 
policy.

A VERIFYing approach starting at C is better suited; It allows C to decide
to 
verify or not A identity.
If C does NOT want to or does NOT support VERIFY the call flows remains 
consistent with current behavior.

That's my 2 cents.

Best Regards,

Patrick

---

From: [email-masked]
Date: Mon, 22 Apr 2002 11:00:58 -0400

In response to the question of when would authenticated referred-by's not
be required, a valid example would be in an enterprise setting where
extra-protocol means of dealing with abuse can easily be used.

Taking the original scenario that led to the discussion of the need for
authentication of Refered-By's (at least as I remember it).

a) Alice is a CEO who only accepts calls screened by her secretary Bob.

b) Carole is an employee who discovers she can call Alice directly  by
creating a fraudulent Refered-By

c) Carole calls Alice and annoys her with some petty grievances.

d) Alice calls Bob and tells him to not allow calls from Carole any more

e) Bob tells Alice that he did not put the call through and that Carole
must have did it herself with an illicit use of the telephone system

f) Alice does not, as in the originally proposed scenario, order the
immedate removal of the PBX. Instead she tells Bob to take care of the
matter
 .
g) Bob calls Carole's manager Dave and they inform her that further
incidents of this sort will lead to unpleasant consequences.

The scenario could be extended with modifications to public network
situations.

"Ben Campbell" <[email-masked]> on 04/22/2002 09:48:19 AM

To:   <[email-masked]>, "Adam Roach" <[email-masked]>
cc:   "'Elwell, John'" <[email-masked]>,
      <[email-masked]>, "Robert Sparks"
      <[email-masked]>, <[email-masked]>

> [email-masked]
> Sent: Friday, April 19, 2002 1:50 PM
> To: Adam Roach
> Cc: 'Elwell, John'; [email-masked]'; Robert Sparks;
> [email-masked]
>  The information could be useful because C could authenticate the
identity
> outside of the SIP protocol if that is felt necesary. In many cases such
> authentication is not required. There can be other means
> extra-protocol  of
> dealing with abusive callers.
>

I'm not sure I see the connection between the last two sentences? How would
one make use of an unauthenticated referred-by in dealing with abusive
callers? I would tend to expect that abusive callers would be very likely
spoof refered-by headers if it is allowed.

I can accept the idea of referred-by being useful _if_ the endpoint has
another channel of authentication. I am skeptical about any real use of it
without authentication.

Considering that Robert's original question was not, "is there a use for an
unauthenticated refered-by?" but was instead "Is there use for refer if it
is published without referred-by?" with the understanding that a solid
referred-by header would be the subject of future work. From that
perspective, I have to agree with Adam's belief that referred-by should be
removed from the current draft.

>
>
>
>
>
> Adam Roach <[email-masked]>@ietf.org on 04/19/2002 02:37:38 PM
>
> Sent by:  [email-masked]
>
>
> To:   "'Elwell, John'" <[email-masked]>,
>       "[email-masked]'" <[email-masked]>, Robert
>       Sparks    <[email-masked]>, [email-masked]
> cc:
>
> Why is such information useful if it's unauthenticated?
>
> Are you planning to use it to implement policy? If so,
> inclusion of such a header only sets a trap for naive
> implementors.
>
> If not, are you envisioning this information will be presented
> to users? If that's your goal, you'll want to do something
> that works with deployed phones. As a convention (and I'm not
> proposing that this be standardized), you could obtain the
> desired effect with something like:
>
> INVITE sip:[email-masked] SIP/2.0
> From: "Adam Roach forwarded by Robert Sparks"
> <sip:[email-masked]>;tag=12397
> ...
>
> Right?
>
> I feel quite strongly that we should *not* include this sort of
> information
> in the current REFER draft, and work on providing an *authenticated*
> version of this draft at a later date.
>
> /a
>
> > From: Elwell, John [mailto:[email-masked]]
> > Sent: Wednesday, April 10, 2002 1:51
> > To: [email-masked]'; [email-masked]; [email-masked]

---

From: "Sriram Parameswar"<[email-masked]>
Date: Mon, 22 Apr 2002 10:26:08 -0500

I have already pointed out that its only a SHOULD in the REFER spec "If the
URL is a SIP URL, the Referred-By header in the REFER request should be
copied into the request sent to the referred-to resource."

Thus removal is not required if you dont like it dont send it. Otherwise I
simply echo Brian's sentiments.

Thanks,

Sriram

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, April 22, 2002 9:21 AM
To: 'Ben Campbell'; [email-masked]; Adam Roach
Cc: 'Elwell, John'; [email-masked]; Robert Sparks;
[email-masked]

Y'know, sometimes I (personally, not as chair) think we take
the security argument just a little too far.

Sure, I can finagle the From, but Referred-By is the header
I want to use in my GUI.  I'll attach no more credence to it
then I get from FROM unless it's authenticated, but it's damn
useful to display to a user.

We have it implemented, we like it, and I'm keeping it.

Let's leave it in and define it, like FROM, as informational
only.

Or shall we remove FROM on the same basis?

Brian

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 9:48 AM
> To: [email-masked]; Adam Roach
> Cc: 'Elwell, John'; [email-masked]; Robert Sparks;
> [email-masked]
> >  The information could be useful because C could 
> authenticate the identity

---

From: [email-masked]
Date: Mon, 22 Apr 2002 13:21:17 -0400

Why would there be impunity. This can be handled as it is handled now
outside of any protocol. VIPs can use their workplace authority to prevent
unpleasnt calls as they useit to prevent unpleasant visitors. They have all
had experience with people who want to attach themsleves to certain types
of  meetings.

Michael Thomas <[email-masked]>@ietf.org on 04/22/2002 12:33:54 PM

To:   "Rosen, Brian" <[email-masked]>
cc:   "'Michael Thomas'" <[email-masked]>, "'Ben Campbell'"
      <[email-masked]>, [email-masked], Adam Roach
      <[email-masked]>, "'Elwell, John'"
      <[email-masked]>, [email-masked], Robert
      Sparks <[email-masked]>, [email-masked]

Rosen, Brian writes:
 > Well, since it's okay to put George Bush's name in the FROM header,
 > it's got to be okay to put Kofi Anann's admin's name in the Referred-By
 > header.  If Mr. Annan accepts the forged FROM, he will accept the
 > forged referral.
 >
 > These headers are (presently) un-authenticated.  We don't DO anything
 > with them (presently) other than show them in a GUI.  It's useful to
 > do that.  I'll accept an authentication mechanism some day, but
 > an un-authenticated field is useful.

   A trip back to first principles might be a good
   idea here. Back in the 50's when my secretary
   Gladys would get me my coffee, she would also buzz
   me in my spacious office when I had an incoming call
   that I should take. Since Gladys was the source of
   my morning caffeine, her voice imprinted at very
   deep level. Thus, when I had an incoming call I
   could be quite sure that an imposter wasn't
   taking away valuable time from my helm of the
   Department of Loafing.

   Fast forward 50 years. Gladys is by and large
   history, and most assuredly the morning coffee
   she used get me is no more. Along with it went
   the deep imprinting, and the spacious office. Now I
   have to rely on a little LCD display that
   doesn't bring me coffee and now you're telling
   me that unimportant people will be able make
   their way through my screening and reach the
   inner sanctum of Loafing decision making with
   complete impunity?

   Progress. Gotta love it.

             Mike

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Mon, 22 Apr 2002 11:35:29 -0600

> > But let's not throw the baby out with the bathwater, guys.
> 
> No one suggested that. They only suggested not delivering the baby
> prematurely, and not making the rest of refer depend on its presence.

Since we already have a number of implementations of non-secure Referred-By, would it be fair to call this an attempt at a late-term abortion?

--Andy

---

From: [email-masked]
Date: Mon, 22 Apr 2002 21:24:31 +0200

Mike,

none of the headers can be trusted. If we move in a direction in 
which nothing is considered valid and useable unless authenticated, 
SIP will have a long long way to go. 

Frank

Michael Thomas <[email-masked]>
Sent by: [email-masked]
22-04-2002 05:31 PM

        To:     "Rosen, Brian" <[email-masked]>
        cc:     "'Ben Campbell'" <[email-masked]>
[email-masked]
Adam Roach <[email-masked]>
"'Elwell, John'" <[email-masked]>
[email-masked]
Robert Sparks <[email-masked]>
[email-masked]
(bcc: Frank Derks/HVS/BE/PHILIPS)
        Subject:        RE: [Sip] REFER security options - removing Referred-By
        Classification: 

 > useful to display to a user.

   So you're saying that it's OK for me to be able
   to just put Kofi Anann's admin's name in the
   Referred-by header, so that I can get through
   his screening so we can chat about my thoughts
   on San Francisco annexing Canada?

   Groovy.

                                     Mike

---

From: [email-masked]
Date: Mon, 22 Apr 2002 21:24:30 +0200

Tom,

the same would apply to fraudulent From headers, if similar services are 
built on it. Obviously, we can then again get into the issue that the From
header can not be trusted either, but it simply happens to be what's there
today. 

Authentication may certainly be an issue, but it doesn't help to assume 
that it is always an issue. If we start doing this, then nothing in the
SIP message can be trusted and consequently we cannot build any services
(including a simple "call") with SIP as it stands today.

It is not impossible that within certain domains (e.g. a company) the 
SIP telephones in use can be configured, by design or by the system 
administrator, so the problems we are all so afraid of _can_ not occur. 
Furthermore, if someone then tries to abuse the system with a softphone 
that can get around such limitations, there are ways to "detect" that 
this phone is not a "device" that is allowed to use the system.

Headers and the message body are there to convey information, if we state
that none of this information can be trusted and that we can therefore not 

make use of them unless they are authenticated, SIP will have a long way 
to 
go before widespread adoption. 

Regards,

Frank

[email-masked]
22-04-2002 05:00 PM

        To:     "Ben Campbell" <[email-masked]>
        cc:     <[email-masked]>
"Adam Roach" <[email-masked]>
"'Elwell, John'" <[email-masked]>
<[email-masked]>
"Robert Sparks" <[email-masked]>
<[email-masked]>
(bcc: Frank Derks/HVS/BE/PHILIPS)
        Subject:        RE: [Sip] REFER security options - removing Referred-By
        Classification: 

identity
> dealing with abusive callers.

I'm not sure I see the connection between the last two sentences? How 
would
one make use of an unauthenticated referred-by in dealing with abusive
callers? I would tend to expect that abusive callers would be very likely
spoof refered-by headers if it is allowed.

Considering that Robert's original question was not, "is there a use for 
an

---

From: [email-masked]
Date: Mon, 22 Apr 2002 21:24:29 +0200

Mike,

Frank

   Groovy.

                                     Mike