Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 2 Mar 2013 23:33:43 +0000

Tom, my apologies for mis quoting you like this. 

On Jan 19, 2013, at 9:32 PM, Tom Taylor <[email-masked]> wrote:

> Those weren't my remarks. All I did on Nov. 20 was forward Andrew's note in readable form.
> 
> On 19/01/2013 11:49 AM, Cullen Jennings (fluffy) wrote:
>> 
>> On Nov 20, 2012, at 10:16 AM, Tom Taylor <[email-masked]>
>> wrote:
>> 
>>> Those that think privacy issues are insufficiently addressed need
>>> to explain why the IMEI is of significantly greater concern in
>>> terms of revealing privacy than the UUID when used as an instance
>>> ID.
>> 
>> That has been explained in detail multiple times. For one thing, the
>> user can't change the IMEI. For a second thing, it can be directly
>> mapped to a specific user in many cases.
>> 
>>> 
>>> In our view the security concerns raised have now been sufficiently
>>> addressed in the drafts and to a much higher bar than that of UUID
>>> in RFC 5626.
>> 
>> I strongly disagree.
>> 
>>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 2 Mar 2013 23:33:43 +0000

But the instance ID is in a register sent to trusted providers that know the users name, credentials etc and can be send in an encrypted channel. This is a bit different it that it goes to other users. The analysis is not at the same. 

On Jan 19, 2013, at 11:31 AM, Andrew Allen <[email-masked]> wrote:

> Cullen
> 
> To clarify these comments I think are your comments not Tom Taylor's (Tom simply forwarded my original post as it was rejected due to attached diff files).
> 
> Where does it state in RFC 5626 or anywhere else that an instance ID can be changed by the user?
> 
> In fact RFC 5626 states the opposite:
> 
> 	3.1.  Summary of Mechanism
> 		 Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled.  
> 
> And
> 
> 	4.1.  Instance ID Creation
> 
>  		Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [RFC2141] that uniquely identifies the device.  Usage of a URN
> 	  provides a persistent and unique name for the UA instance.  It also provides an easy way to guarantee uniqueness within the AOR.  This
> 	  URN MUST be persistent across power cycles of the device.  
> 
> So the instance ID is persistent (RFC 5626 wording) and does not change and is not changeable by the user. Whether the instance ID is a UUID or IMEI this does not change.
> 
> If an Instance ID containing a UUID is provided in a SIP request or response to another party then it can be stored as the instance ID of a device belonging to that user if their identity is known. Then if the same instance ID is provided again in a SIP request when the originating user requests anonymity then that user can potentially be identified by correlation with the stored instance ID.  
> 
> If I call you and your device rings and in the response I receive the instance ID I can potentially learn the Instance ID of the specific device even if it is a UUID.
> 
> This is the same regardless of whether the instance ID is a UUID or IMEI. In 3GPP usage the instance ID is never supplied to the far end party except for the case of emergency calls where the far end is a PSAP.
> 
> RFC 5626 does not seem overly concerned about this privacy issue as it has a very weak statement - prefer to omit is a far lower strength than MUST NOT or SHOULD NOT.
> 
> The only thing it states about it is:
> 
> 	4.1.  Instance ID Creation
> 
> 		One case where a UA could prefer to omit the "sip.instance" media feature  tag is when it is making an anonymous request or some other privacy concern 
> 	requires that the UA not reveal its identity.
> 
> 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect revelation of the Instance ID far more than is required by RFC 5626.
> 
> Andrew
> 
> -----Original Messsage-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
> Sent: Saturday, January 19, 2013 11:49 AM
> To: Tom Taylor; Gonzalo Camarillo
> Cc: [email-masked]
> Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
> 
> 
> On Nov 20, 2012, at 10:16 AM, Tom Taylor <[email-masked]> wrote:
> 
>> Those that think privacy issues are insufficiently addressed need to explain why the IMEI is of significantly greater concern in terms of revealing privacy than the UUID when used as an instance ID.
> 
> That has been explained in detail multiple times. For one thing, the user can't change the IMEI. For a second thing, it can be directly mapped to a specific user in many cases. 
> 
>> 
>> In our view the security concerns raised have now been sufficiently addressed in the drafts and to a much higher bar than that of UUID in RFC 5626.
> 
> I strongly disagree.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 2 Mar 2013 23:33:33 +0000

---

From: Andrew Allen <[email-masked]>
Date: Sun, 3 Mar 2013 22:53:23 +0000

Cullen

I don't fully understand your comment maybe because there are several grammatical or typing errors in the first two sentences.

Are you saying that in your view the instance ID being sent in a register request to a cellular service provider is an issue?

The IMEI is already transmitted to the cellular carriers from every GSM, UMTS and LTE mobile phone using the existing technology and this has been the case since the beginning of GSM (since about 1992). Also in CDMA the MEID (mobile Equipment ID) is sent to the CDMA network carriers in every CDMA network.

OR are you suggesting that we are sending the instance ID to other users - this we are NOT doing.

Andrew

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Mar 2013 15:21:33 -0500 (EST)

> From: "Cullen Jennings (fluffy)" <[email-masked]>
> 
> But the instance ID is in a register sent to trusted providers that
> know the users name, credentials etc and can be send in an encrypted
> channel. This is a bit different it that it goes to other users. The
> analysis is not at the same. 

This is a bit awkward to read, but I believe that your intention is:

    When the instance ID is in a REGISTER, it is sent to trusted
    providers that know the user's name, credentials, etc. already,
    and it can be sent in an encrypted channel.  This proposal (i.e.,
    draft-allen-dispatch-imei-urn-as-instanceid) is different in that
    the the GRUU containing the IMEI is sent to other users.  The
    analysis is not the same.

Please correct me if I'm wrong.

But assuming that I'm correct:  Yes,
draft-allen-dispatch-imei-urn-as-instanceid results in the IMEI being
sent to other users, embedded in the Contact GRUU.  And the privacy
analysis of that is different from that of a REGISTER.

The user that receives the IMEI-containing URI does not have a
database mapping the IMEI to the user's name or other data.  (Or at
least, I don't expect the service providers to make their database
available to subscribers.)

So the IMEI-containing URI is reduced from a personal identifier to a
"constant user fingerprint", an identifier that is associated with
just one person, but anyone who wants to make use of that fact has to
figure out themselves which person it is.

And that is the same as any with other GRUU.  If one's phone is using
a GRUU, any conversant can record the GRUU and one's name, and use it
to identify further calls from one's self.

Of course, if the user intends anonymity, the user can cause the UA to
obtain a temporary GRUU which is not a constant user fingerprint, as
is implied by section 8 of the draft.  We've already worked through
this problem.

Dale

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 10 Mar 2013 22:46:42 +0000

Dale, thanks for parsing that clarifying it. Yes that is what I meant.