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 12:58:32 +0100

: (1) The user inserts their identity, but the subscriber of the outgoing
service being used requires outgoing sessions to be anonymous. Only the
outgoing proxy knows this - well, it's a B2BUA now.
[Peterson, Jon] One could just as easily argue that this is a requirement
not to force such services into the local outbound proxy. The UA could
always dynamically learn about privacy preferences from the service provider
in some fashion, and the service provider could reject requests (at the
local outbound) that don't conform to the privacy rules. And we should when
possible push SIP features to the endpoints anyway. 

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 ? 

(2) A calls B, who forwards to C. B requires privacy, but unfortunately A
has inserted B's identity in the To field. So the proxy performing
forwarding for B must modify the To field - OK, so it's a B2BUA too.
[Peterson, Jon] If B redirects A to C instead, we might get some better
leverage on this problem - that could be one way that B could 'require
privacy'. Today the SIP spec RECOMMENDs that the To field in the new request
following the redirection be the same as the To field in the original
request (although it says UAs MAY update the To and whatnot if they are so
inclined) - however, the spec also allows you to insert replacement headers
into the URL, like:

Contact: sip:[email-masked]?To=[email-masked]
<mailto:sip:[email-masked]?To=[email-masked]> 

I bring these points up not because I disagree that intermediaries providing
privacy and identity will often need to be More Than Just A  Proxy - but I
think there are reasonable attacks on the examples you happen to raise here
that don't require resorting to a B2BUA. Let's not be too quick to close
doors. 

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.

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.

...Mark

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Apr 2002 03:04:07 -0400

Off to "real work" for a week or two, and its amazing the length of some
threads that amass whilst I am not actively reading the list... anyway,
my comments inline.

Mark Watson wrote:
> 
> : (1) The user inserts their identity, but the subscriber of the
> outgoing service being used requires outgoing sessions to be anonymous.
> Only the outgoing proxy knows this - well, it's a B2BUA now.
> [Peterson, Jon] One could just as easily argue that this is a
> requirement not to force such services into the local outbound proxy.
> The UA could always dynamically learn about privacy preferences from the
> service provider in some fashion, and the service provider could reject
> requests (at the local outbound) that don't conform to the privacy
> rules. And we should when possible push SIP features to the endpoints
> anyway.
> 
> 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 ?

I agree with Jon that this is a reasonable approach. I had suggested the
same to some 3g folks in the past, to deal with the more generic
problem, which was that the user signed up for privacy services, but
"forgets" to put anonymous in the from field. 

> 
> (2) A calls B, who forwards to C. B requires privacy, but unfortunately
> A has inserted B's identity in the To field. So the proxy performing

IMHO, the notion of a network provided anonymous forwarding service is
primarily an artifact of the PSTN, where the locations of identity
information were easy to spot and remove. In an IP network, with a
protocol like SIP, you are kidding yourself if you think To/From is
sufficient to "cleanse". Identity information could be lurking in
headers both known and unknown. Some examples:

Subject: Hey, Bob, lets go for lunch
NewHeader: Bob once again
Call-Info: http://foo.com/picture-of-bob-and-me.jpg

and let us not forget the SDP too...

The only way in SIP to offer a useful (meaning, would actually work
reliably from the subscribers perspective) anonymous forwarding service
is to use a B2BUA "with a vengeance". This B2BUA would not propagate ANY
information from the original request, stripping everything, and
reformulating the mandatory headers on its own. It would probably need
to act as a media intermediary too. I would argue that, if you want an
anonymous forwarding service to be network provided, you really DONT
want a proxy in any sense of the word. THis would destroy services, of
course, but thats the penalty for this feature.

Arguing that only the To field needs to be stripped, because that is the
only thing the sip spec defines as identity, will hardly be comforting
to a user that depends on the proper functioning of this service.

> privacy'. Today the SIP spec RECOMMENDs that the To field in the new
> request following the redirection be the same as the To field in the
> original request (although it says UAs MAY update the To and whatnot if
> they are so inclined) - however, the spec also allows you to insert
> replacement headers into the URL, like:
> 
> I bring these points up not because I disagree that intermediaries
> providing privacy and identity will often need to be More Than Just A
> Proxy - but I think there are reasonable attacks on the examples you
> happen to raise here that don't require resorting to a B2BUA. Let's not
> be too quick to close doors.

IMHO, it would be more proper to reject the request outright, with some
kind of new status code indicating that the called party wishes to
forward the call anonymously. However, the problem remains that B now
has to trust A to properly strip all identifying information, not jus
the To field - a risky proposition. Effectively, B needs to ask A to
perform the same functions that B2BUA above provides....

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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