Subject: RE: [Sip] Comment, SIP Privacy draft

From: "Mark Watson"<[email-masked]>
Date: Wed, 27 Mar 2002 10:16:36 -0000

I think we should be careful not to confuse 'scope' - what the mechanism
actually does/solves - with 'applicability' - environments in which it
actually works to provide this.

Used within the environment described in the applicability statement, the
mechanism *does* provide for a *certain level* of privacy to be maintained
whilst also supporting transfer of identity information.

This aside, I'd suggest that the broader privacy issue is very urgent. There
are many kinds of privacy service, but we can be sure that many of them will
require modification of the To/From fields, and so cannot be carried out at
a proxy (if you want 2543 compatibility).

In the absence of even minimal support for such privacy services to be
requested/performed, organisations such as 3GPP are forced into obfuscating
the To/From fields & defining proprietary mechanisms for transferring this
same information from UE to local proxy. I would suggest that this is a 'bad
thing' for SIP. Also, the arguments which lead them to doing this are much
more widely applicable than 3GPP networks, so others will be forced down the
same path in due course (IMO).

We are not going to solve the general privacy problem in time to prevent
this kind of messed up handling of To/From, but 3GPP networks at least do
fall within the scope of the privacy-04 applicability statement.

So, I think we do need something urgently which works within the
environments described in the Applicability Statement - whether it is this
draft or another one I do not care, as long as it happens soon.

What is needed is:
a) A way for network entities to assert 'private' identities, in the case
that To/From have been obfuscated due to privacy requirements
b) A way for users to request that privacy be applied to their identity,
whilst also allowing the user to indicate their desired identity to the
network

A draft which remains within the terms of the Applicability statement could
do this. Only 2-3 comments were made *on the list* during WGLC and we have
not made much attempt to resolve these. Perhaps those concerned that the
draft exceeds the applicability statement could provide detailed comments on
the sections they would like modified, or even a modified draft ?

Regards,

Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 27 March 2002 02:58
> To: 'Flemming Andreasen'
> Cc: [email-masked]
> Subject: RE: [Sip] Comment, SIP Privacy draft
> 
> 
> > > > I would argue that the draft goes outside its applicability 
> > > > statement anytime it discusses providing privacy.
> > 
> > This seems rather backwards to me. Are you saying that the 
> > applicability statement is an exhaustive listing of scope and 
> > requirements and anything that is not listed in there can by 
> > definiton not be mentioned in the document ?
> 
> Well, I'm suggesting that the draft SHOULD NOT include functionality
> that is clearly OUTSIDE the scope specified by the applicability
> statement. That's why we're getting the push back saying the 
> document is
> inconsistent with the AS. Why should a draft present 
> mechanisms to solve
> problems for which the draft declares itself "not applicable"? That
> means either adjust the scope of the draft, or adjust the scope of the
> AS, as needed and allowed by our "spirit guides" in the IESG . . .
> 
> > > As written, it DOESN'T provide
> > >
> > > > privacy. It provides a means whereby a user can REQUEST 
> > that network 
> > > > elements NOT PUBLISH additional information that, if published, 
> > > > would compromise privacy.
> > 
> > Well, it notes that there are different degrees of privacy 
> > and provides procedures for not only hiding this additional 
> > information, but also discussion about other headers that 
> > need to hidden. It also discusses IP address privacy, which 
> > will give you full privacy, however, at your request, the 
> > Anonymity header that used to solve this was removed, but the 
> > issue is still discussed.
> 
> Could I propose we abstract that discussion of privacy 
> concepts into the
> baseline of a general privacy requirements and definition doc? That
> would be cool! We need such a doc, and it would help manage the "Scope
> vs AS" issues on this doc.
> 
> > > I believe that "publish", in the context of this
> > > > document, means "distribute outside a group of proxies 
> > with a shared 
> > > > administrative policy of mutual trust."
> > 
> > Proxies or User Agents. Also, do not forget the call trace 
> > requirement, which was an integral part of the motivation 
> > behind this draft (of course per your argument, we now can't 
> > support call trace either since that's not part of the 
> > applicability statement).
> 
> Well, that gives us good reason to push back on the AS. OTOH, 
> I bet the
> security droids would chew on us less if the "sensitive" information
> were always cryptoprotected, as you propose to do to meet the
> call-traceback-from-outside-the-trust-domain requirement.
>  
> > > >
> > > > And I think it is the lack of mutual understanding 
> > agreement at this 
> > > > level that is the holdup.
> > 
> > I have no idea what the continued holdup is since there's 
> > rarely anything concrete on the table on the mailing list. It 
> > would be helpful if we got something from the people that 
> > have concerns.
> 
> Color me "concerned". 
> 
> --
> Dean
> 
> 
> _______________________________________________
> 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
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 27 Mar 2002 09:00:38 -0500

Mark Watson wrote:

>
>
> I think we should be careful not to confuse 'scope' - what the
> mechanism actually does/solves - with 'applicability' - environments
> in which it actually works to provide this.
>

Yes, yes, and yes.

>
> What is needed is:
> a) A way for network entities to assert 'private' identities, in the
> case that To/From have been obfuscated due to privacy requirements
>
> b) A way for users to request that privacy be applied to their
> identity, whilst also allowing the user to indicate their desired
> identity to the network
>

And

c)    Enable call trace

d)    Not require all "networks" to trust one another

-- Flemming

--
Flemming Andreasen
Cisco Systems