Subject: Re: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 25 May 2013 23:21:39 +0000

I do have a question.

This new RFC to be drafted would appear to be doing nothing more than a spec (T), which does not require an RFC to be published.

So why not just a requirement to document rather than somehow have to put it out as a RFC.

Surely that is just trying to turn the IETF into the policeman

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 29 April 2013 07:29
To: [email-masked]
Subject: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid

In order to make progress on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid a conference call was held on Wednesday

April 17 attended by Culllen Jennings, Atle Monrad, John Luc Bakker and myself.

Below are the combined notes and summary from Cullen and I of this call on the IMEI drafts:

1) change draft-allen-dispatch-imei-urn-as-instanceid to say IMEI is only used in either a register request or also in an emergency invite request

Cullen will then be OK with it from a privacy point of view as long as it explains the trade offs.

It should be highlighted in draft-montemurro-gsma-imei-urn that using the IMEI as a security credential is a bad thing even though some popular commercial applications are actually doing this and some service providers are using knowledge of the IMEI to verify the legitimacy of caller being the authorized user/owner of the device. The IMEI is usually extremely easy to obtain by anyone who has very brief physical access to the device as it is often printed on the device beneath the battery and can be displayed by using a well-known key press sequence.

Change draft-allen-dispatch-imei-urn-as-instanceid to not be open to any extension to URN but instead require a draft updating this draft if any parameter other than ver=0 was to be included.  Also add text in draft-montemurro-gsma-imei-urn and, draft-aindicating that extensions to the IMEI parameters will require an update of draft-allen-dispatch-imei-urn-as-instanceid.

2) Write a new separate draft that tries to deal with the OMA push to talk case.

This would have the UA include the IMEI in an INVITE request in very particular instances where the UA knew that request was going to the POC server and that the POC server would remove it. I'm not sure what I would think of this draft - Cullen might hate it - but regardless of if folks thought it was good or bad, splitting it into a separate problem can allow the use in the first draft to proceed. Cullen would want this draft to be very clear on how a UA knew it was "safe" to put the IMEI in a INVITE and Cullen does not think the IME should ever be in an anonymous INVITE.  The current text around you only include the IMEI if you know it is safe does not seem implementable so Cullen would prefer something where it was really clear when the UA did it and when it did not. Cullen thinks this is much easier to do in the specific case of push to talk than trying to solve it for all uses of an INVITE so this should be easier to get people on board with than the current draft.

Response to Cullen on the IME should never be in an anonymous INVITE point. - in 3GPP networks there is really no such thing as an anonymous INVITE since the P-CSCF always knows the identity of the UE and will always include a P-Asserted-Identity header field. There are instead requests where privacy is requested and the  P-Asserted-Identity header field is removed at the edge of the trust domain. Thus in my view there is no need for a UE in the PoC case where it knows the PoC Server will remove the instance ID to prohibit inclusion of the IMEI. Cullen any comments to that?

3) Update draft-montemurro-gsma-imei-urn security section to clarify that the IMEI-SV is not updated based on the OS version or when new applications are added but represents the software version of lower layer software that has completed certification testing.

I am in the process of updating the drafts as described above.

Comments on the above are of course welcome

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.