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

From: "Jesske, R" <[email-masked]>
Date: Thu, 14 Sep 2006 16:11:49 +0200

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.

I'm against that we explicitly exclude the 'header' value for a reason to send the 433 Response.

The point in section 3 that describes when it is assumed that the call was anonymous is from my point of view a list of examples. So I propose to point this out like:

3.  Server Behavior

A server acting on behalf of the called party, such as the UAS or a
   proxy in their domain, MAY generate a 433 (Anonymity Disallowed)
   response when it receives an anonymous request, and the called party
   refuses to fulfill the request because the requestor is anonymous.  A
   request is considered anonymous when the identity of the originator
   of the request has been explicitly withheld by the originator or on behalf of the originator.  The following cases show exampes where this occur: ...

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Mittwoch, 13. September 2006 22:36
> An: Dean Willis
> Cc: Jesske, Roland; [email-masked]; [email-masked]
> Betreff: Re: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt
> 
> 
> I agree with Dean. And to add to that, I'll also note that I view 
> 'header' privacy as much different than 'id' privacy. Header 
> privacy is 
> likely to be executed almost immediately, at the point of 
> origin. Thus 
> by the time the request reaches the terminating side there is no 
> 'header' value left since the privacy service stripped it. 
> The 'id' tag 
> in the Privacy header is explicitly different; its stripped 
> at the last 
> hop, not at the first.
> 
> Furthermore, any user that wants a level of anonymity associated with 
> 'header' is also likely to use 'id' at the same time, and thus the 
> service would be triggered from that. Any case in which 
> 'header' is used 
> but 'id' is not seems weird to me.
> 
> -Jonathan R.
> 
> Dean Willis wrote:
> 
> > 
> > On Sep 13, 2006, at 5:36 AM, Jesske, R wrote:
> > 
> >>> dy.
> >>>
> >>> In this Draft is described that:
> >>> The request contained a Privacy header field whose value was 'id'
> >>>       [3] or 'user'.  This explicitly excludes the 'header' and
> >>>       'session' privacy services, since those do not directly
> >>> convey the
> >>>       identity of the requestor.
> >>>
> >>> Why the value 'header ' is exluded?
> >>>
> >>> In RFC3323 is described that header:
> >>>       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.
> >>>
> >>> So from my understanding 'id' is a subset of 'header' because
> >>> the P-Asserted-Identity can only be deleted by untermediarities.
> > 
> > 
> > ID privacy is only a subset of header privacy if the 
> identity  mechanism 
> > is entirely header-based. It isn't always that way. IMS is  not the 
> > entire SIP world. RFC 3323 "header" privacy doesn't preclude  
> > non-header-field-based identity expressions, so ACR can't  
> automatically 
> > reject requests with "header" privacy.
> > 
> > Nor can ACR automatically accept a request that does NOT 
> have  "header" 
> > privacy.
> > 
> > In the specific case of ACR, we're trying to reject an 
> INVITE that  does 
> > not contain an explicit and intentional disclosure of the  
> requestor's 
> > identity. While the requestor's identity might "leak"  from 
> headers, 
> > only specific identity headers (or other identity  
> mechanisms, such as 
> > AIB) carry the sort of strong identity assertion  needed 
> for anonymous 
> > call rejection to work as expected.
> > 
> > Here's an example: Let's say the the Contact: header field 
> value in  my 
> > INVITE is really a reversible GRUU. That is, the GRUU 
> contains my  AOR. 
> > I use no other identity mechanisms.
> > 
> > I call you. You have ACR turned on. Is the fact that my 
> identity is  
> > encoded in the Contact: header field of my INVITE good 
> enough to keep  
> > you from rejecting my call?
> > 
> > I'd argue that it is not. Since we don't have a widely 
> accepted way  for 
> > assuring that the identity expressed in a Contact header field is  
> > valid, we really can't use this information for ACR.
> > 
> > 
> > -- 
> > 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
> > 
> 
> -- 
> 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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Sep 2006 14:26:17 -0400

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.

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 14 Sep 2006 13:28:45 -0500

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

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

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?

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?

--
dean

---

From: Shida Schubert <[email-masked]>
Date: Thu, 14 Sep 2006 14:17:28 -0700

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2006 00:34:46 -0400

