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

From: "Jesske, R" <[email-masked]>
Date: Wed, 13 Sep 2006 12:36:18 +0200

Sorry that I forgot to change the Issue. here again.
> Still a open coment I made already. 
> 
> 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.
> 
> Best Regards
> 
> Roland
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Drage, Keith (Keith) [mailto:[email-masked]] 
> > Gesendet: Mittwoch, 13. September 2006 08:51
> > An: [email-masked]
> > Betreff: [Sip] SIP WGLC reminder
> > 
> > 
> > A reminder that both
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-02.txt
> > 
> > And 
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i
> dentity-01
> .txt
> 
> Are currently in WGLC and we are expecting comments by 
> 
> Monday 18th September
> ---------------------
> 
> As yet neither document has sufficient indication of review 
> to submit to
> the IESG. Neither of these documents is particularly long or complex.
> Please review and submit comments. If you have no comments please say
> so.
> 
> Your reviews are the only way (without just killing the work) that we
> can get documents published by the SIP group. Please review.
> 
> Regards
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> [email-masked]
> tel: +44 1793 776249
> 
> _______________________________________________
> 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: Dean Willis <[email-masked]>
Date: Wed, 13 Sep 2006 10:56:41 -0500

On Sep 13, 2006, at 5:36 AM, Jesske, R wrote:
>> dy.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 16:35:46 -0400

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:

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

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