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

From: "Mark Watson"<[email-masked]>
Date: Fri, 5 Apr 2002 10:43:31 +0100

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

The implications of Data Protection in this environment are hard to fathom,
but I think it's only possible to understand them if you look at the
'service' that is being provided in a 'protocol-neutral' way. The Service
Provider is responsible for the operation of the service, full stop. - how
the implementation of the service is decomposed between devices is of not
interest to regulators etc.

If a Service Provider places certain requirements on a device, in order to
access the service, then the Service Provider is responsible in some sense
for the actions of the device in meeting those requirements - the device
could not do otherwise if it wants service. So you can't say that 'The UA is
responsible for the actions of the UA' when these are actions which are
*required* in order to access the service. In the majority case the Service
Provider provided the client anyway.

If part of the service is 'I'll carry any old piece of data you give me to
the called party' then obviously the responsibility for that data, and what
it contains, is entirely with the UA/user.

If part of the service is 'I'll carry the information you put in field X to
the called party, and by the way you should put your identity in field X',
then we are on much more dodgy ground, in particular when the identity of
the caller turns out to contain 'personal data' of someone else (e.g. the
subscriber).

In a service provider example, think of this from the point of view of the
subscriber. The subscriber has asked for all calls from this subscription to
be anonymous - they have a right to ask for this. I think the subscriber
would have a hard time if they tried to beat up the service provider because
one of the users specially configured their client to put their name in an
SMIME body - it is part of the service that bodies are carried transparently
(now if the subscriber wants a special 'body removal' service, then I'm sure
this could be arranged, at a price, though it sounds quite painful, not to
say terminal).

On the other hand, if the subscriber finds that all calls go through with
the name and SIP URL of the calling user in the From field, I think the
Service Provider would have a hard time arguing that they were taking
reasonable steps to ensure the subscribers wishes.

I'm not arguing that proxies need to be able to do this - I'm pointing out
that there are 'privacy services' which certain kinds of service provider
need to provide, which require More Than Just a Proxy, as Jon puts it. I
think it's important we understand this, as some people have the mistaken
impression that such 'privacy services' can be implemented on standard
proxies.

You seem to be arguing that privacy services in the network which modify
From/To are not required at all. This could only be the case if the
'From/To' information had the same status as, say, SMIME bodies in terms of
what the UA is required to put in there. OK, so the SIP spec does not state
a hard requirement on what should be put in there, but there is certainly a
clear implication that it should be the calling/called party identities and
indeed this *is what we want* to happen for the consistent operation of SIP
services.

We can obviously debate how responsible a Service Provider would be for
information inserted in the From/To field, when the Service Provider has not
made any hard requirements on the UA other than that they follow the SIP
spec. Service Providers in 3GPP are certainly of the view that the present
ambiguity in the SIP spec *does not* give them enough to be *sure* of
avoiding responsibility. They have two choices:
a) Accept the responsibility, and provide privacy services as I have
described
b) Decline the responsibility by explicitly requiring that the UA *does not*
put potentially private information in these fields

There is no option of 'Decline responsibility, but refer to the SIP spec for
what the UA does with these fields' - it is just not safe enough, given that
the clear implication and intention is that the UA puts identity information
into From/To. I *know now* that most clients will put personal data of the
subscriber in the From field. In 3 years time, can I really argue to a
regulator with integrity that I took reasonable steps to protect the
subscribers privacy if I do not modify this field ??

Other users of SIP will face the same dilemma - which option would you
prefer them to choose ?

...Mark

> --
> Dean

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 5 Apr 2002 19:15:44 -0600

RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva cy draft)
Mark wrote:
--------
You seem to be arguing that privacy services in the network which modify From/To are not required at all. This could only be the case if the 'From/To' information had the same status as, say, SMIME bodies in terms of what the UA is required to put in there. OK, so the SIP spec does not state a hard requirement on what should be put in there, but there is certainly a clear implication that it should be the calling/called party identities and indeed this *is what we want* to happen for the consistent operation of SIP services.
--------

Yes, that's exactly what I'm saying. Do we need to spit out a new draft "SIP Over Regulated Networks" saying "The stuff in the To and From and fields are user-provided information which will be delivered without modification to the termination point of the dialog"? which can the be referenced along with bis09 by implementors of  regulated services?

--
Dean

---

From: Chris Martin <[email-masked]>
Date: Sat, 06 Apr 2002 10:57:19 -0600

I have a few questions here regarding what it means and what it is that
is desired of privacy in the relation to SIP.

Are we asking to mask the identity of the calling party or provide
confidentiality or both? I am going to stick with what appears to be the
focus so far in mind, as I read the list, which is masking the true
identity. I am still digesting SIPS. 

In this case my assumption is that the topic surrounds commincations
within a service provider environment/doamin not a private individuals
SIP UA and the world, and that we dont need to do anything between
service provider proxy and calling SIP UA, so why add an extension or
additional header at all? I am also going to refer to service provider
customers as enterprise customers just for this exampe, they could just
as easily be SOHO customers.

In the case of a service provider, if we are asking to mask the
identity, as in a private number/username that we dont want disclosed to
the called, then it seems that it would be a bit simpler to maintain
that which is curently implemented in SIP, and just develop the privacy
mechanism as a feature on the SIP proxy, transparently to the Caller
(which has been provisioned due to the desire of the Caller to be a
private entity).

For example if a SIP Proxy recieves a request from the calling SIP UA,
it should then act normally on the request, with the exception that, at
this point it must modify all SIP Headers that contain information such
as IP adresses and usernames of the caller, to <[email-masked]>,
instead of [email-masked], and as a key to getting responses back to
the SIP UA, the SIP Proxy must maintain the Call-ID with modified host
information if there is any in the Call-ID. 

This leaves incoming requests to the SIP UA's, calling parties which
want to call this particular SIP UA, with privacy enabled, will have to
be privvy to the SIP UA actual information. This implies that a request
from a SIP UA within a SIP provider domain are really all that need to
be gaurded by the service provider. 

Example Request:

 F1 INVITE User A -> User B

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy <sip:[email-masked]>
   To: LittleGuy <sip:[email-masked]>
   Call-ID: [email-masked]
   CSeq: 1 INVITE
   Contact: <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=UserA 2890844526 2890844526 IN IP4 here.com
   s=Session SDP
   c=IN IP4 100.101.102.103
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

 F1 SIP Proxy -> User B

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy <sip:[email-masked]>
   To: LittleGuy <sip:[email-masked]>
   Call-ID: [email-masked]       /*SIP Proxies public address
   CSeq: 1 INVITE
   Contact: <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=UserA 2890844526 2890844526 IN IP4 here.com
   s=Session SDP
   c=IN IP4 100.101.102.103	/*may be actual SIP UA or B2BUA ip address
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

The only shady area here is the SDP portion which depending on the
environment it is assumed may or may not be a bad thing, since this
really depends on the enterprise policies at that point, and since DHCP
or a B2BUA may be implemented in many enterprise scenarios.

This sounds too simple to me but I wanted to know to what degree I am
wrong here, if I am at all. 

As for SMIME content, if this information is provided by the user it is
then the users problem, as is the case of enterprise security, and SIP
UA mis-configuration, which is easily detectable within the SIP
messages. This actually could be an value added service, detecting these
mis-configurations.  :^) 

Chris

_______________________________________________
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