This is a good point.

I did not think that the 'header' value applied to P-Asserted-ID.
Rather, the 'id' value does, which is defined specifically for this
purpose in RFC 3325. However I agree with you that *if* 'header' implied
removal of P-Asserted-ID, it becomes a superset of 'id' and then it
should be added to the list of things that define an anonymous call.

Perhaps Jon P. can comment on whether the intent was for 'header'
privacy to apply to P-Asserted-ID?

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 09:20:11 -0400

> should be added to the list of things that define an anonymous call.

I agree that the intent is not entirely clear. But like Jonathan I had 
interpreted the specs so that 'header' privacy did not remove 
P-Asserted-Identity. I just reviewed 3323 and 3325, and I think that is 
still the correct interpretation based on more or less the same logic 
Jonathan mentioned earlier:

- it is suggested that 'header' privacy be applied early on the call
   path. (Section 4.3: "It is RECOMMENDED that service providers couple
   the privacy service function with a local outbound proxy.")

- 'id' privacy must be applied late in the call path or else the
   P-Asserted-ID header isn't available to servers that need it.

- when the 'header' function is carried out, the 'header' token
   is to be removed. That is specified in section 5:

   "When a privacy service performs one of the functions corresponding to
    undesirable."

I guess the following strategy *could* be used to make the 'header' 
privacy level to be a superset of 'id' privacy:

- The outbound proxy it would hide most headers ,
   but would note that it isn't forwarding across a trust domain
   boundary and so not remove P-Asserted-ID.

- It would remove the 'header' token from the Privacy header,
   but because it hasn't completed the job by removing P-Asserted-ID,
   it must insert an 'id' token to ensure that is done later.

While that is a possibility, it seems like quite a stretch to me. I see 
no hints in either document that this kind of behavior is expected. It 
seems way more straightforward to treat them as independent options.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2006 10:41:15 -0400

Right.

So what this means for acr-code is that we are really at a stalemate 
here until its clear what RFC 3323 is supposed to mean. Its important to 
note that it is certainly not the job of acr-code to clarify this behavior.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 17:10:03 -0400

Here are some comments based on a fresh read of this draft.

	Paul

* Intro, second paragraph - typo:

s/to explicitly to indicate/to explicitly indicate/

* Section 3:

    "A server acting on behalf of the called party, such as the UAS or a
    proxy in their domain, MAY generate a 433 ..."

Is there any reason this is restricted to servers acting on behalf of 
the called party? While that is where is is likely to be most useful, I 
can see no reason to prevent a server acting for the calling party, or 
for an intermediary, from using this.

Regarding the controversy over what values of the privacy header might 
justify this response: Why don't we just say that any value in the 
Privacy header other than "none" or "critical" *may* be considered 
grounds for returning this response?

   "It is important to note that lack of a P-Asserted-Identity header
    field, in and of itself, is not an indication of anonymity.  Even
    though a Privacy header field value of 'id' will cause the removal of
    the P-Asserted-Identity header field, there is no way to
    differentiate this case from one in which P-Asserted-Identity was not
    supported by the originating domain.  As a consequence, a request
    without a P-Asserted-Identity is considered anonymous only when there
    is some other indication of this, such as a From header field with a
    display name of 'Anonymous'."

I'm not clear whether this is intended to have normative strength or 
not. I think not. If so, it would be better to make that explicit by 
making it a note or something. I think there is good logic here, but it 
may not suit everyone's policy. And I can see no reason to require this 
policy. If someone has the misfortune to be calling on a path that can't 
deliver the identity then they will not be able to successfully complete 
the call even if they are not overtly blocking their identity. But that 
is life - it is what the callee desires.

(Maybe this question is moot, since these are criteria gating use of 
something at MAY strength.)

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 21 Sep 2006 08:21:49 +0200

I agree so I would like to propose to write this section in more common words instead of waiting for the clarification of RFC3323. 

Roland

> Gesendet: Freitag, 15. September 2006 16:41
> An: Paul Kyzivat
> Cc: [email-masked]; Jesske, Roland; [email-masked]; 
> [email-masked]; [email-masked]; Dean Willis
> Betreff: Re: AW: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt
> 
> 
> Right.
>