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

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 7 Jan 2013 13:10:20 +0200

Folks,

I would like to get more comments on these two drafts before moving
things forward. Now that the Christmas break is over, please have a look
at them and send your comments to this list.

Thanks,

Gonzalo

On 27/11/2012 1:00 PM, Gonzalo Camarillo wrote:
> All,
> 
> as you can see in the email below, Andrew believes that the current
> versions of these drafts address all concerns that were previously
> discussed on this list. Those concerns mostly related to
> interoperability (what happens with UAs that do not have an IMEI) and
> privacy (whether a UA can choose not to send its IMEI in order to
> preserve its user's privacy).
> 
> With respect to the URN definition (in the montemurro draft), it needs
> to also be discussed on the [email-masked] list, per RFC 3406.
> 
> The SIP usage (specified in the allen draft), needs to be reviewed on
> this list. So, please, have a look at the current versions of these
> drafts and send your comments to the list.
> 
> I have already talked with the editors of these drafts so that they are
> responsive. Getting people to reload the state related to these drafts
> into the heads is a lot of work for everyone. So, I would like to
> discuss these drafts one last time and make a *final* decision (whatever
> it is) shortly.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> On 20/11/2012 7:16 PM, Tom Taylor wrote:
>> Andrew's original note appeared to me at least as a brief message:
>> "WARNING: contains banned part", with attachments. As a public service,
>> I have extracted and reproduced the text of his message. Hope this isn't
>> a duplicate from others' point of view.
>>
>> Tom Taylor
>>
>> Andrew's message:
>> ==========================
>> 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.
>>
>> Attached are diffs between the 04 and 06 versions of
>> draft-allen-dispatch-imei-urn-as-instanceid and between the 09 and 11
>> versions of draft-montemurro-gsma-imei-urn.
>>
>> 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
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 18 Jan 2013 13:37:38 +0200

Folks,

at this point, the authors are going to revise the draft to address
Dale's comments and send it to the URN list for feedback.

If you have comments on this draft, please send them to this (DISPATCH)
list shortly.

Thanks,

Gonzalo

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 19 Jan 2013 16:49:04 +0000

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, 19 Jan 2013 16:50:08 +0000

I would like to point out that several of my comments, including the one about IPR, had never been addressed. 

On Nov 20, 2012, at 10:16 AM, Tom Taylor <[email-masked]> wrote:

> Andrew's original note appeared to me at least as a brief message: "WARNING: contains banned part", with attachments. As a public service, I have extracted and reproduced the text of his message. Hope this isn't a duplicate from others' point of view.
> 
> Tom Taylor
> 
> Andrew's message:
> New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid were submitted at the beginning of October.
> 
> 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:
> 
> 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:
> 
> [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."
> 
> 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.
> 
> 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":
> 
> 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.
> 
> 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.
> 
> Attached are diffs between the 04 and 06 versions of draft-allen-dispatch-imei-urn-as-instanceid and between the 09 and 11 versions of draft-montemurro-gsma-imei-urn.
> 
> 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

---

From: Andrew Allen <[email-masked]>
Date: Sat, 19 Jan 2013 17:31:40 +0000

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

   		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:

		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

I strongly disagree.

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

---

From: Andrew Allen <[email-masked]>
Date: Sat, 19 Jan 2013 17:36:07 +0000

Cullen

An IPR declaration on these drafts was made over 3 years ago so I think the IPR situation and terms are well known.

I think Dale Worley  in some much earlier thread also explained why in his view this should not be an issue preventing progress of the draft. I concur with Dale on that.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
Sent: Saturday, January 19, 2013 11:50 AM
To: Tom Taylor
Cc: [email-masked]
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted

> 
> 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 whic
 h only recommends use of TLS even though the general internet is probably more open to attack than a managed carrier network.

---

From: Tom Taylor <[email-masked]>
Date: Sat, 19 Jan 2013 22:32:57 -0500

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:
>> 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.
>
>>
>> addressed in the drafts and to a much higher bar than that of UUID
>> in RFC 5626.
>
> I strongly disagree.
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 21 Jan 2013 19:29:21 -0500 (EST)

> From: "Cullen Jennings (fluffy)" <[email-masked]>
> 

It would be very helpful to me if you could give us a listing of which
specific comments and concerns have not been addressed to your
satisfaction.  You could do this by referencing the archived e-mail
messages, but I would be better informed if you copied and edited them
to remove parts that you think have been properly addressed, updated
the wording to fix any ambiguities that have been discovered, and
clarified the arguments in whatever ways have been revealed in the
following discussions.  As things stand now, I'd have to review all of
your messages for the past several months, and cross-correlate them
with all of the discussions, before I could start to think about your
objections...

Dale