The issue is that while the user may be wanting to use a public GRUU, they may not wish to announce their IMEI. Normally, no matter what privacy, IMEIs are kept secret in 3GPP.
You'll find procedures in the registration proxy in IMS to therefore obfuscate the IMEI when creating a public GRUU. And in 3GPP this was not directly an invention of the protocol group - part of this came from the 3GPP security group. regards Keith > -----Original Message----- > From: Shida Schubert [mailto:[email protected]] > Sent: Thursday, February 19, 2009 7:53 AM > To: DRAGE, Keith (Keith) > Cc: Michael Procter; > [email protected]; [email protected] > Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt > > > Keith; > > I just looked at outbound and gruu again, and AFAICT > temp-gruu doesn't carry the instance-id unlike the pub-gruu > which does. > > With outbound the instance-id is only present in the > REGISTER request when you are establishing the flow, and if > temp-gruu is used, the only time instance-id will be visible > when GRUU is used is also in the REGISTER request. > > I may be blind but I can't seem to see the problem. > > Regards > Shida > > On 18-Feb-09, at 10:53 AM, DRAGE, Keith (Keith) wrote: > > > There is a similar issue with the instance-id as used by > outbound and > > GRUU as well. In a mobile, this uses the IMEI which is not > necessarily > > meant to be revealed. > > > > 3GPP obfuscate the IMEI on generation of the GRUU. > > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] > On Behalf Of > >> Michael Procter > >> Sent: Tuesday, February 17, 2009 8:51 AM > >> To: [email protected]; [email protected] > >> Subject: [Sip] Comment on sip-ua-privacy-05.txt > >> > >> Just a minor point: Is it worth adding (either in section > >> 4.1 or 6) that a temp-gruu might not be as anonymous as you might > >> hope? An observer using RFC 3680 (reg-event) with gruu extensions > >> would be able to correlate temp-gruus with AoRs and > contacts, should > >> they be so authorised. > >> > >> There is some text in RFC 3680 warning of the risks of > reg-event, but > >> that is probably of more direct interest to registrar authors. A > >> reminder of the risk in this document might highlight it for UA > >> authors, so that they can consider the wider implications. > >> > >> Best regards, > >> > >> Michael > >> _______________________________________________ > >> 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 > > _______________________________________________ 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
