Subject: AW: AW: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt

From: "Jesske, R" <[email-masked]>
Date: Fri, 15 Sep 2006 09:33:37 +0200

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Donnerstag, 14. September 2006 20:26
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Betreff: Re: AW: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt
> 
> 
> 
> 
> Jesske, R wrote:
> 
> > The discussion shows how privacy could be interpreted. At least with
> > the 'header' privacy the origin user expresses that he want to be
> > anonymous. So it is an intension of the user. Of course the privacy
> > server can strip of the privacy value but that is due to 
> the Provider
> > of the server. Within RFC3323 I didn't found something that 
> says that
> > if you have privacy performed that you have to delete the privacy
> > header itself.
> 
>  From RFC3323:
> 
> >  When a privacy service performs one of the functions 
> corresponding to
> >    a privacy level listed in the Privacy header, it SHOULD 
> remove the
> >    corresponding priv-value from the Privacy header - otherwise, any
> >    other privacy service involved with routing this message might
> >    unnecessarily apply the same function, which in many 
> cases would be
> >    undesirable.  When the last priv-value (not counting 
> 'critical') has
> >    been removed from the Privacy header, the entire Privacy 
> header MUST
> >    be removed from a message.
> 
> 
> 
> > 
> > I'm against that we explicitly exclude the 'header' value for a
> > reason to send the 433 Response.
> 
> I'm not strongly opposed to it; I just think the semantics of the ACR 
> service are more strongly coupled to the presentation 
> identity, and not 
> other information in the request. For example, what if a user sent a 
> request that did NOT utilize id privacy, but did have header 
> privacy? In 
> such a case, the call would be delivered to the called party with 
> P-Asserted-ID, though would lack identifying information (like IP 
> address) in the Contact. Is this an anonymous request? 

I think this is one interpretation how the 'header' privacy is interpreted but looking into 3323 where 'header' is defined is says:

      header: The user requests that a privacy service obscure those
      headers which cannot be completely expunged of identifying
      information without the assistance of intermediaries (such as Via
      and Contact).  Also, no unnecessary headers should be added by the
      service that might reveal personal information about the
      originator of the request.

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.

I know that the 'id' privacy was defined in an extra context as a P-header draft but the general rules of SIP shall apply. So also the rules of RFC3323. 

Other thoughts?

Thank you and Best Regards

Roland

>From the 
> perspective of the called party, certainly not. Anonymity is only 
> observable to the called party through the 'id' Privacy tag, NOT the 
> header tag.
> 
> Thanks,
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Fri, 15 Sep 2006 09:44:32 +0200

> Von: Dean Willis [mailto:[email-masked]] 
> Gesendet: Donnerstag, 14. September 2006 20:29
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; [email-masked]
> > At least with the 'header' privacy the origin user 
> expresses that he want to be anonymous. So it is an intension 
> of the user. 
> > Of course the privacy server can strip of the privacy value 
> but that is due to the Provider of the server. Within RFC3323 
> I didn't found something that says that if you have privacy 
> performed that you have to delete the privacy header itself.
> 
> Does it? 
YES

I meant that when I make anonymisation in a server there is no rule that says that the privacy header itself must be stripped of. So that within a INVITE the headers itself are anonymised and the privacy indication in the privacy header itself will be kept.

>Do we have real scenarios where the "header" privacy option 
> does NOT imply that the originating user desires anonymity?

No, not that I know
> 
> Or is the case where a call goes out with a "header" privacy 
> value, but 
> includes an authenticated identity body or other non-header identity 
> mechanism simply an error?

With regard to the 'header' privacy I interpret that 'is' is a subset of the 'header' privacy. Please look at the other mail as answer to Jonathans mail where I described how I understand this issue.

> 
> If it is an error, what needs to be corrected, in terms of
> 
> 1) Changing any specifications?
> 
> 2) Run-time detection of and response to the error condition?

I think all is proper described with in RFC3323 and RFC3325

Roland

> dean

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 15 Sep 2006 09:57:03 +0200

Sorry I doubled your comment before.

That is also my interpretation and how people within TISPAN think.

Thanks and Best Regards

Roland

> Von: Shida Schubert [mailto:[email-masked]] 
> Gesendet: Donnerstag, 14. September 2006 23:17
> An: Dean Willis
> Cc: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]
> I personally think RFC3323 is underspecified with what headers to
> be obscured per privacy value. Interestingly though I found 
> the text in
> IANA consideration that is concise about what each privacy value's
> intent.
> 
> "Text from the IANA consideration of RFC3323
> 
>    o  user: Request that privacy services provide a user-level privacy
>       function
> 
>    o  header: Request that privacy services modify headers that cannot
>       be set arbitrarily by the user (Contact/Via)."
> 
> Considering the text above, if "header" was set any headers 
> that can not
> be set
> arbitrarily by the user needs to be obscured/modified by the privacy
> services, which
> I believe would include P-A-ID as well.
> 
> If that's the case, requesting "header" would naturally mean 
> requesting
> anonymity, as the
> domain supporting P-A-ID would alter the value of the P-A-ID to be
> anonymous as the
> text in IANA suggests.
> 
> My original interpretation of "header" privacy value was 
> actually quite
> different. I saw
> the "header privacy" as a way for UA to request some sort of topology
> hiding
> (obscuring Contact, via, headers revealing a path to the UA etc.).
> With that interpretation, I could see a scenario where 
> "header" privacy
> option does NOT
> imply that the originating user desires anonymity(e.g. I call 
> my client,
> I want to show them
> who I am but not wanting them to find out I am calling from 
> home.). But
> this can not hold true if the domain provides P-A-ID as 
> "header' privacy
> value will
> modify the header to obscure the identity of the user, thus 
> making it an
> anonymous call.
> 
> Regards
> Shida
> 
> Dean Willis wrote:
> > Jesske, R wrote:
> expresses that he
> >> want to be anonymous. So it is an intension of the user. Of course
> >> the privacy server can strip of the privacy value but that 
> is due to
> >> the Provider of the server. Within RFC3323 I didn't found something
> >> that says that if you have privacy performed that you have 
> to delete
> >> the privacy header itself.
> >
> > Does it? Do we have real scenarios where the "header" privacy option
> > Or is the case where a call goes out with a "header" privacy value,
> > but includes an authenticated identity body or other non-header
> > identity mechanism simply an error?
> >