Subject: RE: FW: [Sip] Comment, SIP Privacy draft

From: "Mark Watson"<[email-masked]>
Date: Tue, 2 Apr 2002 15:06:28 +0100

Jon Peterson wrote:

> I only entered into this 
> fray because of
> the ways that RPID was proposed to be used, because a 
> concrete case was
> raised in which a major customer of SIP wanted to abuse RPID 
> and create
> serious interoperability concerns. 

This seems to be a key issue here, and one where I do share your concern.

To solve this we do need to solve the underlying problem which led to this
'abuse' of RPID. If we solve this problem, then I think all the rest of our
arguments drop out.

As I said before, I believe the arguments which led to this will lead to the
same place in other contexts - there is nothing special about this
particular 'customer' of SIP in this regard, so we really do need to solve
the root problem.

The root problem is this: A UA cannot place 'private' or 'potentially
private' information in the From or To fields.

This is because there is no mechanism defined to ensure that such
information is not passed to other UAs. In the absence of such a mechanism,
no requirements can be placed on what a UA does with the From/To fields. If
we do not place any requirements on these fields, then we cannot reliably
use them for anything.

We could argue about whether the very naming of the fields, examples in the
SIP spec, etc., define an implicit 'soft' requirement that they contain the
originator and desired destination (unless these are known to be private by
the UAC). The more we engineer this assumption into services, interworkings,
clients etc., then the more the implicit 'soft' requirement becomes in
practice an implicit 'hard' requirement.

We can see this already by the fact that a proposal in a particular system
to always include garbage in these fields causes such concern. People quite
reasonably want these fields to contain the real originator/destination.

In the case of a UA obtaining service from a public service provider, there
may be a requirement for the user to indicate their preferred originating
identity. This would naturally go in the From field, but it may be private
(to other UAs).

Equally, information which might usually be placed in From/To by the UA may
become private due to operation of services within the network. It would be
useful if this could be indicated in a simple way within a trust domain,
since modifying the From/To fields carries some cost.

My suggestions for what to do about this are:
1) We need to accept (and document) the fact that there will be many kinds
of privacy service, and many of these will require the modification of the
From/To fields. This cannot be done by Proxies (with 2543 compatibility), so
we must accept that any SIP-based public service offering (necessarily
incorporating privacy) cannot be based on proxies alone AND have 2543
compatibility.

2) Define a means for UAs to request privacy in respect of the From/To
fields (e.g. using a Generic URI parameter as proposed by Jon)

This would obviate the motivation for untrusted UAs to ever insert RPID. We
could change the privacy draft to differentiate between RPIDs received from
untrusted UAs and from untrusted proxies.

Regards...Mark

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 2 Apr 2002 08:55:21 -0600

Mark wrote:
-----

This is because there is no mechanism defined to ensure that such
information is not passed to other UAs. In the absence of such a
mechanism, no requirements can be placed on what a UA does with the
From/To fields. If we do not place any requirements on these fields,
then we cannot reliably use them for anything.
------

I think this is statement of the situation clearly brings out the
misunderstanding driving this whole thing.

This logic will eventually lead us to deleting all headers or bodies
provided by the UA in at attempt to enforce "privacy" against the wishes
of the actual user. It also precludes intentially authenticating the
user to a service on the other side of the home proxy, as such
authentication by definition is an exposure of private information.

I would restate as follows:

"The SIP protocol explicitly sends the From and To fields to the
destination UA. Therefore the sending UA should only insert information
in the From and To fields that is intended to be delivered to other UAs
and potentially displayed to the user of the other UA. If the user of
the UA wishes to remain anonymous, they must not insert any information
into the From or To fields which compromises this anonymity. This same
caveat applies to every other aspect of SIP, including headers and
bodies, except for those elements which are explicitly removed or
encrypted by intermediate elements known to the UA."

--
Dean

_______________________________________________
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