Subject: RE: [Sipping] History info and privacy

From: "Mark Watson" <[email-masked]>
Date: Wed, 18 Dec 2002 15:43:20 -0000

My opinion is as follows:

For the first aspect, that B may not wish A to be informed that the request
has been retargeted, or the address to which it has been retargeted, seems
valid. B should be able to specify this, in which case the proxy would not
send the History Information to A.

For the second aspect, the information that B is passing to A is just the
information 'B has retargeted this request to C'. This does not give A any
information about the validity or meaning of address C.

If B is not entitled to give this information to A (for example C has
requested that it should not be disclosed and local privacy laws require
such requests to be honoured) then B should configure their proxy to keep it
private (according to the first aspect above). The system should not need to
'police' such settings by referring to C in real-time before revealing the
information.

Regards,

Mark

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: 18 December 2002 15:14
> To: [email-masked]'
> Subject: [Sipping] History info and privacy
> 
> 
> I have a concern that I don't think is addressed by
> draft-ietf-sipping-req-history-00 and 
> draft-barnes-sipping-history-info-00.
> I have had some discussion with the authors, but after 
> failing to come to a
> conclusion on this particular point I would like to seek 
> further opinions.
> 
> Suppose a call from A towards B is retargeted by B's proxy towards C.
> Amongst other things the history-info draft provides a 
> History-info header
> to A (if A has indicated support for this header). This 
> header will reveal
> to A the request-URI of C. The question is whether this is a 
> good thing from
> a privacy point of view.
> 
> One aspect of privacy is that B might not wish A to know that he is
> retargeting his calls to C (or even that he is retargeting 
> his calls at
> all). 
> 
> A second aspect is that C might not wish A to know C's 
> identity. One example
> is where B is in a company and retargets his calls to a 
> colleague's home AOR
> (e.g., to [email-masked] as opposed to [email-masked]). The 
> colleague, C,
> has obviously made his home AOR available to B (and hopefully 
> has authorised
> B to target calls to that AOR). However, C may not have made 
> his address
> public and would not wish it to be disclosed to any caller A.
> 
> I would like opinions as to whether each of these privacy concerns are
> valid.
> 
> 
> John Elwell
> e-mail: mailto:[email-masked]
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 18 Dec 2002 10:01:44 -0600

John,

I'm in the process of updating the requirements and solution drafts.  So, we
may want to revisit your points after the updated draft is available, but
I'll go ahead and respond (as indicated by [MB] inline) and perhaps we'll
get additional feedback for the current revisions I have underway.

Mary.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 9:14 AM
To: [email-masked]'
Subject: [Sipping] History info and privacy

I have a concern that I don't think is addressed by
draft-ietf-sipping-req-history-00 and draft-barnes-sipping-history-info-00.
I have had some discussion with the authors, but after failing to come to a
conclusion on this particular point I would like to seek further opinions.

Suppose a call from A towards B is retargeted by B's proxy towards C.
Amongst other things the history-info draft provides a History-info header
to A (if A has indicated support for this header). This header will reveal
to A the request-URI of C. The question is whether this is a good thing from
a privacy point of view.

One aspect of privacy is that B might not wish A to know that he is
retargeting his calls to C (or even that he is retargeting his calls at
all). 
[MB] If B doesn't want A to have this information, then B's local privacy
policy can overrule the sending of the History-Info in the response to A. 

A second aspect is that C might not wish A to know C's identity. One example
is where B is in a company and retargets his calls to a colleague's home AOR
(e.g., to [email-masked] as opposed to [email-masked]). The colleague, C,
has obviously made his home AOR available to B (and hopefully has authorised
B to target calls to that AOR). However, C may not have made his address
public and would not wish it to be disclosed to any caller A.

[MB] This again relates to the local policy or a specific privacy policy
around C's AOR.  If such a policy is in place, then B should not provide the
History-Info to A that might reveal C's identity.   

John Elwell

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 19 Dec 2002 13:23:05 +0000

Mark,
 
The question is whether it is acceptable for C to rely on B to configure his
proxy appropriately.
 
Regards,

John

John Elwell
e-mail: mailto:[email-masked] <mailto:[email-masked]>  

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 3:43 PM
To: 'Elwell, John'; [email-masked]'
Subject: RE: [Sipping] History info and privacy

Regards, 

Mark 

> From: Elwell, John [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> e-mail: mailto:[email-masked] <mailto:[email-masked]>  
> 
<https://www1.ietf.org/mailman/listinfo/sipping>

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 19 Dec 2002 13:35:53 -0000

John,

Yes, I agree, but I do not see there is any other choice than for C to so
rely on B. In particular, history-info aside, if B's proxy uses redirect to
forward the call, rather then re-targeting, then A will discover C's
address.

...Mark

> Sent: 19 December 2002 13:23
> To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
> <mailto:[email-masked]>  
> 
> 
> <mailto:[email-masked]>  
> >

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 23 Dec 2002 09:53:57 -0000

Jonathan,

I am not trying to 'find fault' with SIP. I'm just trying to understand the
ways in which it is different from existing systems with respect to trust
and privacy. I'm not intending to imply that these differences are 'faults'
- just differences which we ought to understand. In many cases these
differences of course lead to features which just wouldn't exist in legacy
systems.

The point is with this example that the ISDN system implements C's privacy
preference based only on C communicating that to their own service provider
and the inherent trust relationships between Service Providers. The human
user at C does not have to arrange this with B & does not have to themselves
trust the human user at B or B's service provider. Even if C provides B with
a 'private identity' for use in forwarding there are still two problems:
1) B may not use it - if they happened to know C's normal identity too
2) repeated use of the same identity gives away something

