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

From: Andrew Allen <[email-masked]>
Date: Mon, 11 Mar 2013 15:31:04 +0000

Cullen, Dale

> From: "Cullen Jennings (fluffy)" <fluffy at cisco.com>

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

[AA] response:

draft-allen  addresses this. The gr parameter is generated from the IME in the instance ID but is not the IMEI URN:

7.  3GPP Registrar Procedures

   In 3GPP IMS when the Registrar receives in the Contact header field a

   "sip.instance" media feature tag containing the GSMA IMEI URN

   according to the syntax defined in draft-montemurro-gsma-imei-urn-13

   [3] the registrar follows the procedures defined in RFC 5626 [1] and

   RFC 5627 [2] if those extensions are supported and indicated as

   supported by the UA.  If the Registrar allocates a public GRUU

   according to the procedures defined in RFC 5627 [2] the instance-id

   MUST be obfuscated when creating the "gr" parameter in order not to

   reveal the IMEI to other UAs when the public GRUU is included in non-

   register requests. 3GPP TS 24.229 [6] subclause 5.4.7A.2 defines the

   mechanism for obfuscating the IMEI when creating the "gr" parameter.

3GPP TS 24.229 ] subclause 5.4.7A.2 states:

If the "+sip.instance" header field parameter from the Contact address contains an IMEI URN, as specified in draft-montemurro-gsma-imei-urn [153], then the value of the "gr" SIP URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122 [154]. The following applies to the algorithm:

-              the namespace shall be a UUID generated for use across the administrative domain and shall use the algorithm for creating a UUID from truly random numbers specified in RFC 4122 [154];

NOTE:   If the generated UUID is changed, then newly created GRUUs will not match those that were created with the previous UUID. Therefore, the UUID needs to remain the same in order to create consistent GRUUs.

-              SHA-1 shall be used as the hash algorithm; and

-              the "name" is made up of a concatenation of the TAC and SNR portions of the IMEI from the "+sip.instance" header field parameter.

Andrew

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