Subject: RE: [Sipping] History info and privacy

From: "Mark Watson" <[email-masked]>
Date: Fri, 20 Dec 2002 17:24:50 -0000

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

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 20 December 2002 16:57
> To: Watson, Mark [MOP:EP10:EXCH]; 'Elwell, John'
> Cc: [email-masked]
> Subject: RE: [Sipping] History info and privacy
> 
> 
> 
> 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. 
> 
> 
> -----Original Message-----
> 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]'
> Subject: RE: [Sipping] History info and privacy
> 
> 
> 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 
> > -----Original Message----- 
> > 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 
> > 
> > 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 20 Dec 2002 15:05:44 -0500

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.

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.

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.

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

_______________________________________________
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: "Cullen Jennings" <[email-masked]>
Date: Fri, 20 Dec 2002 13:55:43 -0800

My apologies - my comment was silly - I think all the conversation
leading towards better authorization and privacy are a good thing. I'm
sure we both have similar view on the importance of the assumptions of
what is trusted by who being critical to figuring out the overall
mechanism that is appropriate for different situations. In some case I
think SIP will be deployed in configuration similar to traditional
approaches and in other cases something very different. 

Cullen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Watson
Sent: Friday, December 20, 2002 9:25 AM
To: 'Cullen Jennings'; 'Elwell, John'
Cc: [email-masked]
Subject: RE: [Sipping] History info and privacy

Cullen,