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

From: Andrew Allen <[email-masked]>
Date: Tue, 20 Nov 2012 17:13:58 +0000

WARNING: contains banned part

Subject: New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid submitted
From: Andrew Allen <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 20 Nov 2012 17:13:58 +0000

New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid were submitted at the beginning of October.

http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-instanceid-06.txt

http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt

There are not many major changes since the previous versions which were submitted in March and July which themselves were submitted after the conference call held between 3GPP and IETF interested parties in early January on the topic. Basically editorial updates and some strengthening of the normative language.

The main change in draft-montemurro-gsma-imei-urn since the previous version is to address the ABNF comment from Dale and it was decided we do not need parameters to have multiple values so Dale's proposed resolution has been adopted. The January version of draft-montemurro-gsma-imei-urn (09 version) added the following to the Security Considerations section to address the privacy concerns:

Further, because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI SHOULD NOT be included in messages intended to convey any level of anonymity.

In the latest (11 version) this has been strengthened from a SHOULD NOT to a MUST NOT.

The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was submitted in March incorporated a number of significant changes including:

1.    Additional text was added to the abstract stating:

[The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] that state "If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior."

2.    A new section was added describing the three 3GPP use cases

3.    A new section was added for 3GPP Registrar Procedures with the following text:

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-09[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 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] subcluase 5.4.7A.2 defines the mechanism for obfuscating the IMEI when creating the "gr" parameter.

4.    The security section was beefed up as follows:

Because IMEIs like other formats of instance IDs can be loosely correlated to a user, they need to be treated as any other personally identifiable information.  In particular, the "sip.instance" media feature tag containing the GSMA IMEI URN MUST NOT be included in requests or responses intended to convey any level of anonymity.  RFC 5626 [1] states "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".  The same concerns apply when using the GSMA IMEI URN as an instance ID.  Publication of the GSMA IMEI URN to networks that the UA is not attached to or the UA does not have a service relationship with is a security breach and the "sip.instance" media feature tag MUST NOT be forwarded by the service provider's network elements when forwarding requests or responses towards the destination UA.

In order to protect from tampering the REGISTER requests containing the GSMA IMEI URN MUST be sent using a security mechanism such as TLS [12] (or another security mechanism that provides equivalent levels of protection).

There do not seem to be any comments made against the draft-allen-dispatch-imei-urn-as-instanceid-05 version that was submitted in March. Not sure if this was because everyone was Ok with it or because it was overlooked.

At the conference call held between 3GPP and IETF interested participants in January at which privacy concerns about the use of the IMEI as an instance ID by 3GPP were raised. It was proposed during the conference call that the authors submit a new revision of the draft clarifying the use of the mechanism and explaining how the 3GPP architecture addresses the privacy issues that were discussed.

There was a further discussion at a following 3GPP meeting on these privacy concerns. During the 3GPP discussion it was pointed out that RFC 5626 already previously considered and addressed privacy concerns  with instance ID in section 4.1 which only states the "UA could prefer to omit the "sip.instance" media feature tag":

4.1.  Instance ID Creation

   To convey its instance-id in both requests and responses, the UA

   includes a "sip.instance" media feature tag as a UA characteristic

   [RFC3840].  This media feature tag is encoded in the Contact header

   field as the "+sip.instance" Contact header field parameter.  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.

draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid and the 3GPP specified usage of the IMEI already go considerably further than RFC 5626 does in this regard. Regardless of whether a UUID URN or the IMEI URN is used as an instance ID the privacy issues are the same since an instance ID based on a UUID is static once generated and therefore like the IMEI potentially reveals the identity of the caller if it can be correlated with the identity of that caller from a previous call.

The view in 3GPP was that the IMEI should not be of any greater concern when used as an instance ID than using a UUID. Asking 3GPP to go considerably further in addressing privacy concerns with use of IMEI as an instance ID than RFC 5626 already does was considered by many in 3GPP to be unwarranted. Describing fully all the potential uses with 3GPP IMS of instance ID and documenting all the security mechanisms in all scenarios is a really non-trivial task considering that many organizations outside 3GPP specify access networks for IMS and applications using IMS (OMA, GSMA, Cablelabs, 3GPP2, TISPAN, WIMAX Forum...) and outside the capability of the authors of the draft alone. In basic summary most if not all accesses to IMS provide for at least basic levels of transport security such as use of IPsec or TLS tunnels and/or access layer security (although there is no guarantee these will be always enabled by the every carrier). This goes beyond what is required by RFC 5626 which only recommends use of TLS even though the general internet is probably more open to attack than a managed carrier network.

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.

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.

The 3GPP use cases have now been described in draft-allen-dispatch-imei-urn-as-instanceid. It is my view that describing these uses as an instance ID also in draft-montemurro-gsma-imei-urn is both redundant and inappropriate since this draft does not define use of the IMEI as an instance ID.

So I would like to ask for review of these two latest drafts and to provide any comments. 3GPP urgently needs to progress these drafts which are needed to complete 3GPP Release 8.

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.