To do this in SIP would require addition of some trust assumptions (namely
that B's proxy is 'trusted' by C's service provider in some to-be-specified
sense). Perhaps the difference I am getting at is just that this is always
assumed in ISDN, but SIP is designed to work without such assumptions as
well.

Couple of notes below.

...Mark

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 20 December 2002 20:06
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: 'Cullen Jennings'; 'Elwell, John'; [email-masked]
> Subject: Re: [Sipping] History info and privacy
> 
> 
> Mark,
> 
> I believe you are attempting to compare apples to oranges in 
> many cases 
> here.
> 
> If you want to make the same assumptions of trust for SIP as 
> you do in 
> ISDN, then it is easily possible to provide the same 
> capability in SIP 
> as ISDN. B would simply configure their proxy to always proxy (rather 
> than redirect), and C's server would strip out all history 
> info, provide 
> a privacy service, and so on. As a result of this, A never knows C's 
> identity.

'The same assumptions of trust' would imply that B's proxy is 'trusted' by
C's service provider to provide the privacy protection for C, indepenently
of any actions on the part of the human user at B.

> 
> If, on the other hand, you don't want to trust B to do this, C would 
> hand B a private identity to use for forwarding as I have suggested. 
> THen it is no longer dependent on B. This is the best you can do in a 
> network where you don't trust B, and that is the assumption here.
> 

Sure, but still B might know C's public address and might use this
non-the-less - against C's instructions. I can't see any way to protect
against this, nor any need to do so! As Cullen pointed out this is only 1
out of several million ways you could imagine that B might pass C's address
to others, most of which involve simpler technology than SIP (a pen for
example).

> So, the point is, you can build networks with very different 
> assumptions 
> about trust, and still provide this feature. Of course, the means by 
> which you provide it depends on the assumptions and network design. 
> Mark, I think you are finding fault with SIP because there 
> are network 
> architectures which differ from the ISDN, where the same-old-ISDN 
> feature doesn't work the way it does in the ISDN. I think it is 
> unreasonable to try and analyze SIP in this way.
> 

Well, I was kind of trying to do quite the opposite. I would certainly agree
that it is unreasonable to try and analyse SIP in terms of ISDN
architecture. Comparing the service aspects of the system as a whole from a
user perspective, though, is surely quite useful.

