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

From: [email-masked]
Date: Fri, 19 Apr 2002 14:49:33 -0400

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.

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:

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

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

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 1:51
> To: [email-masked]'; [email-masked]; [email-masked]
> Subject: RE: [Sip] REFER security options - removing Referred-By
>
>
> 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,
>
> 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
>
>
> _______________________________________________
> 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: "Ben Campbell" <[email-masked]>
Date: Mon, 22 Apr 2002 08:48:19 -0500

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, April 19, 2002 1:50 PM
> To: Adam Roach
> Cc: 'Elwell, John'; [email-masked]'; Robert Sparks;
> [email-masked]

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.