Shida, I am just looking to have some appropriate discussion text in the relevant place or in the Security Consideration section.
On the one hand, as my last mail pointed out, the domain of the enterprise can itself disclose too much, and in such cases you would have to do as you suggest, i.e., a third party GRUU or an anonymisation service. On the other hand, I could imagine that for some enterprises the policy might forbid hiding of their domain name, in which case there is no problem. John > -----Original Message----- > From: Shida Schubert [mailto:[EMAIL PROTECTED] > Sent: 31 July 2008 22:14 > To: Elwell, John > Cc: Mayumi Munakata; SIP IETF > Subject: Re: [Sip] Comments on draft-ietf-sip-ua-privacy-02 > > > Hi John; > > I understand for enterprise or SOHO, domain name itself > may give away who the caller is. > > We can add the text describing the implication of domain > name contained in the request for enterprise and SOHO > etc. And provide a workaround by using 3rd party Registrar > / Proxy (anonymization service) OR we can suggest that > UA falls back to the use of privacy:header defined in > RFC3323, which doesn't ensure any assurance that you > get the privacy you desire but if there is a privacy service > along the signaling path sufficient privacy will be provided. > > I am content with suggesting the use of anonymization > service, but this will mean that depending on the call, UA > needs to distinguish the set of proxy/registrar to use based > on the user's intent/action (e.g. pushing anonymous button on the > phone?). > > Any other suggestion for a workaround? > > Regards > Shida > > On 31-Jul-08, at 6:35 PM, Elwell, John wrote: > > > Mayumi, > > > >> -----Original Message----- > >> From: Mayumi Munakata [mailto:[EMAIL PROTECTED] > >> Sent: 31 July 2008 13:28 > >> To: Elwell, John > >> Cc: SIP IETF > >> Subject: Re: Comments on draft-ietf-sip-ua-privacy-02 > >> > >> John, > >> > >> Thank you for the comments on ua-privacy draft. > >> > >> See inline. > >> > >>> 1. I think there should be something pointing out the > >> limitations of > >>> GRUU for obtaining an anonymous contact URI. > >> > >> Will add the text to mention it. > >> > >>> A temporary GRUU will still > >>> reveal the issuing domain, i.e., the domain with which the user > >>> registers. For the From URI we specify > >> sip:[EMAIL PROTECTED] > >>> (except where SIP Identity is used), but I don't see the > >> point in this > >>> if Contact reveals the domain. > >> > >> That's true. There is no point to conceal the user's > >> domain name in the From header if the same domain name > >> appears in the Contact header. > >> > >> However, there is an option to use a third-party GRUU server > >> to get a temp-gruu that doesn't reveal the use's domain name. > >> > >> Anyway, the user's domain name is not considered as > >> critical privacy-sensitive information in this draft. > >> So it should be concealed only if that doesn't ruin more > >> important functions such as routing and authentication. > > [JRE] As discussed at the meeting, for a small enterprise the domain > > name is almost certainly critical. Somebody might guess the > particular > > caller, or maybe just knowing the name of the enterprise is > > information > > you don't want to disclose. Even for a large enterprise, the caller > > might be guessed if the callee only knows one person or a > small number > > of people from that enterprise. I would say that for an > enterprise the > > domain name is very likely to be critical privacy-sensitive > > information. > > I agree that for a sizeable service provider it might not > be critical. > > > > John > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