> -Jonathan R.
> 
> 
> Mark Watson wrote:
> > Cullen,
> > 
> > The discussion is not silly. It is important that we 
> clearly understand 
> > the differences between SIP and existing systems with 
> respect to these 
> > kind of privacy issues and equally important that we correctly 
> > understand the differing trust assumptions which underly 
> the different 
> > network systems.
> > 
> > Users, and more importantly, regulators, may well (falsely) 
> assume that 
> > future SIP-based systems will work in the same way as 
> existing systems 
> > with respect to some privacy aspect or other. Where this is 
> not the case 
> > we need to know it, we need to know why, and **we need to 
> be able to 
> > explain why it is not a problem.**
> > 
> > ISDN exchanges act for the network operator first and the 
> user second. 
> > They freely exchange information subject to privacy restrictions. 
> > Release of that information to end-users is controlled at 
> the very edge 
> > of the network. Operators trust each other with their 
> customers private 
> > information - they trust that it will not be released 
> because this is 
> > enshrined in interconnect agreements and they transitively trust 
> > downstream networks.
> > 
> > In SIP we do not have this level of trust. Asserted 
> Identity was all 
> > about introducing this model for a single piece of information for 
> > people who want to operate their systems that way. At the 
> time, I got 
> > the impression that people felt relying on such bilateral 
> agreements & 
> > transitive trust was a 'bad thing' and we should not assume it.
> > 
> > Without these kind of agreements you only expect a SIP node 
> to do what 
> > is in their own interests, so you can't send it private information 
> > unless you have some other reason to believe it will honour 
> the privacy 
> > restriction.
> > 
> > Your example exactly illustrates my point about this 
> particular ISDN 
> > privacy feature, though. The ability to stop B from revealing C's 
> > identity to A in this one specific case of call forwarding 
> in an ISDN 
> > network is not some vital required feature of any system, 
> just something 
> > the ISDN happens to do for ISDN calls. As you point out, 
> the feature 
> > doesn't stop B from revealing C's information some other way.
> > 
> > So, I don't think it is something we have to require in SIP, I just 
> > think we have to understand that it is a difference.
> > 
> > ...Mark
> > 
> >  > From: Cullen Jennings [mailto:[email-masked]]
> >  > Sent: 20 December 2002 16:57
> >  > To: Watson, Mark [MOP:EP10:EXCH]; 'Elwell, John'
> >  > Cc: [email-masked]
> >  > Let's say that the network elements A,B,C are operated 
> by the human
> >  > users Alice, Bob, and Chuck respectively. Now the Chuck 
> told Bob an
> >  > address that Bob can program into B that to be able to
> >  > forward calls to
> >  > C. If Bob takes this address and posts it on a bathroom 
> stall in a bar
> >  > that Alice goes to there is nothing that ISDN can do about it.
> >  >
> >  > This whole argument has diverged into the silly - It is 
> sounding like
> >  > the assumption is that every element in a ISDN networks 
> is trusted and
> >  > always does what it is supposed to and never leaks any 
> information and
> >  > that all SIP network elements are not trusted and do the 
> worst thing
> >  > possible the information they receive. With this 
> assumption, yes, they
> >  > two systems will different overall security properties.
> >  >
> >  > Cullen
> >  >
> >  >
> >  > PS. C' could be a address that was only usable once a new one was
> >  > generated each time.
> >  >
> >  >
> >  > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> >  > Of Mark Watson
> >  > Sent: Friday, December 20, 2002 8:02 AM
> >  > To: 'Jonathan Rosenberg'; Elwell, John
> >  > Cc: [email-masked]'
> >  > Well, there is still a difference between the solutions 
> below and the
> >  > ISDN case.
> >  > B may well know C's (non-private) identity, but not C's privacy
> >  > preferences. C may not have expected B to use their
> >  > non-private identity
> >  > for forwarding, and so has given them C and not C'. C may have
> >  > *instructed* B not to use the identity for forwarding 
> and B may have
> >  > *disobeyed* that instruction.
> >  > The ISDN service provides C with an opportunity, in real-time, to
> >  > prevent their identity being delivered to A - no matter how
> >  > many of C's
> >  > instructions B has disobeyed, and no matter what 
> mis-understandings
> >  > there were about privacy between B and C, the network 
> ensures that C's
> >  > preferences are honoured.
> >  > I don't think SIP can provide this kind of protection against
> >  > 'mis-understandings' and 'disobeyed instructions' 
> between human users,
> >  > because we do not have the same network of 'trusted' 
> elements that the
> >  > ISDN has.
> >  > I don't think this is a problem either, but it is certainly a
> >  > PSTN/ISDN
> >  > feature which is not available in SIP.
> >  > Btw - the C' approach does not work perfectly, because C' still
> >  > identifies C. Ok, so the first time A sees C' they do 
> not know who it
> >  > is, but on subsequent occasions they can glean some 
> information when
> >  > they see the same identity again. Also, C may not wish A 
> to know that
> >  > the call has been forwarded *at all*. This can only be done
> >  > by requiring
> >  > B to use retargeting, rather than redirect, and then 
> probably through
> >  > some privacy service as well.
> >  > Regards...Mark
> >  > > From: Jonathan Rosenberg [mailto:[email-masked]]
> >  > > Sent: 20 December 2002 15:28
> >  > > To: Elwell, John
> >  > > Cc: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
> >  > > Subject: Re: [Sipping] History info and privacy
> >  > >
> >  > >
> >  > >
> >  > >
> >  > > Elwell, John wrote:
> >  > > > Mark,
> >  > > > 
> >  > > > OK, this is a problem with redirects. Perhaps we just have
> >  > > to conclude that
> >  > > > this privacy feature that is available in ISDN/QSIG is not
> >  > > achievable in
> >  > > > SIP.
> >  > >
> >  > > Clearly that is not the case. Its just an issue of proper
> >  > > configuration
> >  > > at B's proxy. Indeed, I would argue that if C was so
> >  > concerned about
> >  > > their identity being revealed, they would provide B with an
> >  > alternate
> >  > > identity, C', which routes to a privacy service before
> >  > > getting forwarded
> >  > > to them.
> >  > >
> >  > > > It means C has to trust B not to use a redirect (unless it
> >  > > is sent back
> >  > > > to another trusted entity) and to configure B's proxy in a
> >  > > way that does not
> >  > > > disclose the identity of C back towards A.
> >  > >
> >  > > If C provides an alternate identity, as I propose 
> above, it doesn't
> >  > > matter whether B redirects or not.
> >  > >
> >  > > -Jonathan R.
> >  > >
> >  > >
> >  > >
> >  > >
> >  > > --
> >  > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> >  > > Chief Scientist                             First Floor
> >  > > dynamicsoft                                 East 
> Hanover, NJ 07936
> >  > > [email-masked]                     FAX:   
> (973) 952-5050
> >  > > http://www.jdrosen.net                      PHONE: 
> (973) 952-5000
> >  > > http://www.dynamicsoft.com
> >  > >
> >  > >
> >  >
> >  >
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
>