Subject: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00

From: Mayumi Munakata <[email-masked]>
Date: Wed, 01 Nov 2006 18:51:59 +0900

Hi all,

Thank you for everybody's comments for draft-munakata-sipping-privacy-clarified-00.

In order to put together the discussions so far, I try rewriting the latter half of the Table 1 as follows.

-----------------------------------------------------------------------
Target headers        user       header     session     id      history

Warning              modify
Record-Route                     strip(*1)
P-Asserted-Identity              delete?    delete?   delete
History-Info                     not add    not add             delete
Path                             strip(*1)
Referred-By          modify(*2)
Replaces
Service-Route                    strip(*1)
Target-Dialog        modify?
Identity-Info                    modify?

*1: "strip" means that privacy services operating on requests should
    remove all Via/Record-Route/Path/Service-Route headers that have
    been added to the request prior to its arrival at the privacy
    service and then should add a single Via/Record-Route/Path/
    Service-Route header representing themselves.  The server doing the
    stripping must restore the stripped value in the responses.

*2: Referred-By header will be modified when it appears in REFER request
    with Privacy:user that means the referrer's privacy is required.
    It should not be modified when it appears in INVITE request.

-----------------------------------------------------------------------

It seems that Warning, Path, Referred-By, Replaces, and Service-Route headers' manipulations were agreed, so I deleted the question marks. (Empty column of Replaces header means that the header is not a target for any priv-values.)

On the other hand, Target-Dialog header likely needs more discussion.
I personally agree Paul's opinion that Target-Dialog should not be modified considering the meaning of the header.

> - Replaces: this references specific state held by the target of the
>    request. It is obviously already known to the target, and the
>    request can't function without it. I don't see what can/should be
>    modified.
> 
> - Target-Dialog: same as Replaces.

A question about P-Asserted-Identity header is asked by Roland.

> My interpretation is that the P-Asserted-Identity is also a header
> 'which cannot be completely expunged of identifying information
> without the assistance of intermediaries'.
> So if the user includes 'header' the P-Asserted-Identity' shall
> also be anonymised.

Another question about Identity-Info header is asked by Shida as well.

> BTW, would you think identity-info, location header be a target
> as well for some of the priv-value(e.g. header) as it generally
> contains the domain name of the caller in URI form?
> 
> Now if identity is provided, one may doubt the motivation of
> requesting privacy but let's not forget that user requesting
> the privacy may have no idea sip-identity is provided as service.
> In which case it is completely reasonable for caller to request
> privacy even when the domain serving that user provides sip-identity.

I would like to hear people's opinions about these headers to be targets for any priv-values.

Thank you,
Mayumi

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 16:56:24 -0500

I'd like to take a step back here for a second.

I think the complexity here on how to do this is really illustrating 
that there is a larger architectural problem. The larger problem is the 
complexity involved in signaling privacy intentions from the UA, given 
the diversity of what such intentions might mean.

I also think its important to note that, AFAIK, the vast majority of SIP 
'privacy' that is deployed today, is just RFC 3325 and 'id' privacy. 
Thats it. This, to me, calls to a failure of RFC 3323 to achieve its goals.

I would suggest that much has changed since the publication of RFC 3323. 
In particular, we know have the tools that make it possible for a UA to 
populate a valid SIP message with fields which don't identify itself. 
This can be accomplished through a combination of TURN and GRUU. Given 
the UA can populate a message which doesn't identify itself, the real 
issue that remains is the service provider including information that 
identifies the user or the provider itself. Clearly, if the user 
includes anonymous identifiers in fields like From, this is a signal 
that an SP should not insert any headers or information that identify 
the user. As for identifying the provider itself - well, there is no 
helping that, since the provider must be identified for the call to 
work. Consequently, if a user wants to avoid having the provider be 
identified, they need to use a different provider entirely, one whose 
function is to be anonymous.

Much of this is discussed in:
http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-privacy-00.txt

which basically suggests deprecation of RFC 3323 entirely.

Before we spend many cycles on "fixing up" RFC 3323, I think we should 
step back and ask ourselves whether we want to even continue to pursue 
it as the vehicle for privacy in SIP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com