Subject: RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva cy draft)

From: "Mark Watson"<[email-masked]>
Date: Wed, 3 Apr 2002 16:10:22 +0100

MW> I'm happy with any solution which works & the above sounds promising.
How would we get the privacy preferences to the UAC & is it backwards
compatible ? 
[Peterson, Jon]  It sounds to me like an instance of the general SIP UA
configuration problem - we already do have an action item to tackle that.
Sure, there's work to be done, but the same is true of the B2BUA approach.
Not sure what you're concerned about this being backwards compatible with,
exactly. 

MW2> RFC2543 clients - how can I ensure the subscribers privacy requirements
are met if the user has an RFC2543 client ? If I'm not worried about this
case, then my proxy can easily just modify the From field, since dialog
matching is based only on the tags. 

MW> The point I'm trying to make is exactly that intermediaries providing
privacy *will* often need to be More Than Just A Proxy, and I'm trying to
see if others on the list agree with this. Some of the 'Bad Things' that
people are concerned about with respect to From/To are happening because
people are trying to solve these privacy problems *without* realising that
they need More Than Just A Proxy.
[Peterson, Jon] Agreed (but we knew that). 

With respect to your example, I can't see that you could trust A's UA to do
this correctly, and there is no device that the new A->C call will pass
through which could reject it if A does not follow the rules in the new URI.
Passing the privacy requirements back to the UA is a good idea, but only
works if there are proxies in a position to reject requests where the UA has
not obeyed the privacy requirements.
[Peterson, Jon] I can't imagine that, in any network likely to interest you,
A wouldn't have a hardwired pre-loaded Route to its local outbound that
would ensure the A->C path has some adult supervision, and that the local
outbound would be in the redirection response path anyway (from the Vias on
the original A->B request). If it is so exceptionally paranoid about
misbehaving UAs, it could enact any number of policies to make sure that
nothing goes awry. 

MW2> So the outbound proxy keeps a note of the Redirection redirection
request going back to A and then policies new INVITES coming in to spot the
redirected call and enforce B's privacy request ? So I need to keep this
state information about outstanding redirect requests that have been passed
to A. I guess it could be done, but it does not sound too great. 

 But I wonder, do the regulatory constraints that make this a requirement
also levy a hefty fine on A if he reveals to C in the ensuing voice
conversation that he had originally dialed B? 

MW2> No, the constraint in this case is really on B's Service Provider. If
this Service Provider offers a forwarding service, then they also ought to
offer an 'Anonymous Forwarding Service' where B's identity is not revealed
to C *by the network*. There is nothing to stop A revealing B's identity to
C.

The problem with just using SIP redirection, is that B's Service Provider
would then have chosen an implementation of the Call Forwarding service
which intrinsically causes B's identity to be revealed to C. Again, I think
the B's Service Provider would be on dodgy ground if they tried to represent
this as an 'Anonymous Forwarding Service' on the basis that 'it wasn't me
wot revealed B's identity, it was that villian A'.

I'll admit it is an open question as to how the identities in SIP will be
interpreted by regulators. The regulatory constraints apply to third parties
(e.g. Service Providers) releasing identity information about the end
users/subscribers. Is the information in the From/To fields being supplied
by the Service Provider, or the end user themselves ?? From a technical
perspective, obviously, it's being supplied by the end user, but it's not
the technical perspective which is used to evaluate the effect of these
regulations, it's the customer's perspective, which is not related to the
technology.

If I as a Service Provider *require* that the end user insert certain
information in these fields, then I am clearly responsible for the insertion
of the information, so I think I inherit some responsibility for preventing
privacy breachs as a result of this.

If I require that end users use SIP-compliant clients, then we inherit all
the requirements of the SIP spec. As I argued before, there is certainly an
implicit 'soft' requirement that the To/From fields should contain the
called/calling party address.

So, I would find it hard as a Service Provider to credibly argue that I have
no responsibility whatsoever for the information placed in these fields by
my users' equipment, when I have required them to be SIP compliant and when
the SIP spec implies so strongly that this information will be there. In the
case of 3GPP it is clearer, because the 3GPP spec will explicitly state what
will or won't be in the To/From fields. That is why it currently explicitly
states that there should be garbage in there, so I can be sure I'm not
responsible for it!

 When the redirection with the Contact address I described in my last mail
arrives at A, A would have to intentionally countermand it in order to
reveal B's identity in the signaling. But A is of course empowered to reveal
B's identity through other means anyway. I have a hard time seeing what the
big deal is. B only remains anonymous at A's sufferance anyway. 

MW2> Again, it's the distinction between the devices supporting the service
(UAs, Proxies etc.) releasing the information because this is intrinsic in
the Service I am offering, and information being released entirely due to
the whim of the human users themselves. The former is regulated, the latter
is freedom of speech.

Anyway, after all that, I was only arguing (a) that in a Service Provider
model, protection of the subscribers privacy would require More Than Just a
Proxy and (b) that Anonymous Call Forwarding would require 'More Than Just a
Proxy'. (assuming RFC2543 compatibility in both cases).

In both cases, you have provided alternative implementations. For (a) I
think your proposal is not compatible with 2543 clients, and for (b) it
requires MTJAP anyway. I actually think that if you drop the 2543
requirement, then you arrive at better solutions for all this. The
overloading of To/From with two completely distinct functions (identity and
dialog matching) in 2543 is a real pain.

...Mark

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 4 Apr 2002 17:00:55 -0600

> RFC2543 clients - how can I ensure the subscribers privacy
requirements are met if the user has an RFC2543 client ? If I'm not
worried about this case, then my proxy can easily just modify the From
field, since dialog matching is based only on the tags.  
 
You can't. You can NEVER prevent a client from giving away his identity.
For exampe, they might add  an SMIME body conatining their name and a
URL to their home-nudie-pix site. At the very best, the privacy draft
documents a means by which a client requests the server not to add
additional private information over and above that which the client has
already seen fit to disclose.
 
The UA is reponsible for the actions of the UA. The proxy is only
responsible for the actions of the proxy . . .

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 04 Apr 2002 18:46:51 -0500

> not to add additional private information over and above that which
> the client has already seen fit to disclose.

And this restriction can only be relevant to a proxy that has a trust or
contractual relationship with the request origin. There is nothing,
morally, legally and technically, that a caller can and should do about
my inbound proxy adding whatever information my inbound proxy has legal
access to, even if that includes the google search result that reveals
that 'playboy' is the top site related to the caller's name.

I'd only wish that the privacy concerns expressed here could be
implanted into the louds using cell phones in public places.

> responsible for the actions of the proxy . . .

_______________________________________________